RE: CICS error

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: RE: CICS error
From: Tom Duerbusch (DuerbuschT@stlouiscity.com)
Date: Mon Apr 07 2008 - 14:34:04 EDT


CEMT INQ DSAS
You can modify the numbers in green, in 256K increments.  (just add 1 or subtract 256K and the system will add/subtract 256K).


If you look at 364:

                                                         LIMIT    5120   
                                  CDSA    UDSA    SDSA    RDSA  Totals   
Current DSA Size ..............   1280     256    2304     512    4352   
Current DSA used ..............   1032      32    1708     468    3240   
Peak DSA used .................   1048      64    1708     468           
Peak DSA Size .................   1280     256    2304     512    4352   
Largest free area/Free Storage.   0.90    0.86    0.37    1.00           
Times short-on-storage (SOS)...      0      0      0      0      0   

You should be able to decrease the dsalimit till you hit the "currrent DSA size" under "totals".  If you try to increase it past what you can, it will give you a message, and not do it.

Tom Duerbusch
THD Consulting

Law of Cat Acceleration

  A cat will accelerate at a constant rate, until he gets good and
  ready to stop.


>>> "Ron Ashley" <rashley@hsvutil.org> 4/7/2008 1:17 PM >>>
Can you safely lower the DSALIMIT - for instance move it from 6912k to
6784k. And how do you do it dynamically?

Thanks

-----Original Message-----
From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf Of
Tom Duerbusch
Sent: Monday, April 07, 2008 12:50 PM
To: VSE Discussion List
Subject: RE: CICS error

Obviously, watch for just "upping the DSA Limit below the line".....

Do a 3,6,3 and look at F2, for the ICCF system.

Look at the high water mark for below the line.  You don't want to infringe
on that.
Take the HWM and subtract the currently used, to get a true "available".
Round that down to the next 256K boundry, and that is what you can safely
raise the DSALIMIT by.  Note, you can dynamically raise it at anytime (it is
reset back to the SIT when CICS is restarted).  You may find that 24 bit
getvis is mostly needed at startup.

If this is the ICCF partition, you can also monitor and shutdown a couple
ICCF pseudo partitions.  Those are carved out of the 24 bit area.  Issue a
"/map" from the console to see your current 5 (default) pseudo partitions.
Don't terminate the Class=I partition, but you may be able to get by with
fewer Class=A and Class=B pseudo partitions.

For all CICS partitions, look at your partitions start address.  For years,
we have been able to start the partitions at 5 MB.  Then, it creeped up to 6
MB.  Do a GETVIS SVA to see if you might be able to rearrange things to
reduce the size to get the partition start address back to 5 MB.  If so,
that is 1 MB more that is available to DSALIMIT.  The next time you upgrade
vendor products, check the requirements on how they are loaded in the SVA.
When your VSE release was initially installed (VSE/ESA 2.4 or later) and
FSU'ed to your current release, your vendors may required their SVA programs
in the 24 bit area.  When they upgrade their programs to load in the 31 bit
SVA, their documentation really doesn't "hit you over the head" that this
has changed.  (This includes IBM when you FSU a system.)  Sometimes, you are
loading in the 24 bit area, when you don't need to.  With enough of these
changes, you might be able to get back to a 5 MB partition start address.

And obviously, compile your programs with Cobol/VSE and run them above the
line.  You may need to change the PPT to say "datalocation below" if the
program will communicate with a 24 bit program, but getting the code above
the line, is a good deal.

Tom Duerbusch
THD Consulting

Law of Cat Acceleration

  A cat will accelerate at a constant rate, until he gets good and
  ready to stop.


>>> "Dan Gofton" <dgofton@saginawcounty.com> 4/7/2008 6:42 AM >>>
Yes, CICS/TS for a lot of years now and programs above the line.  I'm also
increasing DSA which will take effect next CICS cycle (tonight).

Thanks for the suggestion.

Dan Gofton
Systems Programmer
County of Saginaw, MI
989 790 5525 

> -----Original Message-----
> From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] 
> On Behalf Of Dennis McLoud
> Sent: Friday, April 04, 2008 3:49 PM
> To: VSE Discussion List
> Subject: RE: CICS error
> 
> Are you running CICS/TS? Are the programs all running below 
> the line? We have not seen this problem since going to 
> CICS/TS and moving most of our programs above the line. You 
> should only see this error after program space compression. 
> CICS doesn't need the pointer to the library unless the 
> program is flushed from memory. You could at least make the 
> problem less frequent by giving CICS more DSA. 
> 
> Dennis McLoud
> Systronics, Inc.
> 913-829-9229
> 
> 
> 


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b25 : Fri May 16 2008 - 11:05:07 EDT