Setup > Usage > Batch server > Batch server parameters 

The software supervisor includes a batch server to execute tasks in a differed fashion, at the demand of the user who sends requests to this server. It is possible to simultaneously execute a group of the tasks, where the maximum number is defined by the licence used (4 is the standard).

Amongst the specific batch tasks are the :

  • accounting batch task used to update the accounting once automatic postings have taken place from any function in the software.
  • the Workflow signature batch task, named AWRKSIG, which processes the remote signatures by clicking on an link in a message.

This function is used to modify the batch server parameters.

In order to understand the influence of the different parameters, it is advisable to read the documentation explaining the Function cycle for the batch server.

Screen management

Entry screen


A single tab is used to define a group of parameters.




The following fields are present on this tab :

Batch server

  • Server name (field APPLI)

This field, which is display only, gives the name of the folder where the batch server is used. This name depends on the software used (for instance, in the case of ADONIX X3, it is called SERVX3).

  • Time between 2 searches (sec) (field TEMPS)

When no tasks can be started at a given moment, either because the maximum number of simultaneous tasks has been reached, or because no query is waiting execution, the batch server puts itself into wait mode for a number of seconds defined by this parameter. Once this time has passed, the server re-verifies whether it is possible to launch one or more tasks.

Therefore the value of this parameter influences the average time taken into account for a query (all other execution conditions being equal). A time in the order of 30-60 seconds is generally advised (a shorter time can be selected but this has a negative impact on server loading).

  • Time-out search time (sec) (field TIMOUT)

A task having exceeded the execution duration quota that has been authorized is stopped by the server, but the effort in verifying the execution duration for queuing tasks is quite heavy. It is therefore possible to define an interval in seconds between two reads of this type. A minimum time between 1 - 5 minutes is usually sufficient, except in specific cases.

  • Next query number (field NUMREQ)

It is the current number of the request counter; each request is numbered. This number is automatically incremented, but for maintenance reasons, it is possible to modifiy it.

  • Maximum no. active queries (field NBTACHE)

This field makes it possible to define the maximum number of tasks which can be active simultaneously. If this number is exceeded, the starting of the other pending tasks is postponed. It is limited by the number of batch tasks authorized by the license.

  • Maximum delay to launch a query (minutes) (field RETARD)

This field allows the specification of the admissible delay (in minutes) for the start of queries. This delay is the time measured between the moment upon which the task has been planned and the current time. Generally, the fact that the number of current tasks equals the maximum number of possible tasks is the reason why there may be some delay.

A task which could not be started within the allotted time will be marked as Outside the time limits and is no longer executed.

The delay can also be defined at the level of the task and this value takes priority.

If this field is equal to 0, and if the admissible delay indicated for the task is also equal to null, the task will never be considered outside the time limits.

  • Waiting read PID (field LECPID)

In the query management function, the status of a query is displayed as soon as it was started. The status is verified by searching for a file that contains the PID (system process identifier), created by the task when it was started. If this file is not found, a loop is performed, with a timing given by this value (in seconds).

In general, a value of 1 to 5 seconds is reasonable. This value shall be decreased in case of rapid execution tasks, it shall be raised if the batch server is overloaded.

  • field WA


  • Update integration mode (field FLGPATCH)


  • Use of batch files (field JOB)

If this box is checked, it will be possible to start tasks by the creation of files in a dedicated directory (defined below). This supposes that the users on behalf of whom the tasks will be launched have the parameter EXTBATCH equal to Yes. For further information on the submission of queries by file, it is recommended to read the corresponding documentation.

It is then mandatory to fill the various directories used to manage this submission of queries by file.

  • Directory of query start files (.job) (field REPJOB)


  • Directory of template files (.mod) (field REPMOD)

This group of parameters defines the different directories used for the management of queries submitted by a file. These directories are expected to be found, by default, on the application server (another server on the network is possible, with the syntax server@directory, but in no case should the directory be on a client workstation). The extension used for the processed files is specified between brackets in the header of the column.

The creation of the files for submitting the queries to the batch server is documented in more detail in the corresponding documentation.

  • Directory of status files (.sta) (field REPSTA)


  • Directory of in-process query files (.run) (field REPRUN)


  • Directory of pending query files (.req) (field REPREQ)


  • Directory of query stop files (.kil) (field REPKIL)


  • Directory of request start archive files (.old) (field REPOLD)




Error messages

In addition to the generic error messages, the following messages can appear during the entry :

Maximum : N

An attempt has been made to submit more simultaneous batch tasks than are authorised by the license.

Tables used

SEEREFERTTO Refer to documentation Implementation