IBM Mainframe Forum

Hello,

Please excuse me for errors in terminology, as this query is a little outside my expertise.

I need to get the auxillary storage/work space/virtual storage being picked by an executing job; this job has multiple programs executing in it inclusive of a few DFSORT steps.
I can get the info for DFSORT steps from the ICE messages post completion of the steps; but unsure how to get the info for the remaining programs, also, I am not sure how I can get this info during the jobs execution.

The in-execution requirement has come up following a recent system crash when one of the jobs on the test environment *took more than allowed storage causing the crash* (as the sysprogs put it for us).

Really thankful for any pointers to get this information.

Thanks.

This sounds like bunkum and balderdash.

If a test job, and I really mean if, in the strongest sense of the word (as in it is extremely unlikely) has caused the entire system to crash (brought the machine down) then it is not your problem and you need do nothing about it. It is the Sysprogs' problem. There should be no loophole by which you can bring a system down. If one has been revealed, then they, not you, have to plug it.

If they insist on you doing it then insist that they tell you how.

We have no clue what software tools they have, nor standards for implementation at your site. Guess who does know these things.

There are monitoring tools available for z/OS; if your site has one of these tools installed then you can use it MANUALLY to watch a batch job. If your site does not have one installed, then you are pretty much not going to be able to watch the memory usage of the batch job since these tools are expensive (hundreds of thousands of US dollars at a minimum).

The way to resolve your issue is to go back to your site support group and find out from them why they believe the batch job is causing memory problems. And you can find out at the same time what monitoring tool(s) they have available at your site. They should also be able to better isolate the problem (i.e., is the problem with main memory, or auxiliary storage, or paging).

Hello Billy/Robert,

The final diagnostic shared by the sysprog said:
*System ran into some AUX storage shortage because the DFSORT step used up all physical memory that is available on the system.*

Post the crash, there have been changes made to the system parameters, I am not aware of all the changes in my current capacity.

We do have Omegamon, but it is not available on UAT LPAR; I can try getting the SMF type 30 info, but I am not sure how to check the same at run-time of a job.
I'd come across this link:http://ibmmainframes.com/about42619.html where Robert has stated that there might be a possible way to check the info if SDSF is available; can you kindly guide me to this method or a manual that I can refer for the same.

Reason for us trying to get this info is to simply avoid any unforseen situation due to our jobs; business is hot on our heels and the sysprogs are not willing to accept that it was their fault in not having a roust system config around (this is the first time that I've seen a z-system crash due to THIS reason); because of which business has asked us to monitor our jobs- at least for the coming few days.

Thanks.

I'd suggest contacting DFSORT support, dfsort@us.ibm.com. It would seem that the installation options chosen have allowed more "memory" usage than is desirable. DFSORT support will understand the interactions of different installation parameters and should be able to tell you (your site) the implications of what you have and suggest any remedial changes. The installation can be different across your different systems, but once one is reviewed, if there are problems found all should be reviewed.

You might want to start by including the output from ICETOOLS's DEFAULTS operator run on the system which allegedly caused the problem. I'm sure DFSORT Support will tell you what other information you need to provide.

Don't just e-mail them on your own, in case you step on toes locally, but find who in your Technical Support has responsibility for this. They may be happy for you to do it, or they may prefer to do it themselves, but I think it needs to be done.

Don't know if this will help, but in SDSF (if you have it), set your SYSNAME to the 4-char LPAR name your job is running in, key DA OJOB and look at the REAL column. Hit F1 to see what REAL means.

Hello Billy/Terry,

Billy: Sure, will do that; though to be on a safe side, I've capped all my DFSORTs with a 10% limitation on MOSIZE/EXP* params/HIPRMAX.

Terry: Yup, we have SDSF; thanks that was helpful.

Thanks.

Hello,

I was able to get what I was looking for from RMF/Monitor3/Resources/STORM panel.

Thanks for the help.

Cheers.

<Returning to an old post to add a few pointers for future reference>

With z/OS 2.2 SDSF now allows a user to monitor the memory (and more) allocated to a job directly from the SDSF panels; primary commands can be entered in front of the executing/completed job from the DA (Display Active Users)/ST (Status) and few other panels. The enhancements offer quick info for executing steps at run-time as well as a summary once the job is completed - this information had to be earlier pulled out from the RMF panels; same are now translated in spool directly.

Tested on a z/OS 2.2 rig, quick reference for few commands:


SDSF reference manual: SA23-2274-07