Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Background CICS vs MVS JCL Batch
- Thread starter djbooth
- Start date
Yes
[ol][li]CICS generally runs at a significantly higher priority than batch jobs. If your processing is intensive, you need to ensure that it doesn't impact overall performance, not just on the online service but of ancillary address spaces like DB2.[/li][li]You need to make sure that your program doesn't do anything which may impact the CICS address space. This includes opening and closing files, non-CICS I/O, GETMAINs and FREEMAINs outside of LE/370 control, etc. etc. Basically anything that issues an SVC under the covers. When you use the CICS version of these services, they are done asynchronously - CICS puts them on a wait chain and gets on with processing another transaction. If you do them yourself, the CICS maintask gets to wait while the operation completes, and almost 30 years' worth of development effort designed to make CICS as slick as possible goes down the toilet.[/li][li]If you do write an intensive batch style transaction (and this can be a very successful design in the right instance), make sure that everybody else gets a look in. Take regular syncpoints to free up resources, use EXEC CICS DELAY with a zero wait value at reasonable intervals in the middle of compute-intensive loops to give CICS a chance to schedule other transactions. In other words, be nice to other users of the same CICS region.[/li][li]CICS is designed to process lots of little transactions that get turned around very quickly. Long running transactions cause delays during restarts unless they take regular syncpoints[/li][li]Consider restartability: what happens if it breaks? What state will your databases be in? JCL batch may be easier in this situation.[/li][li]How will the process get scheduled? How will you know if it has completed successfully? When a batch job fails, you get to hear about it pretty quickly, either through automated ops, the scheduler, or someone calling you. It is harder to see that a background task has failed, unless you have automated ops monitoring for failure messages in the log.[/li][/ol]That's all I can think of right now. Generally speaking, it's best to do batch work in batch, and OLTP in CICS, but there are exceptions, and I've written some very successful 'batch' CICS transactions. If all you want is a batch job that can be started by an online user from a transaction, then see if your scheduling package has an API you can call to demand in the job. If not, then you can always use SPOOLOPEN/SPOOLWRITE to submit your own job to the internal reader from CICS.
HTH
Steve
[ol][li]CICS generally runs at a significantly higher priority than batch jobs. If your processing is intensive, you need to ensure that it doesn't impact overall performance, not just on the online service but of ancillary address spaces like DB2.[/li][li]You need to make sure that your program doesn't do anything which may impact the CICS address space. This includes opening and closing files, non-CICS I/O, GETMAINs and FREEMAINs outside of LE/370 control, etc. etc. Basically anything that issues an SVC under the covers. When you use the CICS version of these services, they are done asynchronously - CICS puts them on a wait chain and gets on with processing another transaction. If you do them yourself, the CICS maintask gets to wait while the operation completes, and almost 30 years' worth of development effort designed to make CICS as slick as possible goes down the toilet.[/li][li]If you do write an intensive batch style transaction (and this can be a very successful design in the right instance), make sure that everybody else gets a look in. Take regular syncpoints to free up resources, use EXEC CICS DELAY with a zero wait value at reasonable intervals in the middle of compute-intensive loops to give CICS a chance to schedule other transactions. In other words, be nice to other users of the same CICS region.[/li][li]CICS is designed to process lots of little transactions that get turned around very quickly. Long running transactions cause delays during restarts unless they take regular syncpoints[/li][li]Consider restartability: what happens if it breaks? What state will your databases be in? JCL batch may be easier in this situation.[/li][li]How will the process get scheduled? How will you know if it has completed successfully? When a batch job fails, you get to hear about it pretty quickly, either through automated ops, the scheduler, or someone calling you. It is harder to see that a background task has failed, unless you have automated ops monitoring for failure messages in the log.[/li][/ol]That's all I can think of right now. Generally speaking, it's best to do batch work in batch, and OLTP in CICS, but there are exceptions, and I've written some very successful 'batch' CICS transactions. If all you want is a batch job that can be started by an online user from a transaction, then see if your scheduling package has an API you can call to demand in the job. If not, then you can always use SPOOLOPEN/SPOOLWRITE to submit your own job to the internal reader from CICS.
HTH
Steve
- Status
Similar threads
- Locked
- Question