Re: BXLE usage assistance

You are right, of course. What we needed was BXL, but that does not exist. Gunnar -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Thursday, May 30, 2024 2:03 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BXLE usage assistance Not quite

Re: BXLE usage assistance

/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of g...@altiboxmail.no Sent: Wednesday, May 29, 2024 6:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BXLE usage assistance The BXLE

Re: BXLE usage assistance

The BXLE will work in this case, it is clearly explained in the Principles of Operation manual. End the loop with BXLE R1,R3,LOOP R3 must be an even register, then R3 shall hold the increment and R3+1 the compare value. Before the LOOP set R3+1 = array + total length, and R1 = start of first

Re: BXLE usage assistance

: Wednesday, May 29, 2024 5:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BXLE usage assistance I believe there's a branch relative version too; JXLE. On 2024-05-29 4:57 p.m., Seymour J Metz wrote: > EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do > not click

Re: BXLE usage assistance

I believe there's a branch relative version too; JXLE. On 2024-05-29 4:57 p.m., Seymour J Metz wrote: EXTERNAL EMAIL ALERT This email originated from outside of DataKinetics. Do not click links or open any attachments unless you both recognize the sender, and know the content is safe.

Re: BXLE usage assistance

LHRODD,ARRAYLEN LARODD,ARRAYFIRST-1(RODD) LARPTR,ARRAYFIRST LOOP LHREVEN,0(,RPTR) ... BXLE RPTR,REVEN,LOOP where REVEN,RODD is a register pair. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח

Re: BXLE usage assistance

Mark, Here is a code fragment where we use BXLE (fixed width font, hope this comes through): R:A 030D84068 USING VERVPR,R10 ESTAB BASE REG 00311E 5840 D0D8001FC 4069 L R4,VPRTADDR Point at exclude stack 003122 4160 0032

Re: BXLE usage assistance

Mark, There are several excellent examples in the z/Architecture Principles of Operation in Appendix A. Tom Harper Phoenix Software International Sent from my iPhone > On May 29, 2024, at 3:03 PM, Mark > <176dcd91c5b1-dmarc-requ...@listserv.uga.edu> wrote: > > Hello, > > I'm

Re: Assembler Listing PRINT OFF Issue

This sort of sounds like "Doctor, doctor - it hurts when I do this" At any rate, I wonder if you could use OPSYN on those special statements and have the OPSYN replacement macro issue an MNOTE before reissuing the instruction. On Tue, 28 May 2024 12:02:48 -0400 David Clark wrote: :>I think

Re: Assembler Listing PRINT OFF Issue

You should use PUSH PRINT PRINT OFF . . . POP PRINT On Tue, 28 May 2024 16:32:01 + Willy Jensen wrote: :>Well, I have a couple of assembler copy books that are 1000+ records in size. So normally the COPY statements are inside a PRINT OFF and PRINT ON set. Then

Re: Toolkit support for compare and jump?

@LISTSERV.UGA.EDU Subject: Re: Toolkit support for compare and jump? Shipped in 2020: https://www.ibm.com/support/pages/apar/PH31153 Jonathan Scott, HLASM IBM Hursley, UK

Re: Toolkit support for compare and jump?

Format is IF CIJ,R1,EQ,00 Or IF CLIJ,R1,EQ,0 X'F00'won't work; the operand is 1 byte -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, 29 May 2024 16:01 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU

Re: Toolkit support for compare and jump?

Shipped in 2020: https://www.ibm.com/support/pages/apar/PH31153 Jonathan Scott, HLASM IBM Hursley, UK

Re: Assembler Listing PRINT OFF Issue

You can use the assembler options PCONTROL(GEN,ON) to override PRINT NOGEN and PRINT OFF statements without having to change source code. https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=ao-pcontrol Jonathan Scott, HLASM IBM Hursley, UK

Re: [External Sender] Re: Assembler Listing PRINT OFF Issue

Although I know what SYSLIB, TSO, and ISPF are, I wouldn't know how to apply that suggestion in our z/VSE shop. Oh, and add the COPY statement to that list of statements that would still show through PRINT OFF. So, instead of this: 153 *

Re: Assembler Listing PRINT OFF Issue

On 5/28/24 10:02, David Clark wrote: ... Obviously, having copy names match is desirable. But, when there are multiple macros or dsects in a single copy source then it is not possible. If y'all don't have a solution for this then it should be an enhancement request. . An Idea for HLASM

Re: [External Sender] Re: Changing BRANCH to JUMP...

