Auto start jobs

The M3 auto start job subsystem has a number of predefined jobs that are performed according to the settings in the subsystem maintenance programs described in this document. The predefined jobs can be used for purposes such as:

  • Allocating order lines
  • Rescheduling manufacturing orders
  • Processing and printing picking lists
  • Printing order confirmations
  • Releasing stock locations
  • Updating transaction history

The units of work, for example records to be processed, are stored in queues within work tables until the corresponding auto start job has processed them.

The autostart jobs automatically shut down after 24 hours, but new instances of these jobs start when necessary.

Run modes

Two run modes exist for auto start jobs: Classic or In-memory Queue (IMQ) which differ on the queuing process. These modes are indicated for each job on ‘Subsystem Job. Open’ (MNS051/E).

  • Classic

    In this mode, the auto start job runs in a single thread and only one request is processed at a time which is a first in, first out concept. In some auto start jobs, multiple instances are created to enable simultaneous run. Each of these instances has their own single thread.

    By default, the run modes of auto-start jobs are in Classic mode and it is the users' discretion to modify it and use IMQ.

    As an example, when customer orders are entered, records are created and stored in the work table. The auto start job continuously monitors the work table and processes the records. In the auto start job functionality for M3 Business Engine, you can run parallel jobs against a work table to consume the queue faster. As an alternative, you can set priorities in 'Subsystem Job. Select Record' (MNS052).

  • IMQ

    In this mode, the auto start job automatically creates multi-threads to process records depending on the size of the queue. This enables simultaneous execution of work units resulting in better responsiveness of auto start jobs in processing requests. Additional instances of the job will not run if the standard instance of it is running in IMQ mode.

    If the run mode selection is IMQ, fields are also indicated in (MNS051). These fields are managed by Infor and cannot be modified by the users:
    Field The field indicates...
    IMQ program ...the program running when an auto start job is in IMQ mode.
    Max queue size ...the number of records to be distributed to the consumers.
    Max nbr consumers ...the maximum number of parallel threads that process jobs on queue.

    For example, if users have been assigned to roles in 'Roles per User. Connect' (MNS410), the records are then written in the work table. The auto start job will then create multiple parallel threads of the job depending on the size of the records to be processed as shown in the diagram. Once all work units are processed by a thread, it automatically ends.

    IMQ is not applicable to all auto start jobs. One limitation is that IMQ can only run in one market configuration. This means that it is not applicable if the job has selections in (MNS052) for at least one of its instances. The auto start job always runs in Classic mode despite being declared as IMQ-enabled in (MNS051).

Subsystem control

These properties describe the auto start jobs:

  • Job start - The auto start jobs are automatically started each time the subsystem is started. When the subsystem is active, the auto start job functionality is active and works as described in the figure above.
  • Inactive subsystem - Even when the subsystem is not active, the necessary records are written to the work tables. When the auto start jobs are started again, all records are processed. The records are sorted according to the first in, first out principle. It must be observed, however, that when the subsystem is down, certain data, (for instance available to promise), may not be completely up to date.