Re: Time to move
On 4/11/07, David Kreuter [EMAIL PROTECTED] wrote: I understood that. I don't understand why existing code paths that have been around for *A WHILE* would be considered effort by developers, unless it was horribly broken. Shudder. Or no longer in the architecture, unlikely as that may be. Go and measure. Compare z/VM paging I/O with spool I/O and see that on the same disks and the same block size, paging does one to two orders of magnitude more. This actually is a problem, but for spooling and not for paging. As pointed out, most installations these days count paging space in volumes rather than cylinders. For those, using full volumes for paging is not a big deal. No doubt one could redesign z/VM and write all code from scratch. That might even address some of the known itches in z/VM. And it would introduce an entire new set of problems that we did not see before. But we can just call that restrictions and insist that the hardware changes or that people buy more from it. -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Time to move
Doing the DIRECTXA command changes between the pair of directories within the DRCT area. Would the second system notice the change via the Diag? I can see where doing a second DIRECTXA could cause serious problems. Are you saying that if you do it to some other random pack, that would be enough to cause the second system to re-read the real dierctory? Actually, with DirMaint and its dirmsat partner, keeping the two directories isn't really a problem, and I don't have to log into the other system to take care of the directory. Programmers are essentially lazy people, so I don't want to recreate work that I can have handed to me -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 3:36 PM, Rob van der Heij [EMAIL PROTECTED] wrote: On 4/10/07, RPN01 [EMAIL PROTECTED] wrote: Necessity is the Mother of all... He said, while cleaning his ears with the barrel of a gun :-) There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) Indeed. Have you considered to share you object directory as well? That might amuse many. You would run DIRECTXA on one system, and when that completed you make the other systems issue a Diag3C (iirc) to have them drop any cached portions of the object directory. If you want, you could make the slave system run another DIRECTXA to write an up-to-date on your spare RES volume. If you also want the update-in-place directory it may take a bit more tweaking... Rob
Re: Time to move
I'd say it would be dangreous to share the DRCT areas between 2 VM systems: A DIRECTXA on one system can update the 'inactive' DRCT cylinders any way it likes. Suppose two DIRECTXA commands are executed on one system before the second system had a chance to refresh it's DRCT knowledge. CP in the second system might be reading the some DRCT cylinders while the first system is updating those cylinders. Unpredictable things will happen, similar to CMS' famous error 3 reading file from disk when someone updates a minidisk that other users read. 2007/4/11, RPN01 [EMAIL PROTECTED]: Doing the DIRECTXA command changes between the pair of directories within the DRCT area. Would the second system notice the change via the Diag? I can see where doing a second DIRECTXA could cause serious problems. Are you saying that if you do it to some other random pack, that would be enough to cause the second system to re-read the real dierctory? Actually, with DirMaint and its dirmsat partner, keeping the two directories isn't really a problem, and I don't have to log into the other system to take care of the directory. Programmers are essentially lazy people, so I don't want to recreate work that I can have handed to me -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 3:36 PM, Rob van der Heij [EMAIL PROTECTED] wrote: On 4/10/07, RPN01 [EMAIL PROTECTED] wrote: Necessity is the Mother of all... He said, while cleaning his ears with the barrel of a gun :-) There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) Indeed. Have you considered to share you object directory as well? That might amuse many. You would run DIRECTXA on one system, and when that completed you make the other systems issue a Diag3C (iirc) to have them drop any cached portions of the object directory. If you want, you could make the slave system run another DIRECTXA to write an up-to-date on your spare RES volume. If you also want the update-in-place directory it may take a bit more tweaking... Rob -- Kris Buelens, IBM Belgium, VM customer support
Re: Time to move
I think it may refer to the effort of understanding what the system is doing. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 4:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move I understood that. I don't understand why existing code paths that have been around for *A WHILE* would be considered effort by developers, unless it was horribly broken. Shudder. Or no longer in the architecture, unlikely as that may be. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 6:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. --
Re: Time to move
Yes, OS/390 and VM do not do I/O the way a PC does. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Wednesday, April 11, 2007 12:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move I think it may refer to the effort of understanding what the system is doing. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 4:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move I understood that. I don't understand why existing code paths that have been around for *A WHILE* would be considered effort by developers, unless it was horribly broken. Shudder. Or no longer in the architecture, unlikely as that may be. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 6:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Time to move
On 4/11/07, RPN01 [EMAIL PROTECTED] wrote: Doing the DIRECTXA command changes between the pair of directories within the DRCT area. Would the second system notice the change via the Diag? I can see where doing a second DIRECTXA could cause serious problems. Are you saying that if you do it to some other random pack, that would be enough to cause the second system to re-read the real dierctory? Yes. When you run DIRECTXA on the system itself it completes writing the object directory by writing the pointer in cyl 0 and then issues Diag 3C to tell CP to forget the cached directory blocks and read the new one from disk. When we had problems with our ESM, it sometimes happened that the Diag 3C was not allowed by the ESM (the security policy required the 3C to be audited). So DIRECTXA had swapped the pointers but did not tell CP. Once RACF was up again, someone decided to run another DIRECTXA to fix things. At that point we started to overwrite the blocks that CP still believed to be valid - UDR001 is the one that Kris refers to. But in either case you need the master to verify that all slaves have completed their directory switch. Otherwise you end up allocate a new mini disk on the spot where directory t-2 still had something else. So if your directory is not shared but the disks are, you run the risk that someone can see the data of someone else. Not good either. Rob
Re: Time to move
And, while at the subject: when you share set up the CSE area's too, so CP will protect against accidental R/W LINKs from two systems at once. -- Kris Buelens, IBM Belgium, VM customer support 2007/4/11, Rob van der Heij [EMAIL PROTECTED]: On 4/11/07, RPN01 [EMAIL PROTECTED] wrote: Doing the DIRECTXA command changes between the pair of directories within the DRCT area. Would the second system notice the change via the Diag? I can see where doing a second DIRECTXA could cause serious problems. Are you saying that if you do it to some other random pack, that would be enough to cause the second system to re-read the real dierctory? Yes. When you run DIRECTXA on the system itself it completes writing the object directory by writing the pointer in cyl 0 and then issues Diag 3C to tell CP to forget the cached directory blocks and read the new one from disk. When we had problems with our ESM, it sometimes happened that the Diag 3C was not allowed by the ESM (the security policy required the 3C to be audited). So DIRECTXA had swapped the pointers but did not tell CP. Once RACF was up again, someone decided to run another DIRECTXA to fix things. At that point we started to overwrite the blocks that CP still believed to be valid - UDR001 is the one that Kris refers to. But in either case you need the master to verify that all slaves have completed their directory switch. Otherwise you end up allocate a new mini disk on the spot where directory t-2 still had something else. So if your directory is not shared but the disks are, you run the risk that someone can see the data of someone else. Not good either. Rob
Re: Time to move
On Wednesday, 04/11/2007 at 08:14 EST, RPN01 [EMAIL PROTECTED] wrote: Doing the DIRECTXA command changes between the pair of directories within the DRCT area. Would the second system notice the change via the Diag? I can see where doing a second DIRECTXA could cause serious problems. Are you saying that if you do it to some other random pack, that would be enough to cause the second system to re-read the real dierctory? There is no serialization in CP to protect the directory from damage by a second system. I would recommend that the fullpack minidisk that overlaps the directory cylinders be (a) protected by cross-system links (XLINK), and (2) protected by your ESM to prevent MW. At least that way you ensure only one user in the cluster has write access to the directory to perform DIRECTXA. Then you must guarantee another DIRECTXA is not started until the Diag 0x3C has been successfully issued on ALL of the other systems in the cluster. I don't want to envision the carnage if CP reads the directory index and by the time he locates what he wants, the active directory has been rewritten and the index he read is no longer valid. I'll just say Eeeew! and leave it at that. [In order to maintain the PG-13 rating of this forum, the MPAA will not allow a more graphic description.] If the communications link between the cluster members goes down, you can no longer update the shared object directory. Actually, with DirMaint and its dirmsat partner, keeping the two directories isn't really a problem, and I don't have to log into the other system to take care of the directory. Programmers are essentially lazy people, so I don't want to recreate work that I can have handed to me You can make a shared object directory work, but the penalty for failure could be severe. Given the existence of things like DirMaint's cluster directory management capabilities, I would ask Is the benefit worth the risk and the effort? Alan Altmark z/VM Development IBM Endicott
Re: Time to move
Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
In fact, your directory doesn't have to be on the sysres at all. Just make sure the volume it's on is in the CP_Owned list. Dennis O'Brien I wonder if other dogs think poodles are members of a weird religious cult. -- Rita Rudner -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bill Munson Sent: Tuesday, April 10, 2007 11:32 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
That sound like more trouble than necessary. You can put the DRCT anywhere on the volume. In fact it does not have to be on the IPL volume, just a CPOWNED volume. This does take care and consideration. You might want to do it on a 2nd level test system. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Richard Feldman (WFF) Sent: Tuesday, April 10, 2007 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Time to move Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I don't expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure I'll just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Time to move
Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
On Tuesday, 04/10/2007 at 01:51 EST, RPN01 [EMAIL PROTECTED] wrote: Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. WHAT?!? You have something else on your paging volumes? As you say, not ideal. Alan Altmark z/VM Development IBM Endicott
Re: Time to move
On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David From: The IBM z/VM Operating System on behalf of RPN01 Sent: Tue 4/10/2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
Hello Everyone, I have seen, read, and been told about having a separate page volume. It just seems like a true waste of space. Yes, I understand that disk is getting cheaper all the time, but budgets are kept here. I do have room, so the question is with all the VSE systems V=V but with enough real to cover them, and z/VM paging at 0 to 1 per sec, how much of an impact would it be to have paging on other volumes? q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- 430RES 0752257390 24120533563 2% 430W04 0715 1 2000 36 0 0 0% -- -- SUMMARY 384120533 1% USABLE384120533 1% And could you explain (again) the seldom ending channel program for paging? Thanks, Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David
Re: Time to move
It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David From: The IBM z/VM Operating System on behalf of Edward M. Martin Sent: Tue 4/10/2007 3:55 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Hello Everyone, I have seen, read, and been told about having a separate page volume. It just seems like a true waste of space. Yes, I understand that disk is getting cheaper all the time, but budgets are kept here. I do have room, so the question is with all the VSE systems V=V but with enough real to cover them, and z/VM paging at 0 to 1 per sec, how much of an impact would it be to have paging on other volumes? q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- 430RES 0752257390 24120533563 2% 430W04 0715 1 2000 36 0 0 0% -- -- SUMMARY 384120533 1% USABLE384120533 1% And could you explain (again) the seldom ending channel program for paging? Thanks, Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David
Re: Time to move
Necessity is the Mother of all... I wanted to share the RES pack between two systems, and I wanted to share the Spool volumes between the two systems. I needed a pack that would be unique to each system, and I didn't want a full mod 27 devoted to just the CP Directory. We don't have any CMS users to speak of, other than two administrators, and the Linux guests are *supposed* to stay up constantly, so the number of logins and links going on are at a bare minimum, so stashing the directory at the front of the paging volume seemed the least painful place to put it. At least, that's the logic I came up with for my choice. I suppose that, if it becomes a huge conflict at some point in the future, I can get my DASD people to carve me out two mod 3's for the directories (and listen to the abuse I'd have to take) and move the directory to these, separating them from the paging. There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 2:19 PM, David Kreuter [EMAIL PROTECTED] wrote: On the page volume with drct space you will defeat the seldom ending channel program for paging. Directory access uses the same type of channel program but will initiate its own io. And the directory disk pages will be accessed from time to time. Must they be on page volumes? David From: The IBM z/VM Operating System on behalf of RPN01 Sent: Tue 4/10/2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Actually, there's nothing that says the directory has to be on the res pack as well. You could move it to another CP Owned volume. While not ideal, ours live at the beginning of our page packs, and the two systems share the res pack. -- .~.Robert P. Nix Mayo Foundation /V\RO-OC-1-13200 First Street SW /( )\ 507-284-0844 Rochester, MN 55905 ^^-^^ - In theory, theory and practice are the same, but in practice, theory and practice are different. On 4/10/07 1:31 PM, Bill Munson [EMAIL PROTECTED] wrote: Richard, There is nothing that says your Directory has to start at the beginning of the RES pack. Leave the warmstart and checkpoint areas where they are and just move and enlarge the DRCT area someplace else on the res pack. good luck Bill Munson Office of Information Technology State of New Jersey (609) 984-4065 President MVMUA http://www.marist.edu/~mvmua Richard Feldman (WFF) wrote: Listers, Have a modest problem. My directory space is at 48%, gonna bust soon since there must be enough space for two copies of the directory. Even with all the dynamic commands in z/VM 5.2 I dont expect I could dynamically move my warmstart and checkpoint areas. To expand my dircectory I would have to move into those areas. Failing any dynamic commands I figure Ill just move those areas to a new location, sys config em, format the areas, and IPL cold (after spxtapeing everything). I could do a clean but would like to save time going for a cold. After the IPL I should be able to allocate a larger drct area starting at the same point, format it, and directxa. Sound reasonable?, Richard Feldman Senior IT Architect Kelly, Douglas / Westfair Foods Ltd. Ph:(403)291-6339 Fax:(403)291-6585
Re: Time to move
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
On 4/10/07, RPN01 [EMAIL PROTECTED] wrote: Necessity is the Mother of all... He said, while cleaning his ears with the barrel of a gun :-) There's always another way to do it. The simple fact that we run a CSE complex from a single RES volume seems to amaze and amuse the IBM'ers to no end, and if I can confound them, I know I've done something right... :-) Indeed. Have you considered to share you object directory as well? That might amuse many. You would run DIRECTXA on one system, and when that completed you make the other systems issue a Diag3C (iirc) to have them drop any cached portions of the object directory. If you want, you could make the slave system run another DIRECTXA to write an up-to-date on your spare RES volume. If you also want the update-in-place directory it may take a bit more tweaking... Rob
Re: Time to move
But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
-Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Tuesday, April 10, 2007 3:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh Why? You dare ask WHY?!? We, the great unwashed, have no need to know why. Yes, I get testy about IBM being so closed mouth. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 4:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it.
Re: Time to move
Bottom line is 'Do your users complain about poor performance?'. If not then just make a mental note and move on to more productive things. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 4:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move But why is it not worth the effort? Is it because, with full-pack paging devices, they were never using it? IIRC, at one time, perhaps still, MVS required that paging be isolated on its own devices. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Tuesday, April 10, 2007 1:34 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 3:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move It's IO. A SSCH (start channel) instruction is issued with the modify bit on. Then the program can issue a RSCH (resume subchannel) which continues the channel program with the initial i/o ending, allowing for an almost continuous data feed. You can throw new CCWs (channel commands) at it for read and write. While most shops no longer are concerned with physical device geometry, what with everything stored electronically, obviating true seeks, it is still expensive and unnecessary to end the channel program and fire it up again. That's why it is always recommended to keep paging cylinders isolated from all others. All CP io uses the seldom ending channel program (paging, spool, directory, warm, ckpt). Consider if you mix page and drct. Drct access will occur. If a page RSCH in in process it will end (only one i/o at a time san PAV!) so the drct i/o can start. Then a page is needed for paging; the drct RSCH is ended then the page SSCH/RSCH starts. Not good. David Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Time to move
And, by the way, the directory can sit on multiple, not contiguous DRCT areas, spread over one or multiple packs. We often ran like this when in urgent need for extra DRCT space. -- Kris Buelens, IBM Belgium, VM customer support
Re: Time to move
On 4/10/07, David Kreuter [EMAIL PROTECTED] wrote: What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. Right. Most installations with Linux these days find that the amount of page packs is given by the need to keep utilization under 50% rather than by having enough heads to achieve high paging rates. Back then some IBM internal systems used part of the volume for paging and the other part for backups (instead of using tape). This made sense because backups were done at night where the system was probably not paging a lot and certainly few users there to suffer from poor paging. Until you allow end-users to also restore data during office hours... -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Time to move
Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. --
Re: Time to move
I have systems with paging to 3390-3's. A lot of them. It wasn't hard just tedious. And a one time/seldom effort. -Original Message- From: The IBM z/VM Operating System on behalf of Rob van der Heij Sent: Tue 4/10/2007 5:08 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move On 4/10/07, David Kreuter [EMAIL PROTECTED] wrote: What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. Right. Most installations with Linux these days find that the amount of page packs is given by the need to keep utilization under 50% rather than by having enough heads to achieve high paging rates. Back then some IBM internal systems used part of the volume for paging and the other part for backups (instead of using tape). This made sense because backups were done at night where the system was probably not paging a lot and certainly few users there to suffer from poor paging. Until you allow end-users to also restore data during office hours... -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: Time to move
I understood that. I don't understand why existing code paths that have been around for *A WHILE* would be considered effort by developers, unless it was horribly broken. Shudder. Or no longer in the architecture, unlikely as that may be. David -Original Message- From: The IBM z/VM Operating System on behalf of Schuh, Richard Sent: Tue 4/10/2007 6:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Time to move Perhaps I should have snipped part of the message: Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Kreuter Sent: Tuesday, April 10, 2007 1:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Time to move What effort? It's been coded since vm/xa roamed the earth. Why change what works so well? For most shops page space isolation isn't all the difficult to achieve. David -Original Message- snip --- Curiously, the z/OS developers now say that SUSPEND / RESUME is not worth the effort and have removed it from their paging I/O. --
