|
|
|
Scheduling packages help insure that the proper activities are performed at the proper time and in the proper sequence for a given set of tasks. For example, the job that prints the payroll checks cannot run until the job that calculates the amounts is completed. The calculation job cannot run until all the departments have reported their employees' hours for the week.
These scheduling systems use triggers to indicate the successful completion of one task, thereby starting the next. The more traditional triggers, with examples, are as follows:
Job X is complete; now run Job Y and Job Z.
Run job BUDGET at noon on the 30th of every month.
The data entry department finishes their order entries for the day, and tells the system through a command that triggers the inventory, shipping, and billing jobs.
Department A creates a file that holds their employees' hours for the week.
The user does not need an interface between CA XCOM Data Transport and the scheduling system to schedule file transfers. CA XCOM Data Transport can run as a batch job just like any other job in the system, and thus can be scheduled like any other job in the system. If an outgoing transfer is part of the required job stream, then a CA XCOM Data Transport batch job specifying SEND can be included in the schedule. Other jobs can be triggered following the successful (or even unsuccessful) completion of the CA XCOM Data Transport job. Likewise, inbound transfers can be scheduled by running a CA XCOM Data Transport batch job specifying RECEIVE.
If CA XCOM Data Transport is going to be used as a trigger for further processing, it is important to understand the difference between queued and non‑queued transfers. A batch job requesting a file transfer to be queued has completed successfully when that transfer has been scheduled. Since the job has reached its completion once the transfer request is in the queue (TYPE=SCHEDULE), the job itself is not aware of whether the file transfer has actually taken place; it cannot relay information about the actual file transfer.
TYPE=INQUIRE jobs may be used to provide a status for TYPE=SCHEDULE jobs. Non-queued transfers, TYPE=EXECUTE, provide information about the actual job transfer and a return code based on the success or failure of the file transfer. For an explanation of the TYPE=SCHEDULE, TYPE=INQUIRE, and TYPE=EXECUTE, see the CA XCOM Data Transport for z/OS User Guide.
| Copyright © 2012 CA. All rights reserved. |
|