Re: BLS18160D Response
For example, VERBX VSMDATA traverses data structures which are not serialized while they are being captured by IEATDUMP/SYSMDUMP/SDUMP. As a result, sometimes the VSMDATA processing encounters problems due to inconsistent data structures in the dump. The potential for inconsistencies can be exacerbated when some register at time of error or SUMLST range causes some of the relevant VSM stuff data to be captured early during disabled or suspend summary dump, and the rest captured later. So when you see VSMDATA spewing error messages, sometimes you say, "Let me try dropping the dump and reinitializing it, replying N to BLS18160D, and then see if VSMDATA works better for this dump". Replying N to BLS18160D is something I do only rarely, but there are times when, in order to understand what is going on in a dump, you need to know a considerable amount about how dumping works. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/27/2021 09:03:17 PM: > From: "Ed Jaffe" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 03/01/2021 05:04 PM > Subject: BLS18160D Response > Sent by: "IBM Mainframe Discussion List" > > Regarding: > > "BLS18160D May summary dump data be used by dump access? Enter Y to > use, N to bypass." > > Under what conditions would it ever be appropriate to reply N? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLS18160D Response
That doc is about 20 years out of date. Prior to z/OS 1.2, summary
dump could capture multiple SUMDUMP ranges in a single
self-describing 4K dump record, and the metadata for the ranges
did not include the storage key. When 64-bit virtual storage was
implemented in z/OS 1.2, we decided not to to extend
this methodology to 64-bit addresses, and instead, round
SUMPDUMP ranges down and up to 4K page boundaries.
Having done that, all of the storage in a SUMDUMP record
is now the same key, so we capture its key into the record
header, like we do for any other storage being dumped.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
"IBM Mainframe Discussion List" wrote on
02/28/2021 11:08:55 AM:
> From: "Ed Jaffe"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 03/01/2021 04:09 PM
> Subject: Re: BLS18160D Response
> Sent by: "IBM Mainframe Discussion List"
>
> On 2/27/2021 7:48 PM, Mark Jacobs wrote:
> > >From the FM;
> >
> > The summary dump data contains data captured closest to the time
> of the failure. If you reply Y to use this data, IPCS will not be
> able to display storage keys using the DISPLAY(MACHINE) parameter.
>
> Yeah, but...
>
> I don't experience issues displaying keys using DISPLAY(MACHINE) when
> responding 'Y' to BLS18160D.
>
> I tried it just now. I initialized a dump still lying around from
> yesterday (SLIP to capture an SDC2 abend in an SRB) and responded 'Y' to
> the BLS18160D prompt:
>
> IKJ56650I TIME-07:42:42 AM. CPU-00:00:03 SERVICE-22127
> SESSION-00:00:47 FEBRUARY 28,2021
> BLS18122I Initialization in progress for
> DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
> BLS18124I TITLE=SLIP DUMP ID=EEJ6
> BLS18223I Dump written by z/OS 02.04.00-0 SLIP - level same as IPCS
level
> BLS18558I This redactable dump has not been post-processed to protect
> sensitive data
> BLS18222I z/Architecture mode system
> BLS18160D May summary dump data be used by dump access? Enter Y to
> use, N to bypass.
> y
> BLS18255I Dump InitElapsed Time CPU Time
> Input I/O 00:00:01.205379 00:00:01.041953
> DDIR00:00:00.842453 00:00:00.605543
> BLS18123I 161,077 blocks, 670,080,320 bytes, in
> DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
> IKJ56650I TIME-07:44:17 AM. CPU-00:00:07 SERVICE-42085
> SESSION-00:02:21 FEBRUARY 28,2021
> BLS18224I Dump of z/OS 02.04.00-0 - level same as IPCS level
> ***
>
> STATUS shows PSW and registers for the DC2 abend:
>
> CPU STATUS:
> PSW=47045000 8000 019A7318
> (Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
> Enabled for PER I/O EXT MCH
> ASID(X'0072') 019A7318. IEANUC01.IAXV6+24D0 IN READ ONLY NUCLEUS
>ASCB114 at FBD400, JOB(EDJX2), for the home ASID
>ASXB114 at AFD000 for the home ASID. No block is dispatched
>HOME ASID: 0072 PRIMARY ASID: 0072 SECONDARY ASID: 0072
>
>General purpose register values
> Left halves of all registers contain zeros
> 0-3 8400 84DC2000 0001
> 4-7 029B9000 00FBD400 01DDDF00
> 8-11 042FCC30 08004000
> 12-15 019A8550 042FE178 042FE000 66004020
>
> SUMDUMP captures storage on both sides of the PSW and every register. I
> have 'IP SETDEF DISPLAY(MACHINE)' in effect. Listing the PSW via 'IP L
> 019A7318' returns KEY(08):
>
> LIST 019A7318. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(019A7318.) KEY(00)
> 019A7318. B24D001C E31D 00045811 00889110 |.(..Thj.|
> 019A7328. 1008A784 0009C019 04C0D000 C0F9FE00 |..xd..{..{}.{9..|
>
> 'IP L 5R!' returns KEY(00):
>
> LIST 029B9000. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(029B9000.) KEY(08)
> 029B9000. C9C1E7C3 D7E3C2D3 0012 |IAXCPTBL|
> 029B9010. 0012 0040 042FC000 |... ..{.|
>
> 'IP L 7R!' returns KEY(00):
>
> LIST 01DDDF00. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(01DDDF00.) KEY(00)
> 01DDDF00. D9C3C540 002E65A3 0FFE 0EB6 |RCE ...t|
> 01DDDF10. 050B 00350202 142E 28C0 |...{|
>
> 'IP L 9R!' returns KEY(00):
>
> LIST 042FCC30. ASID(X'0072') LENGTH(X'2000') AREA
> ASID(X'0072') ADDRESS(042FCC30.) KEY(00)
> 042FCC30. 009A ||
> 042FCC40. 042FC000 042FC004 |..{...{.|
>
> Same with all of the other registers that look like addresses. Not one
> does not show the KEY information. I get similar results when processing
> dumps in TCB mode. Pretty much everything pointed to by the RT
Re: BLS18160D Response
RSMDATA shows you what z/OS intends for the key to be. DISPLAY shows you what the key actually is, via IVSK for IEATDUMP/SYSMDUMP/SDUMP and ISKE for SADMP. Other than DAT table overlays or some supervisor state doofus thinking it is ok for something other than RSM to use the SSKE instruction, those things are in agreement. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 03/01/2021 04:26:52 AM: > From: "Barbara Nitz" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 03/01/2021 04:12 PM > Subject: Re: BLS18160D Response > Sent by: "IBM Mainframe Discussion List" > > On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe > wrote: > > >I don't experience issues displaying keys using DISPLAY(MACHINE) when > >responding 'Y' to BLS18160D. > > Did you compare the keys with what rsmdata knows about the key of > the page? I learned to use 'yes' to the BLS message and only to use > the key for the page that rsmdata shows. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLS18160D Response
An SDC2 abend on a JES2 warm start? Sounds very familiar. I spent quite a bit
of time with support over that. Here is what was finally determined:
OA58190 has changed the JES2 checkpoint structure, which is independent of
user activity. Such internal changes are necessary in order to support new
functionality. Therefore all JES2 members accessing such a checkpoint
thereafter need the mentioned compatibility APAR OA59665/UJ03635.
Thus. If these APARs/PTFs are applied, there is no falling back. And a
fallback attempt causes the SDC2 abend.
Matthew
On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe
wrote:
>On 2/27/2021 7:48 PM, Mark Jacobs wrote:
>> >From the FM;
>>
>> The summary dump data contains data captured closest to the time of the
>> failure. If you reply Y to use this data, IPCS will not be able to display
>> storage keys using the DISPLAY(MACHINE) parameter.
>
>Yeah, but...
>
>I don't experience issues displaying keys using DISPLAY(MACHINE) when
>responding 'Y' to BLS18160D.
>
>I tried it just now. I initialized a dump still lying around from
>yesterday (SLIP to capture an SDC2 abend in an SRB) and responded 'Y' to
>the BLS18160D prompt:
>
> IKJ56650I TIME-07:42:42 AM. CPU-00:00:03 SERVICE-22127
>SESSION-00:00:47 FEBRUARY 28,2021
> BLS18122I Initialization in progress for
>DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
> BLS18124I TITLE=SLIP DUMP ID=EEJ6
> BLS18223I Dump written by z/OS 02.04.00-0 SLIP - level same as IPCS level
> BLS18558I This redactable dump has not been post-processed to protect
>sensitive data
> BLS18222I z/Architecture mode system
> BLS18160D May summary dump data be used by dump access? Enter Y to
>use, N to bypass.
>y
> BLS18255I Dump Init Elapsed Time CPU Time
> Input I/O 00:00:01.205379 00:00:01.041953
> DDIR 00:00:00.842453 00:00:00.605543
> BLS18123I 161,077 blocks, 670,080,320 bytes, in
>DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
> IKJ56650I TIME-07:44:17 AM. CPU-00:00:07 SERVICE-42085
>SESSION-00:02:21 FEBRUARY 28,2021
> BLS18224I Dump of z/OS 02.04.00-0 - level same as IPCS level
> ***
>
>STATUS shows PSW and registers for the DC2 abend:
>
>CPU STATUS:
>PSW=47045000 8000 019A7318
> (Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
> Enabled for PER I/O EXT MCH
> ASID(X'0072') 019A7318. IEANUC01.IAXV6+24D0 IN READ ONLY NUCLEUS
> ASCB114 at FBD400, JOB(EDJX2), for the home ASID
> ASXB114 at AFD000 for the home ASID. No block is dispatched
> HOME ASID: 0072 PRIMARY ASID: 0072 SECONDARY ASID: 0072
>
> General purpose register values
> Left halves of all registers contain zeros
> 0-3 8400 84DC2000 0001
> 4-7 029B9000 00FBD400 01DDDF00
> 8-11 042FCC30 08004000
> 12-15 019A8550 042FE178 042FE000 66004020
>
>SUMDUMP captures storage on both sides of the PSW and every register. I
>have 'IP SETDEF DISPLAY(MACHINE)' in effect. Listing the PSW via 'IP L
>019A7318' returns KEY(08):
>
>LIST 019A7318. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(019A7318.) KEY(00)
>019A7318. B24D001C E31D 00045811 00889110 |.(..Thj.|
>019A7328. 1008A784 0009C019 04C0D000 C0F9FE00 |..xd..{..{}.{9..|
>
>'IP L 5R!' returns KEY(00):
>
>LIST 029B9000. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(029B9000.) KEY(08)
>029B9000. C9C1E7C3 D7E3C2D3 0012 |IAXCPTBL|
>029B9010. 0012 0040 042FC000 |... ..{.|
>
>'IP L 7R!' returns KEY(00):
>
>LIST 01DDDF00. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(01DDDF00.) KEY(00)
>01DDDF00. D9C3C540 002E65A3 0FFE 0EB6 |RCE ...t|
>01DDDF10. 050B 00350202 142E 28C0 |...{|
>
>'IP L 9R!' returns KEY(00):
>
>LIST 042FCC30. ASID(X'0072') LENGTH(X'2000') AREA
>ASID(X'0072') ADDRESS(042FCC30.) KEY(00)
>042FCC30. 009A ||
>042FCC40. 042FC000 042FC004 |..{...{.|
>
>Same with all of the other registers that look like addresses. Not one
>does not show the KEY information. I get similar results when processing
>dumps in TCB mode. Pretty much everything pointed to by the RTM2WA is
>included in the SUMDUMP and KEY information seems to be routinely provided.
>
>Perhaps there is some pathological situation where that information
>doesn't display?
>
>--
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLS18160D Response
On Sun, 28 Feb 2021 08:08:55 -0800, Ed Jaffe wrote: >I don't experience issues displaying keys using DISPLAY(MACHINE) when >responding 'Y' to BLS18160D. Did you compare the keys with what rsmdata knows about the key of the page? I learned to use 'yes' to the BLS message and only to use the key for the page that rsmdata shows. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BLS18160D Response
On 2/27/2021 7:48 PM, Mark Jacobs wrote:
>From the FM;
The summary dump data contains data captured closest to the time of the
failure. If you reply Y to use this data, IPCS will not be able to display
storage keys using the DISPLAY(MACHINE) parameter.
Yeah, but...
I don't experience issues displaying keys using DISPLAY(MACHINE) when
responding 'Y' to BLS18160D.
I tried it just now. I initialized a dump still lying around from
yesterday (SLIP to capture an SDC2 abend in an SRB) and responded 'Y' to
the BLS18160D prompt:
IKJ56650I TIME-07:42:42 AM. CPU-00:00:03 SERVICE-22127
SESSION-00:00:47 FEBRUARY 28,2021
BLS18122I Initialization in progress for
DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
BLS18124I TITLE=SLIP DUMP ID=EEJ6
BLS18223I Dump written by z/OS 02.04.00-0 SLIP - level same as IPCS level
BLS18558I This redactable dump has not been post-processed to protect
sensitive data
BLS18222I z/Architecture mode system
BLS18160D May summary dump data be used by dump access? Enter Y to
use, N to bypass.
y
BLS18255I Dump Init Elapsed Time CPU Time
Input I/O 00:00:01.205379 00:00:01.041953
DDIR 00:00:00.842453 00:00:00.605543
BLS18123I 161,077 blocks, 670,080,320 bytes, in
DSNAME('SYS3.DUMP.D210227.T222342.EDJX2.S8')
IKJ56650I TIME-07:44:17 AM. CPU-00:00:07 SERVICE-42085
SESSION-00:02:21 FEBRUARY 28,2021
BLS18224I Dump of z/OS 02.04.00-0 - level same as IPCS level
***
STATUS shows PSW and registers for the DC2 abend:
CPU STATUS:
PSW=47045000 8000 019A7318
(Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
ASID(X'0072') 019A7318. IEANUC01.IAXV6+24D0 IN READ ONLY NUCLEUS
ASCB114 at FBD400, JOB(EDJX2), for the home ASID
ASXB114 at AFD000 for the home ASID. No block is dispatched
HOME ASID: 0072 PRIMARY ASID: 0072 SECONDARY ASID: 0072
General purpose register values
Left halves of all registers contain zeros
0-3 8400 84DC2000 0001
4-7 029B9000 00FBD400 01DDDF00
8-11 042FCC30 08004000
12-15 019A8550 042FE178 042FE000 66004020
SUMDUMP captures storage on both sides of the PSW and every register. I
have 'IP SETDEF DISPLAY(MACHINE)' in effect. Listing the PSW via 'IP L
019A7318' returns KEY(08):
LIST 019A7318. ASID(X'0072') LENGTH(X'2000') AREA
ASID(X'0072') ADDRESS(019A7318.) KEY(00)
019A7318. B24D001C E31D 00045811 00889110 |.(..Thj.|
019A7328. 1008A784 0009C019 04C0D000 C0F9FE00 |..xd..{..{}.{9..|
'IP L 5R!' returns KEY(00):
LIST 029B9000. ASID(X'0072') LENGTH(X'2000') AREA
ASID(X'0072') ADDRESS(029B9000.) KEY(08)
029B9000. C9C1E7C3 D7E3C2D3 0012 |IAXCPTBL|
029B9010. 0012 0040 042FC000 |... ..{.|
'IP L 7R!' returns KEY(00):
LIST 01DDDF00. ASID(X'0072') LENGTH(X'2000') AREA
ASID(X'0072') ADDRESS(01DDDF00.) KEY(00)
01DDDF00. D9C3C540 002E65A3 0FFE 0EB6 |RCE ...t|
01DDDF10. 050B 00350202 142E 28C0 |...{|
'IP L 9R!' returns KEY(00):
LIST 042FCC30. ASID(X'0072') LENGTH(X'2000') AREA
ASID(X'0072') ADDRESS(042FCC30.) KEY(00)
042FCC30. 009A ||
042FCC40. 042FC000 042FC004 |..{...{.|
Same with all of the other registers that look like addresses. Not one
does not show the KEY information. I get similar results when processing
dumps in TCB mode. Pretty much everything pointed to by the RTM2WA is
included in the SUMDUMP and KEY information seems to be routinely provided.
Perhaps there is some pathological situation where that information
doesn't display?
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Re: BLS18160D Response
>From the FM; The summary dump data contains data captured closest to the time of the failure. If you reply Y to use this data, IPCS will not be able to display storage keys using the DISPLAY(MACHINE) parameter. In some cases, the dump values generated when summary dump data is processed can be misleading. For example, if the dump is a result of the SDUMP macro and BRANCH=YES was specified, then replying: YES: Causes the PSAAOLD field to contain the address space control block (ASCB) address of the address space that issued the SDUMP. NO: Causes the PSAAOLD field to contain the address of either the address space that is dumped (if one ASID is being dumped) or the master scheduler's address space (if more than one ASID is being dumped). Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Saturday, February 27th, 2021 at 9:03 PM, Ed Jaffe wrote: > Regarding: > > "BLS18160D May summary dump data be used by dump access? Enter Y to > > use, N to bypass." > > Under what conditions would it ever be appropriate to reply N? > > - > > Phoenix Software International > > Edward E. Jaffe > > 831 Parkview Drive North > > El Segundo, CA 90245 > > https://www.phoenixsoftware.com/ > > > --- > > This e-mail message, including any attachments, appended messages and the > > information contained therein, is for the sole use of the intended > > recipient(s). If you are not an intended recipient or have otherwise > > received this email message in error, any use, dissemination, distribution, > > review, storage or copying of this e-mail message and the information > > contained therein is strictly prohibited. If you are not an intended > > recipient, please contact the sender by reply e-mail and destroy all copies > > of this email message and do not otherwise utilize or retain this email > > message or any or all of the information contained therein. Although this > > email message and any attachments or appended messages are believed to be > > free of any virus or other defect that might affect any computer system into > > which it is received and opened, it is the responsibility of the recipient > > to ensure that it is virus free and no responsibility is accepted by the > > sender for any loss or damage arising in any way from its opening or use. > > - > > 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
BLS18160D Response
Regarding: "BLS18160D May summary dump data be used by dump access? Enter Y to use, N to bypass." Under what conditions would it ever be appropriate to reply N? -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
