Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: 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. Or just one: HCPE Command option not permitted by security profile. RC=1234 Exactly what isn't permitted isn't the end user's business (to prevent gaming the system and determining what options are permitted by trial and error), but should be recorded in the ESM log. Beg to differ. My experience is that this is not helpful. My all time favorite is the console log full of Command complete for user messages. You want the requester and owner of the resource (the one who can grant access) to be able to sort this out, so it should be clear to either one of them which profile was preventing or not allowing access. Hiding the why does not make it more secure. There are more effective ways to detect systematic attacks and friends. 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). Takes us back to either a universal *RPI service provider built into CP that we can connect to with pipes and do our own ESM, or supplying a default ESM that's more granular than the classic CP model, doesn't it? You're making wind and causing confusion. *RPI is what CP uses to connect to the RACFVM's. CMS Pipelines can connect to *RPI but that's the reverse of what we want. What I am asking for is an application resource profile that is not used by CP but by applications to control access to services (e.g. APPL.TCPIP.LINK.ABC could allow query or start/stop of link ABC based on access to that profile). It would also require extra support in the ESM to have granular access control for those 3rd party checks (ICHCONN is global). One could imagine a new/changed diagnose to ask CP to ask the ESM, but we have no easy way to use such a diagnose. A new system IUCV service looks cool but also lacks the tools to use it. So maybe a new CP command is the easiest way. Rob
Re: Ops privs
I want to wind back a bit on this one:- We do use RACF as an ESM and we do use LOGONBY (controlled by RACF profiles) extensively. I understand that any user with LOGONBY authority can log on and give any of the commands mentioned but we would be extremely unhappy about these users being able to give those commands on behalf of that user without logging on. This should not be the assumption and, if it becomes so, then there should be an easy way to revert to the current status :- There are 2 issues here :- 1. Visibility Searching RACF audit record is no substitute for seeing the commands entered on the console of the user. 2. Serialisation Insisting the user logs on (LOGONBY) ensures that they (and only they) have control of that user at that time.\ I would be OK with the ability to enable the behaviour suggested but I would be very unhappy for it to be the default that we had to find a workaround for. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Ops privs
This is the kind of change that I hope WILL NOT be the default and will actually take some effort on my part to implement. It is too dramatic a change, with too many installations depending upon the current behavior. As to the serialization of control of a target user, what if there were a 'lock' setting that could be set before executing these new commands on behalf of a target user and unset when the administrator is finished fiddling with the target user. If done in an ESM, I would hope that rules could be written to require that the 'lock' be set by the same requestor. /Tom Kern /301-903-2211 --- Colin Allinson [EMAIL PROTECTED] wrote: I want to wind back a bit on this one:- We do use RACF as an ESM and we do use LOGONBY (controlled by RACF profiles) extensively. I understand that any user with LOGONBY authority can log on and give any of the commands mentioned but we would be extremely unhappy about these users being able to give those commands on behalf of that user without logging on. This should not be the assumption and, if it becomes so, then there should be an easy way to revert to the current status :- There are 2 issues here :- 1. Visibility Searching RACF audit record is no substitute for seeing the commands entered on the console of the user. 2. Serialisation Insisting the user logs on (LOGONBY) ensures that they (and only they) have control of that user at that time.\ I would be OK with the ability to enable the behaviour suggested but I would be very unhappy for it to be the default that we had to find a workaround for. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433
Re: Ops privs
We use LOGONBY to be able to log onto a test user whose profile has nothing but class G authority. It's great to be able to do final testing to make sure that the final users have access to all necessary functions. Changing the privileges by default might negate some of those results. Nora Graves [EMAIL PROTECTED] Main IRS, Room 6513 (202) 622-6735 Fax (202) 622-3123 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 24, 2007 12:54 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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: Ops privs
On 8/27/07, Graves Nora E [EMAIL PROTECTED] wrote: We use LOGONBY to be able to log onto a test user whose profile has nothing but class G authority. It's great to be able to do final testing to make sure that the final users have access to all necessary functions. Changing the privileges by default might negate some of those results. I think your scenario would still be safe with what Alan suggested. During your test you would have the privileges of the target only. Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. Rob
Re: Ops privs
I also agree with Richard. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Friday, August 24, 2007 6:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 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 _ 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 This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
we need a a lot of new error messages to reflect that. Or just one: HCPE Command option not permitted by security profile. RC=1234 Exactly what isn't permitted isn't the end user's business (to prevent gaming the system and determining what options are permitted by trial and error), but should be recorded in the ESM log. Beg to differ. My experience is that this is not helpful. My all time favorite is the console log full of Command complete for user messages. You want the requester and owner of the resource (the one who can grant access) to be able to sort this out, so it should be clear to either one of them which profile was preventing or not allowing access. Hiding the why does not make it more secure. There are more effective ways to detect systematic attacks and friends. I think we will have to agree to disagree. Most of the security weasels I know claim that the less information you give a potential intruder, the better, but that stems from their mindset that *everyone* is a potential intruder. From a usability standpoint, your argument has merit, but I think I would point out that much of the user context we've had historically no longer exists. The number of CMS-intensive shops is being slowly strangled to nothing, and we increasingly see CP plus guests, with only a tiny number of sysprogs having access to a CMS userid. At what point does the balance tip to focusing on the integrity of the CP hipervisors and guest OSes, not on CMS users? Also, if the question is determining what happened, what's to stop us from engineering a *standardized* way to determine the cause of a failure or to review the right set of logs, and deploying that. Right now, everyone out there has to build their own, and document it, and support it. The idea of a common security event stream with proper filtering is, oh, about 30-35 years old now. Isn't it time we caught up with the rest of civilization? 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). Takes us back to either a universal *RPI service provider built into CP that we can connect to with pipes and do our own ESM, or supplying a default ESM that's more granular than the classic CP model, doesn't it? You're making wind and causing confusion. sarcasm Silly me. I thought I was having a serious discussion with other grownups about better ways to implement security models. Pardon me while I find the party in the other room. /sarcasm What I am asking for is an application resource profile that is not used by CP but by applications to control access to services (e.g. APPL.TCPIP.LINK.ABC could allow query or start/stop of link ABC based on access to that profile). It would also require extra support in the ESM to have granular access control for those 3rd party checks (ICHCONN is global). And that's the next step. Once we can ask the questions and get answers at a granular level, then we go after the inconsistencies in CP command behavior, and extend to the parameter level; the syntax you propose looks nice, and would fit in with what I had in mind. One could imagine a new/changed diagnose to ask CP to ask the ESM, but we have no easy way to use such a diagnose. A new system IUCV service looks cool but also lacks the tools to use it. So maybe a new CP command is the easiest way. So you're proposing a *AUTH or something like that where you can pose a authorization question from a user, which will be answered by whatever is connected to *RPI? IUCV has the advantage that it can already be transported across ISFC, which would allow concentrating authorization information on certain nodes in a cluster, a useful scalability and auditability feature. -- db
Re: Ops privs
If it were done in that other ESM for VM, it would be in its audit file. In the absense of an ESM to inplement it, it would be BAU with no new capability. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of A. Harry Williams Sent: Saturday, August 25, 2007 5:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sat, 25 Aug 2007 00:20:38 +0200 Rob van der Heij said: On 8/24/07, Alan Altmark [EMAIL PROTECTED] 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 Put away what you're smoking... Let's get back again to the style where we come up with the requirements and plea for years to get the commands in the directory, and you guys code it ... :-) I understand the idea that these commands achieve things that you could do if you would logon to the virtual machine. Sure, but far from complete: FOR has been suggested, but what about STORE HOST (as long as the frame holds a page of that virtual machine) and DETACH, and... My major concern is auditing. While I trust that the implementation will take care of auditing in the ESM, it makes it much harder to see who has been messing with it. Normally when a user tells his server suddenly failed you could scan the PROP logging and see which of the developers reconnected, and tell him to hit his peer over the head with it. But when neither of the virtual machines has its console spooled, you would not be able to tell what happened. Well, that implies a greater need for logging the auditing. The other system does that via SMF. In VM, that would be either Accounting records or Monitor records. Based on granularity of controlling how much is logged, and the similarity of what is done for other logging uses on VM, I'd recommend Monitor records. ... Rob /ahw
Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: So you're proposing a *AUTH or something like that where you can pose a authorization question from a user, which will be answered by whatever is connected to *RPI? The need to do an IUCV connection adds a lot of complexity we don't need. I think that if we want even locally written tools to exploit this, a CP command would be better. Even if that means it becomes a synchronous interface. So CP CANYOUDO resource name access mode IUCV has the advantage that it can already be transported across ISFC, which would allow concentrating authorization information on certain nodes in a cluster, a useful scalability and auditability feature. I think it would be enough to get CP's answer on *this* system, whatever way CP has come to that conclusion. If CP would trust to connect to the ESM via ISFC, then CP may use that... Rob
Re: Ops privs
On Monday, 08/27/2007 at 09:20 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). Rob, I did not propose to give TESTABC the authorization that TCPMAINT would have/ Rather, I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. That is only the default RACF implementation and is controlled by a RACF exit; CP does not redrive the authorization. In fact, the Common Criteria evaluated configuration requires that this exit be removed. It's on the To Do list to allow the RACF admin to identify specific users who are, in fact, batch machines that need that functionality. Alan Altmark z/VM Development IBM Endicott
Question about IBM-supplied pipe stages/DVD CKD chunk format
So, I'm working on a product that, at its heart, is a couple of DASD images that get restored to the platters. Right now, I require two additional 3390-3s for installation: one to hold the VMARC image of the CMSDDR dump of the disk (because VMARC is copyable around a network easily because it's F 80, while CMSDDR is wildly V), and one to hold the unpacked image so that CMSDDR can restore it. This is idiotic, but I can't think of a better way to do it, unless: So, is the on-disk format of the CKD images that the z/VM DVD installer operates on documented? Because it'd be REAL HANDY to say, hey, put these files on an FTP server somewhere, access MAINT's 2CC disk, run INSTPIPE, make sure you have DASD attached at 150 and 151, and then run the following two pipe stages: PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD150* | ECKDREST 150 PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD151* | ECKDREST 151 Adam
Re: Question about IBM-supplied pipe stages/DVD CKD chunk format
Hello, Adam. Yup this would be a very slick way of distributing software; but I don't think the format of the data on the DVDs is documented anywhere, nor to I think IBM will be documenting how to use the FTPGET stage, either. During the recent 5.3 ESP program, I asked about getting FTPGET documented, but never heard back anything official from IBM. Plus, you will notice that there are *two* undocumented stages used by the DVD restore process: FTPGET itself, and the stage right behind it: ECKDREST...that's not a part of the normal pipeline stage collection, either. Adam Thornton wrote: So, I'm working on a product that, at its heart, is a couple of DASD images that get restored to the platters. Right now, I require two additional 3390-3s for installation: one to hold the VMARC image of the CMSDDR dump of the disk (because VMARC is copyable around a network easily because it's F 80, while CMSDDR is wildly V), and one to hold the unpacked image so that CMSDDR can restore it. This is idiotic, but I can't think of a better way to do it, unless: So, is the on-disk format of the CKD images that the z/VM DVD installer operates on documented? Because it'd be REAL HANDY to say, hey, put these files on an FTP server somewhere, access MAINT's 2CC disk, run INSTPIPE, make sure you have DASD attached at 150 and 151, and then run the following two pipe stages: PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD150* | ECKDREST 150 PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD151* | ECKDREST 151 Adam -- DJ V/Soft
Re: Question about IBM-supplied pipe stages/DVD CKD chunk format
On Monday, 08/27/2007 at 12:28 EDT, Adam Thornton [EMAIL PROTECTED] wrote: So, is the on-disk format of the CKD images that the z/VM DVD installer operates on documented? No. They are subject to change w/o notice. (Though only on a release boundary, obviously! :-) ) Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Alan Altmark [EMAIL PROTECTED] wrote(in part) :- I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :- The number of CMS-intensive shops is being slowly strangled to nothing, and we increasingly see CP plus guests, with only a tiny number of sysprogs having access to a CMS userid. At what point does the balance tip to focusing on the integrity of the CP hipervisors and guest OSes, not on CMS users? Overall you may be right but we are not the only TPF shop where there are many hundreds of VM userids running TPF and many more for the control and administration of these. It will be a long while before we reach the simplicity of running 20-30 Linux images where everything is done within the guests. Colin G Allinson Technical Manager VM Amadeus Data Processing GmbH T +49 (0) 8122-43 49 75 F +49 (0) 8122-43 32 60 [EMAIL PROTECTED] http://www.amadeus.com IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the individual or entity shown above as addressees . It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws . If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system . Amadeus Data Processing GmbH Geschäftsführer: Eberhard Haag Sitz der Gesellschaft: Erding HR München 48 199 Berghamer Strasse 6 85435 Erding Germany
Re: Question about IBM-supplied pipe stages/DVD CKD chunk format
On Aug 27, 2007, at 11:28 AM, Dave Jones wrote: Hello, Adam. Yup this would be a very slick way of distributing software; but I don't think the format of the data on the DVDs is documented anywhere, nor to I think IBM will be documenting how to use the FTPGET stage, either. During the recent 5.3 ESP program, I asked about getting FTPGET documented, but never heard back anything official from IBM. Plus, you will notice that there are *two* undocumented stages used by the DVD restore process: FTPGET itself, and the stage right behind it: ECKDREST...that's not a part of the normal pipeline stage collection, either. Yeah, but I don't need to know *how* either of those stages work, really. I did some experimenting; ECKDREST works if you just download (er, and PIPE UNPACK) the disk files. FTPGET appears to just pull the binary image of the files (hunhcome to think of it, if I were doing a whole mod-3, I might need some ridiculous amount of memory to buffer the output of the initial FTPGET stage anyway, although if it does it one record at a time, not so much). UNPACK, well, UNPACKs to some track image format that ECKDREST consumes that I don't actually need to care about. Yes, of course this might break at some point if IBM changes their formats, but it works with z/VM 5.1 through 5.3, which is, frankly, almost everyone I currently care about supporting for this product. I see that Alan just confirmed that: if they change without notice, they will do so on a release boundary, and it will be obvious because the requires z/VM 5.1 or later for Level 2 installation will change to...something else.\ But since it's not documented, I guess I *do* need to figure out what the format that ECKDREST uses is, so I can dump to it, run it through PIPE PACK and then split to 4M chunks or whatever it is that the CKD files actually are. (COPYFILE ( FROM x FOR y PACK would do this split, right?) Adam
Re: Ops privs
But isn't FORCE just shorthand for LOGON u1 HERE By u2 followed by LOGOFF? Bob Bolch I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :-
Re: Ops privs
David Boyes [EMAIL PROTECTED] wrote :- The number of CMS-intensive shops is being slowly strangled to nothing, and we increasingly see CP plus guests, with only a tiny number of sysprogs having access to a CMS userid. At what point does the balance tip to focusing on the integrity of the CP hipervisors and guest OSes, not on CMS users? Overall you may be right but we are not the only TPF shop where there are many hundreds of VM userids running TPF and many more for the control and administration of these. It will be a long while before we reach the simplicity of running 20-30 Linux images where everything is done within the guests. Makes sense, and there will always be exceptions, just as the guest-only configuration was the exception a few years back. I don't want to prohibit your configuration, but I do want to try to get the default configuration to reflect the most common uses (principle of least surprise).
Re: Question about IBM-supplied pipe stages/DVD CKD chunk format
Take a look at the PIPEDDR package on the IBM Downloads site. It can dump a 'userid mdisk-addr' or '* attached-addr' to a packed CMS file. The packed format is equally transportable around the network as Binary-Fixed-1024. If you compare PIPEDDR and CMSDDR, you may find that PIPEDDR is a bit faster in elapsed time. I don't have any numbers to prove that yet but my experimen ts about piping encrypted DASD images to tape have given some indications. I can imagine the VM community sharing DASD images of linux systems or ju st filesystems in the future. Perhaps it is time for a community designed an d written utility to replace (for our purposes, not IBM's) the base DDR command. Typical input to be user mdisk, a full volume to be attached, a standard-label (or a non-labeled) tape dataset, a CMS file or even an FTPable network file. Typical output would be about the same diversity (anyone have any others? A linux file on a Read-Write minidisk? ). There should be installation replacable exits for compression and encryption. A nd the CMS file versions of the data should be in a network transportable format (Binary-Fixed-4096?). Anyone else have ideas for this fantasy? /Tom Kern /301-903-2211 On Mon, 27 Aug 2007 11:20:50 -0500, Adam Thornton [EMAIL PROTECTED] et wrote: So, I'm working on a product that, at its heart, is a couple of DASD images that get restored to the platters. Right now, I require two additional 3390-3s for installation: one to hold the VMARC image of the CMSDDR dump of the disk (because VMARC is copyable around a network easily because it's F 80, while CMSDDR is wildly V), and one to hold the unpacked image so that CMSDDR can restore it. This is idiotic, but I can't think of a better way to do it, unless: So, is the on-disk format of the CKD images that the z/VM DVD installer operates on documented? Because it'd be REAL HANDY to say, hey, put these files on an FTP server somewhere, access MAINT's 2CC disk, run INSTPIPE, make sure you have DASD attached at 150 and 151, and then run the following two pipe stages: PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD150* | ECKDREST 150 PIPE FTPGET -v BEF -DVDEOF -h host -u userid -p password -d dir CKD151* | ECKDREST 151 Adam =
Re: Ops privs
That way, you can surprise everyone who has been using the old defaults for years :-) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Monday, August 27, 2007 10:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs I don't want to prohibit your configuration, but I do want to try to get the default configuration to reflect the most common uses (principle of least surprise).
Re: Ops privs
It depends. There is the BYUSER field that gets updates with the LOGON ... BY u2. Would it get updated by the FORCE? Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bob Bolch Sent: Monday, August 27, 2007 10:08 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs But isn't FORCE just shorthand for LOGON u1 HERE By u2 followed by LOGOFF? Bob Bolch I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. David Boyes [EMAIL PROTECTED] wrote :-
Re: Ops privs
Reminds me of a system modification we had back in the day, at another company, that the SNA Staff could LOGON to VMVTAM but could not issue LOGOFF. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:27 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 09:20 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: Your scenario would only break when Alan had proposed reverse inheritance or sideways inheritance of privileges (the person who logged on to TESTABC could also have chosen to logon to TCPMAINT, so let's now give TESTABC the authorisation that TCPMAINT would have had). Rob, I did not propose to give TESTABC the authorization that TCPMAINT would have/ Rather, I proposed that TESTABC could, for example: - XAUTOLOG TCPMAINT because the user could just bring up another terminal session and LOGON TCPMAINT/DISC - FORCE TCPMAINT because the user could LOGON TCPMAINT/LOGOFF - SEND TCPMAINT because the user could LOGON TCPMAINT/SET SECUSER TESTABC/DISC or just LOGON TCPMAINT and start issuing commands - SIGNAL SHUTDOWN TCPMAINT because the user could LOGON TCPMAINT/SIGNAL SHUTDOWN/DISC A somewhat similar problem is with the altuser implementation when the target gets the combined authorisation of the worker machine and the owner of the job. That is only the default RACF implementation and is controlled by a RACF exit; CP does not redrive the authorization. In fact, the Common Criteria evaluated configuration requires that this exit be removed. It's on the To Do list to allow the RACF admin to identify specific users who are, in fact, batch machines that need that functionality. Alan Altmark z/VM Development IBM Endicott This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
On Monday, 08/27/2007 at 12:55 EDT, Colin Allinson [EMAIL PROTECTED] wrote: I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. I hear you. I have understood from the various comments like yours that the concerns are not actually related to security, but to system management (avoiding accidents). I understand and accept that. So, no worries about users suddenly and unexpectedly being able to FORCE (e.g.) another user. You will still need to be aware of CP FOR's use of LOGON BY as authorization (ESM only, and only when you are not currently the secuser). Alan Altmark z/VM Development IBM Endicott
Debian SSL Server
Greetings, I used the Debian SSL Enabler from SNA on zVM 5.1 until yesterday when I migrated to zVM 5.3 when it stopped working. I found a couple of errors and corrected them but still no go and I am still scratching my head. Has any one tried Debian SSL Enabler from SNA on 5.3 and can tell me what to expect or what to look for? Thanks very much in advance. Suleiman Shahin _ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
Re: Ops privs
Is FOR new with 5.3? H CP FOR gets me the display for FOrward. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 12:55 EDT, Colin Allinson [EMAIL PROTECTED] wrote: I certainly do not want a user to be able to FORCE another simply because they have LOGONBY authority for that userid. If allowing this is optional (for those shops that want it) then fine but I do not want to be put in a position where this is the default authority for LOGONBY. I hear you. I have understood from the various comments like yours that the concerns are not actually related to security, but to system management (avoiding accidents). I understand and accept that. So, no worries about users suddenly and unexpectedly being able to FORCE (e.g.) another user. You will still need to be aware of CP FOR's use of LOGON BY as authorization (ESM only, and only when you are not currently the secuser). Alan Altmark z/VM Development IBM Endicott
Re: RSCS
Hi, I passed this on to our RSCS ID person and he has corrected the statement. However, the correction won't show up in the current book and help files. Don't know how this one slipped past! Thanks for finding it! Colleen M Brown IBM z/VM and Related Products Development and Service Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/17/2007 04:06 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject RSCS There is no RCF for a HELP display, but one that looks somewhat strange is the HELP RSCS TCPNJE display. If you look at the STREAMS= parameter in the syntax diagram, the non-default line calls for a rather odd entry. J Regards, Richard Schuh
Re: RSCS
Thanks for fixing and responding. Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Colleen Brown Sent: Monday, August 27, 2007 9:49 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSCS Hi, I passed this on to our RSCS ID person and he has corrected the statement. However, the correction won't show up in the current book and help files. Don't know how this one slipped past! Thanks for finding it! Colleen M Brown IBM z/VM and Related Products Development and Service Schuh, Richard [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 08/17/2007 04:06 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject RSCS There is no RCF for a HELP display, but one that looks somewhat strange is the HELP RSCS TCPNJE display. If you look at the STREAMS= parameter in the syntax diagram, the non-default line calls for a rather odd entry. :-) Regards, Richard Schuh
Re: Ops privs
On Monday, 08/27/2007 at 02:17 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Is FOR new with 5.3? H CP FOR gets me the display for FOrward. Yes, it is new with z/VM 5.3. And the abbreviation of FORWARD is now FORW. :-) Alan Altmark z/VM Development IBM Endicott
Re: Debian SSL Server
It would help if you supplied us what errors you're seeing, and what you see in the TCPIP log. I used the Debian SSL Enabler from SNA on zVM 5.1 until yesterday when I migrated to zVM 5.3 when it stopped working. I found a couple of errors and corrected them but still no go and I am still scratching my head. Has any one tried Debian SSL Enabler from SNA on 5.3 and can tell me what to expect or what to look for?
Re: Ops privs
On 8/27/07, David Boyes [EMAIL PROTECTED] wrote: I think we will have to agree to disagree. Most of the security weasels I know claim that the less information you give a potential intruder, the better, but that stems from their mindset that *everyone* is a potential intruder. More like different context. For *authentication* it is good practice not to reveal any information when wrong credentials are supplied. This is where the weasels come from. It was just a nasty prank of me to do a password check that provided hits like 4 good, 2 at the wrong place or the next password response. The approach to revoke a user when someone tried to logon to that account 3 times with a wrong password is imho more a security problem than a solution to one. But once the user is authenticated, it's not a potential intruder anymore. At that point, we normally assume the user is doing the right thing because business conduct guidelines will guide the user. If such a relation does not exist, you have entirely different problems that don't get solved by a computer says No response (see my Less that G approach). Rob
Re: Debian SSL Server
David, The interface between SSLSERV and TCPIP has changed in z/VM 5.3. See: http://www.vm.ibm.com/related/tcpip/tcprl2rl.html#rl2ssl Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3? Thanks, Mark At 02:25 PM 8/27/2007, David Boyes wrote: It would help if you supplied us what errors youre seeing, and what you see in the TCPIP log .. I used the Debian SSL Enabler from SNA on zVM 5.1 until yesterday when I migrated to zVM 5.3 when it stopped working. I found a couple of errors and corrected them but still no go and I am still scratching my head. Has any one tried Debian SSL Enabler from SNA on 5.3 and can tell me what to expect or what to look for? Mark Bodenstein ([EMAIL PROTECTED]) Cornell University
Re: Debian SSL Server
Hello Dave, I am not seeing any errors, but I can attach the log from TCPIP and SSLSERV. Suleiman Shahin Date: Mon, 27 Aug 2007 14:25:06 -0400From: [EMAIL PROTECTED]: Re: Debian SSL ServerTo: IBMVM@LISTSERV.UARK.EDU It would help if you supplied us what errors you’re seeing, and what you see in the TCPIP log….. I used the Debian SSL Enabler from SNA on zVM 5.1 until yesterday when I migrated to zVM5.3 when it stopped working.I found a couple of errors and corrected them but still no go and I am still scratching my head.Has any one tried Debian SSL Enabler from SNA on 5.3 and can tell me what to expect or what to look for? _ Learn. Laugh. Share. Reallivemoms is right place! http://www.reallivemoms.com?ocid=TXT_TAGHMloc=us
Re: Debian SSL Server
Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3? Not yet. It's behind a few other significant pieces of paying work at the moment. It's a few weeks away at best. More later. -- db
Re: Ops privs
On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott
Re: Ops privs
Better the evil you know then the one you do not know? -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 3:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
Re: Ops privs
Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott
Re: Debian SSL Server
Thanks David. Glad to hear you're getting paying work. :-) Mark At 03:08 PM 8/27/2007, you wrote: Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3? Not yet. It's behind a few other significant pieces of paying work at the moment. It's a few weeks away at best. More later. -- db
Re: Ops privs
On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] Alan Altmark z/VM Development IBM Endicott
Re: Debian SSL Server
Dave, I am attaching the TCPIP log for you to look at if you wish. Thanks. Suleiman Shahin Date: Mon, 27 Aug 2007 15:41:22 -0400From: [EMAIL PROTECTED]: Re: Debian SSL ServerTo: [EMAIL PROTECTED] David. Glad to hear you're getting paying work. :-)MarkAt 03:08 PM 8/27/2007, you wrote: Does Sine Nomine have a version of the SSL Enabler incorporating the appropriate RPM for z/VM 5.3?Not yet. It’s behind a few other significant pieces of paying work at the moment. It’s a few weeks away at best. More later. -- db _ Find a local pizza place, movie theater, and more….then map the best route! http://maps.live.com/default.aspx?v=2ss=yp.bars~yp.pizza~yp.movie%20theatercp=42.358996~-71.056691style=rlvl=13tilt=-90dir=0alt=-1000scene=950607encType=1FORM=MGAC01
Re: Ops privs
On Aug 27, 2007, at 2:53 PM, Alan Altmark wrote: On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam
Re: Ops privs
I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
Alan, Hi. My name really is Bob and I'm a z/OS sysprog. pause for greeting And I am looking for a new job! :-) Seriously, as of last week, I have been informed that my position has been eliminated. If anyone on this list is looking for an individual with basic z/VM and Linux skills coupled with extensive z/OS skills, please drop me a note offline. My apologies to the list administrator for not clearing this blatant attempt for assistance in my job search in advance of posting it. Bob Richards VP, Enterprise Technologist - - Enterprise Technology Infrastructure- - Mainframe Services Capacity Performance Mgmt - - Office: 404-575-2798Mobile: 610-246-2943 - - email: [EMAIL PROTECTED] - -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 3:53 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Monday, 08/27/2007 at 03:38 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] Alan Altmark z/VM Development IBM Endicott LEGAL DISCLAIMER 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. SunTrust and Seeing beyond money are federally registered service marks of SunTrust Banks, Inc. [ST:XCL]
Re: Ops privs
1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. A koan for Considering the Presence of Buddha-Nature in ESMs: I hit myself on the head with a hammer. It hurts. I hit myself again. It still hurts. I hit myself with a padded hammer. It hurts less, but it's still being hit with a hammer -- but it's a familiar pain and I know what to do to treat it. I hit myself on the head with a empty bleach bottle. It still hurts, but it's a different kind of hurt. Here endeth the tale. If you're familiar with RACF elsewhere, then yes, you've already taken the first blow to the head, and it's a familiar pain (but not to the head, or at least not immediately). There are net-new Z sites that don't have RACF/zOS. Considered in the abstract (ie, without a pre-existing RACF investment), RACF *is* really, really ugly compared to VM:Secure or even ACF2. The reasons the alternatives exist is to ameliorate that ugly nature. I've managed systems with all three tools installed at various times. IMHO, RACF's principal advantages are that popular presence on the Other Side, and that you (IBM) own it and can decide to supply it by default if you choose to do so w/o dealing with an outside entity. You can put a lot of lipstick on that pig with RACTOOLS and some front-end execs, but it's still a pig deep down.
Re: Ops privs
Sorry; supporting z/OS DRIVES one to drinking! Kris Buelens [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@listserv.uark.edu 08/27/2007 03:10 PM Please respond to The IBM z/VM Operating System IBMVM@listserv.uark.edu To IBMVM@listserv.uark.edu cc Subject Re: Ops privs I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support - This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.
Re: Ops privs
A completely uneducated guess would be 50%, and perhaps as high as 90%. Shops that are already comfortable with the IBM mainframe 'mindset' are much more willing, imho, to consider migrating workload to z/VM and Linux than organizations that have no previous mainframe experience. Schuh, Richard wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft
Re: Ops privs
If that is true, then I shudder to think of what the MS Windows people are abusing! I mean, I know that MS apologists are on dreamy dust and have little connection to reality anymore. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Buckles Sent: Monday, August 27, 2007 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs Sorry; supporting z/OS DRIVES one to drinking!
Re: Ops privs
At one time I think I remember Barton mentioning something about getting a lot of business from smaller shops. Of course, it could be dangerous to trust my memory in a critical situation, I couldn't even remember the command for building an NSS this morning. I had to look it up. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave Jones Sent: Monday, August 27, 2007 1:41 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs A completely uneducated guess would be 50%, and perhaps as high as 90%. Shops that are already comfortable with the IBM mainframe 'mindset' are much more willing, imho, to consider migrating workload to z/VM and Linux than organizations that have no previous mainframe experience. Schuh, Richard wrote: Out of curiosity, what percentages of the new licenses are for shops that fit the category z/OS shops who bring in Linux and z/VM? Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Monday, August 27, 2007 12:32 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs On Sunday, 08/26/2007 at 10:18 EDT, David Boyes [EMAIL PROTECTED] wrote: Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: The only way it is possible to ship RACF installed and enabled with the z/VM base is to provide a snap out ordering feature (a la z/OS) that ships with RACF uninstalled and disabled. The snap out feature results in a price reduction equal to the price of RACF. The rules for this sort of thing were ironed out by lawyers in prior centuries and are well established. 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. I'm sorry, David, but your brush is too broad. z/OS shops who bring in Linux and z/VM usually prefer RACF on z/VM as it is much easier for them to use, administer, operate, and understand. Why? Because RACF is extremely popular with z/OS customers. Alan Altmark z/VM Development IBM Endicott -- DJ V/Soft
Re: Ops privs
On 8/27/07, Kris Buelens [EMAIL PROTECTED] wrote: I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. It's a Dutch acronym for Bewust Onbeschonken Bestuurder (deliberately not-drunk driver) Rob (not Bob)
Re: Ops privs
I thought it quite the opposite; you had to be a heavy drinker to drive z/OS (or at least its predecessor). :-) Regards, Richard Schuh From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, August 27, 2007 1:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs I know why they're all called BOB: to drive z/OS, you can't drink ;-) About 10 years ago an action was organized in Belgium to avoid drunk drivers: people driving to a party should select a BOB, the guy that wouldn't drink alcohol and drive the company home. I don't know who selected BOB as name, but it was a success, and since then everyone here know who BOB is. I heard that a similar action was since then undertaken in other countries, but with another name than BOB. 2007/8/27, Adam Thornton [EMAIL PROTECTED]: I have no idea. z/OS sysprog attendance at z/VM and Linux sessions at conferences continues to grow. My in-box is getting more notes that start Hi. My name is Bob and I'm a z/OS syprog. [HI, BOB.] I wonder why they're all named Bob. That's sort of weird. Adam -- Kris Buelens, IBM Belgium, VM customer support
Re: Ops privs
Hello! I happen to know. Coffee. There are more coffee shops, like Starbucks but stranger then the ones around me, in their home city. Disturbing, but true. -- Gregg C Levine [EMAIL PROTECTED] The Force will be with you. Always. Obi-Wan Kenobi -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, August 27, 2007 4:43 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs If that is true, then I shudder to think of what the MS Windows people are abusing! I mean, I know that MS apologists are on dreamy dust and have little connection to reality anymore. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Buckles Sent: Monday, August 27, 2007 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Ops privs Sorry; supporting z/OS DRIVES one to drinking!
