|
midrange.com
I do not have a V4R5 system to test on but would expect calling QSYGETPH
with 6 parameters to fail with CPD0172. And to throw in a wrinkle I would
expect a similiar test on V5R1 (passing more parameters than are defined,
such as 10) to succeed!
A difference is that on V4R5 QSYGETPH is an OPM *PGM and if you do a DSPPGM
against an OPM *PGM you often find a discrete number of parameters such as
'3 4' indicating (in this example) a minimum of 3 paramters and a
maximum of 4. This limit can be tested by CALL processing when calling
the program and so the system (rather than the API) can send CPD0172. The
API does not actually run in this scenario.
Now it just so happens that if you DSPPGM QSYGETPH starting with V5R1 you
see that the *PGM is now ILE and that the number of parameters is '0
255'. In this case CALL processing cannot determine that only 6 parameters
are defined and so CPD0172 is not sent. The API will run and as it only
attempts to access the 6 defined parameters the call will succeed. This
behavior however should NOT be counted on. The API could just as easily be
doing a test to determine if the number of parameters passed is greater
than 6 and then send it's own error. One possible reason for such a test
(in case you're wondering) would be provide upward compatibility for a
future release. By that I mean that you could on V5R1 pass a 7th parameter
of 'ABC' which works just fine (does nothing). Now you upgrade to a new
release X where parameter 7 is defined (for example as a Binary(4)) and all
of a sudden the 'ABC' being passed causes an error where it didn't
before... Checking for a maximum of 6 would avoid this incompatibility by
catching the error on V5R1.
Bruce Vining
Scott Klement
<midrange-l@scott
klement.com> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
09/15/2005 02:45 Subject
PM RE: WHAT was IBM THINKING?!?!?, Re:
QSYGETPH API
Please respond to
Midrange Systems
Technical
Discussion
> Parms have been there for awhile, just not with the same
> inter-relational requirements. The 2 optional groups were new in V5R1.
Actually, the "Error Code" parameter (which is an "optional parameter
group") existed prior to V5. The 2nd group (pwd len & ccsid) are new in
V5R1.
But what would happen on a V4R5 system if you specified all 6 parms? I
bet it'd still work, the parms would just be ignored (but I
haven't tried it.)
If that's the case, you can still write code that works on any release.
--
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 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.
