Is there a TSO command written in REXX or CLIST that can determine WHO has enqueued a dataset?

Question

I need to write a REXX Exec or Clist to identify WHO has enqueued a Dataset and display a user friendly message on an ISPF dialog application. Due to system configuration issues, the %WHOHAS command is not available. However I also know that ISPF itself (Option 3.4) has proprietary hooks into the zos mainframe to display the enqueued resource information I need - so the infomation can be obtained. Unfortunately I don't know how to access this data from outside ISPF 3.4 using a REXX Exec or CLIST. Any suggestions?

Answer 1

On first reading I thought this would be a pretty simple thing to dig up. Not quite!

Under ISPF you can get a panel to display who is holding a dataset by typing the following on the command line:

TSO ISRDDN ENQ 'Dataset-name'

The ISRDDN command is documented at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr/FRAMESET/ispzug50/G.0?ACTION=MATCHES&REQUEST=isrddn&TYPE=FUZZY&SHELF=ispzpm50&DT=20060621022939

Invoking ISRDDN is possible from within a REXX program but I don't know how to capture the output into a stem variable where you could parse it out and issue a message. I could not find a command line interface to ISRDDN that allows capture of the output.

There is another utiltiy at: http://www.sillysot.com/mvs/index.htm?queryenq.htm that claims to do this as well, I have never tried it so cannot comment any further on it.

I Googled your question and it looks like several people have used the MVS command

D GRS,RES=(*,dsname)

to determine who is holding a dataset. However, this requires console access so would not be appropriate for most users. If console access is allowed, then you could start a console session under REXX and capture the output fairly easily, see: http://www.redbooks.ibm.com/redbooks/pdfs/sg244626.pdf.

One final place to search would be the CBT tapes (freeware for IBM mainframes). Here you can find several implementations of the WHOHAS ISPF command.

Sorry, but this is the best I can do.

Answer 2

This turned out to be a very simple fix. Nothing fancy. If the clist uses CONTROL NOFLUSH it will not abort when the ALLOCation of a dataset fails. We also have a installed product called TSOPLUS that will format a message to the terminal identifying who has allocated a dataset when the allocation fails. By turning off FLUSH and then systrapping the TSOPLUS message, I was able to extract the information I needed.