The Midrange Manager: Names Are Important

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
Actually, we never used field names in form of xxyyyy. For RPG projects, years ago, we used xxxxxx, using a field reference file. With FRF, item number (to continue your example) has the same name in every file that uses it. It could be ITEMNO, or ITMNBR, or even ITEM#, but whichever one was chosen, it's the same everywhere. For anything developed since RPG IV (ILE), we switched to using ten character names. We are still careful, however, to avoid # and other non-alphabetics, because we also have to live with COBOL. Perhaps the prevalence of xxyyyy in some shops was due to influence of Synon/2E (now COOL:2E). But COOL:2E is a code generator, so names were formatted that way for a very specific reason.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
It's also worth mentioning that using the RPG/IV PREFIX() keyword eliminates the problem of overwriting variables from different files with the same name.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
If you're using RPG IV and have the luxury of being able to qualify your fieldnames with the filename then that's great. Unfortunately there are a lot of sites out there that are still running older versions of RPG where a six character unqualified field name is required. It doesn't really matter what the naming convention is that is being used at a site, as long as the programming staff are made aware of it and it is adhered to. Playing the part of the devils advocate here, though, I would hazard a guess and say that even with RPG IV, most programmers would probably prefer to type use a 2/8 character field name than have to do the extra typing and qualify every filed with a file or data structure name.

[buck.calabro@commsoft.net]

** This thread discusses the article: The Midrange Manager: Names Are Important **
I think the reason such old naming conventions are still in use is that the same database files are in use. Just because RPG IV is capable of larger, more meaningful field names doesn't mean that a shop is going to visit every file, DSPF, PRTF and RPG program simply to rename the fields. That's a tremendous amount of work for very little gain. --buck

[rharman@knotts.com]

** This thread discusses the article: The Midrange Manager: Names Are Important **
The convention I inherited here is xxxx## where ## is a two-digit number. The files are named xxxxxx##. So, for example, ITMHDR01 and ITMDTL02 would have ITEM01, and ITEM02 respectively for the item number. At first I didn't like it, but it's grown on me. I've found it quite easy to substitute SV (save), WK (work), ST (subtotal), etc for the number suffix and it makes things pretty easy to keep track of and debug. The suffix seems to lend itself to more clarity than a prefix.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
That's the convention we use, the physical file is defined as INP35. IN tells us the application file is for INventory, P tells us it's a Physical file and 35 is just a sequence number. All fields are identified by the sequence number so ITEM35 makes it reasonably easy to identify what file the variable belongs to within a program.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
In our Financial Portrait package, we use a single character prefix for non-key fields. The character is not derived from the file or format names, which have a different naming standard. Although it doesn't eliminate duplicate names for non-key fields, it usually separates them and allows for 5 characters for the name and a better chance at something meaningful. Key fields are 5 characters and usually duplicated from file to file, often allowing random access of relationally linked records without move statements. The first character can be substituted with characters such as "I" for input, "O" for output and "S" for save and "W" for work in order to get recognizable permutations of the associated field name. For key fields, this first character is concatonated to the five digit name. All database fields reference a field in the reference file, where fields are up to 10 characters and are not duplicated (customer number has only 1 reference field). Finally, to nail down most problems with field name overlap and unintended results during updates, we always use exception update to explicitly name the fields that are being updated. Yes, we know that this is not as smooth as the UPDAT operation, yet it clearly indicates the intent of the update and provides for quicker, more controlled maintenance. I would concur with the author though, that there are opportunities for more meaningful names, blanket prefixes and moves and local variables within RPG IV. Perhaps one way to evolve, is to incorporate these techniques into the program templates that most shops have. On an individual basis, I can probably provide a hard-copy of one of our technical publications, FPS Database and Program Component Naming Standards, just in case anyone would like to get ideas for creating and documenting the standard at their company.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
I'm really surprised to see a call for the elimination of the file prefix in fields names. We only use one byte to desginate the file (they can be reused in different applications) but I love being able to read the code and know what field a file is coming from based on that first byte! Why is that a bad thing. The fact that we can now use 10 byte names makes the file prefix (1 or 2 bytes) less of a burden since now there's 8 or 9 bytes to describe the field contents instead of 4 or 5. The only sad thing is that if RPG had the PREFIX keyword years ago, I would not have put the file prefix in the DB fields themselves, just tacked them onto each F spec. That may sound like a hassle, but it then offers you the flexibility of NOT having the prefix for those times when you want fields of the same name from different files to share the same buffer location. LONG LIVE THE FILE PREFIX!

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
I guess I can't agree, especially when there were only 6 characters available in RPG. I'd much rather to be able to easily know what is in a field by the name, rather than where it came from. When there were only 6 characters availalable it was hard enough to come up with a descriptive name without using up the first byte or two with a prefix. Ironically, in your arguement FOR prefixes you give another good arguement for not using them - the F Spec Keyword Prefix. Since there are 10 characters available in DDS and 14 in RPG you could prefix the field names with up to 4 characters through the prefix keyword.

[Guest.Visitor]

** This thread discusses the article: The Midrange Manager: Names Are Important **
OK, I am building a file SQL in an RPGLE program, then reading the file in. I want to point to the fileds in that file. ExampleF5542PF01.S1AN8), but I get RNF7030 The name or indicator S1AN8 not defined. What REALLY bothers me, the field is in three other files being read in the program. Can anyone explain this???