Re: Another V5R1 query... Qualified DSs -- RPG400-L

Brad,

I don't believe that we will ever get that capability, nor do I think we 
really want it.  That is, the same variable name in two different field
data structures pointing to the same bit of memory.

AddressFile
 Name
 Address
 City

InvoiceFile
 CustNo
 Name
 Address
 City
 CoName
 CoAddress
 CoCity

with the way you are stating things should be, if I have my invoice file open,
and I were to chain to the AddressFile, the fields in the InvoiceFile with the
same name would change also.  In some very limited areas this would be a good
thing, but in most cases it would be a bad thing.

Consider, I'm creating a new invoice and am loading the fields.  I chain to the 
AddressFile and it loads the fields.  Fine.  Now I need to load the information
for the billing party (we bill from more than one division) and this information
is also stored in my AddressFile (mostly hypothetical here).  When I chained to
the AddressFile again to get my company info, it would change the bill to 
information
again.  Not what I intended.  

This type of thing would make programs extremely hard to debug.

Also, data in field data structures is stored in one big block of memory, which 
is
a good thing for pointer manipulation.  Data Structures that are not for file 
filed
definitions, however, are not stored in contiguous blocks of memory, but can 
point
all over the place (which is why you can have a DS point to a field defined in 
an
external file DS).

What I would like the ability to do, and we may already have it, is a memory 
copy
statement.  Something like:

C           Eval    FromPointer = %Addr(AddressFile.Name)
C           Eval    ToPointer = %Addr(Invoicefile.Name)
C           Eval    %MemCopy(FromPointer: ToPointer: 100)

which would, in theory, copy the information byte for byte from my customer 
file to
my invoice file.

I'm sure there's lots of programmers reading this saying, but!  Yeah, if I 
tried to move
from a File Structure to a Data Structure, it could be disaster, since a data 
structure is
not guaranteed to have contiguous memory.

Regards,

Jim Langston

Me transmitte sursum, Caledoni!


"Stone, Brad V (TC)" wrote:
> 
> Let me try and explain a little more.
> 
> I know we've all hated the fact that you can't have the same field in two
> different Data Structures.  So, when I saw this, I thought "cool!  This will
> be great."
> 
> But then I realized.  Using the QUALIFIED keyword means I have to qualify it
> when i use it.
> 
> The reason I wanted to use the same field in two different data structures
> is I wanted them to have the same value as well.  So when I said:
> 
> eval   Date = *DATE
> 
> Each and every data structure with a field of Date inside of it would have
> the same value.
> 
> But, with this new feature, you have to say:
> 
> eval   DS1.Date = *DATE
> eval   DS2.Date = *DATE
> 
> It may be just me, but this is why I wanted to have the same field names in
> data structures.  What you describe in your #3 is just a small piece that
> may be helpful.  It could be quite possible the only reason I'm saying this
> is because I thought it meant something it did not and am looking for
> something that makes this change worth the $15 we had to pay (I don't know
> what it was, I'm just guessing.)
> 
> Brad
>
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---