ca.portal.admin

Why did I go SOS?

Discussion created by ca.portal.admin on Nov 23, 2005
I have a strange situation from my Production R15.0 SP5 system.

This morning it went SOS.

07.33.05 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1
07.34.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.35.15 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1

I didn't get any Abends and as far as I can see there was nothing unusual
going on.

These are the stats for the Pools from PMRM..



02 Storage Pool Detail
Pool Total Storage High SOS SOS Cushn
ID Storage In_Use Water Count Now Size
0 2048kB 492kB 1612kB 256kB
1 1024kB 8192 900kB 49 256kB
128 2048kB 69632 660kB 256kB
129 16mB 1316kB 8720kB 256kB
255 6144kB 1544kB 1828kB


and from DCMT D ALL STO POOL

D ALL STO POOL
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX CONTAINS
SOS TYPES
0 0012C000 2048K 256K 492K 1612K 0 NO SY,TR,DB
1 0032C000 1024K 256K 8K 900K 49 NO ALL
128 1D5A4000 2048K 256K 20K 660K 0 NO US,UK
129 1D7A4000 16384K 256K 852K 8720K 0 NO SH,SK,TR,DB
255 1E7A4000 6144K 0K 1524K 1828K 0 NO SY

1 ENTER NEXT TASK CODE:


What I want to know is why Pool 129 which has a cushion of 256K went SOS
at a HWM of 8 Meg when the full size is 16 Meg. It Implies that the
requested storage was over 8 Meg. But then it started to use Pool 1 which
can't possibly provide 8 meg but did max out after giving around 800K and
hitting the cushion. And why does the display not register a SOS in 129?

What is going to ask for 8 Meg of storage, be refused and then settle for
800K and still work? It isn't locks because they come out of Pool 255 and
there is no overflow. We have no DC Programs or ADS it is all CICS and
Batch. Normally the only thing coming out of 129 is VB50 storage for
Subschemas. Our biggest subschema only takes 800K out of the pool.

I can only think that it must be a user submitting an SQL query but I
can't find anyone who has done so at 7:35AM. SQL generally uses lumps of
Pool128 to Parse the statement and very little else.

Has anyone a suggestion as to what this might be?

Mit freundlichen Grüssen
--------------------------------------------------------------------------------------
Chris Trayler, IXD
Bank Julius Bär & Co. AG
Hohlstrasse 602, CH-8010 Zurich, Switzerland
Telephone +41 (0) 58 887 43 32
Christopher.Trayler@juliusbaer.com, www.juliusbaer.com
--------------------------------------------------------------------------------------


*****Disclaimer*****
This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer

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








Normal

Normal
Re: Why did I go SOS?
"I think I had this problem a few times in the past. The last time just a month or so ago.
My problem was due to a batch job without commits.
In order to accommodate the batch job I upped the syslocks parm in the sysgen from 25,000
to 50,000. Then the job ran. CA says they recommend 100,000 but I did not go that high.
If your problem is the same as mine, check your syslocks parm in the system statement of the sysgen.


J. Wayne Doneker
BAE Systems
York Pa.
717 225 8109
Email: john.doneker@baesystems.com

christopher.trayler@JULIUSBAER.COM 11/23/2005 11:37:21 AM >>>
I have a strange situation from my Production R15.0 SP5 system.

This morning it went SOS.

07.33.05 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1
07.34.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.35.15 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1

I didn't get any Abends and as far as I can see there was nothing unusual
going on.

These are the stats for the Pools from PMRM..



02 Storage Pool Detail
Pool Total Storage High SOS SOS Cushn
ID Storage In_Use Water Count Now Size
0 2048kB 492kB 1612kB 256kB
1 1024kB 8192 900kB 49 256kB
128 2048kB 69632 660kB 256kB
129 16mB 1316kB 8720kB 256kB
255 6144kB 1544kB 1828kB


and from DCMT D ALL STO POOL

D ALL STO POOL
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX CONTAINS
SOS TYPES
0 0012C000 2048K 256K 492K 1612K 0 NO SY,TR,DB
1 0032C000 1024K 256K 8K 900K 49 NO ALL
128 1D5A4000 2048K 256K 20K 660K 0 NO US,UK
129 1D7A4000 16384K 256K 852K 8720K 0 NO SH,SK,TR,DB
255 1E7A4000 6144K 0K 1524K 1828K 0 NO SY

