Re: Corrupt PDSE - IGW699I PDSE Directory Validation Unsuccessful

[Thomas Berg]

Thanks!

Regarding 2:  I restored the dataset to another name and then did 2 renames.  
IEBPDSE did not report any problems. 



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)

Interactive is 'manual.' Batch is 'automatic.'


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of
> Hank Oerlemans
> Sent: Tuesday, May 26, 2015 8:14 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Corrupt PDSE - IGW699I PDSE Directory Validation Unsuccessful
> 
> I've had to deal with a couple of PDSE issues with z/OS 2.1 and Fault
> Analyzer.
> 
> 1. Ensure all systems are up to date with PDSE maintenance
> 2. It's possible that IEBPDSE (the z/OS 2.1 version) against your restored
> PDSE will still report problems. Reallocate your PDSE and copy (IEBCOPY)
> the backup data into it. z/OS 2.1 is more robust about reporting some
> internal PDSE issues than previous z/OS levels. If you don't reallocate
> you are simply continuing the internal structural problems.
> 3. Send your diagnostic data and dumps into IBM to be sure you don't have
> something new .
> 
> Regards Hank Oerlemans,
> IBM Fault Analyzer
> 
> 
> 
> 
> From:   Thomas Berg 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   26/05/2015 11:48
> Subject:Re: Corrupt PDSE - IGW699I PDSE Directory Validation
> Unsuccessful
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> BTW, we are on zOS 2.1 in the DEV system and zOS 1.13 in the prod system.
> 
> 
> 
> Best Regards,
> Thomas Berg
> ___
> Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)
> 
> Interactive is 'manual.' Batch is 'automatic.'
> 
> 
> 
> 
> > -Original Message-
> > From: Thomas Berg
> > Sent: Tuesday, May 26, 2015 3:46 AM
> > To: 'IBM Mainframe Discussion List'
> > Subject: RE: Corrupt PDSE - IGW699I PDSE Directory Validation
> Unsuccessful
> >
> > Did run IEBPDSE, but no new info compared to the abend result I posted
> below:
> >
> > IGW699I PDSE Directory Validation Unsuccessful
> > DESC:PDSE structure is corrupted
> > ERROR NUM:103
> > DSN:SYS6.IDI.PROD5.HIST.FEL
> > VOLSER:GEM040
> > ADPages:10169 IXRecords:405168
> > ADPagesInCore:3 ADPagesRead:10166
> > ADTreeLevels:3
> > NDPages:21 IXRecords:2460
> > NDPagesInCore:1 NDPagesRead:20
> > NDTreeLevels:2
> > AD ND Tree Nodes:2430
> > Version:1
> > Orphan Pages:4682
> > RC:4 RS:01188012
> > IGW702I PDSE Directory Validation Unsuccessful
> > DESC: Structure is corrupted
> > LTK:D561C14040404040404040404040404040404040
> > ERROR NUM:1
> > DSN:SYS6.IDI.PROD5.HIST.FEL
> > VOLSER:GEM040
> > RC:4 RS:01188012 R14:0876C2A4
> > RPN:N/A
> > VPTVFN:N/A
> >
> >
> >
> >
> > Best Regards,
> > Thomas Berg
> > ___
> > Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)
> >
> > Interactive is 'manual.' Batch is 'automatic.'
> >
> >
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of
> > > Mark Jacobs - Listserv
> > > Sent: Tuesday, May 26, 2015 3:27 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: Corrupt PDSE - IGW699I PDSE Directory Validation
> Unsuccessful
> > >
> > > If you take a physical dump of the dataset and send it into IBM for
> > > analysis they might be able to get to the root cause. Assuming you're
> on
> > > zOS 1.13 or higher did you execute IEBPDSE against the restored
> dataset
> > > to verify its structure?
> > >
> > > Mark Jacobs
> > >
> > > > Thomas Berg 
> > > > May 25, 2015 at 9:23 PM
> > > > AFAIK it should have a very low probability. This due to that those
> > > > that can access from outside of the Sysplex (special sysprogs) have
> > > > neither reason or interest of doing that. And this is 3.00 AM here.
> > > > (At least the operator I spoke to had no knowledge of anyone else
> that
> > > > me working at this time.)
> > > >
> > > > I have restored a backup from yesterday now so the immediate problem
> > > > is solved. (And saved the corrupted PDSE in case anyone except me is
> > > > interested.)
> > > >
> > > >
> > > >
> > > > Best Regards,
> > > > Thomas Berg
> > > > ___
> > > > Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
> > > >
> > > > Interactive is 'manual.' Batch is 'automatic.'
> > > >
> > > >
> > > >
> > > >
> --
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> IBM-MAIN
> > > > Mark Jacobs - Listserv 
> > > > May 25, 2015 at 9:09 PM
> > > > Could it have been shared(R/W) outside of a sysplex 

