There are a lot of commands in TSO and some started tasks which allow specification of a dataset name as an output. Some examples would be XD in TSO SDSF. Or the ODS parameter on many DFHSM commands.
But there are times when I would wish that I could direct the output to a UNIX file instead of a sequential file. In a flash of insight or insanity, I thought of the IEFDB401 dynamic allocation exit. One use of this exit is to modify, add, and/or delete text units from a dynamic allocation. Well, would it be possible to look at a DSN in a dynamic allocation request and modify the text units so that some pattern triggers a change to temporarily remove the DSN & DISP text units and replace them with a set of PATH, PATHMODE, PATHOPTS, PATHDISP, and FILEDATA parameters. I know this would not be easy. First is how to tell if a substitution is desired? I had first thought of seeing if the DSN starts with a slash. But that's not valid in a DSN (usually) and most commands validate the DSN and reject it out-of-hand if it is invalid. So we need some way to figure out how to trigger. Next idea: a hard-coded HLQ which is used for no other purpose. Perhaps @UNIX. ? But now, the really had part. How to map the rest of the DSN to a UNIX path and file name. So I thought, why not a special node, say @, which separates the path from the file name? So a DSN is parsed @UNIX.<path>....@.<filename> . We're still a bit stuck because all the letters in a z/OS dataset name are usually UPPER CASE whereas most letters in a UNIX file name are lower case. And we can't easily map special characters which are invalid in a DSN. So, for those invalid charaters: sorry, can't use them. But we now need a way to map the <path> to an actual UNIX pathname. It needs to be a "low cost" method. Perhaps an STC which implements a PC which does a in-memory look from a table which is loaded into memory and does a binary search to do the map. If the map fails, the result in the IEFDB401 routine is to "do nothing" to the request and let it go through as-is. We could determine to either leave the UNIX file name "as is" in UPPER CASE or unconditionally translate it to lower case. Am I serious? Well, likely not. But I really would like many TSO and other "commands" to be able to output to a UNIX file. Why? So that I can look at the output "on the fly" using OBROWSE or tail. What really started this is that I am doing a massive DFHSM recycle right now. About 4,000 tapes worth. My command was like: F DFHSM,RECYCLE ALL PERCENTVALID(2) ODS(SOME.DATA.SET.NAME) But SOME.DATA.SET.NAME is allocated DISP=MOD and I cannot view it until the command completes. I know that I can see these messages in the DFHSM JESMSGLG or even the z/OS SYSLOG or OPERLOG. But this is not always true with some other commands. And my other main desire is to direct SDSF's XD to a UNIX file. And I don't want to first put it in a sequential file and then copy it. Nor do I want to SE and use EDIT to put it into a UNIX file either. Yea - I'm being a bit unreasonable. Perhaps SDSF could use an XU command? OK - I could use the XF command and use the standard TSO ALLOCATE to allocate the DDNAME to a UNIX file. I'm lazy, sue me. I guess what I'll do, for now, is write an ISPF REXX dialog "ALCUNIX" to put up a panel to take in my UNIX data and do a TSO ALLOCATE. <sigh> I'm just too lazy for my own good, sometimes. And it still doesn't address the general case of how to direct output from a program which only supports dynamic allocation of a sequential dataset to a UNIX file. Maybe I'd like do to the same for INPUT as well as output? But then I have problems with LRECL, RECFM, and other DCB parameters. Which could also bite me with an OUTPUT dataset too, I guess. Well, feeling free to ignore me if you think this is stupid. Or just say that it isn't worth the effort. -- John McKown Maranatha! <>< ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
