|
> > 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
As an Amazon Associate we earn from qualifying purchases.
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.