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



Hi Nilesh,

Your "dglsed1" field is only 10 bytes long. Your $current array is 120 bytes long -- therefore, the first 10 bytes of the $current array (which is one element) is overlaying dglsed1. The remaining 110 bytes will contain whatever happens to (by chance) come after dglsed1 in the computer's memory.

They MIGHT be the values of dglsed2, dglsed3, dglsed4, etc. But they might not. it all depends on luck! You haven't done anything (at least, in the code you posted) that forces them to be contiguous, and therefore your program won't work consistently.

You see, when RPG reads data from a database, it doesn't read the entire record all into memory at once as one big contiguous chunk of data. Instead, it reads one field at a time, copies it into an RPG variable (and does conversion if necessary), then reads the next field, and does conversion, etc. The program variables do not necessarily have to be right next to each other in memory -- and in fact, they frequently aren't. Therefore, you can't just assume they'll be contiguous.

To solve your problem, you need to FORCE them to be contiguous, and you do that by putting them into a data structure. For example:

D MyDS ds
D dglsed1
D dglsed2
D dglsed3
D dglsed4
D dglsed5
D dglsed6
D dglsed7
D dglsed8
D dglsed9
D dglsed10
D dglsed11
D dglsed12

When fields are in a data structure, they have a fixed from/to position within the data structure. Since a data structure is one object in memory, and since RPG is documented to assign the from/to positions to be contiguous, you know that the dglsed fields will be contiguous in memory -- so now you can set your basing pointer to the address of dglsed1 with confidence.

Having said that... Why even bother with pointer logic? Why not just do the following? It's much safer, and it's much easier for the next programmer to understand:

D MyDS ds
D dglsed1
D dglsed2
D dglsed3
D dglsed4
D dglsed5
D dglsed6
D dglsed7
D dglsed8
D dglsed9
D dglsed10
D dglsed11
D dglsed12
D $current like(dglsed1) dim(12)
D overlay(myDS:1)

The only time I'd use pointer logic like you've used is if I'm reading the whole record into a data structure for some reason. (For example, so I could take advantage of a qualified name.) In that case, I'd use pointer logic -- but, in that case, the fields are already in a DS, so I wouldn't have to worry about the data being contiguous -- it'd be contiguous already.

Hope that helps.

Butala, Nilesh wrote:
Hi See following code, it compiles file but when I run it gives different results. Any ideas?

***************************************************************** * current year array * ***************************************************************** d $current s based($curptr) d like(dglsed1) dim(12) d ascend d $curptr s * inz(%addr(dglsed1))
c dglscmpny chain(n) dbifgls1 *

The array value is not correct

EVAL $current
$CURRENT(1) = '2007-10-31' $CURRENT(2) = ' 2008' $CURRENT(3) = '-07-31 ' $CURRENT(4) = ' 2008-08-' $CURRENT(5) = '31 20' $CURRENT(6) = '08-09-30 ' $CURRENT(7) = ' 0001-0' $CURRENT(8) = '1-01 ' $CURRENT(9) = '2006-10-31' $CURRENT(10) = ' 2006' $CURRENT(11) = '-11-30 ' $CURRENT(12) = ' 2006-12-'
In file DGLSCMPNY B B 1 COMPANY 1 4 0 DGLSED1 L B PER_END_DATE_01 56 10 DGLSED2 L B PER_END_DATE_02 66 10 DGLSED3 L B PER_END_DATE_03 76 10 DGLSED4 L B PER_END_DATE_04 86 10 DGLSED5 L B PER_END_DATE_05 96 10 DGLSED6 L B PER_END_DATE_06 106 10 DGLSED7 L B PER_END_DATE_07 116 10 DGLSED8 L B PER_END_DATE_08 126 10 DGLSED9 L B PER_END_DATE_09 136 10 DGLSED10 L B PER_END_DATE_10 146 10 DGLSED11 L B PER_END_DATE_11 156 10 DGLSED12 L B PER_END_DATE_12 166 10
This file is created using create table and logical is created using create index. Company is key index.

Thanks

Nilesh



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.