1 ENTER NEXT TASK CODE:


What I want to know is why Pool 129 which has a cushion of 256K went SOS
at a HWM of 8 Meg when the full size is 16 Meg. It Implies that the
requested storage was over 8 Meg. But then it started to use Pool 1 which
can't possibly provide 8 meg but did max out after giving around 800K and
hitting the cushion. And why does the display not register a SOS in 129?

What is going to ask for 8 Meg of storage, be refused and then settle for
800K and still work? It isn't locks because they come out of Pool 255 and
there is no overflow. We have no DC Programs or ADS it is all CICS and
Batch. Normally the only thing coming out of 129 is VB50 storage for
Subschemas. Our biggest subschema only takes 800K out of the pool.

I can only think that it must be a user submitting an SQL query but I
can't find anyone who has done so at 7:35AM. SQL generally uses lumps of
Pool128 to Parse the statement and very little else.

Has anyone a suggestion as to what this might be?

Mit freundlichen Grüssen
--------------------------------------------------------------------------------------
Chris Trayler, IXD
Bank Julius Bär & Co. AG
Hohlstrasse 602, CH-8010 Zurich, Switzerland
Telephone +41 (0) 58 887 43 32
Christopher.Trayler@juliusbaer.com, www.juliusbaer.com
--------------------------------------------------------------------------------------


*****Disclaimer*****
This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer

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








Normal

Normal
Why did I go SOS?
"I have a strange situation from my Production R15.0 SP5 system.

This morning it went SOS.

07.33.05 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.34.02 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1
07.34.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 129: SOS CONDITION 1
07.35.07 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 0
07.35.15 JOB05017 +IDMS DC015007 V1 POOL 001: SOS CONDITION 1

I didn't get any Abends and as far as I can see there was nothing unusual
going on.

These are the stats for the Pools from PMRM..



02 Storage Pool Detail
Pool Total Storage High SOS SOS Cushn
ID Storage In_Use Water Count Now Size
0 2048kB 492kB 1612kB 256kB
1 1024kB 8192 900kB 49 256kB
128 2048kB 69632 660kB 256kB
129 16mB 1316kB 8720kB 256kB
255 6144kB 1544kB 1828kB


and from DCMT D ALL STO POOL

D ALL STO POOL
POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX CONTAINS
SOS TYPES
0 0012C000 2048K 256K 492K 1612K 0 NO SY,TR,DB
1 0032C000 1024K 256K 8K 900K 49 NO ALL
128 1D5A4000 2048K 256K 20K 660K 0 NO US,UK
129 1D7A4000 16384K 256K 852K 8720K 0 NO SH,SK,TR,DB
255 1E7A4000 6144K 0K 1524K 1828K 0 NO SY

1 ENTER NEXT TASK CODE:


What I want to know is why Pool 129 which has a cushion of 256K went SOS
at a HWM of 8 Meg when the full size is 16 Meg. It Implies that the
requested storage was over 8 Meg. But then it started to use Pool 1 which
can't possibly provide 8 meg but did max out after giving around 800K and
hitting the cushion. And why does the display not register a SOS in 129?

What is going to ask for 8 Meg of storage, be refused and then settle for
800K and still work? It isn't locks because they come out of Pool 255 and
there is no overflow. We have no DC Programs or ADS it is all CICS and
Batch. Normally the only thing coming out of 129 is VB50 storage for
Subschemas. Our biggest subschema only takes 800K out of the pool.

I can only think that it must be a user submitting an SQL query but I
can't find anyone who has done so at 7:35AM. SQL generally uses lumps of
Pool128 to Parse the statement and very little else.

Has anyone a suggestion as to what this might be?

Mit freundlichen Grüssen
--------------------------------------------------------------------------------------
Chris Trayler, IXD
Bank Julius Bär & Co. AG
Hohlstrasse 602, CH-8010 Zurich, Switzerland
Telephone +41 (0) 58 887 43 32
Christopher.Trayler@juliusbaer.com, www.juliusbaer.com
--------------------------------------------------------------------------------------


