On 04 Jun 2013 06:12, Franco Lombardo wrote:
Dear IBM, what a bad idea!
Or perhaps... A good idea for implementing a corrective to a poor
design, long overdue, but sadly, a poor implementation.
How anyone ever could have justified the original design as
reasonable and\or sensible should have been laughed out of the design
discussion. IMO the original as-documented apparent /design/ reflects a
probable lack of _actual design_ discussion and\or legitimate review by
the what was called the [system] Design Control Group:
IBM i 7.1 Information Center -> Networking -> TCP/IP applications,
protocols, and services -> i5/OS NetServer -> Administering i5/OS
NetServer -> Disabled user profiles
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzahl/rzahlenableadisableduser.htm
_i Enabling a disabled user profile i_
"You can re-enable a user profile that has become disabled by using
System i® Navigator or by changing the user profile.
...
You can also enable a disabled i5/OS NetServer user by changing the user
profile. To change the user profile, enter the following command:
CHGUSRPRF USRPRF(USERNAME)
where USERNAME is the name of the user profile you want to re-enable.
You can exit the Change User Profile display without making any changes
to the properties for the user profile."
That additional clause "You can exit... *without making any changes*
to ... the user profile" should have figuratively *screamed* at the
reviewers, calling out the ridiculousness of the /implementation/ which
was presumably being passed-off as the /design/ for the feature.
IMO they should have [long ago] added a new parameter to the
CHGUSRPRF to allow the re-enabling effect. However the command should
have shipped [on a new release], with a default special value similar to
the *NOCHG for the EIMASSOC() parameter; i.e. not the special value
*SAME as typically expected. After applying the [new release or the]
PTF delivering the new copy of the CHGUSRPRF, the CHGCMDDFT could be
issued to change the default to effect the re-enable action, regardless
that would be contrary to the corrected design intention of the default
invocation, but changing that command default would allow the command to
to remain consistent with the prior [release or] pre-PTF effects. FWiW
since some release, PTFs including commands was made possible without
regard to the installed language, thus ameliorating the past requirement
to make such changes only on a /new release/ as alluded just above.
For example, if the CHGUSRPRF command had added a new parameter
NETSVRSTS, then it could have shipped with a default special value and
help text similar to the EIMASSOC:
Help NetServer status (NETSVRSTS) - Help
Specifies whether the status of the NetServer user profile
should be re-enabled or disabled.
Note.
1. This information is not stored in the user profile,
thus is not saved or restored with the user profile.
*NOCHG
The status of the NetServer user does not change.
*ENABLED
The user profile is valid for NetServer access.
*DISABLED
The user profile is not valid for NetServer access
until an authorized user re-enables the user.
For any system that wants to maintain the effect of a CHGUSRPRF
[albeit actually as a completed CL request, by pressing Enter; not by
just prompting the command as the earlier doc link seems to imply], then
they could issue CHGCMDDFT CHGUSRPRF 'NETSVRSTS(*ENABLED)' as part of
their system Change Management.
midrange.com
