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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online