× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



It seems to me the simplest solution is to have all of the parameters
available on the command but have the command call a C/L program which
determines which paramters to use and calls the API accordingly. You
could issue an informational message 'Parameter xyz is not valid for
this release - value ignored'.

Albert

On Fri, Oct 22, 2010 at 11:13 AM, Dave Murvin <davem@xxxxxxxx> wrote:
The solution to my problem is to use the PMTCTLPGM parm (Prompt Control
Program) on the command PARM statement.  I added this keyword to the
first input element of my command.  In my case the PMTCTLPGM determines
the current OS release and returns a value such as V5R2 or V5R4.  The
key to this solution is that the value returned by the PMTCTLPGM is only
used for checking the PMTCTL statements.  It is not really returned to
the command processor.  The command processor retains the parameter
value that was entered by the user, and that is what is passed to your
command processing program, not the value returned by the Prompt Control
Program.

Example:
PARM       KWD(FmObjName) TYPE(QUAL1) MIN(1) PROMPT('From Database
Object') +
                          PMTCTLPGM(*LIBL/DRME0162)

Value returned by DRME0162 is only used check the values in my PMTCTL
statements.

 PMTCTL1:    PMTCTL     CTL(FmObjName) COND((*GE V5R4))
 PMTCTL2:    PMTCTL     CTL(FmObjName) COND((*GE V7R1))

The PMTCTL statements are then used to condition the command parameters
that should be available at a particular release.

The only downside I see so far is that if you press F9=All parameters on
the command, you will see all the parameters for all the OS releases in
my case.  You will have to be sure that your command processing program
and validity checking program process any extra parameters correctly.

Thanks for all the ideas that got me on the right track for this solution.

On 10/19/2010 2:40 PM, Dave Murvin wrote:
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.

--
Dave Murvin

www.drmetools.com

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.