× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

(914) 251-9400
(914) 251-9406 (fax)

+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.