Re: CryptoExpress4S - how many domains?

[R.S.]

Good point. SE (or HMC) should show list of domains, BUT
1. I can't access the machine now.
2. I can imagine there is microcode update which extends the number of 
possible domains.



Regards

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-05-26 o 06:14, Rob Schramm pisze:

Its always humorous when the doc conflicts.  Wouldn't it just show you on
the HMC?

Rob Schramm

On Mon, May 25, 2015, 10:09 PM Greg Boyd 
wrote:


Each CEX4S can support up to 16 domains.  There are 16 sets of registers
for storing master keys, so you can have 16 LPARs or virtual guests, each
assigned their own set of registers.   That is true for all the previous
generations of crypto cards, but with the CEX5S that limit goes up ...
probably to 85.  (There is conflicting doc but it is more than 16 and the
consensus seems to be 85.)
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com

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





--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: CryptoExpress4S - how many domains?

[Rob Schramm]

16 was the number for a long time. Also, why 85? 5 x 17?  Where did the
extra 1 come from?  I would have expected ... 5 * 16 = 80

On Tue, May 26, 2015, 6:14 AM R.S.  wrote:

> Good point. SE (or HMC) should show list of domains, BUT
> 1. I can't access the machine now.
> 2. I can imagine there is microcode update which extends the number of
> possible domains.
>
>
> Regards
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2015-05-26 o 06:14, Rob Schramm pisze:
> > Its always humorous when the doc conflicts.  Wouldn't it just show you on
> > the HMC?
> >
> > Rob Schramm
> >
> > On Mon, May 25, 2015, 10:09 PM Greg Boyd 
> > wrote:
> >
> >> Each CEX4S can support up to 16 domains.  There are 16 sets of registers
> >> for storing master keys, so you can have 16 LPARs or virtual guests,
> each
> >> assigned their own set of registers.   That is true for all the previous
> >> generations of crypto cards, but with the CEX5S that limit goes up ...
> >> probably to 85.  (There is conflicting doc but it is more than 16 and
> the
> >> consensus seems to be 85.)
> >> Greg Boyd
> >> Mainframe Crypto
> >> www.mainframecrypto.com
> >>
> >> --
> >> 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
> >
>
>
>
> --
> Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo,
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl
> Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego
> Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP:
> 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku
> S.A. (w całości wpłacony) wynosi 168.840.228 złotych.
>
>
> --
> 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: CryptoExpress4S - how many domains?

[Todd Arnold]

> 16 was the number for a long time. Also, why 85? 5 x 17?  Where did the
> extra 1 come from?  I would have expected ... 5 * 16 = 80

The number of domains architecturally supported in the CEX5 card itself is 
actually 256, which is of course a nice power of 2.  However, that is more than 
that z System machine needs.  The number supported by the machine was 
determined by deciding what a reasonable number of domains would be, relative 
to the number of host LPARs and the processing speed of the machine.

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

Re: z/Linux PSW 0BADCCCC

[Mark Post]

>>> On 5/26/2015 at 02:11 AM, *** ** ***  wrote: 
> It would seem that ' The Linux kernel requires more recent processor 
> hardware' is the culprit.

