Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Background CICS vs MVS JCL Batch

Background CICS vs MVS JCL Batch

Background CICS vs MVS JCL Batch

Hello, Does anyone know the pros/cons of running a program as a Background CICS task vs runnning the same program via JCL Batch?

RE: Background CICS vs MVS JCL Batch


  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. Consider restartability: what happens if it breaks? What state will your databases be in? JCL batch may be easier in this situation.
  6. 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.
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.


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close