Re: blue sky thought: new class of member name in a PDS
In CAAJSdjgxxP=+cGfTAer6+wEHKQ=nivp1no78c_lysn3we7o...@mail.gmail.com, on 05/06/2013 at 08:58 AM, John McKown john.archie.mck...@gmail.com said: This is just a weird thought, feel free to call me an idiot. But there are two classes of members in a PDS at present. There are normal member and there are ALIASes. It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. Am I remembering correctly? No. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
blue sky thought: new class of member name in a PDS
Or maybe just for a PDSE since PDSes are basically moribund. This is just a weird thought, feel free to call me an idiot. But there are two classes of members in a PDS at present. There are normal member and there are ALIASes. It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. Am I remembering correctly? If so, then why not extend the ALIAS concept (a member name which points to another member name) to a new class of member, which I will call a CONCAT member. This is a member name which contains multiple member names, perhaps in the user data area. When you OPEN a CONCAT member for reading, what you get is the contents of all the members listed in the order listed. No, I can't think of a reason why this should be over a standard concatenation of DD statements. But I've only had a few hours sleep per night for the past week and so my mind is misfiring. -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
On 5/6/2013 6:58 AM, John McKown wrote: ... It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. Am I remembering correctly? From IGWSMDE: THE FOLLOWING IS A CASE BY CASE DIAGRAM OF THE POSSIBLE SECTIONS CONTAINED IN THE SMDE: 1) PRIMARY ENTRY - PDS DATA MEMBER: BASIC + NAME + USRD (MAY CONTAIN NOTELIST) 2) ALIAS ENTRY - PDS DATA MEMBER: BASIC + NAME + USRD (MAY CONTAIN NOTELIST) 3) PRIMARY ENTRY - PDSE DATA MEMBER: BASIC + NAME + TOKEN + USRD (NO NOTELIST) 4) ALIAS ENTRY - PDSE DATA MEMBER: BASIC + NAME + TOKEN + PNAME + USRD (NO NOTELIST) 5) PRIMARY ENTRY - PDS LOAD MODULE: BASIC + NAME + PMAR + PMARR 6) ALIAS ENTRY - PDS LOAD MODULE: BASIC + NAME + PNAME + PMAR + PMARR 7) PRIMARY ENTRY - PROGRAM OBJECT (HFS OR PDSE): BASIC + NAME + TOKEN + PMAR + PMARL 8) ALIAS ENTRY - PROGRAM OBJECT (HFS OR PDSE): BASIC + NAME + TOKEN + PNAME + PMAR + PMARL 9) C370LIB ENTRY (PDS or pdse): BASIC + NAME + PNAME + USRD + C370LIB_ATTR_WORD -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
John McKown wrote: ... feel free to call me an idiot. No. I will *NOT* do that. It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. AFAIK, ALIAS does contains a TTR, but that is the same as the original member. If so, then why not extend the ALIAS concept (a member name which points to another member name) to a new class of member, which I will call a CONCAT member. This is a member name which contains multiple member names, perhaps in the user data area. When you OPEN a CONCAT member for reading, what you get is the contents of all the members listed in the order listed. Good idea as long the data area used during an OPEN macro can handle that list and there is little overhead. I already can see a good use: varying list of contents to be used as input for a program or something. Those members can be changed before using that list of members/contents in any order. But I see some little problems: You may need re-parse/re-do your SVC99 so a concatenation can take place. But then again you perhaps need to redrive that SVC 99 to convert that DD into a concatenation. I'm thinking of that word DCCDDNAM and other keywords used for that macro. Unless, if you can write an intercepting exit which can recognize that member and do its own SVC99 instead calling/passing on the standard SVC 99 routines. I foresee there are heavy overhead work for locating each member (TTR), doing an ENQ while hoping the member and its contents are still there when you finally pick up the contents... When do you do an DEQ and FREE? After that member in the list or when your job step is finished? Alternatively, try creating your own Subsystem CONCAT and then this // DD DISP=SHR,DSN=pdse(CONCAT),SUBSYS=(CONCAT,your option) I'm pretty sure there are solutions in the USS / OMVS world where you can achieve something like this. I believe I have seen a custom command where you pipe all those members into one thing and pass it on. But my memory is rusting again... ;-D No, I can't think of a reason why this should be over a standard concatenation of DD statements. But I've only had a few hours sleep per night for the past week and so my mind is misfiring. You are needing 3 (concatenated!) weekends per work week. ;-D Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
UNIX is rather easy: cat file1 file2 file3 otherfile prefix-of-files* | command quite often, if the command expects one or more files, then a single dash can stand for read stdin at this point. In Linux (and z/OS) shell, it is possible to read /dev/fd/0 if the command doesn't implement the - as a shortcut to stdin. On Mon, May 6, 2013 at 10:01 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: snip I'm pretty sure there are solutions in the USS / OMVS world where you can achieve something like this. I believe I have seen a custom command where you pipe all those members into one thing and pass it on. But my memory is rusting again... ;-D snip Groete / Greetings Elardus Engelbrecht -- This is a test of the Emergency Broadcast System. If this had been an actual emergency, do you really think we'd stick around to tell you? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
On 5/6/2013 9:58 AM, John McKown wrote: This is just a weird thought, feel free to call me an idiot. But there are two classes of members in a PDS at present. There are normal member and there are ALIASes. It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. Am I remembering correctly? No. An alias entry differs by one bit, indicating its status, but has its normal complement of one or more TTRs. In the original design, only reentrant load module alias entries also had the name of the main member. I see no obvious way to indicate a member name list, as all bits in the minimum 12-byte directory entry are accounted for. SPF and binder entries could be expanded, but I'd just as soon have an option of specifying a name list on the DD. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
On 05/06/2013 08:58 AM, John McKown wrote: Or maybe just for a PDSE since PDSes are basically moribund. This is just a weird thought, feel free to call me an idiot. But there are two classes of members in a PDS at present. There are normal member and there are ALIASes. It generally seems that an ALIAS does not contain a TTR per se, but actually contains the actual member name. Am I remembering correctly? If so, then why not extend the ALIAS concept (a member name which points to another member name) to a new class of member, which I will call a CONCAT member. This is a member name which contains multiple member names, perhaps in the user data area. When you OPEN a CONCAT member for reading, what you get is the contents of all the members listed in the order listed. No, I can't think of a reason why this should be over a standard concatenation of DD statements. But I've only had a few hours sleep per night for the past week and so my mind is misfiring. The format of an alias directory entry does contain the actual TTR for the member, as well as the main member name (from the time the alias was created), and the alias entry TTR was the TTR used to access the data. One of the weird, confusing things that used to be possible, either deliberately or by accident, was that one could end up with an orphaned (but still functional) alias entry that pointed to a different TTR and data than the TTR in the then-current entry for the main member name. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: blue sky thought: new class of member name in a PDS
John McKown wrote: UNIX is rather easy: cat file1 file2 file3 otherfile prefix-of-files* | command Thanks for oiling my rusting memory. grin REXX is also easy. That is if you don't care to have an extra member containing a list of members. Just 2 loops. One loop for list of member(s) and second loop to get the lines and pass it on to one big mother of dataset/file for further processing. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
