Re: PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
In du2356lef63ibf2hqc4fgng1rrd62u9...@4ax.com, on 07/29/2010 at 11:14 AM, Clark Morris cfmpub...@ns.sympatico.ca said: I don't know anything about the BUNCH operating systems and their successors. The had libraries, in some cases with better interfaces than PDS's. I don't see anything comparable in either Unix/Linux or Windows. DLL's are vaguely comparable, but I was thinking of mainframe operating systems. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
On 28 Jul 2010 21:07:47 -0700, in bit.listserv.ibm-main you wrote: In ahir46pl6pf37rnd70alkbiutp8vv4h...@4ax.com, on 07/26/2010 at 11:47 AM, Howard Brazee howard.bra...@cusys.edu said: I don't even like ordinary PDS. Other operating systems don't need them. ITYM that they call them something else. I know that VSE has/had libraries and I wouldn't be surprised if the OS400 and follow-on operating systems had similar constructs. I don't know anything about the BUNCH operating systems and their successors. I don't see anything comparable in either Unix/Linux or Windows. Clark Morris -- 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
Re: Another reason to hate PDSE's
On Wed, 28 Jul 2010 21:49:34 -0400, Shmuel Metz (Seymour J.) wrote: In ahir46pl6pf37rnd70alkbiutp8vv4h...@4ax.com, on 07/26/2010 at 11:47 AM, Howard Brazee said: I don't even like ordinary PDS. Other operating systems don't need them. ITYM that they call them something else. I see it differently. I assume the something else in other OSes is a directory or a folder. Usually, these differ from PDS[E]s in significant respects: o When a member is deleted the space it occupied is immediately reclaimed (not PDS), and even released to the parent filesystem. o Directories may contain both program objects and non-program objects (whether wisely or not). o Directories may contain subdirectories. o Directories may contain aliases (shortcuts, links, symlinks) to objects in other directories. Enough functional differences to not consider them synonymous. -- gil -- 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
Re: PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
I don't see anything comparable in either Unix/Linux or Windows. DLL's are comparable. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
Ted MacNEIL wrote: I don't see anything comparable in either Unix/Linux or Windows. DLL's are comparable. - I'm not sure I follow this - just how are DLL's comparable to PDS's? - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- 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
Re: PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
I'm not sure I follow this - just how are DLL's comparable to PDS's? They hold more than one 'member' of executable run time modules, similar to SEERUN, for example. Even the name 'Dynamic Link Library' could be comparable. But, remember 'comparable' does not mean exact. They are also more limited than z/OS libraries. Also, multi-membered ZIP files could be (loosely) compared, as well. Somebody stated there were no equivalents on other OS's. At the risk of being pedantic, I came up with an example. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: PDSs or libraries in other OSs was Re: Another reason to hate PDSE's
Sure. Heck, a single-level subdirectory is similar to a PDS! That's how I describe them to the PC kids I work with... On Thu, Jul 29, 2010 at 4:24 PM, Ted MacNEIL eamacn...@yahoo.ca wrote: snip Somebody stated there were no equivalents on other OS's. At the risk of being pedantic, I came up with an example. -- 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
Re: Another reason to hate PDSE's
In listserv%201007290954519942.0...@bama.ua.edu, on 07/29/2010 at 09:54 AM, Paul Gilmartin paulgboul...@aim.com said: I see it differently. I assume the something else in other OSes is a directory or a folder. Or something else. Enough functional differences to not consider them synonymous. Then it's a good thing that I was not referring to directories. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another reason to hate PDSE's
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Tuesday, July 27, 2010 12:06 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Another reason to hate PDSE's SNIP If you don't understand what's wrong with PDS, re-read Etienne Thijsse's thread on attempting to delete a PDSE member. Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. Enough counterintuitive behaviors and flaws with recondite repairs add up to wrong. SNIPPAGE I suppose that if I were to work with a VSAM file with DISP=(SHR,DELETE), that it would be JCL's fault when the VSAM file goes to the bit bucket. And if you were using a data base that you have to point to, and you wanted to delete a row and coded DISP=(OLD,DELETE), that would be JCL's fault also. Later, Steve Thompson -- 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
Re: Another reason to hate PDSE's
On Wed, 28 Jul 2010 10:04:52 -0400, Thompson, Steve wrote: SNIP If you don't understand what's wrong with PDS, re-read Etienne Thijsse's thread on attempting to delete a PDSE member. Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. Enough counterintuitive behaviors and flaws with recondite repairs add up to wrong. SNIPPAGE I suppose that if I were to work with a VSAM file with DISP=(SHR,DELETE), that it would be JCL's fault when the VSAM file goes to the bit bucket. And if you were using a data base that you have to point to, and you wanted to delete a row and coded DISP=(OLD,DELETE), that would be JCL's fault also. What are you assuming appears as the value of DSN=? (I'm not sure what you mean by a VSAM file?) I'd expect a JCL error for (SHR,DELETE) since exclusive access is required for DELETE. In the second case, if DSN= identifies a particular row (is this syntactically possible?), I'd intuitively expect that one row to be deleted; if DSN= identifies the entire data base, the entire data base should be deleted. We are burdened nowadays with Byzantine behaviors that were a necessary accommodation to resource constraints that prevailed 45 years ago. Today, if the programmer codes DSN=DATA.SET(MEMBER), DISP=(OLD,DELETE), it should be easy enough for deallocation to issue a STOW to delete that specific member. The PDS itself is an accommodation to such an antiquated constraint. In 1965 it was elegant; nowadays it's a quaint PITA. -- gil -- 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
Re: Another reason to hate PDSE's
In ahir46pl6pf37rnd70alkbiutp8vv4h...@4ax.com, on 07/26/2010 at 11:47 AM, Howard Brazee howard.bra...@cusys.edu said: I don't even like ordinary PDS. Other operating systems don't need them. ITYM that they call them something else. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another reason to hate PDSE's
Barbara Nitz wrote: No, it's 64K tracks. It is the same per volume limit as many other data set types (non-extended). But PDSes and PDSEs are also limited to a single volume. I am surprised. I did not know about *those* limitations. And most certainly, since they are documented, there will be no way to change things. But: I seem to remember that PDSEs were touted as the only ones making sense on an EAV, because of the 'extented' part of the name, and that they could get bigger (but maybe I misunderstood). Not that I would encourage use of such a large volume, as it is much too slow, and I still haven't opened an ETR to address 90s (or more) until ISPF 3.4 gives you the directory view. (Might end up on an ISPF queue, which would require me to open a complaint due to incompetence.) PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- 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
Re: Another reason to hate PDSE's
Steve Comstock pisze: Barbara Nitz wrote: [...] PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. While I could provide more PDSE advantages than Barbara, I would not mention long names. Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are not handy for me. Of course I know, there are some... but not in operating system components. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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
Re: Another reason to hate PDSE's
On Tue, 27 Jul 2010 12:26:50 +0200, R.S. wrote: Steve Comstock pisze: Barbara Nitz wrote: [...] PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara And, I believe, multiple members can be written concurrently (I believe; am I right?) How would one do this? Must one OPEN two or more DCBs, one for each member being written? And one might yet wish to be able to append or update in place existing members. Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. Steve, why would you call that an advantage? I thought you despise case-sensitivity. Anyway, old fashioned PDSes allow case-sensitive (but not long) member names; it's merely higher level interfaces that try to conceal the case-sensitivity. Would you advocate supporting case-insensitivity at the DFSMS layer, similar to Windows? Mac OS X gives the programmer a choice with a granularity of volume. While I could provide more PDSE advantages than Barbara, I would not mention long names. Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are not handy for me. Of course I know, there are some... but not in operating system components. Isn't this a solution seeking a problem? What interfaces support them? Surely, one can't code // EXEC PGM=Case-sensitive-Long-name? What about ATTACH EP=Case-sensitive-Long-name? What's the format of the word returned by NOTE for a PDSE. It's been discussed here that the low 24 bits contain the relative record number within a member (biased by 0x10). Do the top 8 bits then identify the member? What happens, then, if a programmer performs BLDL for 257 different members? can the NOTE words identify connections to all? If one performs 2 BLDLs for the same member, are the two returned pointers identical? How do Unix directories compare? o They don't need to be compressed. o Multiple members can be written concurrently. o Members can be appended or updated in place (with a granularity of byte.). o They support long case-sensitive names. o They allow a mixture of program objects and other member types. Deficiencies: o Alias entry points are not supported (AFAIK). o The BPAM support is read-only (so far). Questions: o How do performance and reliablity compare with PDS[E]? I suppose there might be four answers, separate for PDS vs. PDSE and for HFS vs. zFS. o What is the limit on member size? o What is the limit on number of members? -- gil -- 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
Re: Another reason to hate PDSE's
PDSEs have only one advantage: snip Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. http://bama.ua.edu/archives/ibm-main.html No not really. Longer names may be contained within the program object, e.g. CALL someverylongname and the binder will make sense of it. External entrypoints (those that could be used by ATTACH, LINK etc.) are still only 8 bytes long. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 17:57:07 +, Ted MacNEIL wrote: I don't even like ordinary PDS. Other operating systems don't need them. That doesn't make them wrong. There are some implementation flaws, but they exist, so use them, and know flaws and repairs. If you don't understand what's wrong with PDS, re-read Etienne Thijsse's thread on attempting to delete a PDSE member. Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. Enough counterintuitive behaviors and flaws with recondite repairs add up to wrong. PS: Can you spell DLL? Nobody's perfect; that's no excuse. -- gil -- 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
Re: Another reason to hate PDSE's
If you don't understand what's wrong with PDS, re-read Etienne Thijsse's thread on attempting to delete a PDSE member. I didn't say I didn't understand, I said that you had to do so. Understand their limitations, and how to fix them when they break. They're not going away. Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. That is documented in so many places. The JCL Manual/User's Guide (or whatever IBM's calling it/them now), for example, and nowhere does it say DISP works at the member level. The explanation of DISP is at the dataset level, everywhere I've looked. Enough counterintuitive behaviors You can't blame PDS(E) for 45+ years of documented behaviour. and flaws with recondite repairs add up to wrong. Possibly, but there are many cases in z/OS where you are stuck with them. I'm not a fan of PDSE, anymore, since IBM broke them circa 2003. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: Another reason to hate PDSE's
A little OT, but just wondering: does ISPF do the same ENQs for PDSEs as with PDS when updating members? -- 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
Re: Another reason to hate PDSE's
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Tuesday, July 27, 2010 1:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Another reason to hate PDSE's A little OT, but just wondering: does ISPF do the same ENQs for PDSEs as with PDS when updating members? Yes. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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
Re: Another reason to hate PDSE's
Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS conversion, all procs were stored in SYS1.PROCLIB. Excessively neat programmer deleted a member using that technique. System was unbootable. When the system came back after the sysgen (no backup res pack!), an APPL.PROCLIB was created and all SYS1 datasets were password protected. Ops was not given the password. So in 40 yrs, the same design flaw has bit how many people/shops? On the other hand, most programs I wrote in the 1960s would run today, if there were still card readers. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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
Re: Another reason to hate PDSE's
-snip Barbara Nitz wrote: No, it's 64K tracks. It is the same per volume limit as many other data set types (non-extended). But PDSes and PDSEs are also limited to a single volume. I am surprised. I did not know about *those* limitations. And most certainly, since they are documented, there will be no way to change things. But: I seem to remember that PDSEs were touted as the only ones making sense on an EAV, because of the 'extented' part of the name, and that they could get bigger (but maybe I misunderstood). Not that I would encourage use of such a large volume, as it is much too slow, and I still haven't opened an ETR to address 90s (or more) until ISPF 3.4 gives you the directory view. (Might end up on an ISPF queue, which would require me to open a complaint due to incompetence.) PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. unsnip--- Steve, I'm incredibly happy you said SOMETIMES, because I've lived with 8-character PDS member names for 40+ years and never could think of a really severe need for the variations you suggest. :-) Rick -- 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
Re: Another reason to hate PDSE's
A little OT, but just wondering: does ISPF do the same ENQs for PDSEs as with PDS when updating members? I don't think it's OT, but the answer is YES. PDSEs, while different under the covers, still look like PDS's to the uninitiated (programmes, not people). - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: Another reason to hate PDSE's
snip-- If you don't understand what's wrong with PDS, re-read Etienne Thijsse's thread on attempting to delete a PDSE member. Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. Enough counterintuitive behaviors and flaws with recondite repairs add up to wrong. --unsnip-- I submit that this issue was caused by a faulty understanding of how PDS's and JCL work together. You can view it as a flaw if you like, and I do, but there are provided mechanisms to circumvent this flaw. Not always nice and certainly not intuitive, but still available. Rick -- 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
Re: Another reason to hate PDSE's
On Tue, 27 Jul 2010 15:42:57 -0400, Kirk Talman wrote: Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS conversion, all procs were stored in SYS1.PROCLIB. Excessively neat programmer deleted a member using that technique. System was unbootable. When the system came back after the sysgen (no backup res pack!), an APPL.PROCLIB was created and all SYS1 datasets were password protected. Ops was not given the password. So in 40 yrs, the same design flaw has bit how many people/shops? But none of those should perceive a problem, since the behavior is documented. -- gil -- 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
Re: Another reason to hate PDSE's
Paul Gilmartin wrote: On Tue, 27 Jul 2010 12:26:50 +0200, R.S. wrote: Steve Comstock pisze: Barbara Nitz wrote: [...] PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara And, I believe, multiple members can be written concurrently (I believe; am I right?) How would one do this? Must one OPEN two or more DCBs, one for each member being written? And one might yet wish to be able to append or update in place existing members. Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. Steve, why would you call that an advantage? I thought you despise case-sensitivity. I do. But in some environments (e.g., DLLs, C, C++) it is a fact of life. If you want to port / use applications from the z/OS world it is good to have the ability. Anyway, old fashioned PDSes allow case-sensitive (but not long) member names; it's merely higher level interfaces that try to conceal the case-sensitivity. Ah, good point. I'd forgotten that, since the interfaces I work with day to day are exactly of that type. Would you advocate supporting case-insensitivity at the DFSMS layer, similar to Windows? Mac OS X gives the programmer a choice with a granularity of volume. Not sure on that one. While I could provide more PDSE advantages than Barbara, I would not mention long names. Reason: I HAVE NEVER SEEN AN APPLICATION WHICH USES THEM. Long names are not handy for me. Of course I know, there are some... but not in operating system components. Isn't this a solution seeking a problem? What interfaces support them? Surely, one can't code // EXEC PGM=Case-sensitive-Long-name? What about ATTACH EP=Case-sensitive-Long-name? Well, you can call DLL entry points from Assembler, COBOL, C, and PL/I. But you can't invoke them from JCL, that's true. Nor can you LOAD, XCTL, or ATTACH to long entry points. But several bpx services can access a long, mixed case, entry name. I admit, it's a stretch. The average day-to-day application programmer does not have a need / use for this feature, at least not today, and one has to work at it to be able to use it. What's the format of the word returned by NOTE for a PDSE. It's been discussed here that the low 24 bits contain the relative record number within a member (biased by 0x10). Do the top 8 bits then identify the member? What happens, then, if a programmer performs BLDL for 257 different members? can the NOTE words identify connections to all? If one performs 2 BLDLs for the same member, are the two returned pointers identical? How do Unix directories compare? o They don't need to be compressed. o Multiple members can be written concurrently. o Members can be appended or updated in place (with a granularity of byte.). o They support long case-sensitive names. o They allow a mixture of program objects and other member types. Deficiencies: o Alias entry points are not supported (AFAIK). o The BPAM support is read-only (so far). Questions: o How do performance and reliablity compare with PDS[E]? I suppose there might be four answers, separate for PDS vs. PDSE and for HFS vs. zFS. o What is the limit on member size? o What is the limit on number of members? -- gil Well, I've been getting more and more into the z/OS UNIX world, and I think you've raised some good questions / concerns here. But based on a thread last year (or was it two years ago), there seems to be precious little management interest in, or support for, developing new applications using z/OS UNIX, and the systems folks on ibm-main are certainly not big fans (for the most part, anyway), eh Barbara? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment -- 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
Re: Another reason to hate PDSE's
On 27 Jul 2010 13:18:29 -0700, in bit.listserv.ibm-main you wrote: -snip Barbara Nitz wrote: No, it's 64K tracks. It is the same per volume limit as many other data set types (non-extended). But PDSes and PDSEs are also limited to a single volume. I am surprised. I did not know about *those* limitations. And most certainly, since they are documented, there will be no way to change things. But: I seem to remember that PDSEs were touted as the only ones making sense on an EAV, because of the 'extented' part of the name, and that they could get bigger (but maybe I misunderstood). Not that I would encourage use of such a large volume, as it is much too slow, and I still haven't opened an ETR to address 90s (or more) until ISPF 3.4 gives you the directory view. (Might end up on an ISPF queue, which would require me to open a complaint due to incompetence.) PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. unsnip--- Steve, I'm incredibly happy you said SOMETIMES, because I've lived with 8-character PDS member names for 40+ years and never could think of a really severe need for the variations you suggest. :-) Given the obscure program names, proc names and member names we have due to the 8 character limitation, I for one would have liked names to be at least 16 characters. In fact I still would and the 8 byte limitation must seem weird and out of date to someone coming from a UNIX or Windows environment. Clark Morris Rick -- 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
Re: Another reason to hate PDSE's
On 27 Jul 2010 14:17:48 -0700, in bit.listserv.ibm-main you wrote: On Tue, 27 Jul 2010 15:42:57 -0400, Kirk Talman wrote: Or imagine my astonished dismay the first time I allocated a member with DISP=(OLD,DELETE) and watched the entire PDS vanish. In the early 1970s, at a bank using MVT on 370/155, soon after DOS-OS conversion, all procs were stored in SYS1.PROCLIB. Excessively neat programmer deleted a member using that technique. System was unbootable. When the system came back after the sysgen (no backup res pack!), an APPL.PROCLIB was created and all SYS1 datasets were password protected. Ops was not given the password. So in 40 yrs, the same design flaw has bit how many people/shops? But none of those should perceive a problem, since the behavior is documented. Just because a stupid design is documented doesn't make it any less stupid. Clark Morris -- gil -- 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 -- 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
Re: Another reason to hate PDSE's
Just because a stupid design is documented doesn't make it any less stupid. True. But, people should not be taken by surprise by something that is well known. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: Another reason to hate PDSE's
Well, they do have at least one other advantage: they can store
program objects, which allows entry points with long, case-sensitive
names, which is sometimes handy.
But based on a thread last year (or was it two years ago), there
seems to be precious little management interest in, or support for,
developing new applications using z/OS UNIX, and the systems folks
on ibm-main are certainly not big fans (for the most part, anyway),
eh Barbara?
okay, I'll bite:
Long entry points.
Have you ever seen a dump of an address space running some sort of
Websphere? Almost *all* of those lmod names are 'long', usually
called 'specialname'. And I don't talk about Java here.
How do Unix directories compare?
o They don't need to be compressed.
o Multiple members can be written concurrently.
o Members can be appended or updated in place (with a granularity
of byte.).
o They support long case-sensitive names.
o They allow a mixture of program objects and other member types.
You're all aware that the original HFSs are based on PDSE code, right? In fact,
they use the same lower levels like media manager to do the actual IO, and on
top of that IGW.. (i.e. PDSE) modules, and then it starts to be different. As
far
as I know, all of the above is a characteristic of PDSEs, that HFSs just happen
to use. And I bet it wasn't too hard (given that media manager uses 4K blocks,
anyway) to put the HFS functionality into zFS, which are VSAM linear using 4K
blocks.
Questions:
o How do performance and reliablity compare with PDS[E]? I suppose
there might be four answers, separate for PDS vs. PDSE and for
HFS vs. zFS.
Take a look at my performance problems with (not-even-*that*-) large
PDSEs. At least one other installation has the same issue, and I bet there are
more out there. Performance of larger PDSE is abysmal, but the limits of PDSs
(they cannot be allocated larger than 64K tracks) force us to use them.
PDS outperforms PDSE for allocations lower than 64K tracks. And that can be
directly attributed to the design of PDSEs - their 'directory' is not in one
place
like in PDS's, but scattered throughout the dataset. So in order to get the
full
directory of the PDSE (10.000 member), in our case it takes more than 10.000
IOs (verified by looking at the SMF records) to get the directory. The long
time (more than 90seconds) to get that list can be directly attributed to the
time it takes for the IO to come back. Remedy is to have a program that keeps
the dataset open artificially, but that only helps for the first about 15
minutes
after the first real access.
I have also mentioned it before: Back when we ran Lotus Notes on z/OS, we
migrated those HFSs to zFS first chance we got (on IBMs urgent
recommendation, when the performance was bad). Fat lot of good it did. After
about 6 months we went back to HFS, and they were *faster* than zFS, due
to the fact that in those days the HFS/PDSE directory must have been stored
differently. A 'recopy' or 'reorg' in those days made directory access faster,
and then performance of the HFS was better than via zFS. That was more
than 5 years ago. (And Lotus Notes now runs on zLinux). Some design change
in PDSE took away that 'reorg' capability (that boosted performance), so
recopying it these days has no effect whatsoever. That's when I invented
my 'just-do-an-open' program.
And the funny thing is, when PDSEs came out about MVS 4.3 (or was it 4.2
and the corresponding SMS version), I really liked them. Still do for *small*
datasets.
But I also think that if they hadn't been foisted on us, then IBM would have
just as happily found a way to make long names and all the new functionality
possible these days only via PDSE for PDSs. As I understand it, back then
customers complained about the need for reorganization. And using PDSE code
for HFSs (now 'functionally stabilized') was just a marketing ploy to force the
world to use PDSEs, IMO. Just like RRSs (or CICSs) use of logger was a way to
get system looger more widely accepted. Just as 'giving away' a WAS
underneath z/OSMF ('at no cost') is a way to enforce usage of WAS on z/OS.
And new functionality will be forced to use z/OSMF, just to get customers
needing that functionality to use z/OSMF.
Barbara
--
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
Re: Another reason to hate PDSE's
On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle pinnc...@rochester.rr.com wrote: I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 08:51:31 -0500, Mark Zelden wrote: Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Hmmm. d2x(15,728,639) is ef. Do they reserve the lower values for flags? And d2x(522,236) is 7f7fc. Inexplicable. -- gil -- 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
Re: Another reason to hate PDSE's
- Original Message - From: Mark Zelden mzel...@flash.net Newsgroups: bit.listserv.ibm-main Sent: Monday, July 26, 2010 9:52 AM Subject: Re: Another reason to hate PDSE's On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle pinnc...@rochester.rr.com wrote: I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Z, Is this documented anywhere? I searched Using Datasets and came up empty. Tom -- 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
Re: Another reason to hate PDSE's
On 25 Jul 2010 18:42:52 -0700, in bit.listserv.ibm-main you wrote: Some months ago, John Ehrman posted asking why we don't like PDSE's. I just found somehting that blows my mind, a ridiculous limitation in PDSE's that all by itself militates against their usage. I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Let that sink in a little. That 68M line member was easily stored in the PDS before the E37, but PDSE can't handle it. PDSE can't support members as big as PDS. Are you #$%ing kidding me? PDSE's are a joke. They've been around for over 20 years, and they still don't have all the bugs out. This limitation is ridiculous, considering that PDSE's were supposed to address all the shortcomings of PDS. GUESS THEY MISSED THIS SHORTCOMING OF PDSE's!! WAY TO GO IBM!!! Could Unix directories handle all of the functions of PDSE? When I read that we would still need PDSs, I wondered what pointy haired idiot designed the PDSE where one needed a started address space even to read it. Clark Morris Sheesh, Tom Conley -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 09:10:16 -0500, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 26 Jul 2010 08:51:31 -0500, Mark Zelden wrote: Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Hmmm. d2x(15,728,639) is ef. Do they reserve the lower values for flags? Did you note the starting TTR? X'FF' - X'11' + 1 is 15,728,639. And d2x(522,236) is 7f7fc. Inexplicable. Yeah, I never figured that one out exactly. The number is fairly close to the highest TTR for a member, which is X'07'. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 10:13:54 -0400, Pinnacle pinnc...@rochester.rr.com wrote: Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Is this documented anywhere? I searched Using Datasets and came up empty. Yes, it is in DFSMS Using Data Sets. At least at z/OS 1.10 and above (I didn't check earlier): MAXIMUM MEMBERS IN A PDSE: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2?SHELF=DGT2BK81DT=20080602122917 MAXIMUM RECORDS (LINES) IN A PDSE MEMBER: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2.4?SHELF=DGT2BK81DT=20080602122917CASE= http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.3?SHELF=DGT2BK81DT=20080602122917 -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: Another reason to hate PDSE's
From my previous days as a frequent SHARE attendee, I have often seen IBM ask specific technical questions of their customer base when contemplating a redesign; e.g., when designing SMS in the early 1980s, they polled their customers to find out how many, if any, were still using unmovable data sets, certain BDAM options, etc. I guess they forgot to ask their customer base what was the largest single PDS member they had. Or did they even conduct such a poll to learn about PDS usage? And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Don Williams Sent: Monday, July 26, 2010 11:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Another reason to hate PDSE's I'm not sure what IBM's PDS design objectives were in the early '60s, but I expect that one was to store multiple data sets per track. Of course, these would tend to be small data sets. I expect that IBM assumed that very few customers, if any, had very large members. Therefore when they designed a replacement, PDSE, handling large members was not likely to be a high priority. Of course, that does not help you, but I can easily see the PDSE designers asking, his member has how many lines? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Sunday, July 25, 2010 9:42 PM To: IBM-MAIN@bama.ua.edu Subject: Another reason to hate PDSE's Some months ago, John Ehrman posted asking why we don't like PDSE's. I just found somehting that blows my mind, a ridiculous limitation in PDSE's that all by itself militates against their usage. I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Let that sink in a little. That 68M line member was easily stored in the PDS before the E37, but PDSE can't handle it. PDSE can't support members as big as PDS. Are you #$%ing kidding me? PDSE's are a joke. They've been around for over 20 years, and they still don't have all the bugs out. This limitation is ridiculous, considering that PDSE's were supposed to address all the shortcomings of PDS. GUESS THEY MISSED THIS SHORTCOMING OF PDSE's!! WAY TO GO IBM!!! Sheesh, Tom Conley -- 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 -- 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 -- 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
Re: Another reason to hate PDSE's
- Original Message - From: Mark Zelden mzel...@flash.net Newsgroups: bit.listserv.ibm-main Sent: Monday, July 26, 2010 10:44 AM Subject: Re: Another reason to hate PDSE's On Mon, 26 Jul 2010 10:13:54 -0400, Pinnacle pinnc...@rochester.rr.com wrote: Yep, you went slightly over the limit of 15,728,639 Record number TTRs start at X'11' within a PDSE member. Record number TTRs range from X'11' to X'FF'. The maximum number of PDSE members is 522,236. Is this documented anywhere? I searched Using Datasets and came up empty. Yes, it is in DFSMS Using Data Sets. At least at z/OS 1.10 and above (I didn't check earlier): MAXIMUM MEMBERS IN A PDSE: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2?SHELF=DGT2BK81DT=20080602122917 MAXIMUM RECORDS (LINES) IN A PDSE MEMBER: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.2.4?SHELF=DGT2BK81DT=20080602122917CASE= http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2D470/3.8.3?SHELF=DGT2BK81DT=20080602122917 Thanks, it explains why my searches came up empty. I didn't have time to read the whole PDSE section. What a crappy design. The maximum PDSE member size should have been at least the number of 80-byte records that would have filled up a 65535 track PDS. Brain dead. Regards, Tom Conley -- 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
Re: Another reason to hate PDSE's
I'm not sure what IBM's PDS design objectives were in the early '60s, but I expect that one was to store multiple data sets per track. Of course, these would tend to be small data sets. I expect that IBM assumed that very few customers, if any, had very large members. Therefore when they designed a replacement, PDSE, handling large members was not likely to be a high priority. Of course, that does not help you, but I can easily see the PDSE designers asking, his member has how many lines? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Sunday, July 25, 2010 9:42 PM To: IBM-MAIN@bama.ua.edu Subject: Another reason to hate PDSE's Some months ago, John Ehrman posted asking why we don't like PDSE's. I just found somehting that blows my mind, a ridiculous limitation in PDSE's that all by itself militates against their usage. I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Let that sink in a little. That 68M line member was easily stored in the PDS before the E37, but PDSE can't handle it. PDSE can't support members as big as PDS. Are you #$%ing kidding me? PDSE's are a joke. They've been around for over 20 years, and they still don't have all the bugs out. This limitation is ridiculous, considering that PDSE's were supposed to address all the shortcomings of PDS. GUESS THEY MISSED THIS SHORTCOMING OF PDSE's!! WAY TO GO IBM!!! Sheesh, Tom Conley -- 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 -- 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
Re: Another reason to hate PDSE's
On Mon, 2010-07-26 at 12:46 -0400, Pinnacle wrote: What a crappy design. [...] Brain dead. I'm inclined to give the PDSE designers a little more credit. One of the PDSPAIN White Paper's requirements was not another VSAM - at the time we were struggling with the filesystem-within-a-filesystem mashup that was VSAM suballocated space. Thank FSM they stopped short of that. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 11:16:17 -0300, Clark Morris wrote: Could Unix directories handle all of the functions of PDSE? When I read that we would still need PDSs, I wondered what pointy haired idiot designed the PDSE where one needed a started address space even to read it. Well, if you don't need STOW. Or you are willing to forgo BPAM entirely and use native Unix services. -- gil -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 12:32:00 -0400, Don Williams wrote: I'm not sure what IBM's PDS design objectives were in the early '60s, but I expect that one was to store multiple data sets per track. Of course, these would tend to be small data sets. I expect that IBM assumed that very few customers, if any, had very large members. Therefore when they designed a replacement, PDSE, handling large members was not likely to be a high priority. Of course, that does not help you, but I can easily see the PDSE designers asking, his member has how many lines? There are only three nice numbers: 0, 1, and as many as you like. 15,000,000 is not one of those. -- gil -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 17:00:52 +, Bill Fairchild wrote: And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members. I believe SMP/E doesn't do that any more; rather it uses VSAM. The design suffered a compatibility constraint: how do you divide up a 32-bit NOTE word to support both more members and more records. They might have done better by not allowing the soft blocking. But then they'd need to somehow index variable size blocks. -- gil -- 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
Re: Another reason to hate PDSE's
And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? No, just like standard PS, it's tracks. Regardless of what you specify, DADSM translates to tracks, in the VTOC. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: Another reason to hate PDSE's
On 26 Jul 2010 07:16:35 -0700, cfmpub...@ns.sympatico.ca (Clark Morris) wrote: Could Unix directories handle all of the functions of PDSE? When I read that we would still need PDSs, I wondered what pointy haired idiot designed the PDSE where one needed a started address space even to read it. I don't even like ordinary PDS. Other operating systems don't need them. -- 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
Re: Another reason to hate PDSE's
I don't even like ordinary PDS. Other operating systems don't need them. That doesn't make them wrong. There are some implementation flaws, but they exist, so use them, and know flaws and repairs. PS: Can you spell DLL? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: Another reason to hate PDSE's
On Mon, 26 Jul 2010 17:00:52 +, Bill Fairchild bi...@mainstar.com wrote: And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? No, it's 64K tracks. It is the same per volume limit as many other data set types (non-extended). But PDSes and PDSEs are also limited to a single volume. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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
Re: Another reason to hate PDSE's
How can you have directory entries, and no members? I can see having a huge directory and no members, but how can you have a directory entry that doesn't point to a member? -- Eric Bielefeld Systems Programmer Bill Fairchild bi...@mainstar.com wrote: And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members. Bill Fairchild Rocket Software -- 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
Re: Another reason to hate PDSE's
The member data is stored in the directory entry as userdata, hence no real member data exists. TTR pointers are zero. Regards, John K From: Eric Bielefeld eric-ibmm...@wi.rr.com To: IBM-MAIN@bama.ua.edu Date: 07/26/2010 01:41 PM Subject:Re: Another reason to hate PDSE's How can you have directory entries, and no members? I can see having a huge directory and no members, but how can you have a directory entry that doesn't point to a member? -- Eric Bielefeld Systems Programmer Bill Fairchild bi...@mainstar.com wrote: And isn't the maximum size of a PDS 65535 cylinders instead of 65535 tracks? But Tom Conley has an excellent point that the maximum size of a PDS member should be supported by any redesign. E.g., I have seen some large PDSes that consisted of only a directory. One example is SMP. Another was a customer file I ran across decades ago where an entire volume was a PDS with only a directory in it; i.e., all directory entries and no members. Bill Fairchild Rocket Software -- 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 -- 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
Re: Another reason to hate PDSE's
No, it's 64K tracks. It is the same per volume limit as many other data set types (non-extended). But PDSes and PDSEs are also limited to a single volume. I am surprised. I did not know about *those* limitations. And most certainly, since they are documented, there will be no way to change things. But: I seem to remember that PDSEs were touted as the only ones making sense on an EAV, because of the 'extented' part of the name, and that they could get bigger (but maybe I misunderstood). Not that I would encourage use of such a large volume, as it is much too slow, and I still haven't opened an ETR to address 90s (or more) until ISPF 3.4 gives you the directory view. (Might end up on an ISPF queue, which would require me to open a complaint due to incompetence.) PDSEs have only one advantage: They don't need to get compressed. The rest us a huge amount of disadvantages. Regards, Barbara -- 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
Re: Another reason to hate PDSE's
On Sun, 25 Jul 2010 21:41:42 -0400, Pinnacle wrote: Let that sink in a little. That 68M line member was easily stored in the PDS before the E37, but PDSE can't handle it. PDSE can't support members as big as PDS. Are you #$%ing kidding me? I can understand it. I don't know that I can forgive it. The NOTE word for a PDSE is a relative line number and an indicator of the member. Suppose it's 6 bits for the member and 26 for the line (x2d(3ff)==67,108,863 -- will it handle 67 M?) And if it allows 6 bits for the member, what happens if you do BLDLs for 65 members, then POINT to each in succession. This problem arise partly because PDSEs are logically unblocked. The same would happen if your PDS were unblocked. So what!? -- gil -- 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
Re: Another reason to hate PDSE's
Tom, Maybe z/OS needs to take a look at the library structure we have available on z/VSE. This library structure has been available since the release of VSE/ESA Version 1 Release 1. A z/VSE library can contain PHASEs (a.k.a. loadable modules), object members, source members, JCL PROCs, storage dumps, and virtually any other user defined data. A z/VSE library can be shared between systems and compressed on the fly without fear of corruption. AFAIK, the maximum size of a z/VSE library is 2G-1 1024 byte blocks. I have not checked, so I cannot say for certain that the z/VSE library structure can handle a member containing 68M records. I suspect that a member is limited to either 2G-1 bytes or 2G-1 records. If the former limitation applies, the z/VSE library structure would NOT be able to accommodate such a member. If the latter limitation applies, which I believe to be the case, the z/VSE library structure would be able to easily accommodate such a member. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Sunday, July 25, 2010 9:42 PM To: IBM-MAIN@bama.ua.edu Subject: Another reason to hate PDSE's Some months ago, John Ehrman posted asking why we don't like PDSE's. I just found somehting that blows my mind, a ridiculous limitation in PDSE's that all by itself militates against their usage. I'm running a utility that outputs IEBUPDTE cards to create a PDS. When running the cards, we hit the maximum size of a PDS, 65535 tracks. Any attempt to go beyond that gets us an E37 abend. So simple solution, right? We just go PDSE. 19 members into the IEBUPDTE cards is a member with 68,994,447 records. This member causes an IEC036I 002-A8 abend, Looking that up says that the maximum number of lines that can be held in a PDSE member is exceeded. Let that sink in a little. That 68M line member was easily stored in the PDS before the E37, but PDSE can't handle it. PDSE can't support members as big as PDS. Are you #$%ing kidding me? PDSE's are a joke. They've been around for over 20 years, and they still don't have all the bugs out. This limitation is ridiculous, considering that PDSE's were supposed to address all the shortcomings of PDS. GUESS THEY MISSED THIS SHORTCOMING OF PDSE's!! WAY TO GO IBM!!! Sheesh, Tom Conley -- 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
