Re: Printed object code and macro calls
I do the opposite, but you can modify it to work: PUSH PRINT,NOPRINT Suppress printing of macro PRINT NOMCALL,NOPRINT... call Some-macro POP PRINT,NOPRINT So change NOMCALL to GEN Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of David Eisenberg Sent: Thursday, September 19, 2024 13:24 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Printed object code and macro calls If anyone can advise me, I would be grateful! I observe that in the HLASM listing, when PRINT NOGEN is in effect, and when a macro call is printed, the location counter and object code of the macro’s first generated machine instruction is printed alongside the macro call. That is very helpful. My question: I’ve written a macro in which the first generated instruction is an MNOTE comment, followed by several generated machine instructions. What I see is that with PRINT NOGEN in effect, I do not see the location counter and object code of the first generated machine instruction. I’m sure that this behavior is expected and is simply how the assembler works. What I’m wondering is if there are any print control statements (or other innocuous statements) that I can insert into the macro to force the first machine instruction’s location counter value and object code to print next to the macro call even when PRINT NOGEN is in effect. I don’t want to move the MNOTE instruction further down within the macro; i.e., when PRINT GEN is in effect, I want the MNOTE to appear before the generated machine instructions. This is not a major issue at all… but if I could change the macro to make this happen, then I would! Thank you, David
Re: Moving beyond S/370
CLIJx I coded a macro that emulated this with CHI/Jx, back in the days where customers may have had machines that didn't support these instructions. Failed assembly on a real CLIJx if immediate was not in 0:255 range, or -128:127 for CIJx, That horrendous CHI instruction I posted previously does assembly time bounds checking that I had to add to fix this. EXRL Before the existence of TRAP type instructions, we used EX n,* to generate S0C3 abends with n in the 0:15 range to distinguish the various S0C3 generated within a specific module. EXRL n,* where n is non-zero may alter the EXRL instruction to something other than EXRL, which may not abend and then fall thru to the next instruction. LARL Same deal with CLIJx, coded a macro to generate BASR reg,0 followed by AHI (or 2 AHI's) to emulate LARL for up to 32K (or 64K with 2 AHI's). Real LARL failed assembly if offset was not even, but emulated version happily generated odd offsets. Had to add code to make BASR second operand the expression 0-(offset // 2)**2 which resolves to zero if offset is even (good), and -1 if it is odd (bad, fails assembly). TMLL There is a subtle difference between the condition codes set by TMxx vs. TM, I always need to check the POPS whenever I use TMxx for testing conditions other than Z or O. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Thursday, July 11, 2024 13:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Moving beyond S/370 I'm dealingusing these won't creat a maintena with some code that currently uses nothing newer than BAS/BASR. I've made some changes using a few newer instructions, plus the SP macros from the toolkit. Any advice on convincing reviewers that there's nothing exotic in these: CLIJx ELSE ENDIF EXRL IF J JAS LARL LAY NILL TMLL -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Getting to CVT with FLAG(PAGE0)
Oops, appended (,0) to wrong CVT symbol! Robert Ngan DXC luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, July 9, 2024 18:05 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Getting to CVT with FLAG(PAGE0) Try: L R9,CVTPTR GET POINTER TO CVT(,0) Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Tuesday, July 9, 2024 17:34 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Getting to CVT with FLAG(PAGE0) [Some people who received this message don't often get email from michael.schm...@dxc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] I'm testing to see if FLAG(PAGE0) gives too many false hits. One problem is with code that is locating the CVT, which is a pointed to by an absolute address. Using CVT DSECT=YES: L R9,CVTPTR GET POINTER TO CVT results in: ** ASMA309W Operand CVTPTR resolved to a displacement with no base register Does this mean: A. Yeah, it is going to give that warning. You have to consider each case to determine if the warning is valid or not. B. I'm coding it wrong. C. I'm coding it right but there's a better way to code it that won't trigger the error. I like my compiles and assembles to be clean: no warnings. So I'm not a fan of option A. I suppose I could put in a compile option to set FLAG(NOPAGE0) in programs that are getting to the CVT. Statistics: of around 80 assembler programs: 2 hit the CVT case 1 set a 1 byte switch to an equate with MVC (should have been MVI) 1 used L R15,8 to set a return code to 8. ___ Michael Schmitt | DXC Apps Development | MassMutual (737) 910-8248 | michael.schm...@dxc.com
Re: Getting to CVT with FLAG(PAGE0)
Try: L R9,CVTPTR GET POINTER TO CVT(,0) Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Tuesday, July 9, 2024 17:34 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Getting to CVT with FLAG(PAGE0) [Some people who received this message don't often get email from michael.schm...@dxc.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] I'm testing to see if FLAG(PAGE0) gives too many false hits. One problem is with code that is locating the CVT, which is a pointed to by an absolute address. Using CVT DSECT=YES: L R9,CVTPTR GET POINTER TO CVT results in: ** ASMA309W Operand CVTPTR resolved to a displacement with no base register Does this mean: A. Yeah, it is going to give that warning. You have to consider each case to determine if the warning is valid or not. B. I'm coding it wrong. C. I'm coding it right but there's a better way to code it that won't trigger the error. I like my compiles and assembles to be clean: no warnings. So I'm not a fan of option A. I suppose I could put in a compile option to set FLAG(NOPAGE0) in programs that are getting to the CVT. Statistics: of around 80 assembler programs: 2 hit the CVT case 1 set a 1 byte switch to an equate with MVC (should have been MVI) 1 used L R15,8 to set a return code to 8. ___ Michael Schmitt | DXC Apps Development | MassMutual (737) 910-8248 | michael.schm...@dxc.com
Re: using 2 consecutives areas
Yes, that makes more sense. I had based my code on loads of 128-bit floating point values e.g. LD1,=LD'2.71828182845904523536028747135266e2497'+0 LD3,=LD'2.71828182845904523536028747135266e2497'+8 With LA, it's simpler. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Tony Thigpen Sent: Tuesday, July 9, 2024 10:16 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: using 2 consecutives areas If going down this path, it would be better: LA1, =AL2(4,C'te',C'xt') LA2,2(,1) Tony Thigpen Ngan, Robert (DXC Luxoft) wrote on 7/9/24 10:58 AM: > Oops, accidently replied directly to João. > > Not sure why you need it for LA, but when I need this, I use: > > MVC target(6),=AL2(4,C'te',C'xt') > > You could use: > > LA1, =AL2(4,C'te',C'xt') > LA2, =AL2(4,C'te',C'xt')+2 > > But that's ugly. Use of consecutive named fields as others suggested would be > the simplest approach. > > Robert Ngan > DXC Luxoft > > P.S. João, In my original reply there was a typo, I used +1 instead of +2 on > the second LA. > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of João Reginato > Sent: Monday, July 8, 2024 08:48 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: using 2 consecutives areas > Importance: Low > > Hi > > > > What can I do to guarantee that the 2 literals below are consecutives in the > literal pool? > > > > La 1,=al2(4) > > La 2,=cl4'text' > > > > > > TIA > > João
Re: using 2 consecutives areas
Oops, accidently replied directly to João. Not sure why you need it for LA, but when I need this, I use: MVC target(6),=AL2(4,C'te',C'xt') You could use: LA1, =AL2(4,C'te',C'xt') LA2, =AL2(4,C'te',C'xt')+2 But that's ugly. Use of consecutive named fields as others suggested would be the simplest approach. Robert Ngan DXC Luxoft P.S. João, In my original reply there was a typo, I used +1 instead of +2 on the second LA. -Original Message- From: IBM Mainframe Assembler List On Behalf Of João Reginato Sent: Monday, July 8, 2024 08:48 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: using 2 consecutives areas Importance: Low Hi What can I do to guarantee that the 2 literals below are consecutives in the literal pool? La 1,=al2(4) La 2,=cl4'text' TIA João
Testing a vector register for low-values
FYI: A while back, I needed to test if a vector register contained all zeroes, but could not figure out how without loading another register via VZERO and then using VCEQGS but I didn't like that since it is really comparing two 64-bit elements. Finally, I found I could use VTM against another register loaded via VONE, and test for CC=0. Today I realized I can just issue a VTM with the same register as source and mask, and check for CC=0. No extra register required. Testing vector registers is hard, since most vector instructions do not set condition codes (including the [non decimal] arithmetic and bitwise operations). Robert Ngan DXC Luxoft
Re: Instructions by Machine
I've commented before that OPCODE table contain all the assembler mnemonics available when that OPCODE table was introduced to HLASM, it is not the list of instructions available at that Z?? machine. So IILF instruction was introduced with z9 hardware But the LFI extended mnemonic was added to HLASM OPCODE table Z16. You can't use LFI with OPTABLE Z9 thru Z15. When the LOC/STOC type extended mnemonics were added, not all condition were included, so some LOC/STOC condition codes won't assemble unless you use the Z13 OPTABLE which is when the missing condition codes were added. OPTABLE is useless to me due to this hardware opcode vs. HLASM mnemonic discrepancy in the implementation of the table. Maybe what we need is a new HARDWARE table type that groups by instruction availability instead on mnemonic introduction (I was going to suggest MACHINE but that already used as a synonym for OPTABLE). Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Emir Garza Sent: Wednesday, May 15, 2024 10:34 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instructions by Machine [Some people who received this message don't often get email from ega...@uk.ibm.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Mark, You may find that the LFI instruction is present on the machine. (I found it was present on our old EC12.) LFI is an extended opcode for IILF. If you use IILF, it will probably work. Regards, Emir Garza
Re: IEABRC anomaly
I remember (a long time ago) we had "first time" code preceded by a NOP, which altered the NOP condition code to branch around the "first time" code on subsequent invocations. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Abe Kornelis Sent: Thursday, May 2, 2024 14:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly [Some people who received this message don't often get email from a...@bixoft.nl. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Shmuel, all, it's been a long time since I last saw code like that. Worst example was code that XOR-ed the opcode of an AH instruction to switch back and forth between AH and SH to print a report in two columns. If I still had code like that in my code base, I'd prioritize to make that code RENT. (if I had enough breathing room to make that decision) Kind regards, Abe === Op 02/05/2024 om 19:16 schreef Seymour J Metz: > Except that IEABRC is only necessary for old code. I've inherited code that > uses NOP as a switch, overlaying the mask with F. > > -- > Shmuel (Seymour J.) Metz > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason > .gmu.edu%2F~smetz3&data=05%7C02%7Crobert.ngan%40dxc.com%7Cc9f10e081dd6 > 47cf875a08dc6ae2549e%7C93f33571550f43cfb09fcd331338d086%7C0%7C0%7C6385 > 02767524497151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l > uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1205muWAwyyeshC > OveMPL6ffrbRvqWVIgVKRulIjy%2BA%3D&reserved=0 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Assembler List > on behalf of Peter Relson > Sent: Thursday, May 2, 2024 8:37 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: IEABRC anomaly > > I don't recall having thought about this when providing IEABRC. But the > conclusion that it's not going to get added is likely a correct one. > > Without a complex macro (which definitely is not going to happen), changing > NOP to JNOP for the cases Jonathan Scott mentioned will reject operands that > are fully valid (avoiding RC=4 if you suppress ASMA212W Branch address > alignment for unfavorable). I believe his case is a very common one of > using the operand of NOP for diagnostic purposes. > > While NOP perhaps isn't a branch (because it never goes anywhere), it is the > conditional branch opcode so could have been a candidate for conversion. But > functionally it is not necessary. Anyone who truly wants conversion of the > operand for some reason could avoid using NOP and code a conditional branch > with mask 0. That will get converted. > > Peter Relson > z/OS Core Technology Design
Re: Complex immediate fields
Assuming you have an assembly listing, you just need to look at the "R-Loc" (i.e. offset) value. We use two LOCTR's for data, one for data that needs to be within 4K of the base register, and another for data referenced with relative long, or long displacement instructions. That single base register will handle both LOCTR's. Robert Ngan DXC/Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, April 15, 2024 22:07 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields On 4/15/24 20:31:33, Seymour J Metz wrote: > Expect a performance hit if you modify instructions. I like to use LOCTR to > keep data physically remote but visually near the instructions that use them. > . LOCTR is a boon for reading source. Perhaps less so for reading dumps. Are any symbolic debuggers LOCTR-savvy, perhaps assisted by ADATA? -- gil
Re: Complex immediate fields
When I first saw "Complex immediate fields", I thought of this code one of our emulation macros used to generate: CGIJL R01,132-(L'BKwa_Module+1+L'BK_LPAOS+1),BK250 + CGHI R01,(1-132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'X + BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(L'BKX + wa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LX + PAOS+1))/256)*256)+256)/256)*256)/128))*(((132-(L'BKwa_MX + odule+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPAOSX + +1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOS+1X + ))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256)/X + 256)*256)+132-(L'BKwa_Module+1+L'BK_LPAOS+1))-((132-X + (L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+256-132-(LX + 'BKwa_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BX + K_LPAOS+1))/256)*256)+256)/256)*256)/128)*132-(L'BKwX + a_Module+1+L'BK_LPAOS+1))-((132-(L'BKwa_Module+1+L'BK_LPX + AOS+1))/256)*256)+256-132-(L'BKwa_Module+1+L'BK_LPAOX + S+1))-((132-(L'BKwa_Module+1+L'BK_LPAOS+1))/256)*256)+25X + 6)/256)*256)-256)+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))+X + 2147483520)*0+((132-(L'BKwa_Module+1+L'BK_LPAOS+1))-2147X + 483520)*0Emulated z10 CGIJL instruction + JLBK250 ... Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 11:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: Complex immediate fields
That fails with an arithmetic overflow if the byte value has the high order bit set. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Friday, March 29, 2024 14:27 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Complex immediate fields What about (untested) ShiftLeft24 EQU x'100' LFI R15,X'40'*ShiftLeft24 Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Friday, March 29, 2024 9:57 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Complex immediate fields Back in he Assembler XF era I would code something like LAR0,L'DEST LAR1,DEST XRR15,R15 ICM R15,8,=C' ' MVCL R0,R14 On current hardware there is an IILF (LFI) instruction, and I would like to use it instead of the XR/ICM sequence. I consider LFI R15,X'4000' to be ugly, and would like to be able to either use an immediate field combing CL1 and XL3 pieces or to refer to an EQU defining that combination. Is there any way to do that in HLASM? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: OPCODE tables
For comparing instructions available by hardware generation, that doesn't work. OPTABLE(Zn) does not give you the instructions available for the Zn hardware. It gives you the assembler mnemonics available in HLASM when support for the Zn series hardware was added to HLASM. So LFI is an extended mnemonic for IILF, and IILF was introduced with the z9. But LFI was added when HLASM was updated to support z16 instructions so LFI will not assemble with OPTABLE values of Z9 thru Z15. The LOC/STOC instructions (z11) have a similar issue, since the OVERFLOW condition code value were missed on the initial HLASM implementation, and were subsequently added with z13 support (i.e. LOCE works with OPTABLE(Z11) or higher, but LOCO required OPTABLE(Z13), and these are basically the same instruction!). So if you want to restrict what instructions are available when your target is a specific hardware series (which is what I was trying to do), using OPTABLE for this does not work. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Farley, Peter Sent: Wednesday, March 20, 2024 16:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: OPCODE tables PoOPS in the "Summary of Changes" sections usually have at least some listing (in text format, nothing tablularized or easy to pick out) of instructions added in each manual section, but sometimes those are "generic" and don't include all the variations of added instructions. The only way I can think of to accurately (more or less) track the additions would be to extract the Appendix B instruction table that is in OPCODE order to a text format file and then compare each edition's table to the prior edition's table. I can say from personal experience that the "pdftotext" command-line utility available from the XPDF project ( https://www.xpdfreader.com/ ) (which is NOT the "pdftotext" version normally included in many linux systems) for Windows execution works pretty well on most editions of PoOPS once you use the right command-line parameters. Once extracted to pure text the tables are at least in a manipulable form that a subsequent text tool can massage into a format you can use for comparisons and extraction of "differences". But truthfully the OPTABLE lists are probably the easier solution. Just run a separate assembly with each OPTABLE value and massage the output to make the columns of instructions into one-line-per-instruction format and you will be able to compare each generation to the next. SMOP, and (g)awk or python would be a reasonable tool to do the text manipulation needed. Peter From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Wednesday, March 20, 2024 5:12 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: OPCODE tables 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). -- 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: Macro variable attributes
We're only at 2022-04, I'll have to get our level of HLASM updated. Thanks, Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Tuesday, December 19, 2023 12:42 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Macro variable attributes Robert Ngan writes: > The ability to do the SETA inside the macro really simplifies our > code, but it's implementation seem to be somewhat flaky. Sometimes it > work, other times it get errors. It doesn't fail with the latest level, and I suspect this might be a symptom of the problem fixed by PH50923 in November 2022, for which the PTF on z/OS is UI83375. The problem was that if a macro parameter variable had been referenced before being used in a SETA, it may have already been parsed and marked as "not numeric" which unfortunately caused the new SETA support code to be bypassed, going straight to the existing error case. Jonathan Scott, HLASM IBM Hursley, UK
Re: Macro variable attributes
Prior to this APAR, I was forced to do the SETA against the equate before the macro call and then pass the resolved value into the macro i.e. &L SETA equ_name MacroName LEN=&L The ability to do the SETA inside the macro really simplifies our code, but it's implementation seem to be somewhat flaky. Sometimes it work, other times it get errors. TestSETA TITLE 'Test LEN macro' MACRO BLAH &FLD AGO .AAm040 AIF (D'&FLD).AAm030 MNOTE 4,'&FLD is not defined' AGO .AAm040 .AAm030 ANOP , MNOTE 0,'&FLD is defined' .AAm040 ANOP , &L SETA &FLD MNOTE 0,'Length of &FLD is &L' MEND , IHASAVER , TestSETA RSECT BLAH SAVF4SA_Len BLAH Saver_Len END This code above assembles correctly, but if you comment out the AGO on line 4, it fails assembly??? Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Friday, November 17, 2023 16:22 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Macro variable attributes > Is there a way to know the real value of the LEN below when I use a > variable instead of a value? > > MACRO > &LABEL WORK &LEN=0 > &LABEL DS XL(&LEN) > MNOTE *,.LEN=&LEN. > MEND If you have a recent maintenance level of HLASM, including APAR PH34116 from February 2021, you can use SETA to obtain the value of an equated symbol which has been defined and resolved. (Some parameter cases did not work and required a further fix for APAR PH50923). So in this case, if you know that &LEN contains a single symbol which has been defined and resolved before the macro is invoked, you can simply use something like: &N SETA &LEN If it contains a more complex expression, you can use EQU to create a dummy variable equal to the expression and then use that in a SETA expression, provided it has been resolved. It is possible to test whether a symbol is defined using the defined attribute D'&LEN but unfortunately it is not currently possible to test whether it has been resolved (which may not be the case if the EQU expression contains forward references), so I do not think it is possible to write code which will assemble without error but which will only conditionally extract the value if it has already been resolved. Jonathan Scott, HLASM IBM Hursley, UK
Re: CLI vs. TRT
For values of "several" up to 16, you might want to look at VFAE. I haven't had a chance to use it yet, but it's on my list of vector instructions potentially useful for general coding. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Thursday, July 7, 2022 09:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: CLI vs. TRT Given several target characters, at what value of "several" is the break-even between TRT and a chain of CLI; BC? (It's probably model-dependent.) The CLI chain might be optimized by CLI first for the median value and using the outcome to bypass half the remaining tests. -- gil
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: 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: 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?
Re: Quadword constant
However, AD(2+2) works fine As long as the expression does not exceed a 32-bit signed value. Yes, it would be very useful if HLASM could resolve 64-bit arithmetic expressions, and it's a PITA that it doesn't. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Thursday, May 19, 2022 14:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Quadword constant On May 19, 2022, at 12:16:45, Ngan, Robert (DXC Luxoft) wrote: > > FD is a fixed point doubleword. > Alas, there's no way to define a doubleword constant containing the value of an arithmetic expression AL8(2+2)? Having only a 32-bit assembler for a 64-bit architecture is increasingly becoming anachronistic. > -Original Message- > From: Schmitt, Michael > Sent: Thursday, May 19, 2022 13:09 > > Today I learned that there isn't a fixed point DOUBLEWORD constant either. > > I never noticed that DC D isn't fixed point, it is floating point. > > > -Original Message- > From: Schmitt, Michael > Sent: Monday, April 18, 2022 10:03 AM > > HLASM has fixed decimal constants for Halfwords, Fullwords, Doublewords, with > appropriate alignment. Why is there none for Quadwords? > > The closest I see is LQ, but that appears to be intended for floating point. -- gil
Re: Quadword constant
FD is a fixed point doubleword. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Thursday, May 19, 2022 13:09 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Quadword constant Today I learned that there isn't a fixed point DOUBLEWORD constant either. I never noticed that DC D isn't fixed point, it is floating point. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Schmitt, Michael Sent: Monday, April 18, 2022 10:03 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Quadword constant HLASM has fixed decimal constants for Halfwords, Fullwords, Doublewords, with appropriate alignment. Why is there none for Quadwords? The closest I see is LQ, but that appears to be intended for floating point.
Re: z16 Principles of Operation POP manual SA22-7832-13.pdf (13.93MB)
Strangely, the revision bars do not encompass the entire table. However, this is advantageous to me since only the new extended mnemonics are tagged and those are what I am primarily interested in. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Monday, May 9, 2022 14:06 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z16 Principles of Operation POP manual SA22-7832-13.pdf (13.93MB) An interesting addition to the latest PoO is "Appendix J. List of Extended Mnemonics". This appears to provide a complete list of all the extended mnemonics that have been splattered across multiple chapters in previous editions.
Re: Signed/unsigned operations
STRL/STGRLl?
Is the GCC compiler generating non-reentrant code?
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Ian Worthington
Sent: Thursday, April 14, 2022 08:05
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Signed/unsigned operations
I noticed today that GCC generates for:
static __uint32_t sumu32; // unsigned int static __uint64_t sumu64; //
unsigned long
void addStuff(__uint64_t a64, __uint64_t b64, __uint32_t a32, __uint32_t b32 ) {
sumu32 = a32 + b32;
sumu64 = a64 + b64;
}
the following:
117: sumu32 = a32 + b32;
77 .loc 1 117 0
78 0044 5810B1C4 l%r1,452(%r11)# sumu32.6, a32
79 0048 5A10B1C0 a%r1,448(%r11)# sumu32.6, b32
80 004c C41F strl%r1,sumu32# sumu32.6, sumu32
80
118: sumu64 = a64 + b64;
81 .loc 1 118 0
82 0052 E310B1D0 lg%r1,464(%r11)# sumu64.7, a64
82 0004
83 0058 E310B1C8 ag%r1,456(%r11)# sumu64.7, b64
83 0008
84 005e C41B stgrl%r1,sumu64# sumu64.7, sumu64
Have I grossly misunderstood something there? Can I really operate on an
unsigned integer with signed operations and get the correct results?
Best wishes / Mejores deseos / Meilleurs vœux
Ian ...
Re: Removal of transactional execution facility
Hmmm, you mention "speculative execution". Maybe that make it vulnerable to meltdown/spectre type attacks. -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: Removal of transactional execution facility
The dual path requirement put me off doing anything with it for a long time. I thought using it to follow suspect pointer chains instead of using ESPIE/ESTAE would be worth dual pathing the ESPIE/ESTAE code, but that is now moot. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mike Shaw Sent: Wednesday, April 6, 2022 15:23 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Removal of transactional execution facility Maybe Dan Greiner can comment on why IBM went to the trouble to introduce this powerful facility and then pull it? ISVs who implemented code using the transactional execution facility might feel kinda "had" now... Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Wed, Apr 6, 2022 at 4:17 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > In the Statement of general direction in the z16 announcement at: > > > https://clicktime.symantec.com/3EajRQyLQEC62msLUyNtDVZ6xn?u=https%3A%2 > F%2Fwww.ibm.com%2Fcommon%2Fssi%2FShowDoc.wss%3FdocURL%3D%2Fcommon%2Fss > i%2Frep_ca%2F1%2F897%2FENUS122-001%2Findex.html > > It says IBM will remove support for the transactional execution > facility, I guess there's no point in attempting to exploit this now. > > Robert Ngan > DXC Luxoft >
Removal of transactional execution facility
In the Statement of general direction in the z16 announcement at: https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/1/897/ENUS122-001/index.html It says IBM will remove support for the transactional execution facility, I guess there's no point in attempting to exploit this now. Robert Ngan DXC Luxoft
Re: z16 Announcement
Not much in the way of details, but information on new z16 instructions that might be of interest to members of this list: https://www.phoronix.com/scan.php?page=news_item&px=IBM-Z-Arch14-GCC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Tuesday, April 5, 2022 17:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: z16 Announcement If you haven't already seen it, IBM announced the z16 today: https://clicktime.symantec.com/36jCCrb8KSR5XH2bF9dM5Jj6xn?u=https%3A%2F%2Fwww.ibm.com%2Fcommon%2Fssi%2FShowDoc.wss%3FdocURL%3D%2Fcommon%2Fssi%2Frep_ca%2F1%2F897%2FENUS122-001%2Findex.html
Re: Testing address validity
We have a similar issue when following pointer chains that could have be corrupted. If you're only reading the storage, I think transactionalizing the code with TBEGIN/TEND will do this for you. If the transaction is successful, you have access, if it's not you don't. Don't know if this approach will actually work, it's the next new instruction facility I intend to play with, when I have the time. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of João Reginato Sent: Monday, March 7, 2022 12:17 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: RES: Testing address validity Importance: Low These macros are great. Thank you all by the discussion. Very useful -Mensagem original- De: IBM Mainframe Assembler List Em nome de Jeremy Schwartz Enviada em: sábado, 5 de março de 2022 17:14 Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU Assunto: Re: Testing address validity Just curious would the following macros work better as a replacement for TPROT in the requested case? IARBRVER, IARBRVEA, and IARBRVKA Regards, Jeremy Schwartz From: IBM Mainframe Assembler List on behalf of Philippe Leite Sent: Saturday, March 5, 2022 9:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity 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. You can use TPROT for this purpose but it's a privileged instruction. Regards, Philippe Leite LAB Services - IBM Em sáb., 5 de mar. de 2022 09:45, João Reginato escreveu: > Hi > > Which is the best instruction to test if a virtual address is still > valid to avoid an unexpected S0C4? > > > > TIA > > João > > > --- 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: Testing address validity
What IBM told us (sometime last century) is that when you get a CC=3 and you really want to know more, you establish a recovery routine, reference the storage (with a CLI or something similar) and then (after cleanup) re-issue the TPROT. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Saturday, March 5, 2022 19:28 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Testing address validity How would you handle CC 3 from TPROT? Does z/VSE have a facility to request a page-in without treating an invalid virtual address as an error? -- Shmuel (Seymour J.) Metz
Re: Executing a ZAP Instruction
Before the advent of the COMPARE AND TRAP type instructions, we all use to use EX Rnn,* to force a S0C3 abend for "this should never happen" conditions. But with baseless code, if you change EX Rnn,* to EXRL Rnn,* then you may not get your expected S0C3 when Rnn is a register other than zero. The low order nybble of the second byte of EXRL is zero indicating an EXRL instruction, if you modify it then it becomes some other X'C0' instruction! Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Friday, February 11, 2022 17:27 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction Meaning what? You can't EX a PACK instruction? Are you absolutely certain of that? I think you can EX anything except an EX/EXR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Friday, February 11, 2022 3:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Executing a ZAP Instruction On Fri, 11 Feb 2022 17:03:09 -0500, Dave Clark wrote: > Does that mean ZAP can't be EXecuted? Yes, you can EXecute a ZAP instruction. But, you can't use it to PACK -- Tom Marchant
Hexadecimal display using vector instructions
I originally just coded the obvious VUPKZ/MVI/TR like a UNPK/MVI/TR or UNPKA/MVI/TR instruction sequence, but found the performance was within 10% for all three variations. It looks like most of the time is spent in the TR instruction. So, we need to eliminate the TR, and I came up with two ways to do hexadecimal display conversion using the vector facility without TR: VECTOR UNPACK LOGICAL VLVR03,WorkXL16Load quadword source VLVR06,=C'0123456789ABCDEF' "Translate" table VREPIB VR05,X'000F'Initialize AND mask *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* VUPLLB VR07,VR03 Pad each byte in LOW doublewordX ... with a null byte on the left VSLD VR02,VR07,VR07,4 Shift out high order nybble VNVR04,VR02,VR05 Mask out L.O. source nybbles inX ... H.O. vector register nybbles VOVR08,VR04,VR07 Merge high/low nybble bytes VPERM VR01,VR06,VR06,VR08 Translate to hexadecimal digits *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* VUPLHB VR07,VR03 Pad each byte in HIGH doubleword X ... with a null byte on the left VSLD VR02,VR07,VR07,4 Shift out high order nybble VNVR04,VR02,VR05 Mask out L.O. source nybbles inX ... H.O. vector register nybbles VOVR08,VR04,VR07 Merge high/low nybble bytes VPERM VR00,VR06,VR06,VR08 Translate to hexadecimal digits *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* VSTM VR00,VR01,WorkCL32 Store 32 hex digits VECTOR MERGE VLVR12,WorkXL16 Load quadword source VLVR15,=C'0123456789ABCDEF' "Translate" table VERLLB VR14,VR12,4 Swap high/low nybbles within bytes VPERM VR13,VR15,VR15,VR12 Translate LOW nybbles to hex digits VPERM VR11,VR15,VR15,VR14 Translate HIGH nybbles to hex digits VMRHB VR09,VR11,VR13 Merge H.O. 16 hexadecimal digits VMRLB VR10,VR11,VR13 Merge L.O. 16 hexadecimal digits VSTEG VR09,WorkCL8a,0 Spread out hex digits, 8 per per store VSTEG VR09,WorkCL8b,1 ... VSTEG VR10,WorkCL8c,0 ... VSTEG VR10,WorkCL8d,1 ... Both versions of the vector code run 5-20 time faster than your classical UNPK/MVI/TR (5-20 nSec vs. 90-100 nSec on a z15 T02). The UNPACK LOGICAL does 8 bytes at a time, so you can shorten the code if you're converting no more than 8 bytes. The MERGE code always does all 16 bytes, but second (low) MERGE is not required if not converting more than 8 bytes. In MERGE example, I'm using multiple VSTEG's instead of a VSTM to spread the output across 4 separate fields for legibility. This code will convert 16 bytes at a time, unlike UNPKA and VUPKZ which are restricted to a maximum of 15 bytes. And there's no "extra" byte to clean up on the target side, or to worry about accessibility to on the source side. A big thanks to Dan Greiner for his extremely helpful PowerPoints explaining how the vector instructions work. But I still have no idea how we'd use half of those instructions in general coding. The VPERM instruction seems to be a (all register) TRANSLATE against a 32-byte table (in two vector registers), looking at only the L.O. 5 bits of each byte. I only needed to look at the bottom 4-bits, and achieved that by using the same register for both halves of the translate table. It's probably too complicate to hand-code, but useful if you have hexadecimal display macro you can generate it from. Robert Ngan DXC Luxoft
Re: Unsigned 64-bit numbers
This is just a LG, just like L for 32-bits. It doesn't matter whether it's signed or unsigned. There's nowhere for a sign to be extended. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Tuesday, February 1, 2022 10:39 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 -- 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: 64-bit registers (was: Unsigned Binary Formats)
Basically, yes. Some instructions always use all 64-bis of the register. However others, like LA are addressing mode sensitive. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Wednesday, January 19, 2022 12:45 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: 64-bit registers (was: Unsigned Binary Formats) "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 -- 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: Unsigned Binary Formats
Assuming you eventually want the value to be in character format, the COBOL compiler doc says that with the appropriate ARCH() level, it'll generate DFP instructions to do this instead of using CVD/UNPK so I assume DFP is faster, and you can use: CDLFTR FP00,0,R02,0 Convert unsigned binary to long DFP CZDT FP00,Target,0 ... and then long DFP to zoned Or via the vector facility, using: VCVD VR31,R02,10,8+2 Convert unsigned binary to decimal VUPKZ VR31,Target,L'Target-1 ... and then to zoned Using DFP or vector seems to be around 10 times faster than CVD/UNPK, according to my measurements on a z15 T02. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dave Clark Sent: Wednesday, January 19, 2022 11:32 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Unsigned Binary Formats 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 -- Winsupply Group Services 3110 Kettering Boulevard Dayton, Ohio 45439 USA (937) 294-5331
Vector register 23?
Under "Saving the caller program's registers", the assembler services guide states: Vector registers (VRs) 8 - 15, bytes 0 - 7, and the entirety of VRs 16 - 23 are unchanged. 16-23 only! Not 16-31. Is this correct? Robert Ngan DXC Luxoft
Re: Base-less macros
As per the FPR usage thread, you could also save GR(s) to FP registers 0 thru 7. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Monday, November 29, 2021 18:03 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I did not think about how this had to happen before you had saved any registers. (Same issue for @Gary's suggestion, which is basically equivalent to mine.) If there is no register that your linkage conventions imply do not need to be saved (R0?) then you could temporarily save a register at 12(R13). That is available no matter what the format. Wastes a storage access, of course. You could save R14 there in whatever is the "expected" format of the save area. If you guessed right then no need to save it again. If "old style" is the most common situation, then you might do the whole R14,R12,12(R13) nine yards and if you got it right then you are mostly done. Steve Smith's suggestion of AR0 is interesting. Never thought about that ... Charles
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
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. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Thursday, November 25, 2021 13:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros My suggestion of using R14 for the base was because it's already set by the call to the subroutine. sas On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold wrote: > 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. > >
Re: Base-less macros
We got rid of all of this form of branch tables way back when, after IBM added a new RC for the OPEN macro (i.e. 16 for RLS), and our code jumped beyond the branch table into the RC=0 code! Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Tuesday, November 23, 2021 10:21 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros ...some BASR R14, or JAS R14, etc. USING *,R14 B *+4(R15) DROP R14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE sas
Re: ASMA030E?
These are pointer fields within table entries. To use LA/LAY, I'd have to unroll the table lookup code, which I don't want to do. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Tuesday, November 23, 2021 16:24 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ASMA030E? Because you can't . It makes sense but you can't do it. Would 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. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, November 23, 2021 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: ASMA030E? Why can't I code: DCA(=C'blah') This give an ASMA030E error, but wanting the address of a literal string seems legitimate to me as I don't otherwise need a named field with this value. Robert Ngan DXC Luxoft
Re: ASMA030E?
I already have 3 LOCTR's (code, static data, and yonder (i.e. long displacement) static data. Since tables and stuff referenced only via adcons belong in the yonder LOCTR, I'd need a second yonder LOCTR to separate the table entries from the character strings, since the table entries need to be contiguous. I'll use &SYSNDX for the names, cache 'em, and generate them with a 'FINAL' type call. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Tuesday, November 23, 2021 15:33 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ASMA030E? On Nov 23, 2021, at 14:14:44, Ngan, Robert (DXC Luxoft) wrote: > > That complicates my code, where I wanted to do this to generate table > entries. Now I need a separate named field for each generated table entry! > Would a MACRO using LOCTR and &SYSNDX simplify it? > -Original Message- > Why can't I code: >> >> >>DCA(=C'blah') >> >> This give an ASMA030E error, but wanting the address of a literal string >> seems legitimate to me as I don't otherwise need a named field with this >> value. >> > Jonatnan Scott answered the same question a couple weeks ago. DC and > literals are handled by a single subroutine which is not coded recursively. > He cited a compromise between code complexity and perceived usefulness. --gil
Re: ASMA030E?
That complicates my code, where I wanted to do this to generate table entries. Now I need a separate named field for each generated table entry! Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Tuesday, November 23, 2021 14:31 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ASMA030E? On Nov 23, 2021, at 12:40:13, Ngan, Robert (DXC Luxoft) wrote: > > Why can't I code: > > DCA(=C'blah') > > This give an ASMA030E error, but wanting the address of a literal string > seems legitimate to me as I don't otherwise need a named field with this > value. > Jonatnan Scott answered the same question a couple weeks ago. DC and literals are handled by a single subroutine which is not coded recursively. He cited a compromise between code complexity and perceived usefulness. -- gil
Re: Base-less macros
Oops, I didn't notice Pieter's response. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, November 23, 2021 13:44 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] 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. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Base-less macros
Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] 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. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
ASMA030E?
Why can't I code: DCA(=C'blah') This give an ASMA030E error, but wanting the address of a literal string seems legitimate to me as I don't otherwise need a named field with this value. Robert Ngan DXC Luxoft
Re: Vector Instructions
I suggested the "omitted uses implied length" syntax since RISBG etc. instructions already have "omitted implies zero" for the fifth operand. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Friday, October 1, 2021 03:21 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector Instructions The HLASM team also failed to spot this oddity in the syntax at the time, partly because the I3 field was not described clearly as "length", even though that is what it is in effect. Dan's concern about adding extra function to the I3 field would not have been a problem for HLASM (provided that the split was on bit boundaries) because HLASM can for example define a 5-bit length field and a 3-bit flag field, even though at present all operand fields start and end on 4-bit boundaries. Any new extra function field could have been defined as a separate operand. Unfortunately the only way to implement the standard syntax would be to add new mnemonics, as we cannot change the existing definitions for compatibility reasons. We might still end up doing something like that. Robert's alternative suggestion of assuming the implied length if omitted would require new unique parsing logic in this case and would make it difficult to extend this instruction in future. Dan Greiner wrote: > Interesting comment, Robert. > > Assuming that the storage operand field of VPKZ/VUPKZ is defined with > an appropriate length, you make a valid point. > > Had I been been paying closer attention when this was architected, I > might have suggested that the VSI instruction format (added > specifically in support of VPKZ and VUPKZ) incorporate the length as > part of the second operand ... that is, an L2 field instead of an I3 > field. That way, you could code the instruction the way you suggested, > or as is done for other storage operands with an embedded length, > e.g., > > vupkz 1,storage_op > vupkz 1,storage_op(23) > vupkz 1,543(21,12) > > However, as is obvious with recent changes in the architecture, IBM > tends to sneak new features into previously reserved operand bits. If > some future enhancement added function to the I3 field, the suggestion > I made above could become awkward. Jonathan Scott, HLASM IBM Hursley, UK
Re: Vector Instructions
One use case: It has been mentioned here that EXECUTE'd instructions are expensive. So for variable length MVCs up to 16 bytes, an executed MVC could be replaced by VLL/VSTL. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Thursday, September 30, 2021 15:30 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector Instructions Thank you Dan, This is a lot easier to understand than what's in the Principles of Operations. I've only gotten thru to Chapter 21 and I've already found three cases where I can use vector instructions in our code. One nit (nothing to do with your Powerpoints), the third VPKZ/VUPKZ operand should be optional, with the assembler defaulting to the length of implied length of the second operand. Having to always code: VPKZ 1,Source,L'Source-1 VUPKZ 2,Target,L'Target-1 will get tedious really fast. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Tuesday, September 28, 2021 23:06 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Vector Instructions I have put together a series of PowerPoint files illustrating the operation of the vector-facility instructions ... a sort of graphic-novel version of Chapters 21-25 of the PoO. Since the Assembler List doesn't accept file uploads, you can find the material on my Google drive: https://clicktime.symantec.com/3ReigZgh6pPBGgrWU1YpCps7Vc?u=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1O_RWJJGMX-tLR0AxEYk4QARxJhi_0MVV%2Fview%3Fusp%3Dsharing Background: Although I edited much of the vector-facility material that was incorporated into the z13 z/Architecture Principles of Operation back in 2015, I was not the engineer responsible for the material, and I never bothered to study it very closely. Since I retired in 2017, I've been looking more closely, and recently I started scribbling some notes on a few instructions that puzzled me ... which turned into a few PowerPoint slides ... which eventually turned into a 300+ slide opus. The PowerPoint files were prepared using a template that I've used in the past for presentations at SHARE conferences. Like other presentations illustrating new architecture, the slides make extensive use of animation to illustrate the operation and data flow. So, they are best viewed in slide-show mode. However, the real meat of the material is in the presenter notes for each slide (with a two monitors, you can see both simultaneously). There are separate PowerPoint files including an introduction, and a file for each chapter of the PoO containing vector instructions (7, and 21-25). In the Chapter 21 file, there are separate slides illustrating the operation of an instruction with each element size. By the time I got to Chapter 22, my carpals were acting up, so the slides are mostly limited to a single element size. At the end of a SHARE presentation, I would (time permitting) solicit questions from the audience, and extended discussions might continue at the SHARE Committee for Informal Discussions (SCIDs, a.k.a. an open bar). Considering the content of these slides, it would likely take days to present one chapter's worth ... by which time, the SCIDs would have long since run out of liquor before any interesting questions could be posed. As it is unlikely this material will make it to the SHARE agenda any time soon, I thought I'd just share it directly. You are welcome to use it for your own enlightenment, but I will have strong words with anyone who tries to make a buck off of it. As one might expect, much of the development involved a lot of copy-and-paste operations on a PC, so there may be a few copy-and-paste type of errors lurking about. If you have questions or meaningful comments as to clarity or accuracy, you're welcome to contact me via email. However, is you simply don't like the fonts, colors, or animation ... well ... have a nice day.
Re: Vector Instructions
Thank you Dan, This is a lot easier to understand than what's in the Principles of Operations. I've only gotten thru to Chapter 21 and I've already found three cases where I can use vector instructions in our code. One nit (nothing to do with your Powerpoints), the third VPKZ/VUPKZ operand should be optional, with the assembler defaulting to the length of implied length of the second operand. Having to always code: VPKZ 1,Source,L'Source-1 VUPKZ 2,Target,L'Target-1 will get tedious really fast. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Tuesday, September 28, 2021 23:06 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Vector Instructions I have put together a series of PowerPoint files illustrating the operation of the vector-facility instructions ... a sort of graphic-novel version of Chapters 21-25 of the PoO. Since the Assembler List doesn't accept file uploads, you can find the material on my Google drive: https://clicktime.symantec.com/3ReigZgh6pPBGgrWU1YpCps7Vc?u=https%3A%2F%2Fdrive.google.com%2Ffile%2Fd%2F1O_RWJJGMX-tLR0AxEYk4QARxJhi_0MVV%2Fview%3Fusp%3Dsharing Background: Although I edited much of the vector-facility material that was incorporated into the z13 z/Architecture Principles of Operation back in 2015, I was not the engineer responsible for the material, and I never bothered to study it very closely. Since I retired in 2017, I've been looking more closely, and recently I started scribbling some notes on a few instructions that puzzled me ... which turned into a few PowerPoint slides ... which eventually turned into a 300+ slide opus. The PowerPoint files were prepared using a template that I've used in the past for presentations at SHARE conferences. Like other presentations illustrating new architecture, the slides make extensive use of animation to illustrate the operation and data flow. So, they are best viewed in slide-show mode. However, the real meat of the material is in the presenter notes for each slide (with a two monitors, you can see both simultaneously). There are separate PowerPoint files including an introduction, and a file for each chapter of the PoO containing vector instructions (7, and 21-25). In the Chapter 21 file, there are separate slides illustrating the operation of an instruction with each element size. By the time I got to Chapter 22, my carpals were acting up, so the slides are mostly limited to a single element size. At the end of a SHARE presentation, I would (time permitting) solicit questions from the audience, and extended discussions might continue at the SHARE Committee for Informal Discussions (SCIDs, a.k.a. an open bar). Considering the content of these slides, it would likely take days to present one chapter's worth ... by which time, the SCIDs would have long since run out of liquor before any interesting questions could be posed. As it is unlikely this material will make it to the SHARE agenda any time soon, I thought I'd just share it directly. You are welcome to use it for your own enlightenment, but I will have strong words with anyone who tries to make a buck off of it. As one might expect, much of the development involved a lot of copy-and-paste operations on a PC, so there may be a few copy-and-paste type of errors lurking about. If you have questions or meaningful comments as to clarity or accuracy, you're welcome to contact me via email. However, is you simply don't like the fonts, colors, or animation ... well ... have a nice day.
Re: How can I invoke an arbitrary macro with arbitrary KEYWORD
Thanks, I'll try AINSERT. For my current use case, this limitation is acceptable. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Thursday, September 30, 2021 08:17 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: How can I invoke an arbitrary macro with arbitrary KEYWORD Ref: Your note of Wed, 29 Sep 2021 23:10:27 + The only way to invoke a macro with dynamically specified keyword parameters is to use AINSERT, which has the limitation that the macro will only get invoked after macro processing returns to the open code level. You can of course use AINSERT again to queue some action to continue the original processing after invoking the macro, for example by invoking the original macro with some sort of resume indicator. Jonathan Scott, HLASM IBM Hursley, UK
Re: How can I invoke an arbitrary macro with arbitrary KEYWORD parameters?
I added:
UNSPLIT3 &Name &PARMS
After UNSPLIT2, it still comes thru as a SYSLIST value.
Robert Ngan
DXC Luxoft
-Original Message-
From: IBM Mainframe Assembler List On Behalf
Of Abe Kornelis
Sent: Thursday, September 30, 2021 00:51
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: How can I invoke an arbitrary macro with arbitrary KEYWORD
parameters?
Robert,
IIRC (I hope so) I got it to work with all parms concatenated into a single
variable.
You might give it a try ...
Success!
Abe
===
Op 30/09/2021 om 01:10 schreef Ngan, Robert (DXC Luxoft):
> I’m trying to invoke a macro specifying keyword parameters within another
> macro, where the keyword and its value were passed to the outer macro.
> However, the assembler is always interpreting keyword=value as a SYSLIST
> value.
> Anyone know how this can be done, or even if it is possible?
> The code below shows what I’m trying to do, the “Invoked”d macros never
> receive keyword operand values.
>
> CallMAC TITLE 'Test macro invocations'
> MACRO
> Invoke &Name,&PARMS
> .**
> .* Invoke passed macro, with the passed parameters *
> .**
> AIF (T'&PARMS(1) EQ 'O').AAm110
> &J SETA INDEX('&PARMS(1)','=')
> &lValue1 SETC '&PARMS(1)'(1,&J-1)
> &rValue1 SETC '&PARMS(1)'(&J+1,*)
> .AAm110 ANOP ,
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
> AIF (T'&PARMS(2) EQ 'O').AAm120
> &J SETA INDEX('&PARMS(2)','=')
> &lValue2 SETC '&PARMS(2)'(1,&J-1)
> &rValue2 SETC '&PARMS(2)'(&J+1,*)
> .AAm120 ANOP ,
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
> AIF ('&PARMS(2)' NE '').AAm220
> AIF ('&PARMS(1)' NE '').AAm210
> UNSPLIT0 &Name ,
> AGO .AAm300
> .AAm210 ANOP ,
> UNSPLIT1 &Name &PARMS(1)
> AGO .AAm300
> .AAm220 ANOP ,
> UNSPLIT2 &Name &PARMS(1),&PARMS(2)
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> *
> .AAm300 ANOP ,
> AIF ('&PARMS(2)' NE '').AAm320
> AIF ('&PARMS(1)' NE '').AAm310
> SPLIT0 &Name ,
> AGO .AAm999
> .AAm310 ANOP ,
> SPLIT1 &Name &lValue1=&rValue1
> SPLIT1A &Name &lValue1.=&rValue1
> AGO .AAm999
> .AAm320 ANOP ,
> SPLIT2 &Name &lValue1=&rValue1,&lValue2=&rValue2
> SPLIT2A &Name &lValue1.=&rValue1,&lValue2.=&rValue2
> .AAm999 ANOP ,
> MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> MACRO
> &Label TestMac1 &T1O1=
> .**
> .* Macro expecting single parameter *
> .**
> &P SETA N'&SYSLIST
> MNOTE *,'TestMac1 &Label #Parms=&P'
> &I SETA 1
> .BBm010 ANOP ,
> AIF (&I GT &P).BBm020
> MNOTE *,' SYSLIST(&I) = /&SYSLIST(&I)/'
> &I SETA &I+1
> AGO .BBm010
> .BBm020 ANOP ,
> MNOTE *,' T1O1=/&T1O1/'
> MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> MACRO
> &Label TestMac2 &T2O1=,&T2O2=
> .**
> .* Macro expecting two parameters *
> .**
> &P SETA N'&SYSLIST
> MNOTE *,'TestMac2 &Label #Parms=&P'
> &I SETA 1
> .CCm010 ANOP ,
> AIF (&I GT &P).CCm020
> MNOTE *,' SYSLIST(&I) = /&SYSLIST(&I)/'
> &I SETA &I+1
> AGO .CCm010
> .CCm020 ANOP ,
> MNOTE *,' T2O1=/&T2O1/,T2O2=/&T2O2/'
> MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> EJECT
> PRINT MCALL
> TestMac1 ,
> TestMac1 T1O1=aaa
> TestMac2 T2O1=bbb,T2O2=ccc
> ***
> Invoke TestMac1
> *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
> Invoke TestMac1,(T1O1=zzz)
> *- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
> Invoke TestMac2,(T2O1=yyy,T2O2=xxx)
> END
>
> Thanks,
> Robert Ngan
> DXC Luxsoft
>
>
>
How can I invoke an arbitrary macro with arbitrary KEYWORD parameters?
I’m trying to invoke a macro specifying keyword parameters within another
macro, where the keyword and its value were passed to the outer macro. However,
the assembler is always interpreting keyword=value as a SYSLIST value.
Anyone know how this can be done, or even if it is possible?
The code below shows what I’m trying to do, the “Invoked”d macros never receive
keyword operand values.
CallMAC TITLE 'Test macro invocations'
MACRO
Invoke &Name,&PARMS
.**
.* Invoke passed macro, with the passed parameters *
.**
AIF (T'&PARMS(1) EQ 'O').AAm110
&J SETA INDEX('&PARMS(1)','=')
&lValue1 SETC '&PARMS(1)'(1,&J-1)
&rValue1 SETC '&PARMS(1)'(&J+1,*)
.AAm110 ANOP ,
.*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
AIF (T'&PARMS(2) EQ 'O').AAm120
&J SETA INDEX('&PARMS(2)','=')
&lValue2 SETC '&PARMS(2)'(1,&J-1)
&rValue2 SETC '&PARMS(2)'(&J+1,*)
.AAm120 ANOP ,
.*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
AIF ('&PARMS(2)' NE '').AAm220
AIF ('&PARMS(1)' NE '').AAm210
UNSPLIT0 &Name ,
AGO .AAm300
.AAm210 ANOP ,
UNSPLIT1 &Name &PARMS(1)
AGO .AAm300
.AAm220 ANOP ,
UNSPLIT2 &Name &PARMS(1),&PARMS(2)
.*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
.AAm300 ANOP ,
AIF ('&PARMS(2)' NE '').AAm320
AIF ('&PARMS(1)' NE '').AAm310
SPLIT0 &Name ,
AGO .AAm999
.AAm310 ANOP ,
SPLIT1 &Name &lValue1=&rValue1
SPLIT1A &Name &lValue1.=&rValue1
AGO .AAm999
.AAm320 ANOP ,
SPLIT2 &Name &lValue1=&rValue1,&lValue2=&rValue2
SPLIT2A &Name &lValue1.=&rValue1,&lValue2.=&rValue2
.AAm999 ANOP ,
MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
MACRO
&Label TestMac1 &T1O1=
.**
.* Macro expecting single parameter *
.**
&P SETA N'&SYSLIST
MNOTE *,'TestMac1 &Label #Parms=&P'
&I SETA 1
.BBm010 ANOP ,
AIF (&I GT &P).BBm020
MNOTE *,' SYSLIST(&I) = /&SYSLIST(&I)/'
&I SETA &I+1
AGO .BBm010
.BBm020 ANOP ,
MNOTE *,' T1O1=/&T1O1/'
MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
MACRO
&Label TestMac2 &T2O1=,&T2O2=
.**
.* Macro expecting two parameters *
.**
&P SETA N'&SYSLIST
MNOTE *,'TestMac2 &Label #Parms=&P'
&I SETA 1
.CCm010 ANOP ,
AIF (&I GT &P).CCm020
MNOTE *,' SYSLIST(&I) = /&SYSLIST(&I)/'
&I SETA &I+1
AGO .CCm010
.CCm020 ANOP ,
MNOTE *,' T2O1=/&T2O1/,T2O2=/&T2O2/'
MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
EJECT
PRINT MCALL
TestMac1 ,
TestMac1 T1O1=aaa
TestMac2 T2O1=bbb,T2O2=ccc
***
Invoke TestMac1
*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
Invoke TestMac1,(T1O1=zzz)
*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
Invoke TestMac2,(T2O1=yyy,T2O2=xxx)
END
Thanks,
Robert Ngan
DXC Luxsoft
Re: Ensuring LRL 2nd operand alignment
Or: DC 0F Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Friday, April 30, 2021 19:48 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Ensuring LRL 2nd operand alignment On 2021-04-30, at 16:17:06, Charles Mills wrote: > ... > And #3 the > DS 0F has a 50-50 (or 3 in 4, depending on how you look at it) chance > of generating a couple of garbage-filled slack bytes. > That's what CNOP is for. -- gil
Re: security with storage allocation under z.OS
I found out the hard way that, if you code EXECUTABLE=YES of the STORAGE OBTAIN, you must also code it on the associated STORAGE RELEASE. Evidently, it's implemented as a subpool under the covers, so like subpool getmains, you must have matching values on OBTAIN and RELEASE. Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Monday, November 16, 2020 11:39 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: security with storage allocation under z.OS There is a new operand on STORAGE, EXECUTABLE=YES|NO. The default is YES, and for earlier releases there was no execute-prevention capability afaik. I don't know what to tell you about the "security model". It's a big subject. sas On Mon, Nov 16, 2020 at 12:24 PM Ze'ev Atlas < 01774d97d104-dmarc-requ...@listserv.uga.edu> wrote: > Hi allIn the 1970's I probably could have done some getmain, write > some code into that obtained memory and jump to that code. I assume > that nowadays, this would be impossible and there is some security > model to prevent such a security breach.Do you know where can I find > information on the mainframe security model under z/OS. > Ze'ev Atlas >
Re: Does the z architecture have something like the SIMD instructions
SA22-7832-15??? The latest version I have is SA22-7832-12, and I've been looking for SA22-7832-13 since the z15 T02 was GA'd last month with 30 new instructions. Has anyone seen the POPS for the z15 T02? Robert Ngan HCL Technologies (USA) -Original Message- From: IBM Mainframe Assembler List On Behalf Of Dan Greiner Sent: Friday, June 5, 2020 13:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does the z architecture have something like the SIMD instructions Although it does actually access multiple data items, PERFORM LOCK OPERATION (PLO) really doesn't qualify as a SIMD instruction (see my PLO screed below). Seymour's reference to the Wikipedia page (https://clicktime.symantec.com/3NjuMxE6MEZBEJLxW7KRK1C7Vc?u=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSIMD) is about as adequate a definition as any I've seen. As I recall, IBM's original implementation of vector instructions appeared as an optional extension to ESA/390, but these were never part of the standard architecture defined in the PoO. With the advent of the z13 (2015), IBM added vector instructions to the general architecture, and added Chapters 21-24 to the PoO. There are 32 vector registers, each having 128 bits ... but the 64 bits of VRs 0-15 are the same as floating-point register 0-15. This is not to say that VRs are necessarily floating-point entities; they can be binary integers, strings, or floating point. With the introduction of the z14 (2017), IBM added (a) new instructions that enhanced the existing VR facility, and (b) a vector packed-decimal facility (the latter being a benefit to COBOL and other packed players). With the introduction of the z15 (2019), IBM added a second enhancement to the VR facility. There are now around 190 separate vector instructions — with a mind-boggling array of extended mnemonics. If you haven't bothered to download a PoO in the last few years, it's worth it (but if you choose to print it, have two reams of paper handy). Check out SA22-7832-15 for the latest version. Regarding PLO, this provides the means by which multiple, discontiguous storage locations can appear to be updated atomically without having to bother acquiring a lock. However, in order for PLO to operate properly, EVERY program that inspects or modifies those storage locations also has to do it with PLO. This is because the firmware for PLO gets its own lock in HSA, and serializes other CPUs attempts to use PLO with that lock. If other programs on other CPUs examine the data, the updates do not necessarily appear to be atomic. And, if some programs use PLO and others try to perform updates with classic compare-and-swap logic, really BAD things happen (as certain z/OS developers have discovered more than once). If nobody was actually using PLO, I would have quietly proposed removing it from the architecture, but (alas) there are some OS components that have actually managed to use it properly. For a far more flexible (and higher performance) means of atomic updates of multiple storage locations, check out the transactional-execution facility introduced in the z12 (2012). 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: *-*
You can specify GR's via: R0 EQU 0,8,,,GR HLASM also supports a bunch of other register types. However when you do this, use of non-register equates (i.e. by CICS macros) gets flagged by the assembler. Robert Ngan -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Thursday, April 30, 2020 11:18 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: *-* LOCTR is indeed your friend, but sometimes more than one EX has the same target. A clear comment of intent (*not* a translation of the instruction) is appropriate in that situation. -- Shmuel (Seymour J.) Metz https://clicktime.symantec.com/3BuUJhU9JjPxguF2J9ZsRay7Vc?u=http%3A%2F%2Fmason.gmu.edu%2F~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Thursday, April 30, 2020 12:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: *-* On 2020-04-30, at 08:56:41, Phil Smith III wrote: > > Comments should be included. But consider an EX: > > MVCEXMVC 0(*-*,R2),0(R3)Copy the parameter > > Now, that statement will appear by itself, not inline (unless you use the > "put it inline and jump around it and then do the EX *-10 or whatever it is, > which I've always found ugly), ... LOCTR is the friend of the avant garde. And it respects USING in effect at its appearance in the text. On 2020-04-30, at 06:54:37, Rob van der Heij wrote: > > I ran into some code where the programmer decided to know better and > had defined RA-RF and used that where he made his changes (and have me > scratch my head about something keeping an address as return code). I > did not friend him. > I ran into some code where the programmer used mnemonic register register equates, such as: RPARM EQU 1 .. RRSA EQU 13 RLINK EQU 14 RRC EQU 15 An expert tells me this is a Bad Idea. In CDC 6600 assemblef, registers were identified by unique symbols, not compatible with numeric expressions. I believe this engendered robust coding techniques; 6600 programmers rarely listed macro expansions: "It does what it ought to; I'd print it out only for debugging, just like a subroutine. But no machine instructions relied on even-odd register pairs. Doesn't HLASM have a register symbol type? Could macros rely on this rather than parentheses to indicate registers? -- gil 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: BASR to AMODE 64 (Baseless code)
We use TWO LOCTR's, one for constants required to be within 4K of the base register and a second for constants only referenced by relative long or long displacement instructions. Useful when your combined constants size exceeds 4K as it moves the "yonder" fields out of the 4K space. I wish there was easy way to aggregate the LTORG literals specifically into pre and (potentially) post 4K LTORGs. Robert Ngan -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, December 2, 2019 19:51 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data do not exceed 4Ki? For programs that don't use a base register for the code, good coding practices requires LOCTR be used to place constants at the beginning of your program (with branch around). As long as constants never exceed 4KB, the program won't need to be reworked to free a register. > dissension about whether control block definitions should > precede or follow instructions. > And the former group was biased by experience with languages which > required symbols defined before reference. CB location in the source is not always cosmetic because of the macro language. I've worked on a product that will not assemble with the CB's at the end of source. The cosmetic problem of placing CB's at the beginning is no longer a problem because ISPF and SDSF editor allows lines to be hidden. Just write an edit macro to hide CB definitions. Jon. 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: Vector enablement control?
Yes, and an even better answer. Thanks, Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jim Mulder Sent: Friday, November 1, 2019 10:42 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector enablement control? The question you really want to ask is "how should I determine if the task under which I am running has used already used vector instructions"? The answer is to look at PSAVSS or STCBVSS (which are classified as Programming Interfaces). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY "IBM Mainframe Assembler List" wrote on 10/31/2019 01:30:13 PM: > From: "Ngan, Robert" > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 11/01/2019 11:36 AM > Subject: Vector enablement control? > Sent by: "IBM Mainframe Assembler List" > > With the new COBOL compilers capable of generating vector instructions > for handling packed fields, I'm looking at modifying our ESTAE > routines to dump the contents of the vector registers. > The PoOPs says you should not issue a vector instruction unless both > the vector enablement control and AFP-register control bits in CR0 are on. > If you're running z/OS on a z13 of higher (i.e. your machine a vector > instruction support), would either of these two bits ever be off? > > From a standard ESTAE routine, I can examine the CR0 contents from the > SDWA, but in a CICS ABEND exit, I don't have access to CR0. > > Robert Ngan > HCL Technologies 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: Vector enablement control?
Thanks, exactly what I wanted to know. Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Peter Relson Sent: Friday, November 1, 2019 06:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Vector enablement control? If you're running z/OS on a z13 of higher (i.e. your machine a vector instruction support), would either of these two bits ever be off? Yes. Note that "machine" is only one of the factors involved. Also involved are "z/OS release" and "LOADxx MACHMIG statement options". You should never use the vector extension facility unless bit CVTVEF is on. There is no z/OS release for which CVTVEF can be assumed to be on regardless of machine and environment (i.e., the vector extension facility is not part of any z/OS architecture levelset). When CVTVEF is on, work units generally start with the relevant CR0 bit off. The first VEF instruction results in a data exception program check (interrupt code 7). The system reacts to that by beginning vector register status save/restore for that work unit at which point that work unit will subsequently have the relevant CR0 bit on and that first VEF instruction is re-executed. The bit's being off is not relevant to much of anything; that is just a starting state. P.S. Is there a mapping macro for the control register bit flags? no. Peter Relson z/OS Core Technology Design 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.
Vector enablement control?
With the new COBOL compilers capable of generating vector instructions for handling packed fields, I'm looking at modifying our ESTAE routines to dump the contents of the vector registers. The PoOPs says you should not issue a vector instruction unless both the vector enablement control and AFP-register control bits in CR0 are on. If you're running z/OS on a z13 of higher (i.e. your machine a vector instruction support), would either of these two bits ever be off? >From a standard ESTAE routine, I can examine the CR0 contents from the SDWA, >but in a CICS ABEND exit, I don't have access to CR0. Robert Ngan HCL Technologies P.S. Is there a mapping macro for the control register bit flags? 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: ltorg question
Correct, 64 bit numbers are still not supported, but negative values are signed extended into the top 32 bits. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Wednesday, June 26, 2019 16:46 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ltorg question > On Jun 26, 2019, at 3:15 PM, Ngan, Robert wrote: > > Or use AD when the value is an expression. > … but not a 64-bit expression. If the value is negative, will it sign-extend? — gil 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: ltorg question
Or use AD when the value is an expression. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Tuesday, June 25, 2019 20:23 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ltorg question DS D defines a floating point field. 4110 is a normalize floating point 1. Use FD for a fixed 64-bit integer. LTORG is irrelevant. Works the same as a literal or as a DC. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman Sent: Tuesday, June 25, 2019 6:03 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ltorg question Thought it was a double word As in DS D > On Jun 25, 2019, at 9:01 PM, Mike Hochee wrote: > > Hey Joe, > > The 'D' (floating point constant type) and F (fixed point constant > type) have been around forever. Somewhere between 95-2002 IBM added the type-extension subfield to the DC instruction. As of 2004, D became a valid type-extension, which clarifies characteristics of the type, so in type-extension context, D is doubleword. ( ftp://public.dhe.ibm.com/software/websphere/awdtools/hlasm/S8164H.pdf pg 3 ) > > For fixed point type double word constants, you can use... ONE DC FD'1' > > I was surprised to stumble across this myself some years ago. > > HTH, > Mike > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Joseph Reichman > Sent: Tuesday, June 25, 2019 8:35 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: ltorg question > > I see the following literal > > > > 41101403=D'1' > > > > Shouldn't it of translated to > > 0001 > > > > And the same for -4 > > C1401406=D'-4' > > Shouldn't it of translated to > > To > > FFFC > > thanks 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: You know you've been writing assembler too long when...
O' does not need to used within a macro, nor with SETC symbols or parameters. We use it in open code (at the top of a module) to determine whether a specific macro is available in the SYSLIB concatenation. Very useful in determining whether optional features should be enabled, based on the presence/absence of feature specific macros during the assembly. Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, May 28, 2019 12:42 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: You know you've been writing assembler too long when... > O' in front of a entity is valid. Some uses are valid, but not that one. The O attribute has to be used inside of a macro, and even then it can only be used with a SETC symbol or parameter. A name that does not begin with an ampersand is neither. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of John McKown Sent: Tuesday, May 28, 2019 1:29 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: You know you've been writing assembler too long when... On Tue, May 28, 2019 at 11:27 AM Seymour J Metz wrote: > Why would I do that? O is not a valid type. You might think that it > was an attribute, but there's no ampersand in front of Halloran. > Clearly that crime book will get error messages. > O' in front of a entity is valid. It is a "Operation Code Attribute". Of course, as you pointed out, it can't be used as a plain operand of a DS instruction. https://secure-web.cisco.com/1QzufXmahzj_EwYG78xVddHD8hjgiElfIeqqH6AEVxWIel0PP3zrSswkDAemZDyUVcxs1e-e_8NiRb67s9bJR0jiFpPLj5qN_KxS2FcnbfUxIyQuI9JSq3_PAsmimQ-1c9WdHWw3xVbthg7iIU_2xbLC-W_N5i96z4iiDKGiAgmcJcqDJm7SHSTeax-tqrjpaXztyipFoMF_ZXyrC2eqmegi0iOVByeRK7oeirpoC2Mkqq2tGn8F0abfHHNGzBkLCIsOYNqe06hn5uJQFFCdzF8w9JxyhVGQMeLNSjyHBqvzn36xhRMb-2DJp9K9i1wEkRmWRWlak0NoB_Gh1Jvm5ALK42av2S0y9aaUlCWpIIb8xqiI-PIZW8qoZ6dJBENdfJ_NiFZXcQ7XI5_XRbIGIiCr2sG5tVO6k_-WOiGYsjoOFfhuJ7YtwglQKtD0n6dwj/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSENW6_1.6.0%2Fcom.ibm.hlasm.v1r6.asma400%2Fasmr1021240.htm > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown 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: Multi CPU interlock question
If you want to load two doublewords, block concurrency guarantees each (aligned) doubleword is consistent, but if task 2 is in process of updating both doublewords, using (for example) LMG may result in you loading one doubleword from before task 2's change and one after. -Original Message- From: IBM Mainframe Assembler List On Behalf Of Keven Sent: Monday, January 14, 2019 16:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Multi CPU interlock question Shouldn’t that be:Protection for readers is only necessary when the storage in question doesn’t cross a doubleword boundary? Keven On Mon, Jan 14, 2019 at 4:17 PM -0600, "Ngan, Robert" wrote: Protection for readers is only necessary when the storage in question is larger than a doubleword. For quadwords, you can use either LPQ or PLO function 3 (CLX). Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Joe Owens Sent: Thursday, January 10, 2019 04:28 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Multi CPU interlock question Yes, your illustration is exactly what I was concerned about. My instinct was CS was just about updaters of storage, and not readers, so there must be some other type of protection for readers. Thanks, Joe 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: Multi CPU interlock question
Protection for readers is only necessary when the storage in question is larger than a doubleword. For quadwords, you can use either LPQ or PLO function 3 (CLX). Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Joe Owens Sent: Thursday, January 10, 2019 04:28 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Multi CPU interlock question Yes, your illustration is exactly what I was concerned about. My instinct was CS was just about updaters of storage, and not readers, so there must be some other type of protection for readers. Thanks, Joe 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: IEATDUMP MF=L Can someone explain this?
I'm so use to splitting the name after the 3rd character I did not even notice this, until one of our younger programmers pronounced it as "I EAT DUMP" Robert Ngan HCL Technologies -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jim Mulder Sent: Sunday, August 26, 2018 00:19 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEATDUMP MF=L Can someone explain this? I suppose the way one groups the letters would be influenced by one's own habits. I would expect that experienced z/OS programmers would know that for the past few decades, new macro names follow the same convention as module names and message IDs by starting with the 3 character prefix of the owning component. IEA - component prefix T- Transaction DUMP - Dump Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY > From: "Paul Gilmartin" > <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 08/26/2018 01:07 AM > Subject: Re: IEATDUMP MF=L Can someone explain this? > Sent by: "IBM Mainframe Assembler List" > Who thinks up these macro names, anyway? That one wouldn't pass > muster as a California vanity license plate. 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: EX
Hmm, didn't think of using CRTE etc, since I was fixated on CLFITxx instructions. The immediate value is a halfword, so you can code a lot more variations of the CLFIT instruction to uniquely identify which specific instance produced the S0C7. Robert Ngan HCL P.S. I always seem to code the CLFIT instruction wrongly, since it is the only variation of the COMPARE AND BRANCH/JUMP/TRAP that requires the F, and I keep forgetting the F (although I do understand why the F was added for it). -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jonathan Scott Sent: Monday, August 6, 2018 12:20 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX Robert Ngan writes: > Not sure why no one has mentioned the COMPARE AND TRAP type > instructions, in > most(?) cases they'll do the test and force the abend when required. If you have to write product code that still works for CMS users in ESA mode, then COMPARE AND TRAP is not an option. It needs z10 or above, which I think is part of the architectural level set required by z/OS 2.2 so if you are on that level or above it is safe to use. > My only gripe is there's no extended mnemonic for an unconditional > TRAP when there's no appropriate "compare" (e.g. I need to do a TM). I've never used it myself, but I think the simplest way to code an unconditional trap is to use CRTE 0,0 or similar, using two references to the same register which are certain to compare equal. Jonathan Scott, HLASM IBM Hursley, UK 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: EX
Not sure why no one has mentioned the COMPARE AND TRAP type instructions, in most(?) cases they'll do the test and force the abend when required. My only gripe is there's no extended mnemonic for an unconditional TRAP when there's no appropriate "compare" (e.g. I need to do a TM). I had to code an unconditional trap (with mask B'1110') within a "xxxTRAP" macro since I've never memorized the condition code mask settings, and didn't want to manually code them every time I needed an unconditional trap. Robert Ngan HCL -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gord Tomlin Sent: Monday, August 6, 2018 10:57 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: EX On 2018-08-06 10:35, Ed Jaffe wrote: > We use 'Jxx *+2' which disturbs no registers and is guaranteed to fail > with an 0C1. 'EX 0,*' was my old standby, but 'Jxx *+2' eliminates the need for a code base register and so is more generally usable in modern code. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ 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: LOC=64 executable code?
Yes, I saw the IEP feature on the z14 announcement. There were severe restrictions on LOC=64 code before (mainly, must be non-interruptible) so since they added EXECUTABLE= to the LOC=64 allocation logic, I figured they might have eased up on what kind of code was allowed above the bar. So... Is the target of an EXECUTE considered to be an executable instruction if it's in EXECUTABLE=NO storage? Robert Ngan CeleritiFinTech Services -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Friday, July 28, 2017 12:07 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: LOC=64 executable code? In other words, EXECUTABLE=YES is not some new RMODE=64 feature. EXECUTABLE=NO is a new security feature. It is a guard against buffer overflow type vulnerabilities in which a bad guy sends you some message (like a Web URL) that is actually machine instructions and also manages to overlay code thus causing a branch to the instructions in the message. You can now mark storage non-executable, and the hardware will not allow a branch to it. ALL storage today is EXECUTABLE=YES. EXECUTABLE=YES is not new; EXECUTABLE=NO is new. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Russell Sent: Friday, July 28, 2017 9:43 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: LOC=64 executable code? >Date:Fri, 28 Jul 2017 00:14:46 + >From:"Ngan, Robert" >Subject: LOC=64 executable code? >Just noticed that the z/OS 2.3 manuals mention EXECUTABLE=YES|NO parameter for >IARV64 GETSTOR requests. >Anyone have a summary of what kinds of code we can move above the bar in z/OS >2.3? >Robert Ngan >CeleritiFinTech Services z14 and z/OS 2.3 support a new facility called Instruction Execution Protection (IEP) based on DAT table entry bit •RSM provides new function to request that non-executable memory be allocated •Exploitation support new EXECUTABLE=NO option on IARV64 and STORAGE •Any attempt to execute an instruction within such an area will result in a program check •Could be an indication of an attempt to violate system integrity •RTM will write LOGREC record of any program-check that results from IEP •Support will also be available for z/OS 2.2 and later running on z14 G. Tom Russell “Stay calm. Be brave. Wait for the signs” — Jasper FriendlyBear “… and remember to leave good news alone.” — Gracie HeavyHand 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.
LOC=64 executable code?
Just noticed that the z/OS 2.3 manuals mention EXECUTABLE=YES|NO parameter for IARV64 GETSTOR requests. Anyone have a summary of what kinds of code we can move above the bar in z/OS 2.3? Robert Ngan CeleritiFinTech Services 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: Quick error termination of an assembler routine (Was: Performance of Decimal Floating Point Instruction)
When using multiple EX instructions within a program to generate S0C3's, I'd
use different registers to differentiate the S0C3's.
However, with EXRL, if you use a non-zero register, and it modifies the
low-order nybble, the target instruction in no longer a EXRL!
Robert Ngan
CeleritiFinTech
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Richard Kuebbing
Sent: Thursday, May 11, 2017 13:23
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Quick error termination of an assembler routine (Was: Performance
of Decimal Floating Point Instruction)
The only issue I ever had with this is that S0C1's are common "real" abends.
On the other hand this almost never occurs:
EX 0,*
EXRL 0,*
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent: Thursday, May 11, 2017 1:44 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Quick error termination of an assembler routine (Was: Performance of
Decimal Floating Point Instruction)
What is *wrong* with DC H'0'? It has the advantage of being incredibly
straightforward. I had to spend a minute thinking about J *+2; I pretty much
guarantee you anyone with six months of HLASM experience would "get" DC H'0'.
I don't write much assembler anymore but if I did I think I might define a
bunch of error situation equates in the 0 < value < 256 range:
Blowup_no_input EQU 1
Blowup_invalid_parm EQU 2
Etc.
Then one could code
DC Y(Blowup_no_input)
And it would (a.) be somewhat self-documenting in the source code and (b.)
would more or less diagnose itself in a dump.
And if 255 were not enough codes, one could go to 16 million+ with DC
FL4(Blowup_whatever).
Frankly, I use DC H'0 very infrequently, usually only temporarily ("I can't
possibly be going through this code, could I?"). If is a "real" error then it
should have a "real" termination with messages, a return code, a user ABEND,
whatever is appropriate to the context, but something better than a
S0C1/S0C3/S0C7. Three years from now if our support crew gets a call reporting
a S0C1/S0C3/S0C7 are they going to have a clue? But if we staked out a user
ABEND number that we always used then they could go "aha!" and look up the
reason code.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Thursday, May 11, 2017 10:24 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Performance of Decimal Floating Point Instruction
On Thu, May 11, 2017 at 12:12 PM, Paul Gilmartin <
0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
> On 2017-05-11, at 06:34, Charles Mills wrote:
>
> >> If you need a way to ABEND, use the proper LE service, or an
> >> assembler
> > routine. Anything else will bite you sooner or later.
> >
> > AMEN!
> >
> No more "DC H'0'"
>
My current favorite is : J *+2 which results in a S0C1, since it is now
guaranteed that x'00' will _never_ be used as a valid opcode. It replaces my
previous favorite of: EX * which is an S0C3.
- The information contained in this
communication (including any attachments hereto) is confidential and is
intended solely for the personal and confidential use of the individual or
entity to whom it is addressed. The information may also constitute a legally
privileged confidential communication. If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this communication in
error and that any review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the contents of this
information is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail, and delete the original message.
Thank you
CSC - This is a PRIVATE message - If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
the Company 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: HLASM "Anomaly"
Hmm, Looks like we don't have PI34981 on either our z/OS 2.1 or 2.2 systems, will have to have a tale with our sysprogs. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Saturday, March 25, 2017 13:16 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" My "favorite" is the warning you get when the target of your JAS/BRAS shifts to an offset more that 64K from the instruction. You only get a ASMA320W warning (when would this not be an error?), and at execution time the truncated immediate offset branches you to some arbitrary address! Am I assembling with different options than you? I get ** ASMA223E Target of a relative immediate operand is out of range... for this program: TEST CSECT JAS 14,A DS 16XL4096 ABR 14 END Peter Relson z/OS Core Technology Design CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: HLASM "Anomaly"
My "favorite" is the warning you get when the target of your JAS/BRAS shifts to an offset more that 64K from the instruction. You only get a ASMA320W warning (when would this not be an error?), and at execution time the truncated immediate offset branches you to some arbitrary address! Thank you for BEAR! -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Boonie Sent: Friday, March 24, 2017 13:39 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM "Anomaly" One reason to implement the messages as warnings instead of errors is that warnings can be suppressed, using options like SUPRWARN, TYPECHECK, FLAG, ALIGN, USING(WARN()), and maybe others. Some of these warnings can also be suppressed "locally" using ACONTROL. I'm not aware of any errors that can be suppressed, and I suspect that that is intentional. Hopefully whatever proposal is submitted to IBM won't ask for existing warnings to be removed. - mb IBM Mainframe Assembler List wrote on 03/24/2017 11:17:02 AM: > From: Charles Mills > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Date: 03/24/2017 11:18 AM > Subject: Re: HLASM "Anomaly" > Sent by: IBM Mainframe Assembler List > > > Apologies for the late reply. Outlook thought this was SPAM. > > Warnings are not much better or different than errors. It sounds great to > say "issue a warning" but the fact is that then the programmer has to either > (a.) live with and ignore RC=4 for the life of the project; of (b.) change > the code. If the former then why issue the warning at all; if the > latter then it is no better or different than an error. I think > warnings in this > situation are kind of wishy-washy: either it's wrong or it's not. I > get the > difficulty in deciding whether LHI 0,X'' is wrong or not, but > saying it > is half wrong (4 rather than 8) is just bailing on the decision. > > Charles CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Transactional Execution - anybody used it?
I looked into it, but we don't have the appropriate h/w so I can't play with it yet. The unconstrained version may always fail, so you need to always create a non-transactional version of the code just in case (so this doubles your coding effort). The only immediate use I could think of for this facility would be in STAE code to check dereferencing of potentially corrupted pointers without the overhead setting up another SPIE/STAE. Robert -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Friday, March 03, 2017 09:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Transactional Execution - anybody used it? I *considered* it for a problem of updating a queue in a multiprocessor reentrance situation. I ended up solving the problem with CSST which seemed like a simpler approach. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Friday, March 3, 2017 6:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Transactional Execution - anybody used it? OK, I guess I asked my question poorly. And I should not have said anything about the PLO (instruction, not Mid-East organization) So. Has anyone on this forum actually used the TBEGIN and TEND instructions in their code? I would appreciate knowing what / why they chose to do so. I'm just trying to understand the real purpose of these instructions on a PRACTICAL level. Yes, I've read up on "Transactional Memory" on the web. And how it allows "atomic updates". But I would like a real world example of why use this vs. the older "atomic" instructions (TSET, CS, CDS, PLO, etc). CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Transactional Execution - anybody used it?
The " Compare and swap and double store" function of PLO? -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John McKown Sent: Thursday, March 02, 2017 15:32 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Transactional Execution - anybody used it? I'm just curious. I don't, personally, have any need for it at present. I can envision some need for it, such as "atomically" incrementing one variable by some amount and decrementing another by that same amount (like DB2 does within an SQL transaction). Or maybe updating a double linked list to remove a node. I tried to see if there were any Redbooks about it, but my searches didn't find anything. -- "Irrigation of the land with seawater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion Maranatha! <>< John McKown CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: HLASM anomaly
I was interested in the top half of the fullword, your equates give me the bottom half, which I do not need to do anything special for since HLASM truncates the value correctly when used directly on the MVHHI instruction. However, I can use your code to strip the low order half off the value before dividing by 65536, which resolves my issue of the value being potentially "off by one" when a negative value is divided. &M1 SETC '(&IMM-((&IMM)/65536)*65536)' &M2 SETC '(&M1+65536)-(&M1+65536)/65536*65536' &M3 SETC '(&IMM-&M2)/65536' PUSH ACONTROL,PRINT,NOPRINT PRINT NOGEN,NOPRINTSuppress printing of following ACONTROL ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages POP PRINT,NOPRINTPrint following instructions MVHHI &TO+0,&M3Set first half of fullword MVHHI &TO+2,&IMM Set second half of fullword POP ACONTROL,NOPRINT The example "expression" I was messing with was actually SAVF4SAID_VALUE (i.e. C'F4SA') which when divided by 65536 gives C'F5' instead of C'F4'. However &M3 above generates the expected value. Robert -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 01, 2017 20:40 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-01, at 17:35, Ngan, Robert wrote: > I noticed the new COBOL compiler was generating: > > MVHHI target,0 > MVHHI target+2,48000 > > instead of: > > MVC target,=F'48000' > > and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal > even when the top half of the value is non-zero. The assembler happily > accepts: > > MVHHI target+2,C'abcd' > > truncating the leading 'ab', but I gave up since I could not determine how to > consistently obtain the top half of the value when it is a general > (resolvable at assembly) expression, ... > How about, with the miracle of integer arithmetic: ABCD EQU c'abcd' Then (best done in a macro): DEN EQU 65536 M1.SYSNDX EQU ABCD-ABCD/DEN*DEN M2.SYSNDX EQU (M1.SYSNDX+DEN)-(M1.SYSNDX+DEN)/DEN*DEN MVHHI target,(ABCD-M2.SYSNDX)/DEN I believe this is safe against oveflows, but I haven't proven it formally. -- gil CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: HLASM anomaly
I noticed the new COBOL compiler was generating: MVHHI target,0 MVHHI target+2,48000 instead of: MVC target,=F'48000' and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal even when the top half of the value is non-zero. The assembler happily accepts: MVHHI target+2,C'abcd' truncating the leading 'ab', but I gave up since I could not determine how to consistently obtain the top half of the value when it is a general (resolvable at assembly) expression, except by doing: MVHHI target,0 ORG *-2 DCA(expression) ORG *-2 MVHHI target+2,expression HLASM need logical shift operations to avoid requiring ORG/DC/ORG in the generate code. Robert Ngan -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 01, 2017 11:54 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-01, at 10:00, Charles Mills wrote: > For sure! It's not a problem I lose sleep over -- perhaps because my > primary language is now C++, no longer assembler. > > I don't recall ever thinking about the issue until it came up on this list. > > I'm a "design elegance" guy. It would please me if there were a single > expression processor such that the syntax of immediate operands and of > DC's of the same length were the same. > What lengths do you want? There are: DCAL1(expression) 1 byte; unsigned DCY(expression)2 bytes; signed DCA(expression)4 bytes; signed Does HLASM issue any operand range warnings for any of LLI[HL][FHL]? Is this implied by the PoOps "The condition code is unchanged." Or, does HLASM simply ignore bits 0-15 of the immediate operand expression? Is this documented? -- gil CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: HLASM anomaly
I've tried using SETA functions directly as instruction operands, doesn't work. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, February 27, 2017 18:56 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly Maybe a little less of a kludge using SETA arithmetic function SLL, but maybe not: LCLA &IIHFARG &IIHFARG SETA SLL(X'01', 16)+X'2345' IIHF R00,&IIHFARG Being able to code the SETA argument in the instruction would be nicer: IIHF R00, SLL(X'01', 16)+X'2345' Have not tried either of those in an actual assembly yet, just guessing here. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ngan, Robert Sent: Monday, February 27, 2017 5:45 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly The ability to specify: IIHF R00,H'12345,0' to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would be useful. Kludge for this is: IIHF R00,12345*65536 which is ugly, while: IIHL R00, 809041920 is even uglier! Robert Ngan -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Saturday, February 25, 2017 11:24 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.) and data types (B, X, C), which definitely adds to the confusion. C (and its derivatives) makes more sense in this regard. OTOH, C does have the interesting feature that the size of ints (and shorts and longs) and pointers can vary. PL/I might have the best model, but I haven't done any serious work with it in many years. sas On 2/25/2017 11:42, Charles Mills wrote: > Another way of looking at things is that X' serves two different roles in the > assembler syntax. I became aware of this when I moved from a long career > writing assembler to C++ as my primary language. > > X' signifies (a.) that the constant that follows is in hexadecimal notation > and (b.) a unit of storage, a byte. > > Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). > Consider the contrast with H' which is only a unit of storage. You can say DC > H'23' but you would not expect to be able to code LHI 0,H'23'. So, similarly, > you can code DC 2X'23' but not LHI 0,2X'23' > > FWIW and OT, C/C++ separates the two functions. 0x23 represents only the > quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly > analogous to LHI) but if you want to define storage, you must explicitly > state the unit of storage that you are defining: char foo = 0x23 or short foo > = 0x23 (roughly equivalent to FOO DC X'23' and FOO DC H'35' respectively). > > Charles > > CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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. 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. CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: HLASM anomaly
The ability to specify: IIHF R00,H'12345,0' to insert 12345 into bytes 0-1, and zero into bytes 2-3 of register would be useful. Kludge for this is: IIHF R00,12345*65536 which is ugly, while: IIHL R00, 809041920 is even uglier! Robert Ngan -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Saturday, February 25, 2017 11:24 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly Exactly. HLASM is inconsistent in conflating storage types (F, H, etc.) and data types (B, X, C), which definitely adds to the confusion. C (and its derivatives) makes more sense in this regard. OTOH, C does have the interesting feature that the size of ints (and shorts and longs) and pointers can vary. PL/I might have the best model, but I haven't done any serious work with it in many years. sas On 2/25/2017 11:42, Charles Mills wrote: > Another way of looking at things is that X' serves two different roles in the > assembler syntax. I became aware of this when I moved from a long career > writing assembler to C++ as my primary language. > > X' signifies (a.) that the constant that follows is in hexadecimal notation > and (b.) a unit of storage, a byte. > > Thus you can say LHI 0,X'23' (role a.) or DC X'23' (roles a. and b.). > Consider the contrast with H' which is only a unit of storage. You can say DC > H'23' but you would not expect to be able to code LHI 0,H'23'. So, similarly, > you can code DC 2X'23' but not LHI 0,2X'23' > > FWIW and OT, C/C++ separates the two functions. 0x23 represents only the > quantity 23 base 16, not a unit of storage. You can say foo = 0x23 (roughly > analogous to LHI) but if you want to define storage, you must explicitly > state the unit of storage that you are defining: char foo = 0x23 or short foo > = 0x23 (roughly equivalent to FOO DC X'23' and FOO DC H'35' respectively). > > Charles > > CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Test of List
2010? -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Thompson Sent: Thursday, October 06, 2016 07:40 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Test of List The last email I've gotten from the list was 10JUN2010. Is this list still working? Regards, Steve Thompson CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Friday puzzle: CNOP 1,2
Hmm, there's always something new to learn with the assembler. I've never encountered the boundary and offset operands of ORG. That's useful to know for future coding. The only thing that ORG doesn't do vs. DC is emit the potential filler byte. Is uninitialized csect/rsect storage still an issue we should be concerned about? -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jonathan Scott Sent: Tuesday, August 23, 2016 05:36 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Friday puzzle: CNOP 1,2 Ref: Your note of Tue, 23 Aug 2016 10:52:13 +0100 OK, I've spotted why I used the more complex format: ORG*+&BOUNDARY-&OFFSET,&BOUNDARY,&OFFSET-&BOUNDARY instead of ORG*-&OFFSET,&BOUNDARY,&OFFSET If you use the simpler form too close to the start of a section, so that the first operand goes negative, you get an error: ASMA038S Operand value falls outside of current section/LOCTR Jonathan Scott IBM Hursley, UK CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Friday puzzle: CNOP 1,2
I was trying to avoid generating an extra filler byte when one was not required. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robin Vowels Sent: Friday, August 19, 2016 20:18 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Friday puzzle: CNOP 1,2 From: "Ngan, Robert" Sent: Saturday, August 20, 2016 4:47 AM I'm writing a macro to build length prefixed character strings. The length is one byte, and the actual string is referenced by LARL so it needs to be halfword aligned. So I coded (what would be a CNOP 1,2 - if it was valid): DC(1-(*-&SYSECT)/2)X'00' Simulate a CNOP 1,2 However, this generates ASMA067S Illegal duplication factor. what's wrong with DS 0H followed by DC X'00' or some such? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Friday puzzle: CNOP 1,2
I went with Tony's modulo/remainder logic (which is what I was trying to code in the first place), as it is more compact. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, August 19, 2016 18:53 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Friday puzzle: CNOP 1,2 On 2016-08-19 16:01, Ngan, Robert wrote: > I wanted the length aligned on the odd byte, so the immediately following > (labeled) string was on a halfword boundary and could therefore be referenced > using a LARL. > How about: DSCAllow at least one byte DS0H Pad to even boundary ORG *-1 Back up to odd boundary. -- gil CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Friday puzzle: CNOP 1,2
I wanted the length aligned on the odd byte, so the immediately following
(labeled) string was on a halfword boundary and could therefore be referenced
using a LARL.
Just realized my expression was doing DIVISION by 2 instead of the MODULO 2 I
wanted.
I was calling it a (conceptual) CNOP, since it was an attempt to force
alignment on one boundary within another boundary. I sometimes use CNOP within
dsects to do this.
Thanks for spotting the [now obvious] flaw in my code.
Robert Ngan
CeleritiFinTech Services
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Harminc
Sent: Friday, August 19, 2016 15:31
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Friday puzzle: CNOP 1,2
On 19 August 2016 at 14:47, Ngan, Robert wrote:
> I'm writing a macro to build length prefixed character strings. The
length is one byte, and the actual string is referenced by LARL so it needs to
be halfword aligned.
The string needs to be halfword aligned, or the length byte does?
> So I coded (what would be a CNOP 1,2 - if it was valid):
I don't see how CNOP comes into this. CNOP (Conditional No OPeration) is used
to pad an instruction stream with NOPRs (X'0700'); it makes no sense for data.
(Not that it's *wrong* to generate unneeded 0700s, but that's why there is no
sense to CNOP 1,2.)
> DC(1-(*-&SYSECT)/2)X'00' Simulate a CNOP 1,2
>
> However, this generates ASMA067S Illegal duplication factor.
You're on the right track here, I think, but I think your calculation is not
quite right.
How about:
DC(1-((*-&SYSECT)-(*-&SYSECT)/2*2))X'00'
Or just use DS:
DS(1-((*-&SYSECT)-(*-&SYSECT)/2*2))X
Or you could use something similar with an ORG.
I'm not clear if you want the length to be generated as a byte before the data
(on the odd boundary), and if so where the label should be. This seems to
produce reasonable results, assuming you want the label on the halfword aligned
data:
TEST CSECT
PRINT DATA
MACRO
&nameCSTRING &data
&dat SETC DEQUOTE('&data')
&len SETA DCLEN('&dat')
DS(1-((*-&SYSECT)-(*-&SYSECT)/2*2))X
DCFL1'&len'
&nameDCC'&dat'
MEND
DataACSTRING 'Some data'
DataBCSTRING 'Some more data'
DataCCSTRING '12345'
DataDCSTRING '1234'
DataECSTRING '1'
DataFCSTRING NoQuotes
DataGCSTRING 'O''Connor'
END
This is somewhat but not completely robust wrt the operand - it can be quoted
or not as you like. Of course if you want the label on the odd-byte-aligned
length byte, just move it. You could also do tricks to give the label the right
length attribute.
&nameEQU *,&len+1
would give it the length of the string plus the length byte. etc. etc.
Tony H.
CSC - This is a PRIVATE message - If you are not the intended recipient,
please delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to bind
the Company 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.
Friday puzzle: CNOP 1,2
I'm writing a macro to build length prefixed character strings. The length is one byte, and the actual string is referenced by LARL so it needs to be halfword aligned. So I coded (what would be a CNOP 1,2 - if it was valid): DC(1-(*-&SYSECT)/2)X'00' Simulate a CNOP 1,2 However, this generates ASMA067S Illegal duplication factor. Yes, I could use LAY instead of LARL, or I could use an aligned halfword length (which is what I've ended up doing for now). However, for curiosity's sake, does anyone know of a technique for forcing alignment to the next odd byte (i.e. a theoretical CNOP 1,2)? Robert Ngan CeleritiFinTech Services CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Generating warning for AL2 expression truncation?
For non-relocatable values, the range of Y values is the same as a signed halfword. In my case, I want unsigned values so I can't use Y. I ended up coding: DCAL2(expr) DS0XL(65536-expr) ASSERT: expr was not truncated -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert Netzlof Sent: Saturday, March 26, 2016 11:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Generating warning for AL2 expression truncation? On 3/26/16, Steve Smith wrote: > Well, it seems to me that the lack of any message on the AL2 is a bug. > > Correct me if I'm wrong, but I think Y-cons are signed... H type constants, yes. Y type constants, no. They are address constants, addresses cannot be negative. They date from the dawn of time, when there were 32K and smaller 360's abroad in the land. -- Bob Netzlof a/k/a Sweet Old Bob CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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.
Generating warning for AL2 expression truncation?
I had a program that was generating a (non-relocatable) value larger than 65535 within an AL2 constant, and it's being silently truncated. A (brief) look at the manuals did not reveal any options for flagging this type of error. Did I miss something, or is there no way to flag this condition? Robert Ngan CeleritiFinTech CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: Return code 8 from assembler no messages
Would PRINT OFF suppress error messages too? -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Ehrman Sent: Thursday, February 11, 2016 17:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Return code 8 from assembler no messages Michael Butz wrote: >I am sorry i had multiple definitions of IBM Mapping macros IHAPSA >IHAASCB >Wonder why it didn't flag it as ** previously defined It should; otherwise there's no way to locate the problem. CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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: load logical halfword immediate
IILF with an immediate value less than 65536 does what you want, and would be my choice. Robert Ngan CeleritiFinTech -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John P. Hartmann Sent: Wednesday, January 20, 2016 1:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: load logical halfword immediate sr x,x icm x,3, address On 01/20/2016 08:21 PM, Swarbrick, Frank wrote: > Is there any such instruction? This would be an instruction that would: > > - Be a register-and-immediate instruction, with a halfword immediate > value as the source. > > - Load the halfword in bytes 48-63. > > - Load zeroes in bytes 32-47. > > - Leave bytes 1-31 unchanged. > > I can't find anything that will do exactly this. > Why do I want to do exactly this? I "just do", and it bugs me I can't find a > single instruction to do it. > > I don't want LLILL because it sets bytes 1-47 to zero. > I don't want IILL because it does not set 32-47 to zeroes (yes, I could > follow the IILL with IILH Rx,0). > I don't want IILF because it uses a fullword immediate value instead of a > halfword immediate value. > I don't want LHI because it sign extends. > LA could almost be used, except it allows a value of "3/4s of a halfword". > LLH does exactly what I want, except that it's register-and-storage, not > register-and-immediate. > > In the end is it really a big deal? No; but I'm obsessing about it, thinking > I'm just overlooking it. Probably I'll use either LLILL or IILF, depending > on if I really care about bits 1-31 (which I don't really...). > > Thanks for putting up with this perhaps silly inquiry! > > Frank CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company 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.