*****Disclaimer*****
This message is for the addressee only and may contain confidential or privileged information. You must delete and not use it if you are not the intended recipient. It may not be secure or error-free. All e-mail communications to and from the Julius Baer Group may be monitored. Processing of incoming e-mails cannot be guaranteed. Any views expressed in this message are those of the individual sender. This message is for information purposes only. All liability of the Julius Baer Group and its entities for any damages resulting from e-mail use is excluded. US persons are kindly requested to read the important legal information presented at following URL: http://www.juliusbaer.com/maildisclaimer

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








Normal

Normal
An Interesting Article
"From COMPUTERWORLD this morning.

http://cwflyris.computerworld.com/t/152587/428241/2873/0/

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








Normal

Normal
Re: High Performance Storage Protection Option in 16.0 SP2
"Paul, I don't understand how HPSPO would engage when your application
programs are running NOPROTECT. The IDMS Performance group folks used
to promote the use of storage protect at the system level and off at the
program level because storage resource chains were anchored off the TCE,
task level, and not the CSA when running with storage protect on the
system level. This made the searches for resources shorter. Having the
application set to NOPROTECT prevented the high price of storage
protection by calling the svc for key switches at every
application/system threshhold change. However, if you're going to be
using HPSPO, real storage protection with less overhead, then I would
imagine your applications run PROTECT. Otherwise, why bother with HPSPO
since IDMS wont be calling the SVC to change keys anyway.

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
High Performance Storage Protection Option in 16.0 SP2
"We are currently running 16.0 SP1 and are preparing the IDMS environment to utilize HPSPO (High Performance Storage Protection Option) in 16.0 SP2 and above by separating the user storage pools as follows:

POOL ADDRESS SIZE CUSHION INUSE HWM TIMES PFIX CONTAINS
SOS TYPES
0 00173000 4000K 1200K 336K 344K 0 NO SY
1 0055B000 1000K 100K 96K 192K 0 NO US,UK
2 00655000 1000K 100K 36K 36K 0 NO SH,SK
3 0074F000 3000K 300K 0K 28K 0 NO TR,DB
128 18D34000 10000K 0K 640K 1452K 0 NO US,UK
129 196F8000 2000K 0K 568K 572K 0 NO SH,SK
130 198EC000 7000K 0K 456K 832K 0 NO TR,DB
255 19FC2000 5000K 0K 2352K 3264K 0 NO SY
V1 Release 16.0 >>> JIS Development CV <<< Enter next task:

We use Storage Key 9, another pre-requisite of HPSPO. We have applied QO71083 to stop TR and DB storage types from being acquired in pool 0.

Has anyone utilize HPSPO in 16.0 SP2 and has observed savings or otherwise in the CPU usage. We are interested in the potential CPU impact on the following three environments.

1) System level PROTECT, program level PROTECT, with user-storage pool separation as shown above and Storage Key 9 and making use of HPSPO

2) System level PROTECT, program level NOPROTECT, with user-storage pool separation as shown above and Storage Key 9 but not making use of HPSPO (according to CA, the user programs, e.g. Cobol, ADS and Assembler must be sysgened as PROTECT at the program level to use HPSPO). If we are not using HPSPO, is there any CPU penalty on programs running NOPROTECT. CA indicated that HPSPO provides significant savings for programs running PROTECT.

3) System Level PROTECT, program level NOPROTECT, with Storage Key 9 and no user storage pool separation (i.e. mixing of User storage US, UK, SH, SK with TR, DB) and hence not using HPSPO

Regards,
Paul Mak
Email : mailTo:paul.mak@eds.com
Phone : +61 2 9378 0503
Mobile : +61 419 398 116
Fax : +61 2 9312 6380
Mail : EDS Australia South Applications Delivery Unit
Level 3, 36-46, George Street, Burwood, NSW 2134, Australia

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








Normal

Normal
Re: Release 16 program loads
"Alan,
I don't think you can. I'm about to get out of my league here, so take
this with a grain of salt.
The IDMS run time system wants to load it's programs out of CDMSLIB (or
CDMSLIBx) using it's own load routines. The normal operating system LOAD
instructions want to load from STEPLIB/JOBLIB, or the LINKLIST. Two
different animals.
Simply, I don't believe the IDMS load operation(s) are designed to look at
LINKLIST. Personally, I think that's good as it gives you a lot of control
as to where you're going to search.

Joe Lupico
IDMS System Support
""Our World is a Happy World""

Outcomes