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



Chuck,
I'm not sure what you mean,
Length specification had been specified on the original DS.

...On the ds definition in the copybook? I've not seen a ds with a specified length before.
How would that be coded there?
d Example_ds...
d ds qualified
d subfield1 6a
d subfield2 2a

Thanks.
-- Michael

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, May 31, 2012 11:10 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Passing data structure to batch job RESOLVED

Ugh! My mistake. I knew I should not have composed that message so late. I had several different variations in my attempts to get that to work. And FWiW I only have v5r3.

That specific change requires that the Length specification had been specified on the original DS. Thus back to my original question about ways to establish a Length based on a compile-time size\length of another variable.? The LIKE worked, but only with the deferral of the explicit length setting on the referenced structure. :-(

However, defining things that way seemed more appropriate; i.e.
assigning the length on the DS, rather than on the based storage. That way if someone increased the length of the DS, then the based storage is automatically adjusted. If someone added subfields and forgot to similarly adjust the length of the DS, the compiler informs with RNF7301 "... is greater than length of data structure ...".

Regards, Chuck

On 31 May 2012 06:45, Koester, Michael wrote:
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.

<<SNIP>>
CRPence on Thursday, May 31, 2012 2:16 AM wrote:

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


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:

<ed> *if* the DS referenced in the LIKE had coded the length :-(


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 '''';

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


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.