There is an RPG extension to the File Description Specification called RECNO that will return the relative record number to the program. But as ridiculous as it might sound, this keyword is only valid if you are processing the file sequentially. To retrieve the relative record number in a randomly processed file, you have to define a field in the file information data structure.
An example of the need for this technique is a subfile maintenance program over a file that does not have a unique key. Depending upon the data, it can be impossible to differentiate the various records on the screen to tell which record to update.
A solution to this problem would be to store the relative record number in the subfile as a hidden field to be used later when you want to update a record. You could then chain to the record using the relative record number and perform the update operation. To do this, you would need to define the file twice in the file description specifications as seen in 4. In this case, TRANS is a physical file and TRNDATE is a logical file built over TRANS. If the two files have the same record format name, you'll need to use the RENAME extension specification to change one of the record format names.
A solution to this problem would be to store the relative record number in the subfile as a hidden field to be used later when you want to update a record. You could then chain to the record using the relative record number and perform the update operation. To do this, you would need to define the file twice in the file description specifications as seen in Figure 4. In this case, TRANS is a physical file and TRNDATE is a logical file built over TRANS. If the two files have the same record format name, you'll need to use the RENAME extension specification to change one of the record format names.
In this example, TRNDATE is processed randomly and used to create a subfile. TRANS is processed by relative record number and is only used for update operations. The TRNINF file information data structure is used to tell the program what the relative record number of each randomly processed record in the TRNDATE file is. The relative record number is moved to a hidden field called HDNRRN and written to the subfile.
When a record is selected on the screen to be updated, the program chains to the correct record of the TRANS file using the hidden field (HDNRRN). It then performs the update on the desired record.
You really have to search through the manuals to find this solution. Here's how I did it. I looked in the RPG/400 Reference manual (SC09-1817, CD-ROM QBKAQV00) under "File Information Data Structure." In the area labeled "File Dependent Feedback Infor-mation," I found the formula used to calculate the From and To positions within the file information data structure for the relative record number. The formula is as follows:
From = 367 + Offset To = (From - 1) + Character_Length
Next I looked in the Data Manage-ment guide (SC41-3710, CD-ROM QBKAUG00) under "I/O Feedback Area for Database Files" to determine the length and offset used. To compute the location of the relative record number, I performed the following calculations:
From = 367 + 30 = 397 To = (397 - 1) + 4 = 400
Finding the Relative Record Number
Figure 4 Accessing the Relative Record Number
*. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 FTRNDATE IF E K DISK F KINFDS TRNINF FTRANS UF E DISK F TRNREC KRENAMEBYRRN * ITRNINF DS I B 397 4000RRN * . * . * . C MOVE RRN HDNRRN C WRITESFLRCD * . * . * . C HDNRRN CHAINBYRRN 68 C *IN68 IFEQ *OFF C MOVE NEWDAT TRNDAT C UPDATBYRRN C ENDIF
LATEST COMMENTS
MC Press Online