Hazy memory, but there is a control block built in LSQA that does
not go away until the INIT/STC terminates when doing RACF calls.
It is only when that address space is cleaned up that the system
gets rid of certain storage and RACF uses that type of storage
(well it did at z/OS 1.13 and prior as I recall).
To keep that from happening, one gets the storage for RACF/SAF
and then frees it once done -- you will have to be in SUPState to
do it.
Dunno if that is the storage creep you are talking about but I
remember, from a past life as a developer, that we had a problem
with it and had to change the way we did things.
Regards,
Steve Thompson
On 05/02/2017 09:41 AM, scott Ford wrote:
All:
I have a STC written in Cobol V4.1 calling Assembler routines to perform
various RACF functions. I have a customer who is reporting seeing a storage
creep in subpool = 0 key 8. We use Subpool = 1 key 8 when we call IRRSEQ00
(r_admin) call. We then issue a 'FREEMAIN', see below:
*---------------------------------------------------------------------*
* REGS PASSED TO FREEMAIN: R3=SUBPOOL R2=SIZE R4=ADDRESS
*---------------------------------------------------------------------*
FREEMAIN RU,A=(R4),SP=(R3),LV=(R2) FREE OLD BLOCK
I know the Freemain is working, we did a test with an ABEND with a dump and
saw r15 = 0 and the above registers and they were correct. The twist here
is right before we call IRRSEQ00, we issue a
MODESET KEY=ZERO,MODE=SUP
issue our call
MODESET KEY=NZERO,MODE=PROB
build output record and pass back to caller.
I ran out STC and issue a RACF command and the issued a
'DUMP COMM=(xxxxxxxx)'
Pulled it into IPCS...reviewing the dump I saw very little subpool = 0
activity..
I am stumped here. We have a called scheduled with IBM.
*IDMWORKS *
Scott Ford
z/OS Dev.
“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”
www.idmworks.com
scott.f...@idmworks.com
Blog: www.idmworks.com/blog
*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
