Re: Devices OFFLINE at IPL
I have a production site and a DR site, the production site is being mirrored to the DR site same volume labels but different address. In my system config file I am using the Systems_Identifier with the CPU type, CPUID and the SystemID, this tell me if I am on the production system or the DR system, is there a way to add logic to the system config file to control which DASD I want online and which I vary offline at IPL time, without customizing the IOCP.. Date: Wed, 14 Jul 2010 10:26:02 -0500 From: r...@velocitysoftware.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
Re: Devices OFFLINE at IPL
We have been using class V for years to allow the TPF guests to be able to find an available Security Module and ATTACH it to themselves. They do not get DETACH because then they could wreak havoc by detaching from other guests and from SYSTEM. Class V also gets the ability to use class B QUERY commands. Nobody outside the VM Systems group and the operators has either class B or C. The normal is class G for those who are not set up for TPF testing; GV for those who are. The only MVS types who even have ids on the system are those who must deal with the hardware configuration. Giving them anything but GV would make me nervous as they may log on once or twice in a year. Their VM skills are not finely honed. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, July 14, 2010 2:01 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL On Wednesday, 07/14/2010 at 02:03 EDT, Gregg reed.gr...@gmail.com wrote: So if it can't be controlled at the LParr, then priv class C(B too?) needs to be locked down to the few MVS security folk trust. - Never give privilege class C to anyone who is not a trained AND trusted z/VM systems programmer. - Never give privilege class B to anyone just so they can issue the ATTACH and VARY commands. Instead, define them as privclass BQ and give your trusted MVS people privclass GQ. (e.g. MODIFY COMMAND ATTACH PRIVCLASS BQ) Alan Altmark z/VM Development IBM Endicott
Re: Devices OFFLINE at IPL
Yes! Use the Record Qualifiers capability of the SYSTEM CONFIG file. For example: System_ID 2094 %%1234 PRODVM/* Production system at home */ System_ID 2094 %%5678 RECOVERY /* Planned-for D.R. system */ System_ID 2097 %%9876 DISASTER /* Even worse! */ PRODVM: , Devices , ONline_at_IPL -0FFF , Sensed -0FFF RECOVERY: , Devices , ONline_at_IPL 1000-1FFF , Sensed 1000-1FFF DISASTER: , Devices , ONline_at_IPL - , /* Something very wrong, get 'em all */ Sensed - You can include multiple record qualifiers for each SYSTEM CONFIG statement, too! E.g. PRODVM: RECOVERY: , Operator_Consoles , 0700 , /* location here */ , 0701 , /* location here */ , 0009 , /* 2nd level test sys */ , SYSTEM_3270, /* HMC Integrated 3270 (SYSG)*/ , SYSTEM_CONSOLE/* HMC Linemode console (SYSC)*/ Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. clifford jackson cliffordjackson...@msn.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/15/2010 10:24 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Devices OFFLINE at IPL I have a production site and a DR site, the production site is being mirrored to the DR site same volume labels but different address. In my system config file I am using the Systems_Identifier with the CPU type, CPUID and the SystemID, this tell me if I am on the production system or the DR system, is there a way to add logic to the system config file to control which DASD I want online and which I vary offline at IPL time, without customizing the IOCP.. Date: Wed, 14 Jul 2010 10:26:02 -0500 From: r...@velocitysoftware.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: Devices OFFLINE at IPL
Just a hint to avoid some grief (or a change request!) if someone upgrades your box... You can put the %% in the machine type to i.e. System_ID 20%% %%1234 PRODVM Course the next box may not be a 20something so perhaps is better :) Marcy -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Thursday, July 15, 2010 8:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Devices OFFLINE at IPL Yes! Use the Record Qualifiers capability of the SYSTEM CONFIG file. For example: System_ID 2094 %%1234 PRODVM/* Production system at home */ System_ID 2094 %%5678 RECOVERY /* Planned-for D.R. system */ System_ID 2097 %%9876 DISASTER /* Even worse! */ PRODVM: , Devices , ONline_at_IPL -0FFF , Sensed -0FFF RECOVERY: , Devices , ONline_at_IPL 1000-1FFF , Sensed 1000-1FFF DISASTER: , Devices , ONline_at_IPL - , /* Something very wrong, get 'em all */ Sensed - You can include multiple record qualifiers for each SYSTEM CONFIG statement, too! E.g. PRODVM: RECOVERY: , Operator_Consoles , 0700 , /* location here */ , 0701 , /* location here */ , 0009 , /* 2nd level test sys */ , SYSTEM_3270, /* HMC Integrated 3270 (SYSG)*/ , SYSTEM_CONSOLE/* HMC Linemode console (SYSC)*/ Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. clifford jackson cliffordjackson...@msn.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/15/2010 10:24 AM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Devices OFFLINE at IPL
Re: Devices OFFLINE at IPL
Presumably, if you are at the DR site, your main site is unavailable. That may be all you really need. One possibility, procedural instead of program logic, would be to use the SALIPL screen to specify a different CONFIG file when you are at the DR site. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of clifford jackson Sent: Thursday, July 15, 2010 8:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL I have a production site and a DR site, the production site is being mirrored to the DR site same volume labels but different address. In my system config file I am using the Systems_Identifier with the CPU type, CPUID and the SystemID, this tell me if I am on the production system or the DR system, is there a way to add logic to the system config file to control which DASD I want online and which I vary offline at IPL time, without customizing the IOCP.. Date: Wed, 14 Jul 2010 10:26:02 -0500 From: r...@velocitysoftware.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy.http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
Re: Devices OFFLINE at IPL
Another possibility is to use the loadparm with a system config file name in it which is useful if you have PPRC'd dasd and have switched the primaries and secondaries and perhaps they aren't back in sync yet and duplicate volumes would cause issues. LOADPARM of FNSITE1 will use a system config file name of SITE1 CONFIG. Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, July 15, 2010 9:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Devices OFFLINE at IPL Presumably, if you are at the DR site, your main site is unavailable. That may be all you really need. One possibility, procedural instead of program logic, would be to use the SALIPL screen to specify a different CONFIG file when you are at the DR site. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of clifford jackson Sent: Thursday, July 15, 2010 8:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL I have a production site and a DR site, the production site is being mirrored to the DR site same volume labels but different address. In my system config file I am using the Systems_Identifier with the CPU type, CPUID and the SystemID, this tell me if I am on the production system or the DR system, is there a way to add logic to the system config file to control which DASD I want online and which I vary offline at IPL time, without customizing the IOCP.. Date: Wed, 14 Jul 2010 10:26:02 -0500 From: r...@velocitysoftware.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
Re: Devices OFFLINE at IPL
The drawback to Mike's approach is that your system name changes at your DR site. True... but I *like* and *use* the different System_Identifier names! That would cause more problems than it would solve for us. Perhaps, but when it is planned for it can be a huge benefit... (aside from users knowing that they are running on a D.R. system, and perhaps not expecting any changes to remain after the test is completed). The System_Identifier from SYSTEM CONFIG is easily returned from rexx code: parse value diag(08,'QUERY USERID') with self . ConfigSysID . '15'x . Note: The CMS command IDENTIFY returns the nodename from SYSTEM NETID S2, not necessarily the same. This permits service machines to take different code paths when running on (e.g.) VMPROD vs 'RECOVERY or VMTEST (2nd level). Perhaps during D.R. certain service machines will use different hardware addresses, not start some applications, or start other ones. Examples include VTAM, and TCPIP. When those servers come up here, they read NODAL CONFIG Y2, and respond accordingly when matching the System Config System_Identifier (node names have been changed below to be more obvious): ---snip--- * This file is read by various REXX and GCS programs for use in * normal operations and in disaster recovery both in Lincolnshire and * at a disaster recovery vendor. *SysCfgID Svm_Name Dtyp Rdev Comment * CPC4 LPAR2 as of 20090214 PRODVM VTAM CTCA 0D61 'CTC 0D61 to SYSE, Read1' PRODVM VTAM CTCA 1D61 'CTC 1D61 to SYSE, Read2' PRODVM VTAM CTCA 0D62 'CTC 0D62 to SYSE, Write1' PRODVM VTAM CTCA 1D62 'CTC 1D62 to SYSE, Write2' PRODVM TCPIPOSA 0140 0140 PRODVM TCPIPOSA 0141 0141 PRODVM TCPIPOSA 0142 0142 * CPC4 LPAR2 as of Feb 2008? PRODVM VTAM CTCA 0D71 'CTC 0D71 to SYSF, Read1' PRODVM VTAM CTCA 1D71 'CTC 1D71 to SYSF, Read2' PRODVM VTAM CTCA 0D72 'CTC 0D72 to SYSF, Write1' PRODVM VTAM CTCA 1D72 'CTC 1D72 to SYSF, Write2' PRODVM TCPIPOSA 0140 0140 PRODVM TCPIPOSA 0141 0141 PRODVM TCPIPOSA 0142 0142 * CPC4 LPAR3 TESTVM VTAM CTCA 0C50 'CTC 0C50 to SYSE, Read1' TESTVM VTAM CTCA 0C51 'CTC 0C51 to SYSE Write1' * CPC5 LPAR3 as of 20090214 RECOVERY VTAM CTCA 0D61 'CTC 0D61 to SYSE for SNA terminals, Read1' RECOVERY VTAM CTCA 1D61 'CTC 1D61 to SYSE for SNA terminals, Read2' RECOVERY VTAM CTCA 0D62 'CTC 0D62 to SYSE for SNA terminals, Write1' RECOVERY VTAM CTCA 1D62 'CTC 1D62 to SYSE for SNA terminals, Write2' RECOVERY TCPIPOSA 6051 0140 RECOVERY TCPIPOSA 6052 0141 RECOVERY TCPIPOSA 6053 0142 ... * Updated 20090215 mrw - Add TCPIP OSA support (HA$TCPTX on TCPMAINT 198) ---snip--- I prefer that our VM system IPL without any manual changes during a D.R. test. After all: the sysprogs may have been casualties during the disaster. OK, we *do* have to install a few product passwords for D.R. serial numbers, but that is well documented, and pretty minimal (newer contracts have stricter ISV requirements allowing us to run on any of our machines). Hardware differences when running on the bare metal (done when recovering from our other data center) can be taken care of programmatically in this manner without requiring manual intervention, and without running VM under VM (making appropriate directory changes just to get the same device addresses as prod). Creating the NODAL CONFIG Y2 file above meant that when hardware addresses are changed, I don't have to search all over the place to find references to those addresses - they are all in one place. As usual, YMMV. After years of tweaking to speed up our D.R. (more or less, the Operator IPLs VM from the recovery machine, responds to a prompt from an EXEC called by OPERATOR's PROFILE EXEC asking if they really do want to IPL on a machine with a different serial number. Then the system comes up automatically adjusting for the processor change and it's particular hardware addresses and own peculiarities. During D.R. (after the mirrored and remote-copied DASD has been cut and the network is up), once we are given the LPAR for VM, the VM IPL takes the same 7-10 minutes it normally takes, and does not require a VM sysprog. Of course, we're always standing by in case something breaks, but this really does take all the work out of it at zero-dark-thirty. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/15/2010 12:06 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Devices OFFLINE at IPL The drawback to Mike's approach is that your system name changes at your DR site. That would cause more
Re: Devices OFFLINE at IPL
Yep, that was one consideration Date: Thu, 15 Jul 2010 09:14:33 -0700 From: rsc...@visa.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU Presumably, if you are at the DR site, your main site is unavailable. That may be all you really need. One possibility, procedural instead of program logic, would be to use the SALIPL screen to specify a different CONFIG file when you are at the DR site. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of clifford jackson Sent: Thursday, July 15, 2010 8:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL I have a production site and a DR site, the production site is being mirrored to the DR site same volume labels but different address. In my system config file I am using the Systems_Identifier with the CPU type, CPUID and the SystemID, this tell me if I am on the production system or the DR system, is there a way to add logic to the system config file to control which DASD I want online and which I vary offline at IPL time, without customizing the IOCP.. Date: Wed, 14 Jul 2010 10:26:02 -0500 From: r...@velocitysoftware.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. Get busy. _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Devices OFFLINE at IPL
Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy
Re: Devices OFFLINE at IPL
That's the way we have it (except we have Sensed last...not sure it makes a difference. Frank M. Ramaekers Jr. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Billy Bingham Sent: Wednesday, July 14, 2010 10:11 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Devices OFFLINE at IPL Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy _ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
Re: Devices OFFLINE at IPL
That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
Re: Devices OFFLINE at IPL
We have thousands of devices in the IOCP that we never want to see on our VM system; however, there are some we do need to access from VM intermixed with them. In this case, we find it better to add yet another category, Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks would be built for them and they could affect the way space is allocated and used in your monitor segment. As with all things that affect the configuration, you must take care when specifying that devices are to be kept offline or not even sensed. It is certainly best to insure that you do not include devices which you need in the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Smrcina Sent: Wednesday, July 14, 2010 8:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL That's one way, as long as the device numbers are never, ever used in this VM system. If they are, on the next IPL it will cause a little problem. Another possibility is to have an exec go through the DASD device list and vary off the devices based on whether the volume 'belongs' to the VM system. 'Ownership' is based on an identifier in the VOLID, eg: VM1RES, VM2WK1, etc. On 07/14/2010 10:11 AM, Billy Bingham wrote: Would the following be the proper way to specify devices, in the SYSTEM CONFIG file, that I don't want to come online at an IPL: Devices , Online_at_IPL -, Sensed -, Offline_at_IPL 0500-050F Thanks, Billy -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
Re: Devices OFFLINE at IPL
If you never want to see certain devices in the VM LPAR then the IOCP should be coded to not allow that LPAR to access the devices. Brian Nielsen On Wed, 14 Jul 2010 09:03:33 -0700, Schuh, Richard rsc...@visa.com wrot e: We have thousands of devices in the IOCP that we never want to see on ou r VM system; however, there are some we do need to access from VM intermixe d with them. In this case, we find it better to add yet another category, Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks would be built for them and they could affect the way space is allocated and used in your monitor segment. As with all things that affect the configuration, you must take care whe n specifying that devices are to be kept offline or not even sensed. It is certainly best to insure that you do not include devices which you need i n the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh
Re: Devices OFFLINE at IPL
Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requiring an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Wednesday, July 14, 2010 9:16 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL If you never want to see certain devices in the VM LPAR then the IOCP should be coded to not allow that LPAR to access the devices. Brian Nielsen On Wed, 14 Jul 2010 09:03:33 -0700, Schuh, Richard rsc...@visa.com wrot= e: We have thousands of devices in the IOCP that we never want to see on ou= r VM system; however, there are some we do need to access from VM intermixe= d with them. In this case, we find it better to add yet another category, = Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of = storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks= would be built for them and they could affect the way space is allocated = and used in your monitor segment. As with all things that affect the configuration, you must take care whe= n specifying that devices are to be kept offline or not even sensed. It is = certainly best to insure that you do not include devices which you need i= n the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh
Re: Devices OFFLINE at IPL
Isn't Not_accepted/Not_Sensed(unsupported) more to do with how CP handles devices Dynamically defined/added by a different LPar(Not_Accepted, specifically)? On Wed, Jul 14, 2010 at 12:41 PM, Schuh, Richard rsc...@visa.com wrote: Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requiring an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
Devices you want to see intermittently are not in the never category and, as you noted, require different treatment than never. Brian Nielsen On Wed, 14 Jul 2010 09:41:22 -0700, Schuh, Richard rsc...@visa.com wrot e: Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requirin g an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Wednesday, July 14, 2010 9:16 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL If you never want to see certain devices in the VM LPAR then the IOCP should be coded to not allow that LPAR to access the devices. Brian Nielsen On Wed, 14 Jul 2010 09:03:33 -0700, Schuh, Richard rsc...@visa.com wrot= e: We have thousands of devices in the IOCP that we never want to see on ou= r VM system; however, there are some we do need to access from VM intermixe= d with them. In this case, we find it better to add yet another category, = Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of = storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks= would be built for them and they could affect the way space is allocated = and used in your monitor segment. As with all things that affect the configuration, you must take care whe= n specifying that devices are to be kept offline or not even sensed. It is = certainly best to insure that you do not include devices which you need i= n the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh = ===
Re: Devices OFFLINE at IPL
So if it can't be controlled at the LParr, then priv class C(B too?) needs to be locked down to the few MVS security folk trust. On Wed, Jul 14, 2010 at 1:49 PM, Brian Nielsen bniel...@sco.idaho.gov wrote: Devices you want to see intermittently are not in the never category and, as you noted, require different treatment than never. Brian Nielsen On Wed, 14 Jul 2010 09:41:22 -0700, Schuh, Richard rsc...@visa.com wrote: Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requiring an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Wednesday, July 14, 2010 9:16 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL If you never want to see certain devices in the VM LPAR then the IOCP should be coded to not allow that LPAR to access the devices. Brian Nielsen On Wed, 14 Jul 2010 09:03:33 -0700, Schuh, Richard rsc...@visa.com wrot= e: We have thousands of devices in the IOCP that we never want to see on ou= r VM system; however, there are some we do need to access from VM intermixe= d with them. In this case, we find it better to add yet another category, = Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of = storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks= would be built for them and they could affect the way space is allocated = and used in your monitor segment. As with all things that affect the configuration, you must take care whe= n specifying that devices are to be kept offline or not even sensed. It is = certainly best to insure that you do not include devices which you need i= n the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
For certain. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gregg Sent: Wednesday, July 14, 2010 11:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL So if it can't be controlled at the LParr, then priv class C(B too?) needs to be locked down to the few MVS security folk trust. On Wed, Jul 14, 2010 at 1:49 PM, Brian Nielsen bniel...@sco.idaho.gov wrote: Devices you want to see intermittently are not in the never category and, as you noted, require different treatment than never. Brian Nielsen On Wed, 14 Jul 2010 09:41:22 -0700, Schuh, Richard rsc...@visa.com wrote: Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requiring an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Brian Nielsen Sent: Wednesday, July 14, 2010 9:16 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL If you never want to see certain devices in the VM LPAR then the IOCP should be coded to not allow that LPAR to access the devices. Brian Nielsen On Wed, 14 Jul 2010 09:03:33 -0700, Schuh, Richard rsc...@visa.com wrot= e: We have thousands of devices in the IOCP that we never want to see on ou= r VM system; however, there are some we do need to access from VM intermixe= d with them. In this case, we find it better to add yet another category, = Not_Accepted, which prevents the devices from being sensed and the building of control blocks for them. This prevents bloat in the use of = storage and in any monitor displays or reports. If you went ahead and sensed the devices and took them offline after the IPL, the device blocks= would be built for them and they could affect the way space is allocated = and used in your monitor segment. As with all things that affect the configuration, you must take care whe= n specifying that devices are to be kept offline or not even sensed. It is = certainly best to insure that you do not include devices which you need i= n the offline or Not_Accepted lists. As we like to say, Your gun, your bullet, your foot. Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
That may have been the original intent; however, customers always find ways to use features that may not have been considered by the designer. If we didn't, VM would have been a conversion tool with a 2 year life span. If a device is sensed and there is a device present, a VMDBK is built for it regardless of its online/offline status. There may be other blocks created for it as well. Making the device Not_Accepted prevents the sensing of the device and the building of the blocks. It is possible to dynamically add the device later using the DEFINE and SET commands, just as you would a device dynamically added to the LPAR. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gregg Sent: Wednesday, July 14, 2010 9:52 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL Isn't Not_accepted/Not_Sensed(unsupported) more to do with how CP handles devices Dynamically defined/added by a different LPar(Not_Accepted, specifically)? On Wed, Jul 14, 2010 at 12:41 PM, Schuh, Richard rsc...@visa.com wrote: Sorry, but there are the intermittent times when we need to see some of them. When needed, that can be accomplished via command, without requiring an update to the IOCP or LPAR Profile. The MVS security people want us to not even be able to vary them online except in special circumstances; thus, the Not_Accepted status. More proof that, All generalities are wrong, including this one. Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
Date: Wed, 14 Jul 2010 12:10:40 -0700 From: rsc...@visa.com Subject: Re: Devices OFFLINE at IPL To: IBMVM@LISTSERV.UARK.EDU If a device is sensed and there is a device present, a VMDBK is built for it regardless of its online/offline status. There may be other blocks created for it as well. Making the device Not_Accepted prevents the sensing of the device and the building of the blocks. It is possible to dynamically add the device later using the DEFINE and SET commands, just as you would a device dynamically added to the LPAR. Regards, Richard Schuh RDEV blocks and RDCBK's, not VMDBK's, but we know what you meant. ;-) Mark Wheeler, UnitedHealth Group _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5
Re: Devices OFFLINE at IPL
I don't know, give it a try; from LP1 define a device on LP2 that has a CU w/paths candidate/access lists. If LP2 has not_accepted it won't show up... w/o intervention, such as cp set accepted... then if you're wild enough to have 2 LPars w/DynIO enabled, you can steel the cookie and define a device from LP2 on LP2... I'm thinking it'll pop up, regardless of not_accepted, according to help cp set devices; if you don't have sensed set, you'll need to cp set rdev or attach it a guest. CP will build the RDEV blocks and RDCBK's, if light gets thru the director, to the cu interface and it'll be there for a vary online. Some time ago, we had a project to *conditionally* allow VM access to at least a simplex copy of TPF on-line dasd for a cmstpf build, Not_Accepted wasn't a lock for us and a CP EXIT we tried was a performance nightmare... but that is an entirely different story. ymmv. On Wed, Jul 14, 2010 at 3:10 PM, Schuh, Richard rsc...@visa.com wrote: That may have been the original intent; however, customers always find ways to use features that may not have been considered by the designer. If we didn't, VM would have been a conversion tool with a 2 year life span. If a device is sensed and there is a device present, a VMDBK is built for it regardless of its online/offline status. There may be other blocks created for it as well. Making the device Not_Accepted prevents the sensing of the device and the building of the blocks. It is possible to dynamically add the device later using the DEFINE and SET commands, just as you would a device dynamically added to the LPAR. Regards, Richard Schuh Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
We have already been doing it for a few years. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Gregg Sent: Wednesday, July 14, 2010 1:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Devices OFFLINE at IPL I don't know, give it a try; from LP1 define a device on LP2 that has a CU w/paths candidate/access lists. If LP2 has not_accepted it won't show up... w/o intervention, such as cp set accepted... then if you're wild enough to have 2 LPars w/DynIO enabled, you can steel the cookie and define a device from LP2 on LP2... I'm thinking it'll pop up, regardless of not_accepted, according to help cp set devices; if you don't have sensed set, you'll need to cp set rdev or attach it a guest. CP will build the RDEV blocks and RDCBK's, if light gets thru the director, to the cu interface and it'll be there for a vary online. Some time ago, we had a project to *conditionally* allow VM access to at least a simplex copy of TPF on-line dasd for a cmstpf build, Not_Accepted wasn't a lock for us and a CP EXIT we tried was a performance nightmare... but that is an entirely different story. ymmv. On Wed, Jul 14, 2010 at 3:10 PM, Schuh, Richard rsc...@visa.com wrote: That may have been the original intent; however, customers always find ways to use features that may not have been considered by the designer. If we didn't, VM would have been a conversion tool with a 2 year life span. If a device is sensed and there is a device present, a VMDBK is built for it regardless of its online/offline status. There may be other blocks created for it as well. Making the device Not_Accepted prevents the sensing of the device and the building of the blocks. It is possible to dynamically add the device later using the DEFINE and SET commands, just as you would a device dynamically added to the LPAR. Regards, Richard Schuh Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
Cheers! give me a logon and priv class... naw. I could be wrong, I have been wrong, let's run w/that. On Wed, Jul 14, 2010 at 4:25 PM, Schuh, Richard rsc...@visa.com wrote: We have already been doing it for a few years. Regards, Richard Schuh -- Gregg Reed No Plan, survives execution
Re: Devices OFFLINE at IPL
On Wednesday, 07/14/2010 at 02:03 EDT, Gregg reed.gr...@gmail.com wrote: So if it can't be controlled at the LParr, then priv class C(B too?) needs to be locked down to the few MVS security folk trust. - Never give privilege class C to anyone who is not a trained AND trusted z/VM systems programmer. - Never give privilege class B to anyone just so they can issue the ATTACH and VARY commands. Instead, define them as privclass BQ and give your trusted MVS people privclass GQ. (e.g. MODIFY COMMAND ATTACH PRIVCLASS BQ) Alan Altmark z/VM Development IBM Endicott
