Give your on-line subsystem sufficient storage

Many VSE users seem to have frequent instances of CICS Dynamic Storage Area Short-On-Storage conditions. These cause very significant increases in transaction response time (extra delays), increased CPU and I/O activity caused by purging programs and subsequently reloading them,

With CICS Transaction Server for VSE and for zOS (or MVS) these conditions should be significantly reduced, but if you are using an older version of CICS (e.g. CICS/VSE) on VSE/ESA 1.3 or later, these SOS conditions are very expensive from a performance perspective.

The key to minimizing these conditions is to first take inventory of the storage available for your CICS subsystem to use. In this case, we are interested only in 24-bit storage.

To begin, we want to inventory the general storage in use by the operating system. We are interested in identifying any UNUSED storage in the system 24-bit shared area. Some key items to consider:

• Use the VSE MAP command to check the system 24-bit shared storage area.

  MAP
  AR 0015  SPACE AREA      V-SIZE   GETVIS  V-ADDR  UNUSED NAME
  AR 0015    S   SUP         656K                0         $$A$SUPX
  AR 0015    S   SVA-24     1648K    1664K   A4000    128K <---------
  AR 0015    0   BG V       1280K    4864K  400000  45056K
  AR 0015    1   F1 V        788K     812K  400000      0K POWSTART
  AR 0015    2   F2 V       2048K   49152K  400000      0K CICSICCF
  . . .
  

  If the 24-bit SVA UNUSED storage (indicated by <-------- above) exceeds 1024K, it is likely that you have not specified the IPL SYS SPSIZE=0M command. Almost no VSE customers use the VSE shared partition space facility, and if you don't use this facility, there is no reason to reserve space for it. The default value for this parameter is SPSIZE=1M, and it should always be overridden explicitly unless you NEED this facility.

  Except when the SYS SPSIZE=0M command has not been specified (and SPSIZE=1M or a larger value is in effect) the largest value for this unused storage will be just less than 1024K, because this value is space not used because of system address space rounding (all address spaces must begin on a 1M boundary).

  The difference between the UNUSED value shown in the MAP command (128K in the example above) and 1024K is the amount of storage needed, which if freed would allow the program partition starting address (40000, or 4M in the above example) to be reduced by 1M.

  The remainder of these items will focus on identifying additional storage that can be combined with the UNUSED storage to lower the partition origin.

  Lowering the partition origin will give CICS or other on-line applications a total of 1024K (1M) additional 24-bit storage which can be used as needed by that application.

• Use the VSE GETVIS SVA command to check the system 24-bit SVA GETVIS area.

  Following is an example of a display of a static partition-GETVIS information:
  AR 015 1I40I READY
  => GETVIS SVA
  AR 015 GETVIS USAGE   SVA-24   SVA-ANY                   SVA-24  SVA-ANY
  AR 015 AREA SIZE:     4,096K    7,168K
  AR 015 ALLOCATED:       100K      228K   MAX. EVER USED:   104K     148K
  AR 015 FREE AREA:     3,996K    6,940K   LARGEST FREE:   3,992K   6,936K
   
         <-- GETVIS Command Column 1 -->   <-- GETVIS Command Column 2 -->
  

  As you can see, the GETVIS command is divided into two major columns, and you should consider the second (right-hand) column to merely be an continuation of the first (left-hand) column.

  Within this data, 24-bit data is specifically identified, while 31-bit data is not directly shown, as the "ANY" data shown is the sum of 31-bit and 24-bit data. Recall that an application requests "24-bit" or "ANY" GETVIS, and if "ANY" is specified, 31-bit storage will be allocated if available. If 31-bit storage is not currently available, then the system will allocate 24-bit storage to fulfill the request if possible.

  In summary, this display tells the following:

  • The SVA has an actual GETVIS space of 4,096 KB below 16MB (SVA-24) and a total GETVIS space of 7,168KB (SVA-ANY). (SVA-ANY) - (SVA-24) gives the GETVIS space for the 31-Bit area.
  • 100 KB (of 4,096) are currently allocated below 16MB; 128 KB are used above 16MB, that means a total of 228KB is used (of 7,168KB). It may be that a MAX.EVER USED SVA-24 shows a total of 4,096KB and SVA-ANY a total of 7,168KB. There may be no unique reason for this situation. It could be that both the space above 16MB and below 16MB really is used up. Definitely the area above 16MB is exhausted. However, if a LOC=ANY request was redirected to the area below 16MB, the MAX.EVER USED value is set to a maximum although the area below 16MB is not completely used up. In this case increase the partition size (area above 16MB) and check the GETVIS usage again until the situation disappears.
  • 104KB (respectively 148KB) is the highest number of bytes that has been used as GETVIS space at any point in time since you started the partition (high watermark).
  • The largest contiguous free area has a size of 3,992KB (6,936KB). GETVIS

  Examine the 24-bit column to identify the 24-bit System GETVIS area size and the highest amount of this area that has been used. After watching the Maximum Ever Used value over a period of time including busy times, you will be able to identify whether there is excess 24-bit System GETVIS specified.

  I recommend that you reserve 200-300K (say 256K) of additional System GETVIS storage beyond the highest amount ever used, to allow for peak demand that might not have been experienced. If you find the area size is more than 256K larger than the maximum amount ever used, you should determine the excess and reduce the IPL SVA GETVIS=(llllK,hhhhK) 24-bit value (the llllK value).

  The llllK value you specify is added to a system determined amount to give the amount of area size you see in the MAP command.

  This amount of storage you remove from the GETVIS llllK parameter is added to the system's 24-bit unused storage area. If this pushes the amount over the 1024K rounding amount, the system will automatically reclaim the unused 1024K and make it available for below-the-line partition storage, by reducing the partitions' origin address by 1M (100000 in the origin column of your MAP command output).

  You should also check the GETVIS output to ensure that there is sufficient 31-bit GETVIS storage available. I recommend you provide 2 megabytes (or so) of additional 31-bit GETVIS, and periodically check to see if more 31-bit GETVIS might be helpful. Note that if the 31-bit GETVIS area is filled, storage in the 24-bit area is used instead. Does this hurt? Yes, because you would need to specify additional 24-bit GETVIS, and that can encroach on your program private space.

