Variable number of parms in CL

41380 pts.
Tags:
AS/400
CL Parameters
CL Program
iseries v5r4
I know I have check in RPG for a variable number of inputted parms. Can I do that in CL also?

Software/Hardware used:
V5R4 AS400

Answer Wiki

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

Thanks for the answers.
That is exactly what I thought and I did some research, but then that is what this website is all about.
Ask your peers and learn something new.

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
  • WilsonAlano
    Hi Charlie, I think that you can't do that! OS (IBMi, i5/OS,...) will try to match parm number and type before calling program... it will send msg CPD0172. Regards, Wilson
    2,485 pointsBadges:
    report
  • TomLiotta
    For a CL *PGM, you can monitor for MCH3601 after attempting to access the parm. IMO, it's best to use CHGVAR to copy parm values into local variables. The MONMSG would monitor each CHGVAR and supply default values as needed as individual parm variables are copied. But for a CL *MODULE (i.e., a called procedure), I'm not sure that any good way exists. RPG provides the %PARMS() bif, but there is no similar function for CL that I'm aware of. That is, a *MODULE may apparently also monitor for MCH3601 if the calling proc explicitly *OMITs the parm; but not if it simply leaves it out of the parm list by specifying fewer parms than expected. (Leaving it out might result in MCH3601, but it's not guaranteed. It can depend on how many parms were in previous procedure calls in the same job, AFAIK.) If anyone can give more info, I'd sure be interested along with you. Tom
    125,585 pointsBadges:
    report
  • WilsonAlano
    Hi Tom For a CL (OPM) MONMSG doesn't work but for a CLLE yes it's possible to monitor the message. Wilson
    2,485 pointsBadges:
    report
  • Koohiisan
    AFAIK you *must* use CLLE for this to work. I typically test whether the variable was passed or not by trying to change it to itself. Trap the MCH3601 error and handle it as you wish, or proceed as normal if it was passed.
    dcl var(&VAR) type(*CHAR) len(1)                       
                                                                        
    chgvar var(&VAR) value(&VAR)                        
    monmsg     msgid(MCH3601) exec(DO) 
        ...                              
    
    5,020 pointsBadges:
    report
  • TomLiotta
    MONMSG MCH3601 works for *PGM objects regardless of OPM or ILE CL. However, the convention of the calling program makes a difference. For example, testing MCH3601 has been the standard way for CL *PGMs that are used as *CMD CPPs to test for unpassed command parms since the very beginning of AS/400s, even before ILE existed. The behavior is essentially at the *PGM object level as part of the "OPM parameter passing convention". Programs are simply called differently than procedures are. That's a big part of why OPM Parameter Address (OPM_PARM_ADDR) can only be used in a PEP and NPM Procedure Parameter List Address (NPM_PARMLIST_ADDR) outside of a PEP. Reviewing those two MI builtins helps see differences. Unfortunately, even those don't help CharlieBrowne for CL -- the compiler creates the PEP on its own and it's not what is coded in the CL source. You can often see it referenced as "_CL_PEP". Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Simple CL example:
    pgm  ( &p )
    
       dcl   &p     *char   10
    
       dcl   &v     *char   10
    
    
       chgvar   &v   &p
       monmsg ( mch3601 )  exec( chgvar &v '*NONE' )
    
    
       sndpgmmsg  msgid( CPF9898 ) msgf( QSYS/QCPFMSG ) +
                    msgdta( &v )
    
       return
    
    endpgm
    Compile it as CLLE or CLP. Then attach it to this command:
     /*    CRTCMD CMD( mylib/@TST3601 )              +
                  PGM( *LIBL/TSTMCH3601 )            +
                  SRCFILE( mylib/QCMDSRC )           +
                  SRCMBR( @TST3601 )                 +
                  REPLACE( *NO )                     */
    
                 CMD        PROMPT('Test command')
    
                 PARM       KWD(P) TYPE(*CHAR) LEN(10) PASSVAL(*NULL) +
                              PROMPT('Enter some value')
    Whether CLP or CLLE, the MCH3601 works the same. It's in how the program is called that the difference shows up. If you try using the CALL command instead of the example command, the behavior changes. The CALL command is still a command, but some experimentation and thought should begin to illuminate that "CALL" has to be doing some special stuff to get its work done. The handling of PARM() alone necessarily requires a lot of behind-the-scenes work. Tom
    125,585 pointsBadges:
    report
  • WilsonAlano
    As CharlieBrowne says this web site is to learn something new... Thanks Tom!
    2,485 pointsBadges:
    report
  • WoodEngineer
    Would it be possible to build a command to launch your CL program? That is one way to handle unpassed parms by letting the command pass default values.
    6,670 pointsBadges:
    report
  • CharlieBrowne
    Response to Wood. Yup, I did build a command so in the future, I have no problem. Right now I have some programs calling the CL directly and they do not have the extra parm that I added. I have changed them to use the command so I do not have this problem in the future.
    41,380 pointsBadges:
    report
  • CharlieBrowne
    Thanks Tom I had not thought of the MONMSG
    41,380 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