Our ESM is VM:Secure. Years ago, when attempting to address the issue of MDISK comments that stay _with_ the MDISK record, we discovered that with VM:Secure:
1) Only the 1st three tokens after the link mode (the positional passwords tokens) must be 8 or fewer characters. 2) There is no limit to the number of tokens after the link mode, just as long as they fit in the first 71 bytes (allowing for serial numbers at the end). 3) With VM:Secure's RULES facility active, the passwords are never, ever used. (I.e. this does not apply to VM:Direct) I don't recall if CA ever documented this nice capability. E.g. part of an olde VM:Backup directory entry: * VM:Backup 3.4 G0506 SP01, VM:Mgr 2.8 0507 SP06, CDTAPE Format MDISK B1F6 3390-3 3319 10 VMPP04 RR * H. A. Between-release fixes MDISK B192 3390-3 1097 20 VMPP03 RR * VMB 3.4 G0506 SP01 The "H. A." stands for Hewitt Associates, but conveniently fits in the first 3 password tokens, taking little space. They could easily have been * * *, or ; ; ; We have no standard comment convention that users could use to guess passwords if we came up without the VM:Secure Rules Facility active. We've never had to bring up CP without VM:Secure Rules active, except on 2nd level test systems when building a new z/VM system before VM:Secure was installed. I too, would vote for a comment extension to the MDISK record. But not in Kris' C-like notation; that takes up an extra character in an already limited space. I'd vote for an '*' (a common leading comment character), or TCPIP's leading ';' but without requiring an adjacent trailing blank (something that has bitten me repeatedly in TCPIP config files). Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Kris Buelens" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" <[email protected]> 02/08/2008 11:42 AM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: How comments treated by DIRMAINT I somewhat agree with you Alan (and these minidisks are indeed already in the HCPRww so that CP doesn't even consult RACF for a RR link. As for these passwords: there is no real convention thet the passwords msut be "monyyyy", they can be anything that explains the content/level. It would be more secure without them, but I prefer knowing what level is on an MDISK and avoid VM (or VM application) outages due to mistakes as I consider the risk of someone deactivating RACF (or starting a CP without RACF) much smaller. You can not my vote to extend the MDISK statement with a COMMENT field that DIRMAINT will always keep with the MDISK card. e.g. a C-like notation (and waw more than 3 words as comment, and no prereq for an ESM) MDISK 019E 3390 1735 190 VTE521 MR ALL // Fixes for CA products DEC2007 2008/2/8, Alan Altmark <[EMAIL PROTECTED]>: > On Friday, 02/08/2008 at 10:06 EST, Kris Buelens <[EMAIL PROTECTED]> > wrote: > > If you are lucky enough to have an ESM like RACF, what means the LINK > > checks are not password based, you can work the way I set things up > > for my client: use the minidisk passwords as descriptive comments. > > Here an extract of MAINT's entry: > > MDISK 0490 3390 2362 107 VTERES RR ALL ZVM520 NOV2006 > > MDISK 0493 3390 1433 167 VTERES RR ALL ZVM520 NOV2006 > > MDISK 019D 3390 681 146 VTEBKP RR ALL ZVM520 NOV2006 > > MDISK 049E 3390 2687 190 VTERES RR ALL ZVM520 NOV2006 > > MDISK 0CF1 3390 587 80 VTERES RR > > MDISK 0CF2 3390 408 80 VTEBKP > > MDISK 0190 3390 399 107 VTE52R MR ALL ZVM520 AUG2007 > > MDISK 0193 3390 0001 167 VTE521 MR ALL ZVM520 AUG2007 > > MDISK 019E 3390 1735 190 VTE521 MR ALL FIXESCA DEC2007 > > Side remark: > > As one can see, we set the read password to ALL for these "general > > public" minidisks. This way if we'd be forced to IPL without RACF, > > people would still be able to LINK RR without password (but, even > > though I still have a CP nuc without RACF on CF1, we never had to use > > a CP-without-RACF in the 19 years we run with RACF > > Since they are public and you don't require auditing of their access, you > can add them to RACF's GLBLDSK macro to prevent RACF from protecting or > auditing read-only access. > > Unfortunately your use of the password fields in that way creates a > security exposure. If the system does come up without RACF, OR if the > VMMDISK were deactivated, anyone who knows your naming convention can get > r/w access. If, in 19 years, you never had to run without RACF, then I > think the risk of the security exposure exceeds the risk of a RACF outage > sufficient to make you run without RACF. > > Alan Altmark > z/VM Development > IBM Endicott > -- Kris Buelens, IBM Belgium, VM customer support 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. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email.
