Bill, the COBOL calls, as opposed to the idmsdc transfer controls could
be expensive. At one time idmsdc was enhanced with an svc screen to
trap getmains to initialize the cobol run time environment and turn
those into getstorage calls from an idms storage pool. For some reason
which I never fathomed, some users cant or wont change their cobol
source into idmsdc dml. I do believe transfer control is the preferred
way. The problem has always been the mvs service requests that cobol
programs did, and the storage(loads, etc) that mvs carved out of idms
regions beyond idms control. Also some mvs storage may be freemained,
but not reusable until idms comes to mvs job termination.
Lutz Petzold
-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
ca-world 2005
"Hi everyone,
Just to let you know that early bird registration has been extended to
Monday, september 19th 2005. If you register by that date, you can get
$200 off the registration fee. If you're a member of a ca recognised
user group, like the IUA, you can get an additional $200 off.
Please visit
www.ca.com/caworld for details regarding the event.
Laura Rochon
IUA
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: IDMS-DC calls to IDMS-DC sub programs
"I read your comments Pete. I too would be interested to hear from Ron
Gagne who had worked out the Cobol runtime environments with
development, over the years.
Lutz Petzold
-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender
by
reply e-mail and then delete this e-mail immediately. Thank you.
Aetna
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP
Normal
Normal
Re: IDMS-DC calls to IDMS-DC sub programs
"We moved to Dynamic calls years ago, for we were running into problems
with STATIC calls. 20 different programs would call a program as
static. If the STATIC program was changed, it required research to find
all programs that were using the static program and then recompiling all
20 mainline programs. It also complicated testing issues.
We also found that the static calls could also cause linkage issues and
ABENDS, between different COBOL versions (moving from COBOL I to COBOL
II ) because of differences between below and above the line storage.
I don't know how many times, I had to look at source to find that a
static call was causing unknown issues, my life simplified using dynamic
calls.
Edward A. Timm
Sallie Mae, Senior Database Analyst
ETIMM@salliemae.com
(317) 596-1182
Fax (317) 595-1494
peter.g.charles@BT.COM 09/14/2005 04:41:18 AM >>>
Lutz,
I was told many years ago buy Chuck Delouis that dynamic calls where
the
best way to call COBOL programs in IDMS DC.
I checked with CA when we switched to LE and that this was still the
case, that is use dynamic calls.
It makes sense as the run time environment is maintained by COBOL.
Look
at the work CA have done to preserve the LE enclave for COBOL programs
in the same task thread. This would be 'automatic' if dynamic calls
were
used.
You mention SVC screening. Even with DC transfers SVC screening is
still
used as it is COBOL still does issues a GETMAIN for working storage
that
has to be converted to a #GETSTG. With dynamic calls the only extra
screening, I think, will be for the LOAD of the called program.
Not sure if any one from CA is 'watching' this but if so I wonder if
they care to comment.
Pete