Re: Is there any way to monitor parameter mismatch error duringpgmcalls in CL or RPG?

Ali Ekinci wrote:
> > > In the following CL, I am making a call and expecting MYPGM to have 3 
> > > parameters, but if the
> > >pgm doesn't have the proper parameter list, I just wanna catch it and 
> > >avoid. 
Then Barbara Morris wrote:
> > But why are you trying to call a program with possibly wrong parameters
> > like this?  When you don't pass the right parameters, there is no
> > guarantee the program will fail; it may just silently go ahead and do
> > the wrong thing.
Then Ali Ekinci wrote:
> ...
> Here is why I am trying to call a mysterious pgm.
> Our product lets users to generate and compile user exit programs to 
> accomplish their specific needs. We have 3 standard parms in each pgm: 
> Process?/ShutDown?/MessageID and we leave the pgms open until the user 
> session ends. If the user already opened a user exit pgm, and then 
> during the same session wants to make a change and recompile it, we 
> used to force user to sign off and sign on back again, so that the 
> newly compiled user exit pgm is used versus the one in the call stack.
> Our solution was to call the pgm with Process=*no/ShutDown=*Yes, and 
> if an earlier release version of the user exit pgm (with more parms) 
> exists, expecting it to fail, but was hoping the catch the parameter 
> mismatch with monmsg. Having never verified this theory, Murphy's 
> "If something can go wrong, it will at the worst possible time" rule 
> once again proved to be true.

>From your Murphy comment, it looks like you've abandoned this approach.

Is your new program one that the users would call to close down their
exit program?  I guess you can just tell them they can only do that if
they sign off one more time and fix it so it checks the parameters.

What do the exit programs currently do if Shutdown = *YES?  Do they
first handle Process and MessageID and THEN do shutdown if necessary? 
What would try to do with a process of '*NO'?   (I'm wondering if you
can just pass a blank MessageID and let the exit program run.  I know I
said before that the program might try to do something bad, but in this
fairly controlled situation, you can be sure that the programs won't do
"bad" things given Process="*NO" and MessageID=' '.)