Re: Provenance of term "yonder"?
Shmuel, all, when the first long-displacement instructions were published the meaning of the Y in the associated mnemonics was not disclosed. On my site I chose to have have it stand for "Yonder" I'm not a native speaker of English (nor American) yet I knew the word from the works of Tolkien :-) Anyway - it is quite likely that I would not have been the only one (or even the first one) to have coined this bit of word-mongery. I was once told (by an IBM-er) they took it from me. Although the idea is flattering, I have some misgivings... At the time it was rumored that the IBM architects had been looking for a letter that had a very low frequency in the extant base of mnemonics. It seemed to make sense to try avoiding creation of ambiguities or even clashes. The Y obviously matched their search criteria. Whether the word Yonder played a role in their decision will probably remain a mystery forever. Kind regards & Happy programming, Abe Kornelis == Op 01/07/2024 om 12:55 schreef Colin Paice: > Good King Wenceslas first looked out, on the feast of Stephens... > *Yonder* peasant, who is he? > Where and what' his dwelling?" > "Sire, he lives *a good league hence* > Underneath the mountain > Right against the forest fence > By Saint Agnes' fountain > > On Mon, 1 Jul 2024 at 11:37, Seymour J Metz wrote: > >> Is the use of "yonder" to designate instructions with long displacements >> official IBM nomenclature? What is its provenance? >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> עַם יִשְׂרָאֵל חַי >> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
Re: strange macro issue.
Tony,
Remove the from the ZDCB invocation.
Despite the error the label is probably defined to HLASM.
If that does not resolce it, then I'd check the symbol cross reference
to see where the prior definition of SYS020 occurred.
Set PRINT option to make sure that line is printed and check which macro
generated it.
Success!
Abe
===
Op 15/06/2024 om 06:15 schreef Tony Thigpen:
> I have a macro that is giving strange results, so I must be doing
> something wrong.
>
> The macro is used so that I can easily port z/VSE and z/OS code
> between the two operating systems. It was working until I needed to
> handle operands that are null.
>
> MACRO
> Z@DCB =,=,=,=, BOTH X
> =,=,=, Z/OS X
> =,=,=0, VSE X
> = JUNK
>
> .DCBZOS ANOP
> SETC 'DDNAME='
> SETC ',RECFM='
> SETC ',DSORG='
> SETC ',LRECL='
> SETC ',BLKSIZE='
> SETC ',EODAD='
> SETC ',MACRF='
> AIF ('' NE '').RFM
> SETC ''
> .RFM ANOP
> AIF ('' NE '').DORG
> SETC ''
> .DORG ANOP
> AIF ('' NE '').LREC
> SETC ''
> .LREC ANOP
> AIF ('' NE '').BLKS
> SETC ''
> .BLKS ANOP
> AIF ('' NE '').EOD
> SETC ''
> .EOD ANOP
> AIF ('' NE '').MAC
> SETC ''
> .MAC ANOP
> SETC ''
>
> ZDCB
> DCB
>
>
> The two identical lines with ZDCB and DCB are just so that the first
> one prints (with an error) before the second one attempts to work.
>
> My first example is really stripped down:
> SYS020 Z@DCB MACRF=E,DDNAME=SYS020,DTF=NO
>
> The assembly reports:
>
> 1202+***
> 1203+SYS020 ZDCB
> DDNAME=SYS020,MACRF=E
> ** ASMA057E Undefined operation code - Z@DCB/ZDCB
> ** ASMA435I Record 120 in SYS1.PROZ.COPYLIB(Z@DCB) on volume: RESCUG
> ** ASMA254I *** MNOTE *** 1207+ 12,*** IHB052 DSORG
> OMITTED
> ** ASMA254I *** MNOTE *** 1209+ 12,*** IHB066
> INCONSISTENT OPERANDA
> 00081C 1210+SYS020 DS 0F GENERATED TO
> DEFINE NAME
>
> Yet, just for testing, I also coded a basic DCB that is identical to
> waht the macro is generating, and it works.
>
> 1212 SYS020 DCB
> DDNAME=SYS020,MACRF=E
> 1215+* DATA
> CONTROL BL
> 1216+*
> 00081C 1217+SYS020 DS 0F'0' ORIGIN ON
> ** ASMA043E Previously defined symbol - SYS020
> no other errors on the usage of DCB.
>
> I assume that I must be hitting some quirk in how macros work when
> generating parms for another macro.
>
>
> Tony Thigpen
Re: Current list of extended mnemonics?
Shmuel, how about https://bixoft.nl/english/oplist.htm I think what you are asking for is: https://bixoft.nl/english/opl_cnxm.htm You can toy with the selectors at the top of the page to get what you need. I hope you'll enjoy as much as I did when creating the generator. (I'm way too lazy to do maintain all those lists by hand) Kind regards, Abe === Op 11/06/2024 om 16:29 schreef Seymour J Metz: >> are the old names > What I really want is a single alphabetical table that contains all of the > mnemonics for instructions valid on Z. That's in addition to the current > table, not in place of it. > >> CONCS and DISCS > Now that's a blast from the past! > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Assembler List on > behalf of Jonathan Scott > Sent: Tuesday, June 11, 2024 7:26 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Current list of extended mnemonics? > > Shmuel (Seymour J.) Metz writes: >> A lot but not all :-( > As far as I can see (using a program to compare appendix J with > the table that I recently added to the HLASM Programmer's Guide) > the only extended mnemonics omitted from Appendix J are the old > names for instructions that have been renamed or extended: > > ADTR AXTR CDFBRCDGBRCDGTRCEFBRCEGBR > CFDBRCFEBRCFXBRCGDBRCGDTRCGEBRCGXBR > CGXTRCUTFUCUUTFCXFBRCXGBRCXGTRDDTR > DXTR FIDBRFIEBRFIXBRLDXBRLEDBRLEXBR > LRDR LRER MDTR ME MER MXTR PPNO > SDTR SXTR TMH TML > > I also note that my table has two spurious "extended mnemonic" > indications, in that the program to generate it found that > mnemonics CONCS and DISCS within OPTABLE(UNI) are marked not to > be used during disassembly but they have the same hex opcodes as > LBEAR and STBEAR, so it assumes they were extended mnemonics for > them. When new instructions were created for the same opcodes, > it seemed unnecessary to remove CONCS and DISCS from the UNI > table as that could in theory still be useful for reassembling > ancient 370 code, but it has caused that weird side-effect. > I don't want to update the table manually to fix that, but I > may modify the program in future to spot that the opcode is > no longer current so it cannot be an extended mnemonic for a > current instruction. > > Jonathan Scott, HLASM > IBM Hursley, UK
Re: Testing a vector register for low-values
Robert, thanks for sharing. That is really useful information! Kind regards, Abe Kornelis == Op 07/06/2024 om 23:59 schreef Ngan, Robert (DXC Luxoft): > 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: Table of all instructions supported by HLASM
Jonathan, I noticed that instructions specific to the 360/20 (e.g. HPR SPSW TIOB CIO XIO) are not included in the overview. I cannot really blame you - it is complex enough as it is... For the sake of curiosity: are there any other model-specific instructions that do not appear in the list you compiled? Thanks in advance, Abe === Op 01/06/2024 om 10:30 schreef Jonathan Scott: > A table of all 2678 instructions currently supported by HLASM > has now been added as a new appendix to the HLASM Programmer's > Guide (both in the HTML form and PDF). It includes information > about operand syntax, base instructions for extended mnemonics, > the ranges of OPTABLEs to which that instruction applies, the > instruction format, the hexadecimal opcode and the descriptive > name of the instruction. > > https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=guide-index-supported-instructions > > This took longer than expected because we had problems fitting > the information into the PDF version of the table without > getting operands or instruction names split within words. > However, our helpful writer has managed to fix most of the > layout problems and has added zero-width spaces so that operand > splits should only occur between operands. > > This table is generated by a program from the HLASM instruction > tables, where most of the descriptive instruction names are > derived from appendix B.2 of the z/Architecture Principles of > Operation. We therefore hope it should be practical to continue > to maintain it to include any future new instructions. > > Jonathan Scott, HLASM > IBM Hursley, UK
Re: Table of all instructions supported by HLASM
Jonathan, great work. Looks good. I love this :-) Abe === Op 01/06/2024 om 10:30 schreef Jonathan Scott: > A table of all 2678 instructions currently supported by HLASM > has now been added as a new appendix to the HLASM Programmer's > Guide (both in the HTML form and PDF). It includes information > about operand syntax, base instructions for extended mnemonics, > the ranges of OPTABLEs to which that instruction applies, the > instruction format, the hexadecimal opcode and the descriptive > name of the instruction. > > https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=guide-index-supported-instructions > > This took longer than expected because we had problems fitting > the information into the PDF version of the table without > getting operands or instruction names split within words. > However, our helpful writer has managed to fix most of the > layout problems and has added zero-width spaces so that operand > splits should only occur between operands. > > This table is generated by a program from the HLASM instruction > tables, where most of the descriptive instruction names are > derived from appendix B.2 of the z/Architecture Principles of > Operation. We therefore hope it should be practical to continue > to maintain it to include any future new instructions. > > Jonathan Scott, HLASM > IBM Hursley, UK
Re: IEABRC anomaly
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 > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > 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: ASMA043E Previously defined symbol
Charles, all, That type of error also occurs within HLASM when it is processing macro code. some errors are caught only if the pertinent statement is actually executed. It hit me so many times that we implemented a non-compatible feature in z390 to do a better job at early error detection. I have liked using that feature very much. Kind regards & happy programming! Abe === Op 01/05/2024 om 20:17 schreef Charles Mills: > Well, and it is a feature of interpretive execution. When you branch to a > label, it looks until it finds that label. It doesn't keep looking to see if > there is another. (Yes, it could and might, but it would take time, and it > doesn't.) > > It's an example of something I dislike about both Rexx and Python: errors > that would be caught in compilation in other languages are not caught until > you hit them, perhaps at oh-dark-thirty at a customer site. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Phil Smith III > Sent: Wednesday, May 1, 2024 10:00 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: ASMA043E Previously defined symbol > > Paul Gilmartin wrote, re Rexx being fine with duplicate labels: >> That's bad. > That's WAD. Remember, the goal of Rexx was ease of use. Just sayin'.
Re: ASMA043E Previously defined symbol
Joao, From a theoretical standpoint you are probably right. A duplicate definition could be flagged as a warning, and an error message could be issued only when referencing it. But this would not work for labels that are externalized. Also, when producing/using Adata it would cause confusion. And finally, the assembler simply was not built to work like that. I *think* ( I cannot be sure) the internal symbol table has no option to store conflicting definitions. So it simply marks any conflict as an error without updating that table. I agree that is would be possible to differentiate between a warning-level duplicate and an error-level duplicate. Yet from a practical standpoint there is zero reason to do so. If you really, really want to pursue this, you are free to clone the z390 open-source assembler and modify it to suit your needs. https://github.com/z390development/z390 Kind regards, Abe Kornelis == Op 01/05/2024 om 12:56 schreef João Reginato: > I can't see it as an additional code if it is already checking the > duplicates. It could only show an error where/when/if the duplicated field > is referenced. Simple > > Em qua., 1 de mai. de 2024, 07:20, Steve Smith escreveu: > >> Because it's an error whether referenced or not. Why should the assembler >> add additional code to check that symbol isn't referenced? >> >> I don't understand your last statement. >> >> sas >> >> On Wed, May 1, 2024 at 11:43 AM João Reginato >> wrote: >> >>> Ok, I understand your point of view. But why show the duplicate as an >>> error if it is not referenced anywhere? It could be an error just in the >>> references. >>> >>>
Re: Decimal Floating Point Numbers
Gary, As Gary Peskin and Tony Harminc have pointed out, the sequence of bits is the same, and the 'value' is the same too. Please see my prior email with examples to validate that the value 7 encoded in either LUV or RUV eventually ends up having the exact same sequence of bits. Which underscores that the view chosen is no more than an aid in understanding the numbers your program is using. As I've come to understand, it makes no sense to have an option to request LUV or RUV since the bit sequence would be the very same. And no, RUV/LUV is not an HLL thingy. It is an additional layer of complexity added into the PoP to confuse us mere mortals :-) Kind regards & Happy programming! Abe === Op 06/03/2024 om 19:02 schreef Gary Weinhold: > This reminds me in a way of number representation in COBOL. The PICTURE > allows you to place the implicit decimal point anywhere, which will afftect > the display of the number, but internally there is just a fullword, or packed > decimal or halfward, etc. So the programmer choses whether to display, for > example, $12345.67 (dollars and cents) or 1234567 pennies or 12.3 Thousands > of dollars. > > Where do you get to indicate whether you want LUV or RUV? Is it part of the > convert to zoned decimal or is it an convention that an application agrees > on? I can see what it is but I can't see how I can request one or the other > in assemlber language. Or is an HLL concept that some asembler subroutine > implements for the HLL? > > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, you > are not authorized to use or disclose this information, and we request that > you notify us by reply mail or telephone and delete the original message from > your mail system. > > > > From: IBM Mainframe Assembler List on > behalf of Gary L Peskin > Sent: March 6, 2024 11:30 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Decimal Floating Point Numbers > > Thanks, Abe. I'm glad I was able to help. I don't really understand why they > started with this whole LUV/RUV thing anyway. They could have just picked one > and said that that's the representation and left it at that (no pun > intended!). But I guess that wouldn't have been confusing enough. > > Take care, > Gary
Re: Decimal Floating Point Numbers
Gary, thanks for explaining. I had to enumerate the options to get to understand it... When encoding 7 with LUV, the decimal point is always after the first digit. Within the cohort, there are - as you mentioned - various members: 7.00E0 - Biased Exp = 95 0.70E1 - Biased Exp = 96 0.07E2 - Biased Exp = 97 0.007000E3 - Biased Exp = 98 0.000700E4 - Biased Exp = 99 0.70E5 - Biased Exp = 100 0.07E6 - Biased Exp = 101 When encoding 7 with RUV, the decimal point is always after the last digit. Within the cohort, there are - again - various members. E.g. 007E0 - Biased Exp = 101 070E-1 - Biased Exp = 100 700E-2 - Biased Exp = 99 0007000E-3 - Biased Exp = 98 007E-4 - Biased Exp = 97 070E-5 - Biased Exp = 96 700E-6 - Biased Exp = 95 Which clearly shows that in the encoded format the RUV vs LUV is not relevant. Thanks a lot for helping me understand. Kind regards, Abe === Op 05/03/2024 om 18:19 schreef Gary L Peskin: > But you need to look at the bias for the exponent. Both views would be > encoded the same. I guess I didn't explain this very well before but this > example will help. For the short format, there are 7 significant digits. > For the LUV, bias of the exponent is 95. For the RUV, bias of the exponent > is 101. See this in figure 20-2 that we mentioned before. > > Also, I think we're getting cohorts mixed up with LUV/RUV. What you're > showing below are two different members of a cohort. Not too different views > of the same representation. But that's another story. I think you'll see what > I mean below. > > Let's take the number 7. This can be encoded with the LUV as 7.00 x > 10**0 or as 700. x 10**-6. In both cases the significand is represented > the exact same as 700. For LUV, the decimal point is implied to the > right of the seven. For RUV, the implied decimal is to the right of the > rightmost zero. > > For LUV, the unbiased exponent is 95 since 95 - 95 = 0. > For RUV, the unbiased exponent is 95 since 95 - 101 = -6. > > So in BOTH cases, the unbiased exponent (which is what is encoded in the > representation in memory) is 95. And in both cases the significand is encoded > as 700. The representation in memory is the SAME. It's just a matter of > whether you want to look at as > > 7.00 x 10 * (95-95) > -or- > 700 x 10 * (95-101) > > I hope this example helps. > > Take care, > Gary > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Abe Kornelis > Sent: Tuesday, March 5, 2024 8:58 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Decimal Floating Point Numbers > > Hi Peter, > > thanks for your response. Nice to hear from you :-) > > They would be encoded quite differently. > Say you'd encode the value seven. > In LUV this would be 7.0*10**0 > In RUV this would be 07*10**0 > > In either case the number of zero digits would depend on the format of the > DFP: D/E/X > > For the sake of completeness: > In LUV the digit 7 would go into the combination field In RUV the digit would > be at the end of the significand. > > Unless I am quite mistaken, which is still quite conceivable :-( > > Kind regards, > Abe > === > > > Op 05/03/2024 om 15:19 schreef Peter Relson: >> I am imagining (and could easily be wrong) that the hex data is identical >> across the views (and thus the instruction implementation does not care >> about the view), and it's only a question of which bits you choose to look >> at (or what arithmetic logical manipulation you use) if formatting the value >> for human consumption. >> >> For example, the exponent differs, as does the significand (a term I had not >> known of until seeing it in the POp). >> >> I don't know what kind of dump was being looked at, but perhaps there's a >> formatting option within the dump viewing program that might say "show me >> this as a Right-Unit View DFP value". >> >> Peter Relson >> z/OS Core Technology Design
Re: Don Higgins has retired from z390 development again
Don, We've worked together for over 20 years with on z390. I have always appreciated your kind patience and your responsiveness when issues were uncovered. I hope you will enjoy your retirement for a while. Family, friends, and all other things you might want to do. Thank you for your kindness, your friendliness, and for all the years of cooperation. And thank you for creating and sharing z390. May you have many more years in good health! We'll miss you - we'll think of you. Kind regards, Abe === Op 05/03/2024 om 21:45 schreef d...@higgins.net: > > *All* > > * * > > *I have retired again from z390 development after having survived > esophageal cancer, kidney cancer, and thyroid cancer over the past 2 > years. All my scans are now clear of cancer, and I feel well again. > So at 79 I’m planning to spend more time with my wife Charlotte > traveling and relaxing.* > > * * > > *I will miss working with the current z390 core development team: Abe > Kornelis, John Ganci, and Anthony Delosa, and hope they will continue on.* > > * * > > *I also miss working with Melvyn Maltz and John Ehrman who supported > z390. Melvyn developed the z390 CICS emulation, and John invited me > to present z390 at several SHARE sessions.* > > * * > > *For those interested in learning more about z390, the current > development site is here: https://github.com/z390development/z390 * > > * * > > *The original website I maintained from 2004 until 2012 when I turned > it over to Abe is here: https://z390.org/* > > * * > > *All z390 code is written in J2SE Java and is open source. * > > * * > > *The purpose of z390 is to help those interested in learning, > developing, and executing mainframe assembler programs on Windows and > Linux.* > > * * > > Don Higgins > > d...@higgins.net > > www.donhiggins.org <http://www.donhiggins.org> > > >
Re: Decimal Floating Point Numbers
Hi Peter, thanks for your response. Nice to hear from you :-) They would be encoded quite differently. Say you'd encode the value seven. In LUV this would be 7.0*10**0 In RUV this would be 07*10**0 In either case the number of zero digits would depend on the format of the DFP: D/E/X For the sake of completeness: In LUV the digit 7 would go into the combination field In RUV the digit would be at the end of the significand. Unless I am quite mistaken, which is still quite conceivable :-( Kind regards, Abe === Op 05/03/2024 om 15:19 schreef Peter Relson: > I am imagining (and could easily be wrong) that the hex data is identical > across the views (and thus the instruction implementation does not care about > the view), and it's only a question of which bits you choose to look at (or > what arithmetic logical manipulation you use) if formatting the value for > human consumption. > > For example, the exponent differs, as does the significand (a term I had not > known of until seeing it in the POp). > > I don't know what kind of dump was being looked at, but perhaps there's a > formatting option within the dump viewing program that might say "show me > this as a Right-Unit View DFP value". > > Peter Relson > z/OS Core Technology Design
Re: Decimal Floating Point Numbers
Hi Gary, Thanks for the PoP quote. I must have missed that one. Otherwise, I roughly got as far as you did. One can move the (virtual) decimal point at will, provided you adjust the exponent value accordingly. When e.g. adding two DFP numbers, the LUV vs. RUV does not seem to matter - the addition results are the same in either case. When adding a RUV-encoded value to a LUV-encoded value the addition is bound to produce rubbish. So it seems relevant to know how to distinguish. Since the processor seems not to make the distinction, I think I must be something... Kind regards, Abe === Op 04/03/2024 om 09:08 schreef Gary L Peskin: > Hi, Abe - > > > > In the version of the PoP that I'm looking at, it states that ". Except where > otherwise indicated, ...DFP [is defined] in terms of the right-units view. So > I think that's just a convention in the documentation. > > > > As far as LUV vs RUV, a given value is represented the same in a register or > storage regardless of whether you view it as LUV or RUV. These are just > "views" at the number. You can view it as if the decimal point is either to > the right of the leftmost digit (LUV) or to the right of the rightmost digit > (RUV). In other words it's sort of like saying 1.234 * 102 (LUV) is the same > as 1234 * 10-1 (RUV). If you look carefully, you’ll see that the biases for > the exponent in figure 20-2 differ by the same amount as the number of digits > in the significand. By considering the bias as having changed, it just > accounts for where the decimal point is even though the representation is the > same. It’s just a question of how you want to view the number. I probably > didn’t explain this very well but I hope you get the idea. > > > > Frankly, I think this whole LUV vs RUV discussion is more confusing than > helpful but I guess some people like to think of their numbers as x. * > 10y and others prefer to think of them as x * 10z. > > > > And figure 9-1 is just showing the possible range of values with an unbiased > exponent. It’s not meant to indicate any representation of the top/bottom of > the range in memory which uses biased exponents. > > > > HTH, > > Gary > > > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Abe Kornelis > Sent: Sunday, March 3, 2024 10:29 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Decimal Floating Point Numbers > > > > All, > > > > There's something with decimal floating point numbers that has been eluding > me for a long time. > > > > According to PoP chapter 20, DFP numbers may be encoded as either Left-Units > View or Right-Units View. > > As shown in e.g. figure 20-2. > > > > Yet when looking at a DFP value in a dump, it seems to be impossible to tell > which view applies. > > Just like a packed decimal does not have the decimal point encoded - you just > have to know where the programmer decided it to be. > > Is it indeed like that with LUV vs. RUV - you just have to know? > > > > Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV > representation limits. > > Instruction descriptions equally make no mention of LUV vs. RUV. > > > > To me it appears the instruction always treat the data as RUV. Is this > correct? > > Or am I missing something obvious? > > > > Thanks in advance, > > Abe Kornelis. > > ==
Decimal Floating Point Numbers
All, There's something with decimal floating point numbers that has been eluding me for a long time. According to PoP chapter 20, DFP numbers may be encoded as either Left-Units View or Right-Units View. As shown in e.g. figure 20-2. Yet when looking at a DFP value in a dump, it seems to be impossible to tell which view applies. Just like a packed decimal does not have the decimal point encoded - you just have to know where the programmer decided it to be. Is it indeed like that with LUV vs. RUV - you just have to know? Additionally, figure 9-1 lists only the RUV values; no mention is made of LUV representation limits. Instruction descriptions equally make no mention of LUV vs. RUV. To me it appears the instruction always treat the data as RUV. Is this correct? Or am I missing something obvious? Thanks in advance, Abe Kornelis. ==
Re: Self-documenting Bit Settings
John, that is correct. Thank you for providing a pointer. I was under the assumption it was no longer available on the web. I still view this document as very instructive. My copy is close at hand, like PoP and HLASM Lang Ref. Actually, this presentation inspired me to create what I call extended assembly language (CBT file 884) I'll probably need to retire before I'll around to add the programs that I created using extended asm. I hope you'll all enjoy reading the document as much I did! Kind regards & happy programming, Abe === Op 17/08/2023 om 04:44 schreef John Dravnieks: > https://bitsavers.org/pdf/ibm/share/Ehrman_-_Assembler_Language_as_a_Higher_Level_Language_SHARE_Summer_2002.pdf > This is the presentation that Abe is referring to. > > Kind regards > John
Re: Self-documenting Bit Settings
All, The technique has been described extensively by the late Dr. John Ehrman. I think it was a Share presentation. I used to create my own version. Works like a charm. I love to be able to simply manage a bit by name, not needing to care about the label used to define the storage location. Kind regards & happy programming! Abe === Op 15/08/2023 om 20:54 schreef Dave Clark: > "IBM Mainframe Assembler List" wrote on > 08/15/2023 02:07:32 PM: >> Ratz! Those macros are not on my system. ;-b > > So, I whipped up my own simple versions and created a little test > program to see how it all works. It is even compatible with my macros for > conditional constructs. Thanks for the idea, Jonathan. > > MACRO >TF >TM,L'TEST FLAG BYTE > MEND > MACRO >SF >OI,L'SET FLAG BYTE > MEND > MACRO >CF >NI,X'FF'-L' CLEAR FLAG BYTE > MEND > > PRINT OFF > COPY IF IF/AND/ELSE/ENDIF CONSTRUCT > COPY SELECT SELECT/WHEN/ENDSL CONSTRUCT > COPY WHILE WHILE/WEXIT/WLOOP/WEND CONSTRUCT > PRINT ON > > TEST CSECT 0 > USING *,12 > SAVE (14,12) > LR12,15 > SFFLAG3 > IFFLAG3,(ON,TF),$NOOP > WTO 'FLAG3 IS ON' > ELSE > WTO 'FLAG3 IS OFF' > ENDIF > CFFLAG3 > IFFLAG3,(ON,TF),$NOOP > WTO 'FLAG3 IS ON' > ELSE > WTO 'FLAG3 IS OFF' > ENDIF > RETURN (14,12),RC=0 > > DS0D > FLAG1EQU *,B'0001' > FLAG2EQU *,B'0010' > FLAG3EQU *,B'0100' > FLAG4EQU *,B'1000' > FLAG5EQU *,B'0001' > FLAG6EQU *,B'0010' > FLAG7EQU *,B'0100' > FLAG8EQU *,B'1000' > DSBL1 FLAG BYTE > END TEST > > > Sincerely, > > Dave Clark
Re: Macros: sublists question
Hi David, As you stated, the parameter is no longer regarded as a sublist by HLASM. Therefore you'll have to do all the parsing yourself. You'll probably have to rely heavily on INDEX, FIND, and substring notation. Depending on the quality and detail of error messages you might want to produce, that could result in a significant amount of code. From what you wrote it appears you have freedom to choose your own syntax. If that is correct, why not choose something that aligns better with HLASM predefined macro invocation behaviour? Your own suggestion was to use: MYMAC (2023,7,31),(=,2024,1,15) I guess you might also choose to keep sublist positions compatible: MYMAC (2023,7,31),(=2024,1,15) Kind regards, Abe Kornelis === Op 01/08/2023 om 22:39 schreef David Eisenberg: > I hope someone can help me; I have a macro assembler question. > > Suppose I write a macro MYMAC receiving two positional parameters: > > MYMAC , > > The macro will do some date arithmetic. If I invoke the macro this way: > > MYMAC (2023,7,31),(2024,1,15)two dates (year,month,day) > > then IIUC, and are both sublists. I therefore have no trouble > coding SETA statements so that I can reference the year, month, and day > values individually. > > Now suppose I wish to modify the macro parameter syntax by requiring an > equals sign in front of one of the dates (because I need to handle certain > dates differently). E.g.: > > MYMAC (2023,7,31),(=,2024,1,15) > > Again, this is simple: I can check for the equals sign and extract the > numeric values from the appropriate positions in each sublist. > > However... suppose I want to allow this syntax: > > MYMAC (2023,7,31),=(2024,1,15) > > in which the equals sign precedes a date, but is *outside* of the > parentheses. Now IIUC, is no longer a sublist. This instruction: > > SETC ''(2,*) > > sets to the string (2024,1,15) which *looks* like a sublist, but of > course it’s not. Maybe I'm on the wrong track. Bottom line: in my last > example, I can’t figure out how to extract the year, month, and day values > from so that I can reference them separately. > > I apologize if this is basic stuff... I would really appreciate the help! > > Thanks, > > David
Re: IEFU86 WorkArea use ?
Hi Guillaume, No I did not see anything specified on serialization. Unless I've missed it, that should imply no serialization is needed. I guess it's serialized by the caller of the exit, or maybe no explicit serialization is needed at all. But that does not help at all in resolving your abend. I'm sorry I cannot help you there. Kind regards, Abe === Op 08/07/2023 om 17:40 schreef Guillaume Boesel: > Hi Abe, > > "coding an authorized exit such as IEFU86 might not be the best option for > learning." > Yes, you are right, I know that it's dangerous but I still did some system > related stuffs with assembler and now I want to try system exits as It's very > interesting. > My iefu86 works fine on my test system but I will not test it at work on a > production system :) > > "I just read up on the exit documentation, following the pointer you > provided." > Did you see something special about the workarea serialization ? > > "Kind regards & success learning assembler!" > Thank you ! > > > Guillaume
Re: IEFU86 WorkArea use ?
Guillaume, I just read up on the exit documentation, following the pointer you provided. And I noticed the exit is called in supervisor mode, key 0. If you are indeed relatively new to assembler programming, then coding an authorized exit such as IEFU86 might not be the best option for learning. I suggest you have a senior colleague review your code before you start testing it. A bug in an exit like this might bring the system down :-( Kind regards & success learning assembler! Abe === Op 08/07/2023 om 16:10 schreef Guillaume Boesel: > Hi Abe and Pieter > Thank you for your replies. > > "I hope you're using CS on the ST of the pointer to the obtained area." > Sorry for my newbie question but what means CS and ST ? > > "Most areas that are shared have a documented serialization requirement." > I didn't see anything about serialization (or I misunderstood it) in the > documentation and in the SYS1.MACLIB(IFAEXITP) > > > https://www.ibm.com/docs/en/zos/2.5.0?topic=exits-iefu86-smf-record-exit#IEFU86__pspu86 > > > It works well with my own Storage Obtain/Release but if the provided workarea > can be used, it should be better. > > Guillaume
Re: IEFU86 WorkArea use ?
Hi Guillaume, ST = STore, a very common instruction. CS = Compare and Swap - an instruction mainly used in multi-processor environments when a 1-word area of storage (such as a 31-bit pointer) needs to be modified in a serialized way. For details, please look up these instructions in the Principles of Operation. Or in the late John Ehrman's excellent (although overcomplete) tutorial Assembler Language Programming for IBM z System Servers. Kind regards & welcome to the world of assembler programming! Abe Kornelis == Op 08/07/2023 om 16:10 schreef Guillaume Boesel: > Hi Abe and Pieter > Thank you for your replies. > > "I hope you're using CS on the ST of the pointer to the obtained area." > Sorry for my newbie question but what means CS and ST ? > > "Most areas that are shared have a documented serialization requirement." > I didn't see anything about serialization (or I misunderstood it) in the > documentation and in the SYS1.MACLIB(IFAEXITP) > > > https://www.ibm.com/docs/en/zos/2.5.0?topic=exits-iefu86-smf-record-exit#IEFU86__pspu86 > > > It works well with my own Storage Obtain/Release but if the provided workarea > can be used, it should be better. > > Guillaume
Re: IEFU86 WorkArea use ?
Hi Pieter, would you really do that? without serialization? I hope you're using CS on the ST of the pointer to the obtained area. And then release the storage in case the CS fails ... Most areas that are shared have a documented serialization requirement. The CS I suggested might be inappropriate if another mechanism is documented. Kind regards, Abe Kornelis. === Op 08/07/2023 om 12:17 schreef Pieter Wiid: > If a work area is shared among exits, I would expect one of those exits to > getmain the area and store the address. > > Consider this: > LT Rx,IFAEXITP > JNZ ALLOCATED > STORAGE OBTAIN. > ALLOCATED DC 0H > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Guillaume Boesel > Sent: Saturday, 08 July 2023 10:51 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: IEFU86 WorkArea use ? > > Hi, > I'm testing IEFU86 exit to be able to write on syslog the SMF record number > on the fly. > It's just for educational purpose. > > When I use the workarea (retrieved from IFAEXITP) to store my WTO, SMF > record,etc it works pretty well. > I am able to WTO the SMF records number in syslog. > But when I login/logoff, it fails with S0C4-11 (I don't use getmain/freemain > storage obtain/release in my code). > > When I use STORAGE OBTAIN/release to store my stuffs and don't use IEFU86 > workarea, it works well. No more S0C4-11 when I login/logoff. > > According to this thread : > > > https://bit.listserv.ibm-main.narkive.com/cIdJ48RP/smf-exit-iefu086-work-area-size#post16 > > the workarea seems shared (maybe why it fails for me ?) If it is the case, > what is the utility of the workarea ? > > Thank you for your help > Guillaume > >
Re: Variable symbol without leading
Jon, I've heard others make that remark before: HLASM is actually two languages. I find the distinction rather arbitrary - both aspects of HLASM are intimately interconnected. As Mr. Metz correctly remarked, there is only a single Language Reference Manual for HLASM. I think that's for a very good reason. Try to split that manual into two separate ones, you'll find yourself facing boundary cases and many references between the two manuals. Kind regards, Abe === Op 28/06/2023 om 19:07 schreef Jon Perryman: > Assembler language and Assembler Macro language are 2 separate languages & > manuals. Both have variables and symbols but they are very different in > concept. In Assembler, symbols have a diverse use, one of which is variable > names. On the other hand in the macro language, symbols and variables are not > related at all. The only macro symbol that comes to mind is sequence symbols > (e.g. AGO .SYMBOL). Because of the period, a macro variable name cannot > become a symbol. If I remember correctly, in certain situations, a sequence > symbol can include a variable (e.g. ago .LABEL). > > As for omitting the & in variable declarations, don't do it to be consistent. > IBM can't change this behavior in the Macro language because it would break > existing code. > > Moral of the story, treat Assembler and Macros as 2 separate languages. There > are a couple of situations where the distinction becomes a little blurred but > it's usually obvious.On Wednesday, June 28, 2023 at 07:46:55 AM PDT, > Seymour J Metz wrote: > > Yes, it's legal, no, it's not an ordinary symbol in a [LCL|GBL]x, and yes, > it's confusing. IMHO it would have been better to accept it but issue a > warning. > > > From: IBM Mainframe Assembler List on > behalf of Joseph Reichman > Sent: Wednesday, June 28, 2023 10:09 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Variable symbol without leading & > > Hi > Just looked at the doc for LCLC says for variable symbol says can be with or > with out leading & > > I did try to assemble a symbol without leading & and it did a assemble > however I would think without the leading & it’s an ordinary symbol > > However when I tried to do a SETC against it I got a assembly error > > So my question becomes if you can declare a variable symbol without a > leading & > But cannt SETC what can it be used for >
Re: Variable symbol without leading
Gil, all, You suggest that a declaration for a variable with a leading ampersand should have the variable name evaluated before it is actually declared. Not only would that break most existing code (I do not recall ever having seen a variable declaration without a leading ampersand), it would also duplicate existing logic and syntax for created set symbols, adding even more confusion than we already have. Created set symbols use a different syntax to disambiguate them from the proposed syntactical construct. I do not _know_ why the ampersands on the variable declarations can be omitted, but it probably relates to compatibility with one or more of HLASM's predecessor assemblers. Since it is pretty confusing to leave out the leading ampersand, I would advise not to use this syntactical feature. Stick with the ampersands. Life is complex enough as it is. And if you need to declare created set symbols, use the existing &() notation. Works like a charm :-) Kind regards & happy programming! Abe Kornelis == Op 28/06/2023 om 16:59 schreef Paul Gilmartin: > On 6/28/23 08:17:20, Dave Clark wrote: >> "IBM Mainframe Assembler List" wrote on >> 06/28/2023 10:09:27 AM: >>> Just looked at the doc for LCLC says for variable symbol says can be >>> with or with out leading & >>> >>> However when I tried to do a SETC against it I got a assembly error >> >> I believe that it means LCLC does not require the leading >> ampersand but in all other uses the leading ampersand is required -- and >> it is the same variable. > > That's gratuitous flexibility that adds no expressive power, > but leads to confusion, as in the original ply. > > Rather, for consistency, symbols appearing as operands of > LCLC should be evaluated: > > SETC '&' > LCLC > > ... should declare to be a local symbol. > > (What about LCLA and LCLB?) >
Re: Notepad++ language formatting
Paul, there's a difference in reference frame, causing confusion. To highlight macros differently from opcodes, Notepad++ needs a list of them. That's the list of macros I referred to. I extended the list to contain most macros from SYS1.MACLIB and SYS1.MODGEN. I'm sure every user will have their own set of commonly-used macros. Those will have to be added - which is pretty straightforward, actually. No macros (pun intended) are needed to achieve that ;-) Kind regards, Abe === Op 04/06/2023 om 17:51 schreef Paul Gilmartin: > On 6/3/23 21:13:53, Charles Mills wrote: >> Geez, people. This was not a religious statement about platforms. >> This was a personal tool that I decided to share. > > I was not advocating for THE or Kedit, merely observing that > they might be more familiar to HLASM programmers. > > Given Windows, my favorite editor is Notepad++. Notepad displays > UNIX files as terraces. Wordpad displays UNIX files correctly, > but Saves them with Windows lineends. Notepad++ handles both > Windows and UNIX files correctly. > >> Why did I develop the file? I wanted highlighting for HLASM in the >> editor that I was already using. >> ... >> BTW @Gil, the macros in question are HLASM macros with .* comments, >> not some sort of NP++ XML macros. > > I'm puzzled. I had assumed the macros mentioned were to accomplish > highlighting for HLASM, and would have expected them to be written > in a desktop language such as VBA or .BAT or ... (Regina?), not > HLSAM, which I wouldn't expect the desktop to understand. >
Re: Notepad++ language formatting
Paul, choice of editor (and platform) is another religious question. To each his/her/their own - Notepad++ is my editor of choice when working off the mainframe. The highlighting was done to make my own life a bit easier. And shared because others might benefit. That's all. Kind regards & happy programming! Abe === Op 03/06/2023 om 23:26 schreef Paul Gilmartin: > On 6/3/23 12:29:30, Abe Kornelis wrote: >> >> based on the work by Charles Mills I created an updated/extended version >> including all current instructions according PoP, more macros, >> more register names, and more file types. >> >> It is not perfect, but it does a reasonable job. >> >> So I submitted it to the Notepad++ community. >> They've taken it up in their library/repository at >> https://github.com/notepad-plus-plus/userDefinedLanguages >> >> If you want to give it a try, you can import >> the definitions from that repository. > > Why Notepad++? I'd expect Kedit or The to be more familiar > to the HLASM community? > > Better macro support? In what language are macros coded? > > Portability? Is Notepad++ available on desktop platforms > other than one, or are the macros editor-agnostic? Of course, > there's WINE, VirtualBox, or VMWare. Which of those would > require a license fee? >
Re: Notepad++ language formatting
All, based on the work by Charles Mills I created an updated/extended version including all current instructions according PoP, more macros, more register names, and more file types. It is not perfect, but it does a reasonable job. So I submitted it to the Notepad++ community. They've taken it up in their library/repository at https://github.com/notepad-plus-plus/userDefinedLanguages If you want to give it a try, you can import the definitions from that repository. If there is sufficient 'demand' I'll consider working with the Notepad++ community to improve their formatting options so we get properly highlighted assembler source. Personally I find most annoying that I could not define macro labels as a separate category. Notepad++ is unable to distinguish between the .labels and the .* comments. Also. recognition of comments is inconsistent. Kind regards, Abe === Op 18/05/2023 om 19:33 schreef Janko Kalinic: > https://www.mail-archive.com/assembler-list@listserv.uga.edu/msg12525.html > > On Thu, May 18, 2023 at 10:50 AM Schmitt, Michael > wrote: > >> Is there a language formatting file for Notepad++ for HLASM? >> >> What I found in Google is that there is one but it had no link to download >> it. >>
Re: Assembler courses
Gary, the z Architecture has a long history, it has built up lots of complexities that are difficult to grasp when you start at the most complex end. >From my experience as an assembler instructor the complexities are best added and explained layer by layer. I usually explain what the limitations were that users (and IBM) were running into and how those were resolved. Starting with reentrant programming seems a pretty tough call. Baseless should - I guess - pose less of a challenge. If you're determined to start at the deep end, I can recommend John Ehrman's exhaustive assembler tutorial. It is available on the web, e.g. from cbttape.org. Please make sure you use the version 2. Kind regards, Abe Kornelis == Op 17/09/2022 om 04:11 schreef Gary Weinhold: > To help a person who has COBOL and C language experience learn to write > assembler, I would like them to learn from the start both reentrant and > baseless coding techniques. Is there training available that assumes the > instruction set available on the z12 is the starting point and that teaches > reentrancy as the norm? > > (Cross-posted to IBM-Main and Assembler-list) > > > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, you > are not authorized to use or disclose this information, and we request that > you notify us by reply mail or telephone and delete the original message from > your mail system.
Re: Documentation on the new 64 bit instructions
Colin, Maybe I'm preaching to the choir. If so, please ignore :-) Please don't confuse using 64-bit registers with running in amode 64. These are independent of one another. When running in amode 31 or 24 you can still use the full set of 64-bit instructions available on your hardware. Obviously, for modal instructions such as LA, the behaviour of the instruction will vary depending on the amode in effect at the time of execution. Kind regards, Abe Kornelis == Op 28/06/2022 om 18:03 schreef Colin Paice: > I've been working on calling an assembler program from a 64 bit C program, > and have been struggling.Is there is a good guide on how to use these new > instructions? > For example1) > "You need to use a LLGTR R1... instruction to clear the register before > using a L R1... because without it the high part of the register will have > some 64 bit rubbish in it" > > 2) > I used > > BAKR R14,0 > PR > But it kept returning in 24 bit mode. It needs BSM 14,0 before the > BAKR.__ > > The POP tells you all about the instructions - but not how to use it. The > z/OS doc says use BACK/PR without mentioning the BSM. > > > Colin Paice
Re: When did logical instructions appear?
Michael, all, in addition to all the replies already provided, I would like to point you to a page I created: https://bixoft.nl/english/opcodes.htm Kind regards & happy programming! Abe === Op 16/06/2022 om 16:36 schreef Schmitt, Michael: > My company's COBOL coding standards are* to define binary fields as signed > (e.g. PIC S9(4) BINARY). I'm wondering why that's the standard. > > The original standards were developed at least 40-60 years ago. They were > revised in 1994 but the signed binary guidance remained. > > One explanation could be if 50 years ago there were only signed binary > instructions such as ADD, but not logical instructions such as ADD LOGICAL. > Or maybe there were some logical instructions but not the full complement we > have today. > > Or it could be that whatever version of COBOL was used then (OS/VS COBOL or > earlier) was more efficient with signed binary, such as due to the choices it > made in instruction selection. > > So my question is, roughly when did the machines get unsigned binary > instructions for halfwords and fullwords? > > > * "are" isn't the right word here, since the COBOL coding conventions are no > longer published anywhere. I only know what they are because I was on the > team that reviewed the 1994 revision, and have a copy saved.
Re: Quadword constant
All, for literals where the assembler refuses to do the calculus for you, you can use a SETA statement to determine the value, then use the SETA symbol to promote the calculated value into the DC value. The upper limit of 2G of results, including any intermediate values, still applies. To get around that you'll need to work out the SETA for a set of variables holding sections of the final number. Clunky, but it can be made to work. Success! Abe === Op 19/05/2022 om 21:48 schreef Paul Gilmartin: > 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.
Re: Weird location counter
Charles, yes - we were saying the same thing. It seems I formulated too concise. I always find it difficult to strike a proper balance between boring everyone to death with lengthy and detailed explanations on the one hand, and short concise descriptions on the other ... At least Joao can now go ahead and sole his problem. Thanks for expanding on my answer ;-) Kind regards, Abe === Op 03/04/2022 om 23:39 schreef Charles Mills: > I didn't realize it reading your answer, Abe, until after I wrote mine, but > yes, I think I am saying the same thing you said. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Abe Kornelis > Sent: Sunday, April 3, 2022 12:29 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Weird location counter > > Joao, > > from what I see it appears that the assembler thinks you have an active > USING > with R13 pointing to the location where the S-con of D000 appears, > offset 2AA4 in the listing. > > I see you do have an ASMA303W indicating overlapping USING ranges. > You do have the active USINGS in the page header, so an additional EJECT > just before the PATCH_AREA might help you to pinpoint the problem.
Re: Weird location counter
Joao, from what I see it appears that the assembler thinks you have an active USING with R13 pointing to the location where the S-con of D000 appears, offset 2AA4 in the listing. I see you do have an ASMA303W indicating overlapping USING ranges. You do have the active USINGS in the page header, so an additional EJECT just before the PATCH_AREA might help you to pinpoint the problem. Kind regards, Abe Kornelis == Op 03/04/2022 om 21:02 schreef João Reginato: > Hi guys > Take a look in these pieces of code compiled in z/OS V2R4: (use any > proportional font like courier for better understanding) > > 000BCC D2A5 D100 8B94 00100 02B94 2107 MVC > WKINFO(LINFO/2),LKINFO INITIALIZE DYNALLOC > 000BD2 D2A5 D1A6 8C3A 001A6 02C3A 2108 MVC > WKINFO+(LINFO/2)(LINFO/2),LKINFO+(LINFO/2) >D 100 02B94 00100 2109 USING LKINFO,WKINFO > ** ASMA303W Multiple address resolutions may result from this USING and the > USING on statement number 781 > 000BD8 4100 D10402B98 2110 LAR0,LKINFO+4 > RB POINTER > 000BDC 5000 D10002B94 2111 STR0,LKINFO > SAVE IT > 000BE0 9680 D100 02B942112 OILKINFO,X'80' > LAST RB > 000BE4 4100 D11802BAC 2113 LAR0,LKTXTIFC > 1ST TEXT UNIT > 000BE8 5000 D10C02BA0 2114 STR0,LKATXTU > SAVE IT > 000BEC 4100 D12802BBC 2115 LAR0,LKDDNP > USE THIS DDNAME > 000BF0 5000 D11802BAC 2116 STR0,LKTXTIFC > SAVE IT > 000BF4 4100 D13A02BCE 2117 LAR0,LKDSGP > RETURN DSORG > 000BF8 5000 D11C02BB0 2118 STR0,LKTXTIFC+4 > SAVE IT > 000BFC 4100 D14602BDA 2119 LAR0,LKDSNP > RETURN DSNAME > 000C00 5000 D12002BB4 2120 STR0,LKTXTIFC+8 > SAVE IT > 000C04 9680 D120 02BB42121 OILKTXTIFC+8,X'80' > LAST TEXT UNIT > ... > 000C20 4110 D10002B94 2129 S3DYNIOK LAR1,LKINFO > POINTS TO PARAMETERS >2130 DYNALLOC , > RETURN DSORG & TRUE DSNAME >2131+*MACDATE Y-2 73082 > 000C24 0A632132+ SVC 99 CALL DYNAMIC > ALLOCATION > ... > Up to here everything appears to be ok. But see below: > ... > 0017FA E3F0 D07C 0058 02B10 3486+ LYR15,=V(FDRCOMPR) > LOAD EPA > ... > 002A8E 5341+PATCH_AREA DS 0H > PATCH AREA > 002A8E 8A8E8A908A92D0005342+ DC64S(*) > PATCH AREA > 002A96 D002D004D006D008 ==> THE LOCATION COUNTER WAS CHANGED SUDDENLY > > 002A9E D00AD00CD00ED010 > 002AA6 D012D014D016D018 > 002AAE D01AD01CD01ED020 > 002AB6 D022D024D026D028 > 002ABE D02AD02CD02ED030 > 002AC6 D032D034D036D038 > 002ACE D03AD03CD03ED040 > 002AD6 D042D044D046D048 > 002ADE D04AD04CD04ED050 > 002AE6 D052D054D056D058 > 002AEE D05AD05CD05ED060 > 002AF6 D062D064D066D068 > 002AFE D06AD06CD06ED070 > 002B06 D072D074D076D078 > 002B10 5343+ LTORG > 002B10 5344=V(FDRCOMPR) > 002B14 5345=V(FDRDCOMP) > ... > Page 83 > Active Usings: TLTCVAF,R2 IHADCB,R3 TASKPARM,R10 FDRIOC,R11,R9,R8 > QCTDCB,R12 JFCB(X'FB4'),R12+X'4C' > DECB(X'FF0'),R12+X'10' WKAREA,R13 LKINFO(X'E56C'),R13+X'2A94' > DCBE,R15 > Loc Object CodeAddr1 Addr2 Stmt Source Statement > HLASM R6.0 2022/04/01 19.40 > ... > 002B94 80002B98 29585 LKINFO DCA(*+X'8004') > RB POINTER > 002B98 1407 29586 DC > AL1(LKTXTIFC-*,S99VRBIN) LENGTH, INFORMATION VERB > 002B9A 0600 29587 DC > AL1(S99MSGL0+S99GDGNT,0) FLAGS1 > 002B9C 29588 LKERCDCAL2(0) > ERROR CODE > 002B9E 29589 LKIRCDCAL2(0) > INFO CODE > 002BA0 2BAC 29590 LKATXTU DCA(LKTXTIFC,0) > TEXT UNIT LIST PTR, RBX > 002BA8 29591 DCAL1(0,0,0,0) > FLAGS2 > 002BAC 2BBC2BCE 29592 LKTXTIFC DC > A(LKDDNP,LKDSGP,LKDSNP+X'8000') > 002BB4 80002BDA > 002BB8 C4C4D5D4 29593 DCC'DDNM' > 002BBC 000100010008 29594 LKDDNP DCAL2(DINDDNAM,1,8) > GET INFO FROM > 002BC2 4040404040404040 29595 LKDDNDCCL8' ' > DDNAME > 002BCA C4E2D6D9 29596 DCC'DSOR' > 002BCE 000A0
Re: Using ARs for MVC vs. using Move to Primary or other instruction?
Tony, My tuppence, since I do not really know VSE I may be quite wrong ... The fastest copy for a very large amount of data would probably be to manipulate the page table entries of your partition to map to the source partition's page frames of interest into an available page range of your partition. Of course, all virtual addresses would be different, so if you're following any pointers, you'll have to adjust for the difference Plus, while you're dumping the data, you may not want anything to change, so you'll probably need to suspend the source partition from being executed until you're done. Which implies that the tasks running there will be suspended longer than if you made a real copy. If you decide you really need to copy the data over, you're probably best off using a loop of MVPG instructions. Kind regards, Abe Kornelis == Op 03/04/2022 om 01:59 schreef Tony Thigpen: > All, > > I have used ARs to get data from other VSE partitions (address spaces > to you z/OS guys). I am looking at a program that needs to 'snap shot' > a partition by copying a lot of data, then printing it. > > I have never used "move to primary" or "move with key" type instructions. > > Is there any performance, or other reason, I should look at these > other instructions? Or, should I just continue to use ARs? > > Tony Thigpen
Re: Fun with RXSBG
Dan, thanks for sharing this. It is not an obvious coding technique. With the semantics of code fragment explained, it does make sense & speed! Kind regards, Abe === Op 03/03/2022 om 23:22 schreef Dan Greiner: > At the risk of sounding pedantic, it's no secret that I think the ROTATE THEN > * SELECTED BITS instructions are the sexiest ops in the architecture. A > former colleague (thanks Tim) recently reminded me of a really cool feature > of the RXSBG instruction that I used to improve a code fragment I've used for > decades. > > For a long time, I've toyed with the following challenge. Given: > ⦁ Register "P" points to the next free location in a buffer, the size and > alignment of which are architecturally integral (i.e., a power of two), and > ⦁ Static value "C" indicates the size and alignment of the buffer in the form > of an characteristic (i.e., 2**C), and > ⦁ Register "L" contains the byte length of a prospective object to be added > to the buffer, > what is the best way to determine whether the object will fit in the buffer. > > Not counting any branch following the determination, I had previously managed > to trim this down to three instructions. For example, to determine if a > prospective insertion crosses a 4 K-byte boundary: > 1.LAY S,-1(L,P) where "S" is a scratch register. > 2.XR S,P determine the difference > 3.NILF S,X'F000' Turn off insignificant bits. > If the condition code is zero following the AND (NILF) instruction, the > object will fit. Obviously, this needs a little tweaking for 64-bit > addressing, and there are other subtleties as to whether the buffer is > completely full or there is additional remaining space. > > The exclusive-or part of a ROTATE THEN EXCLUSIVE OR SELECTED BITS (RXSBG) > instruction can be used to determine the difference between the beginning and > ending pointers, and the "selected bits" part of RXSBG effectively does the > ANDing to determine if overflow occurred. By using the RXSBGT extended > mnemonic, the test-results control is set such that the condition code > indicates the results. Thus, steps 2 and 3 from above can be combined into: > RXSBGT S,P,0,63-C,0 > > If interested, I have a handy "Will It Fit" macro to accommodate any integral > size.
Re: Modifying the VSAM Request Parameter List (RPL)
Dave, I used MODCB extensively in the past and it served me well. The case you're describing may make that approach rather unwieldy. As suggested before, you might consider using the mapping macro (IFGRPL if I recall correctly off the top of my head) and address the RPL fields and masks directly. The drawback is that you will have to know and understand the layout and workings of the RPL. You're skipping all sanity checks that MODCB would implement for you. Also, if anything changes in the RPL structure, your program will at least need to be re-assembled. It is up to you to guesstimate how much of a risk that poses to you ... Kind regards, Abe Kornelis === Op 24/02/2022 om 17:33 schreef Dave Clark: > This isn't strictly an Assembler question -- more of a "How to > Modify a VSAM RPL Efficiently in Assembler" type of question. But... > > The reason I say "efficiently" is because of the dynamic nature of > this external assembler REXX function I am working on. Unlike a high-level > compiler that knows what is needed before a particular READ request and > can create a single MODCB RPL request at that point, I have a nested IF > situation before my GET request that is a bit of a nightmare to say the > least and is a program size hog to say the most. > > In particular, I have 18 MODCB RPL requests just before my GET > request. This is because the caller may have requested an OPEN and then a > READ request that has the following different option combinations. > > Call RXVSAMIO ddname, 'OPEN' > <, 'INPUT'|'UPDATE'|'OUTPUT'|'APPEND'|'RESET' > <, 'SEQUENCE'|'RANDOM'|'DYNAMIC' > >; > > Call RXVSAMIO ddname, 'READ' > <, 'NEXT'|'PREV' > |'RBA'|'KEY' <, 'EQUAL'|'GTEQ' > >; > > I asked this question on the VSE listserve and got the hint to use > the MF=(L,...) and MF=(E,...) macro parameters to separate configuration > of the parameter list from the execution of that parameter list. That > helped a bit to reduce the program size. However, each MODCB MF=(L,...) > request still generates its own in-line parameter list template (ACES) > that "wastes" 20 to 22 bytes before using another 10 bytes to copy the > 16-byte ACES to the dynamic storage parameter list area I have provided. > And that's just the 18 combinations that I have before the GET request -- > not to mention a similar (though smaller) nested IF before the POINT > request. > > So, finally, here is the question... Is there some assembler > technique to further reduce the storage requirements of the following > sequence of instructions? For example... Is there some way to build the > OPTCD value in a separate string and then pass it to a single iteration of > the MODCB MF=(L,...) invocation? > > IF RQARG2,EQ,C'N' GET NEXT > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,UPD) > ELSE > IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL >MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NUP) > ELSE ACCESS IS DIRECT >MODCB MF=(L,PARMLIST),RPL=(*,FILERPL),OPTCD=(SEQ,FWD,NSP) > ENDIF > ENDIF > ELSE > IF RQARG2,EQ,C'K' GET BY KEY > IF RQARG3,EQ,C'G'GTEQ >IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,SEQ,FWD,UPD) > ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,SEQ,FWD,NUP) > ENDIF >ELSE ACCESS IS DIRECT > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,DIR,FWD,UPD) > ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KGE,DIR,FWD,NSP) > ENDIF >ENDIF > ELSE EQUAL >IF FILEOPT,(ON,TM),FILESEQU IF ACCESS IS SEQUENTIAL > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,SEQ,FWD,UPD) > ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,SEQ,FWD,NUP) > ENDIF >ELSE ACCESS IS DIRECT > IF FILEOPT,(ON,TM),FILEUPDT IF OPENED FOR UPDATE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,DIR,FWD,UPD) > ELSE > MODCB MF=(L,PARMLIST),RPL=(*,FILERPL), > OPTCD=(KEY,KEQ,DIR,FWD,NSP) > ENDIF >ENDIF > ENDIF
Re: Branch-and-Link nomenclature question
Hi Melvyn, is this what you are looking for? It does not duplicate PoP, but does have some references ... http://www.bixoft.com/english/opcd/balr.htm Kind regards, Abe === Op 10/02/2022 om 21:30 schreef Melvyn Maltz: > Hi Guys, > > Specifically to Dave Cole's query... > > >>>(FWIW, I find both books to be abysmal documents!) > >>>(There. That ought to create a firestorm!) > > A few years ago and on this forum I dared to say that the PoO was > totally inadequate for the 21st century...an opinion I still hold > > It did get a 'firestorm' reaction, about evenly distributed between, > "it's a bible and cannot be modified" to those agreeing with me > > Among my suggestions, only applying to instruction descriptions is > that... > These should be in a separate Manual, one 'page' per instruction, > hyperlinks to similar instructions, maybe a tracker saying 'people who > looked at AHI also looked at LHI :-)' > > Perhaps there's someone out there who has the time > > Melvyn Maltz. > > On 10/02/2022 07:40 pm, David Cole wrote: >> WRT: >>> "A gentle reminder on terminology: The term "JUMP" appears neither >>> in the PoO nor in the z/Architecture Reference Summary (SA22-7832). >>> What you refer to as "JAS (jump and save)" is simply reflecting the >>> extended mnemonic for BRANCH RELATIVE AND SAVE (BRAS)." >> >> >> >> The PoOps has some inconsistencies... One that I find rather >> irritating is the presences of extended mnemonics for a large number >> of newer instructions, but the omission of same for all of the BC, >> BRC, BRAS and related instructions. >> >> Yes, I am quite aware that I included redundant entries in my list. I >> didn't care because it was beside the point. >> >> Speaking of fake mnemonics... What is the difference between >> "extended mnemonics" (such as CGIJNE) and "alternative mnemonics" >> (such as JAS)? Is it that one is documented only in the PoOp and the >> other only in HLASM Ref? >> >> (FWIW, I find both books to be abysmal documents!) >> (There. That ought to create a firestorm!) >> >> >> Dave >> >> >> >> >> >> >> At 2/10/2022 01:27 PM, Dan Greiner wrote: >>> Having learned this stuff in the 1970s — before the linkage stack >>> showed up in the late 1980s — I was accustomed to hearing them >>> called simply "linkage instructions." For the common usage of >>> application programmers who need a simple instruction to branch to >>> Oz while leaving a footprint of how to get back to Kansas, that's >>> probably sufficient. >>> . >>> >>> The z/Architecture Principles of Operation (SA22-7832-10) refers to >>> such instruction in a section labelled "Subroutine Linkage without >>> the Linkage Stack" (p. 5-16 onward), with the simple stuff like >>> BAL[R], BAS[R] and friends called "Simple Branch Instructions". This >>> text shows the awkwardness that crept into the architecture when >>> various commonly-used terms get redeployed for other purposes. [A >>> brief aside: During the design of the S/360, the designers >>> deliberately eschewed a stack architecture in favor of the chained >>> save-area approach. With the advent of ESA, they changed their minds >>> (sort of) and implemented a linkage stack.] >>> >>> A gentle reminder on terminology: The term "JUMP" appears neither in >>> the PoO nor in the z/Architecture Reference Summary (SA22-7832). >>> What you refer to as "JAS (jump and save)" is simply reflecting the >>> extended mnemonic for BRANCH RELATIVE AND SAVE (BRAS).
Re: Making Encoded Bits Human Readable
Gil, that was a bit too short an answer. I intended it to mean yes, you should surely use IPM to preserve program mask. Having said that, the solution you suggested is far superior. So better forget SPM and IPM altogether ;-) BTW: the closest thing to shift-and-mask is probably RISBG with a zero rotate amount. Which has the advantage of leaving its input register (R2 in PoP parlance) unchanged. So you can easily repeat for the second set of two bits... Abe === Op 31/01/2022 om 21:15 schreef Abe Kornelis: > Gil, > > you surely should! > > Abe > === > > > Op 31/01/2022 om 21:13 schreef Paul Gilmartin: >> On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: >>> Gil, that is clever as all get out. Thanks for the idea, though I don't >>> have any immediate use for it myself. That's one to file in the ASM tools >>> bag, >>> >> You're welcome. Except I forgot there's no shift-and-mask instruction. >> >> >> >> On Jan 31, 2022, at 12:56:33, Abe Kornelis wrote: >>> you might consider to use SPM to set the CC in the PSW from the two bits. >>> Then you can use a series of BC instructions to select the desired >>> subsequent action... >>> >> I'd precede that with IPM to preserve the rest of the Program Mask. >> >> If I diid it that way at all. >>
Re: Making Encoded Bits Human Readable
Gil, you surely should! Abe === Op 31/01/2022 om 21:13 schreef Paul Gilmartin: > On Jan 31, 2022, at 13:03:32, Farley, Peter x23353 wrote: >> Gil, that is clever as all get out. Thanks for the idea, though I don't >> have any immediate use for it myself. That's one to file in the ASM tools >> bag, >> > You're welcome. Except I forgot there's no shift-and-mask instruction. > > > > On Jan 31, 2022, at 12:56:33, Abe Kornelis wrote: >> you might consider to use SPM to set the CC in the PSW from the two bits. >> Then you can use a series of BC instructions to select the desired >> subsequent action... >> > I'd precede that with IPM to preserve the rest of the Program Mask. > > If I diid it that way at all. >
Re: Making Encoded Bits Human Readable
Dave, you might consider to use SPM to set the CC in the PSW from the two bits. Then you can use a series of BC instructions to select the desired subsequent action... Does that make sense without a coded example ? If not, I'll cobble something together for you ... Abe === Op 31/01/2022 om 20:31 schreef Dave Clark: > I have two pairs of encoded bits in the high order of a binary > byte. These two pairs (values of 0 to 3, each) actually represent the > numbers 1 to 4 in each case. Now, I know that I could do this the hard > (long?) way by bit-testing these and come up with the human-readable zoned > equivalents. In fact, I've already done that. > > But, not only do I not like how the code looks in my program, I > also think there should be a shorter way. For example, I could insert the > byte into a register, shift out the unwanted bits, and then add 1 to get > the same numbers -- but in binary. I would then have to > convert-to-decimal and unpack or edit the numbers into zoned format. > > That seems like a bit much. So, is that what I am going to have > to do? ...or stick with bit-testing? ...or is there a better way to > accomplish this? > > Sincerely, > > Dave Clark
Re: Debugging Assembler Rexx programs
Charles, sorry for belated reply. Inserting an invalid opcode works to create a single dump. With SNAP you can have multiple dumps along the path of execution, up to the final abend (if any). If you need to preserve a volatile register across the SNAP invocation, you must save/restore them in your own program. No big deal... Kind regards, Abe === Op 26/01/2022 om 22:35 schreef Charles Mills: > I'm just lazy. Rather than look up SNAP I just used DC H'0'. I seem to recall > that SNAP clobbers a couple of registers but I could be wrong on that. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Abe Kornelis > Sent: Wednesday, January 26, 2022 11:38 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Debugging Assembler Rexx programs > > Charles, > > I've used SNAP dumps extensively - but never in a program called from REXX. > Is there a reason you left it out of your list of options? > I used to like very much the ultra-short snaps with just PSW and > register dump. > > Kind regards, > Abe > === > > > Op 26/01/2022 om 18:32 schreef Charles Mills: >> I have a fair amount of experience writing assembler and calling it from >> Rexx. >> >> Is your problem with "getting going" -- the linkage and that sort of thing >> -- or some logic problem in your assembler once you get going? >> >> You might try writing the world's simplest assembler program first -- maybe >> just do nothing except survive the call and return successfully. Get that >> working. >> >> Then enhance it to return 'Hello, World!" in the result area. SAY it from >> your calling Rexx to make sure you got it right. >> >> And then move forward one step at a time. >> >> You have two "non-debugger" options for debugging: >> >> 1. WTO's. Good especially for tracing how far you got in your logic. >> 2. The old DC H'0' and debug from the dump. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] >> On Behalf Of Joseph Reichman >> Sent: Wednesday, January 26, 2022 8:35 AM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: Debugging Assembler Rexx programs >> >> The copy book is assembler >> It tells me the name of the variable it’s length >> And it’s offset which would be it’s value >> >> I have one Simple question >> >> This url >> >> https://share.confex.com/share/115/webprogram/Handout/Session7691/S7691bla.pdf >> >> Contains what I want to do it says how to write >> The program if the program is extensive >> You have to debug it >> >> The only way to get the Rexx environment >> Block >> >> Address tso >> “Call ‘myloadlib(myprog) passenvb’ >> Passenvb populates register 0 with the address of the envblock >> >> How would I debug this program >> >> It tried test ‘mylosdlib(myprog)’ cp >> And used ECTENVBK but now I am getting >> >> A return code invalid language environment >> >> >> >>> On Jan 26, 2022, at 11:16 AM, Paul Gilmartin >>> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: >>> >>> On Jan 26, 2022, at 08:09:14, Joe Reichman wrote: >>>> Thanks but that would never here at the IRS this place is highly sensitive >>>> to anything from the outside >>>> >>> It's hard for these fora to help you if: >>> >>> o You can't show the failing code. >>> >>> o You can't accept working examples from outside. >>> >>> Must your solution involve Assembler? Why not keep the data in a file, >>> read it with Rexx and populate the variables with assignment statements >>> or VALUE()? >>> >>> -- >>> gil
Re: Debugging Assembler Rexx programs
Charles, I've used SNAP dumps extensively - but never in a program called from REXX. Is there a reason you left it out of your list of options? I used to like very much the ultra-short snaps with just PSW and register dump. Kind regards, Abe === Op 26/01/2022 om 18:32 schreef Charles Mills: > I have a fair amount of experience writing assembler and calling it from Rexx. > > Is your problem with "getting going" -- the linkage and that sort of thing -- > or some logic problem in your assembler once you get going? > > You might try writing the world's simplest assembler program first -- maybe > just do nothing except survive the call and return successfully. Get that > working. > > Then enhance it to return 'Hello, World!" in the result area. SAY it from > your calling Rexx to make sure you got it right. > > And then move forward one step at a time. > > You have two "non-debugger" options for debugging: > > 1. WTO's. Good especially for tracing how far you got in your logic. > 2. The old DC H'0' and debug from the dump. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Joseph Reichman > Sent: Wednesday, January 26, 2022 8:35 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Debugging Assembler Rexx programs > > The copy book is assembler > It tells me the name of the variable it’s length > And it’s offset which would be it’s value > > I have one Simple question > > This url > > https://share.confex.com/share/115/webprogram/Handout/Session7691/S7691bla.pdf > > Contains what I want to do it says how to write > The program if the program is extensive > You have to debug it > > The only way to get the Rexx environment > Block > > Address tso > “Call ‘myloadlib(myprog) passenvb’ > Passenvb populates register 0 with the address of the envblock > > How would I debug this program > > It tried test ‘mylosdlib(myprog)’ cp > And used ECTENVBK but now I am getting > > A return code invalid language environment > > > >> On Jan 26, 2022, at 11:16 AM, Paul Gilmartin >> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: >> >> On Jan 26, 2022, at 08:09:14, Joe Reichman wrote: >>> Thanks but that would never here at the IRS this place is highly sensitive >>> to anything from the outside >>> >> It's hard for these fora to help you if: >> >> o You can't show the failing code. >> >> o You can't accept working examples from outside. >> >> Must your solution involve Assembler? Why not keep the data in a file, >> read it with Rexx and populate the variables with assignment statements >> or VALUE()? >> >> -- >> gil
Re: Unsigned Binary Formats
Dave, your initial request was for conversion of an unsigned 32-bit binary value. The LGF you are using does sign extension... I'd suggest you use LLGF to avoid just that ;-) Additionally, if speed is a concern, you might want to save only the high halves of registers when they may be changed during execution. In your code sample this would be just R2. Kind regards & success! Abe === Op 19/01/2022 om 22:48 schreef Dave Clark: > "IBM Mainframe Assembler List" wrote on > 01/19/2022 12:58:23 PM: >> You can also swap out the first two instructions below with... >> >> LLGF R2,bin4 > OK, I have created a generic subroutine that always converts > 64-bit register 2 to a left-justified, separate-left-signed, zoned number > up to 19 digits and returns it in the work area pointed to by register 1. > I did give it an option to retain leading zeros but the default is to > strip them using the EDMK instruction. So far, I'm using the LGR, LGF, > LGH, XGR/IC, and LLGF instructions to pass the data in register 2 to the > subroutine. Testing looks good. Thanks all. > > LA R1,CWORK POINT TO "RESULT" AREA > LGF R2,AMDCINV GET LRECL VALUE > BAS R15,REG2ZONE CONVERT THAT TO ZONED-DECIMAL > > > Sincerely, > > Dave Clark
Re: Unsigned Binary Formats
Dave, I'd suggest you clear the high-order word of R2 then use CVDG. Would that work for you? Kind regards, Abe Kornelis === Op 19/01/2022 om 18:32 schreef Dave Clark: > 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
Re: Vector Ops
Dan, looks extremely interesting! It's unfortunate I won't have time (anytime soon) to really dive into it. I've kept a copy for future reference. Thanks a lot for sharing! Kind regards, Abe Kornelis == Op 14/12/2021 om 06:03 schreef Dan Greiner: > Back in late September, I posted a series of PowerPoint slides describing the > IBM z/Architecture vector facilities on my Google Drive: > https://drive.google.com/file/d/13OhBkhgbU7N6a20nVo5uEAnR-s3-Pyz8/view?usp=sharing > > > The most common response I've received is something to the effect of "good > stuff ... now what do I do with it?" > > Last Christmas, I received a really annoying puzzle as a gift ... annoying > because solving it involved a lot of repetitive stress on my already inflamed > carpals. A simple C program did the trick, but I wanted to see if I could use > the vector ops to do better, so I started researching them. This led to a > months-long documentation project resulting in the slides mentioned above. > > I've put together another short presentation — only 11 slides — that describe > the puzzle and one solution using vector instructions. There are numerous > features of the vector architecture, but this pitch illustrates what I think > are a few key points: SIMD, branch avoidance, and a really neat instruction > (VPERM). Unlike my previous stuff, there is no animation in these slides; the > meat of it is in the presenter notes, so make sure you view the notes page. > https://docs.google.com/presentation/d/1gD089nRo8Lch-rkg7T7pbwclBAvsp0bf/edit?usp=sharing=104012833061983447284=true=true > > > Enjoy!
Re: FPR usage question
All, to my knowledge, the FPRs got even numbers only because in the initial implementation they existed as register pairs(!) - hence the weird numbering scheme we still have today :-) Kind regards, Abe Kornelis Op 29/11/2021 om 15:22 schreef Seymour J Metz: > I'm not aware of any processor that FP registers beyond what IBM documented. > Certainly non of the functional specs manuals mentioned such a thing. > > >From my perspective it was a long way coming, but I'd bet that there are > >people here and on IBM-MAIN who never saw a processor with only 4. > > > From: IBM Mainframe Assembler List on > behalf of Peter Relson > Sent: Monday, November 29, 2021 8:06 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: FPR usage question > > I wrote > > For z/OS, this question relates to each work unit and the question is > "does the work unit use FPRs 8-15 or VRs?". > If the answer is no, then that work unit does not save/restore those regs > upon undispatch/redispatch and thus saves some cycles. > > > "FPRs 8-15" is incomplete/inaccurate within that. It should be "FPRs > 1,3,5,7-15 or the floating point control register (FPCR)". > > Historically, only FPRs 0,2,4,6 existed and were saved/restored upon > undispatch/redispatch. Maybe Shmuel would know even the "pre-history" as > to whether FPRs 1,3,5,7 ever existed. > > The addition of the "additional floating point registers" (1,3,5,7-15 and > the FPCR) came with enablement by control register bit, with a program > interrupt upon usage without that control register bit (upon which program > interrupt, in many cases, the system would automatically activate > saving/restoring of the additional FPRs). > > Peter Relson > z/OS Core Technology Design
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 ,
> .**
> .* Invoke passed macro, with the passed parameters *
> .**
> AIF (T'(1) EQ 'O').AAm110
>SETA INDEX('(1)','=')
> SETC '(1)'(1,)
> SETC '(1)'(+1,*)
> .AAm110 ANOP ,
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
> AIF (T'(2) EQ 'O').AAm120
>SETA INDEX('(2)','=')
> SETC '(2)'(1,)
> SETC '(2)'(+1,*)
> .AAm120 ANOP ,
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
> AIF ('(2)' NE '').AAm220
> AIF ('(1)' NE '').AAm210
> UNSPLIT0 ,
> AGO .AAm300
> .AAm210 ANOP ,
> UNSPLIT1 (1)
> AGO .AAm300
> .AAm220 ANOP ,
> UNSPLIT2 (1),(2)
> .*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *
> .AAm300 ANOP ,
> AIF ('(2)' NE '').AAm320
> AIF ('(1)' NE '').AAm310
> SPLIT0,
> AGO .AAm999
> .AAm310 ANOP ,
> SPLIT1=
> SPLIT1A =
> AGO .AAm999
> .AAm320 ANOP ,
> SPLIT2=,=
> SPLIT2A =,=
> .AAm999 ANOP ,
> MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> MACRO
>TestMac1 =
> .**
> .* Macro expecting single parameter *
> .**
>SETA N'
> MNOTE *,'TestMac1 #Parms='
>SETA 1
> .BBm010 ANOP ,
> AIF ( GT ).BBm020
> MNOTE *,' SYSLIST() = /()/'
>SETA +1
> AGO .BBm010
> .BBm020 ANOP ,
> MNOTE *,' T1O1=//'
> MEND , -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> MACRO
>TestMac2 =,=
> .**
> .* Macro expecting two parameters *
> .**
>SETA N'
> MNOTE *,'TestMac2 #Parms='
>SETA 1
> .CCm010 ANOP ,
> AIF ( GT ).CCm020
> MNOTE *,' SYSLIST() = /()/'
>SETA +1
> AGO .CCm010
> .CCm020 ANOP ,
> MNOTE *,' T2O1=//,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
>
>
>
z390 update - looking for z390-...@t-online.de
For those who are interested, We're delighted to announce that the development team for the z390 assembler emulator has grown to 14 persons! As a result we are now preparing to speed up development of the z390 software. Most attention goes to instruction support, zVSAM, zCics, zCobol. We're also looking at documentation and the site. To be able to cooperate productively we are in the process of building a git repository and transferring it to github. >From what we see on github it seems the z390 account was created a few years ago, but hardly used since. It is tied to email account z390-...@t-online.de. If that looks familiar to you, would you please contact me off-list? I hope to hear from you soon. On behalf of the z390 development team, With kind regards / mit herzlichen Gruesse, Abe Kornelis. ==
Re: z/390 Assembler and START statement.
Dan, A belated reaction, sorry about the delay. I just checked the source code. It seems START is treated as a synonym of CSECT. At the java level the z390 code does not seem to expect an argument. If you need it, we could raise an RPI. Kind regards, Abe Kornelis. z390 coordinator == Op 03/06/2020 om 07:56 schreef Dan Greiner: > According to the HLASM Language Reference manual (SC26-4940), the START > statement may be used to create the first control section in an assembly and > define an expression that is used to set the initial location counter. For > example: > > START X'1000' > BR14 > END > > should generate an assembly where the BR instruction appears at location 1000 > hex. > > However, the z/390 assembler does not appear to recognize the expression on > the START statement, and flags no error for this. In the listing, the address > of the BR14 is zero, and in object file, the relative address in the .TXT > record is also zero ... regardless of what expression I use. > > This is certainly not a major issue, and I can easily circumvent it. But, I > was curious if I'm incorrectly using START (or is this behavior an > undocumented feature)?
Re: Z390 Assembler Emulator
All, sorry to chime in a little bit late. The SYSMAC option allows you to specify where z390 is to look for macros. The SYSCPY option is used for copybooks. If you use the option on the command line, you'll need to specify the full set of directories on one go. However, if you use an options file, you can use the + prefix to specify a directory to be added to the current list of already specified directories. I use this option extensively. There is quirk, though. If you have macro files without extension, then they are usable only on Windows-based systems. The *ix based operating systems will fail the search for the macros in this specific case, because of the way that z390 defaults the file extension if none is provided. This is an open issue on the to-do list for development. Lacking time, unfortunately, I'm not coming around to fixing the code and testing the fix. I'm sorry about that. kind regards, Abe Kornelis z390 coordinator. == Op 12/05/2020 om 15:42 schreef Kerry Liles: > Thanks Dave - valuable insight. > > On Tue, 12 May 2020 at 04:24, Dave Wade wrote: > >> Kerry, >> >> I tried it recently. I think the simple answer is you need to specify >> macro directories using the SYSMAC option. There are no defaults. >> I spent ages searching for a way to set up a search path that persists. >> There isn't one. >> >> Dave >> >>> -Original Message- >>> From: IBM Mainframe Assembler List >> l...@listserv.uga.edu> On Behalf Of Kerry Liles >>> Sent: 12 May 2020 00:59 >>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >>> Subject: Re: Z390 Assembler Emulator >>> >>> Whatever the resolution is for using z390 ... perhaps it can be shared >> here for >>> the benefit of others. >>> Better still, put on a FAQ page somewhere as well. >>> >>> On Mon, 11 May 2020 at 18:18, MELVYN MALTZ < 072265160664-dmarc- >>> requ...@listserv.uga.edu> wrote: >>> >>>> Hi Frank, >>>> >>>> I'm one of the few z390 developers left >>>> >>>> Contact me directly here zarf77...@blueyonder.co.uk >>>> >>>> z390 fully supports macro language, no special requirements It could >>>> be that your SYSMAC concat isn't correct >>>> >>>> Send me your BAT (renamed) and sample code and I'll sort out your >>>> problem I don't know Linux, but I know someone who does >>>> >>>> Melvyn Maltz. >>>> >>>> - Original Message - >>>> From: "Frank Myers" >>>> To: >>>> Sent: Monday, May 11, 2020 11:05 PM >>>> Subject: Z390 Assembler Emulator >>>> >>>> >>>>> Hi, >>>>> >>>>> I installed the z390 emulator and assembler on Linux. I tried to >>>>> assemble some of my code, but found that It was not recognizing my >>>>> Macros. I >>>> copied >>>>> them into the z390/mac directory, but still it does not find my >> Macros. >>>>> * Is there a required step to preprocess or register macros before >>>>> they can be used? Or do the macros need to adhere to a fixed record >>>>> length? Or perhaps only a subset of IBM Assembler Macro language is >>>>> supported? Or perhaps some other magic?* >>>>> >>>>> Thanks, in advance for any help or advise you can share. >>>>> >>>>> Frank
Re: z14 specific instructions?
I doubt that you will find an airtight solution.. If someone issues an OPSYN to define or undefine the operation mnemonic of your choice, your assembly will take the wrong turn. I fail to see how you would prevent that ... Kind regards, Abe Kornelis == Op 05/06/2019 om 19:13 schreef John McKown: > On Wed, Jun 5, 2019 at 11:57 AM Seymour J Metz wrote: > >> No, O'opcode will tell you whether opcode is defined, and if defined, what >> type of opcode it is. _CURR_OPTABLE and _OPTABLE tell you >> what table the assembler is using. >> > Correct. Suppose you are on a z14 running z/OS 2.3. If you invoke the > assembler with something like: MACHINE(ZS-3) (which is a z9). Then > O'LOCHINZ will return "U" because LOCHINZ is not valid on a z9. At least, > that has been my observation when I play around with this piece of code on > a z14 running z/OS 2.3 with the parm MACHINE(ZS-3). That's why I wanted to > know a z14 only instruction. If O'it was "U", then the code would assemble > the STORAGE macro without an EXECUTE=NO parameter. Simple over optimization > on my part, but this is my current "learning vehicle" code and I am trying > to find "extreme boundries". > > > >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >>
Re: FLAG(TRUNC)
John, that makes sense I think: Y is a signed halfword whereas AL2 is an (unaligned) two-byte unsigned value. If you'd removed the minus signs, I'd expect the warning to disappear as well. Kind regards, Abe === Op 10/04/2019 om 14:48 schreef Janko Kalinic: > This is old code, but it is generating a truncation warning. If I change > the AL2 to a Y constant there is no truncation warning. > > Regards, > John K > > 00FD92 00080013001C0022 23067=DIRBITP2 DC > 0H'0',AL2(+08,+19,+28,+34,+40) > > 00FD9C FFF8000C0018FFE2 23068=DIRBITP3 DC > 0H'0',AL2(-08,+12,+24,-30,+38) > > ** ASMA225W Value truncated to fit field; stored value is incomplete - > +12 > > ** ASMA225W Value truncated to fit field; stored value is incomplete - > +24 > > ** ASMA225W Value truncated to fit field; stored value is incomplete - > +38 >
Re: wrong list but I am in a panic
Richard, Panic is understood. I'm not 100% sure how to handle it. You might try to create a backup copy of the update file, then try and delete the record that has an invalid reference... If you cannot find the culprit line, chop up the update file into pieces. Make it a binary search for the (first) faulty reference. Good luck with you repairs! Abe Kornelis == Op 06/07/2018 om 21:54 schreef Richard Kuebbing: > ISPF edit recovery just failed. > > "Nonexistent record referenced in recovery file or chain" > > Do I have any options? I appear to have lost at least one days work. > > richard > > > - 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
Re: An idea I got when researching a bug - warnings when a specific register is changed
Binyamin, as others have pointed out, no such option exists. But: you can roll your own, if you want to! I built a prototype, and it works like a charm. Here's what I did: 1) replace EQU with a macro. Register all register equates in a set of GBLx tables. Thus, even MY_DCB_POINTER can be used as a register name and the code will know it. 2) Create a USE macro that encapsulates USING. Again, keep track of status in GBLx arrays. Where others employ a DUMMY using, I employ a USE without target address to declare a register as occupied. 3) sidestep, please forgive my verbosity: With these two in place, it is possible to create a macro that will allocate a register upon request. I use EQUREG options to have the assembler allocate an available register at pre-assembly time. 4) I built a LR macro to replace the LR opcode. it will diagnose unnecessary LR instructions, such as LR R5,MY_REG where MY_REG happens to equ R5. It could be enhanced to check for registers declared protected on your version of the USE macro. 5) This macro should be converted into a template, such that macros for all register-modifying opcodes can be generated. You certainly do not desire to maintain all of those manually :-( Generating these on the flight is possible using STACK instructions. I'm sure I've missed some important details. I built this stuff 18 years ago... But you're experienced enough to do get the drift. Kind regards & Happy programming! Abe Kornelis == Op 25/06/2018 om 17:49 schreef Binyamin Dissen: > Since the assembler knows which instructions modify which registers, it would > be nice if there was a way to "protect" a register for a code range. > > Perhaps > > USING area,Rx,protect > > Any alteration of the register until the DROP would cause a warning message on > the instruction. > > Or might such an option exist? > > -- > Binyamin Dissen > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. >
Re: Missing extended mnemonic in zPoP
Jonathan, thanks for the quick reply. I am aware of the LIST option on HLASM. Actually, I've added code to z390 to mimic its behaviour :-) The point is, I do not have access to HLASM on real iron. So I was wondering whether or not the omission in the PoP had been repeated in HLASM. The proof of the pudding would have been to see the instruction being assembled correctly. I'll take your word for it, HLASM will assemble it just fine. Kind regards, Abe Kornelis == Op 29/03/2018 om 10:05 schreef Jonathan Scott: > Abe Kornelis writes: >> Anybody care to double-check on HLASM being aware of the WFKHEXBS mnemonic? > HLASM definitely supports this mnemonic. You can for example use the > option OPTABLE(ZS8,LIST) to list all mnemonics supported for ZS8. > > Jonathan Scott > HLASM, IBM Hursley, UK >
Missing extended mnemonic in zPoP
All, The latest PoP, Publication No: SA22-7832-11, has a section on VFCHE (opcode E7EA) on page 24-13 ff. The section specifies a list of extended mnemonics associated with the VFCHE instruction. >From the looks of it, the final entry seemed to be missing. So I inquired at IBM whether the postulated mnemonic WFKHEXBS = VFCHE V1,V2,V3,4,12,1 was left out accidentally or on purpose. The other day Bruce Giamei replied that it was omitted inadvertently, and that it will be added in the next version of the PoP. So, thanks to Bruce for the quick follow-up. And anyone who cares enough about details like these, please make a mental note about the missing instruction. Anybody care to double-check on HLASM being aware of the WFKHEXBS mnemonic? Kind regards to you all, Abe Kornelis ==
Re: Special character # on ASM names
Hilario, do not let yourself be confused by the appearance of the character. All characters are actually a hex code between X'00' and X'FF' - the meaning of each code depends on the current codepage. What compiles is the # character in the default codepage, represented by code X'7B'. So make sure you use character code X'7B' - what character gets displayed on your screen is irrelevant. Browse your code in hex mode to make sure you have code X'7B' and not something else. BTW: in Ascii/Unicode the same character is normally encoded as X'23'. If you edit your code on a PC you may need to make sure you have that code. Even if that is correct, you'll have to double check that the source code is translated correctly, so that the source code in Ebcdic on the MF does contain X'7B'. Kind regards & success, Abe Kornelis == Op 24-11-2017 om 11:30 schreef Hilario: > Hello group, > > I have to compile source programs with variables that contain the # > character. When compiling the ASM I get the following error: > > ERR # 1 EQU 1 > ** ASMA143E Bad character in name field - # 1 > ** ASMA167E Required name missing > > I have tried to compile the program with the parameter CODEPAGE with values > of 1145, 1140, ... and I always get the error. > > I am solving the problem by changing the # by @ character. I understand that > there is a correct way to solve this problem. > > Thank you very much. > > Hilario >
Re: z14 PoO Available
Jonathan, Thanks for the reminder. Though it is not visible from the distributed posts on the list - they are sent both to the list and to the official IBM response email address. I get a generated email every time to confirm that the email has been received properly. Kind regards, Abe Kornelis == Op 25-9-2017 om 13:00 schreef Jonathan Scott: > Ref: Your note of Sun, 24 Sep 2017 20:17:29 +0200 > > We welcome reports of any possible errors and other suggestions > relating to the z/Architecture Principles of Operation, which > should be reported to IBM using the process documented in the > section "Communicating Your Comments to IBM" at the back of the > book, for example by sending an email to mhvr...@us.ibm.com > with the appropriate details. > > You can also of course discuss possible errors in the book on > this mailing list, but please do not expect any action to be > taken by IBM as a result! > > Jonathan Scott > HLASM team > IBM Hursley, UK >
Re: z14 PoO Available
Dan, thanks for the elaboration. It seems to me that it is up to the individual user to find a way of pronouncing any mnemonic so as to avoid confusion with unintended alternate meanings ;-) With customers all over the globe, speaking many dozens of languages, collisions - or near-collisions - between mnemonics and inappropriate words in any of these languages are unavoidable. Ask any international marketeer how difficult it can be to devise a registered trademark that can be used all over the globe... Kind regards, Abe === Op 23-9-2017 om 19:03 schreef Dan Greiner: > A bit of history here: > > When PERFORM PSEUDORANDOM NUMBER OPERATION was first being developed circa > 2012, (a) pseudorandom was hyphenated (improperly ... it's really a single > word), and (b) the proposed mnemonic was initially PPRNO, but shortened to > PRNO. One of the firmware developers was concerned that — when pronounced > aloud — PRNO sounded too suggestive for a conservative mainframe company, so > we relented and called it PPNO. (Similar sensitivity training applied to the > mnemonic for COMPARE LOGICAL IMMEDIATE AND TRAP and others.) > > With the addition of the message-security-assist extension 7, where the > instruction can now produce either deterministic or true random numbers, we > decided that the risqué mnemonic was more appropriate (and the firmware > developer had overcome his initial concerns). So now, we're back to PRNO. > > Note Well: As suggested by programming note 4.a (p. 7-358) , PRNO-TRNG is not > the swiftest operation in the instruction set. Programming notes 4.b. and 4.c > suggest periodically using PRNO-TRNG to re-seed a deterministic random number > generator (the frequency of such re-seeding based on the durability of the > DRNG function). >
Re: z14 PoO Available - VFLL instruction
Melvyn, the ripped-apart version exists. It starts from www.bixoft.com/english/opcd00.htm (I'm sorry - many instruction pages are missing currently due to space constraints) It's not the complete PoO - it's just opcode descriptions c.a. Just like Jonathan Scott's proof of concept, it is all generated from a simple list, containing opcodes, mnemonics, mask values, and instruction names. It is tedious work to maintain the list. the joy is in the hlasm macros that convert the input list (it uses AREAD) into html documents. Does it make sense? Of course not! But it's fun. Now you know why I'm reading the PoO with such scrutiny! Kind regards & happy programming! Abe Kornelis == Op 25-9-2017 om 2:12 schreef MELVYN MALTZ: > And wouldn't it be great if it was called z390 and available on a > website called www.z390.org and if just a few Java programmers could > be bothered to spend a few hours achieving just that as Don, Melvyn, > Abe and several others tried to do over the past years...doh. > > And while I'm on the subject, does anyone remember that a few months > ago I wanted the PoOPS ripped apart and reconstructed so that every > single instruction had a page to itself with links ? > My suggestion got trashed...I still can't believe that the guys and > gals here have so little imagination. > > 53 years of assembler coding and still no-one listens to me. > > And just to annoy people even more, enhancing the IBM360 architecture > is like redesigning the T-Rex...it's already extinct guys...time to > move on. > > Melvyn Maltz. > > - Original Message - From: "Gary Weinhold" <weinh...@dkl.com> > To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> > Sent: Sunday, September 24, 2017 11:59 PM > Subject: Re: z14 PoO Available - VFLL instruction > > >> But wouldn't be great if the PoO could just be fed into a software >> emulator creator (in machine-readable format, of course) and out >> would come a software emulator. And the another process could create >> all the chips and microcode. That way the PoO would always exactly >> match the processor. >> >> Gary Weinhold >> >> From: a...@bixoft.nl >> Sent: September 24, 2017 3:01 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Reply to: a...@bixoft.nl >> Subject: Re: z14 PoO Available - VFLL instruction >> >> >> All, >> >> In the new PoO, on page 24-26, Programming Note for VFLL instruction, >> there is what seems to be another copy-paste error. I quote: >> >> * Programming Note*: If a trapping IEEE exception is >> encountered during execution of VECTOR LOAD >> LENGTHENED it is model dependent if the VIX in >> the VXC field is the index of the source or target element >> unless the IBM z/Architecture Principles of >> Operation is installed in which case it is always the >> index of the source element. >> >> Beats me how the PoO could be installed in the processor, >> but maybe I'm taking things too literally? >> >> Can it be it should have referred to the vector-enhancement >> facility 1 ? >> >> Kind regards, >> Abe Kornelis >> == >> >> >> >> Op 15-9-2017 om 8:07 schreef Dan Greiner: >>> The IBM z14 processor is generally available today (14 September 2017). >>> >>> The z/Architecture Principles of Operation corresponding to the new >>> z14 processor is available at >>> http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf >>> >>> The z/Architecture Reference Summary corresponding to the new z14 >>> processor is available at >>> http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >>> >> >> Gary Weinhold >> Senior Application Architect >> >> DATAKINETICS | Data Performance & Optimization >> >> Phone: +1.613.523.5500 x216<tel:+1.613.523.5500%20x216> >> Email: weinh...@dkl.com<mailto:weinh...@dkl.com> >> >> [http://www.dkl.com/wp-content/uploads/2015/07/dkl_logo.png]<http://www.dkl.com/> >> >> >> Visit us online at www.DKL.com<http://www.dkl.com/> >> >> [http://www.dkl.com/wp-content/uploads/2015/08/banner.png]<http://www.dkl.com/mailsig> >> >> >> E-mail Notification: The information contained in this email and any >> attachments is confidential and may be subject to copyright or other >> intellectual property protection. If you are not the intended >> recipient, you are not authorized to use or disclose this >> information, and we request that you notify us by reply mail or >> telephone and delete the original message from your mail system. >> >> >> >
Re: z14 PoO Available - VFLR instruction
All, another typo in the new PoO. This time on page 24-27, where extended mnemonic VLED is specified as taking two vector registers and three masks, but the VFLR equivalent has M4,M4,M5 which I think should have been M3,M4,M5. Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available - VFLL instruction
All, In the new PoO, on page 24-26, Programming Note for VFLL instruction, there is what seems to be another copy-paste error. I quote: * Programming Note*: If a trapping IEEE exception is encountered during execution of VECTOR LOAD LENGTHENED it is model dependent if the VIX in the VXC field is the index of the source or target element unless the IBM z/Architecture Principles of Operation is installed in which case it is always the index of the source element. Beats me how the PoO could be installed in the processor, but maybe I'm taking things too literally? Can it be it should have referred to the vector-enhancement facility 1 ? Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available
All, In the new PoO, on page 24-14, the extended mnemonics for VFCHE are listed. It looks like the last one went missing: WFKHEXBS with mask values 4,12,1 I assume it should have been present? Kind regards, Abe Kornelis. === Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available - SIGP description
All, I just noticed in the new PoO (Publication SA22-7832-11) on page 10-134 (SIGP instruction) in the left-hand column the first programming note seems to be incomplete. Also the more detailed description on page 4-84 has table 4-29 with an incomplete entry for order code 20 = X'14': neither a description is given, nor is the code declared unassigned or reserved. Anybody aware of the status of order code X'14' ? Kind regards, Abe Kornelis Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available
All, In the new PoO (Publication SA22-7832-11) I noticed that opcode B93C has changed it's mnemonic from PPNO to PRNO - probably to reflect it's new ability to perform True Random-Number Generation. For compatibility the PPNO mnemonic is still mentioned in the instruction's description. Nevertheless, the PPNO mnemonic has disappeared from the appendix B. This holds for figures B-1, B-2, and B-3. Isn't it strange that a supported mnemonic is omitted from the appendix? Or was the PPNO mnemonic inadvertently maintained in the instruction description? Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available
All, In the new PoO (Publication SA22-7832-11) I noticed something peculiar. On page 7-308, in the left-hand column (relating to Multiply Single), second bullet, last sentence but one it is stated: For MSG and MSGC, the multiplier is a 64-bit signed binary integer, respectively, at the second-operand location in storage. Knowing that it takes extreme precision to read the PoO correctly, I am wondering about the meaning of the word "respectively" in this sentence. It seems superfluous. Am I mistaken? If so, then what is its significance? Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available
All, I just noticed a typo in the new PoO (Publication SA22-7832-11): in figure 4-18 on page 4-65 the entry for GSC=37 specifies GSD bits 0-27. It seems GSD bits 0-26 would have been the correct value. Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: z14 PoO Available
Dan, thanks for posting the links. I'll cross-post it to the z390 list. Kind regards, Abe Kornelis == Op 15-9-2017 om 8:07 schreef Dan Greiner: > The IBM z14 processor is generally available today (14 September 2017). > > The z/Architecture Principles of Operation corresponding to the new z14 > processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf > > The z/Architecture Reference Summary corresponding to the new z14 processor > is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf >
Re: HLASM "Anomaly"
Paul, To my mind, X'' is also -1, which is in the halfword range. Thus it merits a warning as the assembler cannot know whether the X'' value of H5 is intended to be signed or unsigned. Neither should it make any assumptions. So I'm entirely fine with HLASM accepting the value and using it, while issuing a warning. It does what it is told to do, but it might not be what the programmer intended it to do ;-) Abe Kornelis === Op 18-3-2017 om 23:21 schreef Paul Gilmartin: > Compare this with LHI 1,H5 and the next which generate a warning (do > we need the warning ?) > Yes, since X'' is 65535, and not in the halfword range, -32768 to +32767. >
Re: How to automatically position generated data areas after all program-defined areas
Peter, For the case you are describing it seems to me that LOCTR would be the simplest solution. Even so, Keven is right: the END instruction can be replaced with macro. You could define the macro in your MACINIT macro (nested macro definition) including the required OPSYN statement. I used an END replacement macro to produce a subroutine cross reference at the end of the program listing. You could use an END replacement to do all kinds of other nifty stuff. Some experience in writing macros is needed, but from your mail I understand that should not be a problem at all ;-) Kind regards & success! Abe Kornelis Op 17-3-2017 om 22:22 schreef Keven Hall: > Peter, > If the END assembler directive is one that can be redefined, you could write > your own END macro that inserts any required data areas and generates an _END > (or whatever it is that END was redefined as). > > > Keven > >> On Mar 17, 2017, at 12:29, Farley, Peter x23353 >> <peter.far...@broadridge.com> wrote: >> >> I cannot see a way to do the following, so any enlightenment you can provide >> is appreciated. >> >> I have created new versions of an existing set of macros and the new >> versions require a fairly large set of non-reentrant data areas defined in >> the CSECT in which they are used. The first macro invoked (say, MACINIT) >> needs to define these areas in existing assembler programs that may or may >> not be close to exceeding their defined base registers. This is old, >> non-reentrant code that has not been converted to "baseless" mode, and doing >> that conversion now is not on the table due to time and resource constraints. >> >> Rather than defining the new data areas at the place where MACINIT is >> invoked (there is code as well as data in MACINIT, and the code has to be >> positioned near the start of the program), I would like to be able to have >> MACINIT place all of the new data areas AFTER all other data or code defined >> in the CSECT. >> >> All of the new data areas are referred to in the new macro versions by >> "relative long" instructions in the generated code, so they will work >> correctly even if the data areas are totally outside of the defined base >> register coverage areas. >> >> I have looked at the LOCCTR assembler instruction thinking that it might be >> a way to accomplish what I want to do, but I am not really clear on how to >> use it, or even if that is a way for me to do what I want to do. >> >> So far the only way to accomplish this that I can see is to have a separate >> "MACDATA" macro to be manually inserted into the old code at the appropriate >> position. I would prefer an automated solution that does not require a new >> "data" macro, if at all possible. >> >> TIA for any help you can provide. >> >> Peter >> >> >> This message and any attachments are intended only for the use of the >> addressee and may contain information that is privileged and confidential. >> If the reader of the message is not the intended recipient or an authorized >> representative of the intended recipient, you are hereby notified that any >> dissemination of this communication is strictly prohibited. If you have >> received this communication in error, please notify us immediately by e-mail >> and delete the message and any attachments from your system.
Re: ASSEMBLER-LIST Digest - 24 Feb 2017 to 25 Feb 2017 (#2017-14)
John,
welcome back! :-)
Kind regards,
Abe Kornelis
===
Op 26-2-2017 om 6:21 schreef John Ehrman:
> Well, maybe not. I was laid off ("retired") by IBM last June, and managed to
> get back to this list only a few days ago. I'll try to keep active if I
> haven't forgotten too much.
> John Ehrman
> - Original Message -
>
> From: "ASSEMBLER-LIST automatic digest system" <lists...@listserv.uga.edu>
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Sent: Saturday, February 25, 2017 9:00:04 PM
> Subject: ASSEMBLER-LIST Digest - 24 Feb 2017 to 25 Feb 2017 (#2017-14)
>
> Date: Sat, 25 Feb 2017 10:05:57 -0500
> From: Steve Smith <sasd...@gmail.com>
> Subject: Re: HLASM anomaly
>
> Have you not seen the many prior discussions of this excruciating topic?
>
Re: EXECUTE Instruction and location of its target instruction
Philippe, Most of your questions have already been answered by others. The one thing not yet addressed is this one: > Reviewing old Assembler programs, I guess I am surprised to see enough often > that all target instructions for ALL the Execute instructions coded in the > programs grouped mostly at the end... > The reason for this is, in (much) older hardware there was no I-cache versus D-cache, so the performance penalty for not being in the same cache line did not exist. I hope this helps - not in solving your problem, but in understanding how things have come about. Kind regards, Abe Kornelis ===
Re: Use of LQ results in ASMA080E?!
Martin, all, As I read it, you could even use z390 (supported on any Java platform) to create an object deck, then pass that as input to Dave's binder/linker. Am I right, Dave? Abe Kornelis z390 support team. = Op 5-1-2016 om 17:49 schreef mar...@pi-sysprog.de: > Dave, > > let me see if i have this right- > > one can use the HLASM on z/OS (it's there anyway) and > > then use your "binder/linker" to produce stuff that can then be > processed by LNKEDT in z/VSE > > (I omitted the obvious step of running binder in z/OS to produce a > loadable module) >
Re: Use of LQ results in ASMA080E?!
Dave, all, as z390 claims to produce MVS-compatible object deck output, that should not be a problem, then. Thanks for your quick answer! Kind regards & best wishes for 2016 to all of you! Abe === Op 5-1-2016 om 21:52 schreef Dave Rivers: > Hi Abe, > > Sure! As long as it’s standard OBJ, GOFF or XOBJ object format it can be > input to our linker (and, for that matter, IBM’s binder.) > > - Dave R. - > >> On Jan 5, 2016, at 3:45 PM, Abe Kornelis <a...@bixoft.nl> wrote: >> >> Martin, all, >> >> As I read it, you could even use z390 (supported on any Java platform) >> to create an object deck, then pass that as input to Dave's binder/linker. >> >> Am I right, Dave? >> >> Abe Kornelis >> z390 support team. >> = >> >> >> Op 5-1-2016 om 17:49 schreef mar...@pi-sysprog.de: >>> Dave, >>> >>> let me see if i have this right- >>> >>> one can use the HLASM on z/OS (it's there anyway) and >>> >>> then use your "binder/linker" to produce stuff that can then be >>> processed by LNKEDT in z/VSE >>> >>> (I omitted the obvious step of running binder in z/OS to produce a >>> loadable module) >>>
Re: ENQ rname_addr description
Gil, I have always interpreted as qualified by the qname, though I will gladly admit this is an inference not directly implied by the text itself, and therefore subject to discussion. (not intending to start one right now, though). Just my 2p. Abe Kornelis === Op 26-8-2015 om 15:18 schreef Paul Gilmartin: In: z/OS MVS Programming: Assembler Services Reference ABE-HSP SA23-1369-00 under ENQ I read: ... ,rname addr Specifies the address of the name used together with qname to represent a single resource. The name must be from 1 to 255 bytes long, can be qualified, and can contain any valid hexadecimal character. What's a qualified name, as opposed to unqualified? Does this simply mean a conventional data set name containing periods is acceptable? If so, I believe that can be qualified adds no meaning to the description. I do intend to submit an RCF about the otiose and possibly misleading use of valid and hexadecimal. I believe there's no such thing as an invalid or non-hexadecimal character which must not appear in the rname. -- gil
Re: 360/20 instruction macros
Glen, thanks a bunch! Abe. === glen herrmannsfeldt schreef op 27-5-2015 om 3:03: *** SET PS
Re: 360/20 instructions
Robert, both the mnemonics and the opcodes were re-used, though the meaning changed from Branch and Store (Register) in 360/20 to Branch and Save (Register) in S370/XA. Tony, thanks for the additional info. Melvyn, I was aware of the DIAGNOSE instruction, though I've never been able to figure out the associated function codes and their meanings. thanks for the update anyway. Kind regards to you all, Abe Kornelis == Robert A. Rosenberg schreef op 26-5-2015 om 6:25: I may be wrong but I have the Impression hat the 360/20 version of BAS/BASR (that machine's equivalent to BAL/BALR had a different op code from the current BAS/BASR.
Re: 360/20 instructions
Glen, I have extracted the information I need from the manuals: mnemonics, opcodes, assembled instruction formats. But the I/O instructions (CIO, TIOB, XIO) have an unusual format, and there were no source code examples. So you have a copy of the macros you mentioned? Would you be willing to share these macros? I'd like to use them to determine the operand formats used in source code. Thanks in advance, Abe Kornelis. == glen herrmannsfeldt schreef op 21-5-2015 om 21:36: The detail on the instructions are in: httt://www.bitsavers.org/pdf/ibm/360/funcChar/A26-5847-3_360-20_funChar_Apr67.pdf The HRTBP360 program that IBM still distributes, I am told, with HASP, uses macros for the 360/20 specific instructions. (It was written to assembler with OS/360 or OS/VS2 assemblers.) The macros seem to still work with new assemblers. -- glen
Re: 360/20 instructions
Thank you all for the various pointers I received. I have some howmework to. Luckily, it's nearly weekend... Abe === glen herrmannsfeldt schreef op 21-5-2015 om 21:36: The detail on the instructions are in: httt://www.bitsavers.org/pdf/ibm/360/funcChar/A26-5847-3_360-20_funChar_Apr67.pdf The HRTBP360 program that IBM still distributes, I am told, with HASP, uses macros for the 360/20 specific instructions. (It was written to assembler with OS/360 or OS/VS2 assemblers.) The macros seem to still work with new assemblers. -- glen
Re: unusual instructions
Glen, do you have any information available on these 360/20 specific instructions? I would like to use the info to update the instruction lists and charts on hlasm.com. Also, if time permits, I might add support for these instructions in z390. Cheers, Abe Kornelis == glen herrmannsfeldt schreef op 21-5-2015 om 19:44: The OP said he was working with code for a model 20. That was only barely a true S360 and had a few instructions peculiar to it. Yes. XIO is the I/O instruction that reads or writes. Like other 360's, I/O is asynchronous. You have to test (with TIOB) to see if it is done yet. With 8K core, half the core is available without a base register. As I understand it, many were only 4K. It does have some fairly complex instructions, such as DP, ED, and TR, and leaves out some simple ones like L and LR. Registers are 16 bits, so LH, AH, SH, CH, and STH are there. AR and SR, but not most of the other RR instructions. PACK, UNPK, MVO, ZAP, AP, SP, CP, MP, DP so full decimal arithmetic. MVI, MVN, MVZ, CLI, MVC, CLC, NI, OI, ED, BR, B, BASR, BAS. and then the model 20 specific: XIO, TIOB, HPR, SPSW. -- glen
Re: LNKEDT 64-bit mode assembler in AMODE 31
Agreed. Switching to BSAM might be another way to speed the thing up. Abe Kornelis. === Gary Weinhold schreef op 5-5-2015 om 17:50: Sounds like buffering records (like 100) or so into 31-bit memory in AMODE 31 and then looping on the load in AMODE64 could improve things. On 2015-05-05 11:35, Brite wrote: The program is mainly in AMODE 31. It switches to AMODE 64 using SAM64 only when need to use the table in storage above 2GB and switches back after. Can this explain why I only notice significant delay during initial load? It loads a table of 200,000 records from QSAM file to the memory. It switches AMODE back and forth at least 3 times for each record.
Re: Assembler Quiz
Tom, I figured that out after I sent the email. Thanks for trying to help me :-) I maintain it's a nifty piece of code... Abe === Tom Marchant schreef op 30-3-2015 om 15:32: On Sun, 29 Mar 2015 21:44:01 +0200, Abe Kornelis wrote: where the literal ultimately assembles as AL(3)(2) I.e. the trailing (1) has been trimmed off and the generated value is X'02' as expected. Look again, Abe. The (1) is an index register specification. i.e. 4101 C008
Re: Assembler Quiz
All, just tried it on z390. I get the following instruction: LA 0,=AL(3)(2)(1) which assembles as 4101C1C8 where the literal ultimately assembles as AL(3)(2) I.e. the trailing (1) has been trimmed off and the generated value is X'02' as expected. This matches HLASM behaviour exactly. Again, I am surprised by the robustness of the z390 code. Chapeau for Don Higgins (creator of the z390 assembler emulator) And thanks to John Ehrman for testing our wit :-) Kind regards, Abe Kornelis (maintenance coordinator for z390) John Ehrman schreef op 26-3-2015 om 23:07: Steve Smith asked for the answer to my quiz question of March 23: While we're having fun: under what circumstances is the character sequence (4)(3)(2)(1) legal as part of a machine instruction operand, not part of a quoted string, not part of a macro operand, and not part of a SETC statement? And no, it's not an April-Fool question. Here's the answer: USING *,12 V(4) SETC 'L' LA 0,=AV(4)(3)(2)(1) END Try assembling it! (And no, it wasn't my idea originally.) Regards... John
Re: HLASM operand order vs. instruction operand order
Peter, I'm too young to know how this has come into existence. I do know how I explain this to students, though. 1) the machine instructions were architected for machine use 2) the assembler instructions are devised for programmer use For the first two operands I apply these rules-of-thumb: a) for a register and a storage operand, the register comes first, followed by the storage operand b) for operands of equal type (whether two registers or two storage locations) destination comes before source I don't doubt there will be exceptions, and some on this list will be able to name them without thinking, but these rules have served me and my students pretty well. It's not much of an explanation, but it may help. Kind regards, Abe Kornelis. === Farley, Peter x23353 schreef op 26-3-2015 om 21:45: I guess this question is mostly for John Ehrman, but others may have insight as well. For the same machine instruction format, there are sometimes two different HLASM operand orders used for the operands of instructions. For example, LOC has HLASM operands in order 1,2,3 while STMCH operands are in order 1,3,2 and the machine instruction operands are in order 1,3,2: LOC R1,D2(B2),M3 [RSY-b] 'EB' R1 M3 B2 DL2 DH2 'F2' 0 812 1620 32 40 47 STCMHR1,M3,D2(B2)[RSY-b] 'EB' R1 M3 B2 DL2 DH2 '2D' 0 812 1620 32 40 47 Here is a second example, LPD has HLASM order 3,1,2 while MVCOS has HLASM order 1,2,3 and the machine operands are in order 3,1,2: LPDR3,D1(B1),D2(B2) [SSF] 'C8' R3 '4'B1 D1 B2 D2 081216 2032 36 47 MVCOS D1(B1),D2(B2),R3 [SSF] 'C8' R3 '0' B1 D1 B2 D2 0812 16 20 32 36 47 Am I the only one to whom the inconsistency seems arbitrary? Or am I missing some salient characteristic that explains the differences? Peter -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Assembler Quiz
Nifty, I doubt I'd ever dream that up. thanks for the fun moment. And - if used in real code - does deserve some additional comments... Abe Kornelis == John Ehrman schreef op 26-3-2015 om 23:07: Steve Smith asked for the answer to my quiz question of March 23: While we're having fun: under what circumstances is the character sequence (4)(3)(2)(1) legal as part of a machine instruction operand, not part of a quoted string, not part of a macro operand, and not part of a SETC statement? And no, it's not an April-Fool question. Here's the answer: USING *,12 V(4) SETC 'L' LA 0,=AV(4)(3)(2)(1) END Try assembling it! (And no, it wasn't my idea originally.) Regards... John
New Principles of Operation
All, I just downloaded the new version of the Principles of Operation SA22-7832-10 from IBM. The vector new vector architecture looks interesting, but completely different from the old vector architecture. Regards, Abe Kornelis ==
Re: (My) John Ehrman Assembler Book
John, I cannot but replicate the many thanks and compliments expressed by others on both IBM-Main and the Assembler-list. Now I surely won't need to get a book from the library for my vacation. This'll be much more fun! Finding Z13 in the title I had hoped to find some info on the new instructions. I am especially interested in the vector architecture and instructions. To explain the vector architecture well, embellished with examples, exercises and solutions, you might end up with a volume that satisfies Lizette's desires? Kind regards Abe Kornelis == John Ehrman schreef op 9-2-2015 om 19:40: Richard Lawrence posted: The long awaited John Ehrman Assembler book as available at the Marist College web site: http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf I appreciate the many kind comments posted on these discussion lists. Please note that some fixes will be in the next update: (1) The fragmentary index after the preface/introduction will be removed. (2) The solutions for sections 25 and 26 will be restored. (3) Various typographic errors will be fixed. (4) Some minor text reorganizations. Rather than adding change bars, I plan to add an Updates section somewhere at the front or back of the text explaining differences from version to version. After those are finished: (n) I'm currently preparing some lecturer materials like presentation slides. (n+1) A major item will be to add hyperlinks for contents and cross-references. (n+2) I apologize, Lizette, but I doubt I'll add another 1200 pages any time soon. John Ehrman (ehr...@us.ibm.com) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 8 character mnemonics
Chris, Unless my grasp of the English language it failing me, I would be utterly hesitant to relocate to any location ascribed to a Wight ;-) Kind regards Abe Kornelis == Chris Bowen schreef op 26-1-2015 om 10:34: With apologies for lateness and to those with unaware of the received wisdom about parts of Southern England (almost everybody?). Ain't progress wonderful? Anyone know how to stop it ? (progress that is) Relocate to the Isle of Wight?
Re: 8 character mnemonics
John, I have various macros that use embedded macros. To avoid naming collisions I have always used more than 8 characters to name these macros. I can tell you: it has worked fine for me from day one. Kind regards, Abe Kornelis. == John Ehrman schreef op 21-1-2015 om 20:02: Dave Cole noted again... But it does make me wonder if they might eventually go to 9 or longer... I think HLASM has supported operation field entries longer than 8 characters for a long time, but resolution was possible only to source macros. (No, I haven't tried it.) John Ehrman
Re: Reference summary for 360/20
Tony, thanks! Added the document to my library. I noticed there are a few 'uncommon' instructions. As time permits I'll add these to the charts and tables on my site. Cheers, Abe === Tony Harminc schreef op 3-12-2014 17:50: On 3 December 2014 at 00:27, Robert A. Rosenberg a...@rarpsl.com wrote: https://archive.org/details/bitsavers_ibm360refeystem360ReferenceData_662124 ibm :: 360 :: referenceCard :: GX20-1703-9 System360 Reference Data Unfortunately, as others have noted, this for IBM360 model 30 and above. The IBM360 Model 20 had a similar but much smaller and incompatible instruction set. However Bitsavers does have the IBM System/360 Model 20 Functional Characteristics book, A26-5847-3, which while it is not a reference card, does contain the complete description of both the instruction set architecture and the 360/20's unique I/O architecture for the supported devices. The whole thing is 135 pages. Tony H.
Re: Reference summary for 360/20
Well, I attempted something like that: http://www.bixoft.com/english/opcd00.htm and http://www.bixoft.com/english/opcodes.htm Also I have created an extensive list of instruction tables starting at e.g. http://www.bixoft.com/english/opl_bbbm.htm I had to give up on keeping everything up-to-date. Also, the detailed instruction examples have never been extended beyond X'3F'. Maybe after my retirement I'll find to fix all the flaws and omissions... In the meantime, anyone who finds these charts and tables useful is welcome to use the material I provided. Kind regards, Abe Kornelis. === glen herrmannsfeldt schreef op 14-11-2014 18:46: The mention of instruction sets and green cards reminds me, does anyone have a (scan of) a 360/20 Reference Summary? Some places indicate that it might be yellow or red. -- glen
Re: Syntax for using created SET symbols in a SETC value?
Peter, after reviewing John Ehrman's document Assembler Language as a Higher Level Language: Macros and Conditional Assembly Techniques - SHARE 95,Sessions 8167-8168 I was inspired to write a DCL macro that enabled me to define bit fields by name. The byte location, flag value, and their association were managed by the macro. When I would code an IF macro using the bit name, the macro would expand to use the proper field name and flag. Same for Set/Reset etc. So - as noted before - the problem is solvable, but it does take quite some macro coding. And therefore time as well, of course... Reading John Ehrman's document may save you some of that time ;-) Kind regards, Abe Kornelis === Farley, Peter x23353 schreef op 4-10-2014 21:13: John, Thank you for that example, it helps a lot. The example I gave was generating DC lines for the sake of figuring out the proper syntax. My real goal is a bit different. I have a static list of 64 flag bit names (each one like Flag_A EQU X'80'). I want to create a flag-test macro FTEST to test one or more of those bit flags against a set of 8 flag bytes, each named FLAGn, 1 = n = 8. So if Flag_A is defined as a bit in Flag1, I will generate a test like: FTEST Somewhere,Flag_A +TMFlag1,Flag_A +BOSomewhere And if a list of multiple flag names are provided to the test macro, the result should resemble: FTEST Somewhere, (Flag_P,Flag_H,Flag_G,Flag_A) +TMFlag1,Flag_A+Flag_G+Flag_H +BOSomewhere +TMFlag2,Flag_P +BOSomewhere Obviously the trick is to associate a flag number with each name, and to sort the list of flag names provided to the FTEST macro by the flag byte number so that all tests against the same flag byte are grouped together. Also, other than a manually created list of GBLA definitions and SETA initializations for the flag names (like GBLA Flag_A and Flag_A SETA 1), is it possible to create a loop that dynamically computes the flag number for each name (where the flag names are stored in the proper order in an initialized GBLC array) and dynamically creates the GBLA and SETA lines? I.E., is it legal to loop over GBLA as well as SETA statements? Have you solved a problem like this already, or can you suggest an approach that will work for such a macro? Thank you again for your clear example. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Gilmore Sent: Saturday, October 04, 2014 1:05 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Syntax for using created SET symbols in a SETC value? Consider |F1id setc '__F1' --array 1 identifier |F2id setc '__F2' --array 2 identifier |F3id setc '__F3' --array 3 identifier |gblc (F1id)(1) --declare array 1 w/o giving it elements |gblc (F2id)(1) --declare array 2 w/o giving it elements |gblc (F3id)(1) --declare array 3 w/o giving it elements |(F1id)(1) setc 'a','b','c' --initialize/create first 3 elements of array 1 |(F2id)(1) setc 'd','e','f' --initialize/create first 3 elements of array 2 |(F3id)(1) setc 'g','h','i' --initialize/create first 3 elements of array 3 |idaid(1) setc 'F1id','F2id'.'F3id' --array of array identifiers |arraysn seta n'idaid --number of array identifiers |i seta 0 --initialize arrays index |.arrays_loop anop , --top of arrays loop |i seta i+1--increment arrays index |eoa setb (i gt arraysn) --arrays exhausted? | aif (eoa).arrays_lend--if so, leave arrays loop |aident setc '(idaid)(i)' --identifier of array i |elemsn seta n'(aident) --element count array i |j seta 0 --initialize elements index |.elems_loop --top of array i elements loop |j seta j+1--increment elements index |eoe setb (j gt elemsn) --elements of array i exhausted? | aif(eoe).elems_lend--if so, leave elements loop |label setc 'F'.'i'.'j'--DC label |target setc '(aident)(j)' --DC target value |label DC C'target' | ago .elems_loop --next element da capo |.elems_lend anop , --bottom of elements loop | ago .arrays_loop --next array da capo |.arrays_lend anop , --bottom of arrays loop | . . . The only thing problematic about this is the statement |label setc 'F'.'i'.'j'--DC label Suppose you have 0 i 15 0 j 30 within these loops. Then element 29 of array 1 will have the label 'F'.'1'.'29' or F129, and element 9 of array 12 will have the label 'F'.'12'.'9' = F129 too. This sort of thing can be dealt with easily using the A2D builtin function and leading-zeros padding to ensure that the character representations of i all have the same number of digits and that those of j all have the same perhaps different number of digits. I can elaborate on this if it seems opaque
Re: Macro to generate DS or DC
Gary, I'm not sure whether there are any extant solutions. My tuppence: Create an XSECT macro that will AREAD source code until you reach a marker. Have the XSECT macro re-emit all DC/DS/EQU statements (inlcuding a leading DSECT) while saving them for later re-use. Then when allocating an instance of your DSECT, call XSECT with the section-name you assigned so that it will re-emit all statements it has stored when it was first invoked with only a label as parameter. I use OPSYN to replace DS/DC/EQU with my own like-named macros. Macros DSOVR/DCOVR/EQUOVR are used to store overrides which are considered when DS/DC/EQU are expanded. This enables me to override definitions inside IBM-supplied mapping macros without needing to modify the macros themselves. E.g. I use overrides to associate bit names with flag values and byte locations so that I do not need to remember these housekeeping details. Kind regards success! Abe Kornelis === Gary Weinhold schreef op 2-10-2014 18:14: I am trying to develop a technique to force a DSECT (describing some private control block of mine) to stay synchronized with the inline-constant and space-reserving versions of the same control block. For example, for DSECT ABC with field definitions of ABCIDDSCL4 Eyecatcher ABCLEN DSAL2 Length of ABC ABCLVL DSAL2 ABC modification level ABCDATA DSF Some binary data ABCL EQU (*-ABCID) I would like to be able to generate in-line constants: label1 DS0F DCCL4'EYEC' DCAL2(ABCL) DCAL2(1) DCF'0' ABCL EQU (*-label1) and space: label2 DSCL(ABCL) The DSDC macro generates a labeled DS statements or unlabeled DC statements depending on TYPE; its format is, for example: ABCEYE DSDC CL4,C'ABCD','EYECATCHER',TYPE ABCLEN DSDC AL2,(ABCBLKLN),'LENGTH OF THIS CONTROL BLOCK',TYPE Although I started work on this with a macro I call DSDC, I was wondering if I'm reinventing the wheel. Is there a model for this out there? Any suggestions are welcome. Gary Weinhold Data Kinetics, Ltd.
Re: Instruction Lists/Counts.
Dave, thank you for mentioning hlasm.com. There is no straightforward way of counting instructions. There are many ways to count them, many criteria by which to discern or categorize them. I have tried to present the instruction lists with options to include/exclude various (sub)categories, but have never felt the need to create overviews cross-sectioned according to the criteria you mentioned. Which means: you'll have to do it yourself. And btw: after the latest PoP was published I was working on including the newest instructions in the lists and charts, but unfortunately my PC broke down, and then the project got stalled. So at this moment the hlasm.com overviews are not entirely up-tp-date :-( Kind regards, and success! Abe Kornelis. === Op 15-2-2013 20:57, Gibney, Dave schreef: I am doing a high (very high) level presentation for my managers who have no MF experience. I want a simple slide. Something like: IBM architecture is not RISC, there are nnn instructions. nnn Privileged nnn General nnn Decimal nnn Cryptographic etc. I've Googled and looked at some of the sites in the Dino ring including hlasm.com and haven't found it. I don't find a nice set of counts in Pops either. Anyone know of such a list(s) Dave Gibney Information Technology Services Washington State University - Geen virus gevonden in dit bericht. Gecontroleerd door AVG - www.avg.com Versie: 2013.0.2899 / Virusdatabase: 2639/6105 - datum van uitgifte: 02/15/13
Re: Determine if a dataset contains line numbers
John, That works in most cases. The exception being data cards to be consumed by AREAD, which may contain data in columns 73-80. I admit no sensible programmer would/should do that, those columns being prone to being inadvertently renumbered, but they might, they just might contain real data... Cheers, Abe Kornelis Creating Value from IT. What I do, after I download ASM source or JCL or anything else which __might__ have sequence number in it to mess me up, is unconditionally remove whatever may be in columns 73-end_of_record, then remove trailing blanks too. It is simple with Perl (I use Linux on my desktop, not Windows). John McKown
Re: z12 new instruction list
All, since we're at it. There's quite a collection ata www.hlasm.com/english/humor.htm My favorite: ACQT - Advance Cpu-clock to Quitting Time Cheers, Abe. - Original Message - From: Keith E. Moe ke...@sbcglobal.net To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Thursday, July 28, 2011 4:22 AM Subject: Re: z12 new instruction list My all time favorite from the 360/30 days (1966) is: TSH - Trap Secretary and Halt On Wed, 27 Jul 2011 14:41:01 -0400, Gross, Randall [GCG-PFS] wrote: How about some of my favorites: SG - store garbage TTZ - transfer to twilight zone (typically used with SG, above) CFM - come from RWD - rewind disk BSP - backspace card punch
Re: Subjectify my objectivity
On Sat, 14 Aug 2010 19:31:38 +1000, robin wrote: On 8/13/2010 11:22 PM, Ott, Jeff wrote: SR R1,R1 LH R1,STUFF is one of my favs. Probably he was thinking of (or used) IC, then changed to LH. **-- Don't count on it. I've had to maintain a program that was riddled with this kind of logic. Clear a register before loading anything into it, regardless of instruction used. It also featured a subroutine that would emulate EDMK. And to check whether or not a number was divisable by 9 it would add all digits, then check whether or not dividing that sum by 9 would yield a zero remainder. It's all rather annoying, but didn't we all start out empty-handed? Please be a bit kind to the person who had to find a way of getting a job done. A job he/she apparently was not too familiar with. Cheers, Abe. ===
Re: OP-code C8 3
On Mon, 9 Aug 2010 16:43:00 -0500, Peurifoy, Richard L wrote: - David Bond david-b...@comcast.net wrote: There is a millicode-only instruction with a mnemonic of MVCX. It is used by millicode for variable-length moves without the need for EX+MVC. (The Execute instructions are really slow on modern machines.) MVCX is used by the millicode for MVCL and other instructions. We know of the MVCX mnemonic but not the op-code or the operand format. This seems like a good instruction for general use, any idea why it was not made available outside of millicode? David, thanks for your explanation. Richard, one can only guess. They keep their mouths pretty well shut :-( There's a chance that MVCX uses address fields (Displacement-Base, probably) to indirectly address one or more registers partaking in the execution of the instruction. The physical processor has an array of 256 registers. There's a set 16 assigned to be GPRs, a set assigned to be ARs, FPRs, CRs, Millicode-only registers, etc. Addressing them by number is not something that makes sense outside the millicode scope... Just a guess... Cheers, Abe Kornelis. =
