Talk:IBM Basic assembly language and successors

BAL brings back memories

         XC   CATS,DOGS
         XC   DOGS,CATS
         XC   CATS,DOGS
 
 CATS    DC   CL32'Now is the time for all good men'
 DOGS    DC   CL32'It is a far far better thing I d'

I loved those Boolean operators. Naaman Brown (talk) 00:22, 4 February 2009 (UTC)

I love the Execute instruction. You could actually write a very complex program on a 16K machine. —Preceding unsigned comment added by 24.207.255.169 (talk) 02:49, 29 October 2009 (UTC)

There is a lot to be written about IBM System/360 and its successors. The jumps to 31 and 64 bit addressing. The migration of system calls from SVC (Supervisor Call) instructions, with the overhead of the interrupt handler to PC, especially for in-address-space services such as storage management. The evolution of secondary address spaces. Count Key Data disks vs fixed block (and the emulation issues). It goes on. One day… Jhlister (talk) 00:56, 12 February 2010 (UTC)

The purpose of EX was not to write gratuitous self-modifying code although from your comments that was a common misuse. The purpose was to provide a way to cater for dynamic length moves and other instructions where the lengths of the operands were not known until EXecution time.

Other techniques were designed and deployed for memory constrained environments such as linkage overlays. 84.228.198.178 (talk) 18:56, 18 December 2010 (UTC)

The Difference between BAL and ALC

My understanding is that BAL lacked the Extended Mnemonics of ALC. Thus one was forced to code BC 8,LABEL rather than BE LABEL. I suspect that BAL was provided by IBM to support BOS and BPS, which were the early operating systems.

Since C was not used anywhere I worked so I cannot address it, but I very much doubt that any compiled language can compete with well written assembler. The real heart of the matter is that companies were willing and able to trade cycles (and other resources) for an expanded work force. It is hard to train an accomplished assembler programmer when compared to a higher level language programmer.

From my experience (30+ years) as a mainframe systems programmer.

24.130.152.247 (talk) 17:56, 3 April 2010 (UTC)

The name BAL hasn't been used outside of applications shops in the 1980s. Everybody for the last 25 or 30 years just calls it assembler. Not assembly, not assembly language, just "assembler".84.228.198.178 (talk) 18:53, 18 December 2010 (UTC)

No, it was not only extended mnemonics that made Basic Assembler Language different than MACRO Assemblers, it was the flexible MACRO support. IBM has called MACRO assembler: Full Assembler
Basic Assembler Language is assembler language without full MACRO support.
Basic Assembler language can still be taught in classes that teach assembler without teaching the MACROs needed for zOS, TSO, CMS, CP, zVSE, CICS, etc. Student's first class is to learn assembler. Other non-BAL instruction will be needed for the MACROs for the system that a student might want to write code for. Somitcw (talk) 16:17, 29 May 2015 (UTC)

As well as I know, the term BAL was not usually used for the macro assemblers F and up. It might have been usual for the D and E assemblers, and maybe for the DOS/360 F assembler. Gah4 (talk) 09:36, 16 February 2019 (UTC)

"Hello World" does not need savearea

The "Hello World" example stacks a new savearea. This is not necessary, because the "WTO" ("write to operator") eventually expands into a "supervisor call" hardware instruction. Supervisor call handlers in the operating system save and restore registers into their own savearea, not into the savearea pointed to by register 13 upon invocation. Savearea's typically are needed if routines are invoked by a CALL macro instruction, which expands into a BAL or BALR instruction, that invokes the required routine directly, without supervisor involvement (supervisor = operating system).

Granted, the "Hello World" program becomes amazingly simple even in Assembly Language if no (new) savearea is needed. If you want to underline the complexity of this language, peraps use an OPEN, CLOSE, PUT and DCB macro instruction instead. It is actually bad practice to make undue WTO calls, because the operator of a mainframe typically is a person in the computer center, not the user. Rbakels (talk) 05:04, 19 July 2010 (UTC)

Hmm. OPEN, CLOSE & PUT are executable macro instructions: they generate code. OPEN and CLOSE result in SVC (Supervisor Call) instructions. PUT results in a subroutine call, the address of which is obtained from the open DCB (and I can’t remember what the routine is, but it’s one of the LPA routines that support QSAM buffering). So PUT does require a save area.

On the other hand, the DCB macro generates a control block (data structure) that the Z/OS operating system uses to coordinate input/output for a given file. It’s an unfortunate part of the history of the OS/360 and successor operating systems that OS data structures are maintained in user space.

And if anyone finds that weird, look at the underlying code for VSAM, VTAM, and the ACB!

Jhlister (talk) 02:35, 4 July 2012 (UTC)

