> On Nov 20, 2017, at 8:11 PM, Paul Gilmartin > <[email protected]> wrote: > > On Mon, 20 Nov 2017 19:05:17 -0600, Edward Gould wrote: > >>> On Nov 20, 2017, at 2:55 PM, Paul Gilmartin wrote: >>> >>> If it were a PDS I'd recommend IEBCOPY and AMATERSE. >> >> It is a psuedo standard [the operant adjective is "pseudo" -- gil] for >> *AGES* too use iebupdte (or what ever the VM equivalence is). I have not >> been heavily into VM but I believe since day 1 vm source updates have been >> iebupdte type format for OS (PCP-MFT-MVT) >> > An archaic and onerous restriction (I won't deign to call this a "standard") > can often > be relieved by an enhancement. I have a simple implementation in mind, but > IBM > prefers that RFEs avoid suggesting implementations and mention only > requirements.
This is in the realm I believe of a SHARE req (or what ever its called when it would crosses product lines such as MVS and VM). I am sure they might listen but you would have to get the two products to agree, but good luck I don’t think its going to happen any time soon. > >> Its a portable way of doing things IEBCOPY for source is used (I believe) >> only for clists and maybe some netview and misc others. JES2 & 3 both use it >> for distributed source members. There are other examples. >> To put it bluntly you are arguing a standard that won’t go away any time >> soon, unless a replacement is found. >> BTW IBM blew it day 1 for lists as clist put sequence numbers in 1-8 rather >> than 72. It took a number of share/guides to get IBM to figure out that >> iebupdte won’t work with clists. IBM quietly just went to iebcopy for clists >> and then on top of that CLISTS are VB in length which is NOT iebupdte >> friendly. >> > I suspect 1-8 was an intended accommodation to VB. And in another apparent > accommodation, ISPF Edit until recently would not create an 8-character record > but always padded it with an additional blank. I don’t think so as SPF wasn’t around when MVS first came out. I “think” it was 5 or so years afterwards, so that wasn’t the reason. > >> We were probably in the top 100 nationwide to do MVS in production. We saw >> the issue day 2. We sat back and watched IBM argue amongst themselves how >> they were going to handle CLIST. The first time we fired up SMP we could see >> the issue as IBM wrestled with what to use to update. I *think* netview used >> 80 for it's “clist”. >> > In days of yore panel definitions for SPF (now known as ISPF) were VB. > Abruptly > they changed to FB. Disruptively -- it broke all my customized panels. > Cognoscenti > surmised this was an accommodation to SMP(/E) and IEBUPDTE. I will admit that I am leary of that explanation, but when spf came out we laughed at it and called it a resource hog and went in another direction, Instead of panels and etc we stuck with edit and a competitor of SPF FSE. I do not remember the panels of SPF being VB but I will defer to you and others . > >> Way back then when I was a junior sysprog going to Guide wasn’t possible >> until it came to Chicago. The senior sysprog at the time was on one of the >> committees (don’t ask its been a LONG time ago) and he would tell us about >> the arguments that arose about clists and it got to be fun according to him >> seeing IBM trying to argue the point. I know our IBM SE was almost swept up >> in it (IBM internals). He politely refused to get involved. If people don’t >> remember at one time the CDS was in PDS format (IBM sort of broke the rules >> on that one) when SMPE came out and converted the pds to a Vsam dataset all >> was good again. Firing up SMP was a big resource hog as it read (IIRC) the >> CDS directory into memory. The SMP zone was a PDS as well but it was >> manageable, Its been years so my memory might be faulty here, the CDS (at >> least at our installation was created with 20,000 members (or more). >> > I thought that nowadays SMP/E keeps everything in VSAM except its libraries. > At least I've never coded DDDEFs (that's what I use instead of JCL DD) for any > nonVSAM zone files. It does. I was talking about pre SMPE. > >> The first indications that IBM needed to “fix” pds’s was because of SMP and >> somewhere along the line IBM decided to replace PDS’s with PDSe’s, I don’t >> remember what caused the decision, but (again here my memory is iffy) is >> that SMP CDS’s were bumping the limits of PO type datasets. >> > PDSEs have DSORG=PO. (But I believe that's a benign fiction with the goal of > compatibility) I was clearly talking about CDS’s being a huge animal (Pre VSAM and pre PDSE) and like I said (I don’t clearly remember) what caused IBM to redo the thought process of changing to VSAM, other than possible limits on the number of directory blocks. My memory is cloudy here but the actual content of each member was small 1 record (But I could be wrong). The trick IBM used was to use upper/lower case member names but it was definitely a PDS, as we were copying it from volume to volume as we always seemed to be running out of space. Its been so long that I don’t remember what happened to the CDS when it ran out of space. Again my memory is cloudy as to sizing, but it seemed to only grow bigger with every release of MVS. Ed > > -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
