It is definitely possible. mumble years ago I wrote such an IEFDB401 to convert passwords to volsers (as passwords were not used).
That allowed ALLOC F(abc) DA(dsn1/vol1 dsn2/vol2 ...) in place of ALLOC F(abc) DA(dsn1) VOL(vol1) ALLOC F(abc2) DA(dsn2) VOL(vol2) CONCAT abc abc2 If passwords were used, I would have used some key such as "password" volume being online or something like that. Your big problem is that you are limited to a 44 character name space. But if you can figure out how to map the name IEFDB401 could be a solution. On Fri, 26 Nov 2010 11:12:20 -0600 John McKown <[email protected]> wrote: :>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. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
