User Defined Reporting Attributes (UDRA) give LANSA reports access to the many features of IBM i External Printer files. Currently LANSA reports are internally described in data structures, while UDRA's involve the use of Data Description Specifications (DDS).
Note: It is highly recommended that the IBM Manual Programming: Data Description Specifications Reference be reviewed before continuing. The use of UDRA's require technical knowledge of IBM i. Use of UDRA's will make your LANSA function PLATFORM DEPENDENT as DDS is only available on the IBM i.
UDRA's are specified as output attributes on the data dictionary, DEFINE and OVERRIDE commands. UDRA's have the form "URxx"; where xx is any alpha-numeric combination that contains no blanks.
UDRA's will permit access to features such as barcodes, different fonts and sizes etc in your reports.
UDRA's are defined by creating a member in the Source Physical file DC@UDRA with the same name as the required UDRA (e.g. UDRA = URB1, member name = URB1). This source member is of type "PRTF" and contains valid DDS statements that will be applied to the report.
These DDS statements must include valid keywords and/or comments, and be applicable to the level for which they are intended to be used. That is, if keywords are to be applied to a field then they must be applicable to the FIELD LEVEL (refer to IBM Manual Programming: Data Description Specifications Reference for more information).
It is recommended that the IBM Source Entry Utility (SEU) be used to enter UDRA DDS source.
It may be necessary to change the Printer File to DEVTYPE(*IPDS) or DEVTYPE(*AFPDS), depending on the DDS Keywords used. (The DEVTYPE() required for the different keywords is defined in the above mentioned IBM Manual). The Printer File DEVTYPE() is best modified via the DEF_REPORT parameter OTHER_OVR. e.g. DEF_REPORT REPORT_NUM(1) OTHER_OVR('DEVTYPE(*IPDS)').
LANSA cannot determine the effect of DDS keywords on the report spacing, therefore it is the user's responsibility to ensure that the report spacing is correct for their application.
When a UDRA is attached to a report no validation is done as to the existence of the corresponding member in the file DC@UDRA.
If a UDRA is attached to a report or UDRA statements are modified, the changes are not realized until the function is successfully recompiled.
The export and import of the UDRA source file, DC@UDRA is the responsibility of the user.
Step-by-Step Example
Print a field on a report as a barcode.
1. Review IBM Manual "Programming: Data Description Specifications Reference" and decide BARCODE is the keyword to use.
2. Decide on the Keyword parameters necessary to produce required barcode. e.g. BARCODE(EAN8 2 *HRI) - barcode field using type EAN-8, barcode is 2 characters in height and includes Human Readable Interpretation below the barcode.
3. Select a UDRA code to represent the barcode. HINT: create standard UDRA's (URxx) that can be re-used for other reports. e.g. URBC.
4. Edit a new member of type "PRTF" in the file DC@UDRA with the same name as the UDRA code. e.g. URBC.
5. Enter the Keyword with parameters into the source member.
6. Save and Exit the source member.
7. Specify the UDRA code against the field by using the Data Dictionary, DEFINE or OVERRIDE command.
8. Create the report as you normally would through LANSA, except you MUST include FUNCTION OPTION(*OS400_EXT_PRINT) to utilize the UDRA's (for restrictions when using *OS400_EXT_PRINT see the command definition for FUNCTION in the Technical Reference Guide).
9. Compile the report.
The configuration of printers is beyond the scope of the document, but this problem has been encountered and it is not documented in IBM manuals:
When a printer device description is configured as AFP(*YES), the user must set the correct physical size of the page using the MPP, MPL, CPI and LPI values in the printer hardware.