The "Hello World" example is seriously flawed anyway, regardless of whether a savearea is needed or not. Two instructions into the code, registers 12 and 15 will both contain the entry address of the program. However, at this point the Assembler is told to use this position as its assembly base (by the USING *,12 instruction). But we already know that register 12 does not contain this address - it contains the entry point of the program (as above). That is, the base address is incorrect, and the results of this program execution will be unpredictable.

Two possible ways of fixing this.....

1. Move the USING statement to the beginning of the program (i.e. immediately after the CSECT statement), so that USING will reflect register 12's eventual contents. Or... 2. Replace the LR 12,15 instruction with an instruction that establishes addressability two instructions in e.g. BALR 12,0.

This is very basic, I was very surprised indeed to see such a basic programming error in a facility such as Wiki.

Lazyzee (talk) —Preceding undated comment added 20:35, 5 February 2013 (UTC)

For PCP, MFT, MVT, VS1, SVS, MVS, CMS, to zOS:

HELLO    CSECT ,
        PRINT ON,GEN,DATA        I want to see all
        USING HELLO,15           Register 15 points to entry address
        WTO   'Hello world',ROUTCDE=11  Issue SVC X'35'
        DROP  15                 WTO zeroed register 15
        BR    14 or SVC   3      Return to caller
        END   ,                  End of this program

Somitcw (talk) 17:22, 29 May 2015 (UTC)

Instruction Format

The article read "In most instructions, the target for an instruction appears first, then the source on the right (as with "a = 6" in C or Algol programming)." This is just not true. Peter Flass (talk) 03:18, 9 January 2012 (UTC)

I disagree: I don't want to count instructions by hand, but there are classes of instructions which follow the rule:

The RR instructions:

     AR  RX,RY

Adds the contents of RY to RX, so the target is RX.

The RX instructions:

   A   RX,nnn(RY,RZ)

adds the contents of the storage location indexed by RY, RZ and the offset nnn to RX. So the target is RX. There is an exception here: the Store instructions go the other way round.

The decimal, and character instructions work the same way.

Jhlister (talk) —Preceding undated comment added 20:46, 25 August 2012 (UTC)

Assembler versions

When I started this section I figured on a few entries, but it's growing like Topsy. Maybe it should be a separate article? [There are still a few to add, and it probably should include non-IBM S/360, etc. assemblers.] Peter Flass (talk) 12:14, 9 October 2012 (UTC)

---

Does anyone have information on ASMH version 1? Google has zip. I listed ASMH before XF because my recollection is that V1 was a 360 assembler. Peter Flass (talk) 13:51, 16 December 2012 (UTC)

---

Versions section reference possible issue.
Sub-section 7090/7094 Support Package assembler reference [2] is for Basic Programming Support ( actual true ) Basic Assembler Language so is in sub-section Basic Programming Support assembler also.
Was the reference in the wrong sub-section causing duplication meant?
74.110.174.132 (talk) 17:18, 1 July 2015 (UTC)

XFR directive

Which system/assembler version supported the XFR directive - one of the BPS assemblers? Peter Flass (talk) 00:20, 8 November 2012 (UTC)

Capitalization of article title

If the article is about Basic Assembly Language (BAL), should those words also be capitalized in the article title, making it “IBM Basic Assembly Language and successors”? In other words, does BAL count as a proper name under WP:TITLEFORMAT? 50.181.30.121 (talk) 08:22, 5 May 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on IBM Basic assembly language and successors. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20160123064644/http://www.redbooks.ibm.com/redbooks/pdfs/sg243910.pdf to http://www.redbooks.ibm.com/redbooks/pdfs/sg243910.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:44, 10 November 2017 (UTC)

Apples and oranges

@Fish, Peter Flass, Gah4, Guy Harris, Mathnerd314159, and Rfc1394: Recent edits inappropriately renamed the article and conflated several very different assembler. Two edit summaries cited WP:PRECISE, but the moves violated Usually, titles should unambiguously define the topical scope of the article.

The edit https://en.wikipedia.org/w/index.php?title=Basic_Assembly_Language&oldid=1164874838 introduces errors. E.g., the tables shows Basic Assembler Language as having been written in HLASM, which did not exist at the time, and as running on systems other than BPS/360, which it is not able to do. Absent a compelling reason, I plan to restore the status quo. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:27, 11 July 2023 (UTC)

"What the heck?" was my response to that move and merge, too. Go ahead and restore the status quo. Guy Harris (talk) 18:28, 11 July 2023 (UTC)

Well, according to the definition, HLASM is a assembler, not a language. So the essential question is what language HLASM consumes. As far as I could tell, the language HLASM consumes is BAL.

Your comment seems confused about the definitions of various terms. BAL is a language, not an assembler, so it is not written in anything. Mathnerd314159 (talk) 18:33, 11 July 2023 (UTC)

