Re: Storage Creep

[scott Ford]

Elardus:

Here is snips promised:



UPNEXT   DS0H  Top of loop
 LAR7,IWKAUL   R7 = ICHEINTY work area length
 STR7,IWKAUStore length of work area in
*   its header
 MVI   IWKAU+4,X'00'   }  Zero out the rest of the
 MVC   IWKAU+5(27),IWKAU+4 }   ICHEINTY work area header
*
 MVI   PGMRNU,C' ' Blank out the user name field
 MVC   PGMRNU+1(19),PGMRNU
*  Fetch the next USER profile
 ICHEINTY ENTRY=IUID,RELEASE=1.8,WKAREA=IWKAU,MF=(E,INTYU)
 LAR1,12   Code for "no subsequent entries"
 CRR1,R15  Did we get it ?
 BZGPROFS  Yes - get out of the loop
 LTR   R15,R15 Did it otherwise succeed ?
 BNZ   ERROR03 No - issue message, then skip
*   the remaining profiles, and
*   terminate the program.
*  Else R15 = 0
*
*This userid may be shorter than the previous one, in which case
*some residual characters remain.
*Blank out the trailing characters, so that we can treat
*this userid as being an 8 character, blank-filled userid.
*  R15 = 0 still
 ICR15,IUIDR15 = length of userid
 LAR7,THISUID  R7 -> start of userid
 ARR15,R7  R15 -> end+1 of userid
 MVC   0(8,R15),BLANX  Blank out residual characters
 MVC   USERID(8),THISUID   Copy the userid
 MVC   NAME(20),PGMRNU Copy the user name
 MVC   OWNER(8),AUTHU  Copy the owner's id
 UNPK  CODED(7),AUTHDATE(4)Unpack date into zoned field
 MVC   CRE8YY,CODEDStore year number
 MVC   CRE8DDD,CODED+2 Store day number
 PUT   UIDS,UIDSRECWrite the record
*
*Special treatment for unused userids :
*
 L R3,PARAMGet parameter value
 LTR   R3,R3   Is it zero ?
 BZUPNEXT  Yes - don't REVOKE anything
*
 CLC   LJDATE,THREEFF  Has it ever been used ?
 BNE   UPNEXT  Yes - get next USER profile

 ds dcs -

INTYUICHEINTY NEXTC,TYPE='USR',RELEASE=1.8,DATAMAP=NEW,@
   ACTIONS=(ACTNU1,ACTNU2,ACTNU3,ACTNU4,ACTNU5,ACTNU6),@
   MF=L
*
INTYAICHEINTY ALTER,ENTRY=IUID,TYPE='USR',RELEASE=1.8,DATAMAP=NEW, @
   ACTIONS=(ACTNA1),   @
   MF=L
*
IUID DCAL1(8)  Length of ICHEINTY user id (8)
THISUID  DCCL44' ' Name of last profile retrieved




Regards,
Scott

On Wed, May 3, 2017 at 6:44 PM, scott Ford  wrote:

> Hey E,
>
> I didn't find a WKSP, do I assume Subpool 0 doing Nextc to extract userids.
> Definitely ugh..i will post a snip...
>
> Scott
>
>
> On Wed, May 3, 2017 at 8:37 AM Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
>
>> scott Ford wrote:
>>
>> >I found the issues, one as CM mentioned was the Freemain and secondly I
>> found some old assembler RACF macros - ICHEINTY ...and there were NO
>> freemains...ugh ...I reproduced their problem.
>>
>> Oh, thats a bigh ugh! What is value of WKSP in that ICHEINTY? There are
>> weird but documented notes about subpool usage by that macro.
>>
>>
>> >This is a design I inherited so I am obviously in the stage of
>> changing... I appreciate everyone's help
>>
>> Ok, what is that ICHEINTY doing? Extracting data or updating the RACF DB
>> directly?
>>
>> Depending what that macro does, you need to consider alternative RACF
>> macros.
>>
>> Groete / Greetings
>> Elardus Engelbrecht
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> Scott Ford
> IDMWORKS
> z/OS Development
>



