ca.portal.admin

Re:Copy IBM/IDMS files

Discussion created by ca.portal.admin on Apr 18, 2008
I have a lot of IDMS files to copy (and rename) to other packs. I cannot
use FDR or DFDSS. So that leaves me with IEBGENER.

I have nothing against 'gener but I have to preallocate the files first
before I copy them. Is there a utility or something else to copy BDAM
files without preallocating them first? Of course this doesn't involve
GDG's.



Thanks.



J. Wayne Doneker

BAE Systems

York Pa.,

717 225 8109

John.Doneker@baesystems.com
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Database Procedures
"All,

I know that you are not supposed to put DML statements in a database procedure (though I don't know the reason). What I am wondering is.... would the same restriction apply if you placed a call in the procedure and had the DML performed in the called module be allowed.

The situation is this:

We currently have a database procedure that sets a field to 'y' before store and modify of our person record.

There are two batch programs that walk all the person records to find the ones with the 'y' in field. (one retrieval one to reset the field to spaces). At present we have approximately 1.13 million person records and on a daily basis between 2,000 - 6,000 have been updated with the 'y'.

We would like to only have to read/update the records marked with the 'y' and are thinking of using an Optional Manual index to do this (connecting the record when the 'y' is added and disconnecting it when the batch program removes the 'y'). However, the no DML rule is hindering this idea. We of course realize we could add the connect to every program that stores/modifies the record. But we are big enough and have enough turnover in staff that I do not feel comfortable with the idea of leaving the connection to the memories of the programming staff.

So, if anyone can enlighten me as to why no DML in a database procedure and/or if the called module would be an alternative it would be greatly appreciated. Of course if you have any other ideas as to how to identify these records I am open to that as well.

Thanks
Scott Van Der Heyden
State of Iowa Dept. of Human Services
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Database Procedures
"Hi Scott:

Any program that calls a subprogram is merely a technical convenience, as
the 'subprogram' essentially operates as an extension of the caller (unless
you do an ATTACH). Thus, as far as a database procedure is concerned, there
would be no difference if the DML was physically in the procedure or the
called subroutine.

There are numerous reasons for NOT doing DML in a database procedure
(including but not limited to):

1. You could issue DML that would recursively trigger the procedure.
2. You could issue DML that would cause a deadlock.
3. You could issue DML that would cause a wait.

Any of the above are particularly undesireable, so you definitely want to
avoid DML (especially 'update' DML) in a database procedure. Since your
procedure is called for a STORE/MODIFY, doing a CONNECT/DISCONNECT would not
cause recursion (#1), but you can't avoid #2 or #3, or other potential
""issues"".

I think the OM set is probably a good idea, but you'll either have to add
the logic to your programs or add a call to a subroutine from those
programs.

Regards,

Tom Schoenborn
TASchoenborn@msn.com

----- Original Message -----
From: ""VanDerHeyden, Scott"" <svander@DHS.STATE.IA.US>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Friday, April 18, 2008 12:08 PM
Subject: Database Procedures


All,

I know that you are not supposed to put DML statements in a database
procedure (though I don't know the reason). What I am wondering is....
would the same restriction apply if you placed a call in the procedure and
had the DML performed in the called module be allowed.

The situation is this:

We currently have a database procedure that sets a field to 'y'
before store and modify of our person record.

There are two batch programs that walk all the person records to
find the ones with the 'y' in field. (one retrieval one to reset the field
to spaces). At present we have approximately 1.13 million person records
and on a daily basis between 2,000 - 6,000 have been updated with the
'y'.

We would like to only have to read/update the records marked with
the 'y' and are thinking of using an Optional Manual index to do this
(connecting the record when the 'y' is added and disconnecting it when the
batch program removes the 'y'). However, the no DML rule is hindering
this idea. We of course realize we could add the connect to every program
that stores/modifies the record. But we are big enough and have enough
turnover in staff that I do not feel comfortable with the idea of leaving
the connection to the memories of the programming staff.

So, if anyone can enlighten me as to why no DML in a database procedure
and/or if the called module would be an alternative it would be greatly
appreciated. Of course if you have any other ideas as to how to identify
these records I am open to that as well.

Thanks
Scott Van Der Heyden
State of Iowa Dept. of Human Services
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: [IDMSVENDOR-L] Database Procedures
"
or add an unlinked (MA) index on the flag into the same area as the host
record- normally i would not advise this - but this way
all programs that would use the index need NO program changes (i think)

just the program(s) that reads the index would need to be aware of the
index .....




Chris Hoelscher
Senior IDMS & DB2 Database Administrator
Humana Inc
502-476-2538
choelscher@humana.com






Tom&Susan
Schoenborn
<schoents@COMCAST To
.NET> IDMSVENDOR-L@LISTSERV.IUASSN.COM
Sent by: IDMS cc
3rd-party
providers forum Subject
<IDMSVENDOR-L@LIS Re: [IDMSVENDOR-L] Database
TSERV.IUASSN.COM> Procedures


04/18/2008 03:06
PM


Please respond to
IDMS Public
Discussion Forum
<IDMS-L@LISTSERV.
IUASSN.COM>






Hi Scott:

Any program that calls a subprogram is merely a technical convenience, as
the 'subprogram' essentially operates as an extension of the caller (unless
you do an ATTACH). Thus, as far as a database procedure is concerned,
there
would be no difference if the DML was physically in the procedure or the
called subroutine.

There are numerous reasons for NOT doing DML in a database procedure
(including but not limited to):

1. You could issue DML that would recursively trigger the procedure.
2. You could issue DML that would cause a deadlock.
3. You could issue DML that would cause a wait.

Any of the above are particularly undesireable, so you definitely want to
avoid DML (especially 'update' DML) in a database procedure. Since your
procedure is called for a STORE/MODIFY, doing a CONNECT/DISCONNECT would
not
cause recursion (#1), but you can't avoid #2 or #3, or other potential
""issues"".

I think the OM set is probably a good idea, but you'll either have to add
the logic to your programs or add a call to a subroutine from those
programs.

Regards,

Tom Schoenborn
TASchoenborn@msn.com

----- Original Message -----
From: ""VanDerHeyden, Scott"" <svander@DHS.STATE.IA.US>
To: <IDMS-L@LISTSERV.IUASSN.COM>
Sent: Friday, April 18, 2008 12:08 PM
Subject: Database Procedures


All,

I know that you are not supposed to put DML statements in a database
procedure (though I don't know the reason). What I am wondering is....
would the same restriction apply if you placed a call in the procedure and
had the DML performed in the called module be allowed.

The situation is this:

We currently have a database procedure that sets a field to 'y'
before store and modify of our person record.

There are two batch programs that walk all the person records to
find the ones with the 'y' in field. (one retrieval one to reset the field
to spaces). At present we have approximately 1.13 million person records
and on a daily basis between 2,000 - 6,000 have been updated with the
'y'.

We would like to only have to read/update the records marked with
the 'y' and are thinking of using an Optional Manual index to do
this
(connecting the record when the 'y' is added and disconnecting it when the
batch program removes the 'y'). However, the no DML rule is hindering
this idea. We of course realize we could add the connect to every program
that stores/modifies the record. But we are big enough and have enough
turnover in staff that I do not feel comfortable with the idea of
leaving
the connection to the memories of the programming staff.

So, if anyone can enlighten me as to why no DML in a database procedure
and/or if the called module would be an alternative it would be greatly
appreciated. Of course if you have any other ideas as to how to identify
these records I am open to that as well.

Thanks
Scott Van Der Heyden
State of Iowa Dept. of Human Services


The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.

"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: Database Procedures
"NO! NO! NO! NO!

A procedure CANNOT, FOR ANY REASON, issue a DML verb when it is executing.
The reason is that the VIB is SERIALLY reusable, not asynchronous. If you
issue a DML verb from within the procedure you will corrupt the VIB and no
telling what will happen to the rununit that is executing at the application
level.

The reason you can issue a queue related command is because queue processing
takes place in a different rununit, a SYSTEM rununit, and therefore a
different VIB.

Chuck

Outcomes