ca.portal.admin

ABEND 1473 AND SYSGEN PARMS

Discussion created by ca.portal.admin on Feb 24, 2005
i had this abend(max eru's).
has anyone a method to evaluate the correct value(that was not a rule of
thumb) of this parms in sysgen ?

i modify my sysgen by
add number of external adress space accessing this central version(TP
monitor(cics) + TSO).

it seems to me that i had, also, to review parm=max task = max erus +3 +
driver. is it so ?

Finally : is this rule correct :
if max erus + max tasks + system task + master + dbrc + driver > 50
i had to reduce the total number by 50%

thanks.
----------------------------------------------------------------------------
---------------
Cordialement,
Jean-Luc DUPREZ , Département Informatique Bordeaux - PSE
Tél. : 05.56.90.78.25
----------------------------------------------------------------------------
---------------

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








Normal

Normal
Re: ADSO-APPLICATION-GLOBAL-RECORD
"I can't recall seeing many responses to this post - so I'll wade in at the
risk of being totally wrong.

You get the ""invalid response"" from ADS at run-time when the dialog says
EXECUTE NEXT FUNCTION and AGR-CURRENT-RESPONSE still has ""spaces"" in it.
There's a flowchart in the ADS manual that shows the evaluation of what ends
up in AGR-CURRENT-RESPONSE. Basically ADS run-time looks at whether the
operator entered a response, PF keys, whether or not there is a ""default""
response at the ADSA or dialog level and so forth. Of course the results of
all of tis may have been taken over by the dialog moving a value to
AGR-CURRENT-RESPONSE. If after all of that you still have SPACES when you do
EXEC NEXT - then you get ""invalid response""

I have never seen a problem with ADS mixing up sessions because ""multiple
signon"" is enabled. In a green screen application an ADS session is anchored
to the LTE through the RCE and RLE control blocks that keep the ADS context
control blocks tied to that terminal across the pseudo converse. The only
time I could see having a problem is in a cliSent:server scenario using, for
example, APPC. If your voice response application runs across APPC there is
no guarantee which APPC logical terminal each part of the conversation comes
across.

For my money I'd look at the way the connection between the screen scraper
connects to IDMS - whether there's a concept of a pool of signed on
terminals or whatever - and if so how it decides which terminal to use for
each part of the conversation.

I doubt if this will help much - but maybe it will provide some food for
thought.

Cheers - Gary

Gary Cherlet
Justice Technology Services
Telephone (+61-8) 8226 5199
Facsimile (+61-8) 8226 5311
Mobile 041 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