For example, look at [1] - the language (per the footnote) is Basic Assembler Language, the assembler is the IBM High Level Assembler for z/OS & z/VM & z/VSE, known as “HLASM”. Hence the current structure, an article on BAL listing the main implementation as HLASM. Mathnerd314159 (talk) 19:06, 11 July 2023 (UTC)

No-one I remember from the OS/360 days called the assembler BAL. It might be that some who migrated from the DOS/360 world to the OS/360 world did that. I suspect not enough to make it the WP:COMMONNAME though. Even if it was, though, I don't believe it is by the time you get to HLASM. Should the DOS (and successor) assemblers and OS (and successor) assemblers have separate articles? Gah4 (talk) 22:04, 11 July 2023 (UTC)

I always heard it called BAL, but then everyone I knew “migrated from the DOS/360 world to the OS/360 world.” Peter Flass (talk) 22:53, 11 July 2023 (UTC)

No one I knew in the OS/370 world called either the language or the assembler BAL. It was generally just known as "370 Assembly language" or "the IBM Assembler" or variations thereof. The textbook that was assigned in the class where I was first exposed to it was titled System/360–370 Assembler Language (OS). Wasted Time R (talk) 23:07, 11 July 2023 (UTC)

For example, look at [2] - the language (per the footnote) is Basic Assembler Language. A footnote that starts out "Some people call it "BAL"..." doesn't strike me as a strong endorsement of the language's name being BAL/Basic Assembler Language. Following that up with "...but the language is not basic (nor is it BASIC) except in the sense that it can be fundamental to understanding the System z processor's operations." further weakens any such inferred endorsement.

The document in question speaks of it as just "Assembler language", starting with the title. Guy Harris (talk) 09:13, 12 July 2023 (UTC)

Actually, that footnote does not say what you claim. The footnote says that some people call it an incorrect name. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:43, 12 July 2023 (UTC)

No, the footnote states the fact that some people call it that name. It then goes on to express the author's WP:BIASED opinion that the name is a poor choice of name. But the author does not propose a better name; he just calls it Assembler language, which is too generic to use. So unless you find some more sources then Basic Assembly language is the most recognizable WP:COMMMONNAME. In particular I looked for but did not find any sources that describe HLASM as a distinct language, so your splitting of the infobox into two languages is a complete fabrication. Mathnerd314159 (talk) 16:45, 12 July 2023 (UTC)

References

Much of "General characteristics" amounts to "this is an assembly language"

Much of Basic Assembly Language § General characteristics can be summarized as "This is an assembly language, with all that implies." Guy Harris (talk) 08:55, 12 July 2023 (UTC)

I've pruned it a bit. (x86 assembly language could probably use some pruning as well.) Guy Harris (talk) 09:05, 12 July 2023 (UTC)

two comments

1. I don’t think it’s accurate to call it “extremely restricted.” At the time it had fairly typical features. Although it has since been greatly extended, this says nothing about the original version. 2. If we’re quibbling about calling it BAL, I have never head it called “ALC,” while I have always seen/heard “BAL.” Peter Flass (talk) 13:42, 12 July 2023 (UTC)

BAL didn't have macros, at a time when many small systems and all large systems had macro assemblers, with the exception of the Burroughs stack oriented machines. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:50, 12 July 2023 (UTC)

still not right

If we don’t want to call anything other than the BPS assembler “basic assembly language”, then there’s still any number of versions between that and HLASM (ASMD, ASME, ASMF, a VS version I can’t think of, etc.) One reason this is significant is the license - all versions up to the VS assembler are open-source. Peter Flass (talk) 18:00, 12 July 2023 (UTC)

Off the top of my head

Basic Assembler

BAL, BPS/360 only

Assembler D

Bundled with DOS/360 and TOS/360

Assembler E

Bundled with OS/360

Assembler F

Bundled with OS/360, CP-67, TSS/360

Assembler G

Waterloo modifications to Assembler F

Assembler XF

Bundled with OS/VS1, OS/VS2, VM, DOS/VS, DOS/VSE

Assembler H

Program product for OS/360, OS/VS, VM

Assembler H Version 2

Program product for MVS, VM

HLASM

Program product for MVS/ESA, VM/ESA and VSE/ESA and later

Currently bundled with z/OS

I don't believe that we need infoboxes for more than the first and last. I don't recall when HLASM was first bundled. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:42, 12 July 2023 (UTC)

assembler vs assembly

As noted above, I didn't hear it called BAL until many years later. From close to the beginning, though, I remember knowing both assembly language and assembler language, often enough shortened to the first word. This gets back to the question asked above, about the name of the language vs. the name of the program. The program is always assembler, but the language is often assembly. ASSEMBLE is used by VM/CMS as the file type, as it has to fit in 8 characters. Gah4 (talk) 21:06, 12 July 2023 (UTC)

