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



"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:

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.