How to get the file name in RPG when file error/exception occured

Kar

425 pts.

Tags:

AS/400

IBM iSeries

INFDS

My program processes bulk of file updates, and I'm trying to figure out the file name that was failed in processing. However the limitation for INFDS is, we cannot use the same DS name for all the files declared in a program. And it's hectic to declare unique DS for each INFDS. Is there any alternate way to figure out the error file name, so that I can display it in the user message.

-Kar

Software/Hardware used:
Iseries

Asked: June 17, 2011 8:49 AM Last updated: June 15, 2012 11:58 AM

Answer Wiki

Last updated: June 17, 2011 9:37 AM GMT

philpl1jb54,090 pts.
History
Contributors
- Ordered by most recent
- philpl1jb54,090 pts.

Thanks. We'll let you know when a new response is added.

The IFDS gives a great deal of info on the file but on an error you can get some info from the program data structure (PSDS).

This structure is defined with an S in position 23
D PSDS SDS.

40 42 Character 3
Exception type (CPF for a OS/400 system exception or MCH for a machine exception).
43 46 Character 4
Exception number. For a CPF exception, this field contains a CPF message number. For a machine exception, it contains a machine exception number.

175 184 Character 10
Name of file on which the last file operation occurred (updated only when an error occurs). This information always contains the full file name.
209 243 Character 35
Status information on the last file used. This information includes the status code, the RPG IV opcode, the RPG IV routine name, the source listing line number or statement number, and record name. It is updated only when an error occurs.
Note:
The opcode name is in the same form as *OPCODE in the INFDS
The source listing line number is replaced by the source listing statement number if OPTION(*SRCSTMT) is specified instead of OPTION(*NOSRCSTMT). The full statement number is included when it applies to the root source member. If the statement number is greater than 6 digits (that is, it includes a source ID other than zero), the first 2 positions of the 8-byte feedback area will have a “+ ” indicating that the rest of statement number is stored in positions 356-357.
Phil

The IFDS gives a great deal of info on the file but on an error you can get some info from the program data structure (PSDS).

This structure is defined with an S in position 23
D PSDS               SDS.

40  42  Character  3  
 Exception type (CPF for a OS/400 system exception or MCH for a machine exception).  
43  46  Character  4  
 Exception number. For a CPF exception, this field contains a CPF message number. For a machine exception, it contains a machine exception number.

175  184  Character  10  
 Name of file on which the last file operation occurred (updated only when an error occurs). This information always contains the full file name.  
209  243  Character  35  
 Status information on the last file used. This information includes the status code, the RPG IV opcode, the RPG IV routine name, the source listing line number or statement number, and record name. It is updated only when an error occurs. 
Note:
The opcode name is in the same form as *OPCODE in the INFDS 
The source listing line number is replaced by the source listing statement number if OPTION(*SRCSTMT) is specified instead of OPTION(*NOSRCSTMT). The full statement number is included when it applies to the root source member. If the statement number is greater than 6 digits (that is, it includes a source ID other than zero), the first 2 positions of the 8-byte feedback area will have a "+ " indicating that the rest of statement number is stored in positions 356-357.  
Phil

Send me notifications when members answer or reply to this question.

Discuss This Question: 4 Replies

Kar Jun 18, 2011 1:32 AM GMT

Phil, that was an excellent delivery...... I'll try the "last file operation in PSDS" Thanks a lot.! In addition, could you please let me know how to get the session/job that has locked the file/record, due to which my program crashes...! From PSDS & INFDS , I think there is no such parameter to identify the locking job... My error message to the user includes "File Name + User/Session (if possible)", please teach me how to obtain locking part... -karol

425 pointsBadges:

report
TomLiotta Jun 18, 2011 2:19 AM GMT

The PSDS should have enough exception data in positions 91-170 to tell who has the lock. The message ID is likely to be CPF5027, and the exception data should say something like "Record &6 in use by job &9." The record and job info should be filled in. You could create a (service program) procedure that takes the PSDS as a parm and extracts whatever you need. Code like that ought to be maintained in a single location. Tom

125,585 pointsBadges:

report
TomLiotta Jun 18, 2011 2:43 AM GMT
Also, the definition of each INFDS only requires a single line of code:
```
D OPNFDBK1        ds           228
```
That defines a DS covering the first 228 bytes of an INFDS. You can have as many of those as needed to cover each file. You would have the various subfields defined in a BASED() DS. Then when you need info from any one of the different DSes, you set the basing pointer to cover the one that you need. You should only need to check one at a time. Tom
125,585 pointsBadges:
report
philpl1jb Jun 15, 2012 11:58 AM GMT

Great idea. I'm looking forward to your video tutorial on this subject.

54,090 pointsBadges:

report