Re: Howto use fields "by name"

> 
> If, in a RPG pgm, I manage to have in a field (let's call it FieldName)
> the name of a real field from an externally described file, and in
> another field, call it "FieldValue", a value (either alfa or numeric),
> is there a way to write something as:
> Eval FieldName(??) = FieldValue
> 

The answer is that it can be done, but not the way you are thinking of. 
Here's the old-school way we used to do things before we could use SQL
and such:

Define an 'F' specification as an internally defined file, output only,
fixed length record, and set the record length to the length of the
longest file you would want to work with, and call it something like
OUTFILE.

Build a string that exactly matches the output record.  Use a long
string field, or a data structure that matches the record, or an array
of 1 byte characters, or whatever method works for you.  This can be a
bit tricky.  If you want to do it dynamically, use the list field API
(QUSLFLD, sp?) to get the buffer positions, field names and data types
into arrays, or a multiple occurrence data structure.

Now, build the output record buffer.  You have to trim alpha fields,
pack packed fields, set the bits for binary fields and so forth.  It's a
bit of a chore to handle all of the different data types, but doable. 
The catch is that the record buffer has to match the external 
specifications for the file *identically*.

Use the EXCEPT opcode to write the buffer to OUTFILE using the ADD
subcode on an output spec.  The only output field would be the string
you just constructed.  If your string is longer than the actual record
length, OS/400 will be nice and truncate it for you.

Just before you run the code, use an override database file command to
point the fake 'OUTFILE' to a real production file, as in:
OVRDBF OUTFILE SOMELIB/SOMEFILE.

One more thing, writing records this way is not that difficult.  It gets
a bit more hairy if you want to chain and update.  It can be done, but
you have to build a key buffer on the fly that matches the external
record key.

I wrote one of these about fifteen years ago to emergency fix a customer
database.  Turns out that the tables from the customers previous systems
often had nulls and other un-displayable characters in the alpha
fields.  No one noticed until they went live on the new system, and many
programs crashed because of the funky data in the old records.  This
idea cost us an afternoon to implement, but really saved our bacon.


HTH.


--
Regards,
Rich

Current Conditions in Des Moines, IA
Broken Clouds
Temp 84.2F
Winds out of the Southeast at 12mph