z/390 Assembler and START statement.
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: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
My apologies. I did not realize the context and rqmnts. were so well defined. Mike -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, June 2, 2020 10:55 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels) Caution! This message was sent from outside your organization. On 2020-06-02, at 19:37:25, Gary Weinhold wrote: > > I recall that VM/370 CP routines set CC before returning to the > caller; I don't have access to the source anymore (for the last 30 > years or so) to verify this and what technique was used. I just > remember thinking it was different and clever (coming from a VS1/MVS > background). > I'd guess stuffing it in the Old PSW before LPSW returns to caller. > On 2020-06-02, at 18:45:20, Mike Hochee wrote: > > Hmmm... > > "I had a tough time in code review. Reviewers called me naive for using a > negative value in a base register. No, the were ignorant; the code worked > and was correct." > > Perhaps technically 'correct', in that it worked, but why run the risk of > having a customer stumble over the eventual bad fruit borne of the seemingly > enlightened developer decades earlier, but since maintained by lesser souls. > 'Danger Will Robinson! Danger!!!' > No. This is not a case where "It happens to work despite lack of documentation, so I'll rely on it." I've inveighed against such practice elsewhere. Rather, I relied only on the instructions' working as specified in the PoOps. Our requirements were: o Status returned in CC. o Correct operation on 370 where IPM/SPM were unavailable. o Correct operatioh in AMODE 31. It's always possible that an ignorant maintainer break things. "Mit der Dummheit kämpfen Götter selbst vergebens." LH; LA would probably break in AMODE 64. This was not a concerm those decades ago. SH would be no better. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
> "Mit der Dummheit kämpfen Götter selbst vergebens." I thought that was what Mike was referring to. It, the swing and The Wizard of Id should be on every programmer's door. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 10:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels) On 2020-06-02, at 19:37:25, Gary Weinhold wrote: > > I recall that VM/370 CP routines set CC before returning to the caller; > I don't have access to the source anymore (for the last 30 years or so) > to verify this and what technique was used. I just remember thinking it > was different and clever (coming from a VS1/MVS background). > I'd guess stuffing it in the Old PSW before LPSW returns to caller. > On 2020-06-02, at 18:45:20, Mike Hochee wrote: > > Hmmm... > > "I had a tough time in code review. Reviewers called me naive for using a > negative value in a base register. No, the were ignorant; the code worked > and was correct." > > Perhaps technically 'correct', in that it worked, but why run the risk of > having a customer stumble over the eventual bad fruit borne of the seemingly > enlightened developer decades earlier, but since maintained by lesser souls. > 'Danger Will Robinson! Danger!!!' > No. This is not a case where "It happens to work despite lack of documentation, so I'll rely on it." I've inveighed against such practice elsewhere. Rather, I relied only on the instructions' working as specified in the PoOps. Our requirements were: o Status returned in CC. o Correct operation on 370 where IPM/SPM were unavailable. o Correct operatioh in AMODE 31. It's always possible that an ignorant maintainer break things. "Mit der Dummheit kämpfen Götter selbst vergebens." LH; LA would probably break in AMODE 64. This was not a concerm those decades ago. SH would be no better. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
As Mr. Gilmartin has reminded me, SPM was part of the original S/360 instruction set. (I actually did know that, but having been retired for almost 3 years now, I'm getting a little rusty ... thanks Gil for slapping me upside the head.) As Mr. Metz points out, there are countless ways of non-destructively setting the condition code (i.e., without changing registers or memory). A challenge to do this in extremely high-performance code is to do it without a storage-operand reference ... i.e., dragging some operand into the data cache. CC0 is easy (e.g., compare a register to itself). SPM can help with CC1-CC3, but you need a register handy. As Mr. Weinhold notes, VM functions have returned a CC for ages. This is something that is necessary when simulating instructions that are either (a) not part of the machine, or (b) intercepted by the hypervisor and managed by the VM host. (However, in such cases, VM simply modifies the guest's PSW before resuming guest execution.) With regards to Kevin's question, "Are you suggesting the use of SPM/IPM as an alternative to actually setting the condition code?" SPM actually sets the condition code (from bits 34-35) and the program mask (from bits 36-39) of the first-operand register. For example, let's say that you have a value in the rightmost two bits of R0 that you want to become the new CC (and that you don't mind if the program mask gets zeroed): SLL 0,28Shift bits 62-63 to bits 34-35. SPM 0 Set the CC (PM becomes zeros). IPM simply captures the CC and PM (from bits 18-23 of the current PSW) into bits 34-39 of the first-operand register. Why these weird bit positions in the register? In original S/360 architecture, BAL and BALR put the instruction-length code (ILC), CC, and PM in bits 0-7 of the first-operand (32-bit) register, and SPM restored the CC and IPM from the same bit positions. In z/Architecture, these became bits 32-39 of the register, but BAL/BALR does this only in the 24-bit addressing mode in XA and Z.
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
On 2020-06-02, at 19:37:25, Gary Weinhold wrote: > > I recall that VM/370 CP routines set CC before returning to the caller; > I don't have access to the source anymore (for the last 30 years or so) > to verify this and what technique was used. I just remember thinking it > was different and clever (coming from a VS1/MVS background). > I'd guess stuffing it in the Old PSW before LPSW returns to caller. > On 2020-06-02, at 18:45:20, Mike Hochee wrote: > > Hmmm... > > "I had a tough time in code review. Reviewers called me naive for using a > negative value in a base register. No, the were ignorant; the code worked > and was correct." > > Perhaps technically 'correct', in that it worked, but why run the risk of > having a customer stumble over the eventual bad fruit borne of the seemingly > enlightened developer decades earlier, but since maintained by lesser souls. > 'Danger Will Robinson! Danger!!!' > No. This is not a case where "It happens to work despite lack of documentation, so I'll rely on it." I've inveighed against such practice elsewhere. Rather, I relied only on the instructions' working as specified in the PoOps. Our requirements were: o Status returned in CC. o Correct operation on 370 where IPM/SPM were unavailable. o Correct operatioh in AMODE 31. It's always possible that an ignorant maintainer break things. "Mit der Dummheit kämpfen Götter selbst vergebens." LH; LA would probably break in AMODE 64. This was not a concerm those decades ago. SH would be no better. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
I recall that VM/370 CP routines set CC before returning to the caller; I don't have access to the source anymore (for the last 30 years or so) to verify this and what technique was used. I just remember thinking it was different and clever (coming from a VS1/MVS background). On 2020-06-02 5:30 p.m., Dan Greiner wrote: Although Seymour has pointed out the OS/360 convention of placing a return code in GR15, there are numerous alternative approaches used elsewhere. Your example of using "historical opcodes" (BAL 14,some_test / BE success) was used extensively in the National Institute of Health (NIH) version of the Wylbur / Milton text editing / communications packages of the 1960s. Other operating systems and languages take different approaches (an early version of Bell Labs mainframe version of UNIX used R7 for a return code). Other than the conventional OS-360 approach, I tend to favor the above example (i.e., having the subroutine set the CC, rather than the indexed-branch approach). Having the subroutine set the CC provides a means of having (up to) four possible actions that the calling program can take upon return. You state: "The problem for me was that you have to jump through some convolutions to set the condition code." However, you still have to have some determination in the subroutine that loads a condition code (conventional approach), or selects which branch to used (index-branch approach). Using the indexed branch allows for many more possible actions -- not just binary true/false -- but may necessitate accommodating all possible branch cases following each return. I also agree that the indexed branch approach may be more complicated to maintain. As to how to set [and preserve] the condition code, many experienced assembler programmers have yet to discover the "newer" instruction SET PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with tongue pressed firmly in cheek, since these unprivileged instructions have been around since the introduction of the S/370 (five decades ago). Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: z/OS HLASM: EQU for statement labels
- Original Message - From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> To: Sent: Wednesday, June 03, 2020 3:26 AM Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:58:00, David Woolbright wrote: I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. LABELDS0H Guarantees alignment with no drawback. LABELEQU * Risks misalignment to save one keystroke in source. I was once involved with a project tnat had (like): B ENDEYECATCHER DCC'Whatever' Eyecatcher ... more data areas ... ENDEYECATCHER EQU * The eyecatcher grew to an odd number of bytes (Y2K-type problem) and code broke. Because of macro nesting, the remedy was: BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... ENDEYECATCHER EQU * STM R14,R13, === BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... DS 0H == REQUIRED HERE, NOT AS ABOVE ENDEYECATCHER EQU * STM R14,R13, === I pointed out that this introduced a needless slack byte half the time. My suggestion was overruled because of code ownership. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: z/OS HLASM: EQU for statement labels
Hmmm... "I had a tough time in code review. Reviewers called me naive for using a negative value in a base register. No, the were ignorant; the code worked and was correct." Perhaps technically 'correct', in that it worked, but why run the risk of having a customer stumble over the eventual bad fruit borne of the seemingly enlightened developer decades earlier, but since maintained by lesser souls. 'Danger Will Robinson! Danger!!!' My 2 cents worth. Mike -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Tuesday, June 2, 2020 5:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Caution! This message was sent from outside your organization. Not bad. It's very useful for assembler programmers to understand the math behind 2s-complement (and how it nicely "complements" wrap-around addressing) thoroughly enough to get that; besides understanding you avoided changing the CC. But for the record, that's a negative value in an index register. sas On Tue, Jun 2, 2020 at 4:24 PM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > > > Labels... > > Even back in the 60's I was taught never to put a label on an > > instruction I only break that rule now for the subject of an EX (and > > its variants) > > > It's safer than > labelEQU * > > > Returning CC from a subroutine... > > Have to point out that IBM do this in the VSAM TESTCB macro > > > I had one co-worker who insisted on doing that. He augmented our > MVS/XA common return macro to: > > IPM > ... > SHR13,=Y(workarea_length) > ... > SPM , restore CC > > then *I* was tasked with porting to VM/370. No IPM. I did: > LH R1,=Y(-workarea_length) > LA R13,0(R1,R13) > > I had a tough time in code review. Reviewers called me naive for > using a negative value in a base register. No, the were ignorant; the > code worked and was correct. > > -- gil >
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
I might believe MILTEN. Setting CC is not at all arcane Z: CLI *,X'95' H: CLI *,0 L: CLI *,255 O: TM *,1 I thought maybe the 360/67 had IPM for 32-bit mode, but, no, so XA it is. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Dan Greiner [dan_grei...@att.net] Sent: Tuesday, June 2, 2020 5:30 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels) Although Seymour has pointed out the OS/360 convention of placing a return code in GR15, there are numerous alternative approaches used elsewhere. Your example of using "historical opcodes" (BAL 14,some_test / BE success) was used extensively in the National Institute of Health (NIH) version of the Wylbur / Milton text editing / communications packages of the 1960s. Other operating systems and languages take different approaches (an early version of Bell Labs mainframe version of UNIX used R7 for a return code). Other than the conventional OS-360 approach, I tend to favor the above example (i.e., having the subroutine set the CC, rather than the indexed-branch approach). Having the subroutine set the CC provides a means of having (up to) four possible actions that the calling program can take upon return. You state: "The problem for me was that you have to jump through some convolutions to set the condition code." However, you still have to have some determination in the subroutine that loads a condition code (conventional approach), or selects which branch to used (index-branch approach). Using the indexed branch allows for many more possible actions -- not just binary true/false -- but may necessitate accommodating all possible branch cases following each return. I also agree that the indexed branch approach may be more complicated to maintain. As to how to set [and preserve] the condition code, many experienced assembler programmers have yet to discover the "newer" instruction SET PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with tongue pressed firmly in cheek, since these unprivileged instructions have been around since the introduction of the S/370 (five decades ago).
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
On 2020-06-02, at 15:53:34, Keven wrote: > > Are you suggesting the use SPM/IPM as an alternative to setting the > actual condition code? > K3n > I opposed it; its proponent outranked me. > On Tue, Jun 2, 2020 at 4:45 PM -0500, "Paul Gilmartin" > > On 2020-06-02, at 15:30:33, Dan Greiner wrote: >> >> Using the indexed branch allows for many more possible actions -- not just >> binary true/false -- but may necessitate accommodating all possible branch >> cases following each return. I also agree that the indexed branch approach >> may be more complicated to maintain. >> > But the prudent programmer will test the range before branching. > >> As to how to set [and preserve] the condition code, many experienced >> assembler programmers have yet to discover the "newer" instruction SET >> PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with >> tongue pressed firmly in cheek, since these unprivileged instructions have >> been around since the introduction of the S/370 (five decades ago). >> > Only half. I belive SPM is older; IPM appeared only with XA > when BALR no longer sufficed to capture the PM. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
Are you suggesting the use SPM/IPM as an alternative to setting the actual condition code? K3n On Tue, Jun 2, 2020 at 4:45 PM -0500, "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 2020-06-02, at 15:30:33, Dan Greiner wrote: > > Using the indexed branch allows for many more possible actions -- not just > binary true/false -- but may necessitate accommodating all possible branch > cases following each return. I also agree that the indexed branch approach > may be more complicated to maintain. > But the prudent programmer will test the range before branching. > As to how to set [and preserve] the condition code, many experienced > assembler programmers have yet to discover the "newer" instruction SET > PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with > tongue pressed firmly in cheek, since these unprivileged instructions have > been around since the introduction of the S/370 (five decades ago). > Only half. I belive SPM is older; IPM appeared only with XA when BALR no longer sufficed to capture the PM. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
On 2020-06-02, at 15:30:33, Dan Greiner wrote: > > Using the indexed branch allows for many more possible actions -- not just > binary true/false -- but may necessitate accommodating all possible branch > cases following each return. I also agree that the indexed branch approach > may be more complicated to maintain. > But the prudent programmer will test the range before branching. > As to how to set [and preserve] the condition code, many experienced > assembler programmers have yet to discover the "newer" instruction SET > PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with > tongue pressed firmly in cheek, since these unprivileged instructions have > been around since the introduction of the S/370 (five decades ago). > Only half. I belive SPM is older; IPM appeared only with XA when BALR no longer sufficed to capture the PM. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
Although Seymour has pointed out the OS/360 convention of placing a return code in GR15, there are numerous alternative approaches used elsewhere. Your example of using "historical opcodes" (BAL 14,some_test / BE success) was used extensively in the National Institute of Health (NIH) version of the Wylbur / Milton text editing / communications packages of the 1960s. Other operating systems and languages take different approaches (an early version of Bell Labs mainframe version of UNIX used R7 for a return code). Other than the conventional OS-360 approach, I tend to favor the above example (i.e., having the subroutine set the CC, rather than the indexed-branch approach). Having the subroutine set the CC provides a means of having (up to) four possible actions that the calling program can take upon return. You state: "The problem for me was that you have to jump through some convolutions to set the condition code." However, you still have to have some determination in the subroutine that loads a condition code (conventional approach), or selects which branch to used (index-branch approach). Using the indexed branch allows for many more possible actions -- not just binary true/false -- but may necessitate accommodating all possible branch cases following each return. I also agree that the indexed branch approach may be more complicated to maintain. As to how to set [and preserve] the condition code, many experienced assembler programmers have yet to discover the "newer" instruction SET PROGRAM MASK (SPM) [and INSERT PROGRAM MASK (IPM)]. I say "newer" with tongue pressed firmly in cheek, since these unprivileged instructions have been around since the introduction of the S/370 (five decades ago).
Re: z/OS HLASM: EQU for statement labels
Paging? The conventional wisdom has always been to stay within one base register, so for systems with 4K pages that isn't an issue. I tend to use LOCTR so that constants aren't always at the end of the source code. I normally put labels on the same line as the instructions and inserting code has never been a problem. I will admit to using self-modifying code when I was a callow youth, but I stopped doing that and started making any new code reentrant and refreshable sometime around the end of the 1960s. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [072265160664-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 4:01 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Hi Guys, I thought I would put my 2 cents worth in I know that 55 years of Assembler coding doesn't count for much these days :-) Labels... Even back in the 60's I was taught never to put a label on an instruction I only break that rule now for the subject of an EX (and its variants) In the old days of real storage I used to code label EQU * and this was fine Then paging came along and the recommendation was to keep in-line data close to the instructions using it (locality of reference). As people have mentioned this sometimes resulted in odd addresses and S0C1 abends (before unalignment was detected) So I switched to label DS 0H in coding Have to state the obvious...DS 0H might not be appropriate for some data as there are now many instructions that rely on specific alignments I consider... DS 0H label EQU * to be overkill and I would deduct 2 points With changes in architecture, we now move in-line data to avoid cache problems And did you know that this code...popular in ancient times is a performance disaster now ONETIME NOP THERE MVI ONETIME+1,X'F0' Returning CC from a subroutine... Have to point out that IBM do this in the VSAM TESTCB macro Melvyn Maltz. - Original Message - From: "David Woolbright" To: Sent: Tuesday, June 02, 2020 5:58 PM Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually >> I think the cleanest is a DS 0H followed by label EQU *. That clearly >> shows what is going on: re-establishing halfword alignment followed by >> mapping a label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: z/OS HLASM: EQU for statement labels
Not bad. It's very useful for assembler programmers to understand the math behind 2s-complement (and how it nicely "complements" wrap-around addressing) thoroughly enough to get that; besides understanding you avoided changing the CC. But for the record, that's a negative value in an index register. sas On Tue, Jun 2, 2020 at 4:24 PM Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > > > Labels... > > Even back in the 60's I was taught never to put a label on an instruction > > I only break that rule now for the subject of an EX (and its variants) > > > It's safer than > labelEQU * > > > Returning CC from a subroutine... > > Have to point out that IBM do this in the VSAM TESTCB macro > > > I had one co-worker who insisted on doing that. He augmented > our MVS/XA common return macro to: > > IPM > ... > SHR13,=Y(workarea_length) > ... > SPM , restore CC > > then *I* was tasked with porting to VM/370. No IPM. I did: > LH R1,=Y(-workarea_length) > LA R13,0(R1,R13) > > I had a tough time in code review. Reviewers called me > naive for using a negative value in a base register. No, > the were ignorant; the code worked and was correct. > > -- gil >
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 14:01:28, MELVYN MALTZ wrote: > > Labels... > Even back in the 60's I was taught never to put a label on an instruction > I only break that rule now for the subject of an EX (and its variants) > It's safer than labelEQU * > Returning CC from a subroutine... > Have to point out that IBM do this in the VSAM TESTCB macro > I had one co-worker who insisted on doing that. He augmented our MVS/XA common return macro to: IPM ... SHR13,=Y(workarea_length) ... SPM , restore CC then *I* was tasked with porting to VM/370. No IPM. I did: LH R1,=Y(-workarea_length) LA R13,0(R1,R13) I had a tough time in code review. Reviewers called me naive for using a negative value in a base register. No, the were ignorant; the code worked and was correct. -- gil
Re: z/OS HLASM: EQU for statement labels
Hi Guys, I thought I would put my 2 cents worth in I know that 55 years of Assembler coding doesn't count for much these days :-) Labels... Even back in the 60's I was taught never to put a label on an instruction I only break that rule now for the subject of an EX (and its variants) In the old days of real storage I used to code label EQU * and this was fine Then paging came along and the recommendation was to keep in-line data close to the instructions using it (locality of reference). As people have mentioned this sometimes resulted in odd addresses and S0C1 abends (before unalignment was detected) So I switched to label DS 0H in coding Have to state the obvious...DS 0H might not be appropriate for some data as there are now many instructions that rely on specific alignments I consider... DS 0H label EQU * to be overkill and I would deduct 2 points With changes in architecture, we now move in-line data to avoid cache problems And did you know that this code...popular in ancient times is a performance disaster now ONETIME NOP THERE MVI ONETIME+1,X'F0' Returning CC from a subroutine... Have to point out that IBM do this in the VSAM TESTCB macro Melvyn Maltz. - Original Message - From: "David Woolbright" To: Sent: Tuesday, June 02, 2020 5:58 PM Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: Is this useful? Only if you're a sadist. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
> Imagine: My eyes! I had a bad dream, Mommy! That violates every precept of encapsulation and information hiding. A subroutine should no be tinkering with the caller's environment except in very structured ways, e.g., return codes, signals. Having code outside of a loop dealing with the loop is an invitation to disaster. But it's not my dog. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 1:35 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 11:21:23, Seymour J Metz wrote: > > SIGNAL in PL/I is well behaved; in REXX, not so much. > > I like REXX, but it would have been much cleaner had iterate and leave used a > label on the do rather than using the control variable. > Yes. > It would also have been cleaner had there been a proper GOTO so that people > wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. > > What are long-ITERATE and long-LEAVE? > Imagine: DO LOOP = 1 CALL PROC epilogue END LOOP ... PROC: PROCEDURE EXPOSE LOOP stuff IF boolean THEN ITERATE LOOP /* bypass epilogue. */ more stuff RETURN/* to perform epilogue. */ -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote: > > I wrote an entire AVL tree based caching program using the HLASM Toolkit > Feature Structured Programming macros, but then had to rewrite to remove the > macros when the company decided to no longer pay for the feature. > > Now IBM is using the macros in IMS code, even programs where IBM provides the > source to IMS licensees. Maybe that means that if we're an IMS customer we're > also licensed for the macros. I'm kind of afraid to use them, in case we > lose access again. > I believe there's a freeware alternative. The name HAL comes to mind. But it might be in-house code. Ah! https://www.google.com/search?q=hlasm+structure+macro+hal ... points me to: www.naspa.net/magazine/2000/February/T0002006.pdf ... which mentions cbttape.org overflow file 118. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:30:20, Schmitt, Michael wrote: > > I wrote an entire AVL tree based caching program using the HLASM Toolkit > Feature Structured Programming macros, but then had to rewrite to remove the > macros when the company decided to no longer pay for the feature. > I believe there's a freeware alternative. The name HAL comes to mind. But it might be in-house code. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 11:21:23, Seymour J Metz wrote: > > SIGNAL in PL/I is well behaved; in REXX, not so much. > > I like REXX, but it would have been much cleaner had iterate and leave used a > label on the do rather than using the control variable. > Yes. > It would also have been cleaner had there been a proper GOTO so that people > wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. > > What are long-ITERATE and long-LEAVE? > Imagine: DO LOOP = 1 CALL PROC epilogue END LOOP ... PROC: PROCEDURE EXPOSE LOOP stuff IF boolean THEN ITERATE LOOP /* bypass epilogue. */ more stuff RETURN/* to perform epilogue. */ -- gil
Re: z/OS HLASM: EQU for statement labels
Use Concept 14 and you won't have to worry about licensing: http://skycoast.us/pscott/software/mvs/concept14.html -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Tuesday, June 2, 2020 1:30 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, June 02, 2020 12:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz https://clicktime.symantec.com/337D3ncPndju8wuLEmAfEmP7Vc?u=http%3A%2F%2Fmason.gmu.edu%2F~smetz3 I wrote an entire AVL tree based caching program using the HLASM Toolkit Feature Structured Programming macros, but then had to rewrite to remove the macros when the company decided to no longer pay for the feature. Now IBM is using the macros in IMS code, even programs where IBM provides the source to IMS licensees. Maybe that means that if we're an IMS customer we're also licensed for the macros. I'm kind of afraid to use them, in case we lose access again. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
-Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, June 02, 2020 12:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz https://clicktime.symantec.com/337D3ncPndju8wuLEmAfEmP7Vc?u=http%3A%2F%2Fmason.gmu.edu%2F~smetz3 I wrote an entire AVL tree based caching program using the HLASM Toolkit Feature Structured Programming macros, but then had to rewrite to remove the macros when the company decided to no longer pay for the feature. Now IBM is using the macros in IMS code, even programs where IBM provides the source to IMS licensees. Maybe that means that if we're an IMS customer we're also licensed for the macros. I'm kind of afraid to use them, in case we lose access again. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:58:00, David Woolbright wrote: > > I’’m just a humble academic so I hesitate to weigh in. I trained assembler > programmers for one large credit card processing company for many years and > their standard was to use EQU * as the target of all branches, mainly so new > lines could be added easily. I’ve never had an odd address created > accidentally using this technique, but it’s also the case that the assembler > will warn you in cases where you do have an unfavorable address. I’m in the > process of revising many years of teaching material into book format, so your > opinions on this matter to me. Using EQU for targets would seem to be a > stylistic point on which reasonable people could disagree, but perhaps I’m > wrong. > LABELDS0H Guarantees alignment with no drawback. LABELEQU * Risks misalignment to save one keystroke in source. I was once involved with a project tnat had (like): B ENDEYECATCHER DCC'Whatever' Eyecatcher ... more data areas ... ENDEYECATCHER EQU * The eyecatcher grew to an odd number of bytes (Y2K-type problem) and code broke. Because of macro nesting, the remedy was: BENDEYECATCHER DC C'Whatever' Eyecatcher DS 0H ... more data areas ... ENDEYECATCHER EQU * STM R14,R13, I pointed out that this introduced a needless slack byte half the time. My suggestion was overruled because of code ownership. -- gil
Re: z/OS HLASM: EQU for statement labels
Ah, I thought that you were using the macros from the HLASM Toolkit. BTW, I do use foo DS 0H in macros, with generated labels, when it's convenient, but believes that it clutters the listing elsewhere. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Schmitt, Michael [michael.schm...@dxc.com] Sent: Tuesday, June 2, 2020 1:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) Sorry, I was using pseudocode to illustrate a logical structure before coding it _in z/Architecture assembler_, where you have to use labels for your branch points. And it may have been a poorly contrived example because there would be a jump or branch between the two labels. Perhaps a better example is where there is an IF ... ENDIF immediately proceeding a DO ... WHILE, so that the ENDIF is at the same address as the start of the DO loop. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
SIGNAL in PL/I is well behaved; in REXX, not so much. I like REXX, but it would have been much cleaner had iterate and leave used a label on the do rather than using the control variable. It would also have been cleaner had there been a proper GOTO so that people wouldn't shoot themselves in the foot misusing SIGNAL as an ersatz goto. What are long-ITERATE and long-LEAVE? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 12:47 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 10:32:23, Seymour J Metz wrote: > > if x >if y > do a > foo endif > bar else > do b > endif > >> Then later if you want to insert more instructions immediately before the >> ELSE, it is very clear where to put them and none of the labels change. > > if x >if y > do a > foo endif >xcbaz,baz > bar else > do b > endif > Gasp! There are obsessive advocates of GOTO-less coding; there are staunch defenders of GOTO. The above appears to invite the worst of both practices. Throw in a SIGNAL for good measure. (But I admire Rexx for labelled END, ITERATE, and LEAVE, and I wish for long-ITERATE and long-LEAVE.) Sorry, I was using pseudocode to illustrate a logical structure before coding it _in z/Architecture assembler_, where you have to use labels for your branch points. And it may have been a poorly contrived example because there would be a jump or branch between the two labels. Perhaps a better example is where there is an IF ... ENDIF immediately proceeding a DO ... WHILE, so that the ENDIF is at the same address as the start of the DO loop. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
There are several different issues here. First, using foo EQU * instead of foo DS 0H will lead to alignment errors in programs mixing instructions and data, which is a very bad practice. Mixing LOCTR separated instructions and data, however, is a perfectly reasonable practice. Second, with any decent editor it is simple to insert and instruction after the label on another instruction. Third, if yo;re not mixing instructions and data then the difference between foo EQU * and foo DS 0H is purely stylistic. Fourth, stand alone labels will not create appropriate TEST and ADATA output. There might be a similar problem with macros that use the type of a parameter. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of David Woolbright [woolbright_da...@columbusstate.edu] Sent: Tuesday, June 2, 2020 12:58 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually I >> think the cleanest is a DS 0H followed by label EQU *. That clearly shows >> what is going on: re-establishing halfword alignment followed by mapping a >> label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
Hide the details in a macro. INVOKE name,error=(list of labels) SETERROR errorcode On Tue, 2 Jun 2020 08:58:28 -0700 Charles Mills wrote: :>> using condition code as return value from subroutines that tested :> :>I have never settled on a good scheme for returning what is effectively a bool value from an assembler subroutine that performs a test. :> :>I have tried using the condition code: (all examples using "historical" opcodes) :> :>BAL R14,some_test :>BE success :> :>The problem for me was that you have to jump through some convolutions to set the condition code. Sure, it is fairly easy to do, but branching to a CR R0,R0 just to set the CC seems silly. :> :>I have tried using a return of BR R14 for true and B 4(,R14) for false: :> :>BAL R14,some_test :>B success :>B failure :> :>I probably like and use that more than anything else, but it is obviously a trap for unwary future maintenance. The necessary coding in the subroutine is fairly straightforward. :> :>You can return a truth value in a register but registers are often precious and it sometimes has the convolution problem of the condition code approach. :> :>Anyone have a great solution? :> :>Charles :> :> :>-Original Message- :>From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III :>Sent: Tuesday, June 2, 2020 5:21 AM :>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU :>Subject: Re: z/OS HLASM: EQU for statement labels :> :>Charles Mills wrote: :>>I use 0H if it is the beginning of a section of code and there might be :>>an odd-length DC in front of it. But I use * when I am jumping around :>>one instruction. :> :>That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). :> :>>Revealing my age, I got in the habit of using EQU rather than labeled :>>machine instructions because if you are using punched cards and need to :>>insert a new instruction right after the label, you only have to punch :>>one card if you used EQU, but two if you put the label on a machine :>>instruction. :> :>I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! :> :>ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. :> :>The final project, worth a big chunk of our marks, was some stupid little game. I couldnt be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. :> :>I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". :> :>Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. :> :>That was 37 years ago. But I'm not bitter... -- 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: z/OS HLASM: EQU for statement labels
I’’m just a humble academic so I hesitate to weigh in. I trained assembler programmers for one large credit card processing company for many years and their standard was to use EQU * as the target of all branches, mainly so new lines could be added easily. I’ve never had an odd address created accidentally using this technique, but it’s also the case that the assembler will warn you in cases where you do have an unfavorable address. I’m in the process of revising many years of teaching material into book format, so your opinions on this matter to me. Using EQU for targets would seem to be a stylistic point on which reasonable people could disagree, but perhaps I’m wrong. > On Jun 2, 2020, at 11:49 AM, Seymour J Metz wrote: > >> Is this useful? > > Only if you're a sadist. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] > Sent: Tuesday, June 2, 2020 11:40 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: z/OS HLASM: EQU for statement labels > > On 2020-06-02, at 09:33:48, Charles Mills wrote: >> >> I don't claim any benefit to the technique, it's just my habit. Actually I >> think the cleanest is a DS 0H followed by label EQU *. That clearly shows >> what is going on: re-establishing halfword alignment followed by mapping a >> label to an address. >> > I found it ironic that: > LABELCNOP ... > assigns the address of the beginning of the padding rather > than the end to LABEL. Is this useful? > > Fortunately, > LABELDS0H > does the opposite so your 2-instruction construct is otiose. > > -- gil
Re: z/OS HLASM: EQU for statement labels
It was a (not the only) common coding technique "in the old days" to put the fields referenced by a subroutine at the end of that subroutine. If the last field were an odd length then if the next subroutine began with label EQU * you ended up with the alignment problem referenced in these posts. Nowadays putting data near instructions is a terrible technique never minding alignment because it drives the hardware's cache management crazy. Actually you code use that technique now and avoid both alignment and caching problems through the use of LOCTR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Schmitt, Michael Sent: Tuesday, June 2, 2020 9:18 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Thank you for your replies. I too was originally taught to use DS 0H for a label statement, because it guaranteed halfword instruction alignment. But I recently started using EQU * because a) it seemed to be clearer as to the intent, and b) I figured that if your instructions weren't aligned you've got bigger problems. I hadn't considered someone intentionally embedding an odd size storage area in the instruction stream without taking care to realign. I may rethink this, perhaps with Charles Mills suggestion to use DS 0H at the start of routines but continue to use EQU * inside them. As for the question of stand-alone labels vs. putting the label on the next instruction, I like the stand-alone labels because it promotes maintainable code. You can put comments on the label, but more important is that you can code multiple labels for the same address. For example, if you have this kind of structure (begging Outlook not to collapse the leading spaces): if x if y do a endif else do b endif you can code one label for the first ENDIF and another for the ELSE. Then later if you want to insert more instructions immediately before the ELSE, it is very clear where to put them and none of the labels change. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
Thank you for your replies. I too was originally taught to use DS 0H for a label statement, because it guaranteed halfword instruction alignment. But I recently started using EQU * because a) it seemed to be clearer as to the intent, and b) I figured that if your instructions weren't aligned you've got bigger problems. I hadn't considered someone intentionally embedding an odd size storage area in the instruction stream without taking care to realign. I may rethink this, perhaps with Charles Mills suggestion to use DS 0H at the start of routines but continue to use EQU * inside them. As for the question of stand-alone labels vs. putting the label on the next instruction, I like the stand-alone labels because it promotes maintainable code. You can put comments on the label, but more important is that you can code multiple labels for the same address. For example, if you have this kind of structure (begging Outlook not to collapse the leading spaces): if x if y do a endif else do b endif you can code one label for the first ENDIF and another for the ELSE. Then later if you want to insert more instructions immediately before the ELSE, it is very clear where to put them and none of the labels change. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --.
Re: z/OS HLASM: EQU for statement labels
> Is this useful? I think it is at least consistent (and yes, I know ...). I think ORG behaves the same way. > is otiose Nay, it "documents" that two functions are being performed: achieving alignment and defining a label. "not the most compact representation" is not synonymous with otiose. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, June 2, 2020 8:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
Well, the conventional solution in OS/360 is to return a code in R15, preferably a multiple of 4. But I've used both the condition code and branch offset approaches for internal subroutines. OTOH, when I write an assembler subroutine that is to be called from PL/I programs, I indicate unusual conditions with SIGNAL and SIGNAL ERROR if the ON unit returns. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, June 2, 2020 11:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels) > using condition code as return value from subroutines that tested I have never settled on a good scheme for returning what is effectively a bool value from an assembler subroutine that performs a test. I have tried using the condition code: (all examples using "historical" opcodes) BAL R14,some_test BE success The problem for me was that you have to jump through some convolutions to set the condition code. Sure, it is fairly easy to do, but branching to a CR R0,R0 just to set the CC seems silly. I have tried using a return of BR R14 for true and B 4(,R14) for false: BAL R14,some_test B success B failure I probably like and use that more than anything else, but it is obviously a trap for unwary future maintenance. The necessary coding in the subroutine is fairly straightforward. You can return a truth value in a register but registers are often precious and it sometimes has the convolution problem of the condition code approach. Anyone have a great solution? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, June 2, 2020 5:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Re: z/OS HLASM: EQU for statement labels
> (not writing much BAL any more). I doubt that you ever were, or that you've even seen it. > I was taught not to put labels on instructions for the same reason, though it > was because we were using CMS UPDATE at the time, Non sequitor. There's nothing in UPDATE that interferes with using labels on instructions. BTDT,GTTS (no scars, just the tee shirt) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Phil Smith III [li...@akphs.com] Sent: Tuesday, June 2, 2020 8:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Returning bool and similar values from subroutines (was z/OS HLASM: EQU for statement labels)
> using condition code as return value from subroutines that tested I have never settled on a good scheme for returning what is effectively a bool value from an assembler subroutine that performs a test. I have tried using the condition code: (all examples using "historical" opcodes) BAL R14,some_test BE success The problem for me was that you have to jump through some convolutions to set the condition code. Sure, it is fairly easy to do, but branching to a CR R0,R0 just to set the CC seems silly. I have tried using a return of BR R14 for true and B 4(,R14) for false: BAL R14,some_test B success B failure I probably like and use that more than anything else, but it is obviously a trap for unwary future maintenance. The necessary coding in the subroutine is fairly straightforward. You can return a truth value in a register but registers are often precious and it sometimes has the convolution problem of the condition code approach. Anyone have a great solution? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, June 2, 2020 5:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Re: z/OS HLASM: EQU for statement labels
> Is this useful? Only if you're a sadist. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Paul Gilmartin [0014e0e4a59b-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, June 2, 2020 11:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I > think the cleanest is a DS 0H followed by label EQU *. That clearly shows > what is going on: re-establishing halfword alignment followed by mapping a > label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
On 2020-06-02, at 09:33:48, Charles Mills wrote: > > I don't claim any benefit to the technique, it's just my habit. Actually I > think the cleanest is a DS 0H followed by label EQU *. That clearly shows > what is going on: re-establishing halfword alignment followed by mapping a > label to an address. > I found it ironic that: LABELCNOP ... assigns the address of the beginning of the padding rather than the end to LABEL. Is this useful? Fortunately, LABELDS0H does the opposite so your 2-instruction construct is otiose. -- gil
Re: z/OS HLASM: EQU for statement labels
I don't claim any benefit to the technique, it's just my habit. Actually I think the cleanest is a DS 0H followed by label EQU *. That clearly shows what is going on: re-establishing halfword alignment followed by mapping a label to an address. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, June 2, 2020 5:21 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: z/OS HLASM: EQU for statement labels Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more).
Re: z/OS HLASM: EQU for statement labels
Charles Mills wrote: >I use 0H if it is the beginning of a section of code and there might be >an odd-length DC in front of it. But I use * when I am jumping around >one instruction. That's an interesting stylistic trick. I like it. Probably a bit late for me to adopt it, alas (not writing much BAL any more). >Revealing my age, I got in the habit of using EQU rather than labeled >machine instructions because if you are using punched cards and need to >insert a new instruction right after the label, you only have to punch >one card if you used EQU, but two if you put the label on a machine >instruction. I was taught not to put labels on instructions for the same reason, though it was because we were using CMS UPDATE at the time, not actual cards. My card use predates doing real work! ObAnecdote: After three years of writing 370 assembler, I had to take an assembler class as part of my second attempt at university. The platform was Commodore SuperPet. After the first class, I went to the prof and explained that I had been writing real assembler for years and wasn't likely to learn a lot; he told me to do the assignments and exam and that would be OK. The final project, worth a big chunk of our marks, was some stupid little game. I couldn’t be arsed to tinker with it, so mine basically worked but was a bit confused about screen edges (you had to manage that manually, of course). But my code was clean and reasonably elegant, including EQU * on labels, as there was no DS 0H equivalent. I got 48/50, marked down for using condition code as return value from subroutines that tested single conditions, and for using those EQU *. Went to TA, who insisted those were poor practices, without being able to articulate why. Went to prof, who shrugged and said "48 out of 50 is pretty good". Meanwhile, my buddy who had been up all night making his program work perfectly got 46/50. If I was irritated, he was furious, since he knew mine only mostly worked. That was 37 years ago. But I'm not bitter...
Book was RE: z/OS HLASM: EQU for statement labels
> > I've been coding MVS assembler for 30 years and this is the first I've heard > of this guideline. > > Any decent text on the subject (dating from Struble's "Assembler Language > Programming > the IBM S/360" of the 1960s will point this out. Some one was asking about books and Struble is IMHO pretty good, and available for a few pounds on Abe Books UK.. Dave
