IDMS

Can anyone offer insight as to the pros and cons of using an ADS mapless dialog versus a COBOL exit program for commonly-used code that we want to call from several ADS dialogs?

Historically we have typically preferred using ADS mapless dialogs, as ADS has more built-in functions, etc. than does COBOL. However, often we find that later on we need the same processing done in batch, and often end up writing a COBOL batch version anyway. Are we better off just writing a COBOL exit program that we can call from ADS? Then we can easily clone and modify when we need a batch version. (We have started to do this more and more for any processing that we suspect we may need in batch as well at some point).

I understand that there are different run unit issues to consider with each. (With a COBOL exit, the ADS calling dialog's run unit will stay open while the COBOL program begins and ends its own run unit, unless we either do a commit before the call or code the dialog and COBOL program so as to specifically extend the run unit; whereas with a mapless dialog, the ADS calling dialog's run unit either finishes when we call the mapless dialog which then starts its own run unit, or extends its run unit to the mapless dialog depending on the subschemas and ready usage modes, whether we specifically extend it, etc.)

We also have some ""include modules"" that we sometimes use for commonly-used code, but we find the downside to those are that a change requires regenning of all the calling dialogs, resulting in extra work for us and more interruption for our users.

We have some processing that is commonly and frequently used throughout our application. Are there performance considerations to doing it in one way vs. the other?

Any feedback would be most appreciated.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: COBOL exit programs vs. ADS mapless dialogs
"I'm really not sure how retrieval locking works with COBOL since the indicator is set in the ADS generation process. To turn retrieval locking off, calling dialogs must perform no updates and perform a LINK NOSAVE to an update dialog which has to re-establish currency before performing any updates. ADS would abend with an application thread error if a calling dialog had it's retrieval lock indicator turned off and then Linked to a dialog which performed an update on a record retrieved in the calling dialog. I'd like to know what would happen with COBOL. If you have an example of a dialog that performs retrieval only and then links to a COBOL program to perform updates, re-gen the calling dialog with the retrieval lock indicator turned off and see if the COBOL program aborts on an application thread error. I'm not in an IDMS shop right now so I can't try it. I would love to know so if you find out please keep me posted. I've been battling retreival locking problems since release 12.0 came out in 1993. Good Luck.
Margaret

Can anyone offer insight as to the pros and cons of using an ADS
mapless dialog versus a COBOL exit program for commonly-used code that
we want to call from several ADS dialogs?

Historically we have typically preferred using ADS mapless dialogs, as
ADS has more built-in functions, etc. than does COBOL. However, often
we find that later on we need the same processing done in batch, and
often end up writing a COBOL batch version anyway. Are we better off
just writing a COBOL exit program that we can call from ADS? Then we
can easily clone and modify when we need a batch version. (We have
started to do this more and more for any processing that we suspect we
may need in batch as well at some point).

I understand that there are different run unit issues to consider with
each. (With a COBOL exit, the ADS calling dialog's run unit will stay
open while the COBOL program begins and ends its own run unit, unless we
either do a commit before the call or code the dialog and COBOL program
so as to specifically extend the run unit; whereas with a mapless
dialog, the ADS calling dialog's run unit either finishes when we call
the mapless dialog which then starts its own run unit, or extends its
run unit to the mapless dialog depending on the subschemas and ready
usage modes, whether we specifically extend it, etc.)

We also have some ""include modules"" that we sometimes use for
commonly-used code, but we find the downside to those are that a change
requires regenning of all the calling dialogs, resulting in extra work
for us and more interruption for our users.

We have some processing that is commonly and frequently used throughout
our application. Are there performance considerations to doing it in
one way vs. the other?

Any feedback would be most appreciated.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: unsubscribe
"Please remove my name from this list.

Thanks,

Walid.sayed@cdn.fr

Walid
Ce message et toutes les pieces jointes (ci-apres le ""message"") sont confidentiels et etablis a l'attention exclusive des destinataires.
Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est suceptible d'alteration.
Le CREDIT DU NORD et ses filiales declinent toute responsabilite au titre de ce message s'il est altere, deforme ou falsifie.

This message and any attachments (the ""message"") are confidential and intended solely for the addressees.
Any unauthorized use or dissemination is prohibited. E-mails are susceptible to alteration.
Neither CREDIT DU NORD nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
unsubscribe
"Please remove my name from this list.

Thanks,

Nahid


---------------------------------
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how.
"
IDMS Public Discussion Forum
IDMS-L@LISTSERV.IUASSN.COM
SMTP
IDMS-L@LISTSERV.IUASSN.COM
IDMS-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal

"

Please remove my name from the list server>

Thanks!

darlene.alston@ssa.gov

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








Normal

Normal
Re: Fw:unsubscribe
"On Wed, 14 Nov 2007 12:55:36 -0500, Petzold, Lutz <PetzoldL@AETNA.COM>
wrote:

I know of some of the names, and it's more like IDMS'ers who have long

ago crossed the river to the other side.


What? Do you mean that these guys are unsubscribing from the astral
plane?? I've heard of poltergeists', but this is starting to get scary.
"
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] Fw: unsubscribe
"Nope - couldn't be what you said. Mouthwash maybe? Deodorant failure?