Re: Extended linkage index - documentation? PC routine definition problem
We recommend against using LOAD with GLOBAL=(YES The system will free the storage when the LOADing address space terminates, so that is often a system integrity exposure when the LOADing address space is not non-memtermable. CSVDYLPA should be used instead of LOAD GLOBAL=YES Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Richard Zierdt Sent: Tuesday, November 5, 2024 11:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extended linkage index - documentation? PC routine definition problem Problem solved by LOAD . . . GLOBAL=(YES,F) macro / parameter. Another sidebar consideration: When LOADing a module into common storage, the module cannot be linked with PAGE or an ABEND 306-10 is issued. z/OS is probably trying to conserve space. Thanks to all Richard Zierdt From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Tuesday, November 5, 2024 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extended linkage index - documentation? PC routine definition problem Linkage Indexes are reserved via LXRES, using either the LXLIST or ELXLIST keyword. ELXLIST is properly documented as relating to "extended linkage index". I don't know why the OP had difficulty locating that information. Searching the z/OS Linkage Indexes are reserved via LXRES, using either the LXLIST or ELXLIST keyword. ELXLIST is properly documented as relating to "extended linkage index". I don't know why the OP had difficulty locating that information. Searching the z/OS documentation for extended linkage index had the expected hits. Adam J's response describes just what the OP did wrong. Peter Relson z/OS Core Technology Design h 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: Conditional breakpoint TSO TEST
There is some mention of the TPUT exits used by Session Manager and ISPF in here: https://www.ibm.com/support/pages/apar/II02045 Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Wednesday, October 30, 2024 6:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Conditional breakpoint TSO TEST There's a public API that AFAIK is used only by SM; there might be other hooks I don't know about. There's a SM TMP. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Wednesday, October 30, 2024 5:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Conditional breakpoint TSO TEST Caution: This email did not originate from George Mason’s mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, 29 Oct 2024 at 20:47, Seymour J Metz wrote: > Even if TSO TEST LIST uses TPUT, you can capture the output if you run > under the TSO Session Manager. > As an aside, how does that work? Does the Session Manager use SVC screening, or have a private interface to the TPUT SVC? Or something else that I can't think of? Tony H. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS macros with ARCHLVL=7
LINKAGE=SYSTEM was all that STORAGE provided when it was introduced in MVS/ESA. The other LINKAGE options were added in z/OS 1.6. My measurement program says that type 1 SVC linkage is faster than PC for these services. STORAGE SVC: 01.363189 PC: 02.147400 DELTA: 00.784211 POST SVC: 00.525115 PC: 00.766294 DELTA: 00.241179 WAIT SVC: 00.490125 PC: 01.052126 DELTA: 00.562001 ESTAESVC: 01.184268 PC: 01.992566 DELTA: 00.808298 Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, October 20, 2024 6:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS macros with ARCHLVL=7 Using literals is okay if they are likely to be shared, and an L is shorter than an LAY OR IILF, and is massively better than the CNOP/B/DC/L sequence I was complaining about. Does STORAGE still do that in the current z/OS release? BTW, what was the rationale for defaulting STORAGE to LINKAGE=SYSTEM? Is the PC interface faster? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Peter Relson Sent: Saturday, October 19, 2024 8:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS macros with ARCHLVL=7 Caution: This email did not originate from George Mason’s mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. In the alternate reality of unlimited resources and time, those sort of expansion might be done. The only thing that was felt justified was to avoid needing a register to base your code so that you could use relative branch better. IBM macros for the most part require addressability to your static data (so that using literals is felt OK). You can, of course, compare the expansion shown to what you'd get without the specification of SYSSTATE ARCHLVL. Now that is the S/360 version. As to "R form" of freemain (or getmain), we intentionally put no work into that path, as it should probably never be used any longer. Peter Relson z/OS Core Technology Design -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS macros with ARCHLVL=7
The R form (SVC x'A') was functionally replaced by the RU/RC forms (SVC x'78') more than 45 years ago. I don't know when exactly - I have been at IBM for only 45 years. The R form does not support 31- bit addresses or any attribute selections (other than subpool). The same comments apply to the LU, LC, EU, EC, VU, and VC (SVC 4/5) forms. So I would recommend against coding any new instances of them. They will of course remain supported forever for compatibility. But they will never be enhanced. And even the RU/RC forms of the Getmain/Freemain macros are unlikely to be enhanced. Those macros are very old and difficult to maintain due to all the code for the deprecated forms. That is why we added the additional LINKAGE options to STORAGE macro, and have added options like EXECUTABLE only to the STORAGE macro. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Saturday, October 19, 2024 2:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS macros with ARCHLVL=7 > As to "R form" of freemain (or getmain) ... it should probably never be used > any longer. Why? (Serious question.) Charles On Sat, 19 Oct 2024 12:20:44 +, Peter Relson wrote: >In the alternate reality of unlimited resources and time, those sort of >expansion might be done. > >The only thing that was felt justified was to avoid needing a register to base >your code so that you could use relative branch better. >IBM macros for the most part require addressability to your static data (so >that using literals is felt OK). > >You can, of course, compare the expansion shown to what you'd get without the >specification of SYSSTATE ARCHLVL. >Now that is the S/360 version. > >As to "R form" of freemain (or getmain), we intentionally put no work into >that path, as it should probably never be used any longer. -- 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: z14/15 HMC doesn't recognize z/OS 3.1
Yes, we reported that to engineering almost 3 years ago during z/OS 3.1 system testing. In a recent update to the problem record, I see MCL P46683.466 in D41C Bundle H57. and MCL P46598.552 in D41C Bundle S88. Might be one for the SE and one for the HMC, if those MCL, driver, and bundle identifiers mean anything to you. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Wednesday, October 9, 2024 12:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z14/15 HMC doesn't recognize z/OS 3.1 Yes, that's a known bug, I was told that it was supposed to be fixed with the MCLs due out by November. -- 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: Cross-Memory Access: Can an Address Space be treated as a Data Space using an ALET?
It is Program B that needs to do the ALESERV to add the STOKEN for address
space A to address space B's access list.
There is no use to having program A adding address space A to address space A's
access list.
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Richard Zierdt
Sent: Tuesday, October 1, 2024 12:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Cross-Memory Access: Can an Address Space be treated as a Data Space
using an ALET?
The goal is to read data from an address space (not a data space) using an ALET.
The idea is "Program A" creates its own ALET that another program ("Program B")
uses in its address space to read data from Program A's address space. Is this
possible ?
A summary of Program A code (AMODE31, RMODE24, authorized) is:
ALESERV EXTRACTH,STOKEN=stoken Returns STOKEN for the address space
MODESET KEY=ZERONeeded, or return code from ALESERV is not zero
ALESERV ADD AL=PASN,
STOKEN=stoken,input STOKEN
ALET=HomeALET,output ALET
CHKEAX=NO,
AL=PASN,
ACCESS=PUBLIC,
MF=(E,ALESERV)
SYSEVENT DONTSWAP make unswappable
WTOR sit on a WTOR so that Program B can access Program A's address
space
Result is HomeALET=x'01010038' which looks good, except that Program B gets an
0E0, Reason Code 29 (hex) abend using that ALET. "An ALET specified an access
list entry (ALE) that is not valid."
A summary of Program B code (AMODE31, RMODE24, authorized) is:
SAC 512 sets the ASC mode to AR mode
LAM 0,15,Zeros clear access registers
L R6,=x'7000' load offset to datainto GR6
LAM 6,6,=x'01010038'load ALET of Program A into AR6
Abend0E0 MVC Here,0(R6) copy data from Program A to Here
SAC 0 escape AR mode
Here dsCL32
SYSTEM COMPLETION CODE=0E0 REASON CODE=0029 ACTIVE MODULE
ADDRESS=_7000 OFFSET=0050 NAME=PROGRAMB DATA AT PSW 704A
- C0809A66 C084D21F C05C6000
AR/GR 0: /0064 1: /6FF8
2: /0040 3: /008DBD64
4: /008DBD40 5: /008FB058
6: 01010038/7000 7: /00FBB880
8: /008FD608 9: /008D0CB0
A: /01DE1E00 B: /0001
C: /80007000 D: /8000
E: /80FD66D8 F: /80007000
Any help appreciated; Thanks --
Richard Zierdt
Confidentiality Warning/Avertissement de confidentialité:
This message is intended only for the named recipients. This message may
contain information that is privileged or confidential. If you are not the
named recipient, its employee or its agent, please notify us immediately and
permanently destroy this message and any copies you may have. Ce message est
destiné uniquement aux destinataires dûment nommés. Il peut contenir de
l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire
dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder
et supprimer ce message ainsi que toute copie qui peut en avoir été faite.
--
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: 24-bit private region on z16 processor
ASLR was introduced in APAR OA57914 on z/OS 2.4. It affects all storage addresses in the region. A random number of pages of storage are left unused in order to change the addresses of used storage. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark S Waterbury Sent: Thursday, September 12, 2024 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 24-bit private region on z16 processor In that referenced manual, I see the following: = Impact of ASLR on virtual storage The decision to enable ASLR represents a tradeoff between enhanced security and a reduction in the amounts of available 24-bit, 31-bit, and 64-bit private storage. When enabled for 24- and 31-bit virtual storage, the size of available private storage will be reduced by up to 63 pages and 255 pages, respectively. A job’s requested region size must still be satisfied from within the reduced private area in order for the job to be started. Jobs whose region size cannot be satisfied will result in an ABEND 822. If a job’s requested region size is satisfied, it is still possible that the reduced size of private storage prevents the job from completing, resulting in an ABEND 878. = Why does ASLR require so much additional storage? 256Kb to 1Mb of "overhead" for what, exactly? Does this ASLR affect only the addresses where programs are loaded, or does it also affect the address of every GETMAINed chunk of storage in the region? What was the first release of z/OS to support this ASLR? Thanks in advance, Mark S. Waterbury -- 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: 24-bit private region on z16 processor
The documentation about what it does is here: https://www.ibm.com/docs/en/zos/3.1.0?topic=overview-address-space-layout-randomization Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Monday, September 9, 2024 9:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 24-bit private region on z16 processor That's it. Yes. These systems do have ASLR active. I didn't realize that once its enabled we can expect what I'm seeing. Is that documented anywhere? Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com On Monday, September 9th, 2024 at 8:19 PM, Jim Mulder wrote: > I would expect that if Address Space Layout Randomization is active. > > Is ASLR(YES) specified in DIAGxx? > > The D DIAG command, or VERBX IGVDGNIP under IPCS, will tell you. > > Jim Mulder > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Mark Jacobs > > Sent: Monday, September 9, 2024 6:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 24-bit private region on z16 processor > > I'm 99% sure those parameters aren't in any of the systems where I'm being > weirded out as it relates to where low private begins when I look at it using > SDSF VMAP, but I'll check tomorrow. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonma > il.com > > > > > On Monday, September 9th, 2024 at 4:40 PM, Allan Staller > 0632b4c7ca99-dmarc-requ...@listserv.ua.edu wrote: > > > Classification: Confidential > > > > "Low Core" generally extend up to about x'6000' (give or take). This is the > > start of low private. > > V=R and ADDRSPC storage IIRC is just above this so actual "low private" may > > start (e.g. x'8000') depending on values for V=R and ADDRSPC=REAL stoarge. > > > > FWIW, these 2 parameters date from "day 1" of virtual storage and are > > probably useless in this day and age. > > If they are still present in IEASYSxx, I would suggest removing them when > > convenient. > > > > HTH, > > > > -Original Message- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On > > Behalf Of Mark Jacobs > > > > Sent: Monday, September 9, 2024 3:05 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: 24-bit private region on z16 processor > > > > [CAUTION: This Email is from outside the Organization. Unless you > > trust the sender, Don’t click links or open attachments as it may be > > a Phishing email, which can steal your Information and compromise > > your Computer.] > > > > I'm not talking about the top of the 24-bit private region, I'm looking at > > the beginning/bottom of the region and it's starting all over the place. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@proton > > ma > > il.com > > > > On Monday, September 9th, 2024 at 2:30 PM, Mike Schwab > > 05962a42dc49-dmarc-requ...@listserv.ua.edu wrote: > > > > > Varies by operating system level occasionally PTF, and user > > > configuration such as TSO in (non-)LPA area. > > > > > > On Mon, Sep 9, 2024 at 8:25 AM Mark Jacobs > > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > > > > > Silly question. Is there anything different as it relates to sizing of > > > > the 24-bit private region on z16 processors? > > > > > > > > Mark Jacobs > > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 24-bit private region on z16 processor
I would expect that if Address Space Layout Randomization is active. Is ASLR(YES) specified in DIAGxx? The D DIAG command, or VERBX IGVDGNIP under IPCS, will tell you. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Monday, September 9, 2024 6:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 24-bit private region on z16 processor I'm 99% sure those parameters aren't in any of the systems where I'm being weirded out as it relates to where low private begins when I look at it using SDSF VMAP, but I'll check tomorrow. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com On Monday, September 9th, 2024 at 4:40 PM, Allan Staller <0632b4c7ca99-dmarc-requ...@listserv.ua.edu> wrote: > Classification: Confidential > > "Low Core" generally extend up to about x'6000' (give or take). This is the > start of low private. > V=R and ADDRSPC storage IIRC is just above this so actual "low private" may > start (e.g. x'8000') depending on values for V=R and ADDRSPC=REAL stoarge. > > FWIW, these 2 parameters date from "day 1" of virtual storage and are > probably useless in this day and age. > If they are still present in IEASYSxx, I would suggest removing them when > convenient. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf > Of Mark Jacobs > > Sent: Monday, September 9, 2024 3:05 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 24-bit private region on z16 processor > > [CAUTION: This Email is from outside the Organization. Unless you > trust the sender, Don’t click links or open attachments as it may be a > Phishing email, which can steal your Information and compromise your > Computer.] > > I'm not talking about the top of the 24-bit private region, I'm looking at > the beginning/bottom of the region and it's starting all over the place. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjacobs@protonma > il.com > > > > > On Monday, September 9th, 2024 at 2:30 PM, Mike Schwab > 05962a42dc49-dmarc-requ...@listserv.ua.edu wrote: > > > Varies by operating system level occasionally PTF, and user > > configuration such as TSO in (non-)LPA area. > > > > On Mon, Sep 9, 2024 at 8:25 AM Mark Jacobs > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > > > Silly question. Is there anything different as it relates to sizing of > > > the 24-bit private region on z16 processors? > > > > > > Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subpool FREEMAIN
FREEMAIN A=(1),LV=(0) 12,*** IHB001 MODE OPERAND REQ'D-NOT SPECIFIED So it would seem that you actually most have done something like FREEMAIN RU,A=(1),LV=(0) Jim Mulder -Original Message- From: Jim Mulder Sent: Friday, August 30, 2024 8:21 PM To: IBM Mainframe Discussion List Subject: RE: Subpool FREEMAIN You did not specify a positional parameter. It looks like the macro assumed RU (SVC x'78') in that case, but you set R0 and R1 in the format for R (SVC x'A'). FREEMAIN R,A=(1),LV=(0) should work better. But I would recommend FREEMAIN RU,SP=1 Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, August 30, 2024 6:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Subpool FREEMAIN Okay, true confessions time: in more years of this than I care to admit I have never done a subpool FREEMAIN. I am trying to free subpool 1. R0 = x'0100' R1 = 0 I issue FREEMAIN A=(1),LV=(0) I get ABEND S378 001C A user has requested that storage at virtual address 0 be freed. This can happen if the user intended an entire subpool, but has incorrectly specified a non-zero length with an address of 0. In the trace I see SVC 78 _1428E5DC 0003 0100 What might I be doing wrong? (Nothing oddball here: no AMODE 64, no AR mode. z/OS V2R4.) Thanks! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subpool FREEMAIN
You did not specify a positional parameter. It looks like the macro assumed RU (SVC x'78') in that case, but you set R0 and R1 in the format for R (SVC x'A'). FREEMAIN R,A=(1),LV=(0) should work better. But I would recommend FREEMAIN RU,SP=1 Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, August 30, 2024 6:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Subpool FREEMAIN Okay, true confessions time: in more years of this than I care to admit I have never done a subpool FREEMAIN. I am trying to free subpool 1. R0 = x'0100' R1 = 0 I issue FREEMAIN A=(1),LV=(0) I get ABEND S378 001C A user has requested that storage at virtual address 0 be freed. This can happen if the user intended an entire subpool, but has incorrectly specified a non-zero length with an address of 0. In the trace I see SVC 78 _1428E5DC 0003 0100 What might I be doing wrong? (Nothing oddball here: no AMODE 64, no AR mode. z/OS V2R4.) Thanks! Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Breaking Event Address, BEAR
I did not understand their concern, but I don't know squat about Linux. On z/OS, we would have no such concern. An unauthorized program on z/OS can already perform same function as STBEAR simply by having an ESTAE in place, and intentionally causing a program check, and then looking at SDWABEA. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Wednesday, July 31, 2024 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR Sounds like security by obfuscation. The exposure would be that source location can be viewed/altered by the target, If it cannot be altered I wonder how knowing the address would be an exposure. On Wed, 31 Jul 2024 20:34:28 +1000 Attila Fogarasi <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote: :>In Linux STBEAR could be used as part of an attack vector to locate the :>target. No such exposure in z/OS (or z/VSE and z/VM for that matter) due :>to different memory structure. An unintended consequence of supporting a :>disparate architecture. :> :>On Tue, Jul 30, 2024 at 9:17?PM Binyamin Dissen < :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote: :> :>> Curious as to how that would bother Linux. :>> :>> I do understand EPSW as it exposes the real state, but STBEAR? :>> :>> On Tue, 30 Jul 2024 03:36:48 + Jim Mulder wrote: :>> :>> :> I found my emails from 2019-2020 when STBEAR was being designed, and I :>> see that :>> :>I had suggest that (speaking for z/OS) STBEAR should be allowed in :>> problem state for exactly the reason :>> :>for which you want to use it, but Linux :>> :>did not want it to be allowed in problem state. I see that Linux had :>> suggested making it controllable :>> :>by a CR bit (i.e., semi-privileged), but it looks like we didn't pursue :>> that. Sorry about that. :>> :>I supposed I should have paid more attention to that part of the :>> discussion, but it probably was not the hottest :>> :>issue that I was involved with at the time. :>> :> :>> :>Jim Mulder :>> :> :>> :>-Original Message- :>> :>From: IBM Mainframe Discussion List On :>> Behalf Of Steve Austin :>> :>Sent: Monday, July 29, 2024 10:05 AM :>> :>To: IBM-MAIN@LISTSERV.UA.EDU :>> :>Subject: Re: Breaking Event Address, BEAR :>> :> :>> :>Yes I could use JAS/BAS and have done so in the past, but it occurred to :>> me there might be a better way. STBEAR being privileged is disappointing. I :>> can understand LBEAR being privileged , but I'm not sure why STBEAR should :>> be. :>> :> :>> :>-Original Message- :>> :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] :>> On Behalf Of Seymour J Metz :>> :>Sent: Monday, July 29, 2024 2:55 PM :>> :>To: IBM-MAIN@LISTSERV.UA.EDU :>> :>Subject: Re: Breaking Event Address, BEAR :>> :> :>> :>Unless you're in supervisor state, I don't know of a way to do it. Dou :>> you have a spare register so you could JAS to the message routine? :>> :> :>> :>-- :>> :>Shmuel (Seymour J.) Metz :>> :>http://mason.gmu.edu/~smetz3 :>> :>??? ?? ??? :>> :>?? ??? ?? :>> :> :>> :> :>> :> :>> :> :>> :>From: IBM Mainframe Discussion List on :>> behalf of :>> :>Steve Austin :>> :>Sent: Monday, July 29, 2024 8:06 AM :>> :>To: IBM-MAIN@LISTSERV.UA.EDU :>> :>Subject: Re: Breaking Event Address, BEAR :>> :> :>> :>The code I'm dealing with has an error routine that build a message, but :>> :>sometimes the message is insufficient and it would be useful to know what :>> :>branched to that routine without forcing a dump. :>> :> :>> :>-The code Original Message- :>> :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>> :>Behalf Of Seymour J Metz :>> :>Sent: Monday, July 29, 2024 12:58 PM :>> :>To: IBM-MAIN@LISTSERV.UA.EDU :>> :>Subject: Re: Breaking Event Address, BEAR :>> :> :>> :>BEAR is not the address of the last branch, it's the address of the last :>> :>breaking event. If you brnch to an OPEN and get am S213, I don't believe :>> :>that there is any way to recover the branch. :>> :> :>> :>What is the specific scenario you're concerned with. :>> :> :>> :>IBM: is the BEAR at the time of a p
Re: Breaking Event Address, BEAR
I found my emails from 2019-2020 when STBEAR was being designed, and I see that I had suggest that (speaking for z/OS) STBEAR should be allowed in problem state for exactly the reason for which you want to use it, but Linux did not want it to be allowed in problem state. I see that Linux had suggested making it controllable by a CR bit (i.e., semi-privileged), but it looks like we didn't pursue that. Sorry about that. I supposed I should have paid more attention to that part of the discussion, but it probably was not the hottest issue that I was involved with at the time. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Austin Sent: Monday, July 29, 2024 10:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR Yes I could use JAS/BAS and have done so in the past, but it occurred to me there might be a better way. STBEAR being privileged is disappointing. I can understand LBEAR being privileged , but I'm not sure why STBEAR should be. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, July 29, 2024 2:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR Unless you're in supervisor state, I don't know of a way to do it. Dou you have a spare register so you could JAS to the message routine? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Monday, July 29, 2024 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR The code I'm dealing with has an error routine that build a message, but sometimes the message is insufficient and it would be useful to know what branched to that routine without forcing a dump. -The code Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, July 29, 2024 12:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Breaking Event Address, BEAR BEAR is not the address of the last branch, it's the address of the last breaking event. If you brnch to an OPEN and get am S213, I don't believe that there is any way to recover the branch. What is the specific scenario you're concerned with. IBM: is the BEAR at the time of a program check available to recovery exits? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Steve Austin Sent: Monday, July 29, 2024 6:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Breaking Event Address, BEAR I lied I don’t want the Breaking Event address I’d like the source of the Breaking Event address. And I’m assuming the source of the BEA is the same as the source of the branch entries in the trace table. I’d like my running program to retrieve the address of the last branch without breaking anything. Is this possible? Thanks -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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 -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- 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 -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to l
Re: Does MVCDK move 'per byte' like MVC?
Since MVCDK is not an interruptible instruction, it has to move all of the data, or program check and move nothing. There can be no partial moving. I think that MVC in usually implemented with special hardware to detect and optimize the one byte propagation case, since that is known to be a common programing technique going back to the 360 machines. Hypothetically presuming that MVCDK is implemented in millicode, and that hardware does not provide a MVC-like assist to millicode which can fetch using one key and store using another key, one could conceive that millicode might do something like EXRL an MVC to fetch using the PSW key and move to HSA, and then EXRL another MVC to move from HSA, storing using the destination key. That would lead to the results that the original poster observed. I don't know offhand how millicode implements MVCDK on current machines. I know engineers to ask if I really needed to know. Jim Mulder -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inquiry about Installing Hercules on LinuxONE
Yes, I meant for Jason's use case. I was involved in getting z/OS running in the ZVDT/Wazi environment, so I am aware of those things. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY Jim Mulder wrote: >IBM does not provide any license for any release of z/OS that permits >you to run it on a LinuxONE machine, or under any non-IBM emulator >on any machine. I assume you meant ?for the uses Jason Cai described,? and (if so) I agree. To be clear, IBM licenses z/OS (and IBM software products for z/OS) to run on IBM LinuxONE servers, and on IFLs on IBM Z machines, for certain limited purposes. The product that facilities these specific, limited, licensed purposes is called IBM Virtual Dev and Test for z/OS. Here?s the product?s landing page: https://www.ibm.com/products/virtual-dev-and-test-zos IBM Cloud offers a comparable service that runs on IBM hosted machines: https://www.ibm.com/cloud/wazi-as-a-service However, to reiterate, ZVDT/Wazi, and its associated z/OS licensing, do not fit the uses Jason Cai described. I suggest that Jason contact IBM to obtain a suitable z/OS license for his needs. Or contact a z/OS licensee who has a suitable commercial license from IBM for his usage and who is willing to provide hosting services. ? Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com<mailto:sipp...@sg.ibm.com> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Inquiry about Installing Hercules on LinuxONE
IBM does not provide any license for any release of z/OS that permits you to run it on a LinuxONE machine, or under any non-IBM emulator on any machine. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jason Cai Sent: Tuesday, June 11, 2024 1:59 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Inquiry about Installing Hercules on LinuxONE Our organization's z mainframe has reached the end of its hardware service life and is no longer capable of running z/OS. However, we have a LinuxONE machine that remains operational. We possess historical data backups from our z/OS environment that we need to access. To address this, we are considering the installation of the Hercules emulator on our zLinux environment. Our goal is to utilize Hercules to emulate the z/OS necessary to access our backup data sometime. Could you please advise on the feasibility of this approach? Specifically, we are interested in understanding: 1. The compatibility of Hercules with zLinux on a LinuxONE machine. 2. Any known limitations or considerations we should be aware of when using Hercules for this purpose. 3. The steps required to set up Hercules in a zLinux environment to access z/OS backup data. Your expertise and guidance on this matter would be greatly appreciated. We are eager to find a solution that allows us to utilize our existing resources effectively while ensuring the integrity and accessibility of our historical data. Thank you very much for your time and assistance. Best regards, Jason Cai -- 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: Epoch Index
z/OS 3.1 does not support testing with dates beyond 09/17/2042. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Tuesday, June 11, 2024 1:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Epoch Index So, as of z/os 3.1, there does not seem to be a way to test with dates beyond 09/17/2042? A “R 00,DATE=2042.260 “ works, but a “R 00,DATE=2042.261” generates a “IEE306I RPLY HAS INVALID NUMERICS” message. Or am I missing something obvious? Thank you. -- 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: VIO in 2024
It is a way to use real storage to avoid I/O for applications that don't do that on their own. So, yes, as long as you have enough real storage so that VIO use does not result in paging. If the VIO data is getting paged out, you would usually be better off using ordinary I/O than paging I/O. Paging I/O uses a 4K block size, which is inefficient for FICON, unless you are using zHPF. z/OS has not enhanced its paging I/O to use zHPF. With non-paging I/O, you can use a larger block size, and many of the access methods use zHPF. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Wednesday, June 5, 2024 8:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: VIO in 2024 Does sending small datasets to VIO sill make sense in 2024? The Ministry of Silly Questions thanks you in advance for your reply! Mark Jacobs Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.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
Re: finding callers key in svc
Use the ATTACHX macro with KEY=NINE to attach a key 9 subtask. That's what CICS does. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY >Is there a way to force the program to go to subpool 244 for example, that is >not fetch protected? >I'm trying to create an easy test program that could simulate the situation >where the svc is called from a cics task running in key 9 trying to access key >8 storage. That case would fail if I start using MVCSK en MVCDK, and perhaps I >can add an ESTAE to do recovery in that scenario. First thing I >would like to try is to create an ESTAE that would just WTO the 0C4 situation, >for example 'task running in key xx tried to access storage in key yy' . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0c4 creation
From software point of view, the only difference between an operation exception for a 00xx or 00x or 00xx in the instruction stream vs an invalid opcode B2xx in the instruction stream would be the Instruction Length Code, and I don't think that would be an important distinction to software. The invalid 00 opcode provides sufficient capability to cause an operation exception, with diagnostic information of an arbitrary length following the 00 opcode. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Wednesday, April 24, 2024 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0c4 creation I didn't notice that reference to the B2Ex opcodes before. Bitsavers https://bitsavers.org/pdf/ibm/370/princOps/ has several old editions of the POO, wherein I see: The -4 edition of the System/370 POO (1974) has the reference to the B2Ex opcodes. The -6 edition (1980) does not reference B2Ex, but only 00. There is a change bar on that, so I assume the change went in with that edition, but I don't have a -5 to verify that. This seems to continue to be the same, though I didn't check all editions. The -4 edition of the z/Architecture POO (2005) has the same reference that it is "improbable" that opcode 00 will ever be used. Starting in the -5 edition of the z/Architecture POO (2007) it was changed to "Operation code 00 hex will never be assigned to an instruction implemented in the CPU." So the reference to the improbability of B2Ex opcodes ever being implemented was a short lived one. The two opcodes in that range, B2E8 (PPA) and B2EC (ETND) first appeared in the -9 edition of the z/Architecture POO in 2012. -- Tom Marchant On Tue, 23 Apr 2024 18:39:01 -0400, Tony Harminc wrote: >On Mon, 22 Apr 2024 at 09:50, Seymour J Metz wrote: > >> IBM promised to never use opcode 00, and that's what I use when I >> want (E)SPIE in the skie. >> > >But way back when (around the last S/370 PofO they said "The operation >code 00, with a two-byte instruction format, and the set of sixteen >16-bit operation codes B2E0 to B2EF, with a four-byte instruction >format, are allocated for software uses where indication of invalid >operation is required. It is improbable that these operation codes will >ever be assigned to an instruction implemented in the CPU." > >Then at some point (z10 era?), they defied improbability and used some >of the B2Ex opcodes. You'd think it wouldn't have killed them to keep a >range of just 16 two-byte opcodes available for customers. > >Tony H. > >-- >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ASVT & ASID discrepancy mystery
I don't think that there is much with the dump that you could do yourself. The control structures that keep track of nonreusable ASIDs are OCO. Can you open a Case to IBM and send in the dump so I can look at it? Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Alan Haff Sent: Thursday, March 14, 2024 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASVT & ASID discrepancy mystery On Thu, 14 Mar 2024 16:49:03 -0500, Alan Haff wrote: >No records containing either of those but I did find this that corresponds to >the time that IEA059E was issued: >RIDS/IEAVXSRM#L RIDS/#UNKNOWN AB/S0AC7 PRCS/001B REGS/0D218 REGS/041B8 >Also, I just discovered that MASTER took a dump at that time as well. I'll >poke around in the dump. Anything in particular that you think would be >helpful? >Ok, I looked up 001B and yeah, it's just indicating we had an IEA059E. So >no surprise there. -- 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: ASVT & ASID discrepancy mystery
The more important thing would be to have taken a standalone dump before reIPLing. You might have had an ASVT overlay. If you search your logrec, do you see any records containing IEAVESAR or IEAVELCR? Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Alan Haff Sent: Thursday, March 14, 2024 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ASVT & ASID discrepancy mystery On Thu, 14 Mar 2024 19:00:49 +0000, Jim Mulder wrote: > The IEA_ASIDS check should show you all of the ASIDs that are >nonreusable in the IEAVEH012I and IEAVEH001I messages, even more than an hour >past the time when they became nonreusable. ASVTAVAI will be on for those >ASIDs. IEA_ASIDS showed that there were only a handful of nonreusable ASIDs. I wish I had thought to save a copy of the output. :( -- 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: ASVT & ASID discrepancy mystery
Cross memory and the resulting non-reusable ASIDs have only been around since 1981. The field name ASVTAVAI predates that. Since 1981, ASVTAVAI just means that the ASID is not currently in use for an active address space. It does not mean that it is available for reuse, since in may be in a nonreusable state. The IEA_ASIDS check should show you all of the ASIDs that are nonreusable in the IEAVEH012I and IEAVEH001I messages, even more than an hour past the time when they became nonreusable. ASVTAVAI will be on for those ASIDs. >The IEA_ASIDS check definitely caught the problem when it happened. >Unfortunately, the check runs hourly and all of the the ASIDs were consumed in >the span of the hour between runs. >I did run the IEA_ASIDS in verbose mode and as I recall its output roughly >corresponded to ASIDLIST's output. >We think we know which program was the culprit but we'd like to understand why >so many ASVT entries had ASVTAVAI set (meaning they're available) but the ASVT >said so few were available. Jim Mulder z/OS Diagnosis, Design, Development, 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
Re: ASVT & ASID discrepancy mystery
I would suggest starting with the IEA_ASIDS health check. For example, on one of our test systems: SDSF OUTPUT DISPLAY IEA_ASIDS LINE 0 COLUMNS 02- 16 COMMAND INPUT ===>SCROLL ===> CSR *** TOP OF DATA * CHECK(IBMSUP,IEA_ASIDS) SYSPLEX:UTCPLXJ8 SYSTEM: JC0 START TIME: 03/14/2024 12:42:18.542848 CHECK DATE: 20060418 CHECK SEVERITY: LOW CHECK PARM: NORMAL(5%),REPLACEMENT(5%),DAYSUNTILIPL(1) IEAVEH010I Summary of ASID availability ASIDs Limit Avail InUse Total Normal150 2499 501 3000 Replacement 595 5 100 IEAVEH061I The system has been IPLed for between 2 and 3 days. On the average 2 ASIDs have become non-reusable per day. At the current rate of depletion, the system will run out of ASIDs in 1297 days. IEAVEH012I Permanently non-reusable ASIDs by jobname C2PACMON (3) DRLJSMFX (1) AVZC (1) IEAVEH001I Permanently non-reusable ASIDs by ASID ASID: 0215 Jobname: C2PACMON ASID: 01F8 Jobname: C2PACMON ASID: 0199 Jobname: DRLJSMFX ASID: 0178 Jobname: AVZC ASID: 013B Jobname: C2PACMON END TIME: 03/14/2024 12:42:18.543247 STATUS: SUCCESSFUL Jim Mulder Original Message- From: IBM Mainframe Discussion List On Behalf Of Alan Haff Sent: Thursday, March 14, 2024 12:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ASVT & ASID discrepancy mystery We had an outage on one of our development systems earlier this week due to lack of available ASIDs. After I freed up some ASIDs and was able to get logged on, I ran Mark Zelden’s ASIDLIST program (file 434 on the CBT tape). The results were… weird (to me, anyway). The program walks through the ASVT and lists out each ASCB and whether it’s available, non-reusable, or its jobname. At the end of the run, the program lists the total number of address spaces it found, how many of them that are in use, how many of them that are non-reusable, and a calculation of the number that are available (total minus in-use minus non-reusable). TOTAL ADDRESS SPACES IN THE SYSTEM:860 TOTAL ACTIVE ADDRESS SPACES IN THE SYSTEM: 143 TOTAL AVAILABLE ADDRESS SPACES IN THE SYSTEM: 673 TOTAL NON-REUSABLE ADDRESS SPACES IN THE SYSTEM:44 Looks all good right? From this you’d think there would be plenty of available address spaces – 673. But here’s where it gets weird. The program also displays the values from the ASVT itself and for some reason, the value of ASVTAAV (“NUMBER OF FREE SLOTS ON THE ASVT AVAILABLE QUEUE” – see SYS1.MODGEN(IHAASVT)) says that only 9 ASIDs are available: ASID USAGE FROM ASVT MAXUSER FROM IEASYSXX: 500 IN USE ASIDS: 491 AVAILABLE ASIDS: 9 RSVSTRT FROM IEASYSXX:10 RSVSTRT IN USE: 0 RSVSTRT AVAILABLE:10 RSVNONR FROM IEASYSXX: 350 RSVNONR IN USE:44 RSVNONR AVAILABLE: 306 NON-REUSABLE ASIDS :44 At that point I decided to throw in the towel and re-IPL. I don’t know anywhere near enough about z/OS internals to be able to explain the discrepancy I found. Maybe it makes more sense to someone here. Any thoughts? -- 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 / arch
Re: IRB interrupt code
For an SVC interrupt, RBINTCOD indicates the SVC number. For a program check interrupt, RBINTCOD indicates the program interrupt code. For other types of interrupts, RBINTCOD is not updated. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Friday, March 8, 2024 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IRB interrupt code Jim First thanks I’m a little confused here and I’m obviously not an expert But if the interruption was because of a load SVC wouldn’t RBOPSW - 2 = X’0A’ More so I would think that there were more than 2 reason for RB to get interrupted The first 2 abend what I mean by that is a program check and second SVC interrupt In the case of an IRB which is a asynchronous exit it would be and forgive me if I’m not using the right terminology external interrupt or timer interrupt Thanks > On Mar 8, 2024, at 11:53 AM, Jim Mulder wrote: > > SVC 8 (LOAD). > > Jim Mulder > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > Sent: Friday, March 8, 2024 11:09 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: IRB interrupt code > > I thought all list of all the interrupt codes were in the z/os pops I looked > at chapter 6interruptions there was a description for a number of them > > Just not a list with a code > > Anyway for my IRB the previous RB which was my program PRB had RBINTCOD value > X'020008' > > Where can I find out what the interrupt code is > > thanks > > -- > 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 -- 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: IRB interrupt code
SVC 8 (LOAD). Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Friday, March 8, 2024 11:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IRB interrupt code I thought all list of all the interrupt codes were in the z/os pops I looked at chapter 6interruptions there was a description for a number of them Just not a list with a code Anyway for my IRB the previous RB which was my program PRB had RBINTCOD value X'020008' Where can I find out what the interrupt code is thanks -- 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: How to reduce the overhead of WLM?
The most important thing is RMPTTOM for reducing the SRM timer pop overhead. Note that Timer DIE processing is uncaptured time. My IEAOPTxx for running under VM has RMPTTOM=3 /*REDUCE SRM INVOKATION FREQUENCY ON VM */ And that is a value we set a couple of decades ago, and haven't thought much about it since. You might want it even higher for faster machines than we had back then. I suggested some years ago that SRM should self-tune the timer pop interval to be less frequent at low utilization, but I haven't gotten any traction on that so far.. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Wendell Lovewell Sent: Monday, March 4, 2024 6:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: How to reduce the overhead of WLM? This is probably a strange question, but is there a way to reduce WLM cpu usage? Here's the situation: - The system is a lightly used development system. Unless something is in a loop (very rare), CPU % probably is usually less than 10%. And except for system regions & CICS, it's rare to have multiple jobs running concurrently. - Only one processor defined to the VM. No ZIIP either. - We are charged for CPU cycles. - WLM is the highest consumer of CPU. JES2, TCPIP, ZFS and SDSFAUX round out the top 5 consumers. There is a lot of information about WLM tuning, but as best I can tell almost none of it relates to reducing WLM usage. From reading the Init & Tuning manual, I'm trying these settings: AIMANAGEMENT=NO HIPERDISPATCH=NO CCCAWMT=45 RMPTTOM=15000 I was thinking that perhaps reducing whatever processing intervals I could might help. But I can't tell these changes made a difference. (I don't have a tool to measure WLM usage.) Any suggestions would be appreciated. TIA, Wendell -- 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: Nanosecond resolution timestamps for HLL's?
I did not answer your question about " What's the fastest way one processor can signal the other? Spinning on a storage content? Then a cache fault might provide sufficient delay to guarantee consistency." because I did not know how that is implemented in current machines. I asked today, and the answer is that There is special handling of the store operand of a STCK in order to make sure that the store is not released until the TOD bit above the CPU number ticks. Thus if another CPU tries to observe the value stored by a STCK (or anything else in that cache line that contains the STCK operand), it is delayed, because it cannot obtain read access to the cache line until the relevant TOD bit ticks. So that's another performance reason to avoid using STCK. In addition to delaying the CPU issuing STCK if it is soon after another STCK on the same CPU, it can also delay other CPUs from subsequently accessing the cache line that contains the STCK operand. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, February 27, 2024 9:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? On Tue, 27 Feb 2024 16:46:00 -0600, Jon Perryman wrote: >On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder wrote: > >>STCK, which inserts a processor related value in the low order bits to meet >>the "unique with a partition" requirement. > You (carefully) avoided making any representation about multiple partitions. And a "processor related value" can guarantee uniqueness but not monotonicity: Suppose a processor with a higher value does STCK. On detecting this, a processor with a lower value does its own STCK before the clock changes. Clearly the value stored later and differing only in the "processor related value" will be algebraically less. The PoOps guarantees no such inconsistency will be detectable. "detectable" is a tricky word. Schrödinger's cat comes to mind: if you can't see it, you can't say it happened. What's the fastest way one processor can signal the other? Spinning on a storage content? Then a cache fault might provide sufficient delay to guarantee consistency. >If there's not a simple answer, I'll take your word this is monotonic, Out of >curiosity, what is the precision of STCK and how does it guarantee monotonic >time? In other words, how does STCK distinguish between 10 STCK's on the same >CPU in the same partition within 49 microseconds? Multiply 244 picoseconds >(TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz >Telum processor, single cycle instructions take 191 picoseconds which means a >single CPU can potentially execute 256 instructions during that 49 microsecond >timeframe. -- gil -- 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: Nanosecond resolution timestamps for HLL's?
Yes, I did carefully avoid making any representation about multiple partitions. On z16, I believe that it is possible to get the same value from STCK in different partitions. If you need unique values within a z/OS sysplex, STCKE provides that. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, February 27, 2024 9:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? On Tue, 27 Feb 2024 16:46:00 -0600, Jon Perryman wrote: >On Sat, 24 Feb 2024 19:50:32 +0000, Jim Mulder wrote: > >>STCK, which inserts a processor related value in the low order bits to meet >>the "unique with a partition" requirement. > You (carefully) avoided making any representation about multiple partitions. And a "processor related value" can guarantee uniqueness but not monotonicity: Suppose a processor with a higher value does STCK. On detecting this, a processor with a lower value does its own STCK before the clock changes. Clearly the value stored later and differing only in the "processor related value" will be algebraically less. The PoOps guarantees no such inconsistency will be detectable. "detectable" is a tricky word. Schrödinger's cat comes to mind: if you can't see it, you can't say it happened. What's the fastest way one processor can signal the other? Spinning on a storage content? Then a cache fault might provide sufficient delay to guarantee consistency. >If there's not a simple answer, I'll take your word this is monotonic, Out of >curiosity, what is the precision of STCK and how does it guarantee monotonic >time? In other words, how does STCK distinguish between 10 STCK's on the same >CPU in the same partition within 49 microseconds? Multiply 244 picoseconds >(TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz >Telum processor, single cycle instructions take 191 picoseconds which means a >single CPU can potentially execute 256 instructions during that 49 microsecond >timeframe. -- gil -- 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: Nanosecond resolution timestamps for HLL's?
You don't need to take my word that STCK on a processor is monotonic. That is stated in Principles of Operation. As I described in a prior post a week ago, " Monotonic increasing on a processor is done by delaying, when two STCKs are issued too close together on the same processor. " In other words, the hardware delays the execution of a subsequent STCK as needed to wait until a higher value will be returned than for the previous STCK on the same processor. Principles of Operation does not talk about the delaying, but you can infer that since there is no other possible way to implement the monotonic requirement. Principles of Operation does say: "For STORE CLOCK, when the value of a running clock is stored, nonzero values may be stored in positions to the right of the rightmost incremented bit; this is to ensure that a unique value is stored." Due to this, the precision of STCK is model and configuration dependent. Prior to the z16, for a given generation of processor, the number of bits was constant and related to the maximum number of processors in a CEC for that generation. So as newer generations supported more processors in a CEC, the precision of STCK (and the amount of delaying required) got worse. On z16, in order to reduce the delaying in some cases, when there are fewer than some number of processor in the partition, the low order bits are related to the logical processor ID within the partition instead of a physical processor ID, so that fewer bits are needed to ensure uniqueness within the partition. That means that partitions with more than that number of logical processors have lower STCK precision and longer delays. (I do know what the number is, but I don't know if that is intended to be public knowledge, so I am avoiding stating the number). There are of course other performance effects of large partitions, like cross drawer cache and memory access time. A sufficiently motivated programmer might experimentally determine some of these things for various machine generations and configurations by writing a program to issue some number of sequential STCKs and analyzing the returned values to see how many low order bits stay the same in many successive values. I am not sufficiently motivated, because I know the hardware engineers and can ask them whatever I need to know about it. If you really need monotonic behavior (but not uniqueness within the partition), you would get better precision and possibly better performance by issuing STCKF and then looping issuing STCKF until you get a different value than the first STCKF, and then using that final value. My rule is, if your just want to know what time it is, use STCKF or STCKE. Use STCK only if you require a unique value within the partition to use as a token, or you require monotonic behavior and don't care about the delays and lower precision. As to the precision of the clock itself, and STCKF, Principles of Operation says: " For STORE CLOCK FAST, when the value of a running clock is stored, bits to the right of the rightmost bit that is incremented are stored as zeros." In a dump, you can do SYSTRACE ALL and look at the unformatted time stamp (which is like an STCKF value) to see how many of the low order bits are always 0. On a z16, I see DEB714CB848F3C82 DEB714CB848F4A42 DEB714CB848F52A2 DEB714CB848F563A DEB714CB848F691A DEB714CB848F6A68 DEB714CB848F7174 DEB714CB848F761A DEB714CB848F867A DEB714CB848F8904 DEB714CB848F8A88 DEB714CB848F8B96 DEB714CB848F975A DEB714CB848FA078 DEB714CB848FA7B4 DEB714CB848FAE50 DEB714CB848FB426 DEB714CB848FC078 DEB714CB848FC880 DEB714CB848FD06C DEB714CB848FD862 DEB714CB848FDA24 DEB714CB848FEA0A Only bit 63 is always zero in those entries, so I would infer that the precision of the clock and of STCK on z16 is bits 0-62 (i.e., 63 bits). Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Tuesday, February 27, 2024 5:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? On Sat, 24 Feb 2024 19:50:32 +, Jim Mulder wrote: >STCK, which inserts a processor related value in the low order bits to meet >the "unique with a partition" requirement. If there's not a simple answer, I'll take your word this is monotonic, Out of curiosity, what is the precision of STCK and how does it guarantee monotonic time? In other words, how does STCK distinguish between 10 STCK's on the same CPU in the same partition within 49 microseconds? Multiply 244 picoseconds (TOD bit 63) by 200 CPU IDs, STCK precision is 49 microseconds. With a 5Ghz Telum processor, single cycle instructions take 191 picoseconds which means a single CPU can potentially execute 256 instructions during that 49 microsecond timeframe. ---
Re: Nanosecond resolution timestamps for HLL's?
I would say that STCKF is less "approximate" than STCK, since STCKF can have more low order bits of time from the clock than STCK, which inserts a processor related value in the low order bits to meet the "unique with a partition" requirement. STCKF is fine for measure time deltas as long as a delta of 0 is acceptable. z/OS routinely uses STCKF for this purpose. You won't observe time flowing backward from two STCKFs on the same logical processor or the same z/OS work unit. Jim Mulder -Original Message- From: Alan Altmark Sent: Saturday, February 24, 2024 1:48 AM To: ibm-main@listserv.ua.edu Subject: Re: Nanosecond resolution timestamps for HLL's? On Thu, 22 Feb 2024 01:08:55 -0600, Jon Perryman wrote: >Real-time clocks are not monotonical. Regardless of vendor, there is 1 >real-time clock shared by all CPU cores. There is indeed one hardware clock, but it's not visible to the partitions. The "system TOD clock" is what the partitions see, and it is architecturally defined to be monotonically increasing, never going backward and never being the same. Any two executions of STORE CLOCK (STCK or STCKE) on any processor in the partition, same or different, will always result in different clock values, and subsequent executions will result in values that are greater than either of the two prior values. STORE CLOCK FAST (STCKF) guarantees no such relationship, and time may appear to flow backwards. (So it's only useful when "approximately" is good enough.) See Chapter 4 of the PoP, "Setting and Inspecting the Clock". There's a table that I think you will find helpful. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Nanosecond resolution timestamps for HLL's?
What follows is model dependent behavior, not architecture. These instructions are implemented in hardware, so any STCK delaying is done there, not in millicode. Monotonic increasing on a processor is done by delaying, when two STCKs are issued too close together on the same processor. Uniqueness across processors is achieved for STCK and STCKE by storing a processor related value in the low order bits of the resultant timestamp. The method for determining the processor related value is model and configuration dependent. Line up all the CPUs abreast and issue STCKE (or STCK) simultaneously does not exhibit any delay. However, if you try to infer the execution order of the instructions on the various processors by comparing the entire stored timestamps, you will be misleading yourself. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Monday, February 19, 2024 11:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Nanosecond resolution timestamps for HLL's? On Mon, 19 Feb 2024 21:54:56 -0600, Charles Mills wrote: >... your program or some other unrelated program -- has recently issued an > STCK and your program must spin, consuming CPU cycles, until a unique STCK > ... > >OTOH, if you do need a monotonic value, then you should redesign and recode to >use STCKE. > STCKE is faster than STCK because its granularity if finer and doesn't need to spin as long. How many instructions could have been issued during such a (microcode) STCKE spin? I know, it's model dependent. And a mischievous programmer could contrive to line up all the CPUs abreast and issue STCKE simultaneously to exhibit the worst case. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes
https://www.ibm.com/docs/en/zos/3.1.0?topic=reference-mount-command Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: Thursday, February 1, 2024 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Antiquarian Curiosity: Pre-MVS/XA Mount Command for DASD Volumes Before MVS/XA and RAID DASD, offline DASD volumes (e.g. 3330, 3350 & 3380 units) had to be mounted instead of simply being varied online. The mount command used the volser of the offline DASD volume as a parameter. Does anyone remember the format of the mount command? Does anyone have the documentation in .pdf format? -- 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: Data space dump with SDUMPX
What is displayed by this IPCS command for your dump?
CBF RTCT
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Schühle, Simon
Sent: Thursday, February 1, 2024 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Data space dump with SDUMPX
So, just some additional details.
My DUMP Command would look like this:
DUMP COMM=(DSPTST),DSPNAME=('*'.1EDB),SDATA=(SUM,CSA,RGN),END
Compared to the SDUMPX code I posted earlier, it's basically the same.
But with DUMP I get the following result in the dump:
ASID(X'0092') DSPNAME(1EDB)
40.:7F.
X'40' bytes described in ASID(X'0092') DSPNAME(1EDB)
ASID(X'0094') DSPNAME(1EDB)
40.:437FFF.
X'038000' bytes described in ASID(X'0094') DSPNAME(1EDB)
ASID(X'009C') DSPNAME(1EDB)
00.:0FFF., 10.:7F.
X'701000' bytes described in ASID(X'009C') DSPNAME(1EDB)
The last one is the one I want and the one that isn't included when using
SDUMPX.
Am 01/02/2024 um 12:11 schrieb Schühle, Simon:
> Well, this does result in none of the data spaces I am looking for
> showing up in the dump.
> Many others show up, so I suspect that the limit for the amount of
> dumped data spaces was reached before.
>
> But also, when using the DUMP command, the correct data space is
> included in the dump.
> Wouldn't that suggest, that the data space is in memory?
> Or is it handled differently compared to SDUMPX?
>
> Thank you,
> Simon
>
> Am 01/02/2024 um 09:17 schrieb Binyamin Dissen:
>> This seems to suggest that the dataspace name does not exist under this
>> memory.
>>
>> Try specifying your jobname and "*" for the dataspace name. See what
>> comes
>> out.
>>
>> On Wed, 31 Jan 2024 13:23:33 +0100 Schühle, Simon
>> wrote:
>>
>> :>Ok, LDMP is what I used until now to check the dump contents. So
>> that's
>> :>good.
>> :>It shows the correct DSPNAME/data space, but only for the other
>> :>instances/address spaces. As well as some system-related ones.
>> :>But nothing except 'normal' memory for the primary AS (X'7C' in the
>> :>following case) - for example:
>> :>
>> :>--
>> :>X'1E6B7000' bytes described in ASID(X'007C')
>> :>[...]
>> :>ASID(X'0092') DSPNAME(1EDB)
>> :> 40.:7F.
>> :>X'40' bytes described in ASID(X'0092') DSPNAME(1EDB)
>> :>
>> :>ASID(X'0094') DSPNAME(1EDB)
>> :> 40.:437FFF.
>> :>X'038000' bytes described in ASID(X'0094') DSPNAME(1EDB)
>> :>[...]
>> :>X'05E000' bytes described in ASID(X'007C') SUMDUMP
>> :>--
>> :>
>> :>
>> :>This is my code:
>> :>
>> :>--
>> :>MVI WADMPTIT,STOPMSG$ SETUP L'TITLE
>> :>MVC WADMPTIT+1(STOPMSG$),STOPMSG
>> :>MVC WASDUMPX(STOPSDM$),STOPSDMP
>> :>LA R2,WADMPECB
>> :>
>> :>SDUMPX HDRAD=WADMPTIT,ECB=(R2),MF=(E,WASDUMPX),TYPE=FAILRC, +
>> :> SDATA=(SUMDUMP,CSA,RGN), +
>> :> DSPLIST=DSPLST1
>> :>
>> :>STIMER WAIT,BINTVL=INT101 WAIT 1S
>> :>
>> :>[...]
>> :>
>> :>DSPLST1 DC AL4(DLLEN1)
>> :> DC CL8'* '
>> :> DC CL8'1EDB'
>> :>DLLEN1 EQU *-DSPLST1
>> :>
>> :>[...]
>> :>
>> :>STOPSDMP SDUMPX HDRAD=*,MF=L,TYPE=FAILRC,
>> :> SDATA=(SUMDUMP,CSA,RGN),
>> :> DSPLIST=DSPLST1
>> :>STOPSDM$ EQU *-STOPSDMP
>> :>
>> :>[...]
>> :>
>> :>WADMPECB DS F
>> :>WADMPTIT DS X
>> :>WADMPMSG DS CL100
>> :>WASDUMPX DS 0F
>> :> ORG *+STOPSDM$
>> :>--
>> :>
>> :>Kind regards,
>> :>Simon
>> :>
>> :>--
>> :>For IBM-MAIN subscribe / signoff / archive access instructions,
>> :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> Binyamin Dissen
>> http://www.dissensoftware.com
>>
>> Director, Dissen Software, Bar & Grill - Israel
>>
>> --
>> 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
--
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: Regarding RBINTCOD
If the issuer of ESTAE(X) was system key (0-7), the SDWA is obtained from subpool 230 (high private, not subject to the region limit). For user key, the SDWA is obtained from subpool 0 (low private, subject to the region limit), so R0=12 is more likely for this case, Especially if the abend being handled is due to region exhaustion. There is no 1M between 2047M and 2048M, since both of those values are considerably higher than what could ever be available, after you subtract the 16M that is below 16M, and whatever is the size of ENUC+ELPA+ECSA+ESQA. No limits are bypassed, and currently, nothing is reserved. I have been recently working on implementing on an idea I had 20 years ago to maintain a minimum area between the current top of low private and the current bottom of high private, so that low private cannot go into this area, and if high private intrudes more than halfway into this area, VSM initiates a cancel of the job. That would help to reduce 40D-10 abnormal memterms when RTM2 can't get storage below 16M for the IHARMPL, and reduce situations where we can't obtain an SDWA for a system key ESTAE(X). It would also help with the situation that Seymour Metz mentions now and then, that anyone can easily memterm an initiator by running a simple program that SYNCHes to itself infinitely (since that will exhaust private storage below 16M with PRBs). For example, this is what happens currently: CMN JOB00022 IEF403I SYNCHSLF - STARTED - TIME=03.15.45 CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.49 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = YES CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=002 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=COMPID=SC1CJ,COMPON=CONTENTS SUPERVISOR,ISSUER=CSVFR R,878-000C IN IGVVSERR+0F82. INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.50 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = NO *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP30 *DUMPID=002 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:49 * ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 *ID = SC1CJ:878-000C IN IGVVSERR+0F82. CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=003 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=ABEND=40D,RC=10,COMPON=RTM2,COMPID=SCRTM,ISSUER=IEAV TRT2,MEMTERM - UNRECOVERABLE ABEND FAILURE INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEF402I INIT FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 CMN IEF402I SYNCHSLF FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP31 *DUMPID=003 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:50 CMN JOB00022 $HASP310 SYNCHSLF TERMINATED AT END OF MEMORY CMN STC4 $HASP310 INIT TERMINATED AT END OF MEMORY CMN STC00023 IEF403I INIT - STARTED - TIME=03.15.56 But with a minimum area of 50K below 16M, and 1M above 16M, CMN JOB00024 IEF403I SYNCHSLF - STARTED - TIME=03.19.21 CMN JOB00024 IEF450I SYNCHSLF SYNCHSLF - ABEND=S822 U REASON=0004 TIME=03.19.26 CMN JOB00024 IEF404I SYNCHSLF - ENDED - TIME=03.19.26. So maybe that will get into the next release after z/OS 3.1. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sen
Re: IPCS - CBFORMAT
You can make each model an entry point in the module, with an ALIAS for each
one when you bind the module.
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Bill Yeager
Sent: Wednesday, January 24, 2024 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Jim,
Just one more question, if you please...
I'd like to put a bunch of CB mappings in one module if it's possible. The
manual was totally unclear as to whether this is possible and, if so, how to do
it.
Do you know?
Thanks,
Bill
Bill Yeager, CTO
Alebra Technologies, Inc.
PO Box 120390
New Brighton, MN 55112
678-232-3270
This e-mail, including attachments, may include confidential and/or proprietary
information and may be used only by the person or entity to which it is
addressed. If the reader of this email is not the intended recipient, or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jim Mulder
Sent: Tuesday, January 23, 2024 11:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
> ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC
> BLSQMDEF END
>
>2B79E814 D6D7D9D4 E6D9E3C5 D9D9C5D8 | OPRMWRTERREQ |
>2B79E820 E6D9E3C5 D9C5C1C4 | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814
> + EYEC. OPRM
>Control block is truncated
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---
Re: IPCS - CBFORMAT
Try CBF 2B79E814. L(12) STRUCTURE(OPRM)
The Truncated message is telling you that the OPRM model is trying to format
something longer that what is provided.
Since you only specified an address (not a symbol which has a length), the
length would be defaulting to whatever your SETDEF command default length is
(4, if you haven't changed it via the SETRDEF subcommand).
You could also do things like
EQ MYOPRM 2B79E814. L(12) STR(OPRM)
CBF MYOPRM
For your other thing that does work, if it is longer than 4 bytes, maybe IPCS
knows something else about it which determines a length.
IPCSDATA ACTIVE will show you all of the parmlib stuff for your IPCS session.
The LISTMAP subcommand will also tell you about things that IPCS has already
figured out and put into its storage map.
What is the structure name that does work? Where does it show up in the output
of IPCSDATA ACTIVE ?
Does the structure name show up in the output of LISTMAP, or is the address in
an a range that shows as being mapped in the output of LISTMAP?
Jim Mulder
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Jon
Perryman
Sent: Tuesday, January 23, 2024 9:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS - CBFORMAT
This looks correct and essentially the same as mine. I never ran into the
truncated error. I'm guessing the problem must lie somewhere else.
Since ACRONYM= is working, it's unlikely that a spurious blank is causing the
problem. Maybe compare the assembler listings to see if there is a difference.
I think I accessed my IPCS modules thru BLSLLIB or possibly TSOLIB to eliminate
problems associated with linklst. I don't think this is your problem..
I would look at the link listing and verify the entry point and module name is
correct. I don't think this is the problem because HEADER= is working correctly.
Although you didn't include the full source, It appears the CSECT is setup
correctly and nothing spurious seems to be included but maybe you can check the
listing for something unexpected.
I don't think using CBLEN=20 will fix the problem but you could try it.
Sorry I can't be of help but your problem doesn't appear to be with the
definitions.
On Tue, 23 Jan 2024 14:26:20 -0600, Bill Yeager wrote:
>OPRM DSECT
>OPRMEYEC DSCL4EYECATCHER ('OPRM') @E120
>OPRMIFUN DSCL4I/O FUNCTION TO BE PERFORMED
>OPRMCFUN DSCL4COMM FUNCTION TO BE PERFORMED
>
> BLSQMDEF BASELBL=OPRM,CBLEN=12,PREFIX=4,HEADER=OPRM, X
> ACRONYM=OPRM,ACROLBL=OPRMEYEC
> BLSQMFLD NAME=OPRMEYEC,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMIFUN,DTYPE=EBCDIC
> BLSQMFLD NAME=OPRMCFUN,DTYPE=EBCDIC
> BLSQMDEF END
>
>2B79E814 D6D7D9D4 E6D9E3C5 D9D9C5D8 | OPRMWRTERREQ |
>2B79E820 E6D9E3C5 D9C5C1C4 | WRTEREAD |
>
>Command: CBF 2B79E814. STRUCTURE(OPRM)
>
>OPRM: 2B79E814
> + EYEC. OPRM
>Control block is truncated
>
>--
>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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question on SSRV entries in system trace table
We don't want to waste the time and space. The caller information is in the preceding PC trace entry. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Shaw Sent: Wednesday, January 10, 2024 5:39 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question on SSRV entries in system trace table Anyone, The doc on SSRV trace table entries in the "z/OS MVS Diagnosis: Tools and Service Aids" pub says this: PSW- ADDRESS-return--: o For PC/AUTH, supervisor control, and task management: Caller's return address if the service was entered by a branch; 0 if the service was entered by a PC instruction In a dump I see that a specific IARV64 REQUEST=GETSTOR macro invocation generates a PC instruction and there is no PSW information in that trace table entry. Ok. The doc is correct. Does anyone know WHY there is no PSW saved in SSRV trace entries for non-branch-entry system service calls? It makes diagnosis of errors more difficult... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. -- 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: Suspend/Resume for Paging
No, that was removed in in 2006 by APAR OA14248 (HyperPAV support). Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Wednesday, November 15, 2023 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Suspend/Resume for Paging Does z/OS still use this for I/O to its paging devices? Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Heads up: z/os 3.1 WAIT 006 under z/VM + DS6800 question
The Validated Boot enhancements to z/OS made a change to a channel program that we use to build the nucleus. The changed channel program is used regardless of whether you are doing a validated boot or not. z/VM minidisk caching screws up while emulating the channel program. Last I talked to the z/VM developers, they still had not figured out what the bug is. As long as minidisk caching (MDC) is turned off for at least the z/OS IPL device minidisk, the channel program will be executed by the I/O subsystem, which executes it correctly. The problem only occurs when you are IPLing z/OS from a minidisk to which you have LINKed (or is in your VM directory), with MDC enabled for that minidisk. If you instead ATTACH the device to the VM user, the problem will also not occur, since it is not being treated as a minidisk in that case. The type of processor or DASD controller is not relevant to the problem. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Keith Gooding Sent: Tuesday, October 24, 2023 1:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Heads up: z/os 3.1 WAIT 006 under z/VM + DS6800 question It was z/VM 7.2 (still in support) but the APAR states that the problem affects all z/VM releases. > On 24 Oct 2023, at 18:33, Art Zeigler wrote: > > What relase of z/VM did you receive the Wait 006? > > Thanks > > Art Zeigler > > > From: IBM Mainframe Discussion List on > behalf of Keith Gooding > <034af3894af4-dmarc-requ...@listserv.ua.edu> > Sent: Tuesday, October 24, 2023 1:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Heads up: z/os 3.1 WAIT 006 under z/VM + DS6800 question > > For my first z/OS 3.1 IPL (under z/VM) I got WAIT 006. After a long search I > found z/VM APAR VM66721: Z/OS GUEST IPLS FAIL AFTER APPLYING UJ92591/UJ92728. > There is no PTF as yet but there is a work-around (turn off mini-disk > caching). > > Those PTFa are the validated boot PTFs for z/OS 2.5 - the function is > incorporated into z/os 3.1. > > I have no idea why the failure occurs but I thought maybe z/os is using some > I/o command sequence which z/Vm does not support properly. That got me > worrying about whether z/OS 3.1 (or 2.5 with the validated boot PTFs) will > work on old hardware, specifically DS6800 which we have at a backup site. Our > 3.1 test under z/Vm used DS8884. > > Has anyone tried running 3.1 (or 2.5 with the validated boot PTFs), or have > any understanding of why an IPL may fail on DS6800 ?. We are not using > validated boot and have no intention of doing so. > > Keith > > -- > 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 -- 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: What is in SVCDUMP RTCT
VERBX IEAVTSFS displays the partial dump reason code bits for the SDUMP capture phase. If the dump is partial due to an error or running out of space during the write phase, you would need the syslog to see that. VERBX SUMDUMP displays the ranges that were captured during the summary dump. LISTDUMP with appropriate options can be used to display all of the ranges that were dumped. WHERE is useful for addresses in the Nucleus, LPA, and job pack queue modules. It also identifies control blocks that something else has already put into the IPCS storage map. And it displays some VSM attributes for allocated storage in private area non-LSQA subpools. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Monday, October 16, 2023 5:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What is in SVCDUMP RTCT I can't remember how I determined partial dumps from the dump. When customers supplied syslog, I looked for complete / incomplete dump message. I think SUMDUMP is closer to what Joeseph wants. If I remember correctly, It displays the storage ranges that are dumped. I can't remember if partial dumps or unallocated storage affected this list. VSMDATA might be helpful. Besides telling you the storage is allocated, you can determine which SDATA options might be missing (e.g. CSA, SQA, ...). I rarely used WHERE. I don't know if it gives you useful information when storage is missing from the dump. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What is in SVCDUMP RTCT
Under IPCS, to see the effective SDUMP parms for the dump (which is a composition of what was requested on the SDUMP(X) macro plus application of CD commands (as displayed by D D,O )), use STATUS WORKSHEET. The formatted SDUMP parm list is near the bottom of the display. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Monday, October 16, 2023 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What is in SVCDUMP RTCT Sorry didn’t include this in the first email But in the second dump when I dumped CSA the bit setting for CSA in the RTCT was off however I was able to access jesssct Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Given an SVC DUMP is SRB mo0de, how can one find the DUCT?
An SRB is initially dispatched with the home address space's Basic Access List, which is in ELSQA. If you subsequently ALESERV ADD something, then a new access list is obtained from a pool in ESQA. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Binyamin Dissen Sent: Tuesday, September 26, 2023 2:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Given an SVC DUMP is SRB mo0de, how can one find the DUCT? On Sat, 23 Sep 2023 13:20:46 + Peter Relson wrote: :>As Joe R mentioned, the DUCT virtual address for a (running) SRB is in the LCCA, specifically LCCASDUV. Thanks to both of you. :> :>IPCS does not allow access to the real address in CR2. :> :>That would surprise me. :> :>which address binds the DU has :> :>What specifically do you mean by "address binds"? :>Are you referring to finding what entries there are on the SRB's dispatchable unit access list? Yep. It don't see an obvious virtual DUALD pointer. Is this even in home addressable storage? -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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: Equivalent of TSOLIB for batch
Yes, TSOLIB is part of TSO/E and is correctly implemented by ATTACHing subsequent commands with a TASKLIB. The TSO/E developer who was designing TSOLIB wanted to do an incorrect, dangerous thing like STEPLIB did, so that he could provide equivalent function to STEPLIB. Peter Relson, Karl Schmitz, and I did not allow him to do that. STEPLIB was created by Art Breslau, who worked for IBM, but not in the MVS or TSO development organization. STEPLIB may have been an FDP (Field Developed Program). Mr. Breslau had a bit of a bad reputation with our development organization because of the unsupported and dangerous things that he did in his "products". Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Marchant Sent: Wednesday, July 19, 2023 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Equivalent of TSOLIB for batch Peter, I'm a little over my head on this, but isn't TSOLIB in TSO implemented with TASKLIB on ATTACH? -- Tom Marchant On Wed, 19 Jul 2023 12:04:12 +, Peter Relson wrote: >Scary stuff being asked about. Certainly there is nothing that is supported >(and that likely includes whatever TSOLIB does and whatever is on the CBT >tape), and nothing that won't put your customer at risk (including possibly >introducing system integrity problems). > >TASKLIB on ATTACH is the only supported way to influence the search order for >the system module fetch interfaces such as LINK, LOAD, ATTACH, and XCTL, aside >from providing a DCB on those interfaces. -- 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: What happened to GC26-1672 Batch Local Shared Resource(LSR) Documentation?
That is probably the most recent documentation. I doubt that anything has been done since I posted this on IBM-MAIN on Sep 12, 2012: > Thanks! I'd already read the book and noted that Dynamic SSI came after > BLSR. And so the BLSR book might not have been updated. I am pretty sure that I submitted a request about 15 years ago to update the next edition of the Batch LSR manual to say that SETSSI can be used to active Batch LSR. But it would appear that there hasn't been a subsequent edition of that book. (So my request may still be pending somewhere). Jim Mulder Batch LSR Developer IBM Corp. Poughkeepsie, NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Pommier, Rex Sent: Thursday, July 6, 2023 3:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: What happened to GC26-1672 Batch Local Shared Resource(LSR) Documentation? Ehhh, I just found my "current" BLSR documentation. GC28-1469 that somebody already pointed out, MVS/ESA 5.1, June 1994. Guess the old brain cells are getting foggier than I thought they were. Rex -Original Message- From: Pommier, Rex Sent: Thursday, July 6, 2023 2:19 PM To: 'IBM Mainframe Discussion List' Subject: RE: [EXTERNAL] Re: What happened to GC26-1672 Batch Local Shared Resource(LSR) Documentation? I activated BLSR at *current job* a few years back. I had used it very successfully at prior jobs but nobody here had heard of it. I convinced a couple of the application teams to try it on some heavy hitters and they were astonished at the difference. At the time I activated it I thought I had found a relatively current manual on it but for the life of me I can't find it now. :-( Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXT] Re: Counting EXIT invocations
For completeness, I will mention a couple of easy ways to count using a SLIP IF on the entry point of the exit routine. 1. ID=,ML=65535 Then use D SLIP= to see the number of matches. 2. Use the A=AEXIT,AEXIT=IEAVTSZE as documented under the SLIP command for ZAD traps. While this was designed and documented for use with ZAD, it can be useful for counting any type of PER SLIP trap (ZAD,IF,SA,SBT,SK). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of jgmauta...@yahoo.com.ar Sent: Thursday, June 29, 2023 9:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXT] Re: Counting EXIT invocations Thanks you guys. Pretty interesting and technical options were exposed. However, in this particular case (ICHPWX01 - RACF New-password Exit), it is not worth the effort. I just want to know how heavily executed it is. Given the fact that it is invoked just for the following 3 events: -RACF ALTUSER command (with PASSWORD keyword).-RACF PASSWORD command (with PASSWORD or INTERVAL keyword).-RACINIT REQUEST=VERIFY (with NEW Password specified). I can have an estimation of ICHPWX01 executions by just counting these 3 events that cause it to be called. And these events generate SMF type 80 records, so I can go that way. Thanks, Juan Mautalen El jueves, 29 de junio de 2023, 09:53:04 a. m. GMT-3, Crawford Robert C (Contractor) <04e08f385650-dmarc-requ...@listserv.ua.edu> escribió: Are you talking about the EXIT macro? You might be able to use a SLIP trap to count the invocations. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Thursday, June 29, 2023 3:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXT] Re: Counting EXIT invocations On Wed, 28 Jun 2023 at 19:28, Colin Paice wrote: > > Allocate a block of 8 bytes in common memory. Use name token to point > to it. Use Compare double and swap to update value. every 1000 > entries reset to zero and write out Or use Add Immediate (ASI/AGSI) instead, which is interlocked unless you have quite an old machine and probably performs better than CDS. But even if you do have a machine without the interlock, it's unlikely your update will actually clash, and even if it does your count will probably be off by only 1. Would it matter? You're not adding to the balance in a bank account. Tony H. > On Wed, 28 Jun 2023 at 15:49, Seymour J Metz wrote: > > > If the exit serializes access to the N/T pair then there should be > > no lost data. > > > > > > From: IBM Mainframe Discussion List on > > behalf of Colin Paice > > Sent: Wednesday, June 28, 2023 10:41 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Counting EXIT invocations > > > > Having a WTO depends on how many exit calls there are per second. > > 100 a second might cause a problem. > > > > Depending on where your exit runs, and what state it is in, a system > > level name token pair might be a good compromise. > > On first use - allocate a name token, set use count = 0; do a STCK > > and add > > 10 minutes - and store it in name token. > > on every other call > > > > - increment counter > > - If stck(now) > the stored STCK > > - calculate the time delta - and WTO out # seconds and count > > - store now + 10 minutes in the name token. > > > > The time between WTOs may be > 10 minutes but it gives you a > > flavour of the count. You might lose the odd entry if two TSBs are > > trying to update concurrently. > > > > Or do the WTO every 1000 calls. > > > > On Wed, 28 Jun 2023 at 15:10, Jousma, David < > > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > > > Best option would be to have the exit issue a WTO, and then scan > > > operlog for that. > > > > > > Dave Jousma > > > Vice President | Director, Technology Engineering > > > > > > > > > > > > > > > > > > From: IBM Mainframe Discussion List on > > > behalf of jgmauta...@yahoo.com.ar < > > 01f9499d67db-dmarc-requ...@listserv.ua.edu > > > > > > > Date: Wednesday, June 28, 2023 at 9:21 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Counting EXIT invocations Hi! We have recently > > > implemented a RACF exit. Is there a way to know how many times > > > this EXIT was executed (on a given period of time)? Thanks in > > > advance for your help, Juan Mautalen > > > --
Re: Why does ISPF BROWSE abend with S878 searching a large sequential file?
I would set a SLIP and take a dump of the 878 abend, and then look to see what is consuming the storage. If this is an extended format compressed sequential data set, and if Browse uses BSAM to read the data set, it might be due to NOTE/POINT compression tables, We had a problem with the GTF/CTRACE external writer running out of storage while writing to very large extended format compressed data sets. I see that I added the following code in z/OS 2.5 to alleviate that: /***/ /* */ /* Our model DCB had MACRF=WP. Since we do not*/ /* do wrapping for extended format data sets, */ /* we do not use NOTE or POINT. We do not */ /* want BSAM to waste space creating */ /* NOTE/POINT compression tables if the data */ /* set is compressed, so we turn off DCBMRPT1, */ /* which is as if we had specified MACRF=W.*/ /* @L7A*/ /***/ IF (OBTAINsucceeded & DS1STRP) /* If OBTAIN succeeded and it is an extended format data set @L7A*/ | TWCB_NonWrap_Mode THEN /* Or NOWRAP was specified @L7A*/ DCBMRPT2 = False; /* Indicate no NOTE/POINT @L7A*/ Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, May 23, 2023 5:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential file? Possibly. But if so we are in a lot more trouble than annoying abends out of TSO, as this is customer data with legal archiving requirements. If it is somehow corrupted by compression (not sure at this point if that file is using IBM software compression or zEDC hardware compression) we have MUCH larger issues. IMHO it is probably just BAD (broken as designed) BROWSE code, but with OCO there is no way for an ordinary customer to know. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Tuesday, May 23, 2023 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Why does ISPF BROWSE abend with S878 searching a large sequential file? EXTERNAL EMAIL I agree that Browse isn't supposed to require enough memory to hold the file, so it should work. But. Is "compressed data" the key? How is it compressed? Does the fact that it is compressed mean that more data has to be in memory? Or is it going wild on decompression, such as if the data is corrupted so the length is wrong? (Like how it is possible to create a tiny .ZIP file that decompresses to terabytes.) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter Sent: Tuesday, May 23, 2023 3:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Why does ISPF BROWSE abend with S878 searching a large sequential file? This has happened to me twice this afternoon, and several other times in the last few months - I am trying to browse (from ISPF 3.4) a quite large sequential file (> 14500 cylinders of compressed data) for a record with a specific 31-byte key at the beginning of the record, and browse abends with S878 and throws me off TSO entirely, requiring me to login again each time. My TSO logon region size is set to 48000, so what in the world is making browse consume so much memory that it runs out and crashes my TSO session entirely? I know, OCO prevents anyone knowing for sure, but if you have any clue I'd appreciate knowing the answer. I've been forced to search that file using SORT in a batch job to keep the frustration level lower. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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 This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or
Re: IPCS formatting of I/O control blocks
NIOBA 000C964C NECB 7F00 +0 FLAG1 0200SENS ECBPT 7F0D6EA4 CSW 000C9634 0C00 +10START 000C962CDCBPT 000AEA40RESTR INCAM SEEK 098A +28 060B7000 6180 0D6EA4 DECB: ECB 7F00 FLAGS 000D3000DCB 1D551F04 AREA C9C5C1E5 STATUS E7C3C6C5 ***IOB 18 AT LOCATION 0C9654(SAM, BPAM - NORMAL SCHEDULING) CE DE -10VIDAN LENRD NIOBA 000C969C NECB 7F00 +0 FLAG1 0200SENS ECBPT 7F0D6EA4 CSW 000C9684 0C00 +10START 000C967CDCBPT 000AEA40RESTR INCAM SEEK 098A +28 060B7000 6180 0D6EA4 DECB: ECB 7F00 FLAGS 000D3000DCB 1D551F04 AREA C9C5C1E5 STATUS E7C3C6C5 ***IOB 19 AT LOCATION 0C96A4(SAM, BPAM - NORMAL SCHEDULING) CE DE -10VIDAN LENRD NIOBA 000C96EC NECB 7F00 +0 FLAG1 0200SENS ECBPT 7F0D6EA4 CSW 000C96D4 0C00 +10START 000C96CCDCBPT 000AEA40RESTR INCAM SEEK 098A +28 060B7000 6180 0D6EA4 DECB: ECB 7F00 FLAGS 000D3000DCB 1D551F04 AREA C9C5C1E5 STATUS E7C3C6C5 ***IOB 20 AT LOCATION 0C96F4(SAM, BPAM - NORMAL SCHEDULING) CE DE -10VIDAN LENRD NIOBA 000C90FC NECB 7F00 +0 FLAG1 0200SENS ECBPT 7F0D6EA4 CSW 000C9724 0C00 +10START 000C971CDCBPT 000AEA40RESTR INCAM SEEK 098A +28 060B7000 6180 0D6EA4 DECB: ECB 7F00 FLAGS 000D3000DCB 1D551F04 AREA C9C5C1E5 STATUS E7C3C6C5 ***IOB 1 AT LOCATION 0C9104 (SAM, BPAM - NORMAL SCHEDULING) CE DE -10VIDAN LENRD NIOBA 010C914C NECB 7F00 +0 FLAG1 0200SENS ECBPT 7F0D6EA4 CSW 000C9134 0C00 +10START 000C912CDCBPT 000AEA40RESTR INCAM SEEK 098A +28 060B7000 6180 0D6EA4 DECB: ECB 7F00 FLAGS 000D3000DCB 1D551F04 AREA C9C5C1E5 STATUS E7C3C6C5 Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, April 27, 2023 2:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS formatting of I/O control blocks I see TIOT (does that include XTIOT?) but not DCB, DECB or IOB, and I would have expected any new support for them to be via VERBEXIT. Do you have a sample output? Thanks. From: IBM Mainframe Discussion List on behalf of Jim Mulder Sent: Thursday, April 27, 2023 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IPCS formatting of I/O control blocks Yes, Wayne Rhoten enhanced that a while back. I don't remember which release of z/OS, but I have gotten accustomed to seeing it in the output from the SUMMARY FORMAT subcommand. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, April 27, 2023 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS formatting of I/O control blocks The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that changed? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS formatting of I/O control blocks
Yes, Wayne Rhoten enhanced that a while back. I don't remember which release of z/OS, but I have gotten accustomed to seeing it in the output from the SUMMARY FORMAT subcommand. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, April 27, 2023 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS formatting of I/O control blocks The last time I looked, IPCS did not format, e.g., DCB, DECB, IOB. Has that changed? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cant SPKA to PSW Key 4
I have never used IDF. When I want to trace through authorized code, I run z/OS under z/VM and use the TRACE command. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, February 26, 2023 5:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cant SPKA to PSW Key 4 Jim How about IDF or tool debug I have been trying to get IDF running so I can debug code running in key 4 but if you say I’m wasting my time ? > On Feb 26, 2023, at 5:18 PM, Jim Mulder wrote: > > They do not support whatever is in TCBPKF. I have seen code in TSO > which has hardcoded x'80'. > > Jim Mulder > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Ed Jaffe > Sent: Saturday, February 25, 2023 9:50 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cant SPKA to PSW Key 4 > >> On 2/23/2023 6:46 PM, Joseph Reichman wrote: >> I am trying to change psw storage key from "Normal" key 8 to Key 4 >> >> SPKA X'40' >> >> I have bit 15 of the psw 0 ,meaning I am in supervisor state and get >> a >> s0c1 running this code under TESTAUTH >> >> I am able to get to PSW key 0 SPKA 0 >> >> Don't get it > > ISTR discovering empirically 30+ years ago that TSO/E TEST and TESTAUTH > support only two execution keys: X'80' and X'00'. > > I wondered if in-fact they actually support whatever key is in TCBPKF and > X'00' but never experimented to see if that was the case. > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cant SPKA to PSW Key 4
They do not support whatever is in TCBPKF. I have seen code in TSO which has hardcoded x'80'. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Saturday, February 25, 2023 9:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cant SPKA to PSW Key 4 On 2/23/2023 6:46 PM, Joseph Reichman wrote: > I am trying to change psw storage key from "Normal" key 8 to Key 4 > > SPKA X'40' > > I have bit 15 of the psw 0 ,meaning I am in supervisor state and get a > s0c1 running this code under TESTAUTH > > I am able to get to PSW key 0 SPKA 0 > > Don't get it ISTR discovering empirically 30+ years ago that TSO/E TEST and TESTAUTH support only two execution keys: X'80' and X'00'. I wondered if in-fact they actually support whatever key is in TCBPKF and X'00' but never experimented to see if that was the case. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beware IBM PTF UJ09197 (APAR OA63062)
We hit that as well last week on our test systems. UJ09197 has been marked PE, and APAR OA64137 has been opened. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Jaffe Sent: Sunday, January 15, 2023 12:22 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Beware IBM PTF UJ09197 (APAR OA63062) IBM-MAINaholics, Our HSM maintenance jobs failed this morning. The log was full of 0C4 abends pointing to offset +2B0 in TIOC LPA module IGC0009C. The failure appears related to TSO/E SEND command processing. PTF UJ09197 (APAR OA63062) updated IGC0009C yesterday morning via our weekly service APPLY. We backed out the PTF, re-IPLed the affected systems, re-ran the failing jobs, and now all is well... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: architecturally reusable address space
An architecturally reusable address space is one which has the Reusable-ASN Bit (RA) bit turned on in the ASN-Second-Table Entry (ASTE), as described in Principles of Operation. The z/OS considerations are documented here: https://www.ibm.com/docs/en/zos/2.5.0?topic=ra-coding-cross-memory-services-avoid-loss-asids-from-reuse Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of esst...@juno.com Sent: Sunday, January 15, 2023 8:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: architecturally reusable address space Hello, . In an old post "LX and ASN reuse" dated May 1, 2007 I beloeve jim Mulder wrote: "The z/OS 1.9 manuals will document the mechanism for creating an architecturally reusable address space under z/OS and the programming issues for making use of these address spaces, so that may make the picture a bit clearer (although since I wrote the documentation, it may not be clear at all" . I suspect "architecturally reusable address space" is much more than LX and ASN reuse. . What determines an "architecturally reusable address space" ? What is the criteria used to identify "architecturally reusable address space" ? What techniques and mechanisms are used ? . Is this published anywhere ? . Paul DAngelo -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question and CZAM and IPL
The IPL PSW provided by software is always 8 bytes. There is no provision for providing a 16 byte PSW. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Sunday, January 8, 2023 4:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question and CZAM and IPL When a z/arch machine has CZAM installed, is it possible to use a short PSW to IPL. Or, does the short PSW always become a long PSW before IPL, so it is better to use a long PSW to start with? In POPs, it says on page 3-75: "When the CZAM facility is installed, the IPL PSW has the short-PSW format, as shown in Figure 4-3 on page 4-8." But on page 4-8, it says: "Note: The term short PSW refers only to the eight-byte entity in storage. The actual PSW used by the CPU is the 16-byte register illustrated in Figure 4-2." Joe -- 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: dump command not fitting in console
Put the parms in an IEADMCxx parmlib member, and then issue DUMP PARMLIB=xx Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Tuesday, December 13, 2022 9:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: dump command not fitting in console we have a dump request from IBM but the command with all the parameters is not fitting in the console command line. any suggestions? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
On recent generations, the keys are kept in the memory units, and cached in the cache hierarchy. On some prior generations, keys were cached in the TLB. I don't remember offhand in which generation that changed. On the 3090 machines, I remember the engineers referring to separate key arrays. Around 1990, the 3090S and 3090J machines were experiencing a higher rate of uncorrectable storage key errors, so they started keeping a backup copy of the keys in HSA, and the MVS machine check handler was enhanced to use a Diagnose instruction interface to retrieve the backup copy in the case of a key error on those machines. For 24/31 bit address space non-SQA/LSQA virtual storage, VSM keeps track of the original storage key and provides that to RSM. RSM keeps track of what the current key should be in the DAT leaf entry (PTE, STE, or RTE). VSM is not made aware of key changes via the RSM CHANGKEY macro. VSM is not involved or consulted about keys when virtual storage gets backed in real storage. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Wednesday, November 23, 2022 8:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys I know this is super old information ... but given the discussion so far, it seems reasonable to at least apply the same concept ... "The storage-protect unit has a 64 x 8 monolithic storage protection stack that applies to main storage locations zero through 131,072 (in sequential blocks of 2,048 bytes). Additional stacks are provided in the CPU when main storage capacity extends from 131,072 bytes to 524,288 bytes. Above 524,288 bytes, storage protect is located in the Power Frame (03) and is a mix of 64 x 8 and 64 x 18 monolithic storage cards." http://www.bitsavers.org/pdf/ibm/370/fe/3145/SY24-3581-4_3145_Processor_Theory_Maintenance.pdf Joe On Wed, Nov 23, 2022 at 6:56 AM Jay Maynard wrote: > Well, you have to store the key *somewhere* when the page is paged > out. But you're right, the page table entry isn't it. I don't know > what I was thinking. > > I'm sure that VSM maintains its own table of correspondence between > virtual storage addresses and storage key, so the key can be applied > to the page upon page-in, but I don't know the details. > > On Wed, Nov 23, 2022 at 4:12 AM Ian Worthington < > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > > > Many thanks for that Jay. This would certainly seem the logical > > place to store it. > > > > I'm still a bit confused though. The pop section on Page-Table > > Entries (page 3-51 in the 13th edition...) does not mention this > > (though it does have a unused byte at the end). If the intention is > > to make the storage key unaddressable (p 3-9) and alterable only via > > SSKE (which, given the need to propagate it to the caches of all > > processers would seem make > sense) > > would it not be contraindicated to use this byte to keep it in? > > > > I'd love to see a paper or article which discusses how this is done, > > though, like cpu design, I appreciate it may well change from model > > to model. > > > > > > Best wishes > > > > Ian ... > > > > On Tuesday, November 22, 2022 at 05:28:37 PM GMT+1, Jay Maynard > > < jaymayn...@gmail.com> wrote: > > > > They are held in the page tables and set in the hardware - in extra > memory > > that is not software accessible except through a few > > supervisor-level instructions such as SSK (set storage key) - when > > the page is assigned > to a > > real storage frame. > > > > On Tue, Nov 22, 2022 at 10:24 AM Ian Worthington < > > 047bb6801512-dmarc-requ...@listserv.ua.edu> wrote: > > > > > I don't think the storage keys (and their friends) are held in the > > > page tables though. > > > > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > > > Ian ... > > > > > >On Tuesday, November 22, 2022 at 05:04:08 PM GMT+1, Jay Maynard > > > < jaymayn...@gmail.com> wrote: > > > > > > Each page table entry has a byte associated with it that stores > > > the > key, > > > as > > > well as the referenced and changed bits. > > > > > > And yes, 4K page tables do soak up lots of memory, which is why > > > later > > OSes > > > use 1M or 2M pages. > > > > > > On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington < > > > 047bb6801512-dmarc-requ..
Re: Storage protection keys
For a more precise time frame on the introduction of IBM implementation of S/390 architecture using a combination of native hardware microarchitecture plus millicode, this reference agrees with my memory that it was generation 4 of the IBM CMOS processors. https://en.wikipedia.org/wiki/Millicode The G1, G2, and G3 9672 processors were designed at the IBM Boeblingen lab, and I am not familiar with the underlying hardware microarchitecture of those machines. I do remember that that from doing problem diagnosis during MVS bring up on those machines that the term "microcode" was still being used. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message----- From: Jim Mulder Sent: Tuesday, November 22, 2022 10:01 PM To: ibm-main@listserv.ua.edu Subject: Re: Storage protection keys My wife agrees with you that my "vaccine research" comment was over the top, and I am trained to accept her judgement on such matters of decorum, so I apologize for that. I agreed with you that processor designs of the XA/ESA era were as you described. The IBM 303x, 308x,and 3090 processors all implemented the 370, 370/XA, and 370/ESA instruction sets via microcode on top of underlying different hardware microarchitectures, which could be characterized as a form of emulation. And I agree that, for that era, your statement that "last HARDWIRED CPU was probably the S/360 & S/370 model 195" is correct. However, the facts are that the IBM Power processor chips and the IBM z processor chips are separate entities. IBM z/Architecture has never been implemented by IBM on IBM Power processor chips, other than a brief period where the zPDT software emulator had versions for both Power and x86 machines. The Power version was subsequently discontinued. For more than the past decade, a considerable number of the z/Architecture instructions have been implemented directly in hardware, with some others being cracked into multiple hardware ops, and some more complex instructions being implemented in millicode. If you want to think of the millicoded instructions as a form of emulation, I don't object. However, it is done on z hardware, not Power hardware. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "My friends, you know me to be neither rash nor impulsive. I am not given to wild, unsupported statements." (Jor-El, "Superman", 1978, somewhat out of context) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Tuesday, November 22, 2022 8:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys Interesting that you have to resort to a childish rant ... So totally unprofessional ... BTW if you read the documents you proved they actually prove my point ... Dr. Gene Amdahl picked me to lead the design and build of his CMOS XA processor for a reason ... My direct OS and hardware experience... 52 years worth... Paul -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
My wife agrees with you that my "vaccine research" comment was over the top, and I am trained to accept her judgement on such matters of decorum, so I apologize for that. I agreed with you that processor designs of the XA/ESA era were as you described. The IBM 303x, 308x,and 3090 processors all implemented the 370, 370/XA, and 370/ESA instruction sets via microcode on top of underlying different hardware microarchitectures, which could be characterized as a form of emulation. And I agree that, for that era, your statement that "last HARDWIRED CPU was probably the S/360 & S/370 model 195" is correct. However, the facts are that the IBM Power processor chips and the IBM z processor chips are separate entities. IBM z/Architecture has never been implemented by IBM on IBM Power processor chips, other than a brief period where the zPDT software emulator had versions for both Power and x86 machines. The Power version was subsequently discontinued. For more than the past decade, a considerable number of the z/Architecture instructions have been implemented directly in hardware, with some others being cracked into multiple hardware ops, and some more complex instructions being implemented in millicode. If you want to think of the millicoded instructions as a form of emulation, I don't object. However, it is done on z hardware, not Power hardware. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "My friends, you know me to be neither rash nor impulsive. I am not given to wild, unsupported statements." (Jor-El, "Superman", 1978, somewhat out of context) -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Tuesday, November 22, 2022 8:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys Interesting that you have to resort to a childish rant ... So totally unprofessional ... BTW if you read the documents you proved they actually prove my point ... Dr. Gene Amdahl picked me to lead the design and build of his CMOS XA processor for a reason ... My direct OS and hardware experience... 52 years worth... Paul -- 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 protection keys
Fascinating. Do you also do your own vaccine research with similar methodology and results? You might consider these sources: https://community.ibm.com/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=1275a261-ab21-4f8a-b060-5c71880a71fa https://www.ibm.com/blogs/systems/ibm-telum-processor-the-next-gen-microprocessor-for-ibm-z-and-ibm-linuxone/ I have 43 years of experience at IBM in MVS-OS/390-z/OS development and have worked with the processor engineers over most of that interval. Knowledge that you have from Andor Systems designing a 3090 compatible system over 30 years ago would be somewhat outdated. The IBM 3090 bipolar machines of that era did have an underlying hardware architecture upon which the 370/ESA architecture was implemented in horizontal and vertical microcode. However, things are considerably different in more recent generations of processor design. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Tuesday, November 22, 2022 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys After doing more research, I will stand by my retort. The BASIC CPU hardware for zServer is a collection of POWER PC processors with some addition z Enhancements and the z is an EMULATOR because the last HARDWIRED CPU was probably the S/360 & S/370 model 195. Even Intel CPUs are Emulators that is that are a RISC engine ( like the POWER PC ) running the INTEL/AMD X64 instruction set with lots of microcode ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage protection keys
That's an impressive display of misinformation. Present day Z machines are not emulators. They have their own CPU chips which are different from the CPU chips used for Power and I. The storage separation of logical partitions is done via a mechanism that is not storage keys. The LPAR support for Z is distinct from the LPAR support for Power/I. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gorlinsky Sent: Tuesday, November 22, 2022 12:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Storage protection keys Present day z/Arch machines are the combination of several POWER PC chips working together. With the inclusion of LPAR as the only mode to operate the machine, logically, the storage management is more than just the old storage keys, there are also additional KEYS to manage the LPARs themselves and PREVENT one LPAR from looking into the storage of another LPAR. The machine complex is a large emulator of the z/ARCH instruction set, memory/storage subsystem and IO processors. In other words, it's a very fast emulator. With very little change, the hardware is zServer, iServer and pServer, all running different instruction set emulation, but sharing a lot of functionally, like LPAR support in all three. The expert on this would be Lynn Wheeler... so the rest I'll defer to the experts. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MVS/370 System Initialization Library?
SP4.1.0 - NMLDEF macro and IEANYxxx modules SP4.2.2 - NUCLSTxx Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Thursday, November 10, 2022 7:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MVS/370 System Initialization Library? Does anybody have a link for a scanned copy of System Initialization Library for MVS/370 (anything from OS/VS2 R2 through MVS/SP V1) that I can cite for wikipedia? Also, does anybody remember when addition nucleus load modules came in? When the parmlib member replaced the csect for selecting what to load? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CAS Restart during system startup
I nagged Mark Thomen into using a reusable ASID for CATALOG in 2006, release z/OS1.9. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz Sent: Tuesday, October 25, 2022 12:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CAS Restart during system startup Mark, >We don't start it in COMMNDxx/IEACMDxx, z/OS starts it as part of the system >initialization process. I take it that you mean the CATALOG address space. This has been so as long as I can remember: CAS starts in asid x'B' (I think) as a limited function address space to provide *some* catalog services to the IPL process. After other supporting address spaces have come up, CAS restarts itself as a full function address space in an asid with a much higher number. x'B' is left unusable for the life of the IPL. I believe this is described to some extent in the books and is also mentioned in SHARE presentations (with more details, IIRC). Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: D IPLINFO / IEE254I
IPCS STATUS SYSTEMwill also display that information. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Monday, October 24, 2022 3:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: D IPLINFO / IEE254I Interesting after RSU2209 z/os 2.5 this now displays some VM info: VM CPID = z/VMrelease VM UUID IS NOT PROVIDED VM NAME = vmuserid VM EXT NAME IS NOT PROVIDED -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS VERBX 64bit storage
https://listserv.ua.edu/cgi-bin/wa?A2=ind2111&L=IBM-MAIN&P=R28794&X=O14039FAB4B2233B763&Y=d10jhm1%40us.ibm.com Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Janicek Sent: Wednesday, September 21, 2022 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IPCS VERBX 64bit storage Hi all. I am new to this list but I have searched the archives for an answer to my question already without any luck. I am responsible for maintaining an IBM IPCS VERBX (verb exit) that analyzes our application dumps and points out any inconsistencies in it. We are in the process of moving some of our data above the bar (ATB) and I need to update the VERBX to analyze that data. Unfortunately the IBM doc has virtually nothing on how to access 64bit storage in an IPCS dump via a VERBX. I searched the internet and the only clue I found was a 7 year old post on this site by Don Poitras. He listed a routine in C that would access 64bit (and 31bit) storage. I have tried to mimic that code in assembler but I haven't gotten it to work yet. I am posting my code at the end of this listing. My hope is that someone will either point out the error of my ways or, instead, simply post their code that does the same thing. When I attempt to access 64bit storage, I get the following messages: Dump analysis will be incomplete. XSSP passed by exit PLATFORM is not valid. Equate Symbol record failed consistency check. Here's my code that I'm using. Thanks in advance for your time on this. -- 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: Question ABout SSI
The documentation is wrong. For function code 10, SSIBSSNM contains the name of the target subsystem, just like for any other broadcast call. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY From: IBM Mainframe Discussion List on behalf of esst...@juno.com Sent: Sunday, August 28, 2022 4:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question ABout SSI Hello . . I'm reviewing the publication "Using the Subsystem Interface", and an old SHARE presentation "All About the Subsystem Interface". . Looking at The Broadcast Functions an installation can invoke - function codes 04,08,09,10,14,48,50,78 . In general on entry to one of these Broadcast functions, Register 0 points to the SSCVT, mapped by IEFJSCVT. . It is my understanding for most of these Broadcast functions, SSIBSSNM is the name of the subsystem enabled to receive this function call. An installation could easily examine SSIBSSNM for its subsystem name and take the necessary action. . However for Function Code 10 (command processing), SSIBSSNM contains the value "MSTR". . Looking at the examples in "Using the Subsystem Interface", the function routine always checks SSIBSSNM against SSCTSNAM. Is this valid/true for Function Code 10. In other words for SSI Function Code 10 does SSCTSNAM contain "MSTR" as well ? or does it contain the name of the subsystem enabled to receive this function call ? . Otherwise a Function Code 10 routine would need to examine the command buffer text. . . Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Dump DS's
You can also take a standalone dump and then use the COPYCAPD subcommand of IPCS to extract a captured SVC Dump from the standalone dump and write it to a data set. Jim Mulder King of z/OS Dumping From: IBM Mainframe Discussion List on behalf of Barbara Nitz Sent: Monday, August 22, 2022 12:24 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: System Dump DS's >That's correct. I didn't delete mine either, I just made them very small. IIRC, the system dump data sets should not be deleted. Dynamic dumps require SMS to be active. Before SMS is active, no dump can be taken when the old-style dump data sets are not available anymore. I remember one occasion where MSTJCL failed to start. The system did not go into a wait state, but it did not come up, either. Without that old-style dump I would never have found the problem - accidentally ISPF compress was used on the parmlib member. That resulted in a lot of gibberish, but no comprehendable JCL statements. Worst, when you checked mstjclxx via ISPF, it looked completely okay. Better keep your old-style dump data sets to be used until SMS is fully active. Regards, Barbara Nitz -- 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: MODE trace entry
Yes, if you turn it on via TRACE ST,MODE=ON Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Thursday, July 28, 2022 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MODE trace entry The manual z/OS: z/OS MVS Diagnosis: Tools and Service Aids GA32-0905-50 shows that a MODE trace entry will be generated for "a change into or out of 64-bit addressing mode". Is a SAM64 instruction supposed to generate such a trace entry? I am not seeing one when a SAM64 instruction is executed. Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYS1.LOGREC vs VERBX LOGDATA
No. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Thursday, July 28, 2022 3:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYS1.LOGREC vs VERBX LOGDATA Hello: I clear the SYS1.LOGREC with a PGM=IFCEREP1 'ZERO=Y' parm. But if I capture a SVC dump afer that, the VERBX LOGDATA will still show events that occurred before the SYS1.LOGREC was cleared. Is there a way to force the z/os internal version of SYS1.LOGREC to be cleared at the same time the disk-resident version is cleared with a PGM=IFCEREP1 'ZERO=Y' ? Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TIMEUSED macro
Since you are not executing in supervisor state and key 0, you need to specify LINKAGE=SYSTEM on the TIMEUSED macro. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Saturday, July 2, 2022 3:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TIMEUSED macro There was a discussion from 2020 about 'Strange S0C4 on z15' where the instruction L 15,X'B4C'(0,0)58F0 0B4C would cause 0C4 accessing the SVT. It seems that the TIMEUSED macro, even as of z/os 2.5 level (01* STATUS = HBB77C0 ) when coded TIMEUSED STORADR=STIME generates the sequence TIMEUSED STORADR=STIME MACDATE 04/06/2005 LA1,STIMEAREA FOR RETURN OF TIME VALUE L 15,X'B4C'(0,0) SVT ADDRESS L 15,X'88'(0,15) ADDRESS OF SERVICE ROUTINE BASSM 14,15 which causes 0C4 on the L 15,X'B4C'(0,0) instruction. Does the TIMEUSED macro need updating to access the SVT the supported modern way? Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about z/os and VM ADJUNCT
I would not expect the SLIP WAIT to change primary and secondary. You can verify that by displaying CR 3 and 4 for the CPU of interest and comparing it to the CR 3-4 in the IEE844W message. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Schuster Sent: Friday, May 20, 2022 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Question about z/os and VM ADJUNCT I code an IF SLIP with ACTION=WAIT. When it hits, I get the IEE844W message. I start the adjunct, and I want to display the storage at the locations pointed to by the registers. I use the command CPU 0 CMD DISPLAY PRI regval.100 This works for a register that points to common storage, but for a register value that points to private storage I get CPU 0 CMD DISPLAY PRI 7F7FA2E8.100 00: V 0E R 00: V7F7FA2E8 to 7F7FA3E7 non-addressable storage - page translation exception (At the time the SLIP hit, the register value is valid.) Is there something else I need to specify on the DISPLAY command to get the register value correctly translated to the VM third level storage? Or does the ACTION=WAIT destroy the capability of doing a translation? Thank you. -- 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: IBM BLSR subsystem
BLSR was initially developed by Washinton System Center as an assembler language sample program to go along with a book they were writing about using the Subsystem Interface. At the time, IBM was desperately looking for "ESA Exclusives" in order to sell 3090 machines vs the PCM manufacturers, who machines had not yet implemented ESA. This sample program happened to use one BAKR/PR, which meant that it did require ESA. So MVS management wanted to instead ship the program an OCO part of the MVS BCP, and I was commanded to review the code to see what that would entail. I raised several objections concerning the maintainability of the code, the lack of serviceability (no ESTAEs, no dumping, no control block eyecatchers, we didn't want new assembler code), no message IDs, lack of messages and message control, an integrity exposure, etc, etc. Also, VSAM functionality was not really in the BCP's bailiwick, and we would end up having to support this code for decades. So I recommended that we should not do this. But, since selling machines trumps everything, I lost that argument, and was instead assigned to remediate all of my objections to the sample code. I recoded the whole thing in PL/AS and fixed all of the issues, and wrote lots of testcases, and it got shipped as a PTF on top of MVS/ESA SP3.1.3. MVS Project Management did contribute the "Batch LSR" name. Decades later, we continue to support it and probably always will, but at least the right solution eventually got implemented by SMB in DFSMS. And now you know... the rest of the story. James Harvey Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY From: IBM Mainframe Discussion List on behalf of Dave Barry <00a5644c6d08-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, May 18, 2022 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: IBM BLSR subsystem >IIRC, Batch LSR was developed at IBM by the BCP team; SMB was later developed >by the DFdfp team. SMB is not BLSR under-the-covers, but it offers the same >advantages. >SMB is the more modern solution. It has worked wonders at my shop. Just mind >your REGION size. If you haven't converted some VSAM files to Extended >Format, this is a good reason to do so. >The VSAM Demystified Redbook is a good resource. Lots on the Web, e.g. >https://www.ibm.com/docs/en/zos/2.5.0?topic=resource-tuning-system-managed-buffering -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESTAE and IEBCOPY
IEBCOPY does not overlay your ESTAE. It creates its own ESTAE, which gets control before yours. IEBCOPY's ESTAE does a Retry, and RTM releases the RTM2WA before giving control to the retry routine. Since IEBCOPY's ESTAE retried, processing of the Abend is completed, so your ESTAE does not get control. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steff Gladstone Sent: Tuesday, March 8, 2022 10:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ESTAE and IEBCOPY In one of our REXX procedures we execute IEBCOPY to copy a member from one PDS to another. Sometimes IEBCOPY fails (e.g., for lack of space either in the directory or the library). It intercepts the abend through its ESTAE routine and returns a CC=8 with a text message to SYSPRINT. We would like to be able to receive more specific information as to the abend code and reason code of the IEBCOPY fail so we wrote a front-end which creates our own ESTAE before calling IEBCOPY so we can capture the information from the SDWA at abend time. But it appears that IEBCOPY overlays our ESTAE with its own so we don't get control. So we decided that when IEBCOPY returns to our front-end we would locate the RTM2WA and glean the information from it. But the pointer to the RTM2WA (TCBRTWA) is zero at that point (we suppose that IEBCOPY cancels its ESTAE before returning to us and the RTM2WA is released). Does anybody have any ideas how we might capture the abend and reason codes in spite of all this? Thanks, Steff Gladstone -- 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: RTM2WA
IHARTM2A is not provided in MACLIB or MODGEN. It is PL/X only - there is no DSECT. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steff Gladstone Sent: Tuesday, March 8, 2022 7:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RTM2WA Where can I find the DSECT for the RTM2WA control block? I did not find it in either SYS1.MACLIB or SYS1.AMODGEN. Thanks, Steff Gladstone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ESPIE IC > 15?
For ABEND S0Cx, D0D6, and S0E0, the abend reason code is the program check interrupt code. (since SP2.1.4, around 1985). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, March 7, 2022 1:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? ABEND S0C4 was overloaded since SVS, but I remember seeing the correct interrupt code reported on dumps and in APAR descriptions, e.g., PK00040. What I really want is a separate ABEND code and SPIE mask bit for each type of program check, but that ship has sailed. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jim Mulder [d10j...@us.ibm.com] Sent: Sunday, March 6, 2022 10:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? It has worked that way for PIC x'10' and x'11' since MVS/XA, 40 years ago. '38' - x'3B' were added via APAR OW57082, 19 years ago. It looks to me like the original interrupt code would be in STCBOLCP, but STCBOLCP is not designated as a Programming Interface. What you would really want is for the original interrupt code to be provided in one of the IHAEPIE fields that is currently reserved. Unfortunately, OW57082 did not do that. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, March 6, 2022 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Ouch! Those overloaded odes make diagnosis more difficult. Thanks. -- Shmuel (Seymour J.) Metz https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7Csmetz3%40gmu.edu%7C6f047fafd55d4a1c58a308d9ffec8583%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637822213620474251%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P%2FoT2daoya372VBjIOQpCOvgmMsno%2BHd%2FwxPXvHkoS4%3D&reserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jim Mulder [d10j...@us.ibm.com] Sent: Sunday, March 6, 2022 3:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? The code did not work, and appeared to have not worked for a long time. We could not come up with any use for a function that would give control to an ESPIE exit before invoking the Real Storage Manager for a DAT exception. There would not seem to be anything useful that an ESPIE exit could do in that case, since it would not know whether or not the Real Storage Manager would be able to resolve the exception. The ISVs were notified, and I don't remember any objections. Note that for Program Interrupt Codes x'10', x'11',x'38, x'39,' x'3A', and x'3B', an exception that does not get resolved by the Real Storage Manager will get presented to SPIE/ESPIE exits as interrupt code 4. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, March 6, 2022 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Thanks. Any idea why they took it away? -- Shmuel (Seymour J.) Metz https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7Csmetz3%40gmu.edu%7C6f047fafd55d4a1c58a308d9ffec8583%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637822213620474251%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P%2FoT2daoya372VBjIOQpCOvgmMsno%2BHd%2FwxPXvHkoS4%3D&reserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Sunday, March 6, 2022 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Looks like as of z/OS 2.3. 2.2 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1-15 and 17. 2.3 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1 - 15. Joe On Sun, Mar 6, 2022 at 8:04 AM Seymour J Metz wrote: > When did ESPIE stop supporting interrupt code 17? > > -- > Shmuel (Seymour J.) Metz ssage: INFO IBM-MAIN
Re: ESPIE IC > 15?
It has worked that way for PIC x'10' and x'11' since MVS/XA, 40 years ago. '38' - x'3B' were added via APAR OW57082, 19 years ago. It looks to me like the original interrupt code would be in STCBOLCP, but STCBOLCP is not designated as a Programming Interface. What you would really want is for the original interrupt code to be provided in one of the IHAEPIE fields that is currently reserved. Unfortunately, OW57082 did not do that. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, March 6, 2022 5:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Ouch! Those overloaded odes make diagnosis more difficult. Thanks. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jim Mulder [d10j...@us.ibm.com] Sent: Sunday, March 6, 2022 3:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? The code did not work, and appeared to have not worked for a long time. We could not come up with any use for a function that would give control to an ESPIE exit before invoking the Real Storage Manager for a DAT exception. There would not seem to be anything useful that an ESPIE exit could do in that case, since it would not know whether or not the Real Storage Manager would be able to resolve the exception. The ISVs were notified, and I don't remember any objections. Note that for Program Interrupt Codes x'10', x'11',x'38, x'39,' x'3A', and x'3B', an exception that does not get resolved by the Real Storage Manager will get presented to SPIE/ESPIE exits as interrupt code 4. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, March 6, 2022 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Thanks. Any idea why they took it away? -- Shmuel (Seymour J.) Metz https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3&data=04%7C01%7Csmetz3%40gmu.edu%7Caea322dbb0c44b5137a408d9ffafa33b%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637821952103800693%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FMCl5U%2FkJlSZ36YrRoq%2FmvGmLX6fPn%2BrvocyLWTeV4c%3D&reserved=0 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Sunday, March 6, 2022 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Looks like as of z/OS 2.3. 2.2 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1-15 and 17. 2.3 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1 - 15. Joe On Sun, Mar 6, 2022 at 8:04 AM Seymour J Metz wrote: > When did ESPIE stop supporting interrupt code 17? > > -- > Shmuel (Seymour J.) Metz ssage: 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: ESPIE IC > 15?
The code did not work, and appeared to have not worked for a long time. We could not come up with any use for a function that would give control to an ESPIE exit before invoking the Real Storage Manager for a DAT exception. There would not seem to be anything useful that an ESPIE exit could do in that case, since it would not know whether or not the Real Storage Manager would be able to resolve the exception. The ISVs were notified, and I don't remember any objections. Note that for Program Interrupt Codes x'10', x'11',x'38, x'39,' x'3A', and x'3B', an exception that does not get resolved by the Real Storage Manager will get presented to SPIE/ESPIE exits as interrupt code 4. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Sunday, March 6, 2022 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Thanks. Any idea why they took it away? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Joe Monk [joemon...@gmail.com] Sent: Sunday, March 6, 2022 10:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ESPIE IC > 15? Looks like as of z/OS 2.3. 2.2 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1–15 and 17. 2.3 doc: If a program interruption occurs, the SPIE/ESPIE exit receives control only when all of the following conditions exist: - The interrupted program is a problem state program. - The program interrupt code is in the range 1 - 15. Joe On Sun, Mar 6, 2022 at 8:04 AM Seymour J Metz wrote: > When did ESPIE stop supporting interrupt code 17? > > -- > Shmuel (Seymour J.) Metz ssage: 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: 2.5 Heads Up
Yes, the undocumented (but disclosed to ISVs) IGVDGNPP test tool will modify all of the reserved fields in every CPU's PSA in order to expose latent defects in code that happens to seem to work when reserved fields contain zeroes. But since that may expose latent defects in other code (IBM, ISV, or customer), it's not the kind of thing you would want to use on a production system. We of course use that tool on our test systems, so that we tend to not have zeros at PSA+4 on our z/OS 2.5 test systems, which may have contributed to the bug escaping our notice until it got into the field. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/22/2022 10:26:40 AM: > From: "Charles Mills" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/22/2022 02:28 PM > Subject: Re: 2.5 Heads Up > Sent by: "IBM Mainframe Discussion List" > > Would using some "debug" type utility to store a non-zero value at address 4 > be a partial circumvention? > > The pre-Z restart PSW is never used for anything now -- is that correct? > > Charles > > > -Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jim Mulder > Sent: Monday, February 21, 2022 10:03 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: 2.5 Heads Up > > Location 4 means address 4 (i.e. offset 4 in the PSA). > > There was a latent bug from a prior release in the loop control > code so that it was erroneously fetching from address 4, and > behaving especially badly when the data at that location > is x'', which it is as of z/OS 2.5. In prior releases, > it was x'000130E1' when in zArchitecture mode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2.5 Heads Up
Location 4 means address 4 (i.e. offset 4 in the PSA). There was a latent bug from a prior release in the loop control code so that it was erroneously fetching from address 4, and behaving especially badly when the data at that location is x'', which it is as of z/OS 2.5. In prior releases, it was x'000130E1' when in zArchitecture mode. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/21/2022 05:02:54 PM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/22/2022 12:49 AM > Subject: Re: 2.5 Heads Up > Sent by: "IBM Mainframe Discussion List" > > On Mon, 21 Feb 2022 12:54:14 -0800, Ed Jaffe wrote: > > >On 2/21/2022 12:00 PM, Mark Jacobs wrote: > >> Found APAR OA62381 for this problem. PTFs are not yet available. > > > Yet: APAR status > Closed as program error. > > >Hugely helpful! THANKS! > > > >https://www.ibm.com/support/pages/apar/OA62381 > > > Local fix > BYPASS/CIRCUMVENTION: > Set DSENQSHR to DISALLOW in the relevant JOBCLASSes > > Doesn't that just say, "Don't do that!"? Hardly a circumvention. > > if the storage at location x'0004' is zeroed out. > > What's llocation 4 supposed to mean? > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS - Dump timing
VERBX IEAVTSFS Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 02/07/2022 11:05:32 PM: > From: "Jake Anderson" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 02/08/2022 11:17 AM > Subject: IPCS - Dump timing > Sent by: "IBM Mainframe Discussion List" > > Hello > > We have some dumps taken on 6th February but is it possible to know at what > time the dump was captured using IPCS and can we see the timestamp anywhere > in DUMP using IPCS ? > > Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Display user for started tasks started under Master subsystem
Starting in z/OS 2.5, any program can do what IPCS ACTIVE does by using the SYS1.MACLIB(BLSACTV) macro to access storage of other address spaces, if the userid under which the program is running has been granted access to the BLSACTV.SYSTEM Facility Class. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/30/2021 07:08:23 AM: > From: "Lennie Dymoke-Bradshaw" <032fff1be9b4-dmarc- > requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/30/2021 11:55 AM > Subject: Re: Display user for started tasks started under Master subsystem > Sent by: "IBM Mainframe Discussion List" > > Rob, > I was hoping you would pick this up. > Thanks for that insight. It always helps to see the source of information > that is presented. Maybe I can produce a small TSO utility to find this > data. But it looks like it might have to a tiny bit APF authorised to get to > the necessary information. > (I assume you meant to type ASXBSENV rather than ASSBSENV. I think the > ASXBUSER field would probably be sufficient.) > Lennie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Display user for started tasks started under Master subsystem
The D,A command (module IEECB800) similarly uses IAZXJSAB to obtain the userid. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/30/2021 04:16:41 AM: > From: "Rob Scott" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/30/2021 11:51 AM > Subject: Re: Display user for started tasks started under Master subsystem > Sent by: "IBM Mainframe Discussion List" > > SDSF uses IAZXJSAB to extract the userid from the JSAB control block > - hence nothing shown if address space has started SUB=MSTR and has > not requested a JES JOBID (SSI-20). > > As far as I am aware, there is no definitive field in common storage > that contains the userid associated with an address space regardless > of how the job entered the system. > > In a dump, there might be some mileage in examining OUCBUSRD if > there is no JSAB, or sniff the ACEE from ASSBSENV (or even run the > TCB tree and process any non-zero TCBSENVs). > > Rob Scott > Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS CTRACE Buffer Locate Exit
That would be a good question for Phoenix Software International's IBM Technical Advocate. It turns out that is me. I dug around a bit in the code that issues that message, and it looks like it intends to put out some additional diagnostic information (and then Abend if you are in IPCS line mode) if you put IPCS into TEST mode, which is done via the SETDEF TESTsubcommand. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/24/2021 10:39:10 AM: > From: "Tom Harper" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/24/2021 08:17 PM > Subject: IPCS CTRACE Buffer Locate Exit > Sent by: "IBM Mainframe Discussion List" > > All, > > I’ve used IPCS for decades including using CTRACE. One of the > required exits for this facility is the Buffer Locate Exit, which I > have used at prior jobs without issue. > > However now I cannot get it to work and I can’t determine what the issue is. > > The exit passes the address of an equate symbol (ES) record, mapped > by BLSRESSY. > > All the exit is supposed to do is to complete the BLSRESSY record > and pass it back with a return code which indicates whether the exit > should be driven again for another buffer. That all works correctly. > > I can locate the buffers and their lengths fine (l’ve tried both 31- > bit and 64-bit buffers using the respective mappings for the ES) but > to no avail. > > The message I get back from IPCS is BLS18460I which states that the > symbol record is not valid. A further detail is the qualifier: > > “Equate Symbol record failed consistency check.” > > I have no idea what that means. I have carefully checked every field > and they all appear to be correct to me. > > Any ideas would be much appreciated. > > Tom Harper > > Phoenix Software International -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PSA 0
0 was the address of the restart new PSW in ESA/390. When we implemented zArchitecture 20 years ago, we set the obsolete ESA/390 interrupt new PSWs such that if someone tried to simulate an interrupt by doing a LPSW for one of them, the result would be a 0E1 wait state with a unique reason code. We figured that after 20 years of that, we had already gotten whatever value that there might have been from that, and it might now be better not to have things like 000A and 000130E1 hanging around down there where some program that has a null pointer bug might pick them up and end up trying to use them as addresses and get into even more weird results or storage overlays (since those are often valid GETMAINed addresses). So in z/OS 2.5, we changed those back to being reserved fields that are initialized to zeroes. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/24/2021 05:58:15 PM: > From: "Hank Oerlemans" <03c4d8bf55f3-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/24/2021 07:57 PM > Subject: PSA 0 > Sent by: "IBM Mainframe Discussion List" > > A random neuron thinks there was an announcement but if anyone can > shed some light I'm curious about Address 0. > > I am used to seeing X'000A' then X'000130E1' in the first 8-bytes. > This is no longer so. All zeros. A good thing ! > > SA22-7832-12 of Pops doesn't mention anything in CH. 3. > > So was there any kind of announcement for z/OS 2.5 ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AutoIPL Failure, just curious
Why did the system go into a wait state? Was a standalone dump taken? When we process a DIAGxx that specifies MVS(LAST), we copy CVTSYSAD into DgnbAIMvsUCBAddr (in SYS1.MODGEN(IGVDGNB)). When we try to AutoIPL that MVS, we get the device number from UCBCHAN in the UCB pointed to by DgnbAIMvsUCBAddr. So a storage overlay of DgnbAIMvsUCBAddr or of UCBCHAN would result in a wrong device number being used for AutoIPL. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 11/04/2021 08:42:46 PM: > From: "Mark Jacobs" <0224d287a4b1-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/04/2021 11:38 PM > Subject: AutoIPL Failure, just curious > Sent by: "IBM Mainframe Discussion List" > > One of out systems went into a wait state today and autoipl was > attempted. It failed with this message (from the HMC Hardware Events log) > > A load failure occurred on logical partition because a device > address control block (DACB) was not found. Unit address = 5810. > > That unit address is not in our IODF. A manual activation was needed > to bring it back up. I'm just curious how/why this error occurred. > > Mark Jacobs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 2.4 IPL WSC 040
IEAVNP26 is SMS. For any more than that, I would need a standalone dump. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 10/19/2021 06:30:03 PM: > From: "PINION, RICHARD W." > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/19/2021 06:36 PM > Subject: z/OS 2.4 IPL WSC 040 > Sent by: "IBM Mainframe Discussion List" > > I recently applied maintenance to our 2.4 system, and got the > following attempting to IPL. > > Central processor (CP) 0 is in a nonrestartable stopped state due to > a System Control Program (SCP) initiated reset of the I/O interface > for partition BASE. > The disabled wait program status word (PSW) is > 00028040. > > This is the last message display on the console. > > IEA303W ABEND 000 REASON DURING INITIALIZATION UNDER RIM IEAVNP26 > > I've Googled this, and found a discussion about a similar issue from > March 31st of this year, by > Glen Schneck. I didn't see a resolution. > > I've checked the IEASYSxx member, and it is specifying CLPA, and our > LOADxx member does > have INITSQA 0256K 0001M. > > This on an IBM z15. > > Any ideas? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Vector examples?
For z/OS, the programming interface for determining if vectors are available is SYS1.MACLIB(CVT) CVTVEF EQU X'80' Vector Extension Facility @NUA This will be on when you are on at least z/OS 2.1, and this bit is on: BROWSESYS1.MACLIB(IHAFACL) Facl_VectorExtensionFacility EQU X'40' Bit 129. z13 Even if this bit * is on, do not use the VEF unless* bit CVTVEF is on. Jim Mulder z/OS Diagnosis, Design, Development, 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
Re: SIGP Orders
It is assigned. It is used by z/OS. It is intentionally not described in Principles of Operation. So that is all we will publicly say about it. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 10/13/2021 02:57:42 PM: > From: "Joe Monk" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 10/13/2021 07:17 PM > Subject: Re: SIGP Orders > Sent by: "IBM Mainframe Discussion List" > > Alan, > > It's being issued by z/os 2.4... I see it in the trace... > > Joe > > On Wed, Oct 13, 2021 at 4:11 PM Alan Altmark > wrote: > > > On Tue, 12 Oct 2021 07:09:23 -0500, Joe Monk wrote: > > >Looking thru the z/arch POP, I noticed that SIGP order 14 is no longer > > >listed as unassigned, but its definition and functions are missing from > > the > > >POP. > > > > > >Can someone tell us what this order is for? > > > > I suspect that line is supposed to say "Unassigned" just like 0x0F and > > 0x10. Please submit a Reader's Comment Form to request clarification. > > > > Alan Altmark > > IBM > > > > -- > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
Long ago, when I was a new hire at IBM, fresh out of college with my hoity toity computer science degrees, and without enough experience to have much real work to do, I would try to argue with the MVS developers about how MVS perverted the definitions of computer science terms, like using "queue" to refer to any linked list, when "queue" was supposed to be an abstract ordered data structure with specific addition and deletion protocols. And they would mostly tolerantly ignore me and tell me that before long, I would be just like them with too much work to do and no time to argue about such things. And I thought, "No way! They are wrong. I will always make time to be passionate about that." But it didn't take long for them to be proved correct. Jim Mulder z/OS Diagnosis, Design, Development, 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
Re: RENT binder option
With respect to your last paragraph, I am not arguing. I am stating facts. 1. z/OS System Integrity requires that modules which execute in authorized state and are addressable by unauthorized programs must be protected from modification by unauthorized programs, z/OS is designed to satisfy this requirement by using key 0 storage for Nucleus, LPA, and load modules and program objects in APF-authorized libraries that have the RENT attribute. Developers of modules which execute in an authorized state are required to understand this and use these techniques where needed to ensure that their modules conform to this requirement. You are free to have the opinion that using the RENT attribute for this purpose by the MVS designers over 45 years ago was a perversion of the definition of RENT, and that they should not have done that, and possibly used REFR or created a new attribute for that purpose. And I might be inclined to agree with that opinion. I expect that they had pragmatic development cost reasons for doing what they did, and regardless of the reasons, we are stuck with remaining compatible with that, because compatibility is one of the things that keeps z/OS in business, and we like to stay in business. 2. z/OS is not required to protect programs from modification by programs running in an authorized state, However, for system reliability, availability, and serviceability reasons, we find it to be very useful to do so where possible. That is why LPA has been DAT-protected since MVS SP1.3 on enhanced 3033 machines, and why the read-only nucleus has been DAT-protected since MVS/XA, and why I experimented with the possibility of DAT-protecting RENT modules, and ended up implementing REFRPROT. You are free to have the opinion that using the REFR attribute for REFPROT was a perversion of the definition of REFR, and I won't argue against that. We are constrained as always by pragmatic development cost considerations. Such is life in software engineering. Creating a new attribute would be more expensive. and we have space constraints in the PDS directory entry, and getting exploitation by rebinding a lot of things with a new attribute would be expensive, and there were already quite a few things that are bound with the REFR attribute, which provided zero-cost exploitation. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/03/2021 10:05:13 PM: > From: "CM Poncelet" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/04/2021 01:21 AM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > At the risk of inviting 'flak', I suspect that there is a misconception > of what RENT and REFR modules actually are. > > By definition, RENT and REFR modules should never modify themselves > (excluding the peculiar case of a RENT module that ENQ's on part of its > code, modifies it, restores it to what it was, then DEQ's it - as this > would not violate the definition of RENT modules being concurrently > executable by multiple tasks.) > > A module is REFR or RENT - not if it is link-edited as REFR or RENT, but > if it never modifies its own storage. In other words, all modifiable > storage must first be GETMAINed (including the module's savearea > storage) and any WTO(R)s and DYNALLOC/SVC-99s, DCBs, ACBs and/or RPLs > etc. must then use the 'list' and 'executable' forms of these > macros/DSECTs to avoid modifying the module's own storage.) > > As a 'first line of defence', such modules should be coded as RSECTs and > not as CSECTs - and the assembler will then trap (with a CC=08, IIRC) > any direct attempt to modify the module's own storage. But it is the > programmer/developer who is responsible for ensuring that the module's > code is indeed REFR or RENT - and it is not the linkage-editor or > binder's responsibility. > > Arguing that REFR or RENT modules need to be 'protected' from modifying > themselves, or by others, is methinks beside the point - because such > modules should have been coded in such way that they *never* modify > themselves to begin with. If others can modify them, then it is these > other modules that should be investigated, not the REFR or RENT ones. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
1. No. I would expect any such incidences to be treated as a defect and fixed. 2. No 3. It was REFR and is still REFR. It was just a simple code bug, passing a field in the static area to BPX1OPT for a return parameter that gets modified by BPX1OPT. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/03/2021 08:34:33 AM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/03/2021 07:02 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > On Thu, 2 Sep 2021 16:02:07 -0400, Jim Mulder wrote: > > > I found IBM RENT modules that modified themselves > >15 years ago when I was experimenting to see what would > >happen if we tried to page-protect RENT modules. I have a list: > > > Have you a similar list of IBM REFR modules that modify themselfes? > > Does the setting of REFRPROT affect processing of modules > marked RENT but not REFR? > > What were the reusability attributes of the module in OA25089? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
I found IBM RENT modules that modified themselves 15 years ago when I was experimenting to see what would happen if we tried to page-protect RENT modules. I have a list: ANTMAIN ANTSDMLK IEAVNIPX EZATNF IOEFSKN FNMVZJV FNMVZCVA EZAXVMCF DSNHDECP DSN9PARM DSN3INI CNMINIT CNMCSSIM CNMCSSIC We subsequently removed the unintended RENT from IEAVNIPX. So we don't page-protect RENT modules (except for experimental purposes under control of another undocumented DIAGxx TRAP name), and we implemented REFRPROT instead. I haven't heard about any IBM modules that get broken by REFRPROT. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/02/2021 08:54:25 AM: > From: "Seymour J Metz" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/02/2021 03:46 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > Given that IBM has fetched RENT load modules and program objects > from authorized concatenations into SP252 for close to half a > century, there is a case for requiring new reentrant code to also be > read only. I agree about REFR. In both cases, IBM has to take > compatibility into account. > > There is customer code that is REFR or RENT but not read only. Is > there still any IBM code like that? > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
You are further illustrating my point. Your astonishment was due to your inexperience. The use of REFR for storage error recovery was only in predecessors of MVS, and that was before my time at IBM. I only know about that because of Shmuel's posts about it. Although it was before my time, I would guess that the key 0 protection for RENT programs from APF authorized libraries was added only because it was required for system integrity, and limited to APF authorized libraries in order to avoid migration impediments that would have resulted from breakage to existing self-modifying RENT programs in non-APF authorized libraries. That would have been consistent with MVS's emphasis on compatibility, and thus is not astonishing to me. Your "by happenstance it is refreshed and fails" scenario is unlikely to ever occur, since refreshing is currently done only for LPA modules, which are DAT-protected. z/OS will not be implementing refreshing for storage machine checks. The probability of a storage machine check on current machines is so low that, if anything, we would be simplifying or removing storage error machine check processing in z/OS, not enhancing it. In fact, while doing some work on System Trace in z/OS 2.5, I discovered that exploitation of 1MB frames for trace buffers in z/OS 1.10 had introduced a bug where a storage error machine check recovery for trace structures could result in an infinite loop. Based on discussion with hardware engineers about the projections for storage machine checks on the machines supported by z/OS 2.5, I remediated that by simplifying the recovery to just discard and rebuild the whole trace structure for a processor instead of trying to fix the old logic for removing a single 4K frame from the processor's trace structure. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/01/2021 01:58:03 PM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/01/2021 02:40 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > On Wed, 1 Sep 2021 13:25:03 -0400, Jim Mulder wrote: > >... > > As to the Astonishment in POLA, I would > >suggest that astonishment is relative to the > >experience of the beholder, ... > > > The oldest memories are the sharpest. I remember vividly my > astonishment as an MVS/370 novice when I discovered that > RER programs were not protected against modifying themselves > despite ready availability of hardware facilities. (Then I could > grasp the PoOps; no longer.) > > I was even further astonished to learn that a program need to > be Authorized in order to not modify itself. > > I imagine a program incorrectly marked REFR which depends > on self-modification. It works for years until by happenstance > it is refreshed and fails. Of course: "User Error. WAD." > > --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
In a separate post, I have said a little more about rounding and alignment cases for program objects. As to the Astonishment in POLA, I would suggest that astonishment is relative to the experience of the beholder, as illustrated here: SPOCK: Captain, the Intrepid would have done all these things too, and yet they were destroyed. KIRK: Well, they may not have done all of these things. You just pointed out how illogical this situation is. SPOCK: True. It is also true they never knew what was killing them. Their logic would not have permitted them to believe they were being killed. KIRK: Explain. SPOCK: Vulcan has not been conquered within its collective memory. The memory goes back so far that no Vulcan can conceive of a conqueror. I knew the ship was lost because I sensed it. KIRK: What was it you sensed? SPOCK: The touch of death. KIRK: And what do you think they felt? SPOCK: Astonishment. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/01/2021 09:39:18 AM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/01/2021 01:17 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > On Wed, 1 Sep 2021 01:44:44 -0400, Jim Mulder wrote: > > > As we have already discussed, program objects do get > >rounded up to 4k multiples. Load modules do not. > > > So for program objects REFRPROT follows POLA. > > ∎ > > Both ends rounded? > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
Some considerations for conversion to program objects are documented here: https://www.ibm.com/docs/en/zos/2.4.0?topic=objects-what-should-be-converted-program The cases where the program object loader rounds up the size to a 4K multiple and forces 4K alignment (without alignment being requested by a binder option) are those in which DIV is used to read the program directly into the target storage. That is an implementation detail and is thus subject to change, and thus would not be documented. Obviously, a LOAD where the caller specifies the target address is a case where rounding and alignment are not done. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 09/01/2021 11:04:15 AM: > From: "Paul Gilmartin" <000433f07816-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/01/2021 12:43 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > On Wed, 1 Sep 2021 01:44:44 -0400, Jim Mulder wrote: > > > As we have already discussed, program objects do get > >rounded up to 4k multiples. Load modules do not. > >... > > On Mon, 30 Aug 2021 18:11:07 -0400, Gord Tomlin wrote: > > >On 2021-08-30 17:28 PM, Charles Mills wrote: > >> Seriously, I agree with @Gil. Wasting a few bytes should be the > default, not leaving a few bytes unprotected. > >... > >To automatically extend all REFR modules to a multiple of 4K by default > >on a real system could result in much more than "wasting a few bytes". > >To put things in perspective, I have seen customer systems with over two > >hundred subsystems i.. > >-- > Does this mean that conversion to PDSE, implying program objects, implyig > 4Ki rounding would adversely affect them? > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
As we have already discussed, program objects do get rounded up to 4k multiples. Load modules do not. I am a big fan of looking at dumps. We always have hundreds of them readily available around here. Here is an excerpt from SUMMARY FORMAT ASID(1) EX(GL) on a z/OS 2.5 standalone dump. There are multiple load modules on pages 0CB01000 and 0CB0D000. EP... IEFJMSGT ENTPT 8CB0E228RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB0D8A0 LNTH. 0B20 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 02330E0D 60D3D5D2 D3E2E360 EPTOKEN.. 01B3 0001004D EP... ISNGENEX ENTPT 8CB01C10RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB01C10 LNTH. 03A8 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 011C070D 60D3D5D2 D3E2E360 EPTOKEN.. 01B0 0001000E EP... ISNAXOSV ENTPT 8CB06868RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB06868 LNTH. 0650 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 011E0D0D 60D3D5D2 D3E2E360 EPTOKEN.. 01AF 0001002C EP... ISNAXOCF ENTPT 8CB0D000RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB0D000 LNTH. 08A0 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 011E040D 60D3D5D2 D3E2E360 EPTOKEN.. 01AE 0001000D EP... ISNET4 ENTPT 8CB05AC8RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB05AC8 LNTH. 07F8 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 0127180D 60D3D5D2 D3E2E360 EPTOKEN.. 01A8 00010031 EP... ISNMDB ENTPT 8CB01558RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB01558 LNTH. 06B8 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 011B040D 60D3D5D2 D3E2E360 EPTOKEN.. 01A7 00010011 EP... ISNSTATE ENTPT 8CB011D8RRBP. USE.. 0001 SP... FC Reenterable. Reusable. APF library. NRFAC 0001 MSBAD 0CB011D8 LNTH. 0380 NAMEL 0008 ASID. 0001 PROVIDI.. 0002 PROVIDD.. 0001 011E270D 60D3D5D2 D3E2E360 EPTOKEN.. 01A6 00010065 Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/31/2021 11:23:11 PM: > From: "CM Poncelet" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 09/01/2021 01:30 AM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > "Not all modules have or need a 4 KiB alignment." Indeed, for "modules" > (as in CSECT/RSECT MODs, within an LMOD.) But LMODs themselves are > loaded into page-aligned storage. > > The LP (load point) addresses of LMODs always end with x'000' (i.e. > page-aligned) - and the addresses of all MODs they contain always ends > with x'0' or x'8', as in DWORD-aligned, *but* if these MODs are SYSLIN > "ORDER" link-edited as (P) [page-aligned] or SYSLIN "PAGE" link-edited > [likewise page-aligned,] then their addresses always end with x'000'. > This can be seen, checked and verified in/from system dumps. > > GETMAINs (aka STORAGE OBTAINs) are allocated in contiguous DWORD-aligned > storage within a same (or following) page, as too (usually) are MODs > within an LMOD (unless the MODs are page-aligned, as mentioned above.) > FREEMAINs (aka STORAGE RELEASEs) supposedly release GETMAINed storage. > But they do not release a page until *all* GETMAINed storage within it > has been FREEMAINed. Hence, e.g. MVCLs will continue to complete > successfully from one DSECT to another DSECT mapped over released > GETMAINed storage - not because this storage is still GETMAINed, but > because the page still contains some un-FREEMAINed storage and the page > therefore remains allocated and addressable (regardless of [some of] its > storage having been FREEMAINed) until *all* GETMAINed storage in it has > been FREEMAINed. >
Re: RENT binder option
No. It is a popular name. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/31/2021 12:58:55 PM: > From: "Bill Hitefield" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/31/2021 02:05 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > Is this the Dave Cole who wrote "Boney Fingers" - many years ago? > > Bill Hitefield > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Jim Mulder > > Sent: Tuesday, August 31, 2021 12:56 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: RENT binder option > > > > This is not the XDC Dave Cole. Dave Cole the musician > > was an MVS developer who worked on TSO/E (and was the developer of the > > PRINTDS command) and MVS/APPC. > > We did not discuss diagnostic techniques, but we did create a design that > > would have allowed the systems in a sysplex to safely share MVS/APPC TP > > Profile and Side Info data sets, while waiting in line for several > hours to get > > into the "Back To The Future" ride at Universal Studios in Orlando. > > Unfortunately, the funding to implement that design never happened. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
For *my* information? Contents Supervisor uses GETMAIN to obtain module storage. VSM is quite happy to allocate partial pages. It has been thus since before my time at IBM (42 years). I have to go with what Jor-el says at time 0:43 in this clip: https://www.youtube.com/watch?v=zUmMeS2c4Uw Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/30/2021 11:29:35 PM: > From: "CM Poncelet" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/31/2021 12:26 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > FWIW and FYI. > > A 31-bit instrucion is a 4-byte fullword address, as e.g. say at virtual > (DAT) address x'71234568'. > > The first 3 nybles (x'712') indicate the segment from which the LMOD's > storage/address has been allocated. > The next 2 nybles (x'34') are the offset to the page within the segment > that is allocated to the LMOD's address. > The last 3 nybles (x'568') are the offset within the allocated page of > the LMOD's instruction address, within the segment. > So a page, in nybles, is 16 x 16 x 16 = 4096 bytes or 4K - which is then > used to build the LMOD's virtual (DAT) address. > > Hence, the OS allocates whole - not partial - 4K pages to a load module > (LMOD). If the size of a REFR LMOD is < 8K but > 4K then the OS > allocates two 4K pages to it (both of which are then REFR protected). If > a page were partially occupied by a REFR LMOD but otherwise also > occupied by another LMOD, this would lead to situations where, say, a > 31-bit instruction at address x'71234568' could be part of a REFR LMOD > but at address x'71234800' could be part of some other LMOD - and would > imply that a same page had been allocated to more than one LMOD, which > from an addressability point of view would be absurd. > > In other words, pages are either fully allocated/occupied to or by a > REFR LMOD's code or they are not occupied by a REFR LMOD's code at all. > > HTH Cheers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
This is not the XDC Dave Cole. Dave Cole the musician was an MVS developer who worked on TSO/E (and was the developer of the PRINTDS command) and MVS/APPC. We did not discuss diagnostic techniques, but we did create a design that would have allowed the systems in a sysplex to safely share MVS/APPC TP Profile and Side Info data sets, while waiting in line for several hours to get into the "Back To The Future" ride at Universal Studios in Orlando. Unfortunately, the funding to implement that design never happened. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/31/2021 10:26:08 AM: > From: "Greg Price" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/31/2021 12:44 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > On 8/31/2021 11:35 AM, Jim Mulder wrote: > > Yes, I know the lines from that show from having > > played in the orchestra for it here: > > > > https://countyplayers.org/icpdb/shows/0502.html > > I expect you chatted about diagnostic techniques with Dave during breaks > in rehearsal... > > O-O > \_/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
Yes, I know the lines from that show from having played in the orchestra for it here: https://countyplayers.org/icpdb/shows/0502.html Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/30/2021 05:12:37 PM: > From: "Schmutzok, Mike (US - Georgia)" <02dd6b12f291-dmarc- > requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/30/2021 09:32 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > The movie, 1776? lol > > On the vote for Independence... > > "New York abstains, courteously." > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Jim Mulder > Sent: Monday, August 30, 2021 1:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RENT binder option > > ⚠ EXTERNAL MESSAGE – Think Before You Click > > > > New York responds, courteously. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RENT binder option
The undocumented TRAP name in DIAGxx was something I added at very low cost for my use. For documented things, we have a more extensive (and thus costly) process, including: - Design documents - Design document reviews - Formal testing - Interface Change Notification to software vendors - T3 Education for ESP customers - Service Education for Level2/Level3 And if we are changing a default behavior: - Migration Actions If I wanted to spend some serious $$$ on protecting the partial pages, I would look into creating a new subpool specifically for REFR modules, and changing IEWFETCH and the PMLoader to use real addresses for doing relocation (as the PMLoader does during page fault processing for a program object which uses deferred loading). Do you know all of the places in the documentation that need to be updated when adding a new subpool? I don't. But I have come across places that were missed when other subpools were added. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Discussion List" wrote on 08/30/2021 05:28:50 PM: > From: "Charles Mills" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/30/2021 08:51 PM > Subject: Re: RENT binder option > Sent by: "IBM Mainframe Discussion List" > > > RoundUp is a suspected carcinogen. > > Should have referenced a bug killer rather than a weed killer, no? > CsvSP252BlackFlag? > > > Document it. What's IBM trying to protect via obscurantism? > > Not having to document it LOL. I suppose not having to provide it on > an ongoing, "upward compatible" basis. > > Seriously, I agree with @Gil. Wasting a few bytes should be the > default, not leaving a few bytes unprotected. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Paul Gilmartin > Sent: Monday, August 30, 2021 1:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RENT binder option > > On Mon, 30 Aug 2021 13:10:50 -0400, Jim Mulder wrote: > > > > On a test system, you may specify the undocumented > >CsvSP252RoundUpTRAPS name in DIAGxx. For a module > >being loaded into subpool 252, that will round the length up to > >a 4K multiple. > > > Document it. What's IBM trying to protect via obscurantism? > (Cf. Tom Brennan's ply.) > > What's the harm in specifying CsvSP252RoundUp TRAPS on a > production system? I suspect: > > o Squandering a couple slack KiB for each module loaded. > > o Possible program checks in poorly implemented vendor products. > Conscientious vendors should be willingly repair those (what > would IBM do?) > > o RoundUp is a suspected carcinogen. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
