If you are worried about future enhancement of your data structure you
could try just using a large varying length string.
D NMS_DS_VAR S 32000A VARYING
NMS_DS_VAR = NMS_OrderDetails;
If you are curious about the sizes, you could make sure they are the
same.
Checksize = %LEN(NMS_DS_VAR);
Checksize2 = %SIZE(NMS_OrderDetails);
exec sql
set :ParmInHex = 'X''' CONCAT HEX(trim(T FROM(:NMS_DS_VAR)))
CONCAT '''';
The string should contain all the data from the data structure
You would also have to increase Command and ParmInHex to account for the
data structure's max expected size.
Your program could even be prototyped to reference the actual data
structure.
Since you are using QCMDEXC to submit the program it wouldn't care about
the prototype.
D ProgName PR
D ds_PARM1 likeds(NMS_OrderDetails)
Chris Hiebert
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Koester, Michael
Sent: Thursday, May 31, 2012 7:45 AM
To: RPG programming on the IBM i / System i
Subject: RE: Passing data structure to batch job RESOLVED
Thanks so much for the clarifications Chuck (and Barbara).
In trying to incorporate those into my code, I'm getting the SQL0312
when defining NMS_DS " like(NMS_OrderDetails)".
With just that change to my test program "TESTSTUFF" previously
posted...
* Global variables, constants, arrays
d Command s 1024a varying
d ParmInHex s 512a varying
old d**** NMS_DS s 115a based(NMS_DS@)
new d* NMS_DS gets Length established from a LIKE()
new d NMS_DS s like(NMS_OrderDetails)
new d based(NMS_DS@)
d NMS_DS@ s * inz(%addr(NMS_OrderDetails))
... the compiler pitches a fit:
exec sql
set :ParmInHex = 'X''' CONCAT HEX(trim(T FROM(:NMS_DS))) CONCAT
'''';
SQL0312: Position 55 Variable NMS_DS not defined or not usable.
Same issue if I use your set statement:
// Convert the data structuer to hex before passing to sbmjob
command
exec sql
set :ParmInHex = 'X''' CONCAT HEX(:NMS_DS) CONCAT '''';
SQL0312: Position 43 Variable NMS_DS not defined or not usable.
Was this a capability corrected by a recent PTF? I thought we were
pretty current...
I redefine NMS_DS with an explicitly defined length, and it works fine.
-- Michael
-----Original Message-----
<<SNIP>>
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, May 31, 2012 2:16 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Passing data structure to batch job RESOLVED
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
<<SNIP>>
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
