Re: Velocity Software Performance Update (V4.1) - Jersey City
Hello! Apologies in advance, Len, if this is the wrong place to do this, but I remember registering for that event. I even have the printed out confirmation thing for the event. But I've not gotten a confirmation note from the service machine where all of you are for the event. According to the website those were supposed to be sent at least ten days in advance. And Dan, the same to you as well for bringing this up on list. Ideally it should not be. --- Gregg C Levine hansolofal...@att.net "This signature is not the same one. Move along! Move along!" > -Original Message- > From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] > On Behalf Of Len Diegel > Sent: Friday, January 21, 2011 1:00 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: [IBMVM] Velocity Software Performance Update (V4.1) - Jersey City > > > Velocity Software will be conducting a seminar in Jersey City, on March 17th, for > Version 4 of zVPS (formerly ESALPS). Topics and registration information can be > found on the link below. Velocity Software customers should find this seminar > useful. > > http://velocitysoftware.com/seminar/v4update.html > > Regards, > Len > > >
Re: Tape drives : MVS & VM
On Mon, 14 Mar 2011 13:29:59 -0400 (EDT), Alain Benveniste wrote: > > We did a P.O.R this weekend. We added DASD rdev, the only thing we > are supposed to do and now we can vary online a same rdev to both > MVS & VM. We check back the modifications. The chpid are shared, > the rdev are shareable=NO in the MVS IODEF. We don't know where > to look at. We changed something... but what! We have one z800 > with 2 lcss. z/OS1.10 & z/VM 530. > > Any idea It depends. The old reel-to-reel tape drives (3420 and earlier) don't support an ASSIGN command; so there's nothing that prevents them being on-line to two systems at once. (Unless you have some third party software, such as CA MIM.) But the 3480 and newer drives do support an ASSIGN command, and that has historically prevented the drives from being online to two MVS systems at once. In the case of VM, though, by default, the ASSIGN is not done when the VARY ONLINE command is issued, but when an ATTACH command is issued. We didn't like that. Operationally, we don't want the same drive online to two systems at once. What we did was to create a VARY EXEC to front-end the VARY command, since VARY is normally issued manually by an operator. The exec examines the command and, if it detects an attempt to vary on a tape drive(s), adds the ASSIGN option unless NOASSIGN is explicitly specified. With the advent of the MVS SYSPLEX environment, the rules for sharing tape drives between systems in a SYSPLEX get more complicated. I remember there was something extra we had to do, but I don't remember what it was. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Making sure vmsys: is up...
Bob, we use the following PIPE technique: Pipe Literal +30 | Delay | Pipestop The 30 is seconds. VMSERVS comes up pretty quick, but I can still understand a need to momentarily pause. Steve From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of RPN01 Sent: Monday, March 14, 2011 4:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Making sure vmsys: is up... Is there a good or widely accepted way to wait in autolog1 until the vmsys: pool is up and available? -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different."
Re: Making sure vmsys: is up...
On Monday, 03/14/2011 at 03:34 EDT, RPN01 wrote: > Is there a good or widely accepted way to wait in autolog1 until the vmsys: > pool is up and available? In decreasing order of preference: 1. Loop on "ACCESS VMSYS:AUTOLOG1. B" with an appropriate delay. (Enroll AUTOLOG1, of course.) 2. o Use SCIF to watch for the "ready for communications" message. 3. Loop on "QUERY RESOURCE VMSYS" with an appropriate delay. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Making sure vmsys: is up...
A non-zero return code from "QUERY FILEPOOL STATUS filepool" indicates the target filepool is off-air. Brace for a flood of response messages if the filepool *is* on-air. On 3/14/2011 3:34 PM, RPN01 wrote: Is there a good or widely accepted way to wait in autolog1 until the vmsys: pool is up and available? -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different."
Making sure vmsys: is up...
Is there a good or widely accepted way to wait in autolog1 until the vmsys: pool is up and available? -- Robert P. Nix Mayo Foundation.~. RO-OC-1-18 200 First Street SW/V\ 507-284-0844 Rochester, MN 55905 /( )\ -^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different."
Re: Tape drives : MVS & VM
Basically all you did was tell the OSs that the devices were not being shared. If you did not specifically limit the access to a particular LPAR then all the LPARs can see because the CHPID is shared. On Mon, Mar 14, 2011 at 1:29 PM, Alain Benveniste wrote: > Hi, > > We did a P.O.R this weekend. We added DASD rdev, the only thing we are > supposed to do and now we can vary online a same rdev to both MVS & VM. We > check back the modifications. The chpid are shared, the rdev are > shareable=NO in the MVS IODEF. We don't know where to look at. We changed > something... but what ! We have one z800 with 2 lcss. z/OS1.10 & z/VM530. > > Any idea > Alain Benveniste > -- Mark D Pace Senior Systems Engineer Mainline Information Systems
Tape drives : MVS & VM
Hi, We did a P.O.R this weekend. We added DASD rdev, the only thing we are supposed to do and now we can vary online a same rdev to both MVS & V M. We check back the modifications. The chpid are shared, the rdev are shareable=NO in the MVS IODEF. We don't know where to look at. We chang ed something... but what ! We have one z800 with 2 lcss. z/OS1.10 & z/VM 530. Any idea Alain Benveniste
Re: Change OSA cards
Not that it matters, In my situation, this is what worked. Update MPROUTE CONFIG Update sysname TCPIP Update directory entry for TCPIP set vswitch vswitch1 disconnect set vswitch vswitch1 rdev 2f00 set vswitch vswitch1 connect force tcpip autolog tcpip set vswitch vswitch2 disconnect set vswitch vswitch2 rdev 2700 set vswitch vswitch2 connect For our configuration, I also had to do a set vswitch vswitch1 discon set vswitch vswitch1 prirouter set vswitch vswitch1 connect set vswitch vswitch2 discon set vswitch vswitch2 prirouter set vswitch vswitch2 connect Assuming everything works cprel a vmlink maint cf1 Update SYSTEM CONFIG to reflect new rdev's and prirouter vmlink maint 193 cpsyntax system config rel z (det rel x (det cpacc maint cf1 a My backout plan consisted of From another VM system def mdisk 1198 8785 9 resvol <== tcpmaint's 198 disk acc 1198 e update mproute config with old names update sysname tcpip with old addresses rel e (det I had previously updated vmsecure config to authorize operator to manage TCPIP. I would use that to update the directory entry for tcpip. Then set vswitch vswitch1 discon set vswitch vswitch1 rdev 1e08 set vswitch vswitch1 connect force tcpip autolog tcpip set vswitch vswitch2 discon set vswitch vswitch2 rdev 1f08 set vswitch vswitch2 connect I didn't have to exercise the backoff plan, but there were connection issues for the Linux systems. Those were resolved by making the vswitche s prirouter (they were not defined that way previously).
Re: "Three Films Chronicle IBM's Century of Innovation"
> "Three Films Chronicle IBM's Century of Innovation" > ARMONK, N.Y. - 10 Mar 2011: IBM is marking its 100th year as a > company of innovators and inventions through a series of > documentary films that chronicle the ways in which the company > has changed the world through scientific and technology > achievements and the "IBMers" who have been behind those > breakthroughs. > http://www-03.ibm.com/press/us/en/pressrelease/34001.wss Gabe: All these videos are available on Youtube at IBM's page at http://www.youtube.com/user/ibm (click on "Centennial" beside Trending. Jim
Gavin Appleton is out of the office.
I will be out of the office starting 14/03/2011 and will not return until 21/03/2011. On Paternity leave ! If urgent please contact TST MF front shop on 52580.
Re: SFS question
Ivica and others. Thank you for the help. Increasing the size of the control disk fixed the problem. Steve From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] On Behalf Of Ivica Brodaric Sent: Saturday, March 12, 2011 8:12 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SFS question Stephen, Do I understand the formula and definitions correctly? You do, but that's just to get you started. It really all depends on how many objects are going to be created in that file pool. So, take that formula as an attempt to predict the future. MAXUSERS determines the logical size of the catalog and that formula is MAXUSERS * 85 (and that's a real formula). Half of that goes to data blocks and half to index blocks. The physical size of the catalog (number of blocks in group 1) can initially be much smaller than that. That smaller space would again be divided equally to data and index blocks. It is much easier to add another minidisk to group 1 (when you hit physical limit) than to do regenerate file pool (when you hit logical limit). Therefore, allocate MAXUSERS generously, so that you don't have to do this again soon. In your case, you have 640 cylinders in group 1 (16 * 40 cyl), which equates to 115200 blocks. You may have over-allocated group 1, but to decrease that now would be a pain, so leave it. To be able to use all that space, the logical size of the catalog has to be at least that much, so MAXUSERS must be at least 1356, which is 115200 / 85, rounded up. I would suggest that you use at least 5000 if not 1 for MAXUSERS. Over-allocating MAXUSERS is not harmful, it just takes a bit of space in control minidisk. Size of control minidisk (or of the rest of it) determines the number of potentially addressable blocks in the file pool (maximum size to which the file pool can grow to). You can see that number if you do QUERY FILEPOOL OVERVIEW, but roughly, it is a bit less than one million addressable blocks for each control disk cylinder. There is no formula for this, because other things go to control disk as well (MAXDISKS has a hand in it too), but for example (roughly again), with a 50-cylinder control disk you will be left with at least 45 million potentially addressable blocks, which equates to around 75 3390 mod3's. That's the maximum size of disk space that you will ever be able to have in the file pool before having to regenerate it. While regenerating file pool, you will have to increase the size of the control disk. You have to do this to allow for the increase of MAXUSERS in order to maintain at least the same number of potentially addressable blocks. Increase it by 25-33% to be sure, but do *not* over-allocate control disk. Whenever the file pool server performs control data backup (and it does it automatically when log disks fill up more than 80%), the file pool will be unavailable to end users for the duration of the backup. You want that backup to be quick especially if your log disks are small and the backup is run often. Control data backup backs up *entire* control disk and *used* blocks in group 1 (catalog). Therefore, over-allocating group 1 is OK, but over-allocating control disk is not. Follow the procedure to regenerate a repository file pool to which you have been pointed to already and you'll be fine. One final word of advice though: before doing anything like this, make sure that you also have a reliable backup of the whole file pool (storage groups 2 and above) handy. Ivica Brodaric BNZ