-- 



*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 

Re: Storage Creep

[scott Ford]

Hey E,

I didn't find a WKSP, do I assume Subpool 0 doing Nextc to extract userids.
Definitely ugh..i will post a snip...

Scott


On Wed, May 3, 2017 at 8:37 AM Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> scott Ford wrote:
>
> >I found the issues, one as CM mentioned was the Freemain and secondly I
> found some old assembler RACF macros - ICHEINTY ...and there were NO
> freemains...ugh ...I reproduced their problem.
>
> Oh, thats a bigh ugh! What is value of WKSP in that ICHEINTY? There are
> weird but documented notes about subpool usage by that macro.
>
>
> >This is a design I inherited so I am obviously in the stage of
> changing... I appreciate everyone's help
>
> Ok, what is that ICHEINTY doing? Extracting data or updating the RACF DB
> directly?
>
> Depending what that macro does, you need to consider alternative RACF
> macros.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Elardus Engelbrecht]

scott Ford wrote:

>I found the issues, one as CM mentioned was the Freemain and secondly I found 
>some old assembler RACF macros - ICHEINTY ...and there were NO freemains...ugh 
>...I reproduced their problem.

Oh, thats a bigh ugh! What is value of WKSP in that ICHEINTY? There are weird 
but documented notes about subpool usage by that macro.


>This is a design I inherited so I am obviously in the stage of changing... I 
>appreciate everyone's help

Ok, what is that ICHEINTY doing? Extracting data or updating the RACF DB 
directly?

Depending what that macro does, you need to consider alternative RACF macros.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[scott Ford]

CM and All :

I found the issues, one as CM mentioned was the Freemain and secondly I
found some old assembler
RACF macros - ICHEINTY ...and there were NO freemains...ugh ...I reproduced
their problem.

This is a design I inherited so I am obviously in the stage of changing...
I appreciate everyone's help

Thanks all,

Scott

On Wed, May 3, 2017 at 12:26 AM, CM Poncelet <
ad...@poncelet-adsl.demon.co.uk> wrote:

> 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=()'
> >   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
>



-- 



*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

Re: Storage Creep

[CM Poncelet]

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=()'
>   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

Re: Storage Creep

[Doug Henry]

On Tue, 2 May 2017 09:41:05 -0400, scott Ford <idfli...@gmail.com> 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:
>

Hi  Scott,
Check out this IBM canceled apar.

APAR Identifier .. OA51754  Last Changed  17/03/02
  ABEND878-10 USING IRRXUTIL; RMSG BLOCKS LEFT

Doug Henry
USBank

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Steve Thompson]

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=()'
  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

Re: Storage Creep

[Charles Mills]

FREEMAIN will succeed even if the size is too small -- keep that in mind.

Also, I'm too busy to look it up, but there is something "special" about 
authorized (?, Supervisor state? Key 0?) programs and subpool zero. Is that a 
factor here?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Tuesday, May 2, 2017 6:41 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Storage Creep

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:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Binyamin Dissen]

Run the VSMDATA against the dump and look for repeated areas with specific
sizes. Then look at the data.

On Tue, 2 May 2017 09:41:05 -0400 scott Ford <idfli...@gmail.com> 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=()'
:>  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

--
Binyamin Dissen <bdis...@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Tom Marchant]

On Tue, 2 May 2017 09:41:05 -0400, scott Ford wrote:

>I have a STC written in Cobol V4.1 calling Assembler routines to perform
>various RACF functions.

...

>  MODESET KEY=ZERO,MODE=SUP
>  issue our call
>  MODESET KEY=NZERO,MODE=PROB
>  build output record and pass back to caller.

APF authorized Cobol and LE.



-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Mark Jacobs - Listserv]

Would a Getmain/Freemain/Storage Trace on the STC help find the problem?

Mark Jacobs

scott Ford <mailto:idfli...@gmail.com>
May 2, 2017 at 9:41 AM
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=()'
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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Storage Creep

[Elardus Engelbrecht]

