How will SYSB-II affect my batch run-times?

Some batch jobs run longer, while others are not affected. The effect on your particular batch job depends on variables such as:

  • Is your batch job I/O bound?
  • What percentage of the records in the file does batch update?
  • How many records does the file being updated contain?
  • Does the batch job update records on several files or just one file?
  • What is the sync point frequency?
  • Are you using logging on the CICS VSAM files?
  • Are the files being updated in different FORs?
  • Are the VSAM files defined as RLS?
  • Does the batch job also update DB2 or DL/1 files? If so, are those files part of the same VSAM batch transaction (unit of work)?
  • What is the priority of the batch job in relation to other CICS activity?
  • How well-tuned is your CICS address space?

SYSB-II has many capabilities which minimize the impact batch has on your CICS address space and batch run-times. For example, your batch read I/O can stay in the batch address space while CICS does the actual file updating. If you have a long-running batch job, it might be appropriate to use the sequential stripping technique described earlier. This is a very effective technique for shortening batch run times by 30 percent or more.

Every data center is unique. That’s why H&W professionals guide you through tuning your system to ensure you get optimal results with SYSB-II. To learn more, call 1-800-338-6692 or e-mail

Strategic partnerships:

IBM Business Partner IBM Destination z