For NEEDPASS, there was some relief in 2002. But, I still change the
1x0CMDS file. Below the converstaion I had with Mark Ritter on the subject.
--
Kris Buelens,
IBM Belgium, VM customer support
2007/11/8, Jim Bohnsack <[EMAIL PROTECTED]>:
>
> Everytime I install a new DIRMAINT (every 5 years of so), I have the
> same problem. I brought up the level that shipped with zVM 5.3 today on
> our production system and as soon as I entered a DIRM command, I was
> asked for my logon pw. I am in the AUTHUSER list and about everywhere
> else in DIRMAINT and the system that I can give myself authority. I
> solved the problem for that one DIRM command by entering the pw and then
> DIRM NEEDPASS NO. I don't want to have to explain to the half dozen or
> so people whose job it is to add mdisks and new users.
>
> What is the other command that I can use to globally allow everyone and
> then just depend on AUTHUSER?
> jim
>
> --
> Jim Bohnsack
> Cornell University
> (607) 255-1760
> [EMAIL PROTECTED]
>
---------------------------------- old conversation
--------------------------------------
Subject: Re: NEEDPASS NO
From: "Mark Ritter - IBM DirMaint Support" <[EMAIL PROTECTED]>
Organization: W3 Pilot INN Servers
Date: Wed, 27 Feb 2002 23:27:35 UTC
References: 1
Hello, Kris.
No, I don't think you've missed anything. You are correct; there is no
NEEDPASS= entry in the CONFIG* DATADVH file(s). DEFAULT_USEROPTN= is
indeed the place where this was implemented.
Let's look at each one independently.
LNK: Old values=1|0, default was 1 (ENABLE); requirement was to change
to the safer default of 0 (DISABLE) for both new users and existing
users. New values of 0|3 accomplish this. The 1 becomes invalid,
changes to a zero; users who need LINK ENABLE must re-issue the command
to change this option to 3.
LOG: Old values=0|1; default was 0 (OFF); requirement was to change to
the safer default of 1 (ON) for both new and existing users. New values
of 1|2 do this. The 0 becomes invalid, changes to 1; users who need LOG
OFF must re-issue the command to change this option to 2.
NPW: Old values=1|0; default was 1 (YES). I know from experience that
many customers have changed their 140CMDS and 150CMDS files to change
each command from Y to N. I chose to allow flexability here just because
it seemed like the right thing to do. This allows customer tailoring of
the default for new users, without affecting existing users. There was
no requirement in front of me to force a change for existing users.
RCM: Old values=0|1|2; default was 1 (ON). There was no specific
requirement involved here. I chose to allow flexability here just
because it seemed like the right thing to do. This allows customer
tailoring of the default for new users; without affecting existing users.
I'm not aware of any customers changing this default.
SMS: Old values=0|1; default was 0 (OFF). Again, there was no specific
requirement involved here. I chose to allow flexability here just
because it seemed like the right thing to do. This allows customer
tailoring of the default for new users; without affecting existing users.
I'm not aware of any customers changing this default.
Making global changes to the *DVHOPT records isn't that difficult. The
following commands will do it nicely:
DIRM DISABLE
DIRM BACKUP
DIRM CMS PIPE (END ?)
< USER BACKUP G |
A:FIND *DVHOPT_|
CHANGE /NPW1/NPW0/ |
B:FANINANY |
> USER INPUT E
?A:|B:
where: (1) you have the authority to issue all of these commands (the
default command set S will do them all), (2) the CMS PIPE command is
entered all on one line and there is no blank between the _ and the | in
the FIND stage, and (3) you are using the default filemodes of G for
DIRMAINT's 1DB backup disk and E for DIRMAINT's 1DF directory source
disk. Presuming that you get return code zero (DVHREQ2289I) for all
three commands, then issue a DIRM BATCH command to submit the following:
CMS ERASE USER DIRECT E
RLDDATA
(These two commands must be processed as a single batch file, or entered
from DIRMAINT's console. If issued as separate DIRM commands, the DIRM
RLDDATA will fail because the submitter's password is neither waived nor
available for verification. If that happens, you'll have to log on to
the DIRMAINT id to issue the RLDDATA command. :-) Then:
DIRM ENABLE
Regards;
Mark Ritter - IBM DirMaint Support
Mark Ritter/Endicott/[EMAIL PROTECTED] - [EMAIL PROTECTED]
DirMaint Support - Dept G32G / Bldg 250-2
IBM Corporation - 1701 North Street - Endicott, NY 13760
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - -
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I was installing the new service for Dirmaint, and found this in
VM62609
> > The single most common customization of the DirMaint product
> > other than the expected AUTHFOR CONTROL, CONFIG* DATADVH,
> > EXTENT CONTROL, and PWMON CONTROL files, are overriding the
> > password required flag for each command in the 140CMDS
> > DATADVH and 150CMDS DATADVH files.
> > Customers should have the capability to set the default
> > NEEDPASS flag to NO for all users on their system using a
> > CONFIG* DATADVH file(s) entry, without having to modify the
> > the IBM supplied 140CMDS DATADVH and 150CMDS DATADVH files.
>
> This made me happy as I would no longer need to change the 140CMDS
> and 150CMDS file anymore. But, in the new sample config file, there is
> no model for a NEEDPASS statement, and adding " NEEDPASS= NO" doesn't
> help.
> (the details in the Apar description don't mention the NEEDPASS
change
> so it was not a 100% surprize when it turned out not to work).
>
> Maybe the new DEFAULT_USEROPTN= LNK0!3 LOG1!2 RCM0!1!2 SMS0!1 NPW0!1
> is meant to solve the problem. But, as I understand the meaning of
> default in "DEFAULT_USEROPTN", I guess it won't affect the settings for
> existing users; for them DIRMAINT will take the
> *DVHOPT LNK1 LOG0 RCM1 SMS0 NPW1 LNGAMENG PWC19920525 CRC?M
> line from the directory entry.
> When scanning the directory, I found a mixture of NPW1 and NPW0.
>
> My guess is that existing installations still have to change the CMDS
> files unless they'd update all *DVHOPT cards to become NPW0
> (a hell of a job).
> Do I miss something ? Is the Apar text misleading ? ... ?
>
> Thanks, Kris Buelens, VM Customer support, BUELENSC at BEVM
