IBM Mainframe Forum

Dear all,

Greetings for the day!

Here in our shop the system often gets into 'x' clock mode(hangs). when i tried to find the resource usage through RMF III i found some work flow exceptions which states like this. Which is basically a SYSRES volume. Can't find any clue and this is just for the TSO session. Can any one guide me on this. Please let me know whether i have to provide more information. Not sure whether this is the correct place to shoot this question. If not my apologize and please transfer this to the concerned topic. Apologize a ton if i'm wrong!

TIA
Viswa

Linklist and LLA both may be using data sets on that volume -- even from other LPARs. How many LPARs are defined and active?

I presume the S-BSY is from the DISPLAY U operator command. If that is the case, there is a good chance some other system is

• Actively using the volume.
• Has a "reserve" on the volume. This means your system cannot access any data on the volume while the other system has the "reserve."
• It is possible your system is very actively using the volume.

I suspect one or both of my first two bullets, not the third bullet. If this is the case, the volume is being used inappropriately; this is a matter your storage management people and the systems programmers should be investigating.

If you are getting real "reserves" you should be looking at using the GRS function that is a standard feature of z/OS or a competing product such as CA-MIM to avoid these "reserves." The hardware "reserve" feature is very bad news for a number of reasons, but this is not an appropriate place to discuss the performance issues caused by the hardware "reserve" feature..

@Robert: thanks for the time and reply. The storage is being used by two LPAR's defined out of which this DASD unit is dedicated to the single System which is basically a Monoplex system. And i have even checked the status of the device with the another LPAR which is sharing the storage and this particular Unit is offline there. Any suggestions would be helpful.

@Steve: thanks for time and reply!
Yes agreed!

For option 1: it may be actively used taking into account that this is basically a SYSRES volume. But even taking this into account i have not seen this happening before in the same environment. Any guidance would be helpful.

Please let me know if in case i need to give more information. Apologize a ton if i'm wrong!

TIA
Viswa

usually the sysres packs are read only, so the chances of getting reserves should be non existant
but having a reserve on that pack means that somebody is writing to it,

ZEAL804 DEV -SYSRS1 67.0 % delay May be reserved by another system.

since RMF does not lie, i tend to trust more it' s judgement than Yours
so better check Your configuration and setup

enrico-sorichetti wrote:... but having a reserve on that pack means that somebody is writing to it

Not necessarily. As an example, if a system is just opening a dataset, while the system is locating the dataset entry in the VTOC it holds a "reserve" on the VTOC. Still, whatever the reason, there is no way a SYSRES volume should be blocked by a long term reserve.

A possible culprit could be a systems programmer doing maintenance, but this shouldn't be done on an active SYSRES.

when I said writing I was implying <significant> update activity...
I guess that the number of opens needed to hog a shared volume would be quite high !
I doubt that such a big delay would be due just to some open and close

but until the TS finds out the content of the pack in question we' ll keep wandering in the dark

Hi,

Apologize for the delay in response.
yeah this was my thought too. Unfortunately i cant find any misplaced datasets breaching the ACS routines in the mentioned volumes. Is there any other way to find a solution for this. Please let me know in case if need to give more details on this. Apologize if i and my thoughts are wrong!

Regards,
Viswa

what about gettting a snapshot of the overall enq status at the time ?

Viswanathchandru wrote:... And i have even checked the status of the device with the another LPAR which is sharing the storage and this particular Unit is offline there. ...
Viswa

It does not seem likely it was offline to the other LPAR at the time of the incident.