|
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/
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.
midrange.com
