NOF Skeleton Program
To set up a programmatic NOF interface, you must write your own NOF program. You can base your program on the skeleton COBOL NOF program provided with your Agile Business Suite Software, and named:
NGEN28/SAMPLE/NOFYou might add logic to this skeleton program to perform the following functions:
Pass replies from the application to the station or program that initiated the transaction.
Synchronize recovery between the program and the application, when recovery is required.
Provide duplicate protection, where required.
Provide a means of tanking transactions, if required.
Figure Flow Diagram for the NOF Skeleton Program gives a flow diagram of the main routines in the NOF skeleton program, and details of all routines in the program. Study this in conjunction with the program listing, which itself contains some explanatory comments, to gain an understanding of this program.
In addition, a skeleton NOFORM Library is included with your Agile Business Suite Software. This library procedure provides a complex wait routine that is used by the skeleton NOF program. It is named:
*NGEN28/SAMPLE/NOF/LIBRARYDuring the Configure process, these software files are copied to the DICTIONARY pack under the usercode specified for Runtime.
COMS Requirements
Your NOF program requires a COMS Agenda and a COMS window. By default, the Agenda is named NOF and the window is named systemNOF. A default COMS Configuration file is created automatically by the generation process, and you must manually load this into COMS, by using COMS UTILITY. Refer to Compiling and Configuring the NOF Program and Library under Setting Up a NOF Interface for NOF-Initiated Transactions for more information.
Input to the NOF Program
The NOF skeleton program is set up to accept input of the following types:
Port file
This is for an external system interfacing to the NOF program.
Note: If your application contains Ispec Classes, the port file record size must be changed to the maximum expected buffer size (maximum of 65000 bytes).
System
Program-to-program communication from the application to the NOF program through the MCS.
For receipt of Automatic Entries and transaction replies from the application.
External Terminal
Terminal-to-NOF program communication through the MCS.
For receipt of messages from external stations (for when the external system is a station rather than a program).
You can modify the NOF skeleton to accept other types of input, as shown in the following examples:
Your NOF program could read a flat disk file or tape file as input.
External program, through COMS
Currently, the skeleton program assumes that any COMS program-to-program communication is from the application, and that input from an external program comes through a port file. You might choose to make modifications in this area to enable the external system to use program-to-program communication.
Output from the NOF Program
The NOF skeleton is set up to send the following types of output:
NOF program to System
Program-to-program communication through COMS.
For replies to Automatic Entries sent by the application, and for sending transactions to the application.
Replies to Automatic Entries are sent differently, depending upon whether the Automatic Entry was performed by an Ispec or a Report.
NOF program to external terminal
Communication through the COMS.
For replies to external terminal transactions (for when the external system is a station, rather than a program).
You can modify the NOF skeleton to send other types of output. Some suggested methods are:
Flat file. Your NOF program could write any replies it receives to a flat disk file or tape file.
Port file. Your NOF program could be modified to send replies to an external program through the port file interface. As supplied, the skeleton program does not write replies to the port file interface.
Note: If your application contains Ispecs classes, the port file record size must be changed to the maximum expected buffer size (maximum of 65000 bytes).
External program to NOF program
Program-to-program communication through COMS.
Your skeleton NOF program could be modified to write replies to an external program through COMS, using program-to-program communication.
NOF Offline Operations
The NOF program is controlled by COMS, not by the application, thus it can be running even when your application is offline. This offers a number of possibilities. For example, you could include logic in your NOF program to tank transactions whenever the application is unavailable.
If a message is sent to the application, and COMS replied with an error stating that the application is unavailable or disabled, offline input logic could be invoked in your NOF program.