HLI: Using Model 204 completion return codes

From m204wiki
Revision as of 23:07, 29 January 2016 by ELowell (talk | contribs) (Created page with " ==Overview== <p>This topic briefly describes the Model 204 completion return codes for application programmers who are using the Host Language Interface facility.</p> Refer...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

This topic briefly describes the Model 204 completion return codes for application programmers who are using the Host Language Interface facility.

Refer to the Rocket Model 204 Host Language Interface Reference Manual for a description of HLI calls and a complete listing and description of the Model 204 completion return codes.

Using completion return codes for HLI calls

The first parameter of most HLI calls is a binary integer completion code that Model 204 returns to the application program. The completion code indicates whether or not the call finished successfully.

In general, completion codes of less than four indicate normal operation of a call. Completion codes equal to or greater than four usually indicate that the call was not successful and that Model 204 logged a message in the journal.

Note, however, that some return codes greater than 4 indicate normal completion. For example, for IFOPEN, a return code of 16 indicates that a file has been recovered but than processing can proceed without further conditional testing.

Refer to the Rocket Model 204 Host Language Interface Reference Manual for a complete listing and description of completion return codes.

Checking the completion return code

Check the completion code after every HLI call. Unless severe errors are detected, Model 204 does not abend an HLI application program that attempts unsuccessfully to execute a call.

If the completion code indicates an unsuccessful operation, the HLI application program can perform one of the following actions:

  • Reissue the call
  • Stop processing
  • Bypass the call and continue processing

However, use the last option with care. For example, the IFSTRT call, which establishes the connection to Model 204, must complete successfully for HLI processing to continue.

The HLI program must check the return code from IFSTRT, and, if the call did not complete successfully (that is, the return code is not 0), the HLI program must either reissue IFSTRT until it is successful or stop processing. If the HLI program attempts to issue another HLI call after an unsuccessful call to IFSTRT, Model 204 abends the job.

Using the audit trail

Technical Support recommends that you run your HLI program with an audit trail, because this, together with the completion return codes for individual HLI calls, is an important debugging aid.

To get HLI audit information, make sure to set the following parameters in your HLI job:

  • SYSOPT parameter setting to include RK lines
  • LAUDIT parameter with proper setting for logical input lines

Note: On an IFSTRT thread, the last message generated by the system is available to the application program with the IFGERR call. This message is available whether or not a journal is used in the HLI job.

See also