RE: Using CHGCMDDFT

I agree with Al that this command can be dangerous in the wrong hands,
but so can many other commands.
Now what really does SUCK is that the default authority for this command
is *PUBLIC *USE.
I suggest you change it to *PUBLIC *EXCLUDE - and if you have the S/38
environment installed don't forget to change the authority to the
CHGCMDDFT *CMD in library QSYS38 as well as the one in QSYS.
(Of course, the user would still need to have the appropriate authority
to the command they were trying to change).

I had one customer who changed the default on PWRDWNSYS to
RESTART(*YES).
I issued a PWRDWNSYS to shut down the machine so I could install an
Ethernet card.
I waited for it to power down, and waited, and waited, and waited
.........    :-(



Neil Palmer                                AS/400~~~~~      
NxTrend Technology - Canada   ____________          ___  ~     
Thornhill, Ontario,  Canada   |OOOOOOOOOO| ________  o|__||=   
Phone: (905) 731-9000  x238   |__________|_|______|_|______)   
Cell.: (416) 565-1682  x238    oo      oo   oo  oo   OOOo=o\   
Fax:   (905) 731-9202       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
mailto:NPalmer@NxTrend.com        http://www.NxTrend.com


> -----Original Message-----
> From: Al Barsa Jr. [SMTP:barsa2@ibm.net]
> Sent: Saturday, March 07, 1998 4:42 AM
> To:   MIDRANGE-L@midrange.com
> Subject:      RE: Using CHGCMDDFT
> 
> At 10:48 PM 3/6/98 -0600, you wrote:
> >You can change defaults for any parameter on any command.
> >Did you try it and have a problem ?
> 
> 
> CHGCMDDFT is one of the most powerful, and most dangerous command
> available
> on the system.  I really have a love/hate relationship with this
> command.
> (Mostly hate!)
> 
> For example, there are many valid uses of this command.  You might
> want to
> DENSITY parameter on the INZTAP command to a *QIC media into lower
> density
> for compatibility, so you might change the DENSITY parameter from
> *DEVTYPE
> to something else (i.e.: something lower).  This is an OK thing for
> tape
> distribution into other compatibility tape drives.  But I have seen
> many
> people abuse this command.  I once found a System/38 where the RSTLIB
> parameter of the RSTLIB command had been changed from the default
> (*SAVLIB)
> to a fixed name.  (Think about, this could really suck!)  This way,
> anything restored to a system came into a specific library for
> immediate
> scrutiny of a security officer, to validate restored objects.  As a
> programer, how do I deal with this possibility?
> 
> In theory this command sounds like a good idea, right?  Well maybe?
> But as
> an application provider, if I cannot count on the fact that any QSYS
> command has the correct defaults, what do I do?  Do I specify the
> default
> value (that I expect) in every command in every CL program that I
> code?
> Tough stuff!  What happens what a new parameter with an completely new
> default is added in a future release?  Scary stuff!
> 
> Lets go one step further.  As an application provider (where I supply
> my
> own commands), can I assume that no one has mucked with the default
> values
> of my commands?!?!
> 
> If I anyone would have asked for my input this (assuming my input
> would not
> have permitted killing the command completely), this command would be
> severely more restrictive.  Possibly it should have been created so
> that it
> could not change a default for a command in QSYS, or possibly the
> initial
> command default for any command should have been retained in a "hidden
> space", and then give me the option when I create a CL program to
> specify
> an option (this is my fantasy, not a reality) like 'Use original
> default
> (USEORIGDFT)', so I can not worry about the abuse of this command.
> 
> I understand that comments about this command are controversial, and I
> don't want to start a long chain of notes.  But if I had my say, this
> command would have never been created.  (Maybe I should have said that
> this
> commands SUCKS, but the last time I used this (semi-RESERVED) word, I
> took
> a lot of @#$%.
> 
> Al
> Al Barsa, Jr.
> Barsa Consulting, LLC.
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---