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
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
"My understanding of the run unit relationship between a dialog and a
cobol exit is as follows:
If my dialog updates a record, and then calls a COBOL exit without
passing subschema-control and without doing a COMMIT ALL beforehand, it
does not extend its run unit to the COBOL program; it keeps its run unit
open, and the COBOL program opens another run unit. If the COBOL
program then tries to read the record that my dialog updated, it should
deadlock. (since the update done in the dialog would have put an
exclusive lock on the record until the dialog's run unit finished or a
commit was done).
Is this correct?
If you're having to create programs to accommodate both your online and
batch applications, then COBOL is definitely the way to go. As Gary
said, it has allot of built-in functions that ADS has and it's much more
efficient. I also think you avoid the retrieval locking problems with
COBOL that exist with ADS, however, I'm not sure. Whenever you're
linking to a dialog or program that updates the database, it's best to
do 'LINK NOSAVE's and re-establish your currency in the called module.
This avoids deadlocking problems and reduced performance. Good luck.
Margaret
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
"Joan,
If you're having to create programs to accommodate both your online and batch applications, then COBOL is definitely the way to go. As Gary said, it has allot of built-in functions that ADS has and it's much more efficient. I also think you avoid the retrieval locking problems with COBOL that exist with ADS, however, I'm not sure. Whenever you're linking to a dialog or program that updates the database, it's best to do 'LINK NOSAVE's and re-establish your currency in the called module. This avoids deadlocking problems and reduced performance. Good luck.
Margaret
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 am aware it exists, but that's about it. Way back when, the decision
was made to use COBOL over ADS-BATCH for various reasons for our batch
processing, and we've pretty much stuck with it since then.
Are you aware of ADS Batch option ?
HTH
Rene.
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
-----Original Message-----"
From: Joan Hutchinson [mailTo:JHUTCHIN@IPSCO.COM]
Sent: Thursday, November 8, 2007 02:56 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: COBOL exit programs vs. ADS mapless dialogs
My understanding of the run unit relationship between a dialog and a
cobol exit is as follows:
If my dialog updates a record, and then calls a COBOL exit without
passing subschema-control and without doing a COMMIT ALL beforehand, it
does not extend its run unit to the COBOL program; it keeps its run unit
open, and the COBOL program opens another run unit. If the COBOL
program then tries to read the record that my dialog updated, it should
deadlock. (since the update done in the dialog would have put an
exclusive lock on the record until the dialog's run unit finished or a
commit was done).
Is this correct?
Joan,Margaret Sliming <marg@DIVAPROGRAMMER.COM> 11/8/2007 10:30 AM >>>
If you're having to create programs to accommodate both your online and
batch applications, then COBOL is definitely the way to go. As Gary
said, it has allot of built-in functions that ADS has and it's much more
efficient. I also think you avoid the retrieval locking problems with
COBOL that exist with ADS, however, I'm not sure. Whenever you're
linking to a dialog or program that updates the database, it's best to
do 'LINK NOSAVE's and re-establish your currency in the called module.
This avoids deadlocking problems and reduced performance. Good luck.
Margaret
-----Original Message-----decision
From: Joan Hutchinson [mailTo:JHUTCHIN@IPSCO.COM]
Sent: Thursday, November 8, 2007 10:45 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: COBOL exit programs vs. ADS mapless dialogs
I am aware it exists, but that's about it. Way back when, thewas made to use COBOL over ADS-BATCH for various reasons for ourbatchprocessing, and we've pretty much stuck with it since then.
Joan,BRANDT René <rbr@UBP.CH> 11/8/2007 12:53 AM >>>
Are you aware of ADS Batch option ?
HTH
Rene.
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]On Behalf Of Joan Hutchinsonthat
Sent: Wednesday, November 07, 2007 05:57 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: COBOL exit programs vs. ADS mapless dialogs
Can anyone offer insight as to the pros and cons of using an ADS
mapless dialog versus a COBOL exit program for commonly-used codewe want to call from several ADS dialogs?as
Historically we have typically preferred using ADS mapless dialogs,ADS has more built-in functions, etc. than does COBOL. However, oftenwe
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 suspectmay need in batch as well at some point).with
I understand that there are different run unit issues to considereach. (With a COBOL exit, the ADS calling dialog's run unit will staywe
open while the COBOL program begins and ends its own run unit, unlesseither do a commit before the call or code the dialog and COBOLprogramso as to specifically extend the run unit; whereas with a maplesscall
dialog, the ADS calling dialog's run unit either finishes when wethe mapless dialog which then starts its own run unit, or extends itschange
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 arequires regenning of all the calling dialogs, resulting in extraworkfor us and more interruption for our users.throughout
We have some processing that is commonly and frequently usedour 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
"My understanding of the run unit relationship between a dialog and a
cobol exit is as follows:
If my dialog updates a record, and then calls a COBOL exit without
passing subschema-control and without doing a COMMIT ALL beforehand, it
does not extend its run unit to the COBOL program; it keeps its run unit
open, and the COBOL program opens another run unit. If the COBOL
program then tries to read the record that my dialog updated, it should
deadlock. (since the update done in the dialog would have put an
exclusive lock on the record until the dialog's run unit finished or a
commit was done).
Is this correct?
Joan,Margaret Sliming <marg@DIVAPROGRAMMER.COM> 11/8/2007 10:30 AM >>>
If you're having to create programs to accommodate both your online and
batch applications, then COBOL is definitely the way to go. As Gary
said, it has allot of built-in functions that ADS has and it's much more
efficient. I also think you avoid the retrieval locking problems with
COBOL that exist with ADS, however, I'm not sure. Whenever you're
linking to a dialog or program that updates the database, it's best to
do 'LINK NOSAVE's and re-establish your currency in the called module.
This avoids deadlocking problems and reduced performance. Good luck.
Margaret
-----Original Message-----decision
From: Joan Hutchinson [mailTo:JHUTCHIN@IPSCO.COM]
Sent: Thursday, November 8, 2007 10:45 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: COBOL exit programs vs. ADS mapless dialogs
I am aware it exists, but that's about it. Way back when, the
was made to use COBOL over ADS-BATCH for various reasons for ourbatch
processing, and we've pretty much stuck with it since then.
Joan,BRANDT René <rbr@UBP.CH> 11/8/2007 12:53 AM >>>
Are you aware of ADS Batch option ?
HTH
Rene.
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Joan Hutchinsonthat
Sent: Wednesday, November 07, 2007 05:57 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: COBOL exit programs vs. ADS mapless dialogs
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
we want to call from several ADS dialogs?as
Historically we have typically preferred using ADS mapless dialogs,
ADS has more built-in functions, etc. than does COBOL. However, oftenwe
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
may need in batch as well at some point).with
I understand that there are different run unit issues to consider
each. (With a COBOL exit, the ADS calling dialog's run unit will staywe
open while the COBOL program begins and ends its own run unit, unless
either do a commit before the call or code the dialog and COBOLprogram
so as to specifically extend the run unit; whereas with a maplesscall
dialog, the ADS calling dialog's run unit either finishes when we
the mapless dialog which then starts its own run unit, or extends itschange
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
requires regenning of all the calling dialogs, resulting in extrawork
for us and more interruption for our users.throughout
We have some processing that is commonly and frequently used
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
"Joan,
If you're having to create programs to accommodate both your online and batch applications, then COBOL is definitely the way to go. As Gary said, it has allot of built-in functions that ADS has and it's much more efficient. I also think you avoid the retrieval locking problems with COBOL that exist with ADS, however, I'm not sure. Whenever you're linking to a dialog or program that updates the database, it's best to do 'LINK NOSAVE's and re-establish your currency in the called module. This avoids deadlocking problems and reduced performance. Good luck.
Margaret
-----Original Message-----"
From: Joan Hutchinson [mailTo:JHUTCHIN@IPSCO.COM]
Sent: Thursday, November 8, 2007 10:45 AM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: Re: COBOL exit programs vs. ADS mapless dialogs
I am aware it exists, but that's about it. Way back when, the decision
was made to use COBOL over ADS-BATCH for various reasons for our batch
processing, and we've pretty much stuck with it since then.
Joan,BRANDT René <rbr@UBP.CH> 11/8/2007 12:53 AM >>>
Are you aware of ADS Batch option ?
HTH
Rene.
-----Original Message-----
From: IDMS Public Discussion Forum [mailTo:IDMS-L@LISTSERV.IUASSN.COM]
On Behalf Of Joan Hutchinson
Sent: Wednesday, November 07, 2007 05:57 PM
To: IDMS-L@LISTSERV.IUASSN.COM
Subject: COBOL exit programs vs. ADS mapless dialogs
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 am aware it exists, but that's about it. Way back when, the decision
was made to use COBOL over ADS-BATCH for various reasons for our batch
processing, and we've pretty much stuck with it since then.
Joan,BRANDT René <rbr@UBP.CH> 11/8/2007 12:53 AM >>>
Are you aware of ADS Batch option ?
HTH
Rene.
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:
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?