RE: Do third party products add access paths to system tables often?

Mark--

Well, we don't change the commands in QSYS-- but we do clone them into a library ahead of QSYS in the library list.

I see nothing wrong with changing command defaults-- we've done that to tweak the compiler defaults (including the CRTBND* commands) and other "CRT" commands; and tweaked the SAV commands to include the access paths, SAVFDTA(*YES), and set the TGTRLS(*CURRENT) (or set it to the previous version when we're migrating the test system before the production system).

We have a program, carefully maintained, that we can run at OS/upgrade time to delete our copy of the command, re-clone it from QSYS, and re-apply our defaults. This program also tweaks user authority for some of the commands.

I feel there is nothing wrong with this kind of 'system tuning.' We do the same thing with some of the data areas IBM allows to change the behavior of several system functions (such as how overlays align on the page), and how some other print functions work.

I think your 2nd point about creating commands with the same name as IBM's is valid when the command 'we' create is a replacement for IBM's command, and not a default-modified version of IBM's.

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxx> On Behalf Of Mark Waterbury
Sent: Thursday, November 15, 2018 12:11 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Do third party products add access paths to system tables often?

Hi, David:
Thanks for clarifying that situation.
Like any other platform, IBM i provides a number of ways that users can shoot themselves in the foot.  Some of my favorite examples include:

- changing the defaults on IBM-supplied commands
- creating commands with the same name as IBM-supplied commands and placing them in a library ahead of QSYS

Just to name a few ...
Thanks for sharing.
Mark