From: Lee Smith To: All

I am about to clean up an application left by a vendor with whom my company no longer has a business relationship. This application has about 30 physical files and about 150 RPG programs. I would like to create a field reference file (FRF) and recompile all the physicals to reference it. My question is this: Should I build a FRF that contains an entry for every field in every physical file, or should I create the FRF with generic field names, and reference the generic names in the DDS of each physical file?

For example, the item master, order master and inventory master files contain a character field with a length of 15 used as the item number. Each file references the item number with a different field name. Should this be represented by a single, generic item number field in the FRF, or should there be an entry for each individual field?

I tend to favor the generic approach, but I would like to hear opinions.

From: John Wagner To: Lee Smith

I'm with you. Use the generic approach. Given the choice, I'd eliminate the different specific field names in the three files listed unless you have a really good reason for doing otherwise. ITEMNO is ITEMNO is ITEMNO. If you have fields that you know ahead of time must have the multiple-name convention with the same definition, define these toward the end of your FRF, referencing the generic name for the actual definition; this way, if you ever have to change the generic definition, the specific definition changes right with it.

From: Ted Holt To: Lee Smith

I agree. Define one item number field and let all item number fields reference it. If you ever decide to redefine what an item number looks like, you'll only have to change one item number field.

From: Stephen Burns To: Lee Smith

I'm not a programmer, but I seem to remember hearing that you need unique field names in the RPG programs that will be using the files.

From: Matt Sargent To: Lee Smith

All too often, the use of generic fields leads to baffling and essentially useless field descriptions and column headings. Few things are as infuriating as trying to work with a file where half the fields have exactly the same description.

Certainly there are times when generic references make sense. But make sure there is a true relationship between the fields (such as item number in your example); simply having the same number of bytes or decimal places is not enough. Otherwise, you destroy the usefulness of external definitions.

From: Tom Liotta To: Lee Smith

I have to go with the generic ap-proach. In fact, I go a bit farther than that, but that's a bit much to get into here. A thread on such a standard would be never-ending.

Generally, I'm not even overly concerned about naming fields differently in different physical files-as long as they mean the same thing.

If the multiple files are referenced in the same program, the fields should nearly always have the same values anyway. But then, I'm a COBOL programmer at heart and use the ALIAS anyway.

From: Lee Smith To: All

Thanks for the ideas! Another question: If I define a generic field (item number) in the FRF, is there any reason not to use a descriptive 10-character name (ITEMNUMBER) and then define it as the typical cryptic RPG field name (ITEMNO) in the physical file DDS? This would make the FRF more readable.

I agree that the fields defined in the FRF should represent distinct data entities. However, this application has a lot of "description" fields. They are 10, 15, 25, 50 and 256 characters in length. Should I code these in the FRF as DESC_10, DESC_15, DESC_25, and so on? And what about one-byte fields used as Y/N flags? Should I code them as a single FLAG_YN with VALUES('Y' 'N')?

From: Pete Hall To: Lee Smith

What we've done seems to work pretty well.

We define generic fields at the top of the FRF, which are essentially data types. There is one for dates; one for times; a generic name, address and phone number (complete with edit word); and so on.

The generic data types are then referenced by the fields in the record definition section of the FRF using REFFLD(XXXX *SRC), where COLHDG and TEXT attributes are overridden as necessary. There is a section for each file. In cases where it is necessary to duplicate a field name-for whatever reason-the field is listed with the record that contains it, but the field is commented out. This way, you can't create duplicate field names unless you really intend to do so; and all of the field definition information is in one place and based on common attributes.