On Tue, Aug 18, 2009 at 1:24 PM, Llewellyn, Mark<[email protected]> wrote: > Dale, > > The MACLIB is maintained by a service machine which copies it to a large TEMP > disk, compresses it, then copies it back to the prod disk. > > The copy FROM the prod disk always seems to be ok. The copy of the > compressed MACLIB back to the prod disk seems to be where it can get hit. > Users can access this old app anytime they want - we can break the links, > which would cause them some grief, but a link could be established during > this process. > > A related question is whether an ISPF/PDF-based application can be placed in > a "read-only" mode. When this old app is retired, users are still going to > want to reference it for historical reasons. We don't want them to be able > to update it in any way at that point. > > If a read-only mode is possible, that could solve the compress issue as well.
Hm. So the SVM that copies it off could tell if it has been updated in the meantime by checking timestamps, no? Could it also force a dummy update? I'm wondering if the problem is that users A, B, and C have a view of the disk, and then the file gets updated "under" them, and since it's done outside of ISPF, the normal (if MW can be called "normal") ISPF "You need to reACCESS" notification doesn't happen. If instead: SVM copies off MACLIB, notes timestamp SVM compresses MACLIB SVM checks for changed timestamp If timestamp changed, go to step 1 Once it gets to THIS step, it causes an update It copies the MACLIB back (Or perhaps the last two steps should be reversed) Then the window of opportunity for mischief is only between the last two steps. And there could be more timestamp checking in there that would cause the whole thing to restart if needed (oy). At least we aren't designing something overly complex (!)
