Cobol dc on le and high storage pool 0 usage
Javier Sotela
We move to os/390 rel. 2.8 last december. We had a cobol dc program
thats ran o.k. on vse when two user ran the same program. Not high
storage pool 0 consumption. Now, on os/390, when we run the dc-cobol
program its ran and there is not high storage pool 0 consumption. The
problem arise when we run two times the same program. The storage pool 0
go to a 100% and some times the system hang until one of the program its
canceled (we keep at least one user with OPER active). Any ideas or
suggestions will be great.
Thanks.
Javier Sotela
Jim Moore
Wood, Chris
Are you running VSII COBOL programs? Do you have OPTION 49 set on?
Chris Wood
Alberta Department of Resource Development
CANADA
-----Original Message-----
From: Javier Sotela [mailto:jso...@NS.ICE.GO.CR]
Sent: Friday, January 26, 2001 3:56 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Cobol dc on le and high storage pool 0 usage
The programs are linkedited with amode(31) rmode(any), thats exactly that
they was linkedited on vse. Jim are you talking about anything else
?????
Thanks.
Javier Sotela
?????
Thanks.
Jim Moore
Something doesn't sound right. Answer these questions and you might discover the answer:
1) Are the COBOL programs being compiled with the RENT (reentrant) compile time option?
2) Are the progams being link-edited with the RENT (reentrant) option?
3) What program pool are the programs currently being loaded into?
4) On OS/390 V2R8, you should be using LE COBOL. Correct? Does the COBOL compile listing read: COBOL for MVS & VM V1R2 or something like this?
5) How are the tasks that these COBOL programs run under defined in the sysgen? LOC BELOW or LOC ANY?
6) Do any other COBOL programs cause this same problem?
Reentrancy is not the same as AMODE/RMODE. COBOL compilers have for many years tied the two of these together. For example, if you code RENT as a compile time parm of LE COBOL, you will automatically get DATA(31), RMODE(ANY) settings in the object deck (unless overridden via alternate settings to these compile parms). The key to your problem is that it occurs when the same program is run by two different tasks at the same instant in time.
All storage for 31-bit reentrant COBOL programs should be coming from 31-bit pools. Not pool 0.
IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM> wrote:
> Javier,
Are you running VSII COBOL programs? Do you have OPTION 49 set on?
Chris Wood
Alberta Department of Resource Development
CANADA
-----Original Message-----
From: Javier Sotela [mailto:jso...@NS.ICE.GO.CR]
Sent: Friday, January 26, 2001 3:56 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Cobol dc on le and high storage pool 0 usage
The programs are linkedited with amode(31) rmode(any), thats exactly that
they was linkedited on vse. Jim are you talking about anything else
?????
Thanks.
Jim Moore wrote:
> Recompile as reentrant, 31-bit, link-edit 31 bit and change sysgen for
program to be reentrant. LE Cobol should never use Pool 0 storage.
Javier Sotela
Thanks.
Erwin Marschalk
i remember, there is a problem in the LE runtime environment. The LE runtime
allocates at initialization time about 50k storage below the line (Pool 0).
It does not care, if the task is LOC ANY and if the program is AMODE(31)
RMODE(ANY). This storage is always allocated below the line and may be never
used or only used from LE.
Erwin
"Jim Moore" <conl...@IX.NETCOM.COM> wrote in message
news:Springmail.105.98...@springmail.com...
Philippe P Jacqmin
As during peak period we are facing too much SOS on Storage Pool O, we are also trying to catch
the guilty.
PMDC for a running COBOLII under LE (IDMS 14.0) gives the following info:
RESOURCE-TYPE RCE-ADDR RES-ADDR USE RESOURCE-DETAILS
INTERNAL RU 16297EE0 0004E2D8 1 RU=RHDCRUAL AREA= DDLDCRUN
SLTE=SLTE**** 1628B560 1B04A008 1 RU=KR9C5CGE S=KRC5S07 A=AR-KRC5HIT
STORAGE 1628C480 198E7000 1 L=11392 STG POOL#=128 PRFIX=VB50
STORAGE 16297580 1B319E80 1 L=128 STG POOL#=255 PRFIX=0719
STORAGE 16270040 0039B800 1 L=256 STG POOL#=0 PRFIX=R.L.
STORAGE 1627E0C0 1B319000 1 L=3584 STG POOL#=255 PRFIX=$. .
STORAGE 16277FE0 00394400 1 L=640 STG POOL#=0 PRFIX=
STORAGE 1628EC60 0038E200 1 L=768 STG POOL#=0 PRFIX= ...
STORAGE 16281DA0 19B42400 1 L=1792 STG POOL#=128 PRFIX=SRVI
STORAGE 162995C0 1B310000 1 L=3584 STG POOL#=255 PRFIX=$, .
STORAGE 16296EA0 1B2B4000 1 L=3584 STG POOL#=255 PRFIX=$...
STORAGE 16275DE0 19B09000 1 L=127744 STG POOL#=128 PRFIX= .R.
STORAGE 1628A180 00389000 1 L=20736 STG POOL#=0 PRFIX=USER
STORAGE 162865A0 1B2A8000 1 L=3584 STG POOL#=255 PRFIX=
STORAGE 162990C0 192EB300 1 L=1024 STG POOL#=128 PRFIX=EHB$ KEPT
QUEUE 16293560 1B319E88 1 Q=071908EP RECORDS=
PROGRAM 16269460 00199A00 2 PROG=INFOCOMP VERSION=0 RE-ENTRANT POOL
PROGRAM 1626FE20 17317C00 3 PROG=KRC5S07 VERSION=0 XA RENT POOL
PROGRAM 1627F240 17B7BE00 2 PROG=KR9C5CGE VERSION=0 XA RENT POOL
4 pieces of storage are still allocated (or located) below the line.
The largest one is empty, I mean contains binary zeroes.
Another catch using PMDC, same conclusion, the largest block contains binary zeroes
and the another one is displayed : USERREGS....
RESOURCES FOR TSK=KRC5UPC #36776 PR=100 TYPE=USER PRG=KR9C5UPC LTE=LD000000
RESOURCE-TYPE RCE-ADDR RES-ADDR USE RESOURCE-DETAILS
ENQUEUE 16268D00 1AFDC708 2 ID=KRC5UPC
SLTE=SLTE**** 1628A500 1AFDC1D4 1 RU=KR9C5UPC S=KRC5S06 A=AR-UPCSEND
INTERVAL 16273800 1B174F08 1 TYPE=WAIT SECS LEFT=1
STORAGE 16290DA0 194FB000 1 L=9856 STG POOL#=128 PRFIX=VB50
STORAGE 1626A340 002F2000 1 L=18432 STG POOL#=0 PRFIX=
STORAGE 162692E0 19251000 1 L=103808 STG POOL#=128 PRFIX= ?-.
STORAGE 16269000 002AC000 1 L=2304 STG POOL#=0 PRFIX=USER
STORAGE 162697A0 1AFDA000 1 L=3584 STG POOL#=255 PRFIX=
STORAGE 16268F60 19213000 1 L=1280 STG POOL#=128 PRFIX=UAB* KEPT
PROGRAM 16268D80 16BC1200 2 PROG=KRC5S06 VERSION=0 XA RENT POOL
PROGRAM 16269BE0 16BBEC00 2 PROG=KR9C5UPC VERSION=0 XA RENT POOL
002AC000 0000 16269000 00000180 E4E2C5D9 D9C5C7E2 *........USERREGS*
002AC010 0010 19266AB8 19266BE8 192699F4 002F64C0 *......,Y..R4....*
002AC020 0020 16BBEC54 00000000 00000000 00000000 *................*
002AC030 0030 1926A0C0 16BBECA8 192690C0 16BBEE54 *.......Y........*
002AC040 0040 16BBEC80 19266948 8015D1D6 002AC010 *..........JO....*
002AC050 0050 0004D9C0 00000000 96BC0FEE 19266948 *..R.....O.......*
002AC060 0060 002AC488 16BC104E 16BBEC54 002AC4DC *..DH...+......D.*
002AC070 0070 00000000 00000000 802AC234 19266948 *..........B.....*
002AC080 0080 00000000 00000000 16BC0D90 002AC488 *..............DH*
002AC090 0090 96BC0FE0 00000000 078D3000 96BC0FF8 *O...........O..8*
002AC0A0 00A0 00000000 00000000 00000000 00000000 *................*
002AC0B0 00B0 00000000 00000000 00000000 00000000 *................*
002AC0C0 00C0 00000000 00000000 00000000 00000000 *................*
002AC0D0 00D0 00000000 00000000 00000000 00000000 *................*
002AC0E0 00E0 00000000 00000000 F1F27AF0 F17AF5F0 *........12:01:50*
002AC0F0 00F0 4BF3F3F9 F31E167D B0968C17 AE1E167D *.3393..'.O.....'*
002AC100 0100 D8000000 002AC010 002AC010 80176E00 *Q.............>.*
002AC110 0110 000014B8 00000000 0041E930 00000000 *..........Z.....*
002AC120 0120 80000000 00000000 00000000 00000000 *................*
002AC130 0130 00000EE8 88108400 00000000 000025E0 *...YH.D.........*
002AC140 0140 16BBEC00 00000000 D2D9F9C3 F5E4D7C3 *........KR9C5UPC*
We continue our research about the storage pool 0.
We suspect COBOLII under LE still allocates storage below the line.
In ADSO we did catch a OWA (Online Work Area of ADSO) below the line.
This is my contribution to this "Below the line" case.
Always ready to share knowledge.
Philippe JACQMIN
IDMS Middleware
DEXIA Bank
JB Moore
much easier to answer posted queries about COBOL, LE and DC if posts
included all of the specifics of a DC environment. For example:
1) Is it COBOL II running with LE Runtimes (CEE and IGZ mixed)?
2) If COBOL II and LE, are sites using the RES compile option for DC COBOL?
This is a huge.
3) If pure LE, have all of the DC COBOL programs been re-compiled using the
LE compiler?
Some people contacted me to advise that it is the SYSGEN "REENTRANT" clause
on a program that CA-IDMS DC goes by when loading programs. To which I
answer: If you define a program as reentrant in the SYSGEN, it had best be
reentrant. In other words, just declaring it reentrant won't do.
To the curious, the RENT COBOL compile option makes the TGT and the PGT
dynamically acquired, just as Working Storage has always been dynamically
acquired. Since these COBOL control blocks are frequently modified during
the course of a COBOL program's execution, having them as part of the
dynamically acquired "working-set" is what allows for pure reentrancy in
COBOL. In other words, the RENT COBOL option truly generates a reentrant bit
of linkable object code. I know it works because I have put LE COBOL
programs in linklist datasets with the reentrant attribute and never has it
caused any mysterious S0C4s.
The RENT link-edit parm sets a bit in the directory of the load library PDS
and thereby clues in the OS/390 SVC (SVC 06) that this program has the
reentrant attribute.
And finally, lest we forget the BAL folks, the RENT assembly time option
only flags instructions that violate the rule of reentrancy. Which is, by
the way: A program cannot modify "itself". It must do all data manipulation
in storage that it outside of "itself". Whether the program dynamically
acquired such storage, or whether the storage is in some other program's
acquired storage or even if the program is doing ALL of it's work in
registers, it matters not. It CANNOT modify itself.
Easy as hell to do in Assembler but almost impossible to do in COBOL (except
for ALTER GO TO and TGT/PGT).
Jim Moore
Alan Fields
which program pool to load the program in. If the gen attribute is
NON-reent, the program will be loaded in a nonreentrant pool, no matter
what the compile or link edit attributes may say, and, if the gen attribute
is REENT, it will be loaded in a reentrant pool. No matter which pool is
selected for program load, CV will still know that the program is fully
reentrant or not (it gets this from the PDS directory) and handle it
properly.
Alan Fields
VF Services
Greensboro, NC
(336) 332-5631
Alan_...@vfc.com
JB Moore <conl...@IX.NETCOM.COM>@LISTSERV.IUASSN.COM> on 02/05/2001
02:50:31 PM
Please respond to IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
Sent by: IDMS Public Discussion Forum <IDM...@LISTSERV.IUASSN.COM>
To: IDM...@LISTSERV.IUASSN.COM
cc:
Subject: [IDMS-L] Time to pay the RENT, RENT, RENT
Javier Sotela
1. We are running cobol for mvs in a pure le environment, not cobol II on
anywhere.
2. We move our system from vse with cobol for vse on le environment too, not
cobol ii on anywhere.
3. We test our dc programs after we recompile it under le ant its ran o.k., but
I never check where the program was loaded.
4. We move our production environment and everithing running o.k. with our test
pre-real production migration.
5. We move our production environment, not test, it was real. No problem for 15
days.
6. We notice 15 days after the migration a high storage pool 0 consumption.
Checking the system we catch a dc program that ran o.k. only alone. If two
copies of the program ran concurrently the storage pool 0 crash and the only
solution was cancel one dc program.
7. In vse, our program was compiled using rent option only on the compile phase
not on the linkedit fase and the program was catalogued rent. On os/390, you
have to use rent like option on the linkedit phase, not only on the compile
phase. That was the problem, the dc programs was not rent and the final results
are unpredictable, it depends if you run concurrently two copies of the same
program.
Maybe somebody have doubts about it, but beleive thats resolve my problem.
Thanks.
Javier Sotela
JB Moore
straight is: RENT-RENT-RENT (or RENT-cubed)
RENT on the Compile.
RENT on the Link
RENT on the Sysgen.
Jim "I paid my RENT" Moore
BRANDT Rene
You have also to give the parm PARM='COBOL=2' in the IDMS precompilation.
I hope this help,
Rene
----------------------------------------------------------------
This document should only be read by those persons to whom it is
addressed and is not intended to be relied upon by any person
without subsequent written confirmation of its contents. If you
have received this e-mail message in error, please destroy it
and delete it from your computer.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and/or publication of this E-mail
message is strictly prohibited.
----------------------------------------------------------------
René BRANDT / IT (Information technology) rbr...@pictet.com
Pictet & Cie, Banquiers Tel. (+4122) 318 22 11
29, boulevard Georges-Favon Fax (+4122) 318 22 22
CH-1204 GENEVE http://www.pictet.com/
----------------------------------------------------------------