|
midrange.com
A very well thought out and clear response. I understand completely.
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. But allow us to make an intelligent
decision and give us the freedom of choice. Otherwise we'll be forced
into:
RNMOBJ OBJ(QSYS/OLDCMD) OBJTYPE(*CMD) NEWOBJ(OLDCMDX)
And creating a new command, calling our custom program, to execute the X
version of the command.
See, we can get the defaults set our way this way. Which is more dangerous
to the vendor software?
I) using the API to override the parameters?
II) using the RNMOBJ and custom command approach?
I argue that II is because the odds of screwing it up, or omitting
parameters "that no one really ever uses" is greater. The counter argument
is that your weaker developers can't figure out prompt control and some
special parameters and they'll abandon the project.
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)
Now, can I change this with the API or do I have to RNMOBJ the command and
create my own?
Rob Berendt
==================
A smart person learns from their mistakes,
but a wise person learns from OTHER peoples mistakes.
thomas@inorbit.com
Sent by: To: MIDRANGE-L@midrange.com
owner-midrange-l@mi cc:
drange.com Subject: RE: Default for
command without default value?
08/09/2001 09:41 PM
Please respond to
MIDRANGE-L
Rob:
On Tue, 07 August 2001, rob@dekko.com wrote:
> No, it seems like you understand my point. We just differ. I feel that
> the command should be consistent, qualified or not. You feel that there
> should be some 'back door' to override the efforts to standardize a shop.
How long has it been since you looked at how many PARMs are available for
CrtCtlAPPC? and all the dependencies?
I picked that command as an example because it's complex, but plenty others
exist that are also complex. Coding CL so that _EVERY_ parm value on
_EVERY_ command is specified including _EVERY_ possible default value would
get horrendously complex in a hurry. I'd say that's especially true because
you'd have to go back to _EVERY_ existing CLP and fill in everything.
No, I don't mean you individually. I'm referring to any 3rd-party software
vendor who includes CL anywhere including via calls to QCMDEXC, QCMDCHK,
QCAPCMD or what ever. Third-party software suppliers need some kind of
reference to rely upon. This can usually be counted on as being the command
definitions supplied by IBM in QSYS.
If that reference specification couldn't be counted on, if an exit program
forced every reference to any command named CRTCTLAPPC (no matter what
library) to use specific parm values possibly contradictory to objects or
attributes of objects created by other sections of code, if the 3rd-party
developers had no possible way of knowing what standardization was being
forced, chaos could result. Attempting to run a CLP written even the
previous day would yield "unpredictable results".
For the sake of discussion, let's say that a company decided to standardize
printerfile names and attributes. The exit program enforced this
standardization by forcing values. But a 3rd-party application has it's own
internal naming structure and required attributes that are expected to
avoid any conflicts with customer printerfiles, so an OVRPRTF command is
executed to guarantee specific parm values. Ideally, 'QSYS/OVRPRTF' can be
used to get a level of confidence.
But you want to take that away? Would you even trust every in-house program
written in the past? Which commands would you feel comfortable hadn't been
"standardized"? If you were(are?) a 3rd-party developer, how do you propose
providing product support?
Interesting times dead ahead.
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/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@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 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.
