MAXDELAY Limitations and Restrictions

Edit online

There are many considerations to take into account when using PROCESS submission and MAXDELAY. These considerations include:

  • ESF and MAXDELAY are mutually exclusive. During an ESF session, the only command possible is SUBMIT. ESF and SUBMIT with MAXDELAY are not possible and results in SCBI221I MAXDELAY, a failure of the SUBMIT. An ESF submit occurs when the API cannot establish the connection to the Server for any reason, such as when the Server is down or when there is not enough SNA APPLID defined in the NETMAP; in these cases, it is the responsibility of the API to construct and assign the process number, and write the process to the TCQ.
  • When using a MAXDELAY parameter of UNLIMITED, processes submitted that are not immediately eligible for execution are subject to the intelligent retry logic when a PROCESS to the same SNODE cannot establish a session. These processes will be placed into the HOLD queue while the failing process retries. If this failing process exceeds its maximum retry, all processes for that same SNODE with be placed into the HOLD and will require manual intervention to run. This will cause the API to hang while not producing your desired results.
  • If the connection between the API and the C:D Server is lost due to a time out or other network issues, the API is terminated without any knowledge of the results of the submitted process. However, with the DGADBATC EXEC ninth parameter as Y, the MAXRETRY and MAXWAIT will attempt to restart the connection.