Not in this case. When multiple macros are included from a single copybook, there is no indication in that section of the listing as to from where such macros came. Yes, it has the name(s) of the macro but not where it came from. In my case, the copy code also had PRINT OFF around it. The

Re: [External Sender] Re: Changing BRANCH to JUMP...

On 5/24/2024 8:58 AM, David Clark wrote: Can't find that macro, either. Now what? ;-) The "Macro and Copy Code Source Summary" on the HLASM listing shows from which library every macro and copy code member was read. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive

Re: Changing BRANCH to JUMP...

of Martin Trübner <1237eee49f7e-dmarc-requ...@listserv.uga.edu> Sent: Friday, May 24, 2024 11:34 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Changing BRANCH to JUMP... Dave, BK never existed- could this be an inhouse macro? What is the condition that is in the corresponding 47instr

Re: [External Sender] Re: Changing BRANCH to JUMP...

Nevermind... I found them both in a copybook for my IF/THEN/ELSE/ENDIF logical construct set. I missed them when I went though initially to change over to relative jump instructions. Fixing them now. Thanks for listening. ;-) Sincerely, Dave Clark -- int.ext: 91078 direct: (937) 531-6378

Re: [External Sender] Re: Changing BRANCH to JUMP...

Thanks, Martin. The existing code that has worked for years and years looked like this. IF R8,(K,ALR),R8 MVI 0(R9),C'1' ENDIF That generated assembled code that looked like this. 787 ALR R8,R8 788 BNK ELSE0017 789+ BC12,ELSE0017 branch on no carry

Re: Changing BRANCH to JUMP...

Dave, BK never existed- could this be an inhouse macro? What is the condition that is in the corresponding 47instruction? or- how would you code the nn in this: BC nn,label Martin On 24.05.24 17:16, David Clark wrote: Some time back I changed my logical construct macro sets to use the

Re: Instructions by Machine

Robert Ngan writes: > Maybe what we need is a new HARDWARE table type that groups by instruction > availability instead on mnemonic introduction (I was going to suggest > MACHINE but that already used as a synonym for OPTABLE). The reason that HLASM does not retrofit new mnemonics to old tables

Re: Instructions by Machine

as a synonym for OPTABLE). Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Emir Garza Sent: Wednesday, May 15, 2024 10:34 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instructions by Machine [Some people who received this message don't often get

Re: WHERE in debugger?

5:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: WHERE in debugger? Hello Shmuel: Good afternoon. I lurk on the Assembler list and watch your posts go by. z/XDC can do all you're looking for and much, much more. That said, it's a professional engineering tool and it costs money

Re: WHERE in debugger?

Hello Shmuel: Good afternoon.  I lurk on the Assembler list and watch your posts go by. z/XDC can do all you're looking for and much, much more.  That said, it's a professional engineering tool and it costs money. I'm pretty sure that folks on this list have an idea of what z/XDC can do. 

Re: WHERE in debugger?

Hello Shmuel: Good afternoon.  I lurk on the Assembler list and watch your posts go by. z/XDC can do all you're looking for and much, much more.  That said, it's a professional engineering tool and it costs money. Sincerely, Bob On 5/17/24 2:11 PM, Seymour J Metz wrote: Do the IDF and z/OS

Re: Relation between ASMLANGX and EQALANGX

://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Joseph Reichman Sent: Thursday, May 16, 2024 11:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relation between ASMLANGX

Re: Relation between ASMLANGX and EQALANGX

Seymour when I was I. Development they encouraged me to stop using TSO TEST and use to debug tool let me look at my assembly JCL On Thu, May 16, 2024 at 11:51 AM Seymour J Metz wrote: > The HLASM Toolkit includes ASMLANGX and the z/OS debugger includes > EQALANGX; are their outputs

Re: Instructions by Machine

th z900's but this just in: they are in "we're getting off the mainframe" mode and aren't prospects for new ISV software. And if I am wrong and one DOES show up with a large check then you can re-code and create a custom build just for them. One advantage of compiled languages as opposed to H

Re: Instructions by Machine

We're actually using OPTABLE(Z12). Honestly, I'd rather the assembler fail than have a customer get some kind of program exception because they didn't have the right hardware (or feature). I can justify Z12 easily so that's why we have it set in the configuration. *Mark* On Wed, May 15,

Re: Instructions by Machine

PS. Sorry, forgot to say. I had to install PTF PH39324 to get LFI recognized with OPTABLE(ZSA), which, from your post, seems to be what you're using (apologies for the noise if I misread it): https://www.ibm.com/support/pages/apar/PH39324

Re: Instructions by Machine

Mark, You may find that the LFI instruction is present on the machine. (I found it was present on our old EC12.) LFI is an extended opcode for IILF. If you use IILF, it will probably work. Regards, Emir Garza

Re: Instructions by Machine

Just my 2 cents but this makes sense. A few years ago, my company (actually lead developer at the time and I) decided that we would "standardize" on supported versions of IBM operating systems. z/SO 2.2 had just gone 'end of life' and (per Peter's reference) required z10 hardware so that became

Re: Instructions by Machine

be some overlap in the different sets represented (HW vs SW). Thank you. Peter From: IBM Mainframe Assembler List On Behalf Of Peter Relson Sent: Wednesday, May 15, 2024 10:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Instructions by Machine Mike Shaw wrote This _gold_

Re: Instructions by Machine

Mike Shaw wrote This _gold_ for ISVs writing code that must execute on many different z models. Thanks to Dan and Yves for all the work. For Dan's, I'd suggest (somehow) adding a "key" to the 2-character facility names (I know most of them, but many might not, so it could be helpful to

Re: Instructions by Machine

On 5/12/2024 11:02 PM, Yves Colliard wrote: Dear Dan, many thanks. I did a comparable excel - if you're interested take a look, could also be an altenative. https://magentacloud.de/s/7wJAZmS65DFY2zy Best regards Yves Colliard Nice work! -- Phoenix Software International Edward E. Jaffe

Re: Instructions by Machine

Hello Martin, very happy that you like it! ... a little bit rexx ... ;-) a good way for me to get an overview and find the right instruction. Also very usefull during teaching Best regards Yves

Re: Instructions by Machine

Yves, wouw, that was certainly a lot of work. Thank you for it Martin PS: Now I understand why the green card is no longer a card - but a booklet ;-)

Re: Instructions by Machine

Dear Dan, many thanks. I did a comparable excel - if you're interested take a look, could also be an altenative. https://magentacloud.de/s/7wJAZmS65DFY2zy Best regards Yves Colliard

Re: Instructions by Machine

This _gold_ for ISVs writing code that must execute on many different z models. Thank you Dan! Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Sat, May 11, 2024 at 4:07 PM Dan Greiner wrote: > Back when I was a full-time IBMer, I had a spreadsheet with all > z/Architecture

Re: Instructions by Machine

Truly a labor of love, thanks Dan ! Matt Hogstrom m...@hogstrom.org +1-919-656-0564 PGP Key: 0x90ECB270 Facebook LinkedIn Twitter “It may be cognitive, but, it ain’t intuitive." — Hogstrom >

Re: Instructions by Machine

Dan , thank you! (I will use it to get my debugger up to date) Martin On 11.05.24 22:27, Tony Thigpen wrote: Big **THANKS** Tony Thigpen Dan Greiner wrote on 5/11/24 4:06 PM: Back when I was a full-time IBMer, I had a spreadsheet with all z/Architecture instructions sorted by the machine

Re: Instructions by Machine

Big **THANKS** Tony Thigpen Dan Greiner wrote on 5/11/24 4:06 PM: Back when I was a full-time IBMer, I had a spreadsheet with all z/Architecture instructions sorted by the machine in which they were introduced. Unfortunately, this included IBM-confidential instructions, and I was not able

Re: Does the GET macro indicate EOF?

on behalf of Ed Jaffe <17285f33d197-dmarc-requ...@listserv.uga.edu> Sent: Friday, May 10, 2024 3:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does the GET macro indicate EOF? On 5/9/2024 5:41 AM, Binyamin Dissen wrote: > Have your EODAD do > >

Re: Does the GET macro indicate EOF?

On 5/9/2024 5:41 AM, Binyamin Dissen wrote: Have your EODAD do LFI R1,c'EODA' BR R14 Or my favorite value: LFI R1,X'FE0D' Then you can DOEXIT CIJ,R1,LT,0 to exit the loop if negative... -- Phoenix Software International Edward E. Jaffe 831 Parkview

Re: Relative branching instructions info

ָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > > From: IBM Mainframe Assembler List on > behalf of Bertus Bekker > Sent: Friday, May 10, 2024 7:08 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Relative branching instructions info > > Although not fully related

Re: Does the GET macro indicate EOF?

Usually people set a switch in the EODAD routine. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of David Eisenberg Sent: Wednesday, May 8,

Re: Relative branching instructions info

To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info Although not fully related to this topic, and covering more implementation than pure architecture matters, the IBM z Functional Matrix Redpapers do give a summary of some of the evolution. On Fri, May 10, 2024 at 12

Re: Relative branching instructions info

According to the ESA/390 Principles of Operation (SA22-7201-08), relative addressing instructions were introduced in 1996. Relative-long instructions were added in 2000. Under "Highlights of ESA/390", p. 1-3: "The immediate-and-relative-instruction facility includes 13 new instructions, most

Re: Relative branching instructions info

wrote: > I second (or is it fourth or fifth now . . .) that request! > > Peter > > From: IBM Mainframe Assembler List On > Behalf Of Martin Trübner > Sent: Thursday, May 9, 2024 3:35 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Relative branching instru

Re: Relative branching instructions info

I second (or is it fourth or fifth now . . .) that request! Peter From: IBM Mainframe Assembler List On Behalf Of Martin Trübner Sent: Thursday, May 9, 2024 3:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info Yes Sir, please !!! Martin

Re: Relative branching instructions info

Something like this would have answered the question I had a few weeks ago :-). So one up-vote from me. *Mark Hammack* On Thu, May 9, 2024 at 11:04 AM Jonathan Scott wrote: > I have for some years had a comprehensive list of all opcodes > supported by HLASM showing the range of OPTABLEs

Re: Relative branching instructions info

Yes Sir, please !!! Martin On 09.05.24 18:04, Jonathan Scott wrote: I have for some years had a comprehensive list of all opcodes supported by HLASM showing the range of OPTABLEs for which each one is valid, the instruction format, whether it is an extended mnemonic, the instruction name and

Re: Relative branching instructions info

of Jonathan Scott Sent: Thursday, May 9, 2024 12:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info I have for some years had a comprehensive list of all opcodes supported by HLASM showing the range of OPTABLEs for which each one is valid, the instruction format

Re: Relative branching instructions info

AWESOME! Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jonathan Scott Sent: Thursday, May 9, 2024 9:05 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info I have for some years

Re: Relative branching instructions info

I have for some years had a comprehensive list of all opcodes supported by HLASM showing the range of OPTABLEs for which each one is valid, the instruction format, whether it is an extended mnemonic, the instruction name and some other information. This information is generated systematically by

Re: Relative branching instructions info

It used to be in SHARE presentations.  Branch relative was presented in 1998 Stalking the new opcodes. That would be pre-MP3000, pre-zArchitecture,I believe.  I always though a good place to add documentation was https://bixoft.nl/english/opcd00.htm On 2024-05-09 11:21 a.m., Charles Mills wrote:

Re: Relative branching instructions info

From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Thursday, May 9, 2024 11:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info Ah! That's a different question. It's always a research project. I know of no exhaustive "this instru

Re: Relative branching instructions info

The OP said that, but not in his OP. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, May 9, 2024 8:20 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions

Re: Relative branching instructions info

Ah! That's a different question. It's always a research project. I know of no exhaustive "this instruction was introduced with this model" document. You can go through the various Principles of Operation versions and look for change bars. Not a quick task. You can look at the description for

Re: Relative branching instructions info

From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Thursday, May 9, 2024 11:10 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Relative branching instructions info Principles of Operation is both the best source, and also about the only definitive source. https

Re: Relative branching instructions info

If you want to know quickly what instructions are available at a given hardware level, you can assemble a dummy program (just an END statement) with OPTABLE(Znn,LIST) and look at the resulting report. Jonathan Scott, HLASM IBM Hursley, UK

Re: Relative branching instructions info

nsagem original- > De: IBM Mainframe Assembler List Em > nome de Tom Marchant > Enviada em: quinta-feira, 9 de maio de 2024 11:56 > Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Assunto: Re: Relative branching instructions info > > Do you mean information beyond what is d

Re: Relative branching instructions info

Principles of Operation is both the best source, and also about the only definitive source. https://publibz.boulder.ibm.com/epubs/pdf/dz9zr010.pdf Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of João Reginato Sent:

Re: Does the GET macro indicate EOF?

From: IBM Mainframe Assembler List on behalf of Martin Trübner <1237eee49f7e-dmarc-requ...@listserv.uga.edu> Sent: Thursday, May 9, 2024 8:37 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does the GET macro indicate EOF? set the bit as suggested in a separate EOF routine if y

Re: Relative branching instructions info

Do you mean information beyond what is documented in the Principles of Operation? -- Tom Marchant On Thu, 9 May 2024 09:50:07 -0300, João Reginato wrote: >Do you know where can I find additional information about the hardware >implementation of the relative branching instructions? > >(ie.

Re: Does the GET macro indicate EOF?

Thank you so much, everyone; I now understand what I need to do (and I understand why I don't need to dig anything out of the DCB, etc). I hadn't realized (until reading these solutions) that R14 points to the instruction after the GET even when the EODAD routine is called. I'll clear R1 in

Re: Does the GET macro indicate EOF?

Have your EODAD do LFI R1,c'EODA' BR R14 That will not be a record address. On Thu, 9 May 2024 08:18:57 -0400 David Eisenberg wrote: :>>What are you trying to do?< :> :>I'm trying to overcome a limitation in ASMIDF involving single-stepping through code while

Re: Does the GET macro indicate EOF?

, May 8, 2024 7:14 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does the GET macro indicate EOF? You can set up an EODAD routine that clears R1, and BR 14. You can then just check for R1 being 0 after the GET. I think that will work; I only use GL for QSAM. sas

Re: Does the GET macro indicate EOF?

set the bit as suggested in a separate EOF routine if you use the BR 14 to end your EOF handling, you have a bit to test after the GET. so it looks like this GET_LOOP  DS 0H    GET  DCB RESUME DS 0H    TM FLAG,BIT    JO  REAL_EOF SET_FLAG DS 0H    OI  FLAG,BIT    J   RESUME DCB

Re: Does the GET macro indicate EOF?

(Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of David Eisenberg Sent: Thursday, May 9, 2024 8:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Does the GET

Re: Does the GET macro indicate EOF?

>What are you trying to do?< I'm trying to overcome a limitation in ASMIDF involving single-stepping through code while debugging. That's the only reason I'm asking about this. As per the IBM documentation, ASMIDF's single-stepping process involves the automatic placement and removal of

Re: Does the GET macro indicate EOF?

If the manual doesn't state the content of R1, don't rely on it :-) The only thing you really need to sense EOF is to know that the branch to the specified EODAD has been taken, so (as you mention) I would normally keep MYEODAD DS 0H outside the loop. I'm not aware of any quirks of IDF, so I'll

Re: Does the GET macro indicate EOF?

Hi David, Have you acces to a DEB block ? there is the DEBEOF flag Just in case... René Le jeudi 9 mai 2024 à 04:18:29 UTC+2, David Eisenberg a écrit : Peter, Yes... I'm using ASMIDF. I can definitely set a manual breakpoint on the EOF label, and the breakpoint will be

Re: Does the GET macro indicate EOF?

Doctor, doctor, it hurts when I do this. Obviously you do not want to simply branch after the EOF returns after the GET, as you can simply set the EOF to there. You can alter the EODAD in the DCB if you wish to conditionally change where the EOF goes. What are you trying to do? On Wed, 8 May

Re: Does the GET macro indicate EOF?

zXDC? It allows one to step through code Just say 'n'. Steve Thompson On 5/8/2024 10:17 PM, David Eisenberg wrote: Peter, Yes... I'm using ASMIDF. I can definitely set a manual breakpoint on the EOF label, and the breakpoint will be honored... but that's not my problem. The issue

Re: Does the GET macro indicate EOF?

Peter, Yes... I'm using ASMIDF. I can definitely set a manual breakpoint on the EOF label, and the breakpoint will be honored... but that's not my problem. The issue pertains to single-stepping; in my case, using IDF's STMTSTEP command. The code doing the GET resides in an external subroutine

Re: Does the GET macro indicate EOF?

You can set up an EODAD routine that clears R1, and BR 14. You can then just check for R1 being 0 after the GET. I think that will work; I only use GL for QSAM. sas

Re: Does the GET macro indicate EOF?

David, I believe that in ASMIDF (I do assume that’s what you are referring to here), you CAN set a break point at the EOF label and when you single step at GETLOOP it SHOULD just get you to the EOF breakpoint once EOF happens. Are you saying that does NOT happen with a break set at EOF while

Re: Assembler/compiler fun

taking the 13.2 version: stmg%r11,%r15,88(%r15) aghi%r15,-168 lgr%r11,%r15 lgr%r1,%r2 st%r1,164(%r11) l%r1,164(%r11) ms%r1,164(%r11) lgfr%r1,%r1 lgr%r2,%r1 lmg%r11,%r15,256(%r11) br%r14 you can easy see that the authors have not studied their PoPs long enough the following sequence yields the

Re: SV: ASMA043E Previously defined symbol

רָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Sunday, May 5, 2024 10:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: SV: ASMA043E Previously defined

Re: SV: ASMA043E Previously defined symbol

On 5/4/24 22:36:27, Ed Jaffe wrote: ... But we had a register equates macro that came to conflict with IATYREGS when we added JES3 support.  Many JES3 headers used IATYREGS conditioned on setting ofa GBLB. All of the IATY macros have similar conditioning, thus allowing duplicate

Re: SV: ASMA043E Previously defined symbol

On 5/1/2024 9:58 AM, Paul Gilmartin wrote: The desire to accept redefinition with identical value appears to arise from undisciplined design and use of header files. But we had a register equates macro that came to conflict with IATYREGS when we added JES3 support.  Many JES3 headers used

Re: IEABRC anomaly

From: IBM Mainframe Assembler List on behalf of Ngan, Robert (DXC Luxoft) Sent: Friday, May 3, 2024 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly I remember (a long time ago) we had "first time" code preceded by a NOP, which alter

Re: IEABRC anomaly

Of Abe Kornelis Sent: Thursday, May 2, 2024 14:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly [Some people who received this message don't often get email from a...@bixoft.nl. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Shmuel, all, it's be

Re: IEABRC anomaly

arc-requ...@listserv.uga.edu> Sent: Thursday, May 2, 2024 8:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly Would it help to use IEABRCX and disable it around that macro? -- Tom Marchant On Thu, 2 May 2024 21:50:26 +, Seymour J Metz wrote: >It's not clear that t

Re: IEABRC anomaly

>From: IBM Mainframe Assembler List on behalf >of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> >Sent: Thursday, May 2, 2024 5:12 PM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: IEABRC anomaly > >On 5/2/24 11:16:13, Seymour J Metz wrote: >> E

Re: IEABRC anomaly

GA.EDU Subject: Re: IEABRC anomaly On 5/2/24 11:16:13, Seymour J Metz wrote: > Except that IEABRC is only necessary for old code. I've inherited code that > uses NOP as a switch, overlaying the mask with F. > . Self-modifying or EX code!? -- gil

Re: IEABRC anomaly

On 5/2/24 11:16:13, Seymour J Metz wrote: Except that IEABRC is only necessary for old code. I've inherited code that uses NOP as a switch, overlaying the mask with F. . Self-modifying or EX code!? -- gil

Re: IEABRC anomaly

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-L

Re: IEABRC anomaly

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

Re: ASMA043E Previously defined symbol - Rexx

On 5/2/24 06:21:02, Tony Thigpen wrote: What does the REXX compiler do with duplicate labels? . Compatibility with ANSI Rexx should require tolerating them. Phil Smith III wrote on 5/1/24 1:00 PM: That's bad. That's WAD. Remember, the goal of Rexx was ease of use. Just sayinn'. < .

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

Re: ASMA043E Previously defined symbol - Rexx

+++FANPAR0071W Duplicate label: Only first occurrence on line n used > What does the REXX compiler do with duplicate labels? > > Tony Thigpen Jonathan Scott, HLASM IBM Hursley, UK

Re: ASMA043E Previously defined symbol - Rexx

What does the REXX compiler do with duplicate labels? Tony Thigpen Phil Smith III wrote on 5/1/24 1:00 PM: 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

OOREXX seems to ignore duplicates. Just tried this on a Mac: #!/Applications/ooRexx5/bin/rexx call m exit m: procedure say "First m" return m: procedure say "Second m" return Running it produces: $./testdup.rex First m

Re: ASMA043E Previously defined symbol

From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: Wednesday, May 1, 2024 5:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: ASMA043E Previously defined symbol No, it is a feature of *some* interpreters. Others translate

Re: ASMA043E Previously defined symbol

reputation.  Character is what you are, reputation merely what others think you are. - John Wooden DTCC Public (White) -Original Message- From: IBM Mainframe Assembler List On Behalf Of Phil Smith III Sent: Wednesday, May 1, 2024 6:00 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re

Re: IEABRC anomaly

:25 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: IEABRC anomaly There is a B2D2 there just the mask is zero So it falls thru > On May 1, 2024, at 11:06 AM, Pieter Wiid wrote: > > NOP translates to BC 0 > > -Original Message- > From: IBM Mainframe Assembler List

  1   2   3   4   5   6   7   8   9   10   >