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.
>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. >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. >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. >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) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
