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

Jim, 

now THAT's a good use for it.

Define 3 DSs.  One EXTNAME of the customer file.  Then one for Billto, and
onen for Shipto using LIKEDS of the first DS.

Chain to a file.  Fill a Billto.xxx DS with customer info.
Chain again, fill a Shipto.xxx DS with customer info.

Ok, I'm convinced there is a use for it other than what I had assumed it
would do.  I still would like the option, though.  :)

Brad

> -----Original Message-----
> From: Jim Langston [mailto:jimlangston@conexfreight.com]
> Sent: Thursday, May 10, 2001 10:26 AM
> To: RPG400-L@midrange.com
> Subject: Re: Another V5R1 query... Qualified DSs
> 
> 
> 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
> +---
> 
+---
| 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
+---