RE: Default for command without default value?

Rob:

Sorry about taking so long; way too much work and too many items on this list.


On Fri, 10 August 2001, rob@dekko.com wrote:

> I still disagree.  A user can still hose this up.  If I replace the command
> in QSYS with my new version then it might have the same effect as forcing
> the vendor to check every parameter.  Since we can do it this way, allow us
> to do it with the exit point to minimize the risk.
> You're right.  A shop needs to be aware of the risks associated with
> changing the defaults on a command.

Yes, certainly, the original command definition can be changed. But there can 
be serious risks. Not only 3rd-party software but IBM-supplied software may be 
affected if command objects in QSYS are changed. (I suppose it's technically 
possible to affect IBM software seriously enough that functions needed to 
restore original objects wouldn't even work, possibly bringing the need for a 
system reload. A related example would be trying to restore command definitions 
after executing DLTCMD RST*.)

I believe that any customer function that alters QSYS facilities should be 
isolated. In this case, that means one exit program for the command in QSYS and 
another for the command in another library. And make certain it's fully tested 
in the other library first and that there's a way to remove the one from QSYS 
immediately; i.e., don't mess with commands such as ADDEXITPGM and RMVEXITPGM.

In short, if a customer messes with QSYS, all bets are off.

>
> Options I wish to change include RPG compilation defaults.  And forget
> fancy PDM options.  I want it to apply regardless of where the command is
> called:  PDM, command line, CODE/400, etc.  I don't think the vendor
> software will come crashing to a halt if I change from
> DBGVIEW(*STMT)
> to
> DBGVIEW(*LIST)

Although it's true enough that DBGVIEW(*xxx) is unlikely to crash 3rd-party 
software, other commands and parameters aren't so insensitive.

You wrote about intelligently changing parm values but did not describe how 
that could be done against 3rd-party (or IBM-supplied) software. How can you 
intelligently determine what values will be required inside software that you 
cannot see the source for?

If I execute a specific OVRDBF from within RPG, I need to know it will run 
exactly as I code it. Otherwise I cannot support my product. I need a reliable 
reference point and IBM-supplied QSYS is all there is. I will qualify to 
QSYS/OVRDBF and expect it to work as the CL Reference says it will work.

The more I think about this, the more wary I become of what this exit point 
will do in the future no matter how IBM enhances it. Discussions such as this 
one are one way to get systems programmers thinking about implications of what 
they might do, so it's definitely worthwhile.

Tom Liotta




--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/