Sequential number allocation

If you use one or more counters to supply your application with new sequential numbers, consider the following points.

  • You should calculate the frequency of updates for each counter. You should also calculate the elapsed time for the update transaction, measured from update of the counter until commit. If the update frequency multiplied by the calculated elapsed time exceeds about 0.5 in peak hours, the queue time can be unacceptable.
  • If you are considering having more than one counter in the same table space, you should calculate the total counter busy time.
  • If the counters are placed in the same row, they are always locked together.
  • If they are placed in different rows in the same table space, they can be in the same page. Since the locks are obtained at the page level, the rows are also locked together in this case.
  • If the rows are forced to different pages of the same table space (for example by giving 99% free space) it is still possible that the transactions can be queued.

    When for example row 2 in page 2 is accessed, a table space scan can occur. The scan stops to wait at page number 1, if this page is locked by another transaction. You should therefore avoid a table space scan.

  • If an index is defined to avoid the table space scan, it is uncertain whether it can be used. If the number of pages in the table space is low, the index is not used.
  • A solution is then to have only one counter in each table space. This solution is preferred, if more than one CICS® system is accessing the counters.
  • If only one CICS system is accessing the counters, a BDAM file can be an alternative solution. However, the possibility of splitting the CICS system into two or more CICS systems at a later time can make this solution less attractive.