Auxillary/Work Space used by an executing job



Ask about System customization & performance, Workload management, I/O device configuration etc.

Auxillary/Work Space used by an executing job

Postby Aki88 » Thu Aug 14, 2014 7:10 pm

Hello,

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

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Auxillary/Work Space used by an executing job

Postby BillyBoyo » Thu Aug 14, 2014 7:29 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Auxillary/Work Space used by an executing job

Postby Robert Sample » Thu Aug 14, 2014 8:05 pm

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).
Robert Sample
Global moderator
 
Posts: 3720
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 279 times

Re: Auxillary/Work Space used by an executing job

Postby Aki88 » Thu Aug 14, 2014 9:22 pm

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Auxillary/Work Space used by an executing job

Postby BillyBoyo » Thu Aug 14, 2014 10:17 pm

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.
BillyBoyo
Global moderator
 
Posts: 3804
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 265 times

Re: Auxillary/Work Space used by an executing job

Postby Terry Heinze » Thu Aug 14, 2014 11:28 pm

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.
.... Terry
Terry Heinze
 
Posts: 239
Joined: Wed Dec 04, 2013 11:08 pm
Location: Richfield, MN, USA
Has thanked: 12 times
Been thanked: 11 times

Re: Auxillary/Work Space used by an executing job

Postby Aki88 » Fri Aug 15, 2014 11:34 am

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.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Auxillary/Work Space used by an executing job

Postby Aki88 » Thu Aug 21, 2014 12:28 pm

Hello,

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

Thanks for the help.

Cheers.
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times

Re: Auxillary/Work Space used by an executing job

Postby Aki88 » Fri Dec 16, 2016 10:53 pm

<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:
q      Output descriptors      
jy     Job Delay              
jd     Job Devices            
jm     Job Memory              
js     Job Step                
jp     Job Dependency          


SDSF reference manual: SA23-2274-07
Aki88
 
Posts: 381
Joined: Tue Jan 28, 2014 1:52 pm
Has thanked: 33 times
Been thanked: 36 times


Return to System programming

 


  • Related topics
    Replies
    Views
    Last post