16.4.1 Establishing the X_JOBQ.DAT File
To use this emulation facility you must first establish a file called X_JOBQ.DAT in the primary x_lansa directory (for example c:\program files\LANSA\x_win95\x_lansa under Windows 32-bit).
Note that when executing a 64-bit application, x_win64 replaces x_win95.
This file specifies, for all associated partitions, the names of the job queues and optionally, job descriptions which use this facility.
Any reference to job queues or job descriptions that are not defined in X_JOBQ.DAT remain unchanged and continue to execute in the default manner.
X_JOBQ.DAT is a text file that can be created and edited with most text editors. For example, X_JOBQ.DAT may be defined like this:
jobq=qbatch=c:\jobq\qbatch
jobd=qbatch=c:\jobq\qbatch
These X_JOBQ.DAT entries indicate that any SUBMIT command reference to job queue qbatch or job description qbatch should be routed, as a IBM i emulated job, into the directory c:\jobq\qbatch ..... for execution at some later time by the "monitor" of that queue (more information about queue "monitors" follows).
Important things you must know about this file:
- Each line must be formatted,
<type>=<name>=<path> where:
|
|
<type> |
Must be "JOBQ" (job queue) or "JOBD" (job description). |
|
|
<name> |
Is the job queue or job description name which must conform to IBM i object naming conventions. |
|
|
<path> |
Is the fully qualified path name to a directory that will be used as the job "queue". The directory must exist at the time you begin to execute any application that references a job queue or description in this file. The path name does not have to be associated with the queue or job description name in any way. |
- Lines not formatted in this manner will be ignored. No error messages are issued for ignored lines.
- JOBQ= entries may exist by themselves.
- Every JOBD= entry must have an associated JOBQ= entry that has exactly the same path details. This allows job description names to be associated with a job queue name.
- All JOBD= names must be unique.
- All JOBQ= names must be unique.
- Every unique JOBQ= entry must have an associated unique directory path that must exist and be accessible at execution time. All users require write access to the directory. Job queue monitors require full read, write, update and delete rights to the directory.
- No individual entry line in X_JOBQ.DAT can exceed 256 bytes.
- Entries in X_JOBQ.DAT are all read into memory the first time that they are referenced. Subsequent references within the same x_run session refer to the details stored in memory. This means that changes to X_JOBQ.DAT may not be reflected in currently active x_run sessions/jobs.
- When you submit a job to a job queue in LANSA on a windows environment, the job appears with a 'Q' extension, e.g., job T313330.Q50. The Q extension is given a unique alpha/numeric identifier for each job submitted in one second for a particular process. For example if job T313330. Q50 is submitted with other jobs in the same second, LANSA will start assigning extensions Q51, Q52,..., Q5A, Q5B, Q5C, ... Q5Z. There is a limit of 36 jobs per second applicable for this unique identifier. To avoid any potential loss or corruption of submitted jobs, you should not submit more than 36 jobs per second. If your requirements have the potential to submit more than 36 jobs per second, you should include some logic to delay the submission of jobs.
- When jobs are submitted to an emulated IBM i job queue they always have their TPTH= parameter set to the same value as the path associated with the job queue regardless of how the TPTH= value of the submitting job is set.
- The Job Description and Job Queue Name XLANSAJOBX has been reserved for LANSA internal use. Do not define it in X_JOBQ.DAT
Once set up, entries in this file will cause all SUBMIT commands to examine its contents. If a match is found for the referenced job queue or job description name, then the submitted job will be "routed" to the specified directory.
The routing process consists of creating a series of binary files in the directory that contain details of the submitted job (e.g. request details, exchange values, LDA values, etc). These values are in binary format and they should not be edited or changed.
The series of binary files representing the "queued" batch job will wait until their presence is detected, by the "monitor" assigned to the job queue.