RE: CL Problems - Parameter Passing

>Wow! So what you are basically saying is 
>that I shouldn't have a problem if I use 
>variable lengths less than or equal to 
>32, but I must use longer, to make sure 
>they are the same size? 
>(Which by the way was the case) 

This is the assumption that is in error.  Imagine being the CL program doing
the SBMJOB.
CL STEP2CL
dcl &filename *char 50
chgvar &filename 'test.txt'
sbmjob cmd(call STEP3CL &filename)

STEP2CL has set aside 50 bytes of storage for &FILENAME.  When STEP2CL calls
another program, he passes a pointer to his internal storage (parameters are
passed by reference.)  Well, on the AS/400 one job doesn't get to manipulate
storage in another job (SBMJOB creates another job) so this can't work like
a CALL.  

Instead, SBMJOB resolves the value of &FILENAME and passes it to the newly
created job (which is QCMD - look at your routing entries) as a constant.
So instead of "call step3cl <address of &FILENAME>" you get "CALL QCMD
PARM(call step3cl 'test.txt')"   (not really but why add request message
processing to the muddle?) 

QCMD parses out the string that it received and realises that it has to
create some storage for the parameter 'test.txt'  Because it is a character
constant, QCMD creates a 32 byte storage area, initialises it to blanks and
loads the constant into it, left-justified.  QCMD then does a "call STEP3CL
<address of internal storage area>"

CL STEP3CL
pgm &filename
dcl &filename *char 50

When STEP3CL tries to use &FILENAME, it reads 50 characters starting at
<address of internal storage area>  Unfortunately, QCMD only initialised 32
bytes of that area (PARAMETER SIZE MISMATCH ALERT) so the remaining bytes of
&FILENAME contain Who Knows What, also known as Garbage.

The work-arounds:
Have STEP2CL pass 51 bytes of data to SBMJOB.  Here's how that would work:

CL STEP2CL
dcl &filename *char 50
dcl &filetemp *char 51
chgvar &filename 'test.txt'
chgvar &filetemp (&filename *cat 'x')
sbmjob cmd(call STEP3CL &filename)

STEP2CL has set aside 51 bytes of storage for &FILETEMP.  When the SBMJOB
resolves the value of &FILETEMP, you get "CALL QCMD PARM(call step3cl
'test.txt                                 x')"  QCMD does his thing and sees
51 bytes of data, so he allocates an internal work area 51 bytes long.  When
STEP3CL tries to use &FILENAME, it reads 50 characters starting at <address
of internal storage area>  He doesn't care that QCMD has initialised 51
bytes of storage, or that byte 51 contains something: he stops reading at
byte 50.

The Cool Way:
Write your own command.  We've been able to extend OS/400 since the
dinosaurs roamed Pangaea.  Here's how it works:

CMD CVTTOPDF
CMD 'Convert IFS file to PDF'                    
                                                 
PARM KWD(FILENAME) TYPE(*PNAME) LEN(50) MIN(1) + 
       PROMPT('Input file name')                 

crtcmd cvttopdf pgm(STEP3CL)

CL STEP2CL
dcl &filename *char 50
chgvar &filename 'test.txt'
sbmjob cmd(cvttopdf filename(&filename))

The SBMJOB results in "cvttopdf filename('test.txt')  When QCMD does his
thing, he sees that he needs to run a command (not CALL) so the command
processor checks the command definition for each parameter, initialises the
defined amount of storage (here it's 50 bytes) loads the internal storage
areas up and away we go.  When STEP3CL gets called as a result of processing
CVTTOPDF, his definition of 50 bytes exactly matches the caller's definition
of 50 bytes and All Is Well.

I hope this was some help.
Buck Calabro
Commsoft; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---