Re: Pitfalls of duplicated IBM commands when OS is upgraded?

All the previous solutions are good but let me offer another solution:
instead of customizing IBM commands, why not create a user-friendly set of
commands that wrap IBM's commands?

My XXM767 command builds/compiles any source member based on the name (I
have a member/object naming convention) and source member type. I have
pre- and post-compile logic built in and this provides additional control
over the process. Developers don't have to fuss with other parameters;
this reduces their workload. Finally, I can easily script single-object
compile processes with one simple command. For multiple related objects,
my XXM725 command compiles DSPF, PNLGRP, ILE RPG programs and service
programs, CL's, commands, and stored procedures (having a naming convention
greatly simplifies this) in one step. These commands make it easier for
developers, especially 3rd parties and offshore resources) to compile
correctly.

In each CPP, I always qualify the IBM command to QSYS. My experience
suggests the addition of a new and mandatory parameter on a compile command
is highly unlikely; this means you'll isolate yourself from OS changes.
I've used these commands since the 90's and I've never been forced to
change my programs to accommodate a new release. As IBM has added new
optional parameters (preprocessor options, etc.) and new values for
existing (access path page size), I've added additional parameters, with
defaults, to my user-friendlies.

Having "natural" command names (reference: in database, a "natural key" is
a value derived from the attributes of the data. An email address is a
natural key)--WRK, DSP, CHG--is great, especially if you're a touch
anal-retentive about naming standards (guilty!). And it made life easy for
IBM: GO CMDWRK and WRK* are handy. But when you're in the trenches,
WRKACTJOB, WRKJOBSCDE, and WRKSBMJOB are a pain. You can set up 28
one-letter commands (26 + $ + # + @ and without Q)--why isn't WRKACTJOB
just W?






On Fri, Feb 21, 2025 at 8:46 AM Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
wrote:

Not only adding parameters, but they have (in a limited way) changed
several defaults as well.

My standard answer to that question is you need a CLP program that
completes ALL THE CHANGES you have made so you can run it after the
upgrade.

For instance, have any print files been modified directly instead of making
copies, subsystem description changes, IBM supplied job description
changes? The list goes on, but you get the point. One CLP that sets all
of that and your upgrade will go somewhat more smoothly.



--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Fri, Feb 21, 2025 at 10:30 AM Rob Berendt <robertowenberendt@xxxxxxxxx>
wrote:

The standard recommendation is to say you need an IPL program which

deletes

and rebuilds any custom commands.
It is NOT out of the realm of possibility for IBM to add a new parameter

to

a command which the CPP is expecting.

On Fri, Feb 21, 2025 at 11:19 AM Dan Bale <

dan.bale@xxxxxxxxxxxxxxxxxxxxx>

wrote:

It's been ages since I last worked in a shop when an OS was upgraded.

I

think I know the answer to this, but would appreciate confirmation.

I've duplicated several IBM commands to shorter named commands in our
shop's tools library. (I know the PDM commands in QSYS are proxies to

the

same named commands in QPDA, so I duplicated those from QPDA.) Will
upgrading from 7.4 to 7.5 "break" the commands I duplicated from IBM
commands? I don't expect any of these commands (DSPMSG, WRKaaaPDM,
WRKSPLF, etc.) will have any of their function changed.

- Dan Bale
*** CONFIDENTIALITY NOTICE: The information contained in this
communication may be confidential, and is intended only for the use of

the

recipients named above. If the reader of this message is not the

intended

recipient, you are hereby notified that any dissemination,

distribution,

or

copying of this communication, or any of its contents, is strictly
prohibited. If you have received this communication in error, please

return

it to the sender immediately and delete the original message and any

copy

of it from your computer system. If you have any questions concerning

this

message, please contact the sender. ***
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.