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



Kevin,

A command "wrapper" is often the solution to this problem, but in this case Javier has a parm that's 32,000 long. The maximum value a *CHAR parm can handle is 5,000.

-mark

On 8/15/2019 11:22 PM, Kevin Wright wrote:
Hi Javier,

The problem here is the SBMJOB which has the call to your program C. It
goes back to what I would call "command entry conditions". It has no
concept of prototypes. It attempts to guess how long the parameters are
for the call to program C. It leaves off trailing blanks, so there is not
32000 bytes between the 1st and second parameter to it.

Usual solutions are:
- Create a command for the program to be the CPP of and change the
SBMJOB to execute the command rather than call the program
- Declare the long parameter to be 1 greater in the CLP doing the SBMJOB
and place an 'X' in the extra position - this will make the parameters
space out correctly but is lying in the processing

There may be other solutions.

Regards,

Kevin Wright

-----Original Message-----
From: RPG400-L<rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Javier
Sánchez
Sent: Friday, 16 August 2019 1:04 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: Parameter passing between programs

"Simple answer - it doesn't.
The parameters passed to PgmB are pointers to the original storage in
PgmA. So it is likely that you are either looking at it incorrectly in
debug or else it is defined incorrectly in PgmA.

To better suggest an answer we need to see definitions and code -
including your prototype.

Plus how are you using debug to see beyond the 860 bytes?"


Jon, Dave:

Exactly, pgmB is actually a CL module, which before was an RPGLE one.
I
am using now this CL module in order to submit yet another pgmC program,
which would receive the same parameters, types and lengths.

Here is more or less the code. I could not get it out as I am working
for
a customer in a very limited access for security reasons. Using my
memory
I am pretty sure this is 99% exactly what I do:

pgmA declares this variable and procedure:

DCL-S buffer CHAR(32000) INZ;
DCL-S messageId CHAR(24) INZ;
DCL-S correlId CHAR(24) INZ;

DCL-PR ACHSJ920S; // An ILE CL module
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10) CONST;
END-PR;
.
.
.
// Within pgmA I do a read to an MQ message queue with MQGET() and
populate
// buffer (with a pointer to it), and messageId and correlId. MQGET
needs
a pointer to
// buffer not buffer itself as you may already know. But this is not the
point.

//Then, call the submitting CL module:

ACHSJ920S(buffer: messageId: correlId: 'ACHPUTM');

Now, the ILE CL module ACHSJ920S would see like this:

PGM PARM(&BUFFER&MSGID&CORRID&RSPQUE)
DCL&BUFFER *CHAR 32000
DCL&MSGID *CHAR 24
DCL&CORRID *CHAR 24
DCL&RSPQUE *CHAR 10

SBMJOB CMD(CALL PGM(ACHPR920S) PARM(&BUFFER&MSGID&CORRID&RSPQUE))
ENDPGM

Program ACHPR920S (which would be pgmC) has its PR and PI like this:

DCL-PR MAINPROC EXTPROC('ACHPR920S');
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10);
END-PR;

DCL-PI MAINPROC;
parm_buffer CHAR(32000);
parm_messageId CHAR(24);
parm_correlId CHAR(24);
parm_responseQueue CHAR(10)
D-PI;

Ok. When I debug, how do I see beyond the 860th character?
I write this command on the debugger's command line:

EVAL %SUBSTR(buffer 860 800)

or whatever amount of bytes to the right of it.
There is where I can see that the system displays for me, within the
same
string "buffer" the contents of parameter parm_messageId and
parm_correlId.
I would expect to see no other thing than blanks beyond that point.

Even when I debug first the CL module and I press F11 over&BUFFER I get
the same thing.

Do you think you can "lab" this to see whether you get the same results?

Thanks again.


--

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.