× 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.


  1.  Home
  2. MIDRANGE-L
  3. January 2014

Re: optional parm in CLLE

Use a *CMD front-end. This is the proper way to have optional parameters in the CL environment. With this, you can add new parameters as you need without breaking anything.

So you'll have:

1) New program with old name for backward compatibility. It calls the original program (with new parameters and logic added) as a command.

2) The *CMD interface.

3) The original program, now with a new name and the additional logic. It is always called via the *CMD interface (#2) and can either be called from #1, or called directly via the *CMD interface from any new programs.

When you want to add additional parameters down the road, you add them to the *CMD interface as well as the CL program. The *CMD can take care of passing default values or *null addreses for parameters that are unused.

On 1/27/2014 10:57 AM, Briggs, Trevor (TBriggs2) wrote:
Yes, that would work. Until you need to add another parameter... :-)

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jeff Young
Sent: Monday, January 27, 2014 11:52 AM
To: Midrange Systems Technical Discussion
Subject: Re: optional parm in CLLE

Easier to rename the original program, add the new parm(s) and
functionality, and then create a new program with the name of the old
that
takes only the parms that the original did and just calls the new
program
with the new parm(s) defaulted to blank/zero/whatever vaule desired.
When a program calls the *old* program, it will not have a problem, and
the
programs that use the new parm will call the new program (you need to
change them anyway to pass the new parm(s).

Jeff Young
Sr. Programmer Analyst


On Mon, Jan 27, 2014 at 11:24 AM, Briggs, Trevor (TBriggs2) <
TBriggs2@xxxxxxxxxxx> wrote:

This logic is sound but seems limited. You're making the assumption
that
new program PrgZ6 can handle all the new functionality and then call
PrgZ, but this won't always be the case. The new functionality maybe
so
entwined in PrgZ's logic that it can't be clinically separated like
that. In that case, I suppose it would be better just to make PrgZ6 a
clone of PrgZ with the new functionality added (and maybe move common
functionality to a service program).

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Monday, January 27, 2014 11:12 AM
To: Midrange Systems Technical Discussion
Subject: RE: optional parm in CLLE

"Wrap" the old program with a new program (or procedure) that handles
the variable. You're going to have to change every program that passes
the new parameter, why not also change the name of the called program
at
the same time?

PrgA, PrgB, PrgC all call PrgZ with four parameters. You want to add a
parameter when PrgB calls PrgZ. Have PrgB call PrgZ6 with the number
of
parameters in the first parameter. PrgZ6 calls handles the extra
parameters and calls PrgZ with four after (or before) handling the
extra
parameters. PrgA and PrgC don't have to change. Having made that
change
to PrgZ6, you can continue to expand the number of parameters in the
future without extending the wrapping.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor (TBriggs2)
Sent: Monday, January 27, 2014 9:57 AM
To: Midrange Systems Technical Discussion
Subject: RE: optional parm in CLLE

This assumes that you know up front that you may have a varying
number
of parameters. I suspect in many cases the requirement is to add a
new
parameter to an existing CL program without the necessity of
changing
every program that calls it.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dan Kimmel
Sent: Monday, January 27, 2014 10:51 AM
To: Midrange Systems Technical Discussion
Subject: RE: optional parm in CLLE

The time-honored technique is to pass the number of parameters in
the
first parameter.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor (TBriggs2)
Sent: Monday, January 27, 2014 7:29 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: optional parm in CLLE

Barbara,

I have used a similar function in the past (using the "optional"
parameter name in the CHGVAR FROM rather than the TO variable),
and
I
was unaware of the fact that false positives could occur. I
suppose
if
there were a limited number of acceptable values for the parameter
that
you could check against then the chances of "accidentally" finding
ones
of these in a "phantom" parameter would be negligible. But in
cases
where the parameter values could be a large number of values it
seems
from this thread that IBM gives us NO 100% reliable way of
determining
the number of parameters passed to a CL program. Is that so?

Thanks,

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara
Morris
Sent: Friday, January 24, 2014 7:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: optional parm in CLLE

On 1/24/2014 8:29 AM, Alan Cassidy wrote:

I just did this:
CHGVAR&VALUE3&PARAMETER3
MONMSG MCH3601 EXEC(DO)
SNDPGMMSG MSG( 'Did not receive 3 parameters') TOPGMQ(*EXT)
ENDDO
ENDPGM

Worked at least.

I just want to make sure that it's clear that this technique
should
absolutely never be used.

It often seems to work in testing, but it's almost guaranteed to
give
a
false positive at some point, indicating that a parameter was
passed
when it wasn't.

What's especially bad about this technique is that if your program
modifies a parameter that was not actually passed, you can cause
bizarre

and unpredictable errors that might show up long after your
program
has
returned.

--
Barbara
--

--
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.

**********************************************************
**********************************************************
**********************************************************
******************************
This message originates from Lincare Holdings Inc. It contains
information
which may be confidential or privileged and is intended only for the
individual
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or
use
the
contents of this message.
All personal messages express views solely of the sender, which are
not to
be attributed to Lincare Holdings Inc., and may not be copied or
distributed
without this disclaimer.
If you received this message in error, please notify us immediately
at
MailAdmin@xxxxxxxxxxx or (800) 284-2006.
**********************************************************
**********************************************************
**********************************************************
******************************

--
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.



--
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.



************************************************************************
************************************************************************
************************************************************
This message originates from Lincare Holdings Inc. It contains
information
which may be confidential or privileged and is intended only for the
individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use
the
contents of this message.
All personal messages express views solely of the sender, which are
not to
be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@xxxxxxxxxxx or (800) 284-2006.


************************************************************************
************************************************************************
************************************************************

--
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.