ca.portal.admin

ADSC DIALOG option

Discussion created by ca.portal.admin on May 31, 2006
Currently we run all of our dialogs with the DIAGNOSTIC TABLE IS ENABLED
set to ON. The obvious upside to this is that when we have a production
abend, we can instantly see the line on which the abend occurred. The
documentation recommends turning this option off when a dialog is put
into production, in order to reduce load module size (and therefore
system resource usage). I see by regenning a dialog with and without
the option that the load module size change can be significant. Does
anyone have any wisdom or experiences to share regarding this? (i.e.
are there any other upsides/downsides to setting this to OFF)?

Thanks.

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








Normal

Normal
And another one bites the dust................
"At 14:05 this afternoon (Pacific time) on May 31st, 2006, Holland
America Line shutdown it's mainframe.

I hear a voice from the computer room saying ""Ah'll be back!""..........

Scott J. Brady
Former IDMS DBA
Holland America Line
Seattle, WA

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








Normal

Normal
Re: ADSC DIALOG option
"There are two compile options in ADSC that affect dialog size:

1) SYMBOL table - this will really increase the average size of a dialog - it will also run slower - it will force the 2nd option on since it will also generate a ""diagnostic Table"" - you get a warning about this when using ADSC. This is the option you don't want in production - it makes the ADS run-time system work harder - there is no ""executable code"" with this option - while not ""interpretive"" like TSO clists for example it does not generate executable code for simple ""moves"" for example

2)Diagnostic Table - by itself all it adds to the end of your dialog is a list of ""offsets"" of each verb in the dialog - this contains the ICMD and process code line number so that if an ABEND occurs it can look up the line number(s) in the process code for display purposes - it does not add to execution time - it will still generate ""executable"" code - and the size overhead is much smaller.

Even with all of this wisdom our site still runs with both options OFF in production - when we are required to determine where required to get problem determination information for developers we run ADSORPTS against the production dialog to get the ICMD number at the offset in the dialog ABEND message (because that's about all you get with diagnostics and symbol tables off) - then we regenerate the dialog with at least one of the options on and rerun ADSORPTS - look up the ICMD number (the offset will most likely be different - especially with symbol tables on) - and you will find the IDD line number.

Personally - I think we would be fine to run our production system with Diagnostic Tables because it makes problem solving so much easier - but this is a long established policy which I would have trouble changing - so there's a couple of us who have a documented procedure as to how to locate the problem code when there are production abends that need to be followed up by developers.

If you are short on ""real"" memory and run with a small XA REENT program pool - and you do what is in effect a lot of ""paging"" in this pool - then everything you can do to make a dialog smaller is important. Otherwise just make your pool large enough so that everything just loads once in the day - without causing actual operating system paging because of the size of your IDMS program pool.

You can tell if you are ""paging"" in the program pool by looking at total size of all program loads compared to total size of the pool - if you have loaded more bytes of programs than bytes of program pool you are ""overlaying"" already loaded programs - that what I mean by ""paging"". I have seen sites reload the program pool dozens of times over - when we increased the size of the program pool the amount of loading dropped off - with an appropriate amount of IO being dropped off from the dictionary load area. In fact - I had one site that had more IO against the load area than the amount of IO against the most frequently accessed application database area. PMIM I think will show you IO per area within each interval to see just how hard hit the load, and other areas are.

HTH - cheers - Gary


Gary Cherlet
Justice Technology Services
Telephone +61 (0)8 8226 5199
Facsimile +61 (0)8 8226 5311
Mobile +61 (0)41 333 1613
MailTo:cherlet.gary@saugov.sa.gov.au

This e-mail message and any attachments are qualified as follows:
Addressing: If you have received this e-mail in error, please advise by reply e-mail to the sender. Please also destroy the original transmission and its contents.
Confidentiality: This e-mail may contain confidential information which also may be legally privileged. Only the intended recipient(s) may access, use, distribute or copy this e-mail.
Individual Views: Unless otherwise indicated, the views expressed are those of the sender, not Justice Technology Services.
Computer Viruses: It is the recipient's responsibility to check the e-mail and any attached files for viruses.

Outcomes