|
midrange.com
Hi Patrick,
Normally, a CALL from a CL program to another program would pass the
parameters by reference (only pass the memory address of the parameter)
but the SBMJOB command is an exception to that rule.
The reason being, the CALL command isnt actually being executed by the CL
program, but rather is being executed at startup in the new job that
SBMJOB will create. It can't pass variables by reference because the
program will run in a completely different job.
So what happens is it constructs an actual command "string" just like
something that you might type at the command line, and runs it in the new
job. (In the process of creating that string, it strips the trailing
blanks from it.)
From the command line, the CALL command will (by default) allocate 20
bytes (I believe the number is 20) for character parameters... That means
as long as your string is less than 20 bytes, the end will be padded with
blanks, and you won't have any problems. But, when the string is more
than 20 bytes, you'll get exactly the same length parameter as there are
characters in it -- causing the problem you're having.
You could solve this problem simply by adding additional data to the
string, tho I wouldn't recommend that solution. (I dont trust it for some
reason -- I have a vague memory of having strange errors doing this)
The best solution, in my experience is to create a *CMD (user defined
command) for the program that you're currently accessing with the SBMJOB
command. That way, you can specify how long each parameter is to be,
and the system will allocate the appropriate number of bytes to each
parameter....
(I hope this stuff that I just typed made sense!)
Good Luck!
On Wed, 26 Apr 2000, Patrick Conner wrote:
> Group,
>
> I have a problem with a parameter changing values between the calling
> program and the called program. This is the calling program which is also
> called with a parameter. Both programs have CLLE bound modules in them.
>
> START: PGM PARM(&FIC960)
> /* DECLARE VARS */
> DCL VAR(&FIC960) TYPE(*CHAR) LEN(66) <-- Parm for
> this program
> DCL VAR(&FIC962) TYPE(*CHAR) LEN(47) <-- Parm for
> next program
>
> This is how the parameter gets it value. The value below is the debug view
> of the value after the CHGVAR and before the SBMJOB.
> /* SUBMIT REPORT */
> CHGVAR VAR(&FIC962) VALUE(%SST(&FIC960 1 47))
> SBMJOB CMD(CALL PGM(FIC962) PARM(&FIC962)) +
> HOLD(*YES) SCDDATE(&SCDDATE) +
> SCDTIME(&SCDTIME)
> MONMSG MSGID(CPF0000) EXEC(CHGVAR VAR(&ERROR) +
> VALUE('1'))
>
> Debug view of value ---> &FIC962 =
> 'CAN 2000-04-252000-04-2500000000001 '
>
> This is the value received by the called program when looking at the job log
> before I release the job. Where are my trailing blanks?!
> ... CALL PGM(FIC962) PARM('CAN 2000-04-252000-04-2500000000001')
>
> Instead of getting blanks this is what I get...
> Debug view of parm --> &FIC962 =
> 'CAN 2000-04-252000-04-2500000000001 01') o '
>
> Here is why this is a problem...
> START: PGM PARM(&FIC962)
> /* DECLARE VARS */
> DCL VAR(&FIC962) TYPE(*CHAR) LEN(47)
> CHGVAR VAR(&OUTQ) VALUE(%SST(&FIC962 38 10)) <--- This is
> where my blanks should get picked up
> /* OVERRIDE REPORT */
> IF COND(&OUTQ *NE ' ') THEN(OVRPRTF +
> FILE(QSYSPRT) OUTQ(&OUTQ) COPIES(&COPIES))
> ELSE CMD(OVRPRTF FILE(QSYSPRT) COPIES(&COPIES))
>
> Program bombs on the OVRPRTF command.
>
> I know this is not a CLP forum, but I didn't see a CLP mailing list. Any
> suggestions?
>
> Patrick Conner
> ConnecTown
> PWConner@iwon.com
> (828) 244-0822
>
> *********************************************
> iWon.com www.iwon.com why wouldn't you?
> *********************************************
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
>
>
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
