Tweet
Here's a scenario regarding Date fields that we have come across in some programs. In the physical files (non-keyed), there are Date fields, some defined as *MDY, and some *USA. For example:
- BirthDate L Datfmt(*USA)[/list]
- HireDate L Datfmt(*MDY)[/list]In the logicals, Date fields are renamed, and then those fields are redefined as numeric with the original field names. For example (examples are also copied in the code section for better formatting):
- A BDATE R RENAME(BirthDate)[/list]
- A BirthDate S[/list]
- A HDATE R RENAME(HireDate)[/list]
- A HireDate S[/list]Some logicals have a Date field as part of the key:
- A R Record01 PFILE(PhysicalFile)[/list]
- A Field1 R[/list]
- A Field2 R[/list]
- A BDATE R RENAME(BirthDate)[/list]
- A BirthDate[/list]
- A HDATE R RENAME(HireDate)[/list]
- A HireDate S S[/list]
- A K Field1[/list]
- A K BDATE[/list]When chaining to these logicals, the keylist needs a Date field, but when updating the dates in these files, it is the redefined numeric fields that need to get loaded. (This is how RPG handles Renamed fields in logicals.) So for example, to update the hire date in the logical with a work date field that was defined in the program in *ISO format:
- C Eval HireDate = %Int(%Char(WkDate:*MDY0))[/list](This puts the field WkDate into *MDY format to match its format in the physical file. The '0' after *MDY strips off the separators. The %Char converts this date field WkDate into a character field, then the %Int converts that character field into the numeric needed for the logical.) Does anyone see any benefits in writing file structures and programs this way? Could you explain the pros and cons to this? Thank you.
Code