z processor primer version 3 released
https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/c-kevin-shum/2021/07/23/z-primer-version-3-release Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY
Re: Ensuring LRL 2nd operand alignment
I suspect that you did "IPL CMS" and are running in
ESA/390 Compatibility Mode.
First and most importantly, a client should not be
executing a z/Architecture-only instruction while in
ESA/390 compatibility mode. That is unpredictable
behavior and is definitely not intended to be used.
See POPS SA22-7832-12 p. 5-112, LHC:
If the program issues any other instruction that is
defined as being unique to the z/Architecture
architectural mode, it is unpredictable whether an
operation exception is recognized or the instruc-
tion executes according to its z/Architecture defi-
nition.
If you instead do "IPL ZCMS" so that you are
running in z/Architecture mode, I would expect
your LRL instruction to work.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Date:Fri, 30 Apr 2021 19:35:40 +
From:"Stanislawski, Shawn (National VM Capability)"
Subject: Ensuring LRL 2nd operand alignment
Trying to use the LRL(32) instruction ('C4D' / 'C4xD' opcode).
But running into: DMSABE141T Operation exception
-> 00DF5124 LRL C45D6832
*** 00DF5124 PROG0001 -> 0139B660OPERATION
Reading in the "zArchitecture Principles of Operation" (SA22-7832-12) =
"For LOAD RELATIVE LONG (LRL, LGFRL), the second operand must be aligned
on a word boundary,..."
Guessing alignment is the problem.
I know I can use a DS 0F to start the LRL instruction itself on a word
boundary,
but any ideas how to ensure that specifically the second operand of the
LRL instruction will always be aligned on a word boundary?
Fw: A Tale of Interleaving WTO messages
Upon further review, JES2 sets TCBNOIRB to prevent its IRB from being interrupted by another IRB, and its method of processing its message queue should keep the messages in order. Futhermore, I wrote a testcase to issue many LINKAGE=BRANCH WTOs, and I have not seen any instances of out of order messages in the joblog on a JES2 system. Are you using JES3? Are you sure that all of your WTOs specify LINKAGE=BRANCH? Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY Jim Mulder/Poughkeepsie/IBM wrote on 03/04/2021 03:09:21 PM: > From: Jim Mulder/Poughkeepsie/IBM > To: "IBM Mainframe Assembler List" > Date: 03/04/2021 03:09 PM > Subject: Re: A Tale of Interleaving WTO messages > > When the WTO LINKAGE=SVC is issued in the > Console address space, A broadcast SSI WTO call is done. > JES2 has a WTO function routine (that's how WTOs get into the > job log). The JES2 routine sees that it is running in the Console > address space, and thus it does not have addressability to the > job log control blocks and buffers in your job's address space. > So it schedules an SRB to your job's address space. The SRB > routine schedules an IRB to the initiator task in your address > space, and the IRB routine adds the message to your job log. > The dispatching and execution of the SRBs, and the > dispatching of the IRBs, for messages issued close together, > provides opportunity for the messages to not be added to the > job log in the same order as the branch entry WTOs. > > Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. > Poughkeepsie NY > "IBM Mainframe Assembler List" > wrote on 03/04/2021 09:13:09 AM: > > > From: "esst...@juno.com" > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Date: 03/04/2021 11:07 AM > > Subject: A Tale of Interleaving WTO messages > > Sent by: "IBM Mainframe Assembler List" > > > > . > > . > > Jim Mulder wrote, > > >When you do a WTO with LINKAGE=BRANCH, the request is added > > >to a message queue which is serviced asynchronously by a TCB > > >in the CONSOLE address, which issues WTO LINKAGE=SVC for > > >each queued message. So you should have no expectations > > >about the delivery ordering between a WTO with > > >LINKAGE=SVC and a WTO with LINKAGE=BRANCH. > > > > > > > > If all the WTOs with LINKAGE=BRANCH are submitted from the same address > > space and from the same TCB, why wouldn't these WTO messages arrive > > in sequence and get queued in the Console > > Address Space in the order they were submitted ? > > . > > Paul
Re: A Tale of Interleaving WTO messages
When the WTO LINKAGE=SVC is issued in the Console address space, A broadcast SSI WTO call is done. JES2 has a WTO function routine (that's how WTOs get into the job log). The JES2 routine sees that it is running in the Console address space, and thus it does not have addressability to the job log control blocks and buffers in your job's address space. So it schedules an SRB to your job's address space. The SRB routine schedules an IRB to the initiator task in your address space, and the IRB routine adds the message to your job log. The dispatching and execution of the SRBs, and the dispatching of the IRBs, for messages issued close together, provides opportunity for the messages to not be added to the job log in the same order as the branch entry WTOs. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 03/04/2021 09:13:09 AM: > From: "esst...@juno.com" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 03/04/2021 11:07 AM > Subject: A Tale of Interleaving WTO messages > Sent by: "IBM Mainframe Assembler List" > > . > . > Jim Mulder wrote, > >When you do a WTO with LINKAGE=BRANCH, the request is added > >to a message queue which is serviced asynchronously by a TCB > >in the CONSOLE address, which issues WTO LINKAGE=SVC for > >each queued message. So you should have no expectations > >about the delivery ordering between a WTO with > >LINKAGE=SVC and a WTO with LINKAGE=BRANCH. > > > > > If all the WTOs with LINKAGE=BRANCH are submitted from the same address > space and from the same TCB, why wouldn't these WTO messages arrive > in sequence and get queued in the Console > Address Space in the order they were submitted ? > . > Paul
Re: A Tale of Interleaving WTO messages
When you do a WTO with LINKAGE=BRANCH, the request is added to a message queue which is serviced asynchronously by a TCB in the CONSOLE address, which issues WTO LINKAGE=SVC for each queued message. So you should have no expectations about the delivery ordering between a WTO with LINKAGE=SVC and a WTO with LINKAGE=BRANCH. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 03/03/2021 06:07:33 PM: > From: "esst...@juno.com" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 03/04/2021 12:23 AM > Subject: A Tale of Interleaving WTO messages > Sent by: "IBM Mainframe Assembler List" > > Hello, > . > I need to understand why messages written to the JOB LOG, are > *NOT* displayed in the order they were issued. > , > Scenrio 1 > 10.39.38 DRIVER - Invoking Name/Token Services > 10.39.38 DRIVER - Name/Token Retrieved > 10.39.38 DRIVER - Call BAKR Routine > 10.39.38 FUNCTION - Enter > 10.39.38 FUNCTION - DEBUG DELAY > 10.39.38 FUNCTION - DEBUG DELAY > 10.39.38 FUNCTION - Transfer Complete > 10.39.38 DRIVER - Exit BAKR Routine > 10.39.38 FUNCTION - Structure Verified > 10.39.38 DRIVER - Last Function RC=00 > 10.39.38 FUNCTION - Function NTP_CALL Response Normal > 10.39.38 FUNCTION - Function ALESERVA Response Normal > 10.39.38 FUNCTION - Function ALESERVD Response Normal > 10.39.38 FUNCTION - Structure Verified SERVBLKL > , > . > Scenrio 2 > 16.10.54 DRIVER - Invoking Name/Token Services > 16.10.54 DRIVER - Name/Token Retrieved > 16.10.54 DRIVER - Call BAKR Routine > 16.10.54 FUNCTION - DEBUG DELAY > 16.10.54 FUNCTION - DEBUG DELAY > 16.10.54 FUNCTION - Enter > 16.10.54 FUNCTION - Transfer Complete > 16.10.54 FUNCTION - Structure Verified > 16.10.54 DRIVER - Exit BAKR Routine > 16.10.54 FUNCTION - Function NTP_CALL Response Normal > 16.10.54 DRIVER - Last Function RC=00 > 16.10.54 FUNCTION - Function ALESERVA Response Normal > 16.10.54 FUNCTION - Function ALESERVD Response Normal > 16.10.54 FUNCTION - Structure Verified SERVBLKL > 16.10.54 FUNCTION - SERVBLK Transfer Complete > , > . > , > I have two programs (1) a Driver Routine and (2) Various > Functions to be called, by the Driver module. > (The real program names have been changed to protect the Guilty) > , > , > The DRIVER Routine issues messages prefixed by the word "DRIVER". > The FUNCTION Routine issues messages prefixed by the word "FUNCTION". > , > The "Functions" really don't do much. > What I don't understand is why are there interleaving Messages > between the Driver and The Function execution. > , > . > The Driver Program Issues a LOAD for the Function Routine > The Driver Program issues a MODESET to supervisor state > The Driver issues BAKR instruction BAKR R0,R15 > Register 15 contains the entry point of the Function Routine. > . > The Function Routine issues a PR instruction to return control > to the Driver, when its processing is complete. > . > In Scenario 1 The ENTER message is the first message issued by > the Function Routine. > . > In Scenario 2 The ENTER message is the third message issued by > the Function Routine. > . > How is that possible ? > What is it that I don't understand ? > This is a Single TCB program (Task Control Bock) > There are no scheduling of SRBs or IRBs. > There ere NO ATTACH Macros issued. > . > Upon entry to FUNCTION > Register 1 is saved > Registers are not saved by FUNCTION since a Linkage Stack has been > created. > A storage OBTAIN is issued. > A WTO for the ENTER message is issued. > The WTO for the Function routine looks like: >WTO MF=(E,(R1)),LINKAGE=BRANCH > . > . > So Im am not understanding why in Scenario 1 the ENTER > Message appears as the first message issued by the Function > Routine, and in Scenario 2 the ENTER Message appears as the > third message issued by the Function Routine. > . > Also there are other interleaving messages issued by the Driver > Program while the Function Routine is still in control. > I don't understand why this occurs. > . > The Driver Routine does not get control until the Function > routine issues a PR instructions. Yet there are > interleaving messages issued by the Driver while The Function > Routine is in control. > . > .Is this a By-product of the BAKR instruction. > I dont thin so. > . > So what causes the interleaving of messages on the job log. > . > Paul > . > .
Re: security with storage allocation under z.OS
I am not dismayed. REFRPROT works exactly the way I intended it to work. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 11/16/2020 08:35:29 PM: > From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/17/2020 02:16 AM > Subject: Re: security with storage allocation under z.OS > Sent by: "IBM Mainframe Assembler List" > Conversely, there's REFRPROT to prevent storing into programs > marked REFR. Dismayingly, I believe REFRPROT is global and > intrduces incompatibility with "dusty deck" programs erroneously > marked REFR. > > -- gil
Re: security with storage allocation under z.OS
That is correct, a subpool has 2 SPQEs - one for EXECUTABLE=YES, and one for EXECUTEABLE=NO. In z/OS 2.3 and 2.4, we search only the SPQE for the EXECUTABLE attribute that you specify when releasing storage, In future release which follows z/OS 2.4, release processing has been enhanced to treat what you specify as a performance hint, and search that SPQE first, and then search the other one if necessary. So you will no longer need to specify EXECUTABLE correctly on the release, but you will get better performance if you do. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 11/16/2020 05:29:02 PM: > From: "Ngan, Robert" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/17/2020 02:03 AM > Subject: Re: security with storage allocation under z.OS > Sent by: "IBM Mainframe Assembler List" > > I found out the hard way that, if you code EXECUTABLE=YES of the > STORAGE OBTAIN, you must also code it on the associated STORAGE RELEASE. > Evidently, it's implemented as a subpool under the covers, so like > subpool getmains, you must have matching values on OBTAIN and RELEASE. > > Robert Ngan > HCL Technologies
Re: Deep Cuts
Z provides detection of dereferencing 0 via PER ZAD, which is controlled by SLIP ZAD on z/OS. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 09/09/2020 05:30:32 PM: > From: "Charles Mills" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 09/10/2020 11:34 AM > Subject: Re: Deep Cuts > Sent by: "IBM Mainframe Assembler List" > > I think faulting on dereferencing 0 is a hardware function and yes, > most hardware does so. Not so Z, where traditionally much of the > "API" is chained off of the PSA. > > Z faults on references to (in the assembler vernacular; de- > referencing in the C vernacular) x'800' and immediately above, > right? (Do I have that address right?) > > Z faults (usually, for an application) on writes to 0: *((char > *)NULL) = 'A'; > > Charles
Re: Clearing a register
A useful link to post periodically, which discusses register clearing on slide 51: https://community.ibm.com/HigherLogic/System/DownloadDocumentFile.ashx?DocumentFileKey=d1cdb394-0159-464c-92a3-3f74f8c545c4 Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY
Case Study: IBM SYSTEM/360-370 ARCHITECTURE (1987)
https://www.cs.tufts.edu/comp/150FP/archive/alfred-spector/spector87ibm.pdf Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY
Re: Questionable Instructions in Obtaining EAX documentation
MVS/370 also used absolute zero for the IPL processor. In MVS/XA, we changed to use a non-zero prefix for every processor. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 11/12/2019 01:51:22 PM: > From: "Seymour J Metz" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/13/2019 01:14 AM > Subject: Re: Questionable Instructions in Obtaining EAX documentation > Sent by: "IBM Mainframe Assembler List" > > I don't know about MVS, but OS/360 support for 65MP used absolute > address 0 for one processor. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > From: IBM Mainframe Assembler List > on behalf of John McKown > Sent: Tuesday, November 12, 2019 9:49 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Questionable Instructions in Obtaining EAX documentation > > On Tue, Nov 12, 2019 at 8:43 AM Tom Marchant < > 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > > > >I cannot fathom the reason to use _any_ base for the PSA other than GPR0. > > >It is simply wasteful of a scarce resource. > > > > It isn't "the" PSA. There is the PSA of the processor that you are running > > on. > > That PSA is always at location 0. > > > > True. I left out the words "of the processor". I guess that I ASSuMEd that. > > > > > > > Every processor in the LPAR has its own PSA, and when the processor is > > running, > > that PSA is at real (and virtual) location 0 for that processor. The PSA > > for any > > other processor can also be referenced using the real address that matches > > the > > value that is used for the prefix register for that processor. This is > > documented > > in the Principles of Operation under "Prefixing". > > > > I know. But I have never wanted to look at the PSA of any CP other than the > one that I am running on. I'm not really sure why I would. Do you know of a > reason to do so? I am curious. > > > > > > > You cannot use the value in the prefix register for your own processor to > > reference > > your PSA though. That would get you to absolute page 0, which, if I > > understand > > correctly, MVS never uses. > > > > That's interesting. So z/OS and it's ancestors have never really used > absolute page 0. I guess it doesn't really matter since it is a small > amount of physical storage in today's world. Actually, I thought absolute 0 > was used as the PSA for the IPL processor, but that, again, was an > assumption. > > > > > > > -- > > Tom Marchant
Re: Vector enablement control?
The question you really want to ask is "how should I determine if the task under which I am running has used already used vector instructions"? The answer is to look at PSAVSS or STCBVSS (which are classified as Programming Interfaces). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 10/31/2019 01:30:13 PM: > From: "Ngan, Robert" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/01/2019 11:36 AM > Subject: Vector enablement control? > Sent by: "IBM Mainframe Assembler List" > > With the new COBOL compilers capable of generating vector > instructions for handling packed fields, I'm looking at modifying > our ESTAE routines to dump the contents of the vector registers. > The PoOPs says you should not issue a vector instruction unless both > the vector enablement control and AFP-register control bits in CR0 are on. > If you're running z/OS on a z13 of higher (i.e. your machine a > vector instruction support), would either of these two bits ever be off? > > From a standard ESTAE routine, I can examine the CR0 contents from > the SDWA, but in a CICS ABEND exit, I don't have access to CR0. > > Robert Ngan > HCL Technologies
Re: Multi CPU interlock question
The coordination with other CPUs is in getting exclusive control of the storage operand cache line. CS and ST both have to do that, so they would be similar in performance in that regard. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Charles Mills" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 01/10/2019 01:04 AM > Subject: Re: Multi CPU interlock question > Sent by: "IBM Mainframe Assembler List" > Avoid CS if you don't need it (and in this case you don't). CS is > expensive because every CPU has to sit up and take notice.
Re: Multi CPU interlock question
CS/CSD/CSG/CSDG would be considerably faster than PLO. CS is implemented in hardware. PLO is implemented in millicode. The millicode obtains a spin lock, performs the requested operations, and releases the lock. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Charles Mills" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 01/10/2019 12:59 AM > Subject: Re: Multi CPU interlock question > Sent by: "IBM Mainframe Assembler List" > > Take your pick of answers: > > 1. I don't know. > 2. It probably depends on the model. > 3. It probably depends on what exactly is going on with the cache, > contention, etc. > 4. I am going to guess the CS is cheaper than PLO because it is simpler. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [ mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Seymour J Metz > Sent: Wednesday, January 9, 2019 11:52 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Multi CPU interlock question > > How does the cost of CS/CDS compare to PLO? >
Re: IEATDUMP MF=L Can someone explain this?
I suppose the way one groups the letters would be influenced by one's own habits. I would expect that experienced z/OS programmers would know that for the past few decades, new macro names follow the same convention as module names and message IDs by starting with the 3 character prefix of the owning component. IEA - component prefix T- Transaction DUMP - Dump Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 08/26/2018 01:07 AM > Subject: Re: IEATDUMP MF=L Can someone explain this? > Sent by: "IBM Mainframe Assembler List" > Who thinks up these macro names, anyway? That one wouldn't pass muster > as a California vanity license plate.
Re: Fair comparison C vs HLASM
Here in the MVS development shop, we test and debug the code compiled at the optimization level with which it will be shipped. Doing otherwise would mask the source code bugs which have consequences only at a higher optimization level, and would also mask the compiler code generation bugs which are only present at the higher optimization level. Your suggested techniques might make sense for simplistic environments where all of your problems can be recreated with an unoptimized compiles while running under an interactive debug tool. We certainly do not have that luxury in the operating system. Since we are routinely working with dumps, we have a great need to understand the translation from the source code language to the assembler or machine code. PL/X is compiled into assembler source code. We depend heavily on the PL/X compiler to generate symbol names which are relatable to the variable and field names in the source program, to aid us in understanding the translation. Fortunately for me, I don't deal much with C. My limited dealings with the pseudo-assembler listings generated by the IBM C compiler suggest that the IBM C compiler really sucks in that regard, at least compared to PL/X. With regard to the effects of optimization on understanding the translation, that can be a mixed bag. Some optimizations (especially those that move things a long distance) can increase the degree of difficulty. Others that reduce the amount of generated code by avoiding a lot of register reloading can make things easier, especially when you are tracing your way though some code (since there is less of it to trace). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List wrote on 01/31/2018 04:03:34 AM: > From: Robin Vowels > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 01/31/2018 12:23 PM > Subject: Re: Fair comparison C vs HLASM > Sent by: IBM Mainframe Assembler List > > From: "Keith Moe" > Sent: Tuesday, January 30, 2018 11:08 AM > > > > One of the downsides to such great optimization is the added > difficulty in debugging. > > Such optimisations are rarely requested during debugging, > when all the facilities of the compiler - such as subscript bounds checking, > check for uninitialized variables, etc, are employed. > > > Programs will often have code that leaves footprints and saves > various values > > in work areas for diagnostic reasons. > > They might, but at run time, should an error occur in a PL/I program > the error-recovery unit can print the values of any requested variables. > > Also, for diagnostic purposes (either during debugging or during production), > values can be written to a file. > > > Many optimization algorithms will detect > > that these area are "never referenced" after being set and eliminate > > the code that sets or stores these values. > > See previous note. > > > Another optimization that makes debugging difficult is the > inlining of subroutines > > that are only called in one place to save the overhead of the linkage. > > But the generated mapping of the source to the generated machine > code/assembler > > does not match the original source statements to the generated machine code. > > I suppose it is possible, but the PL/I optimising compilers clearly > show where any moved code is placed. This is shown in the > assembler listing. > > > Sure, there are various tricks that can be done to prevent such > optimization, > > Such as not requesting optimising. > > > but that partially defeats the value of using a high level > language when you have to think about > > how to defeat it. > > > When you spend a lot of time debugging problems occurring in > customer production environments, > > life can be difficult. > > See earlier note about printing values from the error-recovery unit. > > > Optimization is great until it isn't! > > Keith Moe > Lead Developer > BMC Software, Inc. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >
Re: Fair comparison C vs HLASM
Much of MVS is written in a compiled language (PL/X and its predecessors), and I have spent the past 38 years making a living by debugging it using dumps. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List wrote on 02/01/2018 09:03:37 AM: > From: Charles Mills > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 02/02/2018 01:00 AM > Subject: Re: Fair comparison C vs HLASM > Sent by: IBM Mainframe Assembler List > > > The last time I used a dump to find bugs in a compiled program was > about 35 years ago. > > Right! I think if you are using a classic "core dump" to find logic > errors in a compiled language program then you are doing something wrong. > > To find an error in some big table or something, sure, but then the > arrangement of the compiled machine instructions should not matter. > > Charles > > > > On Wednesday, January 31, 2018 1:00 AM, Robin Vowels > wrote: > > ... > > The last time I used a dump to find bugs in a compiled program was > about 35 years ago. > PL/I provides all the information required because it has debugging > facilities built in. >
Re: Just Testing - It got very quiet
PLO and CS have very different performance characteristics. CS is a hardware instruction which which performs the serialization by maintaining exclusive access to the cache line containing the operand. PLO is like a software disabled spin lock, but implemented in millicode. Millicode obtains the spin lock, performs the requested operation, and releases the lock. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > PLO is CS on steroids. I can give you specific examples just let me > know what you are looking to do. PLO works well with linked list > node inserts and deletes. It does take a number of instructions of > prep work to fill the PLO parameter block if you are using the > triple store operation.
Re: Question about CPUs
There was no performance cost to of making NI, OI, and XI atomic. The implementation of the newer machines already happened to work that way, and the engineers were willing to commit to maintaining that behavior on future machines, so the behavior was added to the architecture. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > What was the performance cost of making NI, OI, and XI block-concurrent? > I suspect many programs will never rely on this behavior, and have never > used tne NIL and OIL macros, yet will bear the burden of any overhead.
Re: Question about CPUs
Such questions are best answered by reviewing the topic "Block-Concurrent References" in Principles of Operation. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: Phil Smith > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 07/31/2017 02:21 AM > Subject: Re: Question about CPUs > Sent by: IBM Mainframe Assembler List > > Charles Mills wrote, in part: > >The effect of multiple CPUs on a multi-task program is even worse than the > >load, add, store example above. With two CPUs, it is possible for even > >single machine instructions to interleave. So if one task executes MVC > >FOO,=C'Now is the time for all good men to come to the aid of the party' and > >another CPU executes MVC FOO,=C'The quick brown fox jumps over the lazy dog' > >it is at least in theory* possible for FOO to end up containing 'Now is the > >time fox jumps over the lazy dog the aid of the party'. > > Mmm...I'm pretty sure a single instruction is still atomic. I'm sure > Peter Relson or one of the other IBMers will chime in, but it there > has to be some sort of interlock at some level. And I've debugged > plenty of concurrency problems, never seen a mixture from a single > instruction! > > ...phsiii
Re: IBM Diassembler
> > Can the IBM disassembler be invoked > > By a another method then submitting a job > > The disassembler I use most often these days is IPCS. > > IP LIST address INSTR can disassemble any code found in a dump or active > memory. IPCS invokes the IBM Assembler's disassembler. Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. Poughkeepsie, NY
Re: Microprocessor Optimization Primer
> > Can I infer from this that XR/XGR, all else being equal, is to be > preferred (slightly) over LHI/LGHI? > > If so, why might that be? I would have thought the one that > doesn't touch the CC would be "more efficient" than the one that does. > > Or am I misreading your statement? > > > Instruction fetch bandwidth? Perhaps "don't care about the CC" > implies that no instruction testing CC might be in the pipeline > so lockout is not a concern. Response from engineering: It all depends how complicated you want to scheduling algorithm to be. If cc being set to 0 is not a problem for scheduling surrounding code, then XR(XGR) will likely be better because of its shorter instruction lengths. On cc-usage, if it may be more optimal to keep a sequence of CC setting instruction .. clear register .. cc using instruction; then L(G)HI can be used. In general, 4-byte instruction is handled quite well and just like 2-byte, except may be on line-crossing. In the case where super-optimal grouping is key, like within a hot loop, then the 2-byte instruction potentially can allow better grouping opportunity depending on the instruction lengths of other instructions and addresses. A 2-byte instruction provides an ease-of-mind scheduling because it will always allow maximum grouping. On the other hand, before we had the "fastpath", I believe the source register was treated as a dependency, so in a hypothetical sequence of: L R1, (mem) AR R2, R1 XR R1,R1 the XR would have waited for the L. However, with the latest fast-path, that is not a concern. So, the complicated algorithm can be: if no cc scheduling conflict, and (pre-zEC12) no immediate earlier setter of GR, then X(G)R should be used; otherwise, it might be better to use L(G)HI. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Microprocessor Optimization Primer
This may be of interest to some of you: https://www.ibm.com/developerworks/community/forums/html/topic?id=5cf34211-c8e6-4747-a8c2-f8ff7379150b Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Using macro to set assembler option
> > REFRPROT in PROGxx causes REFR load modules and program objects > > to be loaded into key 0 storage, and the full 4K pages are page > > protected. RSECT is not involved. I would expect that the > > individual unprivileged programmer has control over whether he > > specifies REFR when he binds his program. > > > But he can not assure that they get loaded into protected > storage. That's up to the administrator. The administrator should be specifying REFRPROT in PROGxx. The only reason we made it an option was concern that an installation might have self-modifying programs which were incorrectly had the REFR attribute, and we didn't want that to be a migration issue for z/OS 1.9, where REFRPROT was introduced. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Using macro to set assembler option
> > Perhaps I'm forgetting something, but IIRC, as far as the binder and z/OS > > itself is concerned, RSECT matters only for CSECTs in IEANUCxx where they > > are put into the read-only nucleus. It is ignored for all other > > situations. > > > Isn't there for several releases a REFRPROT option (in PARMLIB?) > that causes any REFR CSECT to be write-protected? But this is > the sort of thing where the individual unprivileged programmer > ought to have control, subject to installation defaults and > overrides. REFRPROT in PROGxx causes REFR load modules and program objects to be loaded into key 0 storage, and the full 4K pages are page protected. RSECT is not involved. I would expect that the individual unprivileged programmer has control over whether he specifies REFR when he binds his program. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: BSA (Branch and Set Authority)
> I decided to start looking at the BSA instruction as part of a solution > to accessing memory in various keys using key 0. > > I'm running a reentrant program from an authorized library (so it's > loaded in key 0) in problem state; I get a S0D3 abend, which I assume is > PIC 13 Special Operation exception, executing the following code: > > LARL R6,BSA_RAAddress for reduced authority routine > OILH R6,X'8000' Mark address 31-bit > LLILF R5,X'00C00090' preserve PKM, switch to Key 9 > BSA R5,R6Off to Reduced Authority routine > > BSA_BA DS0H Return to base authority > ... > > > BSA_RA DS0H Reduced authority routine > SRR6,R6zero R6 in order to return > BSA R5,R6Return to base authority > DCX'00DEAD00' If something unpredicted happens > > I abend S0D3 in the BSA_RA routine on the BSA instruction. Until I had > the program in key 0 memory, I abended S0C4 as I entered the BSA_RA > routine at the SR R6,R6 instruction because the program was loaded in > key 8 fetch-protected memory. > > The only reason listed for a Special Operation exception for BSA is if > R6 is non-zero when returning to base authority. And the dump shows it > is zero, and PSW is not updated with the address of BSA_BA. > > Does anyone have any ideas of what probably obvious thing I'm missing here? Reconsider your interpretation of "When BRANCH AND SET AUTHORITY is executed in the reduced-authority state, as indicated by the reduced-authority (RA) bit in the DUCT being one, R2 must be zero; otherwise, a special-operation exception is recognized." And then try BSA R5,0 Return to base authority Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Change in GETMAIN behavior
> > APAR OA27291 describes the change in GETMAIN that was introduced in > > z/OS 2.1. It results in better performance of GETMAIN. A side > effect is that is > > that there is somewhat more chance that a request will be satisfied from a > > location that had been previously obtained and then freed. > > > Is it "more chance", or simply that the hazard is shifted to a different > sequence of GETMAINs? As the designer and implementer of the z/OS 1.10 change, I would say that it creates some additional circumstances where a request (or part of a request) can be satisfied from a location which contains residual data from a previous use. "More chance" is may be a reasonable way to say that colloquially. But yes, the actual behavior depends entirely on the sequence of requests. There is no randomness involved. > Why does the option for "dirty" GETMAIN (I forget the correct name) remain > undocumented, despite its value for testing? IGVINITGETMAIN is the TRAP name. It was designed and implemented as a one person, unfunded, spare time project, by me, to meet some my needs for testing purposes. There were none of the design and externals reviews that are done for the normal development process of documented functions. Low implementation cost, affecting only system components in which I was sufficiently experienced to dabble (which does not in JCL converter/interpreter), was essential. Not being an officially documented function shields it somewhat from complaints about the usability of the externals, complaints about what it does and doesn't do, and requests for enhancements. Also, use of this kind of test tool can cause unexpected damaging system effects. In one case years ago, it exposed a bug which caused corruption of an HSM control data set. Even on a test system, that was pretty disruptive, and it quite a bit of effort for the ISV who encountered this misfortune, working with HSM level 2 support, to salvage his HSM environment. > Why is that option system-wide rather than being available with JOB scope > (option on the JOB statement) or job step scope (option on the EXEC statment)? > I'd use it for testing if it were available to me. See above. Or, to quote from "Man of La Mancha": Don Quixote: "We waited, sire, for a dwarf to mount the battlements... and announce us, but none appeared." Innkeeper: "The, uh, the dwarfs, they're all busy." Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Question of curiosity: Why are IVSK and TPROT instrictions privileged?
> I happened to be browsing PoOPS for another reason and noticed that > TPROT is a privileged instruction. Reading the instruction details > I couldn't really see any particular security exposure that could > result from TPROT being usable in a non-privileged mode by > unauthorized programs. > > Reading about TPROT led me of course to IVSK, which is needed to > extract the access and fetch bits for the block of storage to be > tested with TPROT. Same question there, why is it privileged? It > would seem that it is privileged because it is subject to the > extraction-authority control, bit 36 of control register 0, which > can obviously only be set by a privileged program like the operating > system code. > > But why protect IVSK so closely (and probably by implication TPROT)? > It would seem to me to be an obvious boon to careful programmers > willing to code tests of their input argument addresses to verify > that those addresses can be fetched from, and possibly also for some > argument addresses whether they can be stored into. > > I really can't see the security exposure here. Can anyone explain > the privilege requirement to me? In VM/370 (that is, prior to the invention of SIE in the 370/XA architecture), VM guests always ran in real problem state (even when they were in virtual supervisor state), so that VM could use the privileged-operation exception to intercept instructions which it needed to virtualize. TPROT was certainly an instruction which VM needed to intercept. After SIE in 370/XA, VM would no longer have needed to restrict TPROT to supervisor state. But we would have no way of knowing what other programs might have depended on it. Prior to BAKR/ESTA and EPSW, a program which wanted to determine whether it was running in problem vs. supervisor state might have issued a privileged instruction to see if it caused a privileged-operation exception (which it could intercept in an ESTAE). If the program happened to have chosen TPROT for that purpose, and TPROT had been changed to allow problem state use after SIE came along, that incompatible change to TPROT would have broken the program. I am not aware of any security reasons for restricting TPROT. As someone already posted, z/OS always turns on CR0.36, thus always allowing IVSK in problem state. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Debuggers
> What debug tool are you using for debugging your assembler programs? Mostly, SVC dumps, Stand-alone dumps, and IPCS Sometimes, VM. Occasionally, TSO TEST. Since "my assembler programs" is mainly the guts of the operating system, that limits my choices a bit. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: IPCS error
> I was trying to open a dump dataset using IPCS 2.2 but it ended with below > message. > > System ABEND 878, reason code 0010 > PSW 070C1000 814F7878, module IEANUC01, CSECT IGVVSERR, offset 0E40 > Instruction area 00181610 0A0D18CE 18FB180C > GPR 0R 8400 1R 84878000 2R 7F809C10 3R 0002 > GPR 4R 007F8E78 5R 007933D0 6R 814F2830 7R 00FC5700 > GPR 8R 9R 7FFF4000 10R 11R 7F809970 > GPR 12R 4000 13R 000A0348 14R 3A9D53AC 15R 0010 > System abend code 878, reason code 0016. > Abend in host command SELECT or address environment routine ISPEXEC. > > I was able to open another DUMPS but it just ends only for a specific > dataset. > > z/OS : 2.1 Register 9 contains the size of the request (x'7FFF4000'), which is too large to be statisfied, regardless of your region size. That is likely due to a programming error in IPCS-related code, or something anomalous in the dump. A dump of the 878 abend would be needed for further diagnosis. I don't normally use the IPCS 2.x panels (I issue the IPCS command I want directly). I tried 2.2, and it looks like it is doing ANALYZE STATUS SYSTEM STATUS FAILDATA STATUS CPU REGS You could try those one at a time to see which one fails. Most likely it is ANALYZE - that entails some complex processing which is dependent on a lot of dump data. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: SNAP macro for storage above the 2G bar?
> I have been reading up on the SNAP macro for some debugging efforts > I need to accomplish, but it seems to me from RTFM that SNAP only > supports 24- and 31-bit addresses for the STORAGE, LIST and STRHDR operands. > > Assembling a SNAP macro with "SYSSTATE ARCHLVL=2,AMODE64=YES" does > not modify the size of the address fields in the SNAP parameter > list, which leads me to believe that 64-bit addresses are just not supported. > > Am I correct in my deduction? If so, how would I go about getting > the equivalent of a SNAP for storage above the 2G bar? SNAP was functionally stabilized more than 25 years ago, when it was decided to not enhance it to dump data space storage when data spaces were introduced in MVS/ESA SP3.1.0e. Some IPCS formatting code also runs under SNAP, so SNAP does inherit enhancements that code for free. But the code which is unique to SNAP gets almost no development attention, other than fixes to defects. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: WAVV2010 Presentation
> From: "esst...@juno.com" > To: ASSEMBLER-LIST@listserv.uga.edu > Date: 08/07/2014 01:17 AM > Subject: Re: WAVV2010 Presentation > Sent by: IBM Mainframe Assembler List > > I realize the presentation was not z/OS specific - So Yes I am > curious if this technique would be available on z/OS. > > -- Original Message -- > From: Chuck Arney > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: WAVV2010 Presentation > Date: Wed, 6 Aug 2014 08:19:14 -0500 > > Remember that WAVV is a z/VSE, z/VM And LINUX conference. I do know > the author of the presentation and he runs z/VSE. So I'm sure what > you see there applies to z/VSE and not necessarily to z/OS. > > Chuck Arney > Arney Computer Systems > zosdebug.com > > > > On Aug 6, 2014, at 7:48 AM, "esst...@juno.com" wrote: > > > > I discovered a presentation from 2010 > > WAVV 2010 > > KEY15 vs KEY0 > > Author unknown > > > > This presentation provided some source code which I found intresting. In general, under z/OS, code which is not part of the z/OS BCP should never be doing a LCTL or LCTLG instruction. So it would be very unwise to do this even if it sometimes seemed to produced the desired results. In particular, the z/OS documentation for the MODESET macro makes it very clear that this would never work under z/OS: ,MODE=PROB, MODE=SUP Specifies that the PSW problem state indicator (bit 15) is to be either turned on (PROB) or turned off (SUP). If the MODESET operation completes with a problem state PSW, the caller?s PSW key mask (PKM) is set according to the following rules: ?The bit matching the resulting PSW key is set on. ?The bit matching key 9 is set on. ?For a task attached with ATTACHX using the KEY=NINE parameter, the bits that were on in the PKM of the ATTACHX issuer are set on. ?All other bits are set off. If the resulting PSW is in supervisor state, the caller?s PKM is unchanged. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Local Time conversion to/from UTC Time
> Does it also fail to provide a table of historical CVTLDTO values? > If so, it's an hour off a mere few months ago, on the other side of > the Daylight Saving Time boundary; so much worse. > > > If your program requires historical correctness, it could maintain a > > historical table of leap second values, and compute the difference > > between the number of leap seconds in effect at the date of your > > historical TOD value and the number of leap seconds for the > > current date. Convert that number of seconds of difference to timer > > units (by multiplying by 1,000,000 (microseconds per second) * > > 4096 (timer units per microsecondsecond) ).Add this number of > > timer units to your historical time stamp, and pass the result to > > STCKCONV. > > > Why should each programmer need to do this? Some of them are sure to > get it wrong. Better such a table should be incorporated in STCKCONV. > > But, have you checked the source code? My test program shows > (CONV is my macro to use > STCKCONV STCKEVAL=&STCKEVAL,CONVVAL=PK, x >DATETYPE=MMDD,TIMETYPE=DEC,MF=(E,SPLIST) > to convert then format and print the STCKE argument.) > * > * Circa December, 2008 Leap Second 24, per PoOp. > * > CONV =X'00C3870CB9BB5FFF' > CONV =X'00C3870CB9BB6000' > Prints: > 2009-01-01 00:00:23.99 > 2009-01-01 00:00:24.00 > ... off by 24 seconds because our site runs with CVTLSO=0 because > too much software from vendors (including IBM) yields inconsistent > results with CVTLSO set correctly. Well, I did check the code, but not carefully enough. The code in question is used by both the TIME macro when LINKAGE=SYSTEM is specified, and the STCKCONV macro. Upon closer inspection, the code dealing with CVTLSO and CVTLDTO is on a path used only for TIME with LINKAGE=SYSTEM. STCKCONV does not do anything with CVTLDTO and CVTLSO, or attempt any kind of leap second or time zone adjustment. The caller must make any such desired adjustments before calling STCKCONV. > * > * End of the World. > CONV =X'0100' > CONV =X'01FF' > Prints: > 1900-01-01 00:00:00.00 > 2042-09-17 23:53:47.370495 > ... showing mostly that STCKCONV (as of z/OS 1.13) has not yet > implemented the (proposed) use of the high byte of STCKE when > the ETOD clock wraps. In z/OS 2.1, STCKCONV does handle x'01' on the high byte of an STCKE value (thanks to Peter Relson). > * > TIME STCKE,CLK5,LINKAGE=SYSTEM,MF=(E,W.TPLIST) > CONV CLK5 > * > STCKE CLK5 > CONV CLK5 > Prints: > 2014-07-09 23:05:44.299901 > 2014-07-09 23:05:44.299921 > ... the job log shows "17.05.44 JOB05935 $HASP395 HELLOENDED" > Hmmm... Our CVTLDTO here in sunny Colorado today is -6 hours. > It appears that STCKCONV is *not* applying CVTLDTO. (And I've > learned that the conversion took 20 microseconds.) > > But, I believe that when programmers as sophisticated as you and > I (I'll not presume to call myself in your class) can have > misconceptions about the operation of STCKCONV, Peter Relson is > wrong to call it "common knowledge", not needing further explanation. > > It does give correct GMT for dates prior to 1972. Perhaps someone > merely forgot to update it when UTC came on the scene. I don't know that I have ever been considered to be a "sophisticated programmer" - mostly known around IBM as a dump reader. I haven't ever used STCKCONV - it did not exist until SP4.1.0 (around 1990), so the code I have worked on which needs to do timestamp conversion (mostly code which runs under IPCS) instead uses the BLSUxTOD services supplied by IPCS. The BLSUxTyD services also do not do any leap second or time zone adjustments. I just looked into STCKCONV today to try to answer your questions while Peter is on vacation. If you feel that the STCKCONV documentation should be updated to explicitly say that STCKCONV does not do any leap second or time zone adjustments, I would suggest submitting a Reader's Comment Form. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Local Time conversion to/from UTC Time
>Current UTC is got by subtracting the correction in CVTLSO from the >value returned by STCK. I know of no z/OS supplied facility that >correctly converts historic TOD values to UTC. (It's not clear >whether STCKCONV does this; IBM refuses to provide detailed documentation >of the behavior of STCKCONV, calling it "common knowledge". IMO, >"common knowledge" without even a citation is a shabby alternative >to documentation.) I will tell you exactly what STCKCONV does. It subtracts CVTLSO (obtained from the CVT of the system where STCKCONV is being executed) from the input you provide, It then adds CVTLDTO. STCKCONV has no knowledge of historical leap second values. z/OS obtains the current value for CVTLSO from the machine via an internal ETR/STP interface. This interface does not provide a table of historical values. If your program requires historical correctness, it could maintain a historical table of leap second values, and compute the difference between the number of leap seconds in effect at the date of your historical TOD value and the number of leap seconds for the current date. Convert that number of seconds of difference to timer units (by multiplying by 1,000,000 (microseconds per second) * 4096 (timer units per microsecondsecond) ).Add this number of timer units to your historical time stamp, and pass the result to STCKCONV. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY(845) 435-4741 (T/L 295) M/S P351
Re: Clearing a register
> > Response from hardware designer: > > > > Here are some thoughts on the best way to zero a register. > > > > First, on the z196 and prior generations, all of the common > > instructions for zeroing a register are actually executed in the > > fixed-point execution unit. Starting with the zEC12 generation > > the following instructions are actually "executed" in the > > register renaming stage of the pipeline (where "R" is the > > same register number for a given instruction): XR R,R; SR R,R; > > SLR R,R; LA R,0(0,0); LHI R,0 (plus other small constant values); > > LGHI R,0 (plus other small constant values); SGR R,R; SLGR R,R; > > XGR R,R; IIHF R,0; IILF R,0. > > > > On the z196 and earlier processors, since they are actually > > executed, use of an XR or SR may set up an unnecessary register > > dependency. For example: > > > > AL 5,MEM1 Using GR5 for some prior calculation > > ST 5,MEM2 > > ... > > XR 5,5 This instruction is dependent on the AL > > > > So although the XR will zero the register, regardless of its > > prior value, it still appears to be dependent on the AL so > > it can not execute early. > > I would say that XR is dependent upon the ST instruction, > because it cannot execute until ST has finished with register 5. > > > Other points of interest...the XR/SR/SLR are 2-byte > > instructions so they have a smaller instruction footprint, but > > this is a second or third order performance effect in most > > cases. The IILF/IIHF are 6 byte instructions, so there would > > be little reason to use them. > > > > To conclude, the LHI and LGHI are probably the best overall > > instructions for clearing a register on any generation processor. > > Referring to your 3-instruction example directly above, > LHI is no better than SR, for it cannot be executed until the > ST has completed. The shortest instructions are therefore > to be preferred. Perhaps I did not identify my information source clearly enough. The hardware designer who provided the response I quoted is Tim Slegel, IBM Distinquished Engineer, a lead hardware processor designer for several generations of IBM mainframe machines. It seems unlikely that you would be more expert in the internal implementation of these machines than he is. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Out of Order and Superscalar - small experiment
> XR Rn,Rn is faster than SR. > But does it matter? > Such an instruction should be executed only once, and once only. > It shouldn't be in the loop. Response from hardware designer: Here are some thoughts on the best way to zero a register. First, on the z196 and prior generations, all of the common instructions for zeroing a register are actually executed in the fixed-point execution unit. Starting with the zEC12 generation the following instructions are actually "executed" in the register renaming stage of the pipeline (where "R" is the same register number for a given instruction): XR R,R; SR R,R; SLR R,R; LA R,0(0,0); LHI R,0 (plus other small constant values); LGHI R,0 (plus other small constant values); SGR R,R; SLGR R,R; XGR R,R; IIHF R,0; IILF R,0. On the z196 and earlier processors, since they are actually executed, use of an XR or SR may set up an unnecessary register dependency. For example: AL 5,MEM1 Using GR5 for some prior calculation ST 5,MEM2 ... XR 5,5 This instruction is dependent on the AL So although the XR will zero the register, regardless of its prior value, it still appears to be dependent on the AL so it can not execute early. Other points of interest...the XR/SR/SLR are 2-byte instructions so they have a smaller instruction footprint, but this is a second or third order performance effect in most cases. The IILF/IIHF are 6 byte instructions, so there would be little reason to use them. To conclude, the LHI and LGHI are probably the best overall instructions for clearing a register on any generation processor. I can not imagine we would ever design a machine where these instructions were not at least as fast as XR/SR/SLR for clearing a register, and they have some benefits on prior models. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Program Call Vs SVC
> Just wondering. > What hardware first supported PCs? The 3033 (via a microcode upgrade) was the first processor to support the 370 cross memory architecture, including the PC instruction. This architecture was first used by MVS SP1.2 (which never became generally available) and SP1.3. These releases included a cross memory architecture simulator in the program check interrupt handler so that they could run on older machines which did not support this architecture. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: YREGS MACRO doc?
>I have been looking for where YREGS is documented. I found YREGS > (a MACRO) in SYS1.MACLIB along with other good stuff.It does the > EQUates for the Registers. I see all the old "R0 EQU 0" in a > program I have and I'm sure YREGS will work fine. But where is it > documented as something that will stay around? A search of bookshelf z/OS V1R13 Base Elements Optional Features (September 2012) finds no documentation for YREGS, but does find a few sample programs which use YREGS. Googgling the program number 5695-DF1 found in YREGS's copyright indicates that YREGS is owned by DFSMS. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Amode 64 mainline code , SETRP from an estae with a RUB
> I saw that in the manual. So, if I am running in problem state, > Key 8, can I update the SDWA before executing the SETRP? The SETRP macro always expands into inline code which updates the SDWA. Anything it can do, you can do. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Amode 64 mainline code , SETRP from an estae with a RUB
> I am in the process of moving some data areas above the bar. Is > there a way to update registers for retry specifying a 64 bit register > value? I don't see this in the fine manual. Am I missing something > obvious? RUB is not applicable to 64-bit registers. The manual says: If you are running in z/Architecture mode and specify RETREGS=64, the 64-bit GPRs at retry are restored from SDWAG64 and the ARs are restored from SDWAARSV. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: DS 0H
>When we got our graded projects back, he got 45/50. I got 48/50. I lost two >points for: >1) Using EQU * on labels (no DS 0H in SuperPet assembler) >2) Using the condition code as a return value from subroutines that were >testing for exactly one condition >I pointed out to the professor (who of course had not done the marking -- >that's what grad students are for) that this was bogus, that both were >perfectly reasonable (even recommended) practices in assembler. He shrugged >and said "48 out of 50 is pretty good". Let's not be too hard on grad students who grade assembler projects to pay their tuition. I can tell you from experience that is pretty mind-numbing to spend all night reading and grading 60 assembler programs that do the same thing. And the tough decisions - should I deduct a point from Kurt Gluck because, even though his project greatly exceeds the requirements of the assignment, and is otherwise very well written, he consistently misspells "register" as "regester" in his code comments. (Of course, he probably went on to have a brilliant career somewhere and gets paid twice what I do. And yet, this is why I remember the name 35 years later). And then there was the beginner Fortran (WATFIV) class whose project was supposed to count the number of students in each class, and in the entire school, and if they did CLASSNUM=CLASSNUM+1 SCHOOLNUM=SCHOOLNUM+1 in their inner loop instead of SCHOOLNUM = SCHOOLNUM+CLASSNUM in their outer loop, I deducted a point for "inefficiency". Seems I was pretty ignorant about processor performance in those days. Not that I obsess about such things. :-) Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Conditional assembly for COBOL?
IBM Mainframe Assembler List wrote on 01/10/2012 03:11:25 PM: > The intent of my post was that it would be a lead-in to a more > generalized discussion as to why it might be that System/360 was > designed with a set of registers that contain heterogeneous control > information, sometimes within a single register and yet provides > instructions for loading and storing their values in a whole register at > a time fashion. Having 16 of every type of register promotes a more > orthogonal design aesthetic but I wonder if the designers got a little > carried away with the concept. It allows for a smaller instruction set > I suppose since you only need LCTL and STCTL for reading and updating > values in one or more Control Registers but wholesale loading of control > registers can involve interdependencies that add significant overhead. > The existence of instructions such as ESEA that load specific bits of > Control Registers without incurring overhead due to interdependencies > suggests to me that the 16 of every type of register design aesthetic > may have been over-extended a tad. > > As for using the ESEA instruction? I see no issue with doing so > provided steps are taken to ensure that changes to the EAX are > encapsulated (such as when a PC routine whose ETE specifies a non-zero > EAX value is executed). Like all privileged instructions its use > requires care and attention to detail. > > BTW, I have not been able to find any documentation that corroborates > Jim's assertion that ESEA is only for operating system use. Is there a > list of OS-only instructions that I should be aware of? I guess I'd > like to make sure it's okay for me to be using SCKC and SPX (just > kidding). When the EAX was introduced with 370/ESA architecture. the intended method for altering the EAX was PC/PR. With the introduction of the R bit in the ASCE in z/Architecture, z/OS implemented a means for itself to access real storage by making it look like a Scope=Common data space. A private (i.e. EAX protected) Access List Entry is used for this purpose, and it was not practical to encapsulate all of the code which uses it (like most of the Real Storage Manager) into PC routines. So ESEA was created as alternate means to manipulate the EAX. While use of ESEA outside of this environment is not prohibited, I would not expect it to be prevalent. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Idea for a possible enhancement to z architecture
> > There is some discussion of a concept like this > > in the publicly available literature at > > > > http://www.google.com/patents/US20100325385 > > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > Neat. Thanks for the (non-NULL) pointer! Might be "interesting" to > implement this on Hercules-390, just displaying a message to the > Herc console, and run z/Linux on it (or maybe even MVS 3.8j) to see > how many "hits" it could cause. Based on our research, I would expect that you would see a non-trivial amount of the following: 1. Non-error events for swapped index/base specification 2. Non-error events when address 0 is being legitimately used in a data space (well, not on MVS 3.8, where there are no data spaces) 3. Non-error events in code which is intentionally accessing the PSA, but uses 0 in a register other than R0 as the base 4. Latent errors where a null pointer value is unintentionally used, but the PSA field being accessed always has a value which does not currently cause incorrect results, but could in the future. 5. Errors where a null pointer value is unintentionally used, and there is a reasonable chance of this causing incorrect results Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Idea for a possible enhancement to z architecture
> I've been coding up a UNIX program in HLASM. One thing that I'm > doing is "chain chasing" using pointers. The end of chain is > indicated by a pointer of binary zeros: A(0). The code basically > loops by doing an LT instruction of the next pointer, followed by a > JNZ. Works quite well. Now my mind is churning a bit. I seen this > type of thing in a lot of C code as well. But it depends on the > programmer remembering to check the next pointer for NULL. So what > occurred to me was: "Why doesn't the hardware do this?". That > spawned an idea that I would like your feedback on. What do you > think of a hardware feature, selectable via a bit in a control > register, so that addresses in "low core" can only be referenced via > GPR0? When using GPR0 as either a base or index register, the actual > contents are actually and F'0' is used as the value. I don't know of > any exception to this rule. So why not extend it? I.e. if you use > any register as a base register in an instruction, and that register > contains F'0' (or D'0' in AMODE 64) or x'8000', then a program > interrupt occurs. Granted, this could cause a "false positive" for > those people who reverse the meaning of the "base" and "index" > registers. This could cause a "false positive". Which is why it > should be governed by a bit in a control register. Perhaps with some > way in the binder to indicate that the "interrupt if base register > contents are NULL" switch should be ON for a particular module. I > wonder if this would help with program bugs. It would definately > stop the branch to location 0 when a VCON is unsatisfied. And the > interrupt would be on the branch instruction instead of being in low memory. > > Good idea? Or stupid? There is some discussion of a concept like this in the publicly available literature at http://www.google.com/patents/US20100325385 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Conditional assembly for COBOL?
IBM Mainframe Assembler List wrote on 11/23/2011 09:36:50 AM: > > > >Trigraphs are the wrong answer to a question that should never have been asked. > > > >> I feel the same way about the ESEA instruction. > > > > I don't know of any conditions under which you should be > > contemplating using the ESEA instruction. ESEA is intended > > for use by the operating system. > > > Suppose the operating system is open source and the writer is > a developer. > > The lines blur. I interpreted the Original Poster's comment as "The ESEA instruction is the wrong answer to a question that should never have been asked." In ESA architecture, the intended way manipulate the EAX was PC/PR. In z/OS for z/Architecture, we had a specific need to manipulate the EAX while in supervisor state in order to use a special purpose private access list entry which we include on every PASN Access List. We needed to avoid the inconvenience and performance cost of encapsulating all of the code which uses that access list entry into PC routines. For that reason, the ESEA instruction was created. If another operating system is open source, and the writer is a developer, he is free to use ESEA to meet his needs. ESEA is fully documented in Principles of Operation. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Conditional assembly for COBOL?
IBM Mainframe Assembler List wrote on 11/22/2011 05:26:36 PM: > I feel the same way about the ESEA instruction. > Trigraphs are the wrong > answer to a question that should never have been asked. (IMO, only) > the correct answer is UTF-8. I don't know of any conditions under which you should be contemplating using the ESEA instruction. ESEA is intended for use by the operating system. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: newer opcodes
Peter Relson/Poughkeepsie/IBM@IBMUS wrote on 10/13/2011 08:08:01 AM: > 10/13/2011 07:35 PM > Subject: > Re: newer opcodes > It is true that all z/OS releases can run on any z/Architecture-capable > machine. > > Peter Relson > z/OS Core Technology Design That's not quite true. While it is true that all z/OS releases run on the oldest z/Architecture-capable machine, and the all *currently supported* z/OS releases can run on any z/Architecture-capable machine, it is not the case that all old, unsupported z/OS releases can run on newer machines. For example, z/OS 1.7 is the oldest release that can run on a z196 or z114, because the IPL will fail without a fix for the problem described by APAR OA30777. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: Baseless vs Based
> Not a bad reason at all. The system returns the EPA on a LOAD macro, but the > module load point is much harder to find. CSVQUERY will give it to you in 2010 > but in the old days programs had to "crawl" through CSV control blocks to get > this information. The LOADPT keyword has been available on the LOAD macro since the first release of MVS/XA. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: FYI: SYSEVENT REQFASD on z/OS 1.12 needs a larger work area
IBM Mainframe Assembler List wrote on 09/20/2010 04:51:25 PM: > >> I was going to make the same comment. There are a number of other > >> macros which have such a version field to indicate the mapping of the > > > parm fields etc. The code can thus do fall-back if it is presented > > > with a "downlevel" parm. The problem is that there is no such field > >> in the parm list now so it would be hard to introduce it at this > >> point. > > > > The length field (RASDLEN) has been used in prior releases to > >compatibly extend the area in which data is returned to the requestor. > >However, RASDLEN includes some internal working storage as well as > >the area in which data is returned. If an increase in > >internal working storage is required to process requests which > >were formerly be processed with a smaller amount, this cannot > >be done compatibly. About the best that could be done in that > >case would be to fail the request with a return code of 8, > >which is documented to mean > >"The parameter list is too small." > >That would be incompatible, but at least not destructive. > > This would met my "The code can thus do fall-back if it is presented > with a "downlevel" parm." criteria. My question on your reply is how > would the code know that the RASDLEN is too small? It was my > impression that the issue was that a work area was being allocated > and was too short and thus there was an overlay beyond the end of the > short workarea and that there was no indication in the parms of the > length of that workarea. The invoker of the SYSEVENT provides an area of storage, and sets RASDLEN to be the size of the area of storage it is providing. The SYSEVENT uses some of this area for returning data, and some as an internal work area. The code could be aware of the amount it needs for each purpose, and thus can check against RASDLEN to see if enough has been provided. The code was only using RASDLEN to determine how much data it could return (probably on the assumption that the amount it used for internal work area would never be increased). So when that was increased, it broke things. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
Re: FYI: SYSEVENT REQFASD on z/OS 1.12 needs a larger work area
IBM Mainframe Assembler List wrote on 09/19/2010 09:59:08 AM: > >:>As I understand it, APAR OA33666 changes the work area size requirements in > >:>REQFASD back to the original size. > > > >One wonders why there isn't is a version field to control the output and thus > >the work area length. > > I was going to make the same comment. There are a number of other > macros which have such a version field to indicate the mapping of the > parm fields etc. The code can thus do fall-back if it is presented > with a "downlevel" parm. The problem is that there is no such field > in the parm list now so it would be hard to introduce it at this > point. The length field (RASDLEN) has been used in prior releases to compatibly extend the area in which data is returned to the requestor. However, RASDLEN includes some internal working storage as well as the area in which data is returned. If an increase in internal working storage is required to process requests which were formerly be processed with a smaller amount, this cannot be done compatibly. About the best that could be done in that case would be to fail the request with a return code of 8, which is documented to mean "The parameter list is too small." That would be incompatible, but at least not destructive. Fortunately, it appears from the APAR text that some method was found to avoid requiring the increase to the internal working storage supplied by the user. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
