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


  1.  Home
  2. RPG400-L
  3. June 2013

Re: Data structure overlay *next failure

Just to clarify a bit.

Even if no length is specified there is a length - either from the LIKE or from the external definition of the field. Without one the compile will fail.

The same is true of group fields except the compiler derives the length. It is much the same as when the compiler derives the length of a DS - it is the sum of the length of its subfields. With a group field the compiler derives it from the combined lengths of all the fields that are specified to OVERLAY that group field.

I think what this thread demonstrates - and the point I tried to make from the outset - is that it is a bad idea to specify *Next when you don't have to. It can only lead to confusion.


On 2013-06-19, at 12:49 PM, Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx> wrote:

Hi Brian

I had to look up what OVERLAY (*NEXT) means - here is from the docs -

"Specifying OVERLAY(name:*NEXT) positions the subfield at the next available position within the overlaid field. (This will be the first byte past all other subfields prior to this subfield that overlay the same subfield.)"

At first glance, I interpret the last clause to mean subfields that have the OVERLAY keyword - but Jon is saying there is an implicit OVERLAY when no length is given.

That would line up with your conclusion - and with what I was beginning to intuit when looking at this.

Cheers
Vern

----- Original Message -----
I don't think you are quite getting what *NEXT does.

In your example, I assume you are wanting the carr array to overlay c1 through c12. But that is not what you told it to do. You told it to overlay the data structure starting immediately after the last subfield defined for the structure you are overlaying. So it created the array after c12 since it is also a subfield of PF1_t. Others have already shown you the correct way to do this, which is to create a group field that the c1 - c12 fields will overlay using next. Then overlay the array over the same group field.

The point here is that *NEXT does not overlay starting after the previous overlay *NEXT. It starts after the previous subfield.

Brian May
IBM i Modernization Specialist
Profound Logic Software
http://www.profoundlogic.com
937-439-7925 Phone
877-224-7768 Toll Free






-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx
Sent: Wednesday, June 19, 2013 11:22 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Data structure overlay *next failure

I don't believe the compiler is confused by too many *next fields. I was trying to determine if there is a rule against overlaying the data structure itself, and what the nature of that rule was. Experimental evidence shows there is an issue with it, and I will just avoid it from now on, knowing something goes wrong when you do it.

For example, this is fairly straightforward, but the compiler botches the *next on the 'carr' field. Incidentally, does anyone know how to view the data structure layout? This is SQLRPGLE and I haven't been able to find a layout in the compile listing like I thought I used to see.

D PF1_t DS qualified
D d1 like(LSTBOM1F_t.FRQTYR)
D d2 like(LSTBOM1F_t.FRQTYR)
D d3 like(LSTBOM1F_t.FRQTYR)
D d4 like(LSTBOM1F_t.FRQTYR)
D d5 like(LSTBOM1F_t.FRQTYR)
D d6 like(LSTBOM1F_t.FRQTYR)
D d7 like(LSTBOM1F_t.FRQTYR)
D d8 like(LSTBOM1F_t.FRQTYR)
D d9 like(LSTBOM1F_t.FRQTYR)
D d10 like(LSTBOM1F_t.FRQTYR)
D d11 like(LSTBOM1F_t.FRQTYR)
D d12 like(LSTBOM1F_t.FRQTYR)
D darr overlay(PF1_t) dim(12)
D like(LSTBOM1F_t.FRQTYR)
D c1 like(ITH_t.TQTY)
D c2 like(ITH_t.TQTY)
D c3 like(ITH_t.TQTY)
D c4 like(ITH_t.TQTY)
D c5 like(ITH_t.TQTY)
D c6 like(ITH_t.TQTY)
D c7 like(ITH_t.TQTY)
D c8 like(ITH_t.TQTY)
D c9 like(ITH_t.TQTY)
D c10 like(ITH_t.TQTY)
D c11 like(ITH_t.TQTY)
D c12 like(ITH_t.TQTY)
D carr overlay(PF1_t:*next) dim(12)
D like(ITH_t.TQTY)


From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: "RPG programming on the IBM i \(AS/400 and iSeries\)"
<rpg400-l@xxxxxxxxxxxx>
Date: 06/19/2013 11:43 AM
Subject: Re: Data structure overlay *next failure
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



