Re: ISPF/PDF CMS MACLIB - Maintenance
We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources. Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of A. Harry Williams Sent: Tuesday, August 18, 2009 7:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: 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. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T compress the file COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. 3D= = 3D= ===
Re: ISPF/PDF CMS MACLIB - Maintenance
Any reason you can't change the LINK mode from MW to RR? As extra insurance delete the Write and Multi-write passwords from the MDISK. Less secure, but perhaps sufficient, would be changing the ACCESS command to access the disk as an extention of another disk, thus making it R/O. Even less elegant might be putting the MACLIB on a MDISK that is full so that it can't updated even though there is a write link to it. In any scenario you'd have to see what kind of error the appliation gets when it tries to update the MACLIB and your (and your users) tolerance fo r it. Brian Nielsen On Wed, 19 Aug 2009 11:28:46 -0700, Llewellyn, Mark mllew...@visa.com wrote: What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines.
Re: ISPF/PDF CMS MACLIB - Maintenance
On Wednesday, 08/19/2009 at 02:36 EDT, Llewellyn, Mark mllew...@visa.com wrote: We do have a home-grown utility that does this sort of thing for us, and it's how we normally update files on heavily-accessed resources. Unfortunately, the users would indeed have to re-access the disk...which, to them, will abort whatever they are doing (with unpredictable results) and, since they are mostly not VM-savvy, logging off and logging back on. Frankly, if all goes well, this old library system will be de-activated within a month, so this maintenance issue of the past 15 years is now of relatively low priority. What I'd REALLY like to know, as I've mentioned, is if read-only access to an ISPF/PDF MACLIB-based application and functionality (sans updates) can be achieved. Even though the old app is being supplanted, users will still wish to access pieces of it for historical reference. We simply want the MACLIB permanently frozen, but read-accessible via these local ISPF/PDF routines. Warning: I know nothing about ISPF/PDF's Theory of Operation. Just perusing the ISPF/PDF manual, perhaps a LOCK of each member in the library would let you keep other people out whilst you replace the maclib? Given that each user has R/W access to the disk, control must be via an advisory lock manager. Once you have all the marbles, replace them with new marbles. Alan Altmark z/VM Development IBM Endicott
Re: ISPF/PDF CMS MACLIB - Maintenance
Back to first principles: 1) Can you replicate the *failure* so you'll know whether you've fixed it or made it worse? 2) It's important to understand how the guests detect updates. If it's via a handshake, can you simulate that? I like Harry's almost-atomic update via COPY then RENAME. It wouldn't be hard to write a small assembler program to check the timestamp and issue the ERASE/RENAME if it matches, to minimize the window (though clearly 3 lines of Rexx is pretty fast these days). So the question then becomes whether this is sufficient, and for that you need #2 above.
Re: ISPF/PDF CMS MACLIB - Maintenance
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. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = == ===
Re: ISPF/PDF CMS MACLIB - Maintenance
On Tue, Aug 18, 2009 at 1:24 PM, Llewellyn, Markmllew...@visa.com 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 (!)
Re: ISPF/PDF CMS MACLIB - Maintenance
On Tue, 18 Aug 2009 10:24:59 -0700 Llewellyn, Mark said: 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. Not sure how the MW issues impact this, but how about on the copy back to the prod disk, you do a COPY to a different name, rename the uncompressed file, and then rename the compressed file to the correct name? Something like COPY PROD MACLIB P = = T compress the file COPY PROD MACLIB T = NEW P RENAME PROD MACLIB P = OLD P (NOUP RENAME PROD NEW P = MACLIB P all the users probably have to reaccess the disk, and that scares me. You'll need to test this idea. /ahw -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dale R. Smith Sent: Monday, August 17, 2009 2:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind= of VM service machine. If that's true, how about modifying the user code= to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue= a message to let the user know that it is temporarily unavailable, go int= o a sleep loop and keep checking until the maintenance ID no longer has the= MACLIB disk linked, then allow updates again, or terminate the user code = with a message, etc. That might do the trick and wouldn't require a lot = of work for a soon to be dead app, (we all know how dead things like to= stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. = - Kurt Vonnegut= = On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com = wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application = that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary,= I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this = maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being = updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a = better way of regulating the size of the maclib if possible. This is ou= r only ISPF/PDF application, and the folks who designed it are years gone = from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o= n the fly? If not, is there a safe way to ask ISPF to suspend all update = activity while the backup/compress is occurring, then resume when the = maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = == ===
Re: ISPF/PDF CMS MACLIB - Maintenance
Advice that Chuckie would be proud of :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Stephen Frazier Sent: Friday, August 14, 2009 5:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Schuh, Richard wrote: The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months.. Don't worry about it breaking. If the old one dies then that is a great incentive for the developers to get the new one working quickly. :) I didn't say that. Who me. Never. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: ISPF/PDF CMS MACLIB - Maintenance
A straw at which I cannot grasp. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 6:40 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 7:20 PM, Schuh, Richardrsc...@visa.com wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Ah, true. Urgh. Got FlashCopy? Yes, I'm grasping at straw...
Re: ISPF/PDF CMS MACLIB - Maintenance
Unfortunately, that is not possible. This is a legacy application that is enterprise wide and the users have no knowledge that they are using it. It cannot be decommissioned until its replacement is fully operational sometime next month (assuming there are no delays). Management is fully aware of the problems with it and, like the people responsible for keeping it alive until then, hopes like hell that nothing major happens to either the application or its replacement in the interim. Fortunately, the main problems with the app can usually be fixed by restoring a backup and telling the users to redo what they have don since the restore point. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Friday, August 14, 2009 8:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Ok, then they've already Bet The Business, so it's not your problem. Les Schuh, Richard wrote: Unfortunately, that is not possible. This is a legacy application that is enterprise wide and the users have no knowledge that they are using it. It cannot be decommissioned until its replacement is fully operational sometime next month (assuming there are no delays). Management is fully aware of the problems with it and, like the people responsible for keeping it alive until then, hopes like hell that nothing major happens to either the application or its replacement in the interim. Fortunately, the main problems with the app can usually be fixed by restoring a backup and telling the users to redo what they have don since the restore point. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Friday, August 14, 2009 8:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Mark/Richard: I'm guessing that the nightly compress of the MACLIB is done by some kind of VM service machine. If that's true, how about modifying the user code to use the QUERY LINKS command to determive if the maintenance ID is linked to the MACLIB disk and if it is, don't allow updates. Maybe issue a message to let the user know that it is temporarily unavailable, go int o a sleep loop and keep checking until the maintenance ID no longer has the MACLIB disk linked, then allow updates again, or terminate the user code with a message, etc. That might do the trick and wouldn't require a lot of work for a soon to be dead app, (we all know how dead things like to stick around, like mainframes, VM, COBOL, etc. :-) ). -- Dale R. Smith Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance. - Kurt Vonnegut On Fri, 14 Aug 2009 12:32:49 -0500, Mark Llewellyn mllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is ou r only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib o n the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc. = ===
ISPF/PDF CMS MACLIB - Maintenance
Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application tha t makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activit y and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Thanks! Mark Llewellyn, Visa Inc.
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellynmllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Could the machine doing the compress LINK the disk eXclusive during the update?
Re: ISPF/PDF CMS MACLIB - Maintenance
Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 10:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 1:32 PM, Mark Llewellynmllew...@visa.com wrote: Any veteran ISPF/PDF SMEs out there? We have an ancient and soon-to-be decommissioned ISPF/PDF application that makes use of an enormous MACLIB on a shared mult-write minidisk. Scary, I know, but that's the way ISPF works on CMS. This maclib can grow by millions of records per day, due to heavy activity and inefficient old code. Each night a maintenance routine copies this maclib to a temp disk, compresses it, and copies it back to its home disk. There is an obvious vulnerability here - if the maclib is being updated when being copied back to its usual home, it can corrupt the file. Although this system is going the way of the dinosaur soon, we need a better way of regulating the size of the maclib if possible. This is our only ISPF/PDF application, and the folks who designed it are years gone from the company. Is there ANY way to persuade ISPF to squeeze the air out of the maclib on the fly? If not, is there a safe way to ask ISPF to suspend all update activity while the backup/compress is occurring, then resume when the maclib has been safely returned? Could the machine doing the compress LINK the disk eXclusive during the update?
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
Access control is an ISPF function, I presume that one of the two locks (LMF or SCLM) is used to prevent concurrent updates of the same member. It must also have some way to serialize the updates of the library. That is an area that I have avoided. I hate working with kludges or black boxes. The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. ---Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 2:52 PM, Schuh, Richardrsc...@visa.com wrote: Unfortunately, that will not fly with the application. There are always several users who have the disk MW. It is a heavily used application and users keep it linked active for long periods. The main users of it live in the application. How is simultaneous use of a library controlled? If I edit member A, does that lock it? If so, could the update process edit every member, do the update, then quit every member?
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
Re: ISPF/PDF CMS MACLIB - Maintenance
Schuh, Richard wrote: The developers of the application chose to have the data maintained in a single, ever-increasing, highly used, frequently updated ISPF library, with no maintenance routines, and no good way to identify obsolete members. The application was already firmly entrenched when Mark and I arrived at Visa. There have been at least three unsuccessful attempts to replace in during my tenure here. The current attempt is nearing completion. With luck, we only have to keep the application running for a few more months.. Don't worry about it breaking. If the old one dies then that is a great incentive for the developers to get the new one working quickly. :) I didn't say that. Who me. Never. -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: ISPF/PDF CMS MACLIB - Maintenance
On Fri, Aug 14, 2009 at 7:20 PM, Schuh, Richardrsc...@visa.com wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Ah, true. Urgh. Got FlashCopy? Yes, I'm grasping at straw...
Re: ISPF/PDF CMS MACLIB - Maintenance
Explain the problem to management and let them decide if they want to Bet The Business on the current exposure. If not, let them announce to everyone when ISPF will be unavailable and FORCE all the users and take the ISPF disk away by whatever means are available (I'm retired and was not a SysProg, just a developer!) Les Schuh, Richard wrote: Considering that it is ISPF, I would be worried that taking down the SVM would simply kill all of the protective mechanisms that ISPF employs to keep the users from trashing the file because of the MW links. In the absence of knowledge about its purpose, I would not suggest blindly taking it down. I really do not like to play the game of My gun. My bullet. My body part. I might be able to get along ok if I only hit a little toe, but with my hands, parts higher up, such as a knee (bet you thought I was referring to something else), would also be vulnerable. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of P S Sent: Friday, August 14, 2009 3:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: ISPF/PDF CMS MACLIB - Maintenance On Fri, Aug 14, 2009 at 4:52 PM, Llewellyn, Markmllew...@visa.com wrote: The MACLIB is updated via PDF dialog table services, driven by a number of older REXX EXECs. It contains hundreds of members, which can be updated at any time, and new members are added every day. I'm unsure if ISPF/PDF locks a member, or a table row, each time it's updated. Nevertheless, in order to compress the maclib we'd like to completely halt any possible update activity. Some sort of global ISPF command that I haven't found yet, perhaps. The application runs ISPF in the users' individual virtual machines. ISPF does have a service machine, which runs mysterious ISPF Services. Take down the ISPF machine?
