• Do not have any expectations on first invocation - the connection pool server process will be a 'tabula rasa' - i.e. blank.
• Leave the connection pool server process in the state in which anyone else would want to find it, leaving nothing behind - e.g. record locks.
• If you need to have commonly re-used shared objects such as file handles that are opened once and once only and the kept open then put these in specific COMMON block variables and use program logic and matching boolean flags in COMMON so that they are opened once and once only. These will persist on the connection pooling server process and can be re-used by subsequent invocations. You can use one of two approaches here:
  • Open all files on first invocation in case needed - this simplifies logic a little but at the expense of a potentially significant delay  if a lot of files are opened in one fell swoop.
  • Only open a file as it is needed by the application - this is generally a better approach if  not all calls to a connection pooling process require all the files.

• Do not have any expectations on first invocation - the connection pool server process will be a 'tabula rasa' - i.e. blank.
• Leave the connection pool server process in the state in which anyone else would want to find it, leaving nothing behind - e.g. record locks.
• If you need to have commonly re-used shared objects such as file handles that are opened once and once only and the kept open then put these in specific COMMON block variables and use program logic and matching boolean flags in COMMON so that they are opened once and once only. These will persist on the connection pooling server process and can be re-used by subsequent invocations. You can use one of two approaches here:
  • Open all files on first invocation in case needed - this simplifies logic a little but at the expense of a potentially significant delay  if a lot of files are opened in one fell swoop.
  • Only open a file as it is needed by the application - this is generally a better approach if  not all calls to a connection pooling process require all the files.

• Do not have any expectations on first invocation - the connection pool server process will be a 'tabula rasa' - i.e. blank.
• Leave the connection pool server process in the state in which anyone else would want to find it, leaving nothing behind - e.g. record locks.
• If you need to have commonly re-used shared objects such as file handles that are opened once and once only and the kept open then put these in specific COMMON block variables and use program logic and matching boolean flags in COMMON so that they are opened once and once only. These will persist on the connection pooling server process and can be re-used by subsequent invocations. You can use one of two approaches here:
  • Open all files on first invocation in case needed - this simplifies logic a little but at the expense of a potentially significant delay  if a lot of files are opened in one fell swoop.
  • Only open a file as it is needed by the application - this is generally a better approach if  not all calls to a connection pooling process require all the files.

• Do not have any expectations on first invocation - the connection pool server process will be a 'tabula rasa' - i.e. blank.
• Leave the connection pool server process in the state in which anyone else would want to find it, leaving nothing behind - e.g. record locks.
• If you need to have commonly re-used shared objects such as file handles that are opened once and once only and the kept open then put these in specific COMMON block variables and use program logic and matching boolean flags in COMMON so that they are opened once and once only. These will persist on the connection pooling server process and can be re-used by subsequent invocations. You can use one of two approaches here:
  • Open all files on first invocation in case needed - this simplifies logic a little but at the expense of a potentially significant delay  if a lot of files are opened in one fell swoop.
  • Only open a file as it is needed by the application - this is generally a better approach if  not all calls to a connection pooling process require all the files.

Recommendations

OSFI programming:

As far as adding resiliency to the existing OSFI programming techniques, only a few changes need to be made:

• Any program (foreground or phantom) that opens OSFI files needs to have the following statements executed before opening, reading or writing OSFI files:
  • EXECUTE \NET-ERRORS (SL\ CAPTURING JUNK
    • The L options tells the system "log RFSE's, don't stop and prompt the user for intervention, don't drop to debugger".
    • The S option suppresses echoing of the NET-ERRORS state, probably redundant with CAPTURING JUNK clause.
  • EXECUTE \SET-REMOTE-CLOSE (N\ CAPTURING JUNK
    • Normally when remote files are opened, the file handle is cached by D3 and never explicitly closed, even by a CLOSE statement. This was done to enhance throughput. Setting remote close on allows explicit closing of remote files so that cached handles for no-longer-available resources do not linger to cause problems, as in a temporary network problem.
  • Any program accessing OSFI files should keep them open for as narrow a window as practically dictated by throughput need. Ideally when a single record is going to be read and then written, the flow should be:
    • Open
    • Read and/or Write
    • Close

within the inner loop, not opened at the top of the program and closed at program termination. Exceptions would be when processing a significant number of records in a short period of time where the preferred flow should be:

• Open
• Read and/or Write all records
• Close

within the inner loop.

• In programs that open more than one OSFI file, it's a good idea for any OPEN/ELSE logic to close all OSFI files opened in the program to make sure that none get missed. Example:
  • OPEN RMTFLE1 TO FILE1 ELSE GOTO EXIT
  • OPEN RMTFLE2 TO FILE2 ELSE GOTO EXIT

Then at exit:

• CLOSE FILE1
• CLOSE FILE2

In the event that the first OPEN was successful and the second OPEN failed, the first file needs to be closed on exit, and it doesn't hurt anything to close a file that was never successfully opened.

• All WRITEs performed on OSFI files should use the ON ERROR clause to recover from a failed write.
• Any ELSE clause on a failed OSFI OPEN or ON ERROR clause on a failed OSFI WRITE should handle a graceful close of all OSFI files and exit from the program, and optionally a wait and retry cycle. To the degree that an ELSE clause on a failed read can be certainly attributed to a network error (and not merely a record that genuinely does not exist) should follow the same cleanup and exit path and optional wait and retry cycle.

• Do not have any expectations on first invocation - the connection pool server process will be a 'tabula rasa' - i.e. blank.
• Leave the connection pool server process in the state in which anyone else would want to find it, leaving nothing behind - e.g. record locks.
• If you need to have commonly re-used shared objects such as file handles that are opened once and once only and the kept open then put these in specific COMMON block variables and use program logic and matching boolean flags in COMMON so that they are opened once and once only. These will persist on the connection pooling server process and can be re-used by subsequent invocations. You can use one of two approaches here:
  • Open all files on first invocation in case needed - this simplifies logic a little but at the expense of a potentially significant delay  if a lot of files are opened in one fell swoop.
  • Only open a file as it is needed by the application - this is generally a better approach if  not all calls to a connection pooling process require all the files.