Indeed.  RHEL 7 will only run on a z196/114 or later machine.


Mark Post

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

Re: z/Linux PSW 0BADCCCC

[Lizette Koehler]

There is a Linux List that you may wish to join for these types of questions.  
If you have not done so, you can join here

Linux   http://www2.marist.edu/htbin/wlvindex?LINUX-VM
http://www.marist.edu/htbin/wlvindex?LINUX-390

Here are some more links you might also find interesting for Linux
http://www.cbttape.org/linux390.htm



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mainframe Mainframe
> Sent: Monday, May 25, 2015 11:09 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/Linux PSW 0BAD
> 
> Hello Group,
>   When I am booting the RHEL7 z/linux guest , getting below 
> PSW.
> 
> 
> 0: Please choose (default will boot in 5 seconds):
> 00: FCP 681D ATTACHED TO LNXBT1 681D
> 00: Booting default (linux)...
> 00: The Linux kernel requires more recent processor hardware
> 00: HCPGIR450W CP entered; disabled wait PSW 0002 8000 
> 0BAD
> 
> and not able to boot this newly installed z/Linux system . Please suggest.
> 
> --
> 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: CryptoExpress4S - how many domains?

[R.S.]

W dniu 2015-05-26 o 13:24, Rob Schramm pisze:

16 was the number for a long time. Also, why 85? 5 x 17?  Where did the
extra 1 come from?  I would have expected ... 5 * 16 = 80


The 85 is quite obvious: it is current limit of LPARs in z13. So, single 
CryptoExpress5S card can serve *all* LPARs in the machine.


Of course the question is why z13 has 85 LPARs, but it's another 
question which I cannot answer.


--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Corrupt PDSE - IGW699I PDSE Directory Validation Unsuccessful

[Nims,Alva John (Al)]

Take a look at this APAR:
http://www-01.ibm.com/support/docview.wss?uid=isg1OA44607

In the APAR it has:
" Sparse datasets from release 1.13 or lower and subsequent
updated in R2.1 may cause an index corruption. R2.1 collapse
sparse indexes and it did not delete an empty page in a
particular delete path."

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Monday, May 25, 2015 10:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Corrupt PDSE - IGW699I PDSE Directory Validation Unsuccessful

Yea, it looks damaged to me too. I'd still recommend that you validate the 
integrity of the restored dataset, just to be safe.

Mark Jacobs