scott Ford wrote:

>I have a STC written in Cobol V4.1 calling Assembler routines to perform 
>various RACF functions.

How is your COBOL program(s) compiled? Could you post the AMODE, RMODE and 
other settings?


>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:

> FREEMAIN  RU,A=(R4),SP=(R3),LV=(R2) FREE OLD BLOCK

Please post your GETMAIN too.

Also please post the macro you're using to call IRRSEQ00.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Storage Creep

[scott Ford]

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=()'
  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

Re: Slow storage creep in SYSTEM.SYSSTC

[Martin Packer]

In SYSTEM Service Class (for several customers) I think I'm seeing Master 
Scheduler being said to acquire more storage service over time. Not sure 
if this is what the OP meant by SYSSTC or not. (Probably not).

In my case I suspect this is an anchor point for something Common or 
Shared above the Bar.

Instrumentation I'm using is SMF 30 Interval (2,3) records.

And I agree you can control what goes into SYSSTC and can define Report 
Classes to narrow the doubt if you don't have SMF 30(2,3) to work with. 
Actually for NON-SWAPPABLE address spaces a Report Class would be much 
more accurate for REAL storage usage.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Shane Ginnane ibm-m...@tpg.com.au
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/05/2015 04:30
Subject:Re: Slow storage creep in SYSTEM.SYSSTC
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:

... I neither have nor really can control what falls into SYSSTC. It's 
all z/OS.

You can, and probably should at least look at some of your heavy hitters.
 
Just tossing it out here for thought on identifying the guilty software?

Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run 
the VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what 
you'll get. You may be able to see from a quick eyeball where it's going.
You can run a getmain/freemain trace, but you really don't want to go 
there. Running GTF for weeks, then trying to process the output just ain't 
funny.

All else fails, flick me a return business class air ticket, and I'll come 
have a look. Washington can't be too bad this time of year   ;-)

Shane ...
(all the above presumes you have the DIAGxx member set up already)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Greg Shirey]

Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC 
service class.  We put the systems programmers' TSO sessions there, for 
instance. 

Greg Shirey
Ben E. Keith Company  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: Tuesday, May 26, 2015 6:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC

We just had a zPCR study. There weren't any real surprises, but the Workload 
CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC 
workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor 
really can control what falls into SYSSTC. It's all z/OS.

I recently stopped the practice of monthly IPLs and am a little concerned. The 
growth rate is slow and I have ample head room.

Just tossing it out here for thought on identifying the guilty software?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Vernooij, CP (ITOPT1) - KLM]

Partly true, we have the same setup, but only for the 'standby userid'. It is 
very tempting for sysprogs to give themselves absolute performance, just 
because they can, not because they need it.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Greg Shirey
Sent: 27 May, 2015 15:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC

Sure.  The sysprogs wanted to try and be sure they could get into the system in 
times of stress.  We run a single LPAR on a machine with two processors, so 
CICS (our loved one) in a loop can monopolize one and leave the other 
struggling to service the remaining workloads.   We didn't even bother with 
experimenting with a TSOHOT service class - we felt like we had enough service 
classes defined already.

Greg 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, May 27, 2015 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC

Greg Shirey wrote:

We put the systems programmers' TSO sessions there, for instance. 

TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm?

Just curious, if you don't mind please.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Greg Shirey]

Sure.  The sysprogs wanted to try and be sure they could get into the system in 
times of stress.  We run a single LPAR on a machine with two processors, so 
CICS (our loved one) in a loop can monopolize one and leave the other 
struggling to service the remaining workloads.   We didn't even bother with 
experimenting with a TSOHOT service class - we felt like we had enough service 
classes defined already.

Greg 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, May 27, 2015 8:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC

Greg Shirey wrote:

We put the systems programmers' TSO sessions there, for instance. 

TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm?

Just curious, if you don't mind please.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Vernooij, CP (ITOPT1) - KLM]

There are some sidepaths take from this thread.

Yes, you can add workload to SYSSTC, and you should have done so in the past 
according to recommendations. 

