FWIW The "FREEMAIN  RU,A=(R4), etc." will 'free' the storage at A=(R4),
but will not free the page containing A=(R4) until *all* the GETMAINed
storage in it has been FREEMAINed. A storage creep suggests that pages
are being GETMAINed, but then not all storage in them being FREEMAINed.


On 02/05/2017 14:41, 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

Reply via email to