On Mon, Apr 7, 2014 at 10:14 AM, Paul Gilmartin <paulgboul...@aim.com>wrote:
> On Mon, 7 Apr 2014 09:53:03 -0500, John McKown wrote: > > > >Hum, I don't see the need to downgrade. From what I understand, when a > user > >does an ISPF editor SAVE command, ISPF does: > > > >ENQ SPFEDIT dsn OLD > >write out to PDS > >STOW to update the PDS directory > >DEQ SPFEDIT dsn > > > >That is, ISPF does not have a SHR enqueue on the DSN alone except while > >doing a SAVE. > > > 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) > > 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 just do an ALLOCATE to a DD name and use the QSAM interface to read or write the data. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
