Re: source of VM's duplex info - solution
Two weeks ago, I posted a question about VM giving incorrect information about disks. I did: Q DASD DETAILS 400 0400 CUTYPE = 3990-E9, DEVTYPE = 3390-0C, VOLSER =, CYLS = 10017 CACHE DETAILS: CACHE NVS CFW DFW PINNED CONCOPY -SUBSYSTEM YY Y -N N -DEVICE Y- - YN N DEVICE DETAILS: CCA = 00, DDC = 00 DUPLEX DETAILS: -- PPRC DETAILS: SECONDARY VOLUME READY; T=0.01/0.01 14:31:46 As you see, VM still says: PPRC DETAILS: SECONDARY VOLUME which is in obvious contradiction to ICKDSF which says: DEVICE LEVEL STATE PATH STATUS -- - -- --- 0400PRIMARY DUPLEX ACTIVE So, VM definitely has it wrong! :-( Why??? and how do I get VM to see the light? Since no one here responded (except Kris, but not with an explanation or solution), I figured I should close the story by posting what I got from IBM. They don't know HOW it happened, but they said that somehow a bit in the RDEV got klobbered, resulting in VM being sure of one thing, when DSF (which actually asks the CU for the facts) knew otherwise. The solution was fairly simple: VARY OFF nnn SET RDEV nnn CLEAR VARY ON nnn The CLEAR did exactly that, cleared up the confusion. :-) Then I was able to ATTACH TO SYSTEM again, and all is well. Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 ** **
Re: Setting up VLAN Aware VSWITCH
On Fri, 23 Mar 2007 09:55:05 -0400, Alan Altmark [EMAIL PROTECTED] wrote: It is also my recommendation that you do not share an OSA in use by a VSWITCH, *especially* if it is VLAN-aware. The last thing you want is a fight between two VSWITCHes about whether a VLAN is in use. Yes it is, no it isn't, yes it is, no it isn't If you choose to go down this path, define the VSWITCH with NOGVRP. Would you please eloborate on this? I have multiple VLAN-aware VSWITCHes sharing the same OSA with no problems. Each VSWITCH has a distinct and separate set of VLANs, if that makes any difference. This setup is required to connect non-VLAN-aware guests to multiple VLANs via VSWITCH GRANTs. If there is a pitfall in there somewhere I'd like to know more about it. Brian Nielsen
Re: SSLSERV
Is there documentation that discusses this package from the security perspective? The benefits of having it in place are obvious. What I require is documentation that says no one can modify the configuration because it has not been assigned an IP address or something of that nature. As far as I know, no one has conducted a formal evaluation of the SSL Enabler appliance system yet, and I don't remember any explicit commentary in the IBM security reviews on SSLSERV (but my memory is not what it used to be, I'm afraid). There is commentary in the IBM TCPIP documentation (in the planning and administration guide) on SSLSERV and how it operates, and the installation README file inside the RPM describes at what point the IP stack in the Linux guest is rendered non-functional. After that point, it's pretty tough to change *anything* in that guest without access to the virtual machine console (which would be covered by your VM security package) and even then, you'd have to be comfortable with line-mode editing tools at an unusually capable level. The number of people with Unix experience on real TTYs is not growing...8-) I suspect that to get a formal security confirmation from IBM you would need to move to a SuSE or RH based SSLSERV, as that's what they've evaluated. I'd be happy to work with IBM to get that confirmation for the SSL Enabler appliance, if there's interest. I think there would be a lot of value to cooperatively developing things like this with IBM if the prohibition of IBM being a Linux distributor continues. I know I have a wish list of changes I'd make to the SSLSERV code if I could tweak that OCO module's contents. If either RH or Novell are interested in working on appliances like this with us, please contact us offline. I suspect there is a good opportunity here to gain mindshare for a distributor (with proper credit, of course). -- db
Re: Setting up VLAN Aware VSWITCH
I am also trying to find any documentation that describes this issue. The lpar that we are setting up will eventually be shared with a 2nd lpar with a similar configuration. If I cannot share the OSA I may have a problem. Can someone, maybe IBM, describe in more detail what can or cannot be done with VSWITCH's ? Alan had also mentioned As long as you don't connect a routing guest to two VSWITCHes at the same time, you shouldn't have any spanning tree problems. Does this include firewall routers or guest lan (or another internal vswitch) between these servers ? Is there any information about this I can read about this, is this something a LAN administrator would know ? Thanks, Mark Vandale System Administrator Leader MCS z/VM z/VSE Office: (860) 823-2756 Cell:(860) 705-1657 CSC This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Brian Nielsen [EMAIL PROTECTED] HO.GOVTo Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU Re: Setting up VLAN Aware VSWITCH 03/26/2007 10:53 AM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU On Fri, 23 Mar 2007 09:55:05 -0400, Alan Altmark [EMAIL PROTECTED] wrote: It is also my recommendation that you do not share an OSA in use by a VSWITCH, *especially* if it is VLAN-aware. The last thing you want is a fight between two VSWITCHes about whether a VLAN is in use. Yes it is, no it isn't, yes it is, no it isn't If you choose to go down this path, define the VSWITCH with NOGVRP. Would you please eloborate on this? I have multiple VLAN-aware VSWITCHes sharing the same OSA with no problems. Each VSWITCH has a distinct and separate set of VLANs, if that makes any difference. This setup is required to connect non-VLAN-aware guests to multiple VLANs via VSWITCH GRANTs. If there is a pitfall in there somewhere I'd like to know more about it. Brian Nielsen
Re: Setting up VLAN Aware VSWITCH
On Monday, 03/26/2007 at 09:53 EST, Brian Nielsen [EMAIL PROTECTED] wrote: On Fri, 23 Mar 2007 09:55:05 -0400, Alan Altmark [EMAIL PROTECTED] wrote: It is also my recommendation that you do not share an OSA in use by a VSWITCH, *especially* if it is VLAN-aware. The last thing you want is a fight between two VSWITCHes about whether a VLAN is in use. Yes it is, no it isn't, yes it is, no it isn't If you choose to go down this path, define the VSWITCH with NOGVRP. Would you please eloborate on this? I have multiple VLAN-aware VSWITCHes sharing the same OSA with no problems. Each VSWITCH has a distinct and separate set of VLANs, if that makes any difference. This setup is required to connect non-VLAN-aware guests to multiple VLANs via VSWITCH GRANTs. If there is a pitfall in there somewhere I'd like to know more about it. As long as you do not try to span VLANs across different VSWITCHes sharing an OSA, it will work. The problem I run into is that someone changes the switch (virtual or real) or VLAN configuration without thinking about the affect on a shared port. Things start to fail. But it's just a recommendation, not a requirement. Our gun. Your foot. In z/VM 5.3 we announced support for IBM System z9 IEEE 802.1ad Link Aggregation (channel bonding, etherchannel), providing additional bandwidth with each OSA you add to the aggregation group. In this configuration, the OSAs are usable by only a single VSWITCH at a time, and will use additional hardware support to enforce this. (There is a switch-to-switch protocol flowing over the links along with user data and more than one cook in the kitchen will spoil the broth...) Imagine up to 80 Gb of data per second moving in/out of the box (up to eight 10 Gb ports). This support also provides for the smooth addition or removal of OSAs from the aggregation group, whether because you want to add/take an OSA, or because one fails. No data is lost, with retransmission handled at a packet level rather than at the TCP segment level. If you ever think you will want to take advantage of this support, you need to be planning for dedicated OSAs, even if you need to share right now. And, of course, mixing VLAN-aware and non-VLAN-aware is a no-no, though nothing will enforce it. So, none of this is really about what *can* be done. You can share all you want. But the risk to your virtual data center is lowest if you don't share, and that remains my recommendation. Admittedly, because Alan says so only goes so far (the Wesayso Corporation, anyone?). I have the same problem at home. Go figure. :-) Alan Altmark z/VM Development IBM Endicott
Re: CPU usage -- virtual or dedicated ?
As noted by the entire universe, that is true. Our VM LPAR normally has 5 shared cpus. The normal TPF guest has no more than 3 virtual cpus. If special functional tests are being run, a user may go higher than 5. This requires our complicity as we have to update the directory to allow it, and there are no performance expectations. It is usually off-peak when these tests are run. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stracka, James (GTI) Sent: Friday, March 23, 2007 12:00 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: CPU usage -- virtual or dedicated ? And it is considered bad practice to give a guest more virtual CPUs than real CPUs.
Re: RSCS: LPR page size
Hi Shimon, If you are printing from CMS to a printer on RSCS (LPR or otherwise) and the CMS file doesn't contain carriage control, isn't CMS the one that is breaking it up into 60 line pieces? You would have to tell CMS it has an 80 line (or whatever) printer when it formats its output. On 3/26/07, Shimon Lebowitz [EMAIL PROTECTED] wrote: I am sending files via RSCS to be printed on an LPR link, without any carriage control. The link is defined with EXIT=LPRXONE. The printed output (on portrait mode paper) is only 60 lines per page. How can I control the page size (in lines) of an LPR link? I would like to increase it considerably. Is this possible when printing w/o CC? Using CC I have filled a page. Thanks! Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 ** **
Re: RSCS: LPR page size
Shimon, Would the LINECOUNT parameter for the CMS PRINT command do what you want to do? On 3/26/07, Ron Schmiedge [EMAIL PROTECTED] wrote: Hi Shimon, If you are printing from CMS to a printer on RSCS (LPR or otherwise) and the CMS file doesn't contain carriage control, isn't CMS the one that is breaking it up into 60 line pieces? You would have to tell CMS it has an 80 line (or whatever) printer when it formats its output. On 3/26/07, Shimon Lebowitz [EMAIL PROTECTED] wrote: I am sending files via RSCS to be printed on an LPR link, without any carriage control. The link is defined with EXIT=LPRXONE. The printed output (on portrait mode paper) is only 60 lines per page. How can I control the page size (in lines) of an LPR link? I would like to increase it considerably. Is this possible when printing w/o CC? Using CC I have filled a page. Thanks! Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 ** **
Re: Setting up VLAN Aware VSWITCH
Alan Altmark wrote: [snip of some interesting comments] In z/VM 5.3 we announced support for IBM System z9 IEEE 802.1ad Link Aggregation (channel bonding, etherchannel), providing additional bandwidth with each OSA you add to the aggregation group. In this configuration, the OSAs are usable by only a single VSWITCH at a time, and will use additional hardware support to enforce this. (There is a switch-to-switch protocol flowing over the links along with user data and more than one cook in the kitchen will spoil the broth...) Imagine up to 80 Gb of data per second moving in/out of the box (up to eight 10 Gb ports). Oh, goodie...IBM can now bid z9s as servers for the on line pornographic marketplace:-) One server does both the movies *and* the billing DJ
IODF
I recently converted our IODF file via z/os to V5 format. Z/VM has not been IPL'd since the change. Is there any reason I should be concerned about this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: IODF
Anne, We use z/OS 1.8 in one LPAR to create our IOCDS/IODF files. We also have two LPARs running z/VM (5.1 and 5.2). The z/VM LPARs have no problem coexisting with the z/OS produced configuration files. Of note, the z/VM LPARs seldom have their configurations changed. But, bottom line, there are no problems... HITACHI DATA SYSTEMS Raymond E. Noal Senior Technical Engineer Office: (408) 970 - 7978 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Anne Crabtree Sent: Monday, March 26, 2007 11:32 AM To: IBMVM@LISTSERV.UARK.EDU Subject: IODF I recently converted our IODF file via z/os to V5 format. Z/VM has not been IPL'd since the change. Is there any reason I should be concerned about this? Anne D. Crabtree System Programmer WV Dept of Administration - OT 304-558-5914 ext 8885 Fax 304-558-1351
Re: Setting up VLAN Aware VSWITCH
I appreciate the elaboration and its relevance to link aggregation. My next question would be how to move toward non-shared OSAs and maintain no n- VLAN-aware guests connected to multiple VLANs through the OSA. The two seem to be incompatible. Either the guests need to become VLAN-aware to have multiple NICs to the same VSWITCH, or NICDEF needs a new parameter t o define its' default VLAN (to supercede the VSWITCH GRANT default VLAN for *every* NIC from a guest). Is there another way? Brian Nielsen On Mon, 26 Mar 2007 12:16:00 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Monday, 03/26/2007 at 09:53 EST, Brian Nielsen [EMAIL PROTECTED] V wrote: On Fri, 23 Mar 2007 09:55:05 -0400, Alan Altmark [EMAIL PROTECTED] wrote: It is also my recommendation that you do not share an OSA in use by a VSWITCH, *especially* if it is VLAN-aware. The last thing you want is a fight between two VSWITCHes about whether a VLAN is in use. Yes it is, no it isn't, yes it is, no it isn't If you choose to go down this path , define the VSWITCH with NOGVRP. Would you please eloborate on this? I have multiple VLAN-aware VSWITCHes sharing the same OSA with no problems. Each VSWITCH has a distinct an d separate set of VLANs, if that makes any difference. This setup is required to connect non-VLAN-aware guests to multiple VLANs via VSWITC H GRANTs. If there is a pitfall in there somewhere I'd like to know more about i t. As long as you do not try to span VLANs across different VSWITCHes shari ng an OSA, it will work. The problem I run into is that someone changes th e switch (virtual or real) or VLAN configuration without thinking about th e affect on a shared port. Things start to fail. But it's just a recommendation, not a requirement. Our gun. Your foot. In z/VM 5.3 we announced support for IBM System z9 IEEE 802.1ad Link Aggregation (channel bonding, etherchannel), providing additional bandwidth with each OSA you add to the aggregation group. In this configuration, the OSAs are usable by only a single VSWITCH at a time, a nd will use additional hardware support to enforce this. (There is a switch-to-switch protocol flowing over the links along with user data an d more than one cook in the kitchen will spoil the broth...) Imagine up to 80 Gb of data per second moving in/out of the box (up to eight 10 Gb ports). This support also provides for the smooth addition or removal of OSAs fr om the aggregation group, whether because you want to add/take an OSA, or because one fails. No data is lost, with retransmission handled at a packet level rather than at the TCP segment level. If you ever think you will want to take advantage of this support, you need to be planning for dedicated OSAs, even if you need to share right now. And, of course, mixing VLAN-aware and non-VLAN-aware is a no-no, though nothing will enforce it. So, none of this is really about what *can* be done. You can share all you want. But the risk to your virtual data center is lowest if you don 't share, and that remains my recommendation. Admittedly, because Alan says so only goes so far (the Wesayso Corporation, anyone?). I have the same problem at home. Go figure. : -) Alan Altmark z/VM Development IBM Endicott =
Re: SSLSERV
On Monday, 03/26/2007 at 10:53 AST, David Boyes [EMAIL PROTECTED] wrote: As far as I know, no one has conducted a formal evaluation of the SSL Enabler appliance system yet, and I don't remember any explicit commentary in the IBM security reviews on SSLSERV (but my memory is not what it used to be, I'm afraid). IBM makes no claims about what the SNA SSL Enabler appliance does or does not do. There is commentary in the IBM TCPIP documentation (in the planning and administration guide) on SSLSERV and how it operates, and the installation README file inside the RPM describes at what point the IP stack in the Linux guest is rendered non-functional. After that point, it's pretty tough to change *anything* in that guest without access to the virtual machine console (which would be covered by your VM security package) and even then, you'd have to be comfortable with line-mode editing tools at an unusually capable level. The number of people with Unix experience on real TTYs is not growing...8-) When installed in the IBM-supported environments according IBM documentation, four layers of protection are provided: 1. The SSL server's native AF_INET IP stack and device drivers are rendered inoperative. 2. The only service that is running is the SSL administrative interface. 3. The SSL admin interface binds to the loopback address to limit connections to local VM TCP/IP apps. 4. It uses assists in the VM TCP/IP stack to ensure that only users in the VM TCP/IP obey list can connect to the administrative interface. With all four layers of protection in place, I feel that the SSL server is [more than?] reasonably protected from unauthorized tampering. Naturally, if you give someone access to the SSLSERVE virtual machine itself, none of those protections amount to a hill of beans. But, using one of my freshly-printed Get Out of Jail Free cards, I declare that as Authorized Tampering. Alan Altmark z/VM Development IBM Endicott
Re: Setting up VLAN Aware VSWITCH
On Monday, 03/26/2007 at 02:00 EST, Brian Nielsen [EMAIL PROTECTED] wrote: I appreciate the elaboration and its relevance to link aggregation. My next question would be how to move toward non-shared OSAs and maintain non- VLAN-aware guests connected to multiple VLANs through the OSA. The two seem to be incompatible. Either the guests need to become VLAN-aware to have multiple NICs to the same VSWITCH, or NICDEF needs a new parameter to define its' default VLAN (to supercede the VSWITCH GRANT default VLAN for *every* NIC from a guest). Is there another way? No, you have the right of it. We do not have a way to define the default VLAN on a per-NIC basis. By the time people really start to want to dedicate the OSAs as I have described, I hope to have that problem solved. (Your solution and mine are the same, btw.) But for now it's two VSWITCHes with a different VLAN id for the guest sharing the same OSA, or, as you suggest, making the guest VLAN-aware, but authorized to use only two VLAN ids. But if a user group or customer (via their IBM rep or BP) was able to get a requirement opened for that capability, life would be better for everyone concerned. Alan Altmark z/VM Development IBM Endicott
Re: RSCS: LPR page size
If you are printing from CMS to a printer on RSCS But I am not. My output is being generated on VSE and going via NJE to RSCS to be printed, using a DEST= parameter on the LST card. The printing itself is being done with NO page size control in the application, just keep spewing out the lines till it's done. Thanks, Shimon
Re: RSCS: LPR page size
If you are printing from CMS to a printer on RSCS But I am not. My output is being generated on VSE and going via NJE to RSCS to be printed, using a DEST= parameter on the LST card. The printing itself is being done with NO page size control in the application, just keep spewing out the lines till it's done. You need to define a PCL command (via the link PREFIX string) to tell the printer how many lines/page for the print output. Remember to use the suffix string to reset the printer for the next print out. Best Regards, Les Geer IBM z/VM and Linux Development
Re: RSCS: LPR page size
The printing itself is being done with NO page size control in the application, just keep spewing out the lines till it's done. You need to define a PCL command (via the link PREFIX string) to tell the printer how many lines/page for the print output. Remember to use the suffix string to reset the printer for the next print out. Les, Does this mean that the pages stopping at 60 lines is being done by the printer itself, and not by RSCS? Thank you, Shimon
Re: RSCS: LPR page size
Hi Shimon, You've tried using // STDOPT LINES=nn in your job to change the default number of lines on the page for your job? On 3/26/07, Shimon Lebowitz [EMAIL PROTECTED] wrote: The printing itself is being done with NO page size control in the application, just keep spewing out the lines till it's done. You need to define a PCL command (via the link PREFIX string) to tell the printer how many lines/page for the print output. Remember to use the suffix string to reset the printer for the next print out. Les, Does this mean that the pages stopping at 60 lines is being done by the printer itself, and not by RSCS? Thank you, Shimon
Re: RSCS: LPR page size
From what's been written, I presume that the carriage control that VSE uses would be preserved if it existed. Using // STDOPT LINES= is a way to influence VSE's production of carriage control characters. However, printouts can be produced in VSE in two different ways - via SYSLST (system logical unit) or a numbered SYS (e.g., SYS010 - program logical unit). STDOPT affects only SYSLST output. To complicate matters even further, if your program is a COBOL program and is using DISPLAY (UPON SYSLST) then there will be no page breaks, regardless of STDOPT LINES. Ordinarily reports aren't written with DISPLAY, but it has been done. To put it another way, if your program is using a program logical unit (a numbered SYS), STDOPT LINES= won't help. The only way you can control the page breaks from the VSE side is from within your program. - Tom. At 03:27 PM 3/26/2007, you wrote: Hi Shimon, You've tried using // STDOPT LINES=nn in your job to change the default number of lines on the page for your job? Tom Cluster County of Sonoma Santa Rosa, CA (707) 565-3384 (Tuesdays and Wednesdays only)
Re: RSCS: LPR page size
The printing itself is being done with NO page size control in the application, just keep spewing out the lines till it's done. You need to define a PCL command (via the link PREFIX string) to tell the printer how many lines/page for the print output. Remember to use the suffix string to reset the printer for the next print out. Les, Does this mean that the pages stopping at 60 lines is being done by the printer itself, and not by RSCS? Well, RSCS is not counting lines for LPR printers. It will generate form feeds if the (any) control characters in the print job request such. Do you know if the VSE job contains CC? If not, then the printer is determining lines per page. In either case, RSCS is not. Best Regards, Les Geer IBM z/VM and Linux Development
