Any way to reduce CSA usage in os390 2.10

Discussion:

(too old to reply)

J***@ibm-main.lst

2004-05-25 01:19:35 UTC

We are in a bit of a CSA crunch after going to OS390 2.10. IMS is a big
hitter, but JES2 also shows shows up as using a good bit of CSA, so I have
to ask the question, does anyone know of a way to reduce CSA usage by JES2
?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Shane Ginnane

2004-05-25 02:17:13 UTC

Permalink

Never found JES2 an issue I must admit.
You running SWA above John ???

On my 1.4 system that handles the printers for all LPARs, the total
consumption of CSA for the JES2 address spaces is 8308 (hex) - doesn't
look like a lot to me.

Shane ...

Post by J***@ibm-main.lst
We are in a bit of a CSA crunch after going to OS390 2.10. IMS is a big
hitter, but JES2 also shows shows up as using a good bit of CSA, so I have
to ask the question, does anyone know of a way to reduce CSA usage by JES2

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Larry Kraus

2004-05-25 14:37:15 UTC

Permalink

Are you DASD UCBs above the line? In the past, I worked at a shop that
ran IMS, and we were extremely tight on CSA. I believe we had at least
10,000 DASD devices defined. Life was a lot better once I changed them
to LOCANY=Y.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Behalf Of John Mattson
Sent: Monday, May 24, 2004 9:18 PM
To: IBM-***@BAMA.UA.EDU
Subject: Any way to reduce CSA usage in os390 2.10

We are in a bit of a CSA crunch after going to OS390 2.10. IMS is a big
hitter, but JES2 also shows shows up as using a good bit of CSA, so I
have to ask the question, does anyone know of a way to reduce CSA usage
by JES2 ?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html

Disclaimer: This e-mail message is intended only for the personal use of
the recipient(s) named above. If you are not an intended recipient, you
may not review, copy or distribute this message. If you have received this
communication in error, please notify us immediately by e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or distributed
without this statement.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Ben Alford

2004-05-25 18:29:58 UTC

Permalink

We have run our STC with SWA=ABOVE on os/390 2.10 w/o problems. Note
that all of our old tools and toys we have which cannot tolerate
SWA=ABOVE (yet) are run in batch or TSO.

Ben Alford Enterprise Systems Programming
University of Tennessee, Knoxville INTERNET: ben-***@utk.edu

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

J***@ibm-main.lst

2004-05-25 18:38:57 UTC

Permalink

Just got to os390 2.10, still running CICS410 & old OS/VSCobol. I was
hoping that at 210 I could move CSCBLOC above, but VSCobol CICS blew up
when some Assembler utilities went to check some information that was moved
above the line. Batch ran fine. Links are static in VSCobol CICS. We try
to mazimize the Private below because so much old Cobol runs there. So we
don't want to increase the CSA, any increase and we would lose a full Meg
of Private below 'cuz it goes in meg chunks, I believe.
CSA=(1800K,256M),
CSCBLOC=BELOW,
We are currently running pretty close to the edga
+ XCSA
########################################################################
+ # Warning: Allocated CSA = 85% (1604K out of 1888K)
#
+
########################################################################
1) How do you set SWA above? Can VSCobol handle it?
2) JES is just one of many we are looking upon. We would be glad to save
CSA from anywhere.

Post by Shane Ginnane
Never found JES2 an issue I must admit.
You running SWA above John ???
On my 1.4 system that handles the printers for all LPARs, the total
consumption of CSA for the JES2 address spaces is 8308 (hex) - doesn't
look like a lot to me.
Shane ...

Post by J***@ibm-main.lst
We are in a bit of a CSA crunch after going to OS390 2.10. IMS is a big
hitter, but JES2 also shows shows up as using a good bit of CSA, so I

have

Post by Shane Ginnane

Post by J***@ibm-main.lst
to ask the question, does anyone know of a way to reduce CSA usage by

JES2

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

ibm-main

2004-05-26 08:57:45 UTC

Permalink

Can't spell Cabal, so won't comment.
The comment from Ed should be heeded. Change "Could probably use more
tuning in CSA" to "Could probably use more tuning in common", and you're
away. Any saving in unneeded LPA allocation gets added to CSA - this is
goodness, especially as you are only just getting more than requested.

If you want to find out what is allocating CSA, your monitor should tell
you, or pull a console dump (*master* is usually a good choice -
asid=1), and hit IPCS with;
VERBX VSMDATA 'OWNCOMM SUMMARY'

Shane ...

