On Mon, 7 Apr 2014 10:54:55 -0500, John McKown wrote: > >> Soon, it may be time for a(nother) rant about the difficulty of LMCOPY >> from a UNIX file to a PDS member. The best I can do is first copy it >> to a temp DS (or SYSCALL readfile, then LMPUT in a loop). > >IBM should enhance the UNIX cp command to do the ISPF enqueues. Or, at the >very least, have an option to have it do them. > I assume the nexus is the C RTL.
On Mon, 7 Apr 2014 10:39:52 -0500, John McKown wrote: > >> This provides little or no protection against batch jobs' updating the PDS >> and interleaving member data. Be careful. JWG's comments about PDSE >> noted. > >Very true. In general, from the olden daze, if you wanted to update a PDS, >you were expected to do a DISP=OLD on the DSN in your JCL. They did not >design the original PDS or OPEN to do this type of integrity. Likely, at >the time, it would have been too expensive (in CPU / code size / money) > Do I understand, correctly, that nowadays DFSMS preserves integrity of PDS directories against concurrent STOWs? >> I use LM services for background updates of PDS. (And once was caught >> by a MIM failure.) >> >> Soon, it may be time for a(nother) rant about the difficulty of LMCOPY >> from a UNIX file to a PDS member. The best I can do is first copy it >> to a temp DS (or SYSCALL readfile, then LMPUT in a loop). > >Seems to me that extending LMINIT to a UNIX file should not be too >difficult. To do it properly would require new UNIX code. But I don't know >why ISPF could [not? -- gil] just do an ALLOCATE to a DD name and use >the QSAM interface to read or write the data. > At present, LMINIT of the DDNAME of an allocated UNIX file fails with some sort of complaint about the F1 DSCB. Or perhaps I saw this as a documented restriction. It's all *so* 20th Century! -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
