On 17 September 2014 11:24, Paul Gilmartin <[email protected]> wrote:
> address MVS 'EXECIO 0 DISKR SYSUT1 (open' > > Somewhere in the world this should leave a DCB. Can I find it > (chasing pointers or otherwise) so I can inspect it with STORAGE()? > (This might be thwarted because an opened DCB does not contain > the DDNAME which could be used as an eyecatcher.) Timing is everything. I posted something about a problem doing just that a week or two ago (and I have an update when I get around to it). The easy (and PI, if you care) way is to follow the DEB chain from your TCB. Which TCB may be an issue, but you can look at all of them. So you chain through the DEBs, each DEB points to a DCB (or ACB), each DCB has an offset in the TIOT to the relevant DDNAME entry, and that entry contains the DDNAME. When you find the matching DDNAME, you have your xCB. There is a slight difference if your DCB is open for SYSOUT or SYSIN. Then the DEB points to an ACB created by subsystem open processing, and a different DEB field points to your original DCB. The "which TCB" question is, I think, a matter of TSO/E and/or REXX generally playing strange with the normal rules - perhaps part of the scheme for running authorized programs under TSO. Most TCBs in your address space will have no open datasets, and the TCB DEB chain pointer will be zero. In REXX terms, i.e. 1-origin decimal, the TCBDEB chain pointer is at 9-12, the DEB at 1-4 points back to the TCB for sanity checking, the DEB next DEB pointer is at 5-8, the DEB DCB pointer is at 25-28, the DCB TIOT offset is an unsigned halfword at 41-42, and the DCB points back to the DEB at 45-48. The TIOT itself is found from the TCB at 13-16. This brings up the standard REXX storage() problem of fetching when you don't know the length in advance. But the first 24 bytes will always be there, and the entry pointed to by any DCB offset will always be there, and realistically it's unlikely that the TIOT would be close to the end of a page. Some of these pointers are 24-bit with stuff in the high byte. DEBs and DCBs are BTL, so you can probably just remove/zero the high byte. None of these blocks are in fetch-protected storage, but of course they are all in the private area. Now whether you can do more than "inspect", and "fix up" a DCB you find depends on how it was created; normal application program DCBs are, of course, in user key storage. Those opened by the TMP are in a system key (1?). I don't know about yours, but I suspect it too will be in a system key. We wouldn't want a mere REXX programmer changing the DCBPUT address or something... Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