> Thomas Berg  May 25, 2015 at 10:00 PM 
> Tried on another prodsystem. Got this:
>
> IGW699I PDSE Directory Validation Unsuccessful IEA995I SYMPTOM DUMP 
> OUTPUT SYSTEM COMPLETION CODE=0F4 REASON CODE=0024
> TIME=03.59.10 SEQ=44968 CPU= ASID=01F8 PSW AT TIME OF ERROR 
> 075C1000 88FDA690 ILC 2 INTC 0D NO ACTIVE MODULE FOUND - PRIMARY NOT 
> EQUAL TO HOME NAME=UNKNOWN DATA AT PSW 08FDA68A - 58F05048 0A0DB219 
> A788 AR/GR 0: 008FF6C8/01188012 1: /040F4000
> 2: 0001/00FDB9A0 3: /7EC6E268
> 4: 0002/7703 5: /7EC73400
> 6: /7EC6E060 7: /00FE0548
> 8: /00FE05B8 9: 0001/7EC6E268
> A: /7EC73868 B: /
> C: /08FDA012 D: /7EC73778
> E: /88FDA682 F: /0024 END OF SYMPTOM DUMP 
> DESC:PDSE structure is corrupted ERROR NUM:103 
> DSN:SYS6.IDI.PROD5.HIST.FEL
> VOLSER:GEM040
> ADPages:10169 IXRecords:405168
> ADPagesInCore:159 ADPagesRead:10010
> ADTreeLevels:3
> NDPages:21 IXRecords:2460
> NDPagesInCore:7 NDPagesRead:14
> NDTreeLevels:2
> AD ND Tree Nodes:2430
> Version:1
> Orphan Pages:4682
> RC:4 RS:01188012
> IGW702I PDSE Directory Validation Unsuccessful DESC: Structure is 
> corrupted
> LTK:D561C14040404040404040404040404040404040
> ERROR NUM:1
> DSN:SYS6.IDI.PROD5.HIST.FEL
> VOLSER:GEM040
> RC:4 RS:01188012 R14:08E8D2A4
> RPN:N/A
> VPTVFN:N/A
> IEC036I 002-A4,IGC0005E,S000TBE,KAT30,ISP03594,786B,GEM040,
> SYS6.IDI.PROD5.HIST.FEL
> IRX0250E System abend code 002, reason code 0164.
> IRX0255E Abend in host command SELECT or address environment routine 
> ISPEXEC.
> ***
>
>
>
> Best Regards,
> Thomas Berg
> ___
> Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
>
> Interactive is 'manual.' Batch is 'automatic.'
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Mark 
> Jacobs - Listserv  May 25, 2015 at 
> 9:50 PM Three more questions.
>
> 1. Do you have all the required toleration maintenance applied on your
>1.13 system?
> 2. Does the hang occur on all systems in the sysplex or just one?
> 1. If only on one, can you recycle the SMSPDSE1 address space and
>see if that fixes the problem?
>
> Mark Jacobs
>
>
> Thomas Berg  May 25, 2015 at 9:47 PM 
> BTW, we are on zOS 2.1 in the DEV system and zOS 1.13 in the prod system.
>
>
>
> Best Regards,
> Thomas Berg
> ___
> Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
>
> Interactive is 'manual.' Batch is 'automatic.'
>
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Mark 
> Jacobs - Listserv  May 25, 2015 at 
> 9:27 PM If you take a physical dump of the dataset and send it into 
> IBM for analysis they might be able to get to the root cause. Assuming 
> you're on zOS 1.13 or higher did you execute IEBPDSE against the 
> restored dataset to verify its structure?
>
> Mark Jacobs
>
>
> Thomas Berg  May 25, 2015 at 9:23 PM 
> AFAIK it should have a very low probability. This due to that those 
> that can access from outside of the Sysplex (special sysprogs) have 
> neither reason or interest of doing that. And this is 3.00 AM here.
> (At least the operator I spoke to had no knowledge of anyone else that 
> me working at this time.)
>
> I have restored a backup from yesterday now so the immediate problem 
> is solved. (And saved the corrupted PDSE in case anyone except me is
> interested.)
>
>
>
> Best Regards,
> Thomas Berg
> ___
> Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ)
>
> Interactive

How do I display this storage in IPCS (zos/2.1)?

[Binyamin Dissen]

>From LISTDUMP

  COMPDATA(IARHVSHR) 
 0200_0010.:0200_00100FFF.
   X'1000' bytes described in COMPDATA(IARHVSHR)  
  

--
Binyamin Dissen 
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: How do I display this storage in IPCS (zos/2.1)?

[Jim Mulder]

> From LISTDUMP
> 
>   COMPDATA(IARHVSHR) 
>  0200_0010.:0200_00100FFF. 
>X'1000' bytes described in COMPDATA(IARHVSHR) 

LIST 210. 

If it is a stand-alone dump, you may need to specify an ASID which is 
connected
to the shared memory object of interest.  If it is an SVC dump, I think 
the ASID
is not used.

LIST 210. COMPDATA(IARHVSHR)  should also work. 
 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY 

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

Tailoring SVCDUMP (SDUMPX) on zos/2.1

[Jim Mulder]

>I am trying to issue a tailored SVC dump and am finding that there are 
many
>absolute storage records filling the dump - many more since zos/1.10

>I specify SDATA=(NODEFS,NOALLPSA,NOSQA) - what more do I need to specify?

  How did you determine that there are many absolute storage records? Did 
you
count the number of records whose dump record prefix starts with 'DR2 A .' 
? 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

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

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