Re: Data structure overlay *next failure -- RPG400-L

I didn't say "too many" - but they were pointless.

In the case below the first array should work. I've done it many many times. The second one ... hmmm. As I've already said I wouldn't do it this way even if it worked. The group field is far more obvious I think. But at first glance it looks OK - I'll play some and see what gives.

Overlay against the ds is no different than against a field. It simply says to the compiler that the start address of darr is the same as the start address of the ds PF1_t. *next should work OK but I need to see what it is doing.

On 2013-06-19, at 12:22 PM, darren@xxxxxxxxx wrote:

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.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com