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



On 30 May 2012 08:08, Koester, Michael wrote:
<<SNIP>>

I took the advice to heart and added an "EndOfDS" marker field to
the DS, with a single "x" character to prevent the inadvertent
trimming of trailing blanks, and used Chuck's technique of changing
the contents of the data structure to hex before passing. Thanks for
the advice.

Doing both is unnecessary. The entire DS reconstructed as a hexadecimal character string could be passed [without any non-blank padding], and all should be well. That is to suggest, using the hex formatted character string will both eliminate any issue for a x'7D' being embedded [whether from binary or character] within any data in any subfield(s) of the DS and ensure that the full DS is passed to and received by the called program. As such the DS can be defined without the "EndOfDSmarker" [in NMS_PROTOS; bottom of quoted message], which although documented in comments to explain its existence, probably is best eliminated to avoid ever having to explain why it is there. Instead, explain in comments that the [re]constructing of the DS as a Hexadecimal Character String (X'dsDataAsHexDigits') ensures both that the full DS including any possible embedded apostrophes [even as binary x'7D' data] will be passed properly to the called program.

Chuck, I agree setting up a hard-coded length of the data structure
is not optimal, but I'm at a loss as to how to avoid that. In my
testing, I initially set NMS_DS at 256a, and saw trailing junk passed
in the parm, but since the receiving program does not define that
area of the incoming string, there is no impact. Just needs to be
"big enough".

FWiW, I had determined that the length need not be coded if NMS_DS is declared as shown here:

d* NMS_DS gets Length established from a LIKE()
d NMS_DS s like(NMS_OrderDetails)
d based(NMS_DS@)

And that although no explicit length was specified, the SQL allows the usage of that standalone variable as a Host Variable; i.e. no error SQL0312, as with naming a DS as a :HV in an expression.

Having the correct length, and no non-blank pad, the ParmInHex value can be set to Hex(:NMS_DS) inside of the "X'" and "'" *without* any TRIM activity. Thus simplified to what I originally suggested:

// Convert the data structuer to hex before passing to sbmjob command
exec sql
set :ParmInHex = 'X''' CONCAT HEX(:NMS_DS) CONCAT '''';

And of course the two SQL SET statements could be combined into just one. I originally showed how I would use two, simply because that is IMO, easier to read:

// Build the submit job command with hexed data structure to be passed
exec sql
set :Command = 'SBMJOB CMD(CALL PGM(TESTSTUFF2) PARM('
concat 'X''' CONCAT HEX(:NMS_DS) CONCAT ''''
concat ')) JOB(MKTesting) JOBQ(QBATCH4)';

For those with insatiable curiosity, my test code is at:
http://code.midrange.com/a7cae8b945.html NMS_PROTOS copybook stuff
http://code.midrange.com/456fdb0163.html TESTSTUFF sqlrpgle passing ds
http://code.midrange.com/974ff57bb8.html TESTSTUFF2 sqlrpgle receiving ds

Regards, Chuck

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.