Hi, Dave:
You did not indicate what API(s) you are trying to call, or why.
I would *not* go with the idea of installing (or renaming) different
versions of the command, because then what would happen when the user or
customer upgrades to a newer version of the OS, some time _after_ they
have installed your command? *:-o*
You could do something like this:
1. Create a command where the first required parameter is the current
release, e.g.:
xxxxxxxxxx RLS(*CURRENT, *PRV, V5R2M0, V5R3M0, V5R4M0, V6R1M0,
V7R1M0) ...
2. create a prompt override program so that if you (or your users)
prompt the command, the prompt override program automatically supplies
the correct value for the RLS parameter. (In other words, if you are
running on V5R2M0, and you prompt the xxxxxxxxxx command, you will see:
Version / Release . . . . V5R2M0
on the prompt display.
3. you need to make all of those "optional" parameters "dependent" on
the value supplied in the RLS parameter. Look up the "DEP" command in
the command definition language.
4. Create a validity checking program (VCP) for the command so that if
the command is run in a CL program, the CL program can validate the
value sspecified for RLS. (HINT: There's an API for that; see
QSZCHKTG). Your validity checking program should also verify that none
of the "optional" parameters are supplied that are not valid for the
specified RLS, and depending on what the actual current version of the
OS you are running under. Each optional parameter should specify a
default of *NONE and accept a "*NONE" value when no value is specified
for that parameter.
5. In the command processing program (CPP), you need to recognize
*CURRENT and *PRV for the RLS parameter, and then substitute the correct
value for the current version/release the program is running under.
(HINT: There's an API for that; see QSZRTVPR).
I hope that gives you enough of an idea to "get you started"...
Cheers,
Mark S. Waterbury
> On 10/19/2010 4:40 PM, Dave Murvin wrote:
Hello,
I am looking at creating a command that calls an API that uses different
(additional) parms over various releases. What I would like to do is
create a command that uses this API and will run on multiple releases
(starting at V5r2), but still be able to use the new options that were
added in later releases.
I could make the command dumb and only use the options that were
available in V5R2, but I don't really want to do that.
About all I can come up with so far is to create different versions of
the command (including help text, command processor and validity
checker) for each release where the API parms were enhanced. Then when
the "application" is restored to a machine, determine the current
release for that machine and do a bunch of renames to get the latest
version that would run on that release during the post install process
This sounds doable, but also sounds messy.
Does anyone have any other options or ideas?
Thanks
midrange.com
