On Wed, 26 Apr 2017 22:29:51 -0400, Tony Harminc wrote: >> >> I would think people would be smart enough to say "well it worked with >> PDSE's, it will probably work with the new PDSX's" just as how when I read >> "specify the name of an HFS file" I know that a zFS file will probably work >> as well (assuming the context is individual UNIX files, not the VSAM LDS's >> that underlie xFS). I suspect most z/OS sysprogs would understand "zFS >> file" more clearly than "UNIX file." >> "PDS*"? DSORG=PO? PDSEs have DSORG=PO for compatibility; the physical organization is radically different from that of PDS. I think. IBM doesn't tell me.
BPAM input works on allocated UNIX directories, but OPEN sets DSORG to unknown in the DCB, breaking utilities that verify DSORG. >Yeah, there are lots of pitfalls of over and under specifying. If we say >PDS, does it mean you can't use a PDSE (or a PDSX)? Not likely. But if we >said PDSE, it's much more likely we really mean it, e.g. if we plan to put >Program Objects in there. > >Here's a somewhat out of context snippet of some of our install doc ... > >========= >b) Create a RECFM=FB,LRECL=80 PDS or PDSE for the installation JCL, with >a name appropriate to your environment. >This PDS requires minimal space. Specifying primary tracks of 5 and >secondary tracks of 1 with 5 directory blocks is sufficient. > I'd specify bytes, anticipating the 33x0. >c) Copy the UNIX files in the INSTJCL subdirectory to corresponding >members in the PDS using the OGETX TSO command, ISPF COPY, or other >standard method. Be sure to copy in TEXT mode, which is the default on >OGETX. > >This sample TSO command could be used to copy the files: >ogetx /usr/lpp/slb/RSLB520/INSTJCL 'ESS.V520.INSTJCL' > Very user friendly. I commend you. If customers try other methods (standard or otherwise?) and they work, good for them. If they don't work, you told them so. >Note: If you are comfortable working directly with JCL in UNIX files, there >is no need to copy them into a PDS. > ISPF is quite good at dealing with those nowadays. >The idea is to provide what's needed with general terminology that won't >age badly, with enough specificity to get the job done, but without >overspecifying the details that an installation does in its own way. No one >has complained, but maybe it's annoying, but not quite enough to bother >about. I don't know. > Given the pervasive inclination of customers to complain, I'm surprised how little complaint I've received about installation packages I've crafted. The most intense complaint I recall was from a customer who wanted an ensemble of TSO TRANSMIT unloaded libraries instead of the SMP/E RECEIVE FROMNTS package we supplied. It was in the early days of SMP/E v3, but I thought I was following IBM's direction. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