Post by J***@ibm-main.lst
Just got to os390 2.10, still running CICS410 & old OS/VSCobol. I was
hoping that at 210 I could move CSCBLOC above, but VSCobol CICS blew up
when some Assembler utilities went to check some information that was moved
above the line. Batch ran fine. Links are static in VSCobol CICS. We try
to mazimize the Private below because so much old Cobol runs there. So we
don't want to increase the CSA, any increase and we would lose a full Meg
of Private below 'cuz it goes in meg chunks, I believe.
CSA=(1800K,256M),
CSCBLOC=BELOW,
We are currently running pretty close to the edga
+ XCSA
########################################################################
+ # Warning: Allocated CSA = 85% (1604K out of 1888K)

Peter Pfaffner

2004-05-25 20:06:36 UTC

Permalink

Post by J***@ibm-main.lst
1) How do you set SWA above? Can VSCobol handle it?

Matthew Stitt

2004-05-25 20:59:30 UTC

Permalink

Since it's OS/VS COBOL, every thing must be 24 bit. Above the line doesn't help much.

-----Original Message-----
From: Peter Pfaffner [mailto:***@ibm-main.lst
Sent: Tuesday, May 25, 2004 4:08 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Any way to reduce CSA usage in os390 2.10

Post by J***@ibm-main.lst
1) How do you set SWA above? Can VSCobol handle it?

SWA location is specified in JES-Parms.
You can activate it selectively for STC, TSU and/or single Jobclasses.
AFAIK Cobol does not take a look to the SWA at all.

As Larry suggested, UCB LOCANY=Y in HCD is one off the biiiig VSCR heroes.
It's a pretty old feature and even older CICS and IMS should be able to cope
with (IIRC) because they are mostly hurt by the LINE.

Not meant as an offense: Sometimes I'm really wondering about sysprogs
scared to use pretty old new features :-)

HTH
Peter
****************************************************************************************************
This e-mail and any files transmitted with it are confidential to abc distributing, llc.
("abc"), and may contain proprietary or copyrighted materials belonging to abc, which
are intended solely for the individual named. If you are not the named addressee, you
are notified that any copying, dissemination, distribution or disclosure of any or all of its
contents, and any action taken in reliance on the transmission, are unauthorized and
prohibited. Please notify abc immediately by e-mail reply if you have received this
transmission in error and take all necessary and appropriate actions to permanently
delete it from your system.
*****************************************************************************************************

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

E***@ibm-main.lst

2004-05-25 21:17:44 UTC

Permalink

In a message dated 5/25/2004 3:59:57 PM Central Standard Time,
***@ABCDISTRIBUTING.COM writes:
Since it's OS/VS COBOL, every thing must be 24 bit. Above the line doesn't
help much.
We did our COBOL/LE conversion at OS/390 1.3 with CICS 4.1. I thought that
with 2.10 you
could use the LE environment with VS/COBOL might have to redo the RDO to
language LE370 in PPT and gain benefit by letting buffers go upstairs without
recompiling. Then there's always the XA Conversion guide to test for above and
below modes.

Could probably use more tuning in CSA. For some reason Book Mangler(EOY),
ISAM and
SDSF are by default in LPA.There's also some ISRCOPY and ISPCOPY members in
SAMPLIB to move most lower use modules to a LINKLST dataset.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Ed Gould

2004-05-25 21:35:56 UTC

Permalink

Post by E***@ibm-main.lst
In a message dated 5/25/2004 3:59:57 PM Central Standard Time,
Since it's OS/VS COBOL, every thing must be 24 bit. Above the line doesn't
help much.
We did our COBOL/LE conversion at OS/390 1.3 with CICS 4.1. I thought that
with 2.10 you
could use the LE environment with VS/COBOL might have to redo the RDO to
language LE370 in PPT and gain benefit by letting buffers go upstairs without
recompiling. Then there's always the XA Conversion guide to test for above and
below modes.

----SNIP_______

Ed,

When we moved SWA above the line (10+ years ago ) we were for the most part
os/vs cobol and didn't run into a single issue with vscobol ... Maybe we
were lucky. We had vendor issues but my now I would think vendors would have
fixed the problem.

We had a few COBOL 2 programs and they did not have a problem either. Maybe
someone could point me to an "known issue" with either of these two
compilers.. we didn't see a thing.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Jon Brock

2004-05-26 17:29:58 UTC

Permalink

Hmmmm. "Intriguing."

<snip>
Can't spell Cabal, so won't comment.
</snip>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html