Re: Ops privs (was Re: MAINTENANCE)
TCPIP does FORCE and AUTOLOG/XAUTOLOG users Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/23/2007 06:39 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Ops privs (was Re: MAINTENANCE) True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
On Friday, 08/24/2007 at 07:44 EDT, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Thank you to all who have responded. Let's hope, that IBM will either put labels on future installation cartridges or make it possible to mount unlabeled cartridges on the 3584 library. What did the z/VSE Support Center say when you asked them? I can tell you that z/VM does not ship SL tapes and so would not have a volser machine-readable external label. According to the brochure for 3592s, the barcode label is required to load the tape in an IBM tape library. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs (was Re: MAINTENANCE)
In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? :-) Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, August 24, 2007 5:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) TCPIP does FORCE and AUTOLOG/XAUTOLOG users Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/23/2007 06:39 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Ops privs (was Re: MAINTENANCE) True enough; however, I fear trusting anyone enough to include class A in their directory privileges. We have very few Class C users. While on the subject of privilege classes, why does TCPIP hqve class A? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Thursday, August 23, 2007 3:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) On Thursday, 08/23/2007 at 01:06 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: You do if you are adding a priv that is not in your directory entry. Most of us live in fear of the class A privileges, so we do not include it in our entries. Without either C or A, you cannot add A (or C, for that matter). If you have class C, then you have all classes at your disposal, regardless of what's in the directory. If, however, you define your userid with the maximum privs and then *take away* privs you do not normally require (see prior post), then you do not need class C. When you decide you need class A, just SET PRIV * +A. When done, SET PRIV * -A. The concept of least privilege should be applied. Alan Altmark z/VM Development IBM Endicott
zVM 5.2 TCPIP problem
Yesterday, we started getting the following error messages from the TCPIP stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 AT 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Is there a limit on LDSF devices? What is an LDSF device? Is this the same as the LDEV devices? We use the SCEXIT to do a dial vtam to a bunch of VTAM NON-SNA controller defines. This allows us access to the SNA network. Our user base has been scaling up recently. We are at new high water marks. It looks like we have enough controllers defined to VTAM. It looks like we have enough specials to cover the controllers. So it looks to me that VTAM or the Directory, isn't part of this problem. In the TCPIP log, I don't see any warnings about running out of storage. VM TCP/IP Netstat Level 520 TCPIP Free pool status: ObjectNo. allocNo. freeLo-water Permit size === === ACB10241013 979 102 CCB 158 139 13715 Dat buf 160 157 14616 Sm dat buf 300 98 9330 Tiny dat buf 10 9 7 1 Env 751 751 73875 Lrg env 50 49 47 5 RCB 51 51 51 5 SCB 264 258 25126 SKCB256 255 25425 TCB 256 52 5025 UCB 102 102 10210 Add Xlate 151215121512 5 NCB150115011501 5 IP Route625 601 601 6 IPv6 Route 619 619 619 6 Segment ACK512051205104 512 FPSP total locked pages: 392, Unused locked pages: 113 FPSP allocation threshold: 2200, Low-water mark: 0 z/VM Version 5 Release 2.0, service level 0602 (64-bit) Generated at 09/18/2006 18:39:52 CDT Anyway, I'm looking for direction on what to look for to solve this issue. Thanks Tom Duerbusch THD Consulting
Re: zVM 5.2 TCPIP problem
LDSF is Logical Device Support Facility. The default maximum number of logical devices for the system 4096. Use SET MAXLDEV to change it. See CP Programming Services for more information (Appendix E is a good place to start). Brian NIelsen On Fri, 24 Aug 2007 11:01:09 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: Yesterday, we started getting the following error messages from the TCPI P stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 A T 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Is there a limit on LDSF devices? What is an LDSF device? Is this the same as the LDEV devices? We use the SCEXIT to do a dial vtam to a bunch of VTAM NON-SNA controller defines. This allows us access to the SNA network. Our user base has been scaling up recently. We are at new high water marks. It looks like we have enough controllers defined to VTAM. It looks like we have enough specials to cover the controllers. So it looks to me that VTAM or the Directory, isn't part of this problem . In the TCPIP log, I don't see any warnings about running out of storage. VM TCP/IP Netstat Level 520 TCPIP Free pool status: ObjectNo. allocNo. freeLo-water Permit size === == = ACB10241013 979 102 CCB 158 139 13715 Dat buf 160 157 14616 Sm dat buf 300 98 9330 Tiny dat buf 10 9 7 1 Env 751 751 73875 Lrg env 50 49 47 5 RCB 51 51 51 5 SCB 264 258 25126 SKCB256 255 25425 TCB 256 52 5025 UCB 102 102 10210 Add Xlate 151215121512 5 NCB150115011501 5 IP Route625 601 601 6 IPv6 Route 619 619 619 6 Segment ACK512051205104 512 FPSP total locked pages: 392, Unused locked pages: 113 FPSP allocation threshold: 2200, Low-water mark: 0 z/VM Version 5 Release 2.0, service level 0602 (64-bit) Generated at 09/18/2006 18:39:52 CDT Anyway, I'm looking for direction on what to look for to solve this issu e. Thanks Tom Duerbusch THD Consulting
Re: Ops privs
On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts?
Re: zVM 5.2 TCPIP problem
Thanks Brian LDSF is a new name for LDEVI guess it's an upgrade G. And we do have maxldev set to 4096 and we are no where near that many, I think. Doing a query ldev l001-lfff shows we are well under the 4096 mark. But kind of interesting reading the output. Tom Duerbusch THD Consulting Brian Nielsen [EMAIL PROTECTED] 8/24/2007 11:26 AM LDSF is Logical Device Support Facility. The default maximum number of logical devices for the system 4096. Use SET MAXLDEV to change it. See CP Programming Services for more information (Appendix E is a good place to start). Brian NIelsen On Fri, 24 Aug 2007 11:01:09 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: Yesterday, we started getting the following error messages from the TCPIP stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 AT 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Is there a limit on LDSF devices? What is an LDSF device? Is this the same as the LDEV devices? We use the SCEXIT to do a dial vtam to a bunch of VTAM NON-SNA controller defines. This allows us access to the SNA network. Our user base has been scaling up recently. We are at new high water marks. It looks like we have enough controllers defined to VTAM. It looks like we have enough specials to cover the controllers. So it looks to me that VTAM or the Directory, isn't part of this problem. In the TCPIP log, I don't see any warnings about running out of storage. VM TCP/IP Netstat Level 520 TCPIP Free pool status: ObjectNo. allocNo. freeLo-water Permit size === === ACB10241013 979 102 CCB 158 139 13715 Dat buf 160 157 14616 Sm dat buf 300 98 9330 Tiny dat buf 10 9 7 1 Env 751 751 73875 Lrg env 50 49 47 5 RCB 51 51 51 5 SCB 264 258 25126 SKCB256 255 25425 TCB 256 52 5025 UCB 102 102 10210 Add Xlate 151215121512 5 NCB150115011501 5 IP Route625 601 601 6 IPv6 Route 619 619 619 6 Segment ACK512051205104 512 FPSP total locked pages: 392, Unused locked pages: 113 FPSP allocation threshold: 2200, Low-water mark: 0 z/VM Version 5 Release 2.0, service level 0602 (64-bit) Generated at 09/18/2006 18:39:52 CDT Anyway, I'm looking for direction on what to look for to solve this issue. Thanks Tom Duerbusch THD Consulting
Re: Ops privs (was Re: MAINTENANCE)
We have a class V that allows class B queries. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Nick Laflamme Sent: Friday, August 24, 2007 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Does anyone else define a class that has all of the QUERYs and other output only classes? I run with class GU on my personal userid -- I can look to make sure all is well, but to actually fix anything (or break it worse), I need to get on something like MAINT. Nick Schuh, Richard wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us?
Re: zVM 5.2 TCPIP problem
On Friday, 08/24/2007 at 12:03 EDT, Tom Duerbusch [EMAIL PROTECTED] wrote: Yesterday, we started getting the following error messages from the TCPIP stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 AT 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Tom, please submit a Reader's Comment Form (details in the book) so that we can improve the message to reference SET MAXLDEV. (That command didn't exist when TCP/IP was born!) Alan Altmark z/VM Development IBM Endicott
TCP/IP problem with two z/VM systems
We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice OSAVM1: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0100 01:23:44 DTCQDI001I QDIO device OSAVM1 device number 0102: 01:23:44 DTCQDI007I Disable for QDIO data transfers Another z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice [EMAIL PROTECTED]: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0200 01:23:44 DTCQDI001I QDIO device [EMAIL PROTECTED] device number 0202: 01:23:44 DTCQDI007I Disable for QDIO data transfers We have had IBM replace the OSA for CHPID 01. Where do we look now ? Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] www.serena.com http://www.serena.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: TCP/IP problem with two z/VM systems
Is anything happening to z/OS? Is all of this on one card (with two ports)? Is someone messing around with the switch or hub that these are plugged in to? Is it on flaky power or something? Daniel Allen wrote: We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice OSAVM1: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0100 01:23:44 DTCQDI001I QDIO device OSAVM1 device number 0102: 01:23:44 DTCQDI007I Disable for QDIO data transfers Another z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0200 01:23:44 DTCQDI001I QDIO device [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] device number 0202: 01:23:44 DTCQDI007I Disable for QDIO data transfers We have had IBM replace the OSA for CHPID 01. Where do we look now ? Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Serena Software, Inc. www.serena.com http://www.serena.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: TCP/IP problem with two z/VM systems
Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106. We moved VM02 to use 200-202. We also moved a new cable from port 21 to port 15 on the hub/switch. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Friday, August 24, 2007 11:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Is anything happening to z/OS? Is all of this on one card (with two ports)? Is someone messing around with the switch or hub that these are plugged in to? Is it on flaky power or something? Daniel Allen wrote: We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice OSAVM1: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0100 01:23:44 DTCQDI001I QDIO device OSAVM1 device number 0102: 01:23:44 DTCQDI007I Disable for QDIO data transfers Another z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0200 01:23:44 DTCQDI001I QDIO device [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] device number 0202: 01:23:44 DTCQDI007I Disable for QDIO data transfers We have had IBM replace the OSA for CHPID 01. Where do we look now ? Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Serena Software, Inc. www.serena.com http://www.serena.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ** -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: zVM 5.2 TCPIP problem
My memory may be fuzzy, but I seem to recall a TCPIP parameter that defined the LDEV range that TCPIP will use. Although I've slept a few times (and drank a lot of beer) since then. Tom Duerbusch [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/24/2007 01:41 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: zVM 5.2 TCPIP problem Hi Alan I take it that you believe that we hit the default 4096 mark. That's very interesting. Anyway, I did submit a reader comment form via email. Tom Duerbusch THD Consulting Alan Altmark [EMAIL PROTECTED] 8/24/2007 12:00 PM On Friday, 08/24/2007 at 12:03 EDT, Tom Duerbusch [EMAIL PROTECTED] wrote: Yesterday, we started getting the following error messages from the TCPIP stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 AT 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Tom, please submit a Reader's Comment Form (details in the book) so that we can improve the message to reference SET MAXLDEV. (That command didn't exist when TCP/IP was born!) Alan Altmark z/VM Development IBM Endicott
Re: zVM 5.2 TCPIP problem
On Fri, 24 Aug 2007 11:56:28 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: Thanks Brian LDSF is a new name for LDEVI guess it's an upgrade G. I wrote a program in 1985 called LDSF which used DIAG 7C to create logica l devices. So it's certainly not a recent upgrade. :) Brian Nielsen
Re: OSA question
Unless things have changed, each OSA triplet has to start on an even real address, but the real addresses don't have to be consecutive. Here's how we arrange ours. This setup pre-dates Guest LAN and Virtual Switch. Virtual Machine Real Virtual GUEST1 100100 GUEST1 101101 GUEST1 10A102 GUEST2 102100 GUEST2 103101 GUEST2 10B102 GUEST3 104100 GUEST3 105101 GUEST3 10C102 GUEST4 106100 GUEST4 107101 GUEST4 10D102 GUEST5 108100 GUEST5 109101 GUEST5 10E102 Dennis O'Brien I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. -- Mitch Hedberg From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Thursday, August 23, 2007 16:07 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA question Can z/VM and a guest operating system (z/OS) share the same OSA addresses ? z/VM uses 100,101 and 102. Can z/OS use 100,101 and 103 ? Or does z/OS need to use 103, 104 and 105 ? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Ops privs
Indeed, if can can logon to it one can do these things anyhow, only a bit less flexible. And, to complete the list: the authorized user should also be able to work with the spool files of the. We had to code some VMOPER commands to make this possible. 2007/8/24, Alan Altmark [EMAIL PROTECTED]: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs (was Re: MAINTENANCE)
We have class Q for non-classs G QUERY and INDICATE. 2007/8/24, Schuh, Richard [EMAIL PROTECTED]: We have a class V that allows class B queries. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Nick Laflamme Sent: Friday, August 24, 2007 10:25 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs (was Re: MAINTENANCE) Fortunately, IBM makes it easy for us to define new command classes so we can do it our way. If I were feeling demanding, I might whine about IBM (and other vendors) listing command classes they want instead of commands (and DIAGs) they want, but I'm not, so :-) Does anyone else define a class that has all of the QUERYs and other output only classes? I run with class GU on my personal userid -- I can look to make sure all is well, but to actually fix anything (or break it worse), I need to get on something like MAINT. Nick Schuh, Richard wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do other users? Who knows what information it is shipping to Chuckie unbeknownst to us? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Brian Nielsen On Fri, 24 Aug 2007 12:54:22 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do oth er users? Who knows what information it is shipping to Chuckie unbeknownst to us ? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user shou ld implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? =
Re: TCP/IP problem with two z/VM systems
Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you allowed to?) here is my output. netstat devlink VM TCP/IP Netstat Level 430 Device OSDD20Type: OSD Status: Ready Queue size: 0Address: 0D20 Port name: P140 Router Type: NonRouter Link GBED20 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106. We moved VM02 to use 200-202. We also moved a new cable from port 21 to port 15 on the hub/switch. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Friday, August 24, 2007 11:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Is anything happening to z/OS? Is all of this on one card (with two ports)? Is someone messing around with the switch or hub that these are plugged in to? Is it on flaky power or something? Daniel Allen wrote: We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice OSAVM1: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0100 01:23:44 DTCQDI001I QDIO device OSAVM1 device number 0102: 01:23:44 DTCQDI007I Disable for QDIO data transfers Another z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received adapter-initiated Stop Lan * 08/24/07 * 01:23:44 DTCOSD082E OSD shutting down: 01:23:44 DTCPRI385IDevice [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 01:23:44 DTCPRI386I Type: OSD, Status: Ready 01:23:44 DTCPRI387I Envelope queue size: 0 01:23:44 DTCPRI388I Address: 0200 01:23:44 DTCQDI001I QDIO device [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] device number 0202: 01:23:44 DTCQDI007I Disable for QDIO data transfers We have had IBM replace the OSA for CHPID 01. Where do we look now ? Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Serena Software, Inc. www.serena.com http://www.serena.com/ ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: zVM 5.2 TCPIP problem
And THAT's a winner! I couldn't tie any of the numbers I've seen together to make any sense. I forgot that a couple months ago, we had to put some 30 users directly on TUBES (a session manager). We did this by having them dial tubes. So when I was counting VTAM sessions, we seemed to fail on a weird, odd, number. But when I add in a rough number of tubes sessions, I do, indeed, come very close to the LDEVRANGE parm in my config file. That is much easier to fix, then trying to figure out how we were generating a few thousand extra LDEV sessions in order for us to hit the MAXLDEV parm. Time to revise my Reader Comment Form, I already sent in... Tom Duerbusch THD Consulting [EMAIL PROTECTED] 8/24/2007 12:46 PM My memory may be fuzzy, but I seem to recall a TCPIP parameter that defined the LDEV range that TCPIP will use. Although I've slept a few times (and drank a lot of beer) since then. Tom Duerbusch [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/24/2007 01:41 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: zVM 5.2 TCPIP problem Hi Alan I take it that you believe that we hit the default 4096 mark. That's very interesting. Anyway, I did submit a reader comment form via email. Tom Duerbusch THD Consulting Alan Altmark [EMAIL PROTECTED] 8/24/2007 12:00 PM On Friday, 08/24/2007 at 12:03 EDT, Tom Duerbusch [EMAIL PROTECTED] wrote: Yesterday, we started getting the following error messages from the TCPIP stack: 11:12:25 DTCSTM259E CONN 237: LDSFINITIATE RETURNED TRYING TO USE LDSF FOR TOO MANY DEVICES. 11:12:25 DTCSTM163I TELNET SERVER: CONN 238:CONNECTION OPENED 08/23/07 AT 11:12:25 11:12:25 DTCPRC150IFOREIGN INTERNET ADDRESS AND PORT: NET ADDRESS = 205.235.239.50, PORT= 1163 The first error message DTCSTM258E, when looked up, doesn't give much of a reason. Tom, please submit a Reader's Comment Form (details in the book) so that we can improve the message to reference SET MAXLDEV. (That command didn't exist when TCP/IP was born!) Alan Altmark z/VM Development IBM Endicott
Re: TCP/IP problem with two z/VM systems
Hello Daniel, Has this been happening for some time or is it a new occurrence? We are on z890 and are getting ready to apply concurrent microcode updates. We will have to offline/online each OSA card to get the full updates. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you allowed to?) here is my output. netstat devlink VM TCP/IP Netstat Level 430 Device OSDD20Type: OSD Status: Ready Queue size: 0Address: 0D20 Port name: P140 Router Type: NonRouter Link GBED20 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106. We moved VM02 to use 200-202. We also moved a new cable from port 21 to port 15 on the hub/switch. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Friday, August 24, 2007 11:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Is anything happening to z/OS? Is all of this on one card (with two ports)? Is someone messing around with the switch or hub that these are plugged in to? Is it on flaky power or something? Daniel Allen wrote: We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44
Re: TCP/IP problem with two z/VM systems
Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you allowed to?) here is my output. netstat devlink VM TCP/IP Netstat Level 430 Device OSDD20Type: OSD Status: Ready Queue size: 0Address: 0D20 Port name: P140 Router Type: NonRouter Link GBED20 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106. We moved VM02 to use 200-202. We also moved a new cable from port 21 to port 15 on the hub/switch. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Friday, August 24, 2007 11:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Is anything happening to z/OS? Is all of this on one card (with two ports)? Is someone messing around with the switch or hub that these are plugged in to? Is it on flaky power or something? Daniel Allen wrote: We are experiencing a TCP/IP with two z/VM systems. Background: One z/VM system using OSA 100-102. One z/OS guest using OSA 104-106. Another z/VM system using OSA 200-202. One z/VM system TCPIP machine dies with the following: * 08/24/07 * 01:23:44 DTCOSD309W Received
Re: Ops privs
I think you didn't understand: when a user is aythorized to LOGONBY VMGUEST1, then -as class G user- he should alos be authorized to XAUTOLOG/FORCE of the VMGUEST1 userid. 2007/8/24, Brian Nielsen [EMAIL PROTECTED]: I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Brian Nielsen On Fri, 24 Aug 2007 12:54:22 -0400, Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 11:54 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: In that case, FORCE and XAUTOLOG should be in a class that does not include SHUTDOWN. After all, why should we trust TCPIP any more than we do oth er users? Who knows what information it is shipping to Chuckie unbeknownst to us ? C says: no no no. it's fine. really. trust me. (heh heh) There are some who believe that the authority to LOGON BY to a user shou ld implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? = -- Kris Buelens, IBM Belgium, VM customer support
Re: TCP/IP problem with two z/VM systems
It has been happening since June/July timeframe. No maintenance (z/VM (4.3 or 5.2) or OS/390) has been put on. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel, Has this been happening for some time or is it a new occurrence? We are on z890 and are getting ready to apply concurrent microcode updates. We will have to offline/online each OSA card to get the full updates. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you allowed to?) here is my output. netstat devlink VM TCP/IP Netstat Level 430 Device OSDD20Type: OSD Status: Ready Queue size: 0Address: 0D20 Port name: P140 Router Type: NonRouter Link GBED20 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106. We moved VM02 to use 200-202. We also moved a new cable from port 21 to port 15 on the hub/switch. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Smrcina Sent: Friday, August 24, 2007 11:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Is anything happening to
Re: Ops privs
On Friday, 08/24/2007 at 02:49 EDT, Brian Nielsen [EMAIL PROTECTED] wrote: I don't think that's a good idea. Class G users can be given LOGONBY to another class G user for a variety of reasons. Neither userid should get other than class G just because of the LOGONBY authorization. Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? That gives two general classes of action: - manage the guest (start, stop) - BE the guest (start, stop, see, do) Alan Altmark z/VM Development IBM Endicott
Re: OSA question
We use this layout for z/VM, z/OS, Linux, and TPF guests. Some of the z/OS guests are in sysplexes. It doesn't matter. The point is that everyone gets virtual 100, 101, and 102, no matter what the real addresses are, and that each triplet starts on an even real address. If you have more than 5 virtual machines that need OSA access, the pattern continues with real 110, 111, and 11A dedicated as virtual 100, 101, and 102, and so on. Everyone can have the same virtual addresses, but the only way to share real OSA addresses is with a guest LAN or virtual switch. Dennis O'Brien I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. -- Mitch Hedberg From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 12:42 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] OSA question Can I assume that these guests are OS/390 or z/OS guests not running in a SYSPLEX ? From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Friday, August 24, 2007 11:56 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: OSA question Unless things have changed, each OSA triplet has to start on an even real address, but the real addresses don't have to be consecutive. Here's how we arrange ours. This setup pre-dates Guest LAN and Virtual Switch. Virtual Machine Real Virtual GUEST1 100100 GUEST1 101101 GUEST1 10A102 GUEST2 102100 GUEST2 103101 GUEST2 10B102 GUEST3 104100 GUEST3 105101 GUEST3 10C102 GUEST4 106100 GUEST4 107101 GUEST4 10D102 GUEST5 108100 GUEST5 109101 GUEST5 10E102 Dennis O'Brien I don't have a girlfriend. I just know a girl who would get really mad if she heard me say that. -- Mitch Hedberg From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Thursday, August 23, 2007 16:07 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] OSA question Can z/VM and a guest operating system (z/OS) share the same OSA addresses ? z/VM uses 100,101 and 102. Can z/OS use 100,101 and 103 ? Or does z/OS need to use 103, 104 and 105 ? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. **
Re: Ops privs
No. No. No. No. No. We use LOGONBY as a means of controlling who is allowed to log on to group ids and tracking what they do. None of those other commands would be useful or necessary in that context. Giving those permissions would negate, or at least complicate, our ability to track who did what when. Further, we would not want one user to be able to alter or compromise the functions being performed by another who was already logged on via LOGONBY. SEND, FORCE, and SIGNAL SHUTDOWN certainly have that potential, for example. Most of what is listed could be useful only to someone who is really knowledgeable about the functions of the virtual machine. They are also mostly useful in looking after service machines. They are not useful to someone who is a more naïve user who logs on to a group id to perform simple functions or to run an application program, and could be somewhat dangerous if abused, accidentally or on purpose, by such a person. It is the latter group that we must protect against by not giving them authorities that they will never need. The former group probably has the knowledge needed to function without the added authority. Regards, Richard Schuh There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: zVM 5.2 TCPIP problem
Maybe to some of us, that is as recent as we can remember :-) After all, it is the short term memory that goes first. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Brian Nielsen Sent: Friday, August 24, 2007 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: zVM 5.2 TCPIP problem On Fri, 24 Aug 2007 11:56:28 -0500, Tom Duerbusch [EMAIL PROTECTED] wrote: Thanks Brian LDSF is a new name for LDEVI guess it's an upgrade G. I wrote a program in 1985 called LDSF which used DIAG 7C to create logica= l devices. So it's certainly not a recent upgrade. :) Brian Nielsen
Re: Ops privs
On Fri, 24 Aug 2007, Alan Altmark wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? And maybe FOR, in 5.3. At my current job, we create LOGONBY profiles out of laziness - small group, development shop, most of us log onto multiple ids every day, so no one has to remember (or change) any password but their own. In this environment, there would be no issue with bundling all of that with LOGONBY. At my last job (security weasel for a RBC), surrogate facilities like LOGONBY were mostly used to solve the problem of how to provide accountable access by multiple people to a shared security principle (userid) for administration or maintenance, with convenience way down the priority list. Frequently, there was an implied serialization of the resource, too. There, we wouldn't have wanted to see something like this because it would have made collisions less likely to be detected before something bad happened, and auditing more complex if it did. The logic of but they could do it anyway if they can log onto the user is hard to argue against. The question is whether there is really any difference that matters, other than maybe the serialization thing, between doing something while logged on as a user and doing more or less the same thing as or to that user while loggged on as a different user. Steve -- Steve Marak -- [EMAIL PROTECTED]
Re: Ops privs
I like the idea that XAUTLOG authority can me taken as authority to do al l of the Start/Stop functions for that target user and then LOGONBY be take n as complete authority to be that target user. So I could give a server authority (via XAUTOLOG in target users' directories) to XAUTOLOG, FORCE, SIGNAL SHUTDOWN, but not be able to transfer spool files owned by the tar get users or to modify (via SEND) the configuration of the target server. I could reserve for an administrator (via LOGONBY in target users' directories) the authority to manipulate the spool files and machine configuration. I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementat ion. /Tom Kern /301-903-2211 On Fri, 24 Aug 2007 15:52:55 -0400, Alan Altmark [EMAIL PROTECTED] wrote: Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? That gives two general classes of action: - manage the guest (start, stop) - BE the guest (start, stop, see, do) Alan Altmark z/VM Development IBM Endicott
Re: TCP/IP problem with two z/VM systems
Has the IBM CE done any microcode updates? Seems I remember that Alcoa in Cuyahoga Falls having a z890/OSA drop problem. I can check with our IBM CE. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems It has been happening since June/July timeframe. No maintenance (z/VM (4.3 or 5.2) or OS/390) has been put on. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel, Has this been happening for some time or is it a new occurrence? We are on z890 and are getting ready to apply concurrent microcode updates. We will have to offline/online each OSA card to get the full updates. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you allowed to?) here is my output. netstat devlink VM TCP/IP Netstat Level 430 Device OSDD20Type: OSD Status: Ready Queue size: 0Address: 0D20 Port name: P140 Router Type: NonRouter Link GBED20 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 2:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Our z/OS guest is actually a OS/390 2.10 system. When I force/xautolog TCPIP on VM01, the OS/390 2.10 system works. When this problem first started, we had VM01 using 100-102, VM02 using 103-105 and OS/390 2.10 using 104-106.
Re: TCP/IP problem with two z/VM systems
Did this start after the OSA replacement? If it did, that is where I would start looking. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 4:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Before the CE replaced the OSA, he upgraded the microcode. We are running on Z9BC. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Has the IBM CE done any microcode updates? Seems I remember that Alcoa in Cuyahoga Falls having a z890/OSA drop problem. I can check with our IBM CE. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems It has been happening since June/July timeframe. No maintenance (z/VM (4.3 or 5.2) or OS/390) has been put on. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel, Has this been happening for some time or is it a new occurrence? We are on z890 and are getting ready to apply concurrent microcode updates. We will have to offline/online each OSA card to get the full updates. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or equivalent) could be shutdown and a Stoplan instruction would be issued to the device. When I shutdown TCPIP using a logical device on an OSA-2 card, it would shutdown that card, therefore we had to code the STOPLAN=NO on all devices in the VSE systems. It seems that something is issuing a STOPLAN instruction to both of your z/VM system cards. Would you do a NETSTAT DEVLINK on your z/VM systems and send the output here? (Are you
Re: TCP/IP problem with two z/VM systems
It started before the OSA replacement and the microcode upgrade. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 1:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Did this start after the OSA replacement? If it did, that is where I would start looking. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 4:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Before the CE replaced the OSA, he upgraded the microcode. We are running on Z9BC. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 1:33 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Has the IBM CE done any microcode updates? Seems I remember that Alcoa in Cuyahoga Falls having a z890/OSA drop problem. I can check with our IBM CE. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems It has been happening since June/July timeframe. No maintenance (z/VM (4.3 or 5.2) or OS/390) has been put on. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel, Has this been happening for some time or is it a new occurrence? We are on z890 and are getting ready to apply concurrent microcode updates. We will have to offline/online each OSA card to get the full updates. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Allen Sent: Friday, August 24, 2007 3:18 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router Type: NonRouter Link OSA100 Type: QDIOETHERNET Net number: 0 Broadcast Capability: Yes Multicast Capability: Yes GroupMembers ---- 224.0.0.1 1 Here is VM02: VM TCP/IP Netstat Level 520 Device [EMAIL PROTECTED]Type: OSDStatus: Ready Queue size: 0 CPU: 0 Address: 0200Port name: PORTVM2 IPv4 Router Type: PrimaryArp Query Support: Yes Link OSAVM2Type: QDIOETHERNET Net number: 0 BytesIn: 198045 BytesOut: 377427 Forwarding: Enabled MTU: 1492IPv6: Disabled Broadcast Capability: Yes Multicast Capability: Yes Group Members - --- 224.0.0.1 1 Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Edward M. Martin Sent: Friday, August 24, 2007 12:06 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: TCP/IP problem with two z/VM systems Hello Daniel Allen, We have a z890 with the QDIO being used by Both z/VM and VSE systems. The VSE system had a parameter (removed now that we are on QDIO) of STOPLAN=YES/NO. The STOPLAN=yes was the default. We had to have STOPLAN=NO. From what I learned, a 3172 (or
Re: TCP/IP problem with two z/VM systems
Did anything happen to the hub/switch before this started happening? Like a code update? Is there a different hub/switch available that you can plug in to? Daniel Allen wrote: It started before the OSA replacement and the microcode upgrade. Daniel Allen Sr. System Programmer Serena Software, Inc. 13713 Pinto Lane Lodi, CA 95240 800-457-3736 ext. 11241 [EMAIL PROTECTED] Serena Software, Inc. www.serena.com -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: Ops privs
On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
It is definitely necessary to have the exceptions capability, if implemented. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 24, 2007 2:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Sorry to confuse. I was suggesting a rule that says, as a class G user, you could target - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE (with a new class G version) - SIGNAL SHUTDOWN to any user to whom you are authorized for LOGON BY. Thinking further, if you did not have LOGON BY, but did have XAUTOLOG authority, would it be ok to implicitly grant FORCE and SIGNAL SHUTDOWN? Not a good assumption. I think I'd argue that you should provide a way to individually control each command and ship that with CP. Long term, that's the better solution, and there's a load of stuff that you're dual-pathing now for people that do and don't have an ESM. Much as I dislike RACF, you'd be better off spending the effort to bundle RACF with CP and moving all the command authentication stuff to RACF profiles. You'd solve a lot of other problems in the process, and let sites determine this behavior more granularly than command classes permit today. It would also be a better technology argument vs VMWare and the other Intel virtualization solutions -- they're going to have to invent something very much like RACF in the near future, and you can beat them to the punch. Then you can start on command operand authorization...8-) -- db
Re: Ops privs
I agree with Richard. Not only do you have a serialization issue with multiple people able to issue commands, but all these additional commands would need to be logable by an ESM. I can't think of any cases where I'd want to give SEND or SIGNAL SHUTDOWN authorization to general users. If I did, I'd rather be able to give that authorization individually, and not have it lumped in with Logonby. Dennis O'Brien Chelsea Clinton asked a returning US Soldier about fear. He said there were only three things he was afraid of: Osama, Obama and Yo Mama. -- Truckee Tahoe Times From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Friday, August 24, 2007 13:21 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Ops privs No. No. No. No. No. We use LOGONBY as a means of controlling who is allowed to log on to group ids and tracking what they do. None of those other commands would be useful or necessary in that context. Giving those permissions would negate, or at least complicate, our ability to track who did what when. Further, we would not want one user to be able to alter or compromise the functions being performed by another who was already logged on via LOGONBY. SEND, FORCE, and SIGNAL SHUTDOWN certainly have that potential, for example. Most of what is listed could be useful only to someone who is really knowledgeable about the functions of the virtual machine. They are also mostly useful in looking after service machines. They are not useful to someone who is a more naïve user who logs on to a group id to perform simple functions or to run an application program, and could be somewhat dangerous if abused, accidentally or on purpose, by such a person. It is the latter group that we must protect against by not giving them authorities that they will never need. The former group probably has the knowledge needed to function without the added authority. Regards, Richard Schuh There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
On 8/25/07, David Boyes [EMAIL PROTECTED] wrote: Then you can start on command operand authorization...8-) Oh no... you gave Chucky a new idea. We'll blame you for all that comes out of this. Most CP commands right now only allow the ESM to audit, not to control access. If the ESM gets granular access control, we need a a lot of new error messages to reflect that. Given enough beverages of choice, I could come up with situations where you might want user A to be able to use the DEFSEG command for segment S only. What you do now is to have a disconnected virtual machine with enough privileges and run PROP there. An easy API for RACROUTE might be nice to avoid yet-another-list of powerful users (especially since some weasels want that all disks with lists of powerful users are protected against reading). Rob
Re: Ops privs
And to satisfy those installations that are not as simplistic as mine, an ESM implementation could allow an installation to turn it off and use all of the old authorizations just as they are today. Wow, Chuckie must have a distant cousin around here who typed at my keyboard. I don't think I have ever leaned toward implementing something in the ESM when it could be done in CP. /Tom Kern --- Alan Altmark [EMAIL PROTECTED] wrote: On Friday, 08/24/2007 at 04:26 EDT, Thomas Kern [EMAIL PROTECTED] wrote: I like it. Are you thinking of having this as a CP implementation or an ESM based add-on function? I would not object to either but prefer a CP implementation. I'm not thinking of any particular implementation, I'm just asking for opinions on the concept of implied consent. But now that you ask, what I've described so far is doable within CP as well as an ESM, though the ESM provides more flexibility and exceptions capability. Alan Altmark z/VM Development IBM Endicott Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz
Re: Ops privs
And if RACF were a no-cost component of z/VM, I could get away with using it even if the other side of the mainframe runs that other security product. /Tom Kern --- David Boyes [EMAIL PROTECTED] wrote: Not a good assumption. I think I'd argue that you should provide a way to individually control each command and ship that with CP. Long term, that's the better solution, and there's a load of stuff that you're dual-pathing now for people that do and don't have an ESM. Much as I dislike RACF, you'd be better off spending the effort to bundle RACF with CP and moving all the command authentication stuff to RACF profiles. You'd solve a lot of other problems in the process, and let sites determine this behavior more granularly than command classes permit today. It would also be a better technology argument vs VMWare and the other Intel virtualization solutions -- they're going to have to invent something very much like RACF in the near future, and you can beat them to the punch. Then you can start on command operand authorization...8-) -- db Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/
Re: FTP
Or better yet, google VMFTP (written by Romney White), download it, and you can write rexx scripts that test for reply msgs and return codes. Very powerful, not too difficult. Mike Walter Hewitt Associatea - Original Message - From: John Hanley [EMAIL PROTECTED] Sent: 08/24/2007 11:54 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: FTP Ann, Try like this: /**/ arg fn ft fm queue 'johnh ' queue 'ebcdic' queue 'mode b' queue 'mput' fn'.'ft'.'fm queue 'quit' 'ftp 192.168.1.100' John Hanley (804) 786-7823 Aisik Chang [EMAIL PROTECTED] m To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System [EMAIL PROTECTED] Subject ARK.EDU FTP 08/24/2007 12:34 PM Please respond to The IBM z/VM Operating System [EMAIL PROTECTED] ARK.EDU I tried to use exec to ftp a file, but it woundn't go: The exec: /**/ TRACE R push 'profile.exec.a' 'k9830t.profile.exec' push push K9830TS ftp metprodl -- the result is: 3 *-* push 'profile.exec.a' 'k9830t.profile.exec' profile.exec.a k9830t.profile.exec 4 *-* push 5 *-* push K9830TS K9830TS 6 *-* ftp metprodl FTP METPRODL VM TCP/IP FTP Level 520 Connecting to METPRODL 10.9.199.100, port 21 220-FTPSERVE IBM VM Level 520 at METPRODL.METLIFE.COM, 12:30:34 EDT FRIDAY 2007- 08-24 220 Connection will close if idle for more than 5 minutes. USER (identify yourself to the host): USER K9830TS 331 Send password please. Password: - Thanks for your help, Ann 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.
