× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Parm problems
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Wed, 26 Apr 2000 11:26:24 -0500 (CDT)


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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.