Re: Ops privs
On Friday, 08/24/2007 at 06:21 EDT, Rob van der Heij [EMAIL PROTECTED] wrote: 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. Command auditing is already provided by ESMs. Nothing would change in that respect. Oh, and how about RACF restrictions that apply to the LOGON (like terminal or time) ? How would that apply to the proposed commands? No change. The conditional access list for LOGON is not applied to other CP commands. Further, it only applies at the point the user is logged on. Once logged on, those restrictions are never imposed again. No double jeopardy. If you really think this is useful, then use different profiles in the surrogate class (e.g. MAGICBY.target) so that an installation can decide which end users are able to use this. That is what I originally envisioned and remains my fall-back position. Thank you, everyone, for your considered comments. I've gotten what I needed. I should point out, however, that the class G FOR command requires you to be the SECUSER of the target. With an ESM, if you are not the SECUSER, then LOGON BY authority is sufficient. Alan Altmark z/VM Development IBM Endicott
Re: OSA question
On Friday, 08/24/2007 at 03:01 EDT, O'Brien, Dennis L Dennis.L.O'[EMAIL PROTECTED] wrote: 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. Things changed quite a while ago. The address can start on even or odd. Device drivers on older systems may still reflect the original start-with-even requirement. Alan Altmark z/VM Development IBM Endicott
Re: OSA question
On 8/26/07, Alan Altmark [EMAIL PROTECTED] wrote: Things changed quite a while ago. The address can start on even or odd. Device drivers on older systems may still reflect the original start-with-even requirement. And I recall at one point the driver would tolerate any order, but expected an even virtual address to be an even real address as well... Rob --
Re: Ops privs
On 8/26/07, Alan Altmark [EMAIL PROTECTED] wrote: Command auditing is already provided by ESMs. Nothing would change in that respect. It's different type of auditing, with different audience. When I would be paged in the middle of the night, I could search the operator console for smoking guns. Being able to see who was tampering with the thing the night before is enough to divert the call. Many installations will not allow the average support person to run SMF reports. And if they allow, it's not as much fun that I would like you to wake me up for it... Rob
Re: How to insert zvse4 installation tapes without barcode label on 3953/3584 library
Of course, the problem is independent of the operating system you want to install. The problem is not the standard label written on the tape but barcode label on the cartridge. The library does not check the written magnetic SL on the tape when importing it. In my case the customer has opened in parallel a pmr on the hardware and they gave the same explanation that I gave here on the list. The local IBM service guy will give the customer some barcode labels which he can stick on the cartridge and everything is fine. The easiest way for IBM to solve the problem is to put a barcode label on each cartridge per default like ZVM531, 532 and so on or VSE411, 412 , ZOS191, 192, ... At the worst case the customer has such a label in his library, - which I don't really believe -, and he has to eject these cartridges, import the installation cartridges, copy these cartridges to own ones and reimport the original ZVM-, VSE- or ZOS- labeled cartridges. The other possibility is to give the library the functionality in the microcode to import unlabeled cartridges like it was on the 3494. If IBM doesn't give the customer one of these possibilities they can soon begin to stop creating cartridges as the 3584/3953 libraries will more and more replace the 3494 installations and deliver the software only on CD/DVD. As this is currently possible on z/VM and z/VSE it is not on the self-defined Mercedes of IBM, z/OS. This has surely something to do with the amount of data (at least 6 3390-3) and the lack of a kind of virtual tape server as in VSE to read directly from AWS simulated tape files. kind regards Franz Josef Pohlen Alan Altmark schrieb: 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
Bundle RACF??? That might be a blow to the users of VM:Secure and other ESMs. Is it? Let's think about that: 1) The major difference between RACF and the alternatives is that all of the alternatives are easier to use, administer, operate and understand. How does bundling RACF change that? 2) Installing RACF or any of the alternatives involves a CP mod. Removing RACF and installing an alternative isn't any more complicated than removing the dummy RPI modules and replacing them with your chosen substitute. 3) How many of the alternatives are getting more than life-support style maintenance? CA doesn't promote VM:Secure any longer (not the strategic solution), and ACF2/VM isn't exactly healthy either. What else is left? 4) RACF (with all it's grotesque hideousness) shares (or can share) development costs with the z/OS version. Is it really worth asking IBM to duplicate that effort in CP just to get ESM functionality, or invent something else (implying all the development, testing, documentation and support) when it's a question of figuring out how to license something that already exists? 5) There are a fair number of places where CP and CMS command logging and authorization is inconsistent or REALLY hard to understand (take SFS auth for starters), and a lot of effort is performed to kludge around the absence of an ESM. Even a horrible ESM like RACF is better than no ESM. Why can't we kick up the base level a notch, if there's a fairly easy way to do it? It just strikes me as a waste of effort to keep kludging around with the base CP security model and inventing half a dozen different ways to do command authorization and logging if we can do it by asking IBM to step up the base model with something that doesn't require them to do (and maintain) new development. -- db
Re: Ops privs
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. Oh, we've been chatting about this one for a long, long time...he's long since corrupted. The problem is finding a way to juggle priorities to let him do it...8-) 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. 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? -- db
Vdisk under zVM 5.3
Is this funny or what!I just brought up zVM 5.3 from 5.1Defining a Vdisk as follows fails:CP DEFINE VFB-512 AS 0153 BLK 20and I getHCPLNM091E DASD 0153 not defined; vdisk space not availableBut CP DEFINE VFB-512 AS 0153 BLK 19does not fail. My user Vdisk limit was 75 blocks and I changed to Infinite but the attempt for 20 still fails. _ Messenger Café — open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline
Re: Vdisk under zVM 5.3
Look for this entry in SYSTEM CONFIG Vdisk Userlim 144000 blocks /* Maximum vdisk allowed per user */ Rick Richard R. Bourgeois Virtual Software Systems, Inc. 7715 Browns Bridge Rd Gainesville, GA 30506 770-781-3200 [EMAIL PROTECTED] _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Suleiman Shahin Sent: Sunday, August 26, 2007 10:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Vdisk under zVM 5.3 Is this funny or what! I just brought up zVM 5.3 from 5.1 Defining a Vdisk as follows fails: CP DEFINE VFB-512 AS 0153 BLK 20 and I get HCPLNM091E DASD 0153 not defined; vdisk space not available But CP DEFINE VFB-512 AS 0153 BLK 19 does not fail. My user Vdisk limit was 75 blocks and I changed to Infinite but the attempt for 20 still fails. _ Messenger Café open for fun 24/7. Hot games, cool activities served daily. Visit http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline now.
Re: Vdisk under zVM 5.3
Sorry I didnt see the whole note because it was in a preview window. What do you see when you query the limits? q vdisk syslim VDISK SYSTEM LIMIT IS 10817616 BLK, 55000 BLK IN USE Ready; T=0.01/0.01 23:43:57 q vdisk userlim VDISK USER LIMIT IS 144000 BLK Richard R. Bourgeois Virtual Software Systems, Inc. 7715 Browns Bridge Rd Gainesville, GA 30506 770-781-3200 [EMAIL PROTECTED] _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Suleiman Shahin Sent: Sunday, August 26, 2007 10:28 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Vdisk under zVM 5.3 Is this funny or what! I just brought up zVM 5.3 from 5.1 Defining a Vdisk as follows fails: CP DEFINE VFB-512 AS 0153 BLK 20 and I get HCPLNM091E DASD 0153 not defined; vdisk space not available But CP DEFINE VFB-512 AS 0153 BLK 19 does not fail. My user Vdisk limit was 75 blocks and I changed to Infinite but the attempt for 20 still fails. _ Messenger Café open for fun 24/7. Hot games, cool activities served daily. Visit http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline now.