The assembler for BAL is named Basic Assembler. There is a link to http://bitsavers.org/pdf/ibm/360/bos_bps/C20-6503-0_BAL_Feb65.pdf in the article. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:53, 12 July 2023 (UTC)

Even something as simple as writing a "sequential file" is coded differently e.g. in z/OS than in z/VSE.

The article says: Even something as simple as writing a "sequential file" is coded differently e.g. in z/OS than in z/VSE which I presume is true. z/VSE is a descendant of DOS/360, and z/OS a descendant of OS/360. They started out different, and are still different. I suspect that the macros for DOS/360 are similar to those of z/VSE. At some point, DOS/360 was supposed to be interim until OS/360 was available. In that sense, we could ask why we are still using it (almost) 60 years later. Or maybe we should have two articles, one for the DOS/360 side, and one for the OS/360 side, which it seems will never meet. Gah4 (talk) 07:33, 13 July 2023 (UTC)

What they're discussing amounts to "z/VSE isn't mostly compatible with z/OS"; they compare this with UN*X system calls, but, at least at the level of calls mentioned in POSIX, UN*Xes are 99% compatible. The fact that z/VSE isn't mostly compatible with z/OS isn't the fault of assembly language. If they want an apples-to-apples comparison, then, well, "Even something as simple as writing a "sequential file" is coded differently e.g. in UN*X than in Windows NT.", at least at the low-level API layer - open() isn't the same as CreateFile(), write() isn't the same as WriteFile(), etc. (although they're in some ways not too different, as they both involve pathnames and seekable byte streams, but I digress).

So I'm not sure what point they're trying to make, other than "IBM's mainframe OSes aren't like different UN*X ports, they're different OSes with different APIs", which is true, but it's not clear why it's significant here, unless the goal is to disabuse members of the UN*X community of the notion that all IBM mainframe OSes have the same APIs. Guy Harris (talk) 07:51, 13 July 2023 (UTC)

I tweaked that part a bit. Hopefully it explains why this is the case sufficiently that it no longer lets the reader get the impression that this should be considered surprising. Guy Harris (talk) 08:13, 13 July 2023 (UTC)

Looks fine to me. I do still wonder, though, if they should be separate articles. We wouldn't have the same article for Unix assembler and Windows assembler, even when running on the same hardware. As I never had the chance to run anything on DOS/360, it took some time to know how different they are! Gah4 (talk) 09:09, 13 July 2023 (UTC)

The references to z/OS and z/VSE are just examples of the fact that HLASM allows user-provided libraries and does not dictate the contents of those libraries. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 13 July 2023 (UTC)

Essentially the same is true for anything that allows user-defined libraries: the semantics, and sometimes the syntax, depend on the libraries that the user provides. There is nothing special about, e.g., SYS1.MACLIB, from the perspective of HLASM. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:23, 13 July 2023 (UTC)

"True" in the sense that "there may be two or more libraries, for a given language, where the libraries provide ways of doing some particular thing, but the way you do it with one of those libraries isn't the way you do it with another", but if smething allows user-defined libraries, user-defined libraries could be provided for several different OSes that supprt sequential file access with the same API on all of those different OSes, so you *could*, for example, provide the ability to sequentially write a file with the same code on z/OS and z/VSE, by linking the code, on z/OS, with the z/OS version of the library (which would implement its APIs atop QSAM APIs) and linking the code, on z/VME, with the z/VME version of the library (whch owuld implement its APIs top z/VME sequential I/O macros).

But if you want to use the OS's "native" sequential I/O APIs, you'd have to write different code for different OSes, as the APIs in question aren't the same.

This is similar to, for example, "if you want to write code to write a text file sequentially, using the same C code on multiple OSes, you can use the standard C I/O routines, which would be implemented differently atop OSes that have different APIs for that, but if you want to use the native APIs, you might be able to do that with common code atop Linux/Solaris/macOS/FreeBSD/HP-UX/NetBSD/AIX/V7 UNIX/..., as they're all UN*Xes with the same core APIs for that, but you'd have to change the code a bit on Windows and a lot on VMS or other OSes for which there are C compilers". The difference here is that, as far as I know, HLASM doesn't provide any libraries with OS-independent sequential I/O APIs, whereas the library for a hosted C implementation must provide the standard C I/O routines. Guy Harris (talk) 21:03, 13 July 2023 (UTC)

In the case of z/OS and z/VSE, even macros with the same name do not have the same syntax.

The HLA Toolkit does include an OS-independent macro library, containing macros for control structures, e.g., CASE, IF. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:24, 13 July 2023 (UTC)