But this is not the point. Some task in SYSSTC has the creep. You can display 
the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC in the 
display. Then you know which tasks to monitor. In CMF I can start a VSM monitor 
for selected tasks, I assume RMF can do the same. Run the VSM report weekly and 
you must be able to find the creep(er).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: 27 May, 2015 1:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC

We just had a zPCR study. There weren't any real surprises, but the Workload 
CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC 
workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor 
really can control what falls into SYSSTC. It's all z/OS.

I recently stopped the practice of monthly IPLs and am a little concerned. The 
growth rate is slow and I have ample head room.

Just tossing it out here for thought on identifying the guilty software?

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Martin Packer]

I wouldn't use a command but rather proper regular timestamped information 
- to get the behaviour. That would be 72-3 for suitably-coded report 
classes.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/05/2015 14:15
Subject:Re: Slow storage creep in SYSTEM.SYSSTC
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



There are some sidepaths take from this thread.

Yes, you can add workload to SYSSTC, and you should have done so in the 
past according to recommendations. 

But this is not the point. Some task in SYSSTC has the creep. You can 
display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC 
in the display. Then you know which tasks to monitor. In CMF I can start a 
VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM 
report weekly and you must be able to find the creep(er).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Gibney, David Allen,Jr
Sent: 27 May, 2015 1:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC

We just had a zPCR study. There weren't any real surprises, but the 
Workload CS Samples for my production Lpar shows a very slow creep in 
the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I 
neither have nor really can control what falls into SYSSTC. It's all z/OS.

I recently stopped the practice of monthly IPLs and am a little concerned. 
The growth rate is slow and I have ample head room.

Just tossing it out here for thought on identifying the guilty software?

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 
confidential and privileged material intended for the addressee only. If 
you are not the addressee, you are notified that no part of the e-mail or 
any attachment may be disclosed, copied or distributed, and that any other 
action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered 
number 33014286

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Shane Ginnane]

On Wed, 27 May 2015 13:51:23 +, Vernooij, CP wrote:

It is very tempting for sysprogs to give themselves absolute performance, just 
because they can, not because they need it. 

True 'nuff.
As I don't live in any site, I try to placate the troops. When I need to get in 
and fix things, I get my userid reset.
If the ops can't get in and reset me, there are bigger problems. Seen that too 
of course 

Shane ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Vernooij, CP (ITOPT1) - KLM]

Still you are looking for the one task that has the creep and therefor you must 
go down to the details of each individual task. By displaying which tasks run 
in SYSSTC, you can limit the number of tasks to monitor.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: 27 May, 2015 15:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Slow storage creep in SYSTEM.SYSSTC

I wouldn't use a command but rather proper regular timestamped information 
- to get the behaviour. That would be 72-3 for suitably-coded report 
classes.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   27/05/2015 14:15
Subject:Re: Slow storage creep in SYSTEM.SYSSTC
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



There are some sidepaths take from this thread.

Yes, you can add workload to SYSSTC, and you should have done so in the 
past according to recommendations. 

But this is not the point. Some task in SYSSTC has the creep. You can 
display the tasks in SYSSTC with the command D A,ALL. Look for SCL=SYSSTC 
in the display. Then you know which tasks to monitor. In CMF I can start a 
VSM monitor for selected tasks, I assume RMF can do the same. Run the VSM 
report weekly and you must be able to find the creep(er).

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Gibney, David Allen,Jr
Sent: 27 May, 2015 1:26
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Slow storage creep in SYSTEM.SYSSTC

We just had a zPCR study. There weren't any real surprises, but the 
Workload CS Samples for my production Lpar shows a very slow creep in 
the SYSTEM.SYSSTC workload. I am z/OS 1.13 at RSU1408. As far as I know, I 
neither have nor really can control what falls into SYSSTC. It's all z/OS.

I recently stopped the practice of monthly IPLs and am a little concerned. 
The growth rate is slow and I have ample head room.