The code I show below works Darren - trust me.

And no - you don't need *next. As I said there is zero difference between saying *Next on the first DS field against the DS name and leaving off the overlay all together. By definition a DS defined with length only (or no
length) is implicitly *Next.

When you get to the fields you need to overlay to create the array simply do as I showed and create a group field. List the array fields after that overlaid against the _group_ field name as I showed using just overlay on the first and *Next after that. Then define the array as an overlay against the group field.

Even if by using *Next all over the place you don't succeed in confusing the compiler - which you appear to have done - you will confuse any poor bugger who has to maintain the code.

This is a simple problem - use a simple technique.


On 2013-06-19, at 11:35 AM, darren@xxxxxxxxx wrote:

If I didn't specify the *next on the early fields, the *next would
overlay
on the first fields in the structure, which is not what I want. I
could move the array structures to the top of the structure to prevent
needing this extra stuff. The program was written this way, and I was
avoiding unnecessarily modifying it more than I had. The original
program had the
overlay:90 hardcoded, so I was trying to prevent needing the hardcoded
overlay positions.




From: Jon Paris <jon.paris@xxxxxxxxxxxxxx>
To: "RPG programming on the IBM i \(AS/400 and iSeries\)"
<rpg400-l@xxxxxxxxxxxx>
Date: 06/19/2013 09:56 AM
Subject: Re: Data structure overlay *next failure
Sent by: rpg400-l-bounces@xxxxxxxxxxxx



Why are you using *next at all on the early fields? It has no effect
and (as you have seen) can create confusion you. In fact it confuses
things
so
much I'm not absolutely sure what you area trying to do.

This:
D ParmDS DS INZ
D XEnd6 overlay(ParmDS)
D XWeeks overlay(ParmDS:*next)
D xFac overlay(ParmDS:*next)

And this:

D ParmDS DS INZ
D XEnd6
D XWeeks
D xFac

Are identical in effect.

If you are trying to create an array over a set of database fields
then
use
a group field like so:

D XwrkC
D XWrkC1 overlay(XwrkC)
D XWrkC2 overlay(XwrkC:*next)
D XWrkC3 overlay(XwrkC:*next)
D XWrkC4 overlay(XwrkC:*next)
D XWrkC5 overlay(XwrkC:*next)
D XWrkC6 overlay(XwrkC:*next)
D XWrkCA Like(xWrkC1) Dim(6)
D overlay(XwrkC)

This is using *Next the way it should be - to redefine something.

I've written a shoe article on this topic - check out
http://www.ibmsystemsmag.com/ibmi/developer/general/D-spec-Discoveries
/



On 2013-06-19, at 9:17 AM, darren@xxxxxxxxx wrote:


I'm having an issue creating arrarys over fields in a data structure.
I have something like the following, but the *next function doesn't
work
with
the arrays. They seem to get their own memory, rather than being
overlaid
on the XWrkC* fields. I've seen lots of overlay examples, but I
don't
see
them specify the actual data structure name in the overlay *next
command,
so I'm wondering if there is some restriction I haven't seen yet,
where
you
aren't supposed to overlay on the data structure itself, but only on
the subfields. In this case, the fields are actually display file
fields,
but
I've seen this behavior with independently declared fields as well.



D ParmDS DS INZ
D XEnd6 overlay(ParmDS)
D XWeeks overlay(ParmDS:*next)
D xFac overlay(ParmDS:*next)
D XBuyC overlay(ParmDS:*next)
D XPlnC overlay(ParmDS:*next)
D XPVnd overlay(ParmDS:*next)
D XDept overlay(ParmDS:*next)
D XITYP overlay(ParmDS:*next)
D XWrkC1
D XWrkC2
D XWrkC3
D XWrkC4
D XWrkC5
D XWrkC6
D XWrkCA Like(xWrkC1) Dim(6)
D overlay(ParmDS:*next)
D xItem1
D xItem2
D xItem3
D xItem4
D xItem5
D xItem6
D xItemA Like(xItem1) Dim(6)
D overlay(ParmDS:*next)

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.



--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(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.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com




--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.



--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (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.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com





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.