Re: SHARE attendees - Any Update on the Live Guest Migration?
It was mentioned in a keynote - so I guess it is official now. No dates for it that I know of, except I think Jim Elliot said not this year in one of his presentations. -Paul On Mar 5, 2009, at 2:19 PM, Lionel B. Dyck wrote: Has there been any update on the status of Live Guest Migration? thx Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: lionel.b.d...@kp.org AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We’re here to make lives better.” “Never attribute to malice what can be caused by miscommunication.” NOTICE TO RECIPIENT: If you are not the intended recipient of this e- mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you.
Re: VSWITCH and OSPF setup
If your system does not need to move around in the network and you have a flat network than look at using two vswitch Controller and 1 VSWICH and let CP handle any failover for hardware failures. To be totally redundant you would need to separate OSA cards, but you can do it with two OSA ports on the same card. V S OSA Port 0 - S T W A OSA Port 1 - I C T K C H From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Spann, Elizebeth (Betsie) Sent: Thursday, March 05, 2009 6:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: VSWITCH and OSPF setup Hi All, I'm looking for advice on converting from static IP on my VM stack to OSPF. I think I will need to go to two VSWITCHes rather than just the one I use for static IP. I've created a simple PowerPoint to illustrate. OSPF -1.ppt All advice welcomed. Betsie
Re: VSWITCH and OSPF setup
On Thursday, 03/05/2009 at 06:23 EST, Spann, Elizebeth (Betsie) bsp...@visa.com wrote: I'm looking for advice on converting from static IP on my VM stack to OSPF. I think I will need to go to two VSWITCHes rather than just the one I use for static IP. I've created a simple PowerPoint to illustrate. Betsie, what problem do you want to solve? 1. If you want to protect yourself from an OSA outage, a single VSWITCH with two or more OSAs plugged into a single physical switch is sufficient. 2. If you want to protect yourself from a PHYSICAL SWITCH outage, then buy a second switch and plug OSA#2 of ONE VSWITCH into it. The physical switches must be trunked together in an HA configuration. Or did you have a diffferent concern? Alan Altmark z/VM Development IBM Endicott
VMLINK
I would like to replace 'ACCESS VMSYS:TOOLS.TOOLBOX R/A' VMLINK. I used 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX R/A'. This resulted in only linking the SFS directory as filemode R not as an extension of A. What am I missing? TIA. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VMLINK
Try 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX * R/A' -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Friday, March 06, 2009 8:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: VMLINK I would like to replace 'ACCESS VMSYS:TOOLS.TOOLBOX R/A' VMLINK. I used 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX R/A'. This resulted in only linking the SFS directory as filemode R not as an extension of A. What am I missing? TIA.
Service - Where did it come from
A question was posed to me recently that I couldn't think of a way to answer. We have been running through some testing on a system and applying a lot of PTFs to resolve issues. Then, along comes RSU 802 and it is put on. We roll 802 out to the other LPARs and then comes the question: Which PTFs are missing from the other systems? Or, what PTFs that we put on the first LPAR to solve problems were not included on the 802 RSU? I couldn't come up with a quick and easy answer. So my question is: Is there a way to list the PTFs on a system so that it says where they came from? Perhaps a file that has all the PTFs on the system that could be compared to a TOC of the RSU (PIPE collate comes to mind)? Bob Bates Enterprise Hosting Services w. (469)892-6660 c. (214) 907-5071 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.
Re: VMLINK
Perfect - Thanks! What does the '*' do? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Hodge, Robert L Sent: Friday, March 06, 2009 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VMLINK Try 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX * R/A' -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Friday, March 06, 2009 8:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: VMLINK I would like to replace 'ACCESS VMSYS:TOOLS.TOOLBOX R/A' VMLINK. I used 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX R/A'. This resulted in only linking the SFS directory as filemode R not as an extension of A. What am I missing? TIA. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: VMLINK
The * is a placeholder for the virtual address or range of addresses. Since this is SFS, there is no virtual address, but you still need a placeholder. Also note that you're forcing the directory to be accessed as R, even if something else is already accessed as R. You could code a range instead: * R-Z/A On Fri, Mar 6, 2009 at 10:54 AM, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: Perfect - Thanks! What does the '*' do? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Hodge, Robert L Sent: Friday, March 06, 2009 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VMLINK Try 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX * R/A' -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Friday, March 06, 2009 8:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: VMLINK I would like to replace 'ACCESS VMSYS:TOOLS.TOOLBOX R/A' VMLINK. I used 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX R/A'. This resulted in only linking the SFS directory as filemode R not as an extension of A. What am I missing? TIA. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: Service - Where did it come from
Look at the $APPLIST file on the DELTA disk for the product. From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bates Sent: Friday, March 06, 2009 8:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Service - Where did it come from A question was posed to me recently that I couldn't think of a way to answer. We have been running through some testing on a system and applying a lot of PTFs to resolve issues. Then, along comes RSU 802 and it is put on. We roll 802 out to the other LPARs and then comes the question: Which PTFs are missing from the other systems? Or, what PTFs that we put on the first LPAR to solve problems were not included on the 802 RSU? I couldn't come up with a quick and easy answer. So my question is: Is there a way to list the PTFs on a system so that it says where they came from? Perhaps a file that has all the PTFs on the system that could be compared to a TOC of the RSU (PIPE collate comes to mind)? Bob Bates Enterprise Hosting Services w. (469)892-6660 c. (214) 907-5071 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.
Re: OSADMIN3 Failure when attempting GUI
It looks like it could be OSASF APAR OA27349. Also remember, you will need to (re)BUILD the IOAXTSRV MODULE after the OSASF install is complete becase we ship 'stubs' for the TCPIP module since way back when we could not determine the level of TCPIP you were running (this is all doc'd in the OSASF440 PSP Install bucket). Note (also in psp bucket) there is a CM S APAR VM64552 that can cause problems during the build...please see the details in the VMOSASF440 PSP bucket. I would recommend applying this CM S apar and all the available OSASF R440 COR. -Roger Lunsford z/VM CP Level2
fcp disk under SUSE9
We are attempting to use zfcp scsi devices with SuSE 9 sp4 (linux on z) We place a 10gb lun into a volume group. We have to manually create the volume groups since yast is not working fo r SUSE 9 (known issue) Once this procedue is completed, the disk is recognized and can be used for read/write operation. The mount is placed in fstab. After we reboot the machine nothing comes back (We perform mkintrd and zipl). We can manually re-define the volume group and the system will recognize it again. There are occasions when the data is corrupted. Has anyone run into issue s attaching fcp disk to a volume group with SUSE 9 ? We have had no problem s utilizing fcp disk with SUSE 10.
Re: VMLINK
Even better - thanks! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bruce Hayden Sent: Friday, March 06, 2009 9:57 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VMLINK The * is a placeholder for the virtual address or range of addresses. Since this is SFS, there is no virtual address, but you still need a placeholder. Also note that you're forcing the directory to be accessed as R, even if something else is already accessed as R. You could code a range instead: * R-Z/A On Fri, Mar 6, 2009 at 10:54 AM, Wandschneider, Scott scott.wandschnei...@infocrossing.com wrote: Perfect - Thanks! What does the '*' do? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Hodge, Robert L Sent: Friday, March 06, 2009 9:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VMLINK Try 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX * R/A' -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: Friday, March 06, 2009 8:43 AM To: IBMVM@LISTSERV.UARK.EDU Subject: VMLINK I would like to replace 'ACCESS VMSYS:TOOLS.TOOLBOX R/A' VMLINK. I used 'EXEC VMLINK .DIR VMSYS:TOOLS.TOOLBOX R/A'. This resulted in only linking the SFS directory as filemode R not as an extension of A. What am I missing? TIA. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. -- Bruce Hayden Linux on System z Advanced Technical Support IBM, Endicott, NY
Re: XSTORE
We don't need a thumb drive on the mainframewe need a fist drive on the mainframe. Just something a lot bigger G. Tom Duerbusch THD Consulting Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM If it was dynamic to configure XSTORE one could experiment a bit. Or if the Z11 comes with a USB port that one could plug a thumb drive into and be back to what XSTORE used to be .. I digress we really don't need USB ports on the mainframe. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE That may not be a good thing. The most frequent advice I have heard/seen in that area is to do all MDC to main and only use XSTORE for paging. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ron Schmiedge Sent: Thursday, March 05, 2009 8:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE Hi Mike, Many experts have talked about XSTORE and VM using it for paging. All our defined XSTORE is being used for MDCACHE. It made a noticable difference to I/O performance for our VSE production guest. We could have done it all in regular storage but until a recent processor change, we didn't have much real storage that I wanted to give away. A new-to-us z800 came with a lot more memory than we used to have, so we configured some as XSTORE and MDC took it all. I wish I could claim good planning on our part. Ron On Wed, Mar 4, 2009 at 12:55 PM, Michael Coffin michaelcof...@mccci.com wrote: Hi Folks, What value is there in defining XSTORE these days? Aside from the ability to attach XSTORE to specific virtual machines, wouldn't it be best to just make it all DPA and let CP manage it? Also, assuming you aren't paging much - is attaching XSTORE to a userid going to provide a VERY noticable improvement in performance (at the expense of taking it away from all other virtual machines, of course)? -Mike
Re: XSTORE
What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, March 06, 2009 8:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE We don't need a thumb drive on the mainframewe need a fist drive on the mainframe. Just something a lot bigger G. Tom Duerbusch THD Consulting Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM If it was dynamic to configure XSTORE one could experiment a bit. Or if the Z11 comes with a USB port that one could plug a thumb drive into and be back to what XSTORE used to be .. I digress we really don't need USB ports on the mainframe. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE That may not be a good thing. The most frequent advice I have heard/seen in that area is to do all MDC to main and only use XSTORE for paging. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ron Schmiedge Sent: Thursday, March 05, 2009 8:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE Hi Mike, Many experts have talked about XSTORE and VM using it for paging. All our defined XSTORE is being used for MDCACHE. It made a noticable difference to I/O performance for our VSE production guest. We could have done it all in regular storage but until a recent processor change, we didn't have much real storage that I wanted to give away. A new-to-us z800 came with a lot more memory than we used to have, so we configured some as XSTORE and MDC took it all. I wish I could claim good planning on our part. Ron On Wed, Mar 4, 2009 at 12:55 PM, Michael Coffin michaelcof...@mccci.com wrote: Hi Folks, What value is there in defining XSTORE these days? Aside from the ability to attach XSTORE to specific virtual machines, wouldn't it be best to just make it all DPA and let CP manage it? Also, assuming you aren't paging much - is attaching XSTORE to a userid going to provide a VERY noticable improvement in performance (at the expense of taking it away from all other virtual machines, of course)? -Mike
Re: XSTORE
On 3/6/09 11:32 AM, Schuh, Richard rsc...@visa.com wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. OK, it has to be said: It's not the size. It's what you do with it. (Is it time to go home yet?) --d b
Re: XSTORE
You should have said that before. I was responding to the mention of size being some sort of determining factor. (It will be Friday for the rest of the day.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Friday, March 06, 2009 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE On 3/6/09 11:32 AM, Schuh, Richard rsc...@visa.com wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. OK, it has to be said: It's not the size. It's what you do with it. (Is it time to go home yet?) --d b
Re: XSTORE
Let's call them flash drives. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 10:39 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE You should have said that before. I was responding to the mention of size being some sort of determining factor. (It will be Friday for the rest of the day.) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Friday, March 06, 2009 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE On 3/6/09 11:32 AM, Schuh, Richard rsc...@visa.com wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. OK, it has to be said: It's not the size. It's what you do with it. (Is it time to go home yet?) --d b
Must be Friday: Mainframe USBs!
On 3/6/2009 10:32 AM, Schuh, Richard wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. I've been working with open systems for too long; I can't figure out what that would be in CKD terms. A 3390-243? (Can someone ask at the cluster closing, please?)
Re: Must be Friday: Mainframe USBs!
A 3390 formatted in 4K blocks is about 2.5G. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Nick Laflamme Sent: Friday, March 06, 2009 9:08 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Must be Friday: Mainframe USBs! On 3/6/2009 10:32 AM, Schuh, Richard wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. I've been working with open systems for too long; I can't figure out what that would be in CKD terms. A 3390-243? (Can someone ask at the cluster closing, please?)
Re: Using LBYONLY
Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid cannot be logged onto, LOGONBY rules are irrelevant. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Shimon Lebowitz Sent: Wednesday, March 04, 2009 02:14 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY I am sorry, but that set of rules WILL work in VM:Secure. To quote the Rules Manual: quote When two or more rules in a file govern a particular access request, VM:Secure establishes an order of preference based on how precisely the requester is specified. In order of
Re: Must be Friday: Mainframe USBs!
3390 mod 3 characteristics. 3339 cyls, 15 trks/cyl, 58786 bytes/trk 2944296810 bytes 2875289.853515625 k-bytes 2807.9002475738525390625m-bytes 2.74209008552134037017822265625 g-bytes 3390 mod 9 characteristics. 10017 cyls, 15 trks/cyl,58786 bytes/trk 8832890430 bytes 8625869.560546875 k-bytes 8423.7007427215576171875m-bytes 8.22627025656402111053466796875 g-bytes VSAM calls up to 10017 cylinders BIG-3390 Up to 65,520 cylinders are FAT-3390. And somewhere are larger cylindered customized-sized 3390 using the Catch all of LVS (Large volume support) Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 12:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Must be Friday: Mainframe USBs! A 3390 formatted in 4K blocks is about 2.5G. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Nick Laflamme Sent: Friday, March 06, 2009 9:08 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Must be Friday: Mainframe USBs! On 3/6/2009 10:32 AM, Schuh, Richard wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. I've been working with open systems for too long; I can't figure out what that would be in CKD terms. A 3390-243? (Can someone ask at the cluster closing, please?)
Re: Using LBYONLY
Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on to the id. Since they all attempt to control some aspect of the decision whether to accept or reject a log on, they all ought to be considered when evaluating the rules. It would have been more consistent to also say, If you want to keep that user from being logged on unless it is by AUTOLOG, use AUTOONLY. Of course, I prefer the other road to consistency. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Demeritt, Yvonne Sent: Thursday, March 05, 2009 11:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Yep, Dennis is correct. The documentation shows a REJECT LINK and ACCEPT LINK, same command. LOGON and LOGONBY are evaluated separately. What would work is: REJECT * LOGONBY ACCEPT someuser LOGONBY If you want to keep that user from being logged on to unless it is a logonby, use LBYONLY. Yvonne Yvonne DeMeritt CA yvonne.demer...@ca.com From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, March 04, 2009 1:25 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Shimon, What release of VM:Secure are you running? In r2.8 G0808, it definitely doesn't work. I tested before I posted. You're assuming that LOGON and LOGONBY rules are evaluated together to determine the most specific rule. That's not how it works. LOGON rules are evaluated first. If the userid
Estimated speed/duplex values for virtual NICs
I think I know the answer to this, but for confirmation purposes I'm trying to update the OpenSolaris dladm command to report useful values on device speeds and status. Currently it (correctly) reports: # dladm show-dev LINK STATE SPEED DUPLEX osa0 unknown 0Mb unknown osa1 unknown 0Mb unknown osa2 unknown 0Mb unknown since it has absolutely no idea how to retrieve the speed and duplex settings from the hardware. I think duplex should always be full for a VNIC. The question is what to put in as a speed value for a virtual interface, as the Solaris TCP stack does some moderately smart things with packet scheduling if it knows this information. Based on packet delivery being a memory-to-memory operation with diag2a8, I'm leaning toward just inserting an estimated value of 10Gbit/sec per interface for the speed estimate reported by dladm. Does anyone else have a better value or an idea of how to measure this value?
Re: XSTORE
16 TB or better G. I wonder if the USB connector is strong enough to hold a fist? Perhaps something with a cable attachment? Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 3/6/2009 10:32 AM What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, March 06, 2009 8:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE We don't need a thumb drive on the mainframewe need a fist drive on the mainframe. Just something a lot bigger G. Tom Duerbusch THD Consulting Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM If it was dynamic to configure XSTORE one could experiment a bit. Or if the Z11 comes with a USB port that one could plug a thumb drive into and be back to what XSTORE used to be .. I digress we really don't need USB ports on the mainframe. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE That may not be a good thing. The most frequent advice I have heard/seen in that area is to do all MDC to main and only use XSTORE for paging. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ron Schmiedge Sent: Thursday, March 05, 2009 8:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE Hi Mike, Many experts have talked about XSTORE and VM using it for paging. All our defined XSTORE is being used for MDCACHE. It made a noticable difference to I/O performance for our VSE production guest. We could have done it all in regular storage but until a recent processor change, we didn't have much real storage that I wanted to give away. A new-to-us z800 came with a lot more memory than we used to have, so we configured some as XSTORE and MDC took it all. I wish I could claim good planning on our part. Ron On Wed, Mar 4, 2009 at 12:55 PM, Michael Coffin michaelcof...@mccci.com wrote: Hi Folks, What value is there in defining XSTORE these days? Aside from the ability to attach XSTORE to specific virtual machines, wouldn't it be best to just make it all DPA and let CP manage it? Also, assuming you aren't paging much - is attaching XSTORE to a userid going to provide a VERY noticable improvement in performance (at the expense of taking it away from all other virtual machines, of course)? -Mike
Re: XSTORE
You could always use duct tape to secure the usb fist Mace -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, March 06, 2009 1:19 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE 16 TB or better G. I wonder if the USB connector is strong enough to hold a fist? Perhaps something with a cable attachment? Tom Duerbusch THD Consulting Schuh, Richard rsc...@visa.com 3/6/2009 10:32 AM What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Friday, March 06, 2009 8:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE We don't need a thumb drive on the mainframewe need a fist drive on the mainframe. Just something a lot bigger G. Tom Duerbusch THD Consulting Huegel, Thomas thue...@kable.com 3/5/2009 11:02 AM If it was dynamic to configure XSTORE one could experiment a bit. Or if the Z11 comes with a USB port that one could plug a thumb drive into and be back to what XSTORE used to be .. I digress we really don't need USB ports on the mainframe. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]on Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 10:55 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE That may not be a good thing. The most frequent advice I have heard/seen in that area is to do all MDC to main and only use XSTORE for paging. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Ron Schmiedge Sent: Thursday, March 05, 2009 8:03 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE Hi Mike, Many experts have talked about XSTORE and VM using it for paging. All our defined XSTORE is being used for MDCACHE. It made a noticable difference to I/O performance for our VSE production guest. We could have done it all in regular storage but until a recent processor change, we didn't have much real storage that I wanted to give away. A new-to-us z800 came with a lot more memory than we used to have, so we configured some as XSTORE and MDC took it all. I wish I could claim good planning on our part. Ron On Wed, Mar 4, 2009 at 12:55 PM, Michael Coffin michaelcof...@mccci.com wrote: Hi Folks, What value is there in defining XSTORE these days? Aside from the ability to attach XSTORE to specific virtual machines, wouldn't it be best to just make it all DPA and let CP manage it? Also, assuming you aren't paging much - is attaching XSTORE to a userid going to provide a VERY noticable improvement in performance (at the expense of taking it away from all other virtual machines, of course)? -Mike - The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.
Re: Using LBYONLY
You say, They don't and they shouldn't. That is where we have a philosophical difference. And no, I am not trying to tie them together; they are inextricably tied together by use of the same, not a similar or parallel, process. I realize that AUTOLOG is not LOGON followed by DISCONNECT; however the code used to create the virtual machine is the same except for the handling of the console. The difference is only a very small percentage of the code executed in creating the virtual machine. As you say, there is no LOGONBY command. The problem is that somebody chose arbitrarily to make LOGONBY one word while the real command is LOGON with a parameter of BY. You do not use a command LOGONBY, you really do enter a LOGON command. Therefore, ACCEPT userid LOGONBY should be treated as a peer of ACCEPT 1A0 LOGON and ACCEPT ipaddr LOGON. If only BY had never been affixed to LOGON, there never would have been any question and we would not be having this discussion.. Your argument is essentially saying that is how it is, so that is how it should be. I am saying that the implementation is not the standard by which it should be measured. Rather, it is the design. And, in this case, the design is, in my opinion, lacking and why I say that it is inconsistent. If LOGONBY were actually a separate command, I might be more inclined to agree with you. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Friday, March 06, 2009 10:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON should control all forms of logging the user on. After all, the same code is used to create the virtual machine. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Thursday, March 05, 2009 4:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY There's no inconsistency. AUTOLOG and LOGON and two separate commands. The rules covering them are independent of each other. There is no LOGONBY command. The command is LOGON, and a LOGONBY rule just allows a special case of providing the password. If there were a CP LOGONBY command, something like LOGONBY target byuser, then you'd have a point. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Thursday, March 05, 2009 14:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY It seems like there are some inconsistencies: REJECT * LOGON ACCEPT userid LOGONBY Logonby is rejected. REJECT * LOGON ACCEPT userid AUTOLOG (NOPASS An autolog is accepted. It would seem to me that all are rules governing how a logon attempt is to be treated. If it makes sense to reject the LOGONBY, then it also makes sense to reject the AUTOLOG. That is especially true since there is AUTOONLY as a password that can be used to prevent someone from logging on
Re: Using LBYONLY
It's perfectly fine to discuss the way things should be -vs- the way things are, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. An obvious exception has to be made when the way it works now conflicts with some new behavior, that was unanticipated by the original design, but I don't think this is one of those cases. Bob Bolch
Re: Using LBYONLY
Richard, Yes, we have a philosophical difference. I'm not saying that the current design is right just because it's the current design. I'm saying the current design is right because it makes sense. External security managers don't evaluate virtual machine creation, they evaluate commands. AUTOLOG and LOGON are separate commands, and should be treated separately. I agree that LOGONBY rules are a special case, because there's no LOGONBY command. The problem with making LOGON and LOGONBY rules peers is that it complicates conflict resolution. More specific rules take precedence over general rules, but what do you do when the requestor is different for the two types of rules? The requestor for a LOGON rule is a terminal. The requestor for a LOGONBY or AUTOLOG rule is a userid (or member of an ACI group). Consider the following two rules: REJECT 1A0 LOGON ACCEPT RICHARD LOGONBY Both rules are as specific as they can be. One rejects logons from a single terminal. The other accepts logon by a single userid. What happens when someone enters LOGON BY RICHARD from terminal 1A0? Should it be accepted or not? Right now, the answer is clear. The LOGON rule is evaluated first. No one can log on from terminal 1A0. Checking the password or byuser is irrelevant. Under your proposal, the answer is ambiguous. While this simple example could be resolved in code, you can quickly get into a very confusing mess with ACI groups and ranges of terminals. If we treat AUTOLOG and LOGON rules the same, we also get into a wonderful grey area. Should we be able to allow AUTOLOG from a given userid, but not if it's entered on a certain terminal? Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 11:56 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY You say, They don't and they shouldn't. That is where we have a philosophical difference. And no, I am not trying to tie them together; they are inextricably tied together by use of the same, not a similar or parallel, process. I realize that AUTOLOG is not LOGON followed by DISCONNECT; however the code used to create the virtual machine is the same except for the handling of the console. The difference is only a very small percentage of the code executed in creating the virtual machine. As you say, there is no LOGONBY command. The problem is that somebody chose arbitrarily to make LOGONBY one word while the real command is LOGON with a parameter of BY. You do not use a command LOGONBY, you really do enter a LOGON command. Therefore, ACCEPT userid LOGONBY should be treated as a peer of ACCEPT 1A0 LOGON and ACCEPT ipaddr LOGON. If only BY had never been affixed to LOGON, there never would have been any question and we would not be having this discussion.. Your argument is essentially saying that is how it is, so that is how it should be. I am saying that the implementation is not the standard by which it should be measured. Rather, it is the design. And, in this case, the design is, in my opinion, lacking and why I say that it is inconsistent. If LOGONBY were actually a separate command, I might be more inclined to agree with you. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Friday, March 06, 2009 10:31 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY Richard, The problem is your assumption that LOGON rules should control all forms of logging on. They don't and they shouldn't. LOGON and AUTOLOG are two separate commands, controlled by separate rules. You're trying to tie them together. AUTOLOG is not LOGON immediately followed by DISCONNECT, it's a separate command. REJECT * LOGON allows overrides just like other rules. For example: REJECT * LOGON ACCEPT 1A0 LOGON ACCEPT 192.168.*.* (IPADDR allows logons only from real device 1A0 and any IP address in the 192.168.0.0-192.168.255.255 range. Dennis O'Brien 39,556 From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard Sent: Friday, March 06, 2009 09:47 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Using LBYONLY Ah, but I do have a point. The REJECT * LOGON does not allow the same type of override that is allowed by other rules. In this, there is inconsistency. Actually, I have two points. The second is that, if LOGON is viewed as a process that is being controlled by the rule, then REJECT * LOGON
Re: Using LBYONLY
Not if you add function. Let it work both ways. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bolch Sent: Friday, March 06, 2009 12:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using LBYONLY It's perfectly fine to discuss the way things should be -vs- the way things are, but when a design is more than 20 years old, as in this case, then the way it works now is, by definition, the way it should be. Making some changes is just too painful. An obvious exception has to be made when the way it works now conflicts with some new behavior, that was unanticipated by the original design, but I don't think this is one of those cases. Bob Bolch
Another VMLINK Question
How can I get VMLINK to return the filemode assigned. I tried the following and it obviously doesn't work, any direction is appreciated. TIA. EXEC vmlink .dir VMSYSU:VSEMAINT.TOPSECRET * b-z forcerw (.msg STEM .FM1 Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Another VMLINK Question
EXEC VMLINK * 197 (PUSH .FM STEM mode = word(vmlink.1,words(vmlink.1)) -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: March 6, 2009 16:54 To: IBMVM@LISTSERV.UARK.EDU Subject: Another VMLINK Question How can I get VMLINK to return the filemode assigned. I tried the following and it obviously doesn't work, any direction is appreciated. TIA. EXEC vmlink .dir VMSYSU:VSEMAINT.TOPSECRET * b-z forcerw (.msg STEM .FM1 Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner.
Re: Another VMLINK Question
Thank you! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of peter.w...@ttc.ca Sent: Friday, March 06, 2009 3:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Another VMLINK Question EXEC VMLINK * 197 (PUSH .FM STEM mode = word(vmlink.1,words(vmlink.1)) -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Wandschneider, Scott Sent: March 6, 2009 16:54 To: IBMVM@LISTSERV.UARK.EDU Subject: Another VMLINK Question How can I get VMLINK to return the filemode assigned. I tried the following and it obviously doesn't work, any direction is appreciated. TIA. EXEC vmlink .dir VMSYSU:VSEMAINT.TOPSECRET * b-z forcerw (.msg STEM .FM1 Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review retransmission dissemination or other use of or taking any action in reliance upon this information by persons or entities other than the intended recipient or delegate is strictly prohibited. If you received this in error please contact the sender and delete the material from any computer. The integrity and security of this message cannot be guaranteed on the Internet. The sender accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of information provided. The recipient should check this e-mail and any attachments for the presence of viruses. The sender accepts no liability for any damage caused by any virus transmitted by this e-mail. This disclaimer is property of the TTC and must not be altered or circumvented in any manner. Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: XSTORE
Schuh, Richard wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. Regards, Richard Schuh I have one that is 1000GB. Thats very close to a TB. :) Mine is bigger than yours. :) -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: XSTORE
I didn't say that I had one that was 64GB, I don't even come close. So yours is wy bigger. :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Stephen Frazier Sent: Friday, March 06, 2009 3:20 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: XSTORE Schuh, Richard wrote: What size does it have to be to become a fist? There are USB flash memory drives that are at least 64GB. Regards, Richard Schuh I have one that is 1000GB. Thats very close to a TB. :) Mine is bigger than yours. :) -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: fcp disk under SUSE9
We use FCP with SLES 9 all the time. Is your disk on two paths? If so, then you also need to have MPIO installed and running. (multipathd and boot.multipath) You ran mkinitrd and zipl, but did you notice if they were successful? Is /boot on its own disk? Is it mounted RW? Is the underlying minidisk RW? You said that you have to define the vol group manually. That's how we always do it: pvcreate, vgcreate (or vgextend), and lvcreate (or lvextend). I recommend that you NOT partition a SAN volume intended to be used as a PV. (ie: pvcreate /dev/sda instead of pvcreate /dev/sda1) But I don't think that is your problem. More inclined to think there is a hardware problem, but how then does SLES 10 cope? I hope this helps. On 3/6/09, Robert J McCarthy bob.mccar...@custserv.com wrote: We are attempting to use zfcp scsi devices with SuSE 9 sp4 (linux on z) We place a 10gb lun into a volume group. We have to manually create the volume groups since yast is not working for SUSE 9 (known issue) Once this procedue is completed, the disk is recognized and can be used for read/write operation. The mount is placed in fstab. After we reboot the machine nothing comes back (We perform mkintrd and zipl). We can manually re-define the volume group and the system will recognize it again. There are occasions when the data is corrupted. Has anyone run into issues attaching fcp disk to a volume group with SUSE 9 ? We have had no problems utilizing fcp disk with SUSE 10. -- Sent from Gmail for mobile | mobile.google.com -- R; Q: Isn't filtering stupidity elitist? A: Yes. Yes, it is. That's sort of the whole point. -- Ortiz and Starr
Re: Another VMLINK Question
Scott -- As you're clearly coding something you may like to know, if you don't already, that if you use cms pipelines to process files residing in an sfs directory you don't need to bother to access it - PIPE will read it fine just given the directory and filename. i -- Original Message -- Received: Fri, 06 Mar 2009 04:54:48 PM COT From: Wandschneider, Scott scott.wandschnei...@infocrossing.com To: IBMVM@LISTSERV.UARK.EDU Subject: Another VMLINK Question How can I get VMLINK to return the filemode assigned. I tried the following and it obviously doesn't work, any direction is appreciated. TIA. EXEC vmlink .dir VMSYSU:VSEMAINT.TOPSECRET * b-z forcerw (.msg STEM .FM1 Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or Protected Health Information, within the meaning of the regulations under the Health Insurance Portability Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Service - Where did it come from
RSU's do not remove PTF's that are not included in them, But What you are looking for is the command VMFINFO you can use this command to interrogate the PTF's on the current system and their current status From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bates Sent: Friday, March 06, 2009 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Service - Where did it come from A question was posed to me recently that I couldn't think of a way to answer. We have been running through some testing on a system and applying a lot of PTFs to resolve issues. Then, along comes RSU 802 and it is put on. We roll 802 out to the other LPARs and then comes the question: Which PTFs are missing from the other systems? Or, what PTFs that we put on the first LPAR to solve problems were not included on the 802 RSU? I couldn't come up with a quick and easy answer. So my question is: Is there a way to list the PTFs on a system so that it says where they came from? Perhaps a file that has all the PTFs on the system that could be compared to a TOC of the RSU (PIPE collate comes to mind)? Bob Bates Enterprise Hosting Services w. (469)892-6660 c. (214) 907-5071 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.
ts1120 e05 encryption z/VM transparent guest support for z/VSE
Greetings, Looking for validation of required maintenance to support TS1120 E05 encryption in IBM 3584 library for z/VSE 4.1.x. In customer environment, the encryption will be done from z/VSE. In the disaster recovery environment, z/VSE 4.1.x will be recovered as a guest under z/VM 5.3.0. IBM Systems Storage tape encryption solutions redbook states that PTF for APAR VM64062 is required for DFSMS/VM support for z/VSE guests. Please confirm if this apar is required for DR environment. The production environment is z/VSE native, no z/VM. Thanks in advance. Michele Lewandowski Marek Sr. Systems Engineer SunGard Availability Services (630) 250-5021 (phone) michele.ma...@sungard.com __ Keeping People and Information Connected® http://www.availability.sungard.com CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you received this e-mail in error, please notify the sender and delete this e-mail from your system.
Re: Service - Where did it come from
VMFINFO is panel driven, not suited when wanting to compare a lot of fixes. There is also a VMSES command to compare two repositories, (VMFxxx COMPTBL?) it is used (I guess) by VMFPSU (the command one uses in the RSU process) to see what you'll get and what needs to be reapplied. But, for this case, I'd go for a simple PIPE and compare the apply list (on the delta disk) or some other control file found on the apply disk. I'd have the result in less than the time it takes to study the syntax/parameters for the VMSES command. 2009/3/6 Davis, Larry larry.davis.consult...@nielsen.com RSU's do not remove PTF's that are not included in them, But What you are looking for is the command VMFINFO you can use this command to interrogate the PTF's on the current system and their current status From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bates Sent: Friday, March 06, 2009 10:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Service - Where did it come from A question was posed to me recently that I couldn't think of a way to answer. We have been running through some testing on a system and applying a lot of PTFs to resolve issues. Then, along comes RSU 802 and it is put on. We roll 802 out to the other LPARs and then comes the question: Which PTFs are missing from the other systems? Or, what PTFs that we put on the first LPAR to solve problems were not included on the 802 RSU? I couldn't come up with a quick and easy answer. So my question is: Is there a way to list the PTFs on a system so that it says where they came from? Perhaps a file that has all the PTFs on the system that could be compared to a TOC of the RSU (PIPE collate comes to mind)? Bob Bates Enterprise Hosting Services w. (469)892-6660 c. (214) 907-5071 “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. -- Kris Buelens, IBM Belgium, VM customer support