Just tossing it out here for thought on identifying the guilty software?

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain 
confidential and privileged material intended for the addressee only. If 
you are not the addressee, you are notified that no part of the e-mail or 
any attachment may be disclosed, copied or distributed, and that any other 
action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify 
the sender immediately by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission 
of this e-mail or any attachments, nor responsible for any delay in 
receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered 
number 33014286

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke

Re: Slow storage creep in SYSTEM.SYSSTC

[Elardus Engelbrecht]

Greg Shirey wrote:

Sure.  The sysprogs wanted to try and be sure they could get into the system 
in times of stress.  We run a single LPAR on a machine with two processors, so 
CICS (our loved one) in a loop can monopolize one and leave the other 
struggling to service the remaining workloads.   We didn't even bother with 
experimenting with a TSOHOT service class - we felt like we had enough service 
classes defined already.

Thanks. Those loved CICS can get your system with two CPUs for dinner leaving 
you only with little crumbs to sit with... 

Your setup seemed realistic to me, thanks for telling. Much appreciated.

Sorry, that I can't really contribute to this creeepy thread... ;-)

I'll creep out of this thread for now...

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Elardus Engelbrecht]

Greg Shirey wrote:

Just a note - perhaps you haven't at your shop, but you can add to the SYSSTC 
service class. 

Good suggestion.

We put the systems programmers' TSO sessions there, for instance. 

TSO sessions not at TSOHOT, TSOHI, TSOMD, TSOLOW, etc.? Hmmm?

Just curious, if you don't mind please.

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Slow storage creep in SYSTEM.SYSSTC

[Gibney, David Allen,Jr]

Thanks for all the suggestions. I'll look for time to try some of them :)

Wish I could just send a ticket Shane, is is fairly nice out there right now.

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
 On Behalf Of Shane Ginnane
 Sent: Tuesday, May 26, 2015 8:30 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: Slow storage creep in SYSTEM.SYSSTC
 
 On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:
 
 ... I neither have nor really can control what falls into SYSSTC. It's all 
 z/OS.
 
 You can, and probably should at least look at some of your heavy hitters.
 
 Just tossing it out here for thought on identifying the guilty software?
 
 Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the
 VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of
 what you'll get. You may be able to see from a quick eyeball where it's going.
 You can run a getmain/freemain trace, but you really don't want to go there.
 Running GTF for weeks, then trying to process the output just ain't funny.
 
 All else fails, flick me a return business class air ticket, and I'll come 
 have a
 look. Washington can't be too bad this time of year   ;-)
 
 Shane ...
 (all the above presumes you have the DIAGxx member set up already)
 
 --
 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

Re: Slow storage creep in SYSTEM.SYSSTC

[Shane Ginnane]

On Tue, 26 May 2015 23:25:42 +, Gibney, David wrote:

... I neither have nor really can control what falls into SYSSTC. It's all 
z/OS.

You can, and probably should at least look at some of your heavy hitters.
 
Just tossing it out here for thought on identifying the guilty software?

Grab a couple of (system) dumps a couple of weeks apart. Under IPCS run the 
VSMDATA with OWNCOMM SUMMARY. The Diag Reference has examples of what you'll 
get. You may be able to see from a quick eyeball where it's going.
You can run a getmain/freemain trace, but you really don't want to go there. 
Running GTF for weeks, then trying to process the output just ain't funny.

All else fails, flick me a return business class air ticket, and I'll come have 
a look. Washington can't be too bad this time of year   ;-)

Shane ...
(all the above presumes you have the DIAGxx member set up already)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Slow storage creep in SYSTEM.SYSSTC

[Gibney, David Allen,Jr]

We just had a zPCR study. There weren't any real surprises, but the Workload 
CS Samples for my production Lpar shows a very slow creep in the SYSTEM.SYSSTC 
workload. I am z/OS 1.13 at RSU1408. As far as I know, I neither have nor 
really can control what falls into SYSSTC. It's all z/OS.

I recently stopped the practice of monthly IPLs and am a little concerned. The 
growth rate is slow and I have ample head room.

Just tossing it out here for thought on identifying the guilty software?

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN