Omitting parameters in CLLE

5580 pts.
Tags:
CLLE
MCH3601
I was adding a couple of parameters and monmsg mch3601 to a CLLE function called from many and unspecified programs. To avoid it falling over I was being careful to ensure that the first executable code was a Chgvar / monmsg mch3601 of the parameter which may have been omitted on a call from an unchanged CL. When I was frightened by finding the clipping below, from Barbara Morris no less. Does this still apply? Can anyone improve on the technique? Surely i5 is too grown up to allow a bad program to corrupt data. - - - - - - - - - - - - - - - - - - - You can monitor for MCH3601 to check for unpassed parameter. ============================================================================ CLLE parameter checking like %Parms in RPGLE Posted by Guest.Visitor - 2000/10/10 06:43 _____________________________________ Gene, that's not reliable. There's no guarantee that you will get a MCH3601 if the parameter isn't passed; there may occasionally be a valid pointer where the CLLE program/procedure is looking for the parameter. If you use that "parameter"'s value, your program won't run properly, and if you change that "parameter", you will corrupt some storage, who knows where (possibly different every time, depending on what calls were made before the CLLE was called ). When you corrupt storage, if you're lucky you'll get a nice noisy exception; if you're unlucky you'll corrupt more storage, and possibly your database will get corrupted. Barbara Morris, IBM Toronto Lab, RPG Compiler Development ============================================================================

Answer Wiki

Thanks. We'll let you know when a new response is added.

bad form to answer my own question, but somehow it didn’t get an ‘answer’ only a discussion.

The geeks who made this interface didn’t think of that, so it shows up as ‘unanswered’

If it was ‘My’ interface I’d be putting ain a change requirement..

:-)

Discuss This Question: 10  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • BigKat
    Why would IBM make it possible to CALL a CL program with an incorrect number of parameters, and NOT provide a RELIABLE way to determine if they were passed???
    8,350 pointsBadges:
    report
  • Cwc
    That surprises me a bit too, Yorkshireman, though I would expect that if you did get a valid pointer even for an unpassed parameter, that it could only affect storage of the current job and not other jobs in the system, and certainly not critical OS functions. I was curious and found these two articles, in case you haven't already seen them. http://www.itjungle.com/fhg/fhg081104-story02.html http://www.itjungle.com/fhg/fhg092204-story03.html There was one time that I needed to conditionally use a parameter in an ILE CL program that wasn't necessarily passed, but I used a method to check what was in the call stack to determine whether or not the calling program would have passed the parameter or not.
    4,290 pointsBadges:
    report
  • Cwc
    Those URLs got messed up in my last comment. Here they are again: http://www.itjungle.com/fhg/fhg081104-story02.html http://www.itjungle.com/fhg/fhg092204-story03.html
    4,290 pointsBadges:
    report
  • Yorkshireman
    Thanks Cwc - I've seen the previous discussion oby 'Ted' about omitting parameters, and bypassed this when it came up in google. It seems to confirm the danger of an unspecified parameter 'happening' to contain a valid pointer. If Barabara Morris says it's a bad thing, then it's a bad thing. Mind, I still expect it to corrupt storage in 'my' job - though that *could* include database data I suppose. So - no good answer then. More headscratching. I was expecting this to have been fixed by now. I wonder if the problem is the same for all data types of the parameter? BigKat - well -= they do give you an MCH3601 message - if you then trap it and ignore it, whose fault is that. Same as the folk who code monmsg CPF0000 - to catch 'all errors' and continue processing. . .
    5,580 pointsBadges:
    report
  • BigKat
    I meant that you could not RELY on getting a MCH3601 (or some other) message if a parameter wasn't explicitly passed to THIS program or that there wasn't a %parms that could be tested. The fact that it might find some other pointer when you can omit parameters is just wrong. With that being the case, I would rather CLLEs not be able to omit parameters rather than maybe have them grab onto something else. Kevin
    8,350 pointsBadges:
    report
  • WoodEngineer
    Yes, I've also wished for a CLP version of RPG's %parms function. Our solution is to create a command to call the CL. By coding default values in the command definition for the optional parms you can get around the problem quite nicely.
    6,875 pointsBadges:
    report
  • Yorkshireman
    Thanks to everyone for comments aned suggestions so far. If this was going to be new stuff I'd originated then I'd provide a command with validation functions, or use RPGLE, or, in fact, I'd make it a procedure - anything but what I've got. Which is, that the CLLE has to accept a call from anywhere else that pre exists, which will NOT get a recompile, so will not be 'passing' any values. In fact, the new parms are character - file names. so the question of their memory location containing a valid value doesn't arise. Because they are uninitialised though, the 'first touch' within the code throws an exception, which needs to be trapped. I suppose the alternative action needs to be a CHKOBJ for a *FILE in this case, just in case a random collection of characters could be used as a file name. There again, it would seem that an entirely new version of the pgm, used to receive the revised call, is the way to go. The old pgm (by name) is retired, and exists just to receive old calls, and calls the new pgm. The (only) calling point that needed the new parms calls the new pgm directly. One more object to slow down execution and be added to the 6 million lines of code and be managed. (sigh) I *hate* old hand coded crap...! ! !
    5,580 pointsBadges:
    report
  • Gilly400
    Hi, Maybe it's an idea to create a log of which programs call this and with which parameters. Could be useful for maintenance purposes. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • bvining
    I am confused. The original request refered to'function' and 'omitted' parameters -- which I interpret as meaning you have a procedure where you want to test for omissable parameters. The MCH is not reliable in this situation. Now it sounds like you have a *PGM (rather than a procedure/function). In the case of a CLLE *PGM the MCH check is reliable. A followup to Barbara's note can be found here where it's qualified that the limitation is with procedure calls, not program calls. Bruce Bruce Vining Services
    6,620 pointsBadges:
    report
  • Yorkshireman
    Yes, it does that - I wrote a little general purpose function which logs the caller of the program it's initiated from. I know what functions call this function, even in the soup we call 'system' impact analysis reveals all the calling points. The difficulty is that, even for a recompilation, the recompilaed function will need to pass through 'testing' which would a) take an age and b) cost a lot {oh, and c) achieve nothing !} This started as one of those 'simple' little mods which strayed off into an intellectual chase for 'the best way' of doing something. Always fascinating. As the irishman said when asked for directions / irish accent on 'Sure, and if I was wanting to go there from here, then I would be starting out from somewhere else" /irish accent off - with no racial or stereotype offence intended to any readers. Maybe it should be a Dalesman who says it, but no-one would know how to reproduce a North Yorkshire accent. Yorkshireman
    5,580 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following