Re: Ops privs (was Re: MAINTENANCE)

2007-08-24 Thread pfa
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

Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library

2007-08-24 Thread Alan Altmark
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

Re: Ops privs (was Re: MAINTENANCE)

2007-08-24 Thread Schuh, Richard
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

zVM 5.2 TCPIP problem

2007-08-24 Thread Tom Duerbusch
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 DTCPRC150I

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Brian Nielsen
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

Re: Ops privs

2007-08-24 Thread Alan Altmark
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

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Tom Duerbusch
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

Re: Ops privs (was Re: MAINTENANCE)

2007-08-24 Thread Schuh, Richard
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:

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Alan Altmark
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

TCP/IP problem with two z/VM systems

2007-08-24 Thread Daniel Allen
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 *

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Rich Smrcina
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Daniel Allen
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

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread pfa
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

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Brian Nielsen
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

2007-08-24 Thread O'Brien, Dennis L
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

Re: Ops privs

2007-08-24 Thread Kris Buelens
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]:

Re: Ops privs (was Re: MAINTENANCE)

2007-08-24 Thread Kris Buelens
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

Re: Ops privs

2007-08-24 Thread Brian Nielsen
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]

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Edward M. Martin
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)

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Tom Duerbusch
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Edward M. Martin
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Daniel Allen
Here is VM01: VM TCP/IP Netstat Level 430 Device OSAVM1Type: OSD Status: Ready Queue size: 0Address: 0100 Port name: PORTVM1 Router

Re: Ops privs

2007-08-24 Thread Kris Buelens
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Daniel Allen
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

Re: Ops privs

2007-08-24 Thread Alan Altmark
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

Re: OSA question

2007-08-24 Thread O'Brien, Dennis L
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

Re: Ops privs

2007-08-24 Thread Schuh, Richard
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

Re: zVM 5.2 TCPIP problem

2007-08-24 Thread Schuh, Richard
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

Re: Ops privs

2007-08-24 Thread Steve Marak
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

Re: Ops privs

2007-08-24 Thread Thomas Kern
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,

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Edward M. Martin
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Edward M. Martin
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:

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Daniel Allen
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

Re: TCP/IP problem with two z/VM systems

2007-08-24 Thread Rich Smrcina
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

Re: Ops privs

2007-08-24 Thread Alan Altmark
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

Re: Ops privs

2007-08-24 Thread Schuh, Richard
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

2007-08-24 Thread David Boyes
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

Re: Ops privs

2007-08-24 Thread O'Brien, Dennis L
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

Re: Ops privs

2007-08-24 Thread Rob van der Heij
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

Re: Ops privs

2007-08-24 Thread Thomas Kern
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

Re: Ops privs

2007-08-24 Thread Thomas Kern
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

Re: FTP

2007-08-24 Thread Mike Walter
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