× 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

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





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.