• Use ICCF or the console to run the VSE Librarian (LIBR) interactively. Issue the LIBR LD SDL command to examine the program area of the SVA.

  The beginning of the LIBR output will show an overview of LIBR use of 24-bit and 31-bit SVA storage for SDL entries and for programs.

  You should remember that VSE systems seldom change or add to the programs in the SVA between IPLs -- but that when an SVA-loaded program is re-linked due to service or other system maintenance, a new copy will be loaded into the SVA, and it will occupy additional SVA space. Thus, you should reserve some SVA space for program maintenance, but the amount need not be excessive. I recommend 100-150K (say 128K) of additional System SVA program area. If you examine the LIBR LD SDL output after several days of activity, you can determine whether you have excessive allocation for 24-bit SVA programs.

  Determine the excess program area amount, and then subtract the excess amount from the IPL SVA PSIZE=(llllK,hhhhK) llllK value.

  As with the SVA GETVIS parameter, the amount you've removed from the PSIZE 24-bit value will be added to the system's SVA UNUSED area, and if the UNUSED area goes over the 1024K amount, it will be reduced automatically and the additional address space area will be moved into the program partition area. If you provide too little 31-bit SVA program area, the programs will be loaded into 24-bit SVA storage, which in turn increases the system's 24-bit shared area size and can adversely impact the size of your program partition area.

• Other areas that may similarly be reduced include the SDAREA if you don't use SDAID or vendor products which use that storage area. It is normally not useful to allocate a SDAREA larger than 64K in any case.
• You can use the SIR command to determine the usage of CCW Translation Buffers (also called Copy Blocks). The default VSE system (2.3 and earlier) used these in a method called "Fast CCW Translation", where the contents of the buffers was retained as long as possible to attempt to reuse already translated channel programs.

  The problems with this (nice sounding) mechanism include

  1. you can't tell how many copy blocks you need, so you will likely have over-allocated the number, just in case.
  2. CICS, VTAM, VSAM, DL/I, SQL (DB2) and other programs which use dynamic buffering techniques for their buffering gain no benefit from the Fast CCW Translation mechanism, as they seldom if ever reuse a channel program. Using FASTTR requires that VSE first scan the pool of copy blocks, where it will not find a stored channel program that matches, and then must translate the new channel program normally.
  3. As the number of buffers increase, some additional CPU time is needed to manage and scan the buffers.

  So, what should you do? Specify the NOFASTTR option in your system STDOPT statements to disable the FASTTR mechanism. Then, you can use the SIR command to identify the true high water mark of copy blocks in use. If you find, as many do, that you have excessive copy blocks define (the default is 1500), you can reduce that value. This storage will also be moved into the UNUSED area to help get additional storage for CICS' use.

  Because copy blocks are only 72 bytes long, savings may not be great, but if the additional storage savings can cross the 1024K boundary, you can save another megabyte of private area storage.