Branch to DROP
Now that we've discussed this, some AI app will start recommending it to IBM assembler programmers. My main concern with it is if the coder thought the action of DROP was dependent on being in the execution stream. On 2024-10-06 6:08 p.m., Steve Smith wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. EQU * has exactly the same problem. Nevertheless, it's ridiculously popular (by those who "know" it will always be on a halfword boundary, and of course the many more who don't know much). For this case of an ordinary symbol not being allowed on DROP, yet actually implemented with only a warning, I say that's just wrong. The correct behavior would be to not create the symbol, and issue an E-level message. There's no benefit to accepting undocumented usage. Nevertheless, nothing is perfect, even HLASM, and I'm not sure it's worth the effort to change it. Your program may well be the only one in the world where someone tried this. sas On Sun, Oct 6, 2024 at 4:30 PM Steve Thompson wrote: Hi: What I was reporting is how it was coded in a program (in production). Which was astonishing to me!! I'd never seen any one attempt this before that I can remember. We have discussed this also on/in IBM Main. It was pointed out by someone else, that this could lead to a S0C6 -- which is what bothered me about how HLASM dealt with this to start with. In all the code I've written and/or worked on from the S/360-20 through z/16s, this was the first time I can recall someone attempting to "branch" to a drop statement. Or any other assembler directive. Your example, if it was on an odd boundary would result in S0C6 - Specification error (which someone demonstrated on/in IBM Main). I certainly hope the HLASM folks will take another look at this and realize how this could be even more confusing to newbie ALC programmers who may do this and then have such a directive end up being preceded with something like DS X that would put the next byte on an odd byte boundary (the S0C6 problem). Regards, Steve Thompson Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Question on HLASM - B to a DROP statement!?!
I can imagine a junior assembler programmer thinking that they should branch to the DROP to ensure it was executed before entering the following code. I think it takes a while for new programmers to understand what USING and DROP statements actually do other than the necessity of having a USING at the beginning of a program (often hidden in a macro). On 2024-10-01 5:46 p.m., Steve Thompson wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. Yes the subject is correct. I just ran into this situation. Program is in production. Multiple points in this program do the following: B DROPR11 Now, a few screens away we have this: DROPR11 DROP R11 LA R1,x (or something similar) The DROPR11 above gets flagged with an invalid label The various B DROPR11 statements resolve to the LA R1 Anyone see a problem with this? When did this kind of thing get accepted? I would have figured that invalid label would have gotten at least an RC=8 And every one of those "Branch" instructions would have been flagged for an undefined label or some such. An inquiring mind would like to know. Regards, Steve Thompson Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Getting to CVT with FLAG(PAGE0)
We use ACONTROL FLAG(NOPAGE0) followed by the instruction/macro then ACONTROL FLAG(PAGE0). It also takes care of some IBM-supplied macros that are still non-standard. ACONTROL is handy if you want 0 return codes on all assemblies but you want to catch the errors. from its opening or use. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: 64-bit Execution Slower?
I thought I heard that the additional translation tables involved for 64-bit address made DAT take longer. Whether that involved additional pipeline stages I don't know. I have not seen any documentation that the same instruction that doesn't involve addresses takes long under 64-bit vs. 31-bit, like AGR, AGFI, LGHR, etc. On 2024-06-04 8:00 p.m., Ed Jaffe wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. I remember hearing years ago from IBM that 64-bit mode programs tended to run slightly slower than those running in 31-bit mode. At the time, I assumed the reason was that programs using 8-byte pointers and integer values use more cache lines and 4K pages/frames than programs using 4-byte values. However, in a recent discussion we wondered if perhaps the "grande" instructions that operate on the full 64-bits of a register might also run a tiny bit slower than their counterpart instructions that operate only on the low halves of the registers. Wondering if anyone can shed some authoritative light on this topic... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: BXLE usage assistance
I believe the CLC would be CLC 2(9,R7) although in actual code it would probably be executed with Rn containing R8 - 1. On 2024-06-05 11:02 a.m., Seymour J Metz wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. What's wrong with CHKOPTS1 LAR7,TABLE1+2 ADDRESS OF FIRST ELEMENT LAR9,TABLE1+2 ADDRESS OF BEGINNING OF TABLE AHR9,TABLE1 CALC ADDR OF END OF TABLE LOOP1 LHR8,0(R7) entry length for BXLE CLC 0(9,R7),=C'F' JEFOUND ENTRY FOUND = RC=0 BXLE R7,R8,LOOP1 LOOPING UNTIL OPT FOUND Specifying the length field on your USING? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: RES: The best way to check any virtual address
TPROT is not definitive; LRA can tell you, but is privileged and still has some limitations. On 2024-06-03 5:34 p.m., João Reginato wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. I meant a simplest way to check if the address is still available and don´t touch it if don't. Like LRA or TPROT or other similar instructions do Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Mensagem original- De: IBM Mainframe Assembler List Em nome de Binyamin Dissen Enviada em: segunda-feira, 3 de junho de 2024 17:00 Para:ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: The best way to check any virtual address On Mon, 3 Jun 2024 15:56:17 -0300 João Reginato wrote: :>What do you guys use to check if a virtual address is still valid to avoid a :>S0C4? Why? What would you code do differently? Just recover from the 0C4. You could use VSMLOC, but that won't help you with key mismatches. And, of course, that can change after you get your response. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
Re: The best way to check any virtual address
We created a subroutine using ESPIE to return none/read/write access. On 2024-06-03 3:09 p.m., Paul Gilmartin wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. Did you intend to request private replies? The topic seems to be of general interest. On 6/3/24 12:56, João Reginato wrote: What do you guys use to check if a virtual address is still valid to avoid a S0C4? Why not set an ESTAE and field the S0C4? Valid for read or valid for tor store? Why? Beware of TOCTTOU. -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: BXLE usage assistance
I believe there's a branch relative version too; JXLE. On 2024-05-29 4:57 p.m., Seymour J Metz wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. LHRODD,ARRAYLEN LARODD,ARRAYFIRST-1(RODD) LARPTR,ARRAYFIRST LOOP LHREVEN,0(,RPTR) ... BXLE RPTR,REVEN,LOOP where REVEN,RODD is a register pair. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ____ Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Mark<176dcd91c5b1-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, May 29, 2024 3:03 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: BXLE usage assistance Hello, I'm writing an exit where I have to scan through an array of variable length entries in a table where the format is as below (all the entires are readable characters) First 2 bytes = total length of array in hex then 2 bytes for length of first entry in hex First Entry in table 2 bytes for length of 2nd entry in hex 2nd entry in table 2 bytes for length of 3rd entry in hex 3rd entry in table. repeats until end of array. I'm thinking a BXLE will work, but getting stuck on exactly how to code it. any help is greatly appriciated. Thanks, Mark. .
Re: Relative branching instructions info
It used to be in SHARE presentations. Branch relative was presented in 1998 Stalking the new opcodes. That would be pre-MP3000, pre-zArchitecture,I believe. I always though a good place to add documentation was https://bixoft.nl/english/opcd00.htm On 2024-05-09 11:21 a.m., Charles Mills wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe. Ah! That's a different question. It's always a research project. I know of no exhaustive "this instruction was introduced with this model" document. You can go through the various Principles of Operation versions and look for change bars. Not a quick task. You can look at the description for each instruction and look at the Program Exceptions paragraph and find something like "Operation (if the general-instructions-extension facility is not installed)." And then go through the various announcements looking for when the relevant facility was announced. Another trick is to look at the supported opcodes for each hardware level specification for HLASM. As I say, not simple. A research project. I once thought about doing a definitive spreadsheet but I gave up on the project before I had made much progress. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent: Thursday, May 9, 2024 8:07 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: RES: Relative branching instructions info Importance: Low I need to know in what hardware it was first implemented
Re: Complex immediate fields
>From a performance and sometimes readability point of view, having constants >(whether instructions or operands), close in memory to the instructions >using them is desirable. As Gil mentions, macroes are likely to do it. There >ia a data cache and an intruction cache, but there is nothing inherent to >prevent a program from modifying the instruction stream or the instruction >stream from branching into an area of the program that's in the data cache. >(There may be key exceptions that create errors). But any modification to the >instruction cache requires the instruction cache line to be moved to the data >cache, and any attempt to execute instructions in the data cache requires the >cache line to be moved to the instruction cache. I don't think this affects >page fault handling. Whether instructions are refreshable depends on external >factors, including binder options and characteristics of the load library. I >don't know about USS. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: April 15, 2024 13:37 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 4/15/24 10:09:06, Charles Mills wrote: > ... > And I would never, ever embed data in the instruction stream. > . I.e. no parameters following the CALL-type instruction? Don't some library macros (still) do this, bypassing with a relative (ugh!) branch instruction? Are instruction pages distinguished from data pages nowadays? Do page faults behave differently between the two? Are instruction pages REFReshable? -- gil
Re: OPCODE tables
I've used this one https://bixoft.nl/english/opl_bonm.htm Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Mark Hammack Sent: March 20, 2024 17:38 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables Thanks! That's pretty handy :-). *Mark* On Wed, Mar 20, 2024 at 4:35 PM Tony Harminc wrote: > On Wed, 20 Mar 2024 at 17:12, Mark Hammack wrote: > > > Is there a list somewhere (other than OPTABLE LIST) that shows which > > instructions were added at each hardware level? > > > > I thought PoP used to have something similar but I don't see anything > back > > to Revision 7 (oldest copy I have). > > > > Although I don't know the status of the Tachyon assembler, I still find the > opcode tables there to be handy. > > http://www.tachyonsoft.com/inst390o.htm > > I don't think it's been updated for quite a few years - maybe since the z10 > or so - but it's really good for historical stuff. > > Tony H. >
Re: Decimal Floating Point Numbers
This reminds me in a way of number representation in COBOL. The PICTURE allows you to place the implicit decimal point anywhere, which will afftect the display of the number, but internally there is just a fullword, or packed decimal or halfward, etc. So the programmer choses whether to display, for example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands of dollars. Where do you get to indicate whether you want LUV or RUV? Is it part of the convert to zoned decimal or is it an convention that an application agrees on? I can see what it is but I can't see how I can request one or the other in assemlber language. Or is an HLL concept that some asembler subroutine implements for the HLL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Gary L Peskin Sent: March 6, 2024 11:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Decimal Floating Point Numbers Thanks, Abe. I'm glad I was able to help. I don't really understand why they started with this whole LUV/RUV thing anyway. They could have just picked one and said that that's the representation and left it at that (no pun intended!). But I guess that wouldn't have been confusing enough. Take care, Gary
Re: Linkage Editor Include Order
Yes, we've been doing it since the early 2000's with linkage editor invocation (I don't know when that internally switched to binder). Check what happens when the ORDER statement is specified: ORDER csect1, csect2,... Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Adam Johanson <0dcd75b5594e-dmarc-requ...@listserv.uga.edu> Sent: December 4, 2023 14:27 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Linkage Editor Include Order > Is it possible to influence the order the linkage editor includes objects? I don't know about the linkage editor, but the Binder ;) has an ORDER statement that can be used. === Adam Johanson Broadcom Mainframe Software Division
Re: Reseting RMODE
I think I understand: you wish the last RMODE in a CSECT to override all previous RMODEs in the CSECT or possibly, as Shmuel suggests, the most restrictive to override all others. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: December 4, 2023 11:44 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE is there an RFE for an RMODE(MIN) option to accept multiple RMODE statements and use the most restrictive? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, December 4, 2023 10:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Reseting RMODE (Don't be greedy; don't set personal "Reply-to:") On 12/4/23 07:28:51, João Reginato wrote: > As I've said before, I wasn't clear enough here. > My intent is to change the RMODE during the compilation phase only. > I have all CSECTS with RMODE ANY so, one of them, need to be RMODE 24, and I > cannot change it because the HLASM doesn't allow that. despite it hasn't > finished the compilation of all my csects, issuing the message reported > before. >. Ir would be marginally useful if HLASM, when the programmer codes conflicting RMODE instructions, chose the one most restrictive. But you can simulate this by setting a GBLA wherever any RMODE is needed and choosing the least one with AIF logic near the end of your assembly. -- gil
Re: BAKR/PR and Linkage Convenction
You don't have to. Static areas and code can share a cache line with no performance penalty. It's dynamic areas (and dynamic code) that should be isolated from static areas and static code. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Dave Clark Sent: November 30, 2023 11:12 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BAKR/PR and Linkage Convenction "IBM Mainframe Assembler List" wrote on 11/21/2023 04:49:37 PM: > On 11/21/23 14:32:27, Tom Marchant wrote: > > Modern processors use a 256-byte cache line, with separate caches for > > instructions and data. A cache line maps to 256 bytes of storage on a > > 256-byte boundary. There are performance penalties when the same line > > of storage needs to be in both the instruction cache and the data cache. > Is it recommended, then, to cache-line align LTORG so instructions > and data don't share a cache line. Is there an instruction that > will continue to do this for future hardware? So, how does one force a 256-byte alignment? I have LOCTR now placing all of my static data areas at the beginning of the program (after the initial jump to the start of the code area). How do I pad that data area so that the following code area starts on the next 256-byte boundary? Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: BAKR/PR and Linkage Convenction
My understanding was that instructions and other constants can share a cache line with no interference. Data that is changed, whether instructions or "constants", will require the cache line to be present in the data cache. The separation should be between data that can/will be changed and the data that will not change. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Pieter Wiid Sent: November 28, 2023 09:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BAKR/PR and Linkage Convenction I have a PAD macro that takes the alignment as a parameter. It generates nC'P', where "n" is calculated to align on your selected boundary -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, 21 November 2023 23:50 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BAKR/PR and Linkage Convenction On 11/21/23 14:32:27, Tom Marchant wrote: > Modern processors use a 256-byte cache line, with separate caches for > instructions and data. A cache line maps to 256 bytes of storage on a > 256-byte boundary. > There are performance penalties when the same line of storage needs to > be in both the instruction cache and the data cache. > It has nothing to do with the base register used. > > Is it recommended, then, to cache-line align LTORG so instructions and data don't share a cache line. Is there an instruction that will continue to do this for future hardware? -- gil -- This email has been checked for viruses by Avast antivirus software. www.avast.com<http://www.avast.com>
Re: Based vs. Relative (was: Internal Exit Routine Handling)
For the question about use in structuring macros, the first question would be is how many concurrent base registers are usually in play; that would help determine whether to choose regular or long displacement instructions. The other consideration is structured code style. Within an IF-THEN-ELSE structure (or even a CASE structure) inplemented in assembler, how much code do you really want between structure elements before you really want to imbed the code in a out-of-line subroutine using JAS or LARL and BASR to access it? I would personally find If condition Then 200 lines of code Else 150 lines of code End-if hard to navigate. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: November 9, 2023 12:33 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Based vs. Relative (was: Internal Exit Routine Handling) Principles is your friend! I found the transition from based to relative to be relatively (ha ha) painless. You don't have to do it all at once. Just start coding relative jumps now. The existence of base register does not preclude using relative jumps. Then when you get comfortable, comment out the USING and see what happens. > I know I can do a relative jump up to 4K, correct The programmer answer is Yes. But in addition to up to 4K, you can actually do up to +/- 65K. There are also even longer ones that will jump anywhere. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Thursday, November 9, 2023 9:17 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Based vs. Relative (was: Internal Exit Routine Handling) "IBM Mainframe Assembler List" wrote on 11/09/2023 11:27:20 AM: > IMHO, relative branch use is a "best practice" in all situations. I > *never* use a based branch if an equivalent relative branch will suffice... I've been coding based-branches since 1980 and never moved on to the new stuff. But I recognize that it would be beneficial if I did. So, let me ask a couple of simple questions... Is it, relatively speaking (hehe), "a lot" of effort (or even possible/practical) to do away with a code base register altogether? The first place that I would like to switch to relative jumps is in my structured programming macro sets. But do relative jumps come in more than one flavor? ...like long jumps and "how far"? I know I can do a relative jump up to 4K, correct? Is there a long jump beyond that? And since there can be as much code between the macros in my macro sets as the user determines to put in there, should I use long jumps as opposed to "short" jumps, just-in-case? For example... I have these 4 macros in one of my sets. Internally, I generate labels for THEN, ELSE, and ENDF. These also arbitrarily allow nesting up to 8 levels. IF condition,AND/OR,condition AND condition,AND,condition ... as much code as the user desires between here ... ELSE ... as much code as the user desires between here ... ENDIF Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378 home: (937) 751-3300 Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331 * This email message and any attachments is for use only by the named addressee(s) and may contain confidential, privileged and/or proprietary information. If you have received this message in error, please immediately notify the sender and delete and destroy the message and all copies. All unauthorized direct or indirect use or disclosure of this message is strictly prohibited. No right to confidentiality or privilege is waived or lost by any error in transmission. *
Re: Tutorials for z and HLASM?
Interskill has courses that IBM gives badges for: https://interskill.com/ibm-credentials/ibm-badges/ I don't really know anything about them - somebody had previously recommended them to me based on a similar question. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: October 5, 2023 21:33 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Tutorials for z and HLASM? Are there any good online tutorials for unprivileged z/Architecture and HLASM for programmers with no prior assembler experience? Ideally I'd like something faster paced than Programming 101, and several of us will be available as mentors, workload permitting.
assembler-list@listserv.uga.edu
The PoOp manual has always gone beyond the hardware definitions of machine language instructions to provide the symbolic format in HLASM (and its predecessors) of each machine language instruction, e.g., MVC D1(L,B1),D2(B2). There could be many other zSeries assemblers (I don't know of any) that do not use the symbolic format documented in the PoOp to create those machine language instructions. HLASM relies on the PoOp to document the symbolic format of zSeries insructions. When we code in that format, we rely on HLASM to convert the code into machine language instructions. Otherwise we'd have to code machine language instructions as constants, either directly or in macros. It appears that the PoOp, by documenting the HLASM symbolic format of instructions, is a critical and necessary supplement to the HLASM Reference manuals. Since AFAIK HLASM only supports IBM's zSeries (and predecessors) hardware, it would be close to useless without the PoOp. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Shower thought
Or packed decimal or floating point Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: June 12, 2023 19:14 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought As opposed to a signed integer? For C, X'1000' compares greater than x'8000'. For CL, the reverse is true (a bit-for-bit comparison). Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Monday, June 12, 2023 4:08 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Shower thought Jonathan Scott wrote: >On trying to catch up with this thread I don't think I saw what >I would have considered the most likely reason for the term >"logical". >I assumed the word "logical" refers to Boolean logical values >(true and false, usually represented as 1 and 0) and hence to a >bit string. So logical comparisons simply treat the operand as >a bit string. Well, I thought I covered that with my first thought that it was a yes/no on the comparison. But even beyond that, I don't think that it makes sense to say that it treats it as a bit string-as opposed to what?
Re: ChatGPT "knows" HLASM
Our manager, who is not an HLASM programmer, asked ChatGPT to create an assembler program to move data from one location to another. He then had to ask it to do it for z/OS. The response was: For z/OS assembly language, you can use the BALR (Branch and Link Register) instruction to move data from one memory address to another. Here's an example program that demonstrates how to perform the data transfer: USING *,12 STARTEQU * LRR1,R3 Load source address into R1 LRR2,R4 Load destination address into R2 L R5,0(R1)Load data from source address STR5,0(R2)Store data to destination address . . . (Rest of the program) . . . END START I critiqued the results and in response, a tech support person said, well, I'm sure it could learn quicker than I could. My response was: * ChatGpt has the limitation that it doesn't have a mentor that takes the time to say, that's a good try but this is better. It is limited to what is published out there and lacking comments, doesn't have a good way to evaluate which are the best techniques. So it guesses just like a human. * And I personally think you could learn to be effective in assembler faster than ChatGPT, because you'd have a mentor and a place to test your code. ChatGPT obviously doesn't assemble its code and test it. If you isolate ChatGPT (or any AI) to only consult code samples from sources that have been vetted to be good (for some value of good) and if it accepted and remembered criticism without getting sulky, perhaps it could learn to present acceptable HLASM code. My concern is that ChapGPT will teach everyone the System 360 (or at best S/370) instruction set (because of the volume of code and textbooks available) instead of consulting Ehrmann's (and others) excellent SHARE presentations. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Wendell Lovewell <09624390d784-dmarc-requ...@listserv.uga.edu> Sent: June 2, 2023 13:48 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ChatGPT "knows" HLASM fwiw, I've been using ChatGPT and especially Monica to convert some DOS .BAT programs to Python. I paste in the BAT file and ask it to convert it to Python. It does a remarkable job generating "real" Python code--not just rewriting the DOS statements one by one. However, I'd guess it's been wrong maybe 30%-40% of the time. But since I'm just learning Python (this way), it's been a huge help. It's kind of like being in a computer lab with your own personal assistant who is 100% confident in their answers, but wrong at least 1/3 of the time. I'd guess it gets a lot more Python questions than Assembler, so I imagine the Assembler code would be even worse. But if you don't know the language, it's an easier way to get started. Wendell
Re: Automatic Variable Insertion
We resolved this by creating using the TEXT= option with a register which allowed us to use a single WTO MF=L and a single WTO MF=E for all WTOs. The messages themselves are generated by a macro which has a LITERAL type (to generate the constants), a DSECT form (to name where the variables are), and a SPACE type, to reserve space in working storage for reentrant programs. We don't use a macro to fill in the variables though. It seems like what you want is similar to an assembler version of the C language printf library function. Your macro would have to scan the WTO text for a symbol, e.g. "&", and match the following characters to a macro parameter (like &P1 matched to P1). Somehow the logic has to know the length to move in which has to be no more than the length reserved in the message text (otherwise it gets complicated). And it would have to loop to handle multiple input arguments and multiple &s in the TEXT. Fortunately, the length of the message precedes the message in the TEXT= format so you know when you're done scanning the text. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: April 18, 2023 10:55 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Automatic Variable Insertion I suggest, by the way, that you use the TEXT keyword of WTO. It can make things much more flexible for you, since the message line is then not part of the WTO expansion, rather just the address of it. Peter Relson z/OS Core Technology Design
Re: Blocking Low core access from Assembler programs
Early on the OP said that program that were OK before (I assume meaning that they passed testing) were now (with z/OS 2.5) not OK, but not abending. He had evidently tracked enough errors to accessing page 0 instead of their intended target that he's worried there are more. This is not unique to assembler, although it may be in the OP's case. I've written COBOL and REXX programs to chase pointers to find control blocks. If I don't check that my pointers are non-zero, I could have the same type of errors. And these programs are not production programs, so failures are inconvenient, not catastrophic. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Retired Mainframer <0fdaa76f2a18-dmarc-requ...@listserv.uga.edu> Sent: March 27, 2023 21:21 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Blocking Low core access from Assembler programs You are asking how to implement a solution but you have not told us what problem you are trying to solve. What is the real issue with this program accessing data in page 0? -Original Message- From: IBM Mainframe Assembler List On Behalf Of syama prasad Sent: Monday, March 27, 2023 3:48 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Blocking Low core access from Assembler programs Hi, Is it possible to force an Assembler program to hit an access error if it tries to load data from the low core (page starting from address zero)?Assembler *PROCESS FLAG(PAGE0) " helps to find cases like MVC TARGET,1But will it be possible to have a run time detection and possibly a dump if the program tries to do things likeLA R5,1MVC TARGET,0(R5)Basically, any way to restrict access of an application program to PSA- first control block? Regards,Syama
Re: Blocking Low core access from Assembler programs
It may be possible to devise a slip trap that would exempt the master TCB, but it might catch many perfectly legitimate problem state accesses, like to access the CVT to start a pointer chase to an IBM or ISV service or control block. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: March 27, 2023 19:37 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Blocking Low core access from Assembler programs z/OS has a lot of code that requires access to the PSA. Making it inaccessible would break applications. Of course, the machine has no core. From: IBM Mainframe Assembler List on behalf of syama prasad <13f87d4b715f-dmarc-requ...@listserv.uga.edu> Sent: Monday, March 27, 2023 6:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Blocking Low core access from Assembler programs Hi, Is it possible to force an Assembler program to hit an access error if it tries to load data from the low core (page starting from address zero)?Assembler *PROCESS FLAG(PAGE0) " helps to find cases like MVC TARGET,1But will it be possible to have a run time detection and possibly a dump if the program tries to do things likeLA R5,1MVC TARGET,0(R5)Basically, any way to restrict access of an application program to PSA- first control block? Regards,Syama
Re: ADD LOGICAL WITH SIGNED IMMEDIATE HIGH N
Also instructions that don't set the condition code preserve the existing condition code for following instructions. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: November 15, 2022 16:47 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ADD LOGICAL WITH SIGNED IMMEDIATE HIGH N On 11/15/2022 1:19 PM, Paul Gilmartin wrote: > > Is the hardware smart enough to bypass setting the condition code when > it's > not needed but might slow the pipeline? Maybe next year's model. It's not so much setting the condition code that slows the pipeline, it's waiting to check the condition code that slows the pipeline. For example, CLI/JNE. The JNE has to wait for the cc to be surfaced. That's why we mostly use CIJNE instead. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Assembler courses
To help a person who has COBOL and C language experience learn to write assembler, I would like them to learn from the start both reentrant and baseless coding techniques. Is there training available that assumes the instruction set available on the z12 is the starting point and that teaches reentrancy as the norm? (Cross-posted to IBM-Main and Assembler-list) Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: When did logical instructions appear?
My understanding was that using signed binary numbers made COBOL more efficient for arithmetic operations: L(H) a register, do the arithmetic and ST(H) the result. Unsigned binary meant L(H) a register, force it positive, do the arithmetic, force the result positive, ST(H) the result. (I'm pretty sure that COBOL treated unsigned binary fields as having to be positive numbers). ____ Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: June 16, 2022 10:58 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: When did logical instructions appear? ADD LOGICAL and SUBTRACT LOGICAL were part of the original System/360, and are documented in the A22-6821-0 edition of the System/360 Principles of Operation, as well as in "Architecture of the IBM System/360", published in the IBM Journal in April, 1964, which describes the reasoning for many of the design choices. -- Tom Marchant On Thu, 16 Jun 2022 14:36:12 +, Schmitt, Michael wrote: >My company's COBOL coding standards are* to define binary fields as signed >(e.g. PIC S9(4) BINARY). I'm wondering why that's the standard. > >The original standards were developed at least 40-60 years ago. They were >revised in 1994 but the signed binary guidance remained. > >One explanation could be if 50 years ago there were only signed binary >instructions such as ADD, but not logical instructions such as ADD LOGICAL. Or >maybe there were some logical instructions but not the full complement we have >today. > >Or it could be that whatever version of COBOL was used then (OS/VS COBOL or >earlier) was more efficient with signed binary, such as due to the choices it >made in instruction selection. > >So my question is, roughly when did the machines get unsigned binary >instructions for halfwords and fullwords?
Re: MVCRL
Only if they are in the same cache line, which are 256 bytes the last I knew. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Ngan, Robert (DXC Luxoft) Sent: June 8, 2022 11:32 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: MVCRL Oops, didn't notice the "code is executing in getmained area" part. Doesn't that cause performance issues with Instruction/Data caches though? Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Wednesday, June 8, 2022 10:17 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: MVCRL How would you gain relative access to a getmained area, other than by editing the immediate value in the instruction after the getmain? Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Farley, Peter x23353 Sent: Tuesday, June 7, 2022 17:51 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: MVCRL Not if the code is executing in a getmained area. I've often put code in such areas for various reasons (e.g. OPEN exits, I/O error exits. etc.), and it's annoying to have to set up base registers. But I confess I think an "MVCRL" instruction where *both* source and destination are relative to the instruction address would see little use. If only the SOURCE address was relative to the instruction address, that might be a tad more useful. Then the D(L,B) for the destination could be in a reentrant area. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, June 7, 2022 6:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: MVCRL If the source is relative to the instruction address, the code would most like be non-reentrant. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Tuesday, June 7, 2022 17:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: MVCRL Why isn't there a Move Relative Long instruction, i.e. move with no registers, where both the source and destination are relative to the instruction address? Is this because there's no instruction format with two RI fields and a length? -- 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.
Re: Missing New z16 Instructions
I think VM/370 (CP or CMS, perhaps both) used to rely on the CC after a calls to internal routines. As a debugger, since it's tracing the instructions, I wouldn't be surprised if it knew exactly which instruction set the CC. On 2022-05-10 2:29 p.m., Paul Gilmartin wrote (snipped): What if there are multiple code paths to the BC? (I had one co-worker perverse enough to rely on the CC after a subroutine return. He reset the program Mask before the BR 14 and I had to support it on a 370.) Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Unsigned 64-bit numbers
When loading 8 bytes into an 64-bit register, you needn't worry about logical vs. arithmetic. The sign only makes a difference if it's less than a doubleword being loaded. An LG will load it.. On 2022-04-28 5:20 p.m., Schmitt, Michael wrote: How did you do it in COBOL? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 11:39 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Unsigned 64-bit numbers I previously asked about 32-bit unsigned numbers and that opened up some new instructions (new to me, anyway: LLGF, LLGH, etc) for loading unsigned numbers into registers. But now I have need to load a 64-bit unsigned value into a register and I don't see an LLGD instruction for that. In case it makes a difference, this value is a timestamp (presumably from the store-clock instruction) but it is stored in an 8-byte file field. Now I need to take the file field and turn it into a date and a time value. I have done this in REXX and COBOL but now I need to do it in assembler. Actually, I have done something similar in assembler but it was for the CICS ABSTIME value -- which is a 15-digit packed number, not binary. So, any hints? Thanks. Sincerely, Dave Clark -- 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.
Re: Signed/unsigned operations
In situations where reentrancy is not necessary, maintaining code and data in separate adjacent areas each on cache boundaries and sizes a multiple of cache line length, these instructions may be very useful. And perhaps there are enough critical kernel code paths protected by locks for which the above code/data organization provides sufficient performance to justify the effort of implementing the instructions. On 2022-04-14 4:02 p.m., Tony Harminc wrote: On Thu, 14 Apr 2022 at 12:29, Ngan, Robert (DXC Luxoft) wrote: STRL/STGRLl? Is the GCC compiler generating non-reentrant code? I've wondered why these relatively (heh...) recent instructions exist in the architecture at all. (There is also STHRL.) Certainly they appeared long after it became the norm both to separate code and data for cache reasons, and more generally to not have non-reenterable code. (I know, C uses different terminology from everyone else - I guess I could say "constant" areas.) Maybe Dan Greiner knows why. Tony H. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Removal of transactional execution facility
If you research general discussion about how Spectre worked, it appears it was dependent on data being brought into cache or not from the path not taken. Timing how long it took to access the data indirectly a second time could reveal something about the data value. On 2022-04-07 12:30 p.m., Ed Jaffe wrote: On 4/7/2022 9:16 AM, Paul Gilmartin wrote: On Apr 7, 2022, at 09:57:35, Ed Jaffe wrote: z/Architecture does *not* require an alternative path around TBEGINC/TEND. How, then, does z/Architecture defend against such as Spectre? Does it balance paths so all exhibit the worst-case timing? Speculative execution is constantly being done for all instruction paths, not just those inside TBEGINC/TEND. How IBM Z defends against spectre has never been disclosed. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Removal of transactional execution facility
I believe any speculative execution, including starting to process both paths of a conditional branch in advance, is open to spectre if you don't clean up all internal traces of the path not taken before returning control to the next instruction. It may be that it's messier or more time-consuming to clean up after transactional execution because there could be a lot more speculative execution before it fails. On 2022-04-06 7:46 p.m., Ngan, Robert (DXC Luxoft) wrote: Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Wednesday, April 6, 2022 17:47 To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Removal of transactional execution facility I was as surprised – no, make that shocked – to see that IBM announced the removal of transactional-execution (TX) and constrained-transactional-execution (CTX) facilities in some future Z system. During the development of the facility, it showed significant (incredible!) performance benefits in lock elision; it was also touted by the Java development team for its speculative-execution characteristics. Having been retired for over four years now, I cannot speak to the rationale (or irrationale) for planning on the facilities' removal. One might speculate that the minimal usage of the facilities did not justify the ongoing complexity of their implementation (TX is REALLY complex). As with any new architectural feature, it takes quite a while before many ISVs and customers exploit it. Having to dual-path one's code to account for the presence or absence of such a facility only prolongs the delay in exploitation. Consider how long it takes for an OS's level-set to catch up with the ever-evolving architecture. But if TX was such a hot feature, why wasn't its exploitation by IBM's own software sufficient to justify the obvious benefits that it provided? As the announcement letter said, "In some future IBM Z hardware system family, the transactional execution and constrained transactional execution facility will no longer be supported." Perhaps this ambiguity opens the possibility to a change of heart on IBM's part if enough customers and ISVs protest loudly enough ... but I doubt it. As to Mr. Shaw's comment about "feeling kinda 'had' now" ... yeah, that's a polite way to put it.
Re: Eliminating Base Registers (was: Inlining routines)
some brief comments: plus IBM macros have to be converted, there should be a macro to do that On 2022-04-01 2:41 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 04/01/2022 02:14:38 PM: Where I disagree is on the base register issue. Base registers and code addressability issues should have gone away. It is pretty trivial to replace old branches with their newer relative counterparts. Should be faster code, too, FWIW. OK, I'll bite. This discussion has probably been done before but I wasn't around for that. Forgive my newbie questions -- even though I have been programming in assembler on and off since 1978. That said... I understand relative branching on a basic level. But I haven't really looked into them and haven't used them at all to this point. So... 1. Is it as simple as just using a different mnemonic for the branch? Yes 2. Does the target label still have to be within 4K for the relative branch? No 3. ...or is there an extended relative branch that uses the extended displacement feature? The default is extended 4. What about the target for the EXecute instruction? Is there a relative version of this? EXRL 5. Even if code base register(s) is(are) eliminated, you still need a data base register -- yes? Reentrant, of course; there are some relative data reference commands 6. If you have a large program with constant data at the end of the program, how do you establish the base register needed for that data area? LARL will get the address 7. Lastly, if the code base register has been eliminated, does this mean you should no longer have things like LTORG at the end of each subroutine to force data to be stored near the subroutine that uses it (where previously the code base register for the subroutine would have served double-duty as the data base register)? Yes but more immediate instructions may mean less need for literals Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Edit Masks
Have you considered executing an EXECuted MVC of character zeroes over the edited data? Or a CLI, MVI loop on the edited data? On 2022-03-10 1:12 p.m., Steve Smith wrote: There's really nothing that can beat trying it out. Moving the Sig Start earlier is usually all you need; except it has what I consider to be the perverse effect of starting significance with the following digit. Which makes it impossible to include the first leading zero naturally (because SoS picks up a digit, and suppresses it if 0). Sometimes using C'0' as the pad works out; sometimes, you have to coerce the input field to be longer than (1 more digits) than you want to display. sas On Thu, Mar 10, 2022 at 12:23 PM Charles Mills wrote: Dave, you raise a good point. ED is powerful but tricky. You would have to read the PoOp very carefully. Sorry to wimp out here, but it has been a long time for me. I fear you are correct: that ED will happily use the significance starter as a fill byte, with unhappy results. For the "no blank fill" case you may have to ZAP the data to a larger field, or use UNPK and OI. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Modifying the VSAM Request Parameter List (RPL)
Are the mappings identical; the answers for MVS versions of the macros may not be the same for the VSE versions. The values you want to set better be at the same displacements. On 2022-02-24 12:29 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 02/24/2022 12:19:43 PM: As I see while writing this, just doing it yourself by updating IFGRPL fields has already been suggested. I agree. OK, my only question is whether I have to do this through the IFGRPL DSECT or whether I can just use the IKQRPL DSECT directly? Does IFGRPL have something I will need that IKQRPL does not? You can try to validate as you go (e.g. in your code above but without the MODCBs), or you can do a validation pass first, and only when you're sure you have a correct set of things to do, do them. Everything has already been validated before the process gets to this point. At this point it is just conditional statements to see what I need to do. But at least if I don't have to use MODCB then I can rearrange and simplify these conditional statements. Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: SRST vs. SRSTU
Thanks to all. From the responses so far and my experience I'm inclined to believe SRST is hardware and probably SRSTU is millicode (perhaps based on SRST for the first byte) and we must look for another technique. My original thought was that we would use a serial search until the number of keys exceeded some threshold and then build and maintain the 2-byte hash table and switch to SRSTU, based on naively expecting its performance to be comparable to SRST up to some number of keys and significantly better than SRST when the number of entries exceeded some multiple of 256. We are experimenting with other techniques, but we can't change that the keys are added and deleted dynamically, are continually accessed, and the total number of entries varies significantly in different applications. I guess it's time to look at vector instructions and possibly B-trees. Gary Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
SRST vs. SRSTU
We are trying to optimize a search routine for keys in fixed length rows in an unordered array. As the number of rows in the array grows, a serial search becomes relatively inefficient, so we looked for another technique. We tried a SEARCH STRING (SRST) against a one byte hash of the key to see if it could give us better performance. The relative positive of the matching byte in the SRST array was used to determine the location of the key in the original array; if the keys match, the row is found; if they don't match, we redrive the SRST. At about 50 rows, SRST is more efficient than a serial search so it justifies maintaining the hash array. On the average, we assume the SRST would have to be redriven about (n/256)/2 times, where n is the number of rows in the array. This would not be a big factor for several thousand rows, but as the number of rows went into the tens of thousands, we tried Search String Unicode (SRSTU). It appears to be identical to SRST, except it compares 2-byte values (at 2-byte boundaries). So we created a 2-byte hash and, using the same technique based on relative position, tested for performance improvements compared to SRST when the number of rows exceeded 1. We thought that the reduction in the number of redrives due to non-matching keys (on average, (n/65536)/2) would more than offset the hash array doubling in size. Our preliminary results show SRSTU about taking about 50-60% more time for 15000 and 25000 rows. That came as a surprise to us. We will do more testing. Is there a possibility we are encountering a hardware vs. microcode implementation of the instuctions? Has anyone else tested the performance of these instructions? Regards, Gary Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Rules for Zoned Overpunch
For the decimal point, one normally just has different edit patterns for each different number of positions to the right of the decimal point. And usually the edit pattern will set the significance indicator to the left of the decimal point so the decimal portion is zero-filled. On 2022-02-11 5:05 p.m., Charles Mills wrote: I am talking off the top of my head here. I have not used PACK and friends in years. Yes, there are length limitations. Pack is limited to 16 bytes and EDIT to 256 bytes of output. I am not familiar with PKA. CVB is not real relevant. Forget I said that. Well, it would help answer your sign question. I *think* you could pack the last few bytes of your input into a doubleword (no problem if the entire field is longer than that) and then CVB it and test the sign of the register. I *think* CVB handles all those oddball "overpunch" sign specifications. ZAP sets the CC based on the sign also, right? Yes, PACK and EDIT/EDMK handle implied decimals. For EDIT/EDMK you can tell it where to insert a real decimal point. IIRC it sets the CC so you know the sign of what you just edited. This is EXACTLY the chore that EDIT is designed for. Look at COBOL zoned decimal pictures. Now translate that in your head into a hardware instruction. That's EDIT. EDMK is one of those instructions where you have to read the PoOp about three times, but what it does is give you an address in R1 (?) that tells you where a floating minus sign or currency symbol needs to go. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Dave Clark Sent: Friday, February 11, 2022 11:51 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Rules for Zoned Overpunch "IBM Mainframe Assembler List" wrote on 02/11/2022 02:24:38 PM: Doesn't PACK + CVB + EDMK pretty much just do this for you? Well, in the first place I am allowing the incoming zoned-decimal field to be up to 31 bytes. PACK won't handle that -- although that is not insurmountable with PKA. But I'm also allowing the zone-decimal field to have an implied decimal with from 0 to 15 places. I don't think PACK + CVB + EDMK handle decimal digits for me plus inserting the decimal point in the proper place -- correct me if I am wrong. Sincerely, Dave Clark
Re: Branch-and-Link nomenclature question
I refer to them all as generic branch and link instructions, and include all other instructions that provide a return address for the routine being entered, whether it's through the instruction itself (like these) or hardware (like PC, SVC). I tend not to use "Call" because there's an IBM macro with that name. On 2022-02-10 11:04 a.m., David Cole wrote: In Assembler there are many machine instructions that are suitable for calling subroutines: - They go somewhere, - But they also set a register that can be used to return to the next following instruction. These instructions include: - BAL (Branch and link) - BALR (Branch and link register) - BAS (Branch and save) - JAS (jump and save) - BRAS (Branch relative and save) - BRASL (Branch relative and save long) - BASSM (Branch and save and set mode) My question is this... What is the collective name for these instructions? In a sentence such as "Then you branch and link to a subroutine...", I tend to say "branch and link", but I'm always unhappy about that... - Yes, "branch and link" is an accurate description of you're doing, - While "branch and save" is a bit opaque. - However, the phrase "branch and link" is ambiguous and invites unnecessary quibbling. So my question is... What would you say? TIA, David Cole dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Saving Caller's 64-bit Registers
In some of those cases, perhaps cheating would work. Assuming 64-bit registers R15, R0, and R1 are insufficient (if they are truly volatile in your application), perhaps you have an unused register that can hold the high half of another register which you'll use as a 64-bit register. On 2022-01-27 5:42 p.m., Tony Thigpen wrote: Ed Jaffe wrote on 1/27/22 5:06 PM: On 1/27/2022 11:20 AM, Tony Thigpen wrote: The question has nothing to do with "what if +4 is zeros." It is "what if +4 has one of the standard literals." I gotta ask... From a purely practical standpoint, would you or anyone really want to maintain bifurcated code that took different save/restore code paths based upon the value discovered at 4(R13)? Maybe. I have a lot of small reenterable routines where I need to start saving the high-halves. I can see where I can optimize them using 64bit instructions. They don't call anybody else, so they don't currently set up new save areas. I am looking at the CPU savings of only obtaining the storage for a new save area for the high-halfs when I actually need it (because I don't know what the caller provided). Part of my questions are simply to better understand this subject. And, by some of the other posts, this is a subject were there is much confusion. Tony Thigpen -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: ZAP to expand remainder
I think you need to specify the length of the second operand or else it will take the length of WKPACK and pick up bytes beyond the end of WKPACK. On 2022-01-26 2:02 p.m., Keven Hall wrote: The second operand must end on or after the end (last byte) of the first operand for correct results. Regards Keven On Jan 26, 2022, at 11:45, Frank M. Ramaekers wrote: Will this instruction work? ZAP WKPACK,WKPACK+(L'WKPACK-L'KDAYSQC) Expand remainder In other words, can one expand the remainder from a DP instruction to the entire field? Frank Ramaekers Jr. | Systems Senior Administrator | CIS Mainframe Services Unisys | O-(512) 387-3949 | M-(254) 214-1820 |francis.ramaek...@unisys.com<mailto:francis.ramaek...@unisys.com> [unisys_logo]<http://www.unisys.com/> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all devices. [Grey_LI]<http://www.linkedin.com/company/unisys> [Grey_TW]<http://twitter.com/unisyscorp> [Grey_GP]<https://plus.google.com/+UnisysCorp/posts> [Grey_YT]<http://www.youtube.com/theunisyschannel> [Grey_FB]<http://www.facebook.com/unisyscorp> [Grey_Vimeo]<https://vimeo.com/unisys> [Grey_UB]<http://blogs.unisys.com/> [Grey_Weibo]<https://weibo.com/unisyschina> -- This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us atprivacy...@globe.life. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Saving Caller's 64-bit Registers
Can the REXX folks say anything about whether any changes to savearea size also affect VSE? It sounds like not. The original poster works in a VSE environment. On 2022-01-26 11:56 a.m., Peter Relson wrote: Some more info from the REXX folks: The savearea passed to programs invoked via ADDRESS LINK, LINKMVS, or LINKPGM was extended to pass a 144-byte savearea to the caller by APAR OA44581 (whenever that became available). Programs invoked as REXX functions or subroutines are still passed a 72-byte savearea (I don't know why they didn't similarly change that). This makes REXX LINK more compatible with REXX ATTACH -- the target routine in both cases gets a 144-byte savearea. Peter Relson z/OS Core Technology Design Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Saving Caller's 64-bit Regsiters
For both VSE and zOS, there is REXX documentation (VSE'sis at https://www.ibm.com/docs/en/zvse/6.2?topic=packages-interface-writing-external-function-subroutine-code that states that on entry to the called routine Register 13 contains the address of a register save area. What it doesn't say is how large that save area is. My assumption would be that it is 18 fullwords, just because it's not documented as being any different in VSE or z/OS and REXX is a 31-bit application. The fact that is not explicitly documented is troublesome, since as was pointed out, the writer of the routine sets the requirements for the users of the routine, and it would be reassuring to know that REXX always meets those requirements. On 2022-01-24 2:14 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 01/24/2022 02:01:29 PM: When I'm following save area chains in a dump, starting with R13, I look at the second word. If it is an address, I know that the save area at that address is a standard 72-byte save area. If it is F4SA, F5SA, F7SA, or F8SA, offset X'80' from R13 is the address of the save area, and I know what format it is. That is all well and good -- when you're looking at a dump. But I'm given to understand that none of that information is helpful when a called program receives control from a 2nd- or 3rd-party caller (i.e., any caller not written on-site) in terms of being able to tell how much storage the caller allocated for the savearea whose address is passed to the called program. Now, if I've got that wrong, then please enlighten me. Thanks. Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: 64-bit registers (was: Unsigned Binary Formats)
That's correct. Your greater the 4-byte arithmetic just got easier! If you use them in an assembler subroutine, you should save the the incoming 64-bit register and restore it on the way out. There are details about only saving the high half and it not being necessary for certain registers, but in general that's your responsibility. On 2022-01-19 1:44 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 01/19/2022 01:00:07 PM: I'd suggest you clear the high-order word of R2 then use CVDG. Would that work for you? OK, that brings up a question that I have not had to address before this. Up till now I've used odd-even register pairs for 64-bit operations. But I'm given to understand that all general registers are actually 64-bit now instead of the traditional 32-bit. Is that correct? So, 32-bit instructions just use the low order 32 bits of the general purpose register and 64-bit instructions automatically use the full register -- with no register "pairs" involved. Is that correct? Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Unsigned Binary Formats
Insert the unsigned 4 byte value in the right half of a zeroed 64-bit register and use CVDG. There is also a CVBG. On 2022-01-19 12:32 p.m., Dave Clark wrote: If I have a 4-byte signed binary number (i.e., up to 2147483647), I can convert it to packed format as follows. LR2,BIN4 CVD R2,PWORK8 How would I convert a 4-byte --un--signed binary number (such as an RBA, up to 4294967295) to packed format? If you need a reason, I'm writing an external REXX function that needs to be able to return an RBA in zoned decimal format to the caller. Thus, although I know how I would convert a signed zoned number back to a signed binary format, I also need to know how to convert those unsigned 10 zoned digits back to an unsigned binary format. Help with both issues? Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Convert Zoned to Packed
Also remember that COBOL, like any compiled or interpreted language, can define fields and operations on those fields that require an assembler subroutine to implement. I also understand that more recent versions of the IBM z/OS COBOL compiler use decimal floating point to implement decimal arithmetic. I don't know about VSE. On 2022-01-07 2:48 p.m., Dave Clark wrote: "IBM Mainframe Assembler List" wrote on 01/07/2022 02:34:49 PM: If it is possible, how do you code in assembler to convert more than 16 digits of zoned data into a packed field? I'm presuming, of course, that a packed field can be longer than 8 bytes in assembler. VSE COBOL can handle 18 digits, correct? So, that would be a 10-byte packed field. But it seems the assembler PACK instruction can only handle up to 16 digits of zoned data. Am I missing something? Hmmm, I guess I found my answer -- at least partially. I happened to read about the next instruction in the manual just out of curiosity (yeah, I'm a nerd who likes to read technical manuals). So, apparently, I can pack up to 31 digits into a 16-byte packed field using the PKA instruction. However, it looks like I have to handle the sign separately. Sincerely, Dave Clark Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Vector Ops
A belated thank you to you, Dan. I appreciate your explanations of the more esoteric features of the Z hardware instruction set. I would assume that the selection of 42 as the solution was done with full knowledge of the precedent. And I was informed the 6 x 9 is 42 in base 13. Gary On 2021-12-14 12:03 a.m., Dan Greiner wrote: Back in late September, I posted a series of PowerPoint slides describing the IBM z/Architecture vector facilities on my Google Drive:https://drive.google.com/file/d/13OhBkhgbU7N6a20nVo5uEAnR-s3-Pyz8/view?usp=sharing The most common response I've received is something to the effect of "good stuff ... now what do I do with it?" Last Christmas, I received a really annoying puzzle as a gift ... annoying because solving it involved a lot of repetitive stress on my already inflamed carpals. A simple C program did the trick, but I wanted to see if I could use the vector ops to do better, so I started researching them. This led to a months-long documentation project resulting in the slides mentioned above. I've put together another short presentation — only 11 slides — that describe the puzzle and one solution using vector instructions. There are numerous features of the vector architecture, but this pitch illustrates what I think are a few key points: SIMD, branch avoidance, and a really neat instruction (VPERM). Unlike my previous stuff, there is no animation in these slides; the meat of it is in the presenter notes, so make sure you view the notes page. https://docs.google.com/presentation/d/1gD089nRo8Lch-rkg7T7pbwclBAvsp0bf/edit?usp=sharing&ouid=104012833061983447284&rtpof=true&sd=true Enjoy! Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Hints for coding JES2 exit routines (z/OS JES2 Documentation)
It could be that they were trying to give stylistic recommendations: only branch if the bit(s) in question are set or not set, otherwise fall through to the next instruction. But if they are going so far as to recommend specific acceptable instructions, one would think they would mention the fall-thru case. I'm not sure the conclusion is valid "the logic of the branch instruction does not have to be modified when adding or deleting flags in the instruction mask." If the mask is for one bit and I add another bit, I not sure that BO or BNO will still be what the correct instruction. On 2021-12-13 2:54 p.m., Seymour J Metz wrote: Is everyone in agreement on the above branch instruction recommendation? In agreement with each other? Yes. In agreement with you? No. There are three possible CC values after TM, not just two. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ____ Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Janko Kalinic [the.pds.comm...@gmail.com] Sent: Monday, December 13, 2021 1:24 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Hints for coding JES2 exit routines (z/OS JES2 Documentation) Assembler instructions - All TM (test-under-mask) instructions should use BO/BOR/BNO/BNOR/BM/BMR branch instructions rather than BZ/BZR/BNZ/BNZR branch instructions. If this technique is used, the logic of the branch instruction does not have to be modified when adding or deleting flags in the instruction mask. Is everyone in agreement on the above branch instruction recommendation? Regards, John K
Re: Is it possible to update CSA from an unauthorized user-key program?
That's a legitimate complaint. We are an ISV and actually have a product that would meet his requirements; the problem is that it does quite a bit more, so it's probably not cost-effective for the OPs purposes. And considering the cost in time, money, software and hardware of meeting the security requirements of some commercial mainframe environments, I suspect most ISVs would not see a sufficient market to provide a narrower solution at an acceptable cost to potential customers. On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote: I don't know about anyone else, but I am really getting tired of these continuous calls from supposedly knowledgeable people to "invent your own PC or SVC to protect your global shared storage application solution and don’t trust anyone or anything and if you do this your integrity is your own problem not ours". Why hasn't IBM or even some clever ISV supplied a pre-packaged, integral-part-of-the-operating-system solution to safely share and update global storage any way an application designer can imagine and easily usable from normal HLL application programs? Protected by standardized SAF security calls and all that is needed for real integrity. Why do we have to "roll our own" and "own the loss of integrity if you screw it up"? Why can't those who know more than we do provide the solution? This isn't rocket science, it's just programming, and IBM + ISV's have more programmers more intimately familiar with how to safely secure memory sharing than anyone else, so why aren't they doing it instead of foisting it onto us? DB2 does it for disk-resident data, why can't something like that (maybe not QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be provided for global memory? There are exabytes to be exploited!! Help us use them!! Peter Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Monday, December 6, 2021 9:27 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Is it possible to update CSA from an unauthorized user-key program? Assuming you could accomplish your objective, which appears to be user-key (8 or 9) storage updatable by any process running on the lpar, it would appear that not only is the information stored there not confidential, but its integrity is not important. You have no protection from any user-key program overlaying the storage with any value it wishes, whether purposely or accidentally. Even if you have a plan to restrict access to obtaining the address of this shared storage, accidental overlays could still occur, like buffer overruns. a) In general, key 0 memory that is not fetch protected can be read by any key 8 user b) By definition, key 8 users cannot update key 0 memory. c) Considering the restrictions, any value of key 0 to key 7 works for the macro d) That would break integrity rules. One method for updating the storage is to encapsulate the update routine in a PC or SVC, which includes a security check for whether the caller is authorized to update the value and determines the location of the memory itself (not trusting the caller to supply it). On 2021-12-06 7:13 p.m., Wendell Lovewell wrote: Hello Listers, I'd like to be able to update a common storage area across all CICS and batch regions. I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it requires supervisor state and/or key 0-7. It seems that something like issuing a STORAGE macro similar to: STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM ...from an authorized program would allocate the storage needed. But I don't know the rules for accessing it from "user-mode" (unauthorized, key 8) programs like a CICS application. a) Given the address of the storage obtained like that, can any user-mode program read that storage? b) Could a user-mode program update that storage? c) Should the KEY parameter be specified, and if so, what value should I use. Afaik it has to be 0-7 since User-key CSA was outlawed. d) Am I correct that there isn't an IRAV64 option that will allow a user-mode program to update the storage? Thanks for your help! Wendell (Cross-posted to the CICS list.) -- This message and any attachments are intended only for the use of the addressee and may conta
Re: Is it possible to update CSA from an unauthorized user-key program?
Assuming you could accomplish your objective, which appears to be user-key (8 or 9) storage updatable by any process running on the lpar, it would appear that not only is the information stored there not confidential, but its integrity is not important. You have no protection from any user-key program overlaying the storage with any value it wishes, whether purposely or accidentally. Even if you have a plan to restrict access to obtaining the address of this shared storage, accidental overlays could still occur, like buffer overruns. a) In general, key 0 memory that is not fetch protected can be read by any key 8 user b) By definition, key 8 users cannot update key 0 memory. c) Considering the restrictions, any value of key 0 to key 7 works for the macro d) That would break integrity rules. One method for updating the storage is to encapsulate the update routine in a PC or SVC, which includes a security check for whether the caller is authorized to update the value and determines the location of the memory itself (not trusting the caller to supply it). On 2021-12-06 7:13 p.m., Wendell Lovewell wrote: Hello Listers, I'd like to be able to update a common storage area across all CICS and batch regions. I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it requires supervisor state and/or key 0-7. It seems that something like issuing a STORAGE macro similar to: STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM ...from an authorized program would allocate the storage needed. But I don't know the rules for accessing it from "user-mode" (unauthorized, key 8) programs like a CICS application. a) Given the address of the storage obtained like that, can any user-mode program read that storage? b) Could a user-mode program update that storage? c) Should the KEY parameter be specified, and if so, what value should I use. Afaik it has to be 0-7 since User-key CSA was outlawed. d) Am I correct that there isn't an IRAV64 option that will allow a user-mode program to update the storage? Thanks for your help! Wendell (Cross-posted to the CICS list.) Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Base-less macros
From what I understand that you are right. However OP Mark indicates there is a convention at his shop which allows the calling program (the presumed allocater of the save area) to indicate to the called program how large the save area is by using the F4SA eyecatcher. It's a convention at his shop, but it's no different in my mind from conventions that use enqueues or Compare and Swap to control access to code paths. They only work if everyone plays by the rules. On 2021-11-30 9:36 a.m., Charles Mills wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. So the OP's premise is incorrect. A program cannot learn the length or format of the incoming save area by examining it (although an FnSA string there would give you a clue of what the caller was up to in general). I am inferring that there is no way for a called program to determine programmatically the length or expected format of the incoming save area. It must be agreed upon by the two programs, or phrasing it differently, the called program's save area expectations must be documented and respected by the caller. Am I right, or off (pardon the pun) base? Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Tuesday, November 30, 2021 5:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Steve Smith wrote: And there are other bizarre ways to return without restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
From the conversation, I think this is an internal convention at their shop. They require the callers to put the eyecatcher in to indicate they created/reserved a 144-byte savearea. Callers that don't do that are probably some kind of legacy and can't be assumed to have a 144 byte save area. I gathered the macro was the glue code between various callers and the actual subroutines. On 2021-11-30 1:40 p.m., Paul Gilmartin wrote: On Nov 30, 2021, at 11:21:51, Mark Hammack wrote: If the caller only passes a 72 byte save area (rather than part of a larger save area stack) then I've got bigger problems than how to test and/or set c'F4SA' in the save area. :-) The code of the subroutine should cut the Gordian Knot; take a cue from "UNIX System... Callable Services" and provide dual entry points, e.g.: AMODE (BPX1OPN):31-bit AMODE (BPX4OPN):64-bit -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Base-less macros
Actually the 24-bit architecture wasn't the legacy problem as much as not restricting the leading byte of a fullword (whether in memory or registers) that the hardware would interpret as an address. That led to the use of the high-order bit to denote a 31-bit address, which led to the missing 2G in the 64-bit architecture. On 2021-11-30 11:57 a.m., Charles Mills wrote: I remember well. It was very much about saving storage. Storage was precious. Main memory sizes were measured in kilobytes, not megabytes or gigabytes. There was no virtual storage, so main memory size was very much a limiting factor -- not just to performance, as it is now, but an absolute limit on what program and how many programs one could run at once. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Ward Sent: Tuesday, November 30, 2021 8:52 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 30/11/2021 16:36, Paul Gilmartin wrote: Didn't IBM do that? Doesn't mean that it was a good idea :-) "The 64-bit IBM zSeries (2001) still supports 24-bit mode, 40-plus years later. Why did 24-bit happen? I’m told that it was all for the sake of one low-cost early model, the 360/30, where 32 bits would have run slower because it had 8-bit data paths. These were last shipped more than 30 years ago. Were they worth the decades of extra headaches?" John R. Mashey, "The Long Road to 64 Bits" ACM Queue, 4, 8, October 2006 https://queue.acm.org/detail.cfm?id=1165766
Re: Base-less macros
Can you temporarily save one register, load it register with the 4(R13) and use a CFI? On 2021-11-29 5:51 p.m., Mark Hammack wrote: So an interesting dilemma: I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. Before saving the registers, I am checking whether the current save area is old (24/31 bit) or new (64 bit) save area. The original code used CLC =C'F4SA',4(R13) to check (since it is all our code, I don't need to worry about the other 64 bit save area formats). However, that implies a literal pool within 4k of the subroutine entry point (R15 at this point). I could add a 4 byte literal to the macro and then branch around it. The other option I thought of which removes the necessity of a base register is to use CLHHSI 4(R13),C'F4'/JNE .../CLHHSI 6(R13),C'SA'/JNE ... However, this is confusing and since there are multiple points in the macro where I need the F4SA literal, I'll probably go with door number one. If only there were 20 bit displacement options for CLC and MVC...(LRL, LARL, LAY, etc. have come in handy for reducing the number of LTORGS in the programs, especially for =A(address) type literals). *Mark* On Mon, Nov 29, 2021 at 4:06 PM Seymour J Metz wrote: "When control is returned to your control section from the called control section, registers 2-14 contain the same information they contained when control was passed, as long as system conventions are followed." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] Sent: Monday, November 29, 2021 3:57 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros The assembler services guide doesn't specify what is in (bottom half of) R14 upon return. Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the low-order bit set. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, November 29, 2021 14:01 To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: DON'T DO THAT! I had to find/redo all our code that did this when our subroutine return logic was changed to use a BIC instruction. Which of you violated standard linkage conventions? My understanding is that R14 is expected to point to the instruction after the CALL; R15 to the ENTRY point. Either may be changed by an embedded CALL and should be treated as volatile. RETURN should use LM to retrieve the value of R14, etc. -Original Message- From: Steve Smith Sent: Thursday, November 25, 2021 13:49 My suggestion of using R14 for the base was because it's already set by the call to the subroutine. -- gil
Re: Base-less macros
The performance consideration I think would be the loading of R14 immediately before its use in the branch instruction. Moving it up a couple instructions may help. On 2021-11-25 2:11 p.m., Jeremy Schwartz wrote: Nice job and thanks for correction on branch to table. One thing to point out especially with mainframe assembly is just to be sure when generating instructions that the proper instruction facilities are installed other wise S0C1. Best regards, Jeremy Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: Thursday, November 25, 2021 8:31 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12 --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: ASMA030E?
I think the consensus just recently (in a discussion of where the arguments (resolved at build time rather than execution time) of an expanded macro should be placed) was that EX(RL) accesses the instruction in the I-cache. On 2021-11-23 8:55 p.m., Charles Mills wrote: Is the EX target accessed from the I-cache or the D-cache? I have forgotten but I know I have seen it documented. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, November 23, 2021 3:57 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ASMA030E? On Nov 23, 2021, at 15:23:49, Charles Mills wrote: ... LA somereg,=C'blah') And an EX rather than an L. Would that work for you? Does require a base register. LARL would not, but it's 6 bytes rather than 4. Does an EX of an LARL displace relative to the location of the EX or thee LARL? HLASM can only assume the latter and hope the hardware concurs. (Is the EX target accessed from the I-cache or the D-cache?) A harder question might be whether a literal S-constant assumes the USING in effect at the point of generating the literal or at the LTORG. Is this documented or does POLA suffice? (Thinking back a few weeks to a recherché use of a triple S-literal to generate an SS instruction in the literal pool.) -- gil
Re: Base-less macros
How about fixing the problem you had with branch tables and introducing a new instruction JIC (branch relative indexed conditional)? JIC *+4(15),nn J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE J RCERR_RTN Where nn is an immediate value hw that limits the value of RC and Jumps to *+4+(nn+4) if it is exceeded (last valid entry + 4) On 2021-11-23 11:24 a.m., Charles Mills wrote: Should that second instruction be an LA? I quit using branch tables. I know, they are useful, but IMHO wild branches are the worst of bugs, and so I have eschewed branch tables. The architecture could use a new instruction "branch relative indexed" or JI. So then your original code would become JI *+4(15) JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 7:42 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program.
Re: A question about an Authorizing PC Service Routine
Sometimes you hear of certain types of hacks on PCs (personal computers), where they insert some code that allows them to control the machine but most of the time lies there silently and un-noticed. That is what this is on z/OS. If a person can get this code into a system unnoticed and untraced, at some later time they or an accomplice can invoke it to do anything they know how to do, as others have pointed out. If they plan well, they can be sure that backups are corrupted for a period of time before actually interfering with the running system, making recovery a challenge. Determining that this code is installed in the system is not rocket science (not casting any aspersions here on Rocket Software). Z OS hackers talk about looking for an SVC that would put a problem state program into supervisor state. This is just an updated version of the same technique. On 2021-10-30 1:06 p.m., Keven Hall wrote: Hi Paul Yes, anybody can call this PC and it will branch to the address in R1 with Psw Key 0. The target code probably is expected to issue a PR to return to the instruction following the PC . The System is basically compromised and unsecured Regards, Keven Hall On Oct 30, 2021, at 09:31,esst...@juno.com wrote: . Hello . I discovered this program and found it interesting. When invoked from a Non Authorized program it will switch the calling routine into supervisor state. . This is the complete PC Service Routine. * LCLC &CSECTDEFINE LOCAL CSECT VARIABLE &CSECT SETC 'XMS@SVC' INITIALIZE CSECT SYMBOL &CSECT AMODE 31ADDRESSING MODE &CSECT RMODE ANY RESIDENCY MODE &CSECT CSECT J ZGO Jump Around Module Identifier * JMODID ID=&CSECT * ZGO CNOP 2,4 LM1,2,0(1)Load passed parameters SPKA 0(2)Set PSW key EREG 2,13Get caller's registers off stack BSM 0,1 Branch back to User Code LTORG Local Litteral Pool * XMS@SVCP END &CSECT . The above module resides in LPA and runs as a Non Space Switching Stacking PC Routine. The ETDEF for this module specifies a System LX. . A non APF program can call this PC routine and switch into Supervisor State. The BSM 0,1 Branches back into user code, which will now be running in supervisor state. The User Code would eventually issue a PR instruction to remove the Linkage Stack Entry. . 1st It is my assessment the above code circumvents MVS integrity protocol. Is My assessment correct ? . . 2nd For curiosity - Once this PC routine Branches back to the users code (BSM 0,1), the user code is running in supervisor state and would issue a PR instruction to remove the entry from the linkage stack. I find this code very messy. How would the user code return to an instruction following the BSM so the PC Service Routine would issue the PR instruction ? . Paul D'Angelo * Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Ensuring LRL 2nd operand alignment
If you know whether your instruction is aligned on a fullword or not, if the number of halfwords specified in the instruction is even, the displacement is an integral number of fullwords, if not, not. On 2021-04-30 3:35 p.m., Stanislawski, Shawn (National VM Capability) wrote: Guessing alignment is the problem. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Help with EZASMI assembly
There was an assembler warning (and it was considered "bad form" if a programmer used the same construction). On 2021-01-21 9:35 p.m., Paul Gilmartin wrote: On 2021-01-21, at 19:07:36, Gary Weinhold wrote: ... the GET still has a "L 15,24(1)". Is there any harm in that? In days of yore there may have been a performance penalty, but now? In a contrived case, it may depend on displacement reach: USING 5000,2 LA15,6000(1) but not: USING 5000,2 LA15,6000(,1) It also contained CICS macro DFHRMCAL that generated a CSECT statement instead of saving and using &SYSSTYP. We were using this macro in RSECTs. Isn't that the long way around instead of: &SYSLOC LOCTR ??? So it wasn't all about reentrant code; but it was about a lead programmer who wanted all assemblies to end with no errors with all warnings flags set, especially for less experienced programmers. -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Help with EZASMI assembly
We had a MACLIB that contained ENDREQ,GET, ESTAEX, IDACB2, PUT all of which had L or ST instructions with an index and no base register which caused the assembly warning message. We didn't want to disable the warning because we wanted to catch our own errors. Just a cursory check indicates the GET still has a "L 15,24(1)". It also contained CICS macro DFHRMCAL that generated a CSECT statement instead of saving and using &SYSSTYP. We were using this macro in RSECTs. So it wasn't all about reentrant code; but it was about a lead programmer who wanted all assemblies to end with no errors with all warnings flags set, especially for less experienced programmers. This discussion has reminded me to check whether we still need these overrides. On 2021-01-19 9:47 a.m., Peter Relson wrote: Gary W wrote: I recall we had to do it to produce reentrant code with some IBM macros about 20 years ago. If you happen to remember, I would be interested in learning of that example/experience. To all: Bringing up issues with respect to macros that require codereg addressability on the forum provides for interesting discussion but is not in general productive. Please consider helping yourself and others by opening an RFE. I think the team might consider making such updates, but might not do so without an RFE to which the work can be correlated. Peter Relson z/OS Core Technology Design Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Help with EZASMI assembly
It is possible to copy the macro to your own library and make it compatible. It, of course, requires monitoring for changes in the macro every time maintenance is installed on your system, but I recall we had to do it to produce reentrant code with some IBM macros about 20 years ago. On 2021-01-17 8:54 a.m., Mark Henderson wrote: Thanks for the feedback, John. Seems there's no relief in sight. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: An old-timer confirming what's changed (since MVS/ESA :-) )
A short answer is so the hardware knows to use the 64-bit address in the 64-bit register instead of just the last 31-bits (AMODE-31). On 2020-11-24 9:38 a.m., Rupert Reynolds wrote: Reading (a lot of) documentation from IBM it seems that a lot has gone into the *nix side of z/OS and extra instructions and 64-bit addrssability for data, but that the code itself still resides below the bar, so that most AMODE 24 and 31 code from years ago will still compile/assemble and run as is, or with minimal change. Is that fair? But if new code using 64-bit data is still loaded and executed below the bar, and new instructions and extended registers handle the addressing of data with 64-bit addresses, why is there an AMODE 64 at all? Is it simply to indicate that a larger (DS 18D) savearea should be provided, as it may be needed by the called program? Thanks for any clarification you can offer. Roops Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: SDUMPs
What I normally due in this type of situation is add a SYSUDUMP DD and zap the instruction location where I want the dump to X'00' to force an abend. If you are running in LE (COBOL or some other HLL is in the environment), add a CEEOPTS DD* with TRAP(OFF) to prevent LE from reimaging the abend. On 2020-10-29 7:56 p.m., Tony Thigpen wrote: Once I added SYSMDUMP DD SYSOUT=*, I now see the dumps in IPCS. I just can't seem to find any command in IPCS that just lets me see the GRs and browse storage. Tony Thigpen Seymour J Metz wrote on 10/29/20 6:37 PM: 1. What is the authorization of your program? If unauthorized, consider IEATDUMP instead. 2. Do you have a SYSMDUMP DD allocated? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ____ Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Thursday, October 29, 2020 6:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: SDUMPs I am very open to using IPCS (although I still have to learn use it.) When I use SDUMP, I get the following message on the console: *74 IEA793A NO DUMP DATA SETS AVAILABLE FOR DUMPID=011 BY JOB (FLASHME4). USE THE DUMPDS COMMAND OR REPLY D TO DELETE THE DUMP I tried: DD ADD VOL=HKYSY4 18.05.26 HKYP dd add,vol=HKYSY4 18.05.26 HKYP IGD100I 1213 ALLOCATED TO DDNAME SYS00051 DATACLAS ( ) 18.05.26 HKYP IEE855I DUMPDS COMMAND RESPONSE DUMPDS COMMAND SYS1.DUMP DATA SET STATUS DASD VOLUMES ADDED: HKYSY4 Then: dd alloc=active Then: DD ADD DSN=01 18.07.01 HKYP dd add,dsn=01 18.07.01 HKYP IEE855I DUMPDS COMMAND RESPONSE DUMPDS COMMAND SYS1.DUMP DATA SET STATUS SYS1.DUMP DASD DATA SETS NOT ADDED: LOCATE FAILED: (01,08) Suggestion? Tony Thigpen Seymour J Metz wrote on 10/29/20 5:35 PM: SDUMP in MVS is for creating an unformatted dump to be viewed online with IPCS. For a short formated storage dump use SNAPX. However, once you get used to it you may find SDUMP and IPCS more convenient. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Thursday, October 29, 2020 4:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: SDUMPs All, Trying to debug a program I am porting from z/VSE to z/OS. Unfortunately, the debug process on z/OS is a lot different from z/VSE. Normally, all I want is to create either a small SDUMP so I can look at some storage before I take the program to an end. On z/VSE, I just use the SDUMP macro and the storage is printed on the z/VSE equivalent of SYSOUT=*. I am using: SDUMP HDR='GP_VOL',STORAGE=((2),(3)) Is there any way to force the data to the JES2 SYSOUT? Tony Thigpen
Re: Is TESTCB a bad boy ?
I am reassured to hear the instruction being executed was being built in storage dynamically obtained for this instance. From the conversation preceding this that was not clear and left me thinking the routine was not actually reentrant, but was writing into itself and relying on the proximity of the two instructions (MVI, then EX) to simulate reentrancy. Does an executed instruction have to be brought into the I-cache? Or is this just the delay because an instruction references data changed by the preceding instruction? Gary On 2020-10-28 12:28 p.m., Peter Relson wrote: No one would say that every function is written to perform as well as it conceivably could. Especially when there is no business need. If you can demonstrate a problem due to poor performance of an existing function, then open an RFE and ask for it to be improved. But simply saying that it is not as good as it could be will not be sufficient justification. In the grand scheme of things, one additional "EX" is often not a big deal. As with most performance-related things, it comes down to "how often?". I wouldn't tend to think of a "compiler" (COBOL or otherwise) as generating code to invoke TESTCB. Maybe an LE-provided function would. Maybe I'm mis-thinking. IDA019C1 is a reentrant module. In practice, it is not going to be the case that the storage being written into to create the execute target instruction is in the same cache line as the execute itself (the execute target is built within the caller's 72-byte save area). According to comments in the module, the module was re-written in the early 80's, well after the time that the OP has the source for. I have no idea what it looked like before then. It still does the dynamic building of the TM instruction. As to why the module dynamically builds its TM instruction, it probably did not matter too much back when this module was written (way before the I-cache and D-cache were separated). Probably someone thought it was "clever" and/or "easier" (the processing is table-driven), and no one has made a case to change it. And maybe the limited amount of dynamic storage available to them led them down this path. Peter Relson z/OS Core Technology Design Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Is TESTCB a bad boy ?
A performance hit is only a factor if this will run many times an hour in an application. However as a possible future example of how to code a TESTCB that might end up in a heavily used subroutine, I believe the standard form of TESTCB should never be used without lots of warnings if anyone else will ever see it. TESTCB has list, execute, and generate forms; they generate reentrant code. On 2020-10-26 2:07 p.m., Christopher Y. Blaicher wrote: This will not have the same performance hit. The problem with the MVI was the CPU had to 1) bring the cache line into the data cache; 2) apply the MVI data; 3) refresh the cache line in the instruction cache; and finally 4) execute the instruction. Doing an EX skips steps 1, 2 and 3. EX has its own set of overheads, but nowhere near what all the cache hits have. Chris Blaicher Technical Architect Precisely.com Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Monday, October 26, 2020 11:16 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Is TESTCB a bad boy ? This message originated Externally. Use proper judgement and caution with attachments, links, or responses. In ancient times it was common practice to do this sort of thing... SWITCH NOP GO MVI SWITCH+1,X'F0' I believe this clears the cache and causes severe performance hits In my research into TESTCB for the z390 Project I found that it dynamically builds the subject instruction for an EX Would this have the same performance hit ? Melvyn Maltz.
Re: Conditional MVCL macro?
Our testing on a Z14 (MVS under VM), MVCL was considerably slower than a 256-byte MVC loop plus an executed MVC for various unaligned data lengths from 40 bytes to 32K. For zeroing memory up to 1G, XC in a loop was about the same as MVCL up to 256 bytes, then MVCL was faster (MVCLE was slightly slower even when the MVCL had to be looped)). MVCL was also faster than MVPG, DSPSERV RELEASE, PGSER in general, except when page aligned for MVPG. On 2020-10-20 12:39 p.m., Mike Hochee wrote: Really interesting thread to start the day with! Our experience has been that the MVC loops are typically faster, up to a point, that being about 30-40 instructions in the pipeline and as mentioned, and this seemed very processor dependent. However when source and target operands happen to both be aligned on a page boundary, then the opportunity exists for the async data mover to kick in if a move long is being used. I think this applied to both MVCL and MVCLE, but not sure. So ideally a macro would want to utilize both MVCs and MVCL/E. More grist for the mill! Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of baron_car...@technologist.com Sent: Tuesday, October 20, 2020 12:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Conditional MVCL macro? Caution! This message was sent from outside your organization. The COBOL compiler for a 4000 byte move, from to the same with OPT(2) generates LAY R10,5072(,R9) FROM LA R7,1072(,R9) TO MVC 0(256,R7),0(R10) MVC 256(256,R7),256(R10) MVC 512(256,R7),512(R10) MVC 768(256,R7),768(R10) MVC 1024(256,R7),1024(R10) MVC 1280(256,R7),1280(R10) MVC 1536(256,R7),1536(R10) MVC 1792(256,R7),1792(R10) MVC 2048(256,R7),2048(R10) MVC 2304(256,R7),2304(R10) MVC 2560(256,R7),2560(R10) MVC 2816(256,R7),2816(R10) MVC 3072(256,R7),3072(R10) MVC 3328(256,R7),3328(R10) MVC 3584(256,R7),3584(R10) MVC 3840(160,R7),3840(R10) However for 5000 bytes it generates: LAY R7,6072(,R9) LA R10,0(,R7) LA R7,1072(,R9) LHI R11,0x13 EQU * MVC 0(256,R7),0(R10) LA R10,256(,R10) LA R7,256(,R7) BRCTR11,L0128 MVC 0(136,R7),0(R10) And yes the change occurred at 4097 bytes. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Tuesday, October 20, 2020 10:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Conditional MVCL macro? @Ed, can you elaborate a little on your reasoning? (Not doubting it; just curious.) Is it that the interruptibility provides a significant improvement over MVCL? Or the support for lengths greater than 16M? Or ... ? When I asked Dr. Shum about move strategies he seemed to indicate that for data that was already or would soon anyway be in cache an MVC loop was generally faster than MVCL. (I did not ask about MVCLE at the time; not sure why. He did not suggest it.) Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ed Jaffe Sent: Tuesday, October 20, 2020 6:52 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Conditional MVCL macro? We've switched almost exclusively to MVCLE except for short, fixed-length moves.
Re: Deep cuts
Nulls Sent from my BlackBerry — the most secure mobile device — via the Bell Network Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: 0014e0e4a59b-dmarc-requ...@listserv.uga.edu Sent: September 4, 2020 09:32 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Reply to: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Deep cuts On 2020-09-04, at 07:23:49, Gary Weinhold wrote: > > Even if they'd had the foresight to use a different way to indicate the > end of a parameter list, I don't think they were consciously seeing not > changing the extenal architecture of the hardware for 40 years. > Terminatingthe argument list with a null pointer would have allowed extension to 32 or 64 bits and supported an empty argument list, not possible with CALL -VL. But storage was too expensive a half century ago to add 4 bytes to each CALL. What does JCL generate for an EXEC with no PARM? -- gil
Re: Deep cuts
Even if they'd had the foresight to use a different way to indicate the end of a parameter list, I don't think they were consciously seeing not changing the extenal architecture of the hardware for 40 years. The 360 was designed to replace IBM and competitor systems that had different hardware instruction sets. Although the 360 supplied many different machine capacities in the same architecture, I don't know that IBM was already planning to always provide backward-compatible architecture forever. They may have considered providing emulators as they did for 1400 series in the early 360s, but expected conversions for major architectural changes, like 31/32 bit. On 20-09-04 6:16 a.m., Leland Bond wrote: Fullword bit 0 is used to mark the last entry in parameter lists since the beginning of OS/360. Using that bit for addresses would have broken too much software. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Reply to ZoomToSHARE.org session Wed. Sept. 2, 2020 from 11-12 AM EDT
Don't you get the impression that for that low price you get a TSOid, complete access to create and update datasets with your own prefix, a z/OS volume on a VM minidisk, and the ability to submit jobs and see the output? I suspect you become one of many TSOid's on one z/OS system with security designed to keep your id isolated. I worked for a vendor over 20 years ago that had a similar arrangement for mulitple TSO ids with a US-based service bureau. Wouldn't the same model work now, wherever it's actually deployed? I also got the impression that mathrutech is using a service bureau to provide the environment they are reselling. Their warning that you shouldn't meddle with system datasets implies to me that you shouldn't assume you are completely secure in your environment on their system; that they attempted to lock everything down but they can't guarantee it. On 2020-09-02 7:41 p.m., Schmitt, Michael wrote: So the website is http://www.mathrutech.com/index.html. The pricing seems suspicious to me. Are you sure this is a real mainframe and not an older version of IBM Z Development and Test Environment (or a newer version of Rational Developer for System Z Unit Test), where you’re actually running on a PC? The software list they provide seems to match the RDzUT list. But even here what they’d need to be doing is allowing multiple users to share the same “one” test environment user. IBM’s site says that the personal edition of Z Development and Test Environment runs at least $5,220 per user per year, which is $435 per month. From: IBM Mainframe Assembler List on behalf of FancyDancer Reply-To: IBM Mainframe Assembler List Date: Wednesday, September 2, 2020 at 3:41 PM To: "ASSEMBLER-LIST@LISTSERV.UGA.EDU" Subject: Reply to ZoomToSHARE.org session Wed. Sept. 2, 2020 from 11-12 AM EDT I really enjoyed "meeting" all of you at today's session. I mentioned that I have rented time on a zOS system to test some macro code using HLASM. The following is the reply that I received back from my first inquiry into getting access to HLASM. The price offered to me was $50.00 US for one month, and I still have more than a week left! < ORIGINAL RESPONSE ===> Hi Dan, Thank you for choosing MathruTech service. Please find below details of Mainframe ID. This ID is valid till 13-Sep-2020, however you can get it extended prior to expiration. IP Address: xxx.xxx.xxx.xxx Port: 23 or 8723 ID: XX Password: YY DB2 database: DBZ Tablespace: TSXX DB2 Plans: XXA, XXB, XXC, XXD, XXE, XXF Predefined CICS resources: Apart from these you can define resources with CEDA under group XX Program: XXXPGM1 Mapset: XXXMPS1 Transaction: XXX1 File: XXXFIL1 DB2Entry: XXXENT1 DB2Tran: XXXTRN1 TDQueue:XXXT Mappings Txn Program DB2Entry Plan DB2Tran DB2Entry Txn XXX1 -> XXXPGM1 XXXENT1 -> XXA XXXTRN1 -> XXXENT1 & XXX1 Please make sure using volume XX for all data set creations. Also ensure any data set allocations should have your ID as prefix. Use your ID name as CICS group name. Data set space allocations should always be in Tracks; for PDS, primary 8 & Secondary 12 should be sufficient. You can find all the compile JCLs in XX.JOBLIB, member @README will give fair details. Important: Please note that users are advised not to meddle with system datasets, users are supposed to work only with their own data sets. We bring to your kind notice that any violation of this clause will result in ID termination without notification. We request users to kindly comply with this and understand that is imposed from our service provider. Regards, Ramesh S, Mathru Technologies. Mob: +91-9885439898 Web: https://clicktime.symantec.com/3N4XsaXVXyF3UkM34UY7Kcq7Vc?u=www.mathrutech.com Email: sa...@mathrutech.com<mailto:sa...@mathrutech.com> < END OF RESPONSE ===> Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
Thanks; I was confused by some of the responses and re-responses. On 2020-08-12 5:34 p.m., Steve Smith wrote: The goal should be to return to the caller in its amode, as that's undoubtedly what it expects. If a program is invoked via BASSM (or BSM), the amode in effect at entry is NOT the caller's amode, other than by chance. So if you save the amode at your entry, and use that for return, you will likely cause an abend or worse. This is the end of my tutorial on basic linkage. This is all well-documented in the Principles of Operation, and Assembler Services Guide Chapter 5. sas Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. On Wed, Aug 12, 2020 at 3:25 PM Gary Weinhold wrote: That was my point; If the goal is to allow the called program to switch to amode 31 and return to the caller in the amode it was in, it appears Binjamin's 2 instructions are sufficient. The original code is checking to see if they need to do this (and there is a small exposure because the opcodes could be spoofed or EXECed, as others pointed out, or the locations preceding the R14 could be unaddressable), and it may be more efficient to just run the LA and BSM without checking. Tony mentioned that the code is now used outside its original controlled environment, so the assumptions abut how it's entered may no longer apply. My comment on speed was checking the opcodes and branching take some cycles and the LA, BSM instructions may take fewer. On 2020-08-12 2:04 p.m., Martin Truebner wrote: Gary, Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? the code Tony had was to ensure that it can switch to whatever mode a routine to be called from that code needs without effecting the original caller of the code From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. no no - if BSM is needed (because original caller of the code is 24 and final target is 31) then Binjamin's code is fine (at entry!) ... but it also is executed if everyone is 24 and there is no need for it. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
That was my point; If the goal is to allow the called program to switch to amode 31 and return to the caller in the amode it was in, it appears Binjamin's 2 instructions are sufficient. The original code is checking to see if they need to do this (and there is a small exposure because the opcodes could be spoofed or EXECed, as others pointed out, or the locations preceding the R14 could be unaddressable), and it may be more efficient to just run the LA and BSM without checking. Tony mentioned that the code is now used outside its original controlled environment, so the assumptions abut how it's entered may no longer apply. My comment on speed was checking the opcodes and branching take some cycles and the LA, BSM instructions may take fewer. On 2020-08-12 2:04 p.m., Martin Truebner wrote: Gary, Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? the code Tony had was to ensure that it can switch to whatever mode a routine to be called from that code needs without effecting the original caller of the code From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. no no - if BSM is needed (because original caller of the code is 24 and final target is 31) then Binjamin's code is fine (at entry!) ... but it also is executed if everyone is 24 and there is no need for it. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: how to return?
Are we to conclude from that this discussion that this is a reliable way to ensure that an AMODE 31 subroutine returns control to its caller in the correct amode? From Binjamin's response, it appears that checking the opcode of the previous instruction was unnecessary and perhaps, depending on the speed of BSM, actually slowed down the routine. Tony, I appreciated the "quarks" for "quirks" typo. It's like we're going way deeper than just the bits and electrons level! Gary On 2020-08-12 6:18 a.m., Tony Thigpen wrote: I talked to the author of the code. 1) The original program that this code was coded within actually was a glue phase that replaced a vendor provided phase that was always called using an api macro provided by the vendor to the customer. 2) At one point, the vendor was 24bit, but later changed to 31bit. Also, the vendor changed from BALR to BASSM (with a short use of BSM during one intermediate update). 3) This glue phase has always calling additional modules using BASSM and those modules were always 31bit. 4) The original vendor macro was used in a lot of programs and they did not want to recompile everything every time the vendor changed the api macro. So, the glue code had to handle a lot of quarks in how it was called. So, the glue phase had to handle the following situations over several releases of the vendor product: 1) 24bit using BALR 2) 31bit using BALR 3) 31bit using BSM 4) 31bit using BASSM Eventually, his special entry macro was used by others even when they did not need the special functionality. Tony Thigpen Martin Truebner wrote on 8/12/20 5:15 AM: Binjamin, your sequence LA 14,0(,14) Fix-up address (in case 24 bit) BSM 14,0 Now BSM 0,14 will restore the current amode Will clear the amode-bit and BSM will set to that mode (0=24) and go there. If you are very lucky you are never called in 31 bit mode then the code will not do any harm If you are called in 31 bit mode then you could be lucky and the truncated address is nonsense in 24 bit mode- but -- Martin Trübner; everything around "PoOps of z/arch" Teichstraße 39E D-63225 Langen F: +49 6103 71254 M: +49 171 850 7132 E: mar...@pi-sysprog.de Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Clearing a register
The only hardware I can imagine that it could possibly make a timing difference is on very early 360 models. And I haven't had access to one in a long time. On 2020-08-10 6:28 p.m., Steve Smith wrote: The only difference between SR & SLR is how they set the condition code. If that could produce a measurable difference in a trillion executions, I'd love to see it. sas Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. On Mon, Aug 10, 2020 at 5:49 PM Gary Weinhold wrote: it may go back to the idea that SR might require an extra step to set/propagate the sign while SLR wouldn't. But I don't know if that actually ever made a timing difference on any machine.
Re: Clearing a register
it may go back to the idea that SR might require an extra step to set/propagate the sign while SLR wouldn't. But I don't know if that actually ever made a timing difference on any machine. On 2020-08-10 4:08 p.m., Schmitt, Michael wrote: Arrgh! You're right, I said SRA but meant SLR. That's how IBM documents standard return logic in the Assembler Services Guide: SLR 15,15 Set return code of zero So that question remains: I wonder why they use SLR instead of SR. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List On Behalf Of John Melcher Sent: Monday, August 10, 2020 3:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Clearing a register My 360/67 functional characteristics says XR 1.25 microsec SR0.65 microsec SLR 0.65 microsec -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Monday, August 10, 2020 2:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Clearing a register *** External email: Verify sender before opening attachments or links *** Yes, only clear low 32-bits of 64-bit registers. I've seen method #3 in IBM code or documentation, which makes one wonder why they used it instead of SR. I forgot about LA Rn,0. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mike Hochee Sent: Monday, August 10, 2020 2:50 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Clearing a register I tend to use XR or XGR and LLIHF or LLILF. SRA does not operate against all 32 bits, and sometimes I do not want to think about extras like sign extension with LHI. (I know, it's not much to have to think about) I suppose if you want compatibility with machines of 30/40 years ago you might tend towards XR and SR. My 2 cents worth, Mike -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Schmitt, Michael Sent: Monday, August 10, 2020 3:13 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Clearing a register Caution! This message was sent from outside your organization. There are many ways to set a register to binary zero. My question is, which is the most efficient? 1. XR Rn,Rn 2. SR Rn,RN 3. SLR Rn,Rn 4. LHI Rn,0 5. Other instruction 6. Depends on hardware 7. Depends on other factors. (What?) 8. They all have equal performance 9. Method X has worse performance but other advantages. (What?) Michael Schmitt | https://clicktime.symantec.com/3MNgr55ce6EuuspodizxSyE7Vc?u=http%3A%2F%2FTOC.ASG.COM%3A8080%2F%3FdmVyPTEuMDAxJiY5NDAwZTcxY2MxYTNlOTI2Nz01RjMxQTY1Q184NzM1XzIyOTRfMSYmMTVhZDkzNzI2NzRlYzEzPTEyMzImJnVybD1EWEMlMkV0ZWNobm9sb2d5 (469) 808-4403 | michael.schm...@dxc.com DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: Digest Utility?
i use digests for high-traffic listservs, but not assembler list. Thunderbird on PC seems to know to reply to the list and but then you have to do a lot of deleting. But the redundancy within digests in email reply chains is time-consuming to scroll through. gary On 2020-08-10 5:06 p.m., Charles Mills wrote: Is "by never signing up for a digest" a valid answer to your question? I hate digests because my entire exposure to them is from people who reply to the whole digest, mucking up the Listserve threads. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, August 10, 2020 1:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Digest Utility? As an experiment I set my subscription to ASSMBLER-LIST to DIGEST for one day. MacOS Mail.app shows the digest as a single stream of messages with unrendered Quoted-printable. There seems to be no way to reply to a single message, only to the entire digest. Thunderbird does somewhat better I can see individual messages and reply to each. But LISTSERV seems to have omitted the Reply-to: headers -- Replies would go by default to the originator, not to the list. How do others deal with digests? Thanks, gil
Re: Clearing a register
I'll make a stab at some principles behind the answer(s): Have the preceding instructions touched/changed Rn? That could affect the how long the pipeline may have to idle before changing the register. If the following instructions will check the condition code or the contents of the register, they will be delayed. However, the result in Rn can be predicted before the instruction is executed, so there may be special circuitry to bypass pipeline steps for these or following instructions. Are you interested only zeroing the 32-bit RH FW of the 64-bit registers? On 2020-08-10 3:12 p.m., Schmitt, Michael wrote: There are many ways to set a register to binary zero. My question is, which is the most efficient? 1. XR Rn,Rn 2. SR Rn,RN 3. SRA Rn,Rn 4. LHI Rn,0 5. Other instruction 6. Depends on hardware 7. Depends on other factors. (What?) 8. They are have equal performance 9. Method X has worse performance but other advantages. (What?) Michael Schmitt | DXC.technology (469) 808-4403 | michael.schm...@dxc.com DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Code visitation
Back in the day (70s), every system programmer and IBM SE i knew had a stockpile of code and JCL that they brought into every site and left with (plus additions) as they moved on. Sometimes it was on cards, sometimes on those small diameter tape reels IBM sent service on, sometime listings, sometimes microfiche. When PCs came into the picture, I assume it got much easier. And now I assume security has made it much more difficult. Gary On 2020-08-05 8:23 a.m., Seymour J Metz wrote: I suspect that's most of us. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ____ Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Keven [k...@k3n.us] Sent: Wednesday, August 5, 2020 3:49 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Code visitation Are there any of y’all out there who, like me, sometimes have a wistful yearning to see some code they wrote some number of years ago at a company they no longer work for..for no reason other than simply wanting to look at it? Maybe also to scroll some of it up and down a few times for extra fuzzies? Keven
Re: Does the z architecture have something like the SIMD instructions
You may find some of the SHARE presentations useful. I used SIMD z os share as keywords. On 2020-06-05 7:11 a.m., Seymour J Metz wrote: IBM has "Vector" instructions, but the size of a vector is limited to one quadword. Usefull, but not what you normally think of as SIMD. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ze'ev Atlas [01774d97d104-dmarc-requ...@listserv.uga.edu] Sent: Friday, June 5, 2020 12:56 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Does the z architecture have something like the SIMD instructions I admit being away from the mainframe for long time. Most of my work is on Solaris and Linux servers and therefore I do not code in Assembler. However, I was active in porting a C library into classic z/OS.I was looking to do another port and stumbled upon the fact that that library has several SIMD architecture specific extensions (Altivec, Neon are two examples). While I can ignore that stuff, I became somewhat interested in the subject. Ze'ev Atlas
Re: z/OS HLASM: EQU for statement labels
Pot, kettle On 2020-06-03 11:18 a.m., Seymour J Metz wrote: O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? No. RYFM. I'd suggest that it appears you've never actually supported code using CMS UPDATE, ROTF,LMAO! I'd suggest that you haven't a clue about what anybody else's experience is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Wednesday, June 3, 2020 11:07 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Metz scrawled: (not writing much BAL any more). I doubt that you ever were, or that you've even seen it. O my. Are you subscribing to some arcane definition of Basic Assembler Language that requires hand-punching cards on a Jacquard loom or something? Give me a break. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, Non sequitor. There's nothing in UPDATE that interferes with using labels on instructions. BTDT,GTTS (no scars, just the tee shirt) That's "sequitur", if we're being pedantic. Of course there's nothing that *interferes* with it. It's just that hygiene means you change as little as possible, so the same issue applies as with physical cards: if there's an instruction on a label and you need to add something between the label and that instruction, you have to change more. This was particularly true when hand-crafting UPDATE decks, and thus became less of an issue once XEDIT and UPDATE mode came along, but good hygiene continued. If we're going to continue the theme of being rude, I'd suggest that it appears you've never actually supported code using CMS UPDATE, or you'd know this. Or maybe you were just poorly taught.
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
I was referring to CP routines calling other CP routines. It's true that the CC also had to be set correctly when redispatching the code running in a virtual machine after intercepting a privileged operation. On 2020-06-02 10:54 p.m., Paul Gilmartin wrote (snipped): On 2020-06-02, at 19:37:25, Gary Weinhold wrote: I recall that VM/370 CP routines set CC before returning to the caller; I don't have access to the source anymore (for the last 30 years or so) to verify this and what technique was used. I just remember thinking it was different and clever (coming from a VS1/MVS background). I'd guess stuffing it in the Old PSW before LPSW returns to caller. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
I recall that VM/370 CP routines set CC before returning to the caller; I don't have access to the source anymore (for the last 30 years or so) to verify this and what technique was used. I just remember thinking it was different and clever (coming from a VS1/MVS background). On 2020-06-02 5:30 p.m., Dan Greiner wrote: Although Seymour has pointed out the OS/360 convention of placing a return code in GR15, there are numerous alternative approaches used elsewhere. Your example of using "historical opcodes" (BAL 14,some_test / BE success) was used extensively in the National Institute of Health (NIH) version of the Wylbur / Milton text editing / communications packages of the 1960s. Other operating systems and languages take different approaches (an early version of Bell Labs mainframe version of UNIX used R7 for a return code). Other than the conventional OS-360 approach, I tend to favor the above example (i.e., having the subroutine set the CC, rather than the indexed-branch approach). Having the subroutine set the CC provides a means of having (up to) four possible actions that the calling program can take upon return. You state: "The problem for me was that you have to jump through some convolutions to set the condition code." However, you still have to have some determination in the subroutine that loads a condition code (conventional approach), or selects which branch to used (index-branch approach). Using the indexed branch allows for many more possible actions -- not just binary true/false -- but may necessitate accommodating all possible branch cases following each return. I also agree that the indexed branch approach may be more complicated to maintain. As to how to set [and preserve] the condition code, many experienced assembler programmers have yet to discover the "newer" instruction SET PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with tongue pressed firmly in cheek, since these unprivileged instructions have been around since the introduction of the S/370 (five decades ago). Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: *-*
Page 5, middle of left column On 2020-05-01 10:59 a.m., Martin Ward wrote: On 01/05/2020 05:07, Seymour J Metz wrote: The usage precedes the S/360 by years; it dates to the 709 if not before. See, e.g., the FAP manual on bitsavers. Page number? Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: *-*
The expression *-* in FAP (Fortran assembler) has an identical meaning
to 360/370 assembler; however the usage in FAP does not appear to extend
to denoting a length value in an instruction.
The explanation by the professor appears to me to provide a helpful way
to assist students in learning the rule for the length field in
MVC/CLC/XC (and by extension the value to use when EXecuting those
instructions).
The use of *-* is a convention in S360/S370 assembler in some
programming styles. The FAP manual only shows using ** (which also
generates 0) in code samples, so I have no idea if usage of *-* was ever
a convention in FAP.
The programmer at our place who used this convention once said that he
learned much of his assembler programming style from JES2 source. Does
anyone know if JES2 used the *-* convention? He had also worked on the
WATFOR compiler immediately after graduating.
On 2020-05-01 12:07 a.m., Seymour J Metz wrote:
Actually, you don't remember the origin, you remember an uninformed instructor
feeding you an invented etymology. The usage precedes the S/360 by years; it
dates to the 709 if not before. See, e.g., the FAP manual on bitsavers.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any
attachments is confidential and may be subject to copyright or other
intellectual property protection. If you are not the intended recipient, you
are not authorized to use or disclose this information, and we request that you
notify us by reply mail or telephone and delete the original message from your
mail system.
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of jba...@ngssallc.com [jba...@ngssallc.com]
Sent: Thursday, April 30, 2020 10:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
I must really be getting old, because I actually remember the origin of the
convention.
The convention of "*-*" in a length field was based upon an interpretation
of the expression "{address-of-last-byte}-{address-of-first-byte}" which
calculates the "machine length" of the field, which is one less than the
actual length of the field.
When moving a variable length field, the instruction had to be "EX(ecuted)",
so the programmer likely did not know the value of "{address-of-last-byte}"
at assembly time and in many cases did not know the value of
"{address-of-first-byte}" at assembly time, so the programmer simply
replaced each unknown with "*" and voila, we had "*-*".
We discussed this in assembler programming class some 47 years ago.
John P. Baker
Software Developer
-Original Message-
From: IBM Mainframe Assembler List On
Behalf Of robi...@dodo.com.au
Sent: Thursday, April 30, 2020 4:46 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: *-*
On 2020-04-30 18:15, Martin Ward wrote:
On 30/04/2020 03:48, robi...@dodo.com.au wrote:
What's wrong with a comment?
It *is* a comment (in the broader sense).
No it isn't. *-* doesn't explain anything.
If it did, people wouldn't be asking what on earth is it.
A comment that explains that the length is planted by some other instruction
or whatever else is it, is the only way to document it.
Re: *-*
It's in our code, mostly introduced, I believe, by a life-long assembler coder who meant it to signal that this value is zero at assembly but will be filled at execution time by, for example, the address of a module after a LOAD macro. He also used it for the length value in an EXecute instruction. I think in both cases he was trying to signal future programmers reading the code that they shouldn't assume that if the value is zero at assembly, it will be zero at execution time. He hoped that using *-* would make the experienced programmers think and the inexperienced ones ask about it. We did. On 2020-04-29 5:00 p.m., Mark Boonie wrote: I've probably been writing assembler for too long to be asking this question now, but what is the purpose of coding '*-*' in some assembler expressions? I've seen it in parameter lists (usually as an adcon), operands of executed instruction (e.g., MVC 0(*-*,5),0(6)), etc. As far as I can tell it effectively operates the same as '0', so it must mean something to the coder and/or the reader (but not to this reader). Any insights? - mb Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: BASR to AMODE 64
Yes, hardware translation uses the translation tables maintained by the software. If the translation tables indicate a specific virtual page does not have a corresponding real memory frame, it returns a program check; it is up to the software how to respond to the program check: assign a frame, page-in the page from auxiliary memory, return an error to the program, etc. There's more to it than that, of course. But the developers of z/OS decided that 31-bit programs should be minimally impacted by 64-bit addressability. On 2019-11-22 5:23 p.m., Paul Gilmartin wrote: > On 2019-11-22, at 08:14:13, Dougie Lawson wrote: >> ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as >> the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we >> were in 24-bit or 31-bit. >> >> So the 64-bit guys decided that the easiest fix was to completely disallow >> any address from 800 through to 8FFF, which is an extremely good >> idea to avoid breaking 31-bit code. >> > Do I understand correctly that enforcement is entirely by > software; those addresses are quite acceptable to the hardware? > >> They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and >> we've seen a few of those with Db2). > -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Global character not keeping value
Depends on the company I suppose. I worked at a manufacturing company and we were considered begrudgingly-tolerated overhead to the real business of making stuff out of metal and plastic. Operations decided if they had enough time to run programmer jobs (put cards in reader) during the day. In 1979, my manager didn't think there was an economic advantage to providing programmers with terminals, although they were used for clerical staff for order entry, processing, shipping and invoicing, I believe. I recall we shared one terminal among about 10 programmers so we could review source code, JCL, copy books, etc,. using a homegrown TCAM application under VS1. On 2019-11-18 1:34 p.m., Seymour J Metz wrote: > Once a day? Even in the 1960s I got better than that. > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Global character not keeping value
My technique for debugging this kind of problem is to start with the just the epilogue and prologue, then add half the code back in, then half the remaining code, etc., until i get the error again (ignoring all the other errors), then stripping out code until I get rid of the error. Ever since I got away from once a day turnaround on batch assemblies in the early 80's this has proved pretty efficient. On 2019-11-18 10:35 a.m., Tom Marchant wrote: > On Mon, 18 Nov 2019 08:17:37 -0500, Peter Relson wrote: > >> Due diligence before posting such questions includes trying to eliminate >> the possibility that you made some simple mistake. > Such as assembling the prolog and epilog macros with no intervening code. > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Questionable Instructions in Obtaining EAX documentation
I had a reason a couple weeks ago. We were trying to programmatically verify whether we were running certain code on a zIIP or a CP. I found a bit in the PSA that it appeared was set if you're on a zIIP and not if not. It was not set for my PSA, (not surprising since I was on TSO ISPF running TASID). But wanted to look at the zIIP's PSA to verify it. But I couldn't find an easy way to locate it Instead, the person developing a JNI routine and testing it for lazy switching effects just added it to their code and it seems to be a valid indicator. At IPL absolute 0 is the only PSA because I believe software has to implement prefixing as it implements multi-tasking. I assume absolute zero is only absolute from the lpar's (or virtual machine's) point of view. On 2019-11-12 10:00 a.m., Tom Marchant wrote: > On Tue, 12 Nov 2019 08:49:36 -0600, John McKown wrote: > >> 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. > I have no need to do so, and don't know why I might. But the post from Peter > > that you replied to was about doing that > >> I thought absolute 0 >> was used as the PSA for the IPL processor, but that, again, was an >> assumption. > That may be. I don't know. The POO would probably say. > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Poll
Did you pronounce it "Pov Op"? On 2019-09-17 2:40 p.m., Phil Smith III wrote: > And as some of you will have guessed: I grew up calling it PofOp, which seems > to put me in the vanishing minority! > > > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: Phil Smith III [mailto:li...@akphs.com] > Sent: Monday, September 16, 2019 3:50 PM > To: 'IBM Mainframe Assembler List' > Subject: Poll > > > > Principles of Operation-how do you refer to it? (NOT including case-let's not > make this any more complicated than it is already!) > > 1) PofOp > > 2) POP > > 3) POO > > 4) Pops > > 5) other? > > > > Just curious-there are no wrong answers, of course! (Well, I suppose "IntelR > 64 and IA-32 Architectures Software Developer Manuals" is wrong.) > > > > .phsiii > >
Re: Poll
POO and PoOp On 2019-09-16 3:50 p.m., Phil Smith III wrote: > Principles of Operation-how do you refer to it? (NOT including case-let's not > make this any more complicated than it is already!) > > 1) PofOp > > 2) POP > > 3) POO > > 4) Pops > > 5) other? > > > > Just curious-there are no wrong answers, of course! (Well, I suppose "IntelR > 64 and IA-32 Architectures Software Developer Manuals" is wrong.) > > > > .phsiii > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: z15 is announced...
We always abbreviated it POO or PoOp (or should I say acronymized it)? On 2019-09-16 11:16 a.m., Steve Smith wrote: > Re LLIxx: thanks! > > Re PoPs: I didn't really mean to sound pedantic, it's just a curiosity of > mine. In the official title, "Operation" is not plural (nor has it ever > been as far as I can tell). Nevertheless, if everyone wants to call it > PoPs, the fact that it isn't strictly logical doesn't matter much. English > is like that. > > sas > > > On Mon, Sep 16, 2019 at 4:16 AM Jonathan Scott > wrote: > >> Ref: Your note of Fri, 13 Sep 2019 14:05:32 -0400 >> Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. >> Steve Smith wrote: >>> Sheesh. The z/OS 2.4 page still links to the -11 version of PoOp (I >> don't >>> understand what "PoPs" is supposed be abbreviating). >> I thought "POps" = "P of Ops" = "Principles of Operations" but >> the case does seem to be very variable (even in my own notes). >> >> I've passed on the comment about the LLIxx instructions to the >> editor. >> >> HLASM support for the z15 instructions is in the following PTFs >> for APAR PH00902 which were sent to distribution on announcement >> day, September 12th: >> >> z/VM: UI65289 >> z/OS: UI65290 >> z/VSE: UI65291 >> >> Jonathan Scott, HLASM >> IBM Hursley, UK >> >
Re: Circular Queue Handling in Assembler
One use for a circular queue is a wrapping trace table. Normally it's a queue that's never harvested until there's an abend, On 2019-08-01 11:56 p.m., Jon wrote: >> Well, the performance isn't good but this looks like a use case for PLO. > How is PLO a use case for a multi-tasking circular queue? Or maybe it's > actually a free storage pool. Either way, how do you force the random > activity into sequential activity? How do you eliminate timing issues, deadly > embraces and spin lock hangs? > > Let's make this simple by ignoring the circular wrapping and all the other > stuff mentioned. Pauls request boils down to: > startindx dc h'0' > endindx dc h'0' > queue dc 200CL256' ' > > If this is a queue as mentioned, how does the receiving task wait for > index=10 because it's taking longer than index=11? Remember that queueing > requires prep work for the queue data. > > If it's a free storage pool, do you have 30 tasks in a spin loop waiting to > terminate because the first task is still running? Or do you have ECB's? Or > maybe you have a table of the entries that have been freed creating more > timing issues. > > The only time a circular queue works is when you have 1 sender and 1 > receiver. In this case, CS and PLO are not needed. The sender modifies one > index and receiver modifies the other index. No timing issue. > > Unless I left out a scenario, using a circular queue will be far more > complicated than a chained queue. > > Jon. Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Circular Queue Handling in Assembler
Like Transactional execution (TBEGIN/TEND/...) with z12, which I think of as PLO unwrapped. On 2019-07-30 1:32 p.m., Charles Mills wrote: > FSVO "new" CharlesSent from a mobile; please excuse the brevity. > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. Original message From: Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Date: 7/30/19 12:39 PM (GMT-05:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Circular Queue Handling in Assembler On 2019-07-30, at 10:19:34, Gary Weinhold wrote:> > After loading the new index value, check if it's 256. If so, do a> compare and swap for 255 to 0; if another process beat you to it, CS> fails and you have to reload the index value you now want (like 0 to 1),> just like you would if compare and swap fails. The check for new index> = 255 has to be done in every loop.> > Or, it more be more efficient to do as was suggested in another answer:> after loading the new index value, aNd the register with '00FF'.> > This may not be sufficient to protect the data being maintained in the> circular queue. If my instance acquires index 42, for example, with the> above CS logic, there may be nothing to ensure that my instance actually> get the CPU cycles to move data to the associated 64-bit address before> the index is cycled by higher priority processes and some other instance> acquires index 42.> +1... if the producer does the CS first, there's no hazard two instances'acquiring "42"; rather the hazard is that a consumer will fetch the databefore the producer finishes moving it in.Surely, the problem of managing a FIFO queue, whether with a circularbuffer or otherwise, has been posed and solved numerous times. Theremust be a published solution available.Are there new z Series instructions to facilitate this? Perhaps PLO?-- gil
Re: Circular Queue Handling in Assembler
After loading the new index value, check if it's 256. If so, do a compare and swap for 255 to 0; if another process beat you to it, CS fails and you have to reload the index value you now want (like 0 to 1), just like you would if compare and swap fails. The check for new index = 255 has to be done in every loop. Or, it more be more efficient to do as was suggested in another answer: after loading the new index value, aNd the register with '00FF'. This may not be sufficient to protect the data being maintained in the circular queue. If my instance acquires index 42, for example, with the above CS logic, there may be nothing to ensure that my instance actually get the CPU cycles to move data to the associated 64-bit address before the index is cycled by higher priority processes and some other instance acquires index 42. Gary On 2019-07-29 2:32 p.m., Charles Mills wrote: > I don't think there is an easy answer to before or after. It depends on the > particular logic. I have been writing assembler code for (literally!) fifty > years and I have to pause and think and think and think every time about > code like this. > > You need to take a pencil and put a little line between every two > instructions and say "if I get interrupted here, and all this other code > runs while one thread is between these two instructions, what happens?" And > do that for every two instructions. Further, if you could get interrupted by > another processor (which is almost certainly the case) you have to do the > same thing for every *individual* instruction that is *not* atomic (LM/STM, > MVC, etc.). > > Charles > > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of esst...@juno.com > Sent: Monday, July 29, 2019 10:45 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Circular Queue Handling in Assembler > > Hi, > . > I have a program which obtains a Memory Chunk, which is carved into a queue > of 256 > byte fixed length entries. I could have used a Data space. > . > In 31 Bit storage is the control information for the 64Bit Memory Chunk > queue. > The 31 Bit storage control structure has the beginning address of the Memory > Chunk, the Ending Address Of the Memory Chunk, the number of fixed length > entries > an Ordinal Number (INDEX) and some state data. > . > The ordinal Number is used to index into the Memory Chunk of fixed length > entries > (queue) and is incremented using Compare and Swap (CS). > The program never searches the queue to find an available slot - it always > appends to the next entry by incrementing the ordinal number using compare > and swap.. > . > The memory chunk is used as a circular queue, meaning, when we reach the end > of > the queue (memory chunk), we resume by re-using the first entry at the top > of the queue > (wrap around). > We all-ways add new/next entries by incrementing the ordinal number and > indexing > into our Memory Chunk. > . > Here's My concern - > When we reach the end of the queue - the program needs to reset ther Ordinal > Index back to 0. > (so we can continue to add the next entry at the beginning of the queue).. > Is it better to test/reset this Index number before or after adding the last > entry in the queue ?Should there be a second Compare and Swap ? > . > . > Paul > * > .
Re: Sysadata symbol and literal cross reference record type x’44’ re-post from IBMMAIN
Unless you can ensure all executions will also be under those conditions, you will also need to exercise all possible code paths in the program with every possible variation of input(s). On 2019-05-15 5:57 p.m., Paul Gilmartin wrote: More practical, mark your module REFR and run with REFRPROT in effect. -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Sysadata to linear
OP wanted to get adata into a dataspace and thought he had to load it to a linear data set first. He was responded to on IBM-Main. On 2019-04-02 12:41 p.m., Martin Truebner wrote: What was the original question? I used it as base for a debugger (as opposed to native machine code) to reconstruct source (and associated dsects/csects/info) and link it to HLASM stmts... works like a charm Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Determing the Presence of an Instruction
This is probably part of Start Interpretive Execution (assuming that's still used). VM used to be based on running users in problem state so every privop is intercepted , but SIE allows more selective trapping of which ops are intercepted especially for operating systems like z/OS. I think VM was trapping STCK during the Y2K testing era as an example of non-privileged ops. On 2019-03-28 4:42 p.m., Charles Mills wrote: Is this one of those situations that is controlled by a control register bit? VM does not interpret every instruction like Hercules. It must be getting an interrupt on STFLE or whatever. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Thursday, March 28, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Determing the Presence of an Instruction On Thu, 28 Mar 2019 09:56:23 -0700, Charles Mills wrote: VM does a fair amount of "interception" and instruction simulation in any event. For privileged instructions, yes. In this case, something has to happen for non-privileged instructions too.
Re: Determing the Presence of an Instruction
And wouldn't a "dial-up" facility be nice, too? We would never have had to leave our MP3000! Gary On 2019-03-27 3:24 p.m., Charles Mills wrote: since they probably don't have the hardware farm And if they do, then they can test on back-level hardware natively. What would really be nice, what would solve the "problem" for ISVs, is not necessarily full LGR capability, but simply a "dial down" capability in VM: "I know this is really a z14, but make it appear to this particular guest as a z12" -- which if I am understanding correctly is more or less a subset of LGR. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone +1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold Sent: Wednesday, March 27, 2019 11:50 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Determing the Presence of an Instruction So it appears the LGR facility to limit the instruction set is not practical for those ISVs who wish to test thei software on prior generations of z hardware, since they probably don't have the hardware farm (unless LGR works on a couple of zPDTs hooked together).
