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)

A bit late, but the only exceptions I can think of on S/360 are

• Branches, e.g., BCR
• Convert to Decimal (CVD)
• Execute
• Shift instructions, e.g., SRDL
• Storage Immediate (SI) instructions, e.g., MVI
• Translation instructions, e.g., Translate and Test (TRT)
• Store instructions, e.g., STH

By the time you get to z there are, of course, more, but it's still the exception. In general, the assembler syntax for any instruction format is the same regardless of the direction of data movement. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:11, 31 August 2023 (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/VSE, with the z/VSE version of the library (whch would implement its APIs atop z/VSE 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)

In the case of z/OS and z/VSE, even macros with the same name do not have the same syntax. Yes, that's one reason why, in assembly language, you can't write code using the GET and PUT sequential I/O APIs and have it build for and run on both OSes. The reasons are different for the C low-level file APIs - for example, the lowest-level sequential file I/O APIs are read() and write() on UN*Xes and ReadFile() and WriteFile() on Windows and, while the Visual Studio C library has file I/O APIs that are very similar to read() and write(), they are named _read() and _write() to avoid that very sort of name collision, and the lowest-level sequential file I/O APIs on VMS are whatever Record Management Services gives you - but the underlying problem is the same.

The HLA Toolkit does include an OS-independent macro library, containing macros for control structures, e.g., CASE, IF. Are they "OS-independent" in the sense that they have different implementations on z/OS and z/VSE because of OS differences, or are they "OS-independent" in that there is no reason to have different implementations on different OSes and thus the implementations aren't different? If the HLA Toolkit were to offer macros and library routines to hide the differences between z/OS and z/VSE sequential I/O, that would be interesting, and might be the equivalent fo the C-defined file I/O APIs. Guy Harris (talk) 22:04, 13 July 2023 (UTC)

The structured programming macros in the HLA Toolkit do not use OS services; there is a single code base regardless of OS.

OT: z/TPX cannot host any compiler; you need a z/OS or Linux system to do builds. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 05:35, 14 July 2023 (UTC)

DSECT

It occurs to me that there is no article for DSECT. I wanted to link to it, but there isn't one. Since I don't know where else to ask, I am putting it here. I believe it deserves its own article. I am not sure how it works in DOS/360 and its successors. It would also be interesting to know of other (non-IBM) assemblers with a similar system. I previously asked in OS/360_and_successors, where it was suggested to ask here. Gah4 (talk) 01:49, 31 August 2023 (UTC)

I would suggest adding CSECT, DC, DROP, DS, DSECT, EQU and USING under #Assembler instructions.

This might be a good time to move the article, as previously discussed. Or should it first be listed at WP:Requested moves for further discussion?. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:33, 31 August 2023 (UTC)

I would say discuss, there certainly has been "past debate about the best title for the page" in the Apples and Oranges section, so by my reading any further renaming would count as a potentially controversial move. Also I don't think any potential titles have actually been put forward and discussed as of yet. Mathnerd314159 (talk) 02:18, 1 September 2023 (UTC)

Requested move 3 September 2023

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. Consensus that the title "Basic Assembly Language" does not accurately describe the article's scope. The improvement in accuracy appears to have been viewed as significant enough to outweigh the reduction in WP:CONCISION. (closed by non-admin page mover) ModernDayTrilobite (talk • contribs) 14:20, 22 September 2023 (UTC)

---

Basic Assembly Language → IBM Basic assembly language and successors – The article discusses the entire family of assemblers for the IBM S/360 through z mainframes; only on BPS/360 and BOS/360 was the assembler named BAL. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:10, 3 September 2023 (UTC)

For context, I had moved the article IBM Basic assembly language to IBM Basic assembly language and successors a decade ago in edit Special:Permalink/566727959; Mathnerd314159 moved it to Basic Assembly Language on 11 July 2023 in edit Special:Permalink/1164870417. I initiated a discussion at Talk:Basic Assembly Language#Apples and oranges and am seeking comments from other editors, as well as suggestions for alternate names. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:10, 3 September 2023 (UTC)

Support The title needs to have IBM in it, and the proposed title better describes the article’s subject. Peter Flass (talk) 18:21, 3 September 2023 (UTC)

Support The proposed title is more descriptive and has similarity in form to the OS/360 and successors and DOS/360 and successors article names. Wasted Time R (talk) 18:26, 3 September 2023 (UTC)

Oppose The proposed inclusions of "IBM" and "and successors" are wordy and do not follow WP:CONCISE. The current title is WP:PRECISE enough to identify its subject. For example, [3] and [4] use BAL / Basic Assembly Language as the identifying name, sans IBM. Also note they have capitals for all three letters of BAL, as opposed to Chatul's proposal to drop the capitals for A and L. Regarding "and successors", there are sources such as [5] that state that the successors are also called BAL by some people, so it is superfluous to list a separate phrase for what actually the same thing. Furthermore the listed "OS/360 and successors" and "DOS/360 and successors" are the only use of this scheme in mainstream articles on Wikipedia; the other uses are list articles with titles such as "List of rosters for Radclub–Resch & Frisch–EYBL and its successors". I could not find any sources suggesting that the current (HLASM) assembly language is actually a different language; the IBM docs simply call it "the assembler language supported by High Level Assembler", while mentioning that it is substantially compatible all the way back to the original IBM 360 BAL. Mathnerd314159 (talk) 15:14, 5 September 2023 (UTC)

The current title is not WP:PRECISE enough to identify its subject. Most of the article is about assemblers that are not BAL. The page you cited reads

The instructions, syntax and coding conventions of the assembler language supported by High Level Assembler include functional extensions to those supported by Assembler H Version 2 and DOS/VSE Assembler. This chapter describes the most important of those extensions, and the language differences between High Level Assembler and the earlier assemblers.

It never mentions BAL or any other version of the assembler earlier than XF. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:22, 5 September 2023 (UTC)

It does, on page 4 (pdf page 43). The full quote reads:

The level that is our primary concern is usually known as “Assembler Language programming” or“assembler coding”. [Footnote 3: Some people call it “BAL” — meaning “Basic Assembler Language” — 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.] The assembler we'll describe is the IBM High Level Assembler for z/OS & z/VM & z/VSE, known as “HLASM”. It also can be used on IBM Linux for System z.

This establishes that "some people" refer to the assembly language accepted by HLASM as Basic Assembler Language. Since the earliest (360) language is BAL, and HLASM processes BAL, one logically concludes that all intermediate assemblers process BAL as well, so the entire article is indeed about BAL. There are no other identifying names for any of these languages, nor alternate meanings of BAL, so BAL as a title is indeed WP:precise and unambiguous, denoting exactly the scope of the article. Mathnerd314159 (talk) 19:00, 5 September 2023 (UTC)

the entire article is indeed about BAL So are you claiming that Basic Assembly Language § Macros and conditional assembly is about BAL? It mentions a feature that BAL lacks (and even notes that). Guy Harris (talk) 20:03, 5 September 2023 (UTC)

Everything in the table in Appendix D (pages 59-61) of IBM System/360 Basic Programming Support Basic Assembler Language that the "Basic Programming Support/360: Basic Assembler" column indicates isn't supported would not belong in an article that's solely about the IBM Basic Assembler Language. If any of that stuff is discussed in this article, this article is not solely about the IBM System/360 Basic Programming Support Basic Assembler Language. Guy Harris (talk) 21:30, 5 September 2023 (UTC)

Page 6 of IBM System/360 Basic Programming Support Basic Assembler Language states that

Programs written in the Basic Assembler Language as described in this publication are acceptable to the other Basic Programming Support, Basic Operating System, and Operating System Assemblers, and the 7090/7094 Support Package Assembler. Similarly, source programs written in these other assembly languages are acceptable to the Basic Assembler if they do not embody any of the features of these assemblers which are unacceptable to the Basic Assembler. Appendix D contains a list of features supported by the System/360 Assemblers and may be used as a guide for the interchangeability of source programs.

so the IBM System/360 Basic Programming Support Basic Assembler Language is an assembler language, programs written in which can be assembled by all of the assemblers in question. The OS/360 Assembler can also assemble programs written in another assembler language with greater capabilities than the IBM System/360 Basic Programming Support Basic Assembler Language, such as 8-character symbol names, a division operator in expressions evaluated at assembly time, and macro instructions. That language is, as per "Programs written in the Basic Assembler Language as described in this publication are acceptable to the other ... and Operating System Assemblers", a proper superset of the IBM System/360 Basic Programming Support Basic Assembler Language.

Perhaps some people have used "BAL" to refer to assembler languages other than the IBM System/360 Basic Programming Support Basic Assembler Language; if that usage is sufficiently common, perhaps a case can be made for using "BAL" as a term for all S/360 through z/Architecture assembler languages. Unless they've used "Basic Assembler Language" in that sense, rather than in the specific sense of the IBM System/360 Basic Programming Support Basic Assembler Language, a similar case for "Basic Assembler Language" would not work. Guy Harris (talk) 21:58, 5 September 2023 (UTC)

I'm one Peter Flass (talk) 23:55, 5 September 2023 (UTC)

"BAL" (which might have become a generic term divorced from its use as an initialism for "Basic Assembler Language"), or "Basic Assembler Language"? Guy Harris (talk) 02:14, 6 September 2023 (UTC)

It's a reasonable point, but alas it is unsourced. I've updated that section with Guy Harris's source and it no longer mentions BAL. Mathnerd314159 (talk) 05:27, 6 September 2023 (UTC)

Might be, but I never heard it in the OS/360 or OS/VS2 days. I never used DOS/360 or DOS/VSE. It might be that I never knew anyone who did. Did enough people call it that to make it the WP:COMMONNAME? My guess is no, but I haven't asked so many people. Gah4 (talk) 11:22, 6 September 2023 (UTC)

It was used in some shops, some textbooks, some news articles, but I wouldn't say it was the common name. Doing an ACM Digital Library search, IBM AND ("basic assembly language" OR "basic assembler language") has 28 hits, while "360 assembly language" OR "370 assembly language" OR "360 assembler language" OR "370 assembler language" produces 142 hits. Those were the common names, or simply "the assembler". Wasted Time R (talk) 23:49, 6 September 2023 (UTC)

I have lost a few times in WP:COMMONNAME discussions, when I thought an article should have the technically correct name. If it isn't the correct name or the WP:COMMONAME then maybe we should change it? Gah4 (talk) 20:40, 7 September 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

DOS vs OS?

I managed never to run anything on DOS/360, so maybe don't know much about it. As far as I know, BAL and Basic Assembler Language goes with the DOS/360, and similar smaller machine systems, such as TOS/360. In all the days of OS/360, OS/VS2, and later, I never heard the name BAL or Basic Assembler Language. I think that means that I would like to see separate articles for the two. I think I won't suggest names yet, though. Gah4 (talk) 11:00, 4 September 2023 (UTC)

They’re “basically” the same language. DOS assembler was Assembler D, and I expect it shared a lot of phases with E and F, just like other IBM compilers. Obviously it had a few limitations. “Basic” Basic Assembler lacked features such as extended branch menmonics (BCR,15 instead of B). Assembler D had those, along with full macro capability. At this remove I can’t remember the differences, they’re probably listed in a manual, but I don’t think they were much.

http://bitsavers.org/pdf/ibm/360/asm/GC28-6514-8_OS_Assembler_Language_Rel21_197201.pdf Appendix I.
Peter Flass (talk) 13:46, 4 September 2023 (UTC)

Assembler D was much more sophisticated than BAL. It was mostly upward compatible, although it did drop a few things. :Assemblers E and F were the same code base, differing in how they were link edited, and were more sophisticated than but upward compatible with D. I don't know whether D shared any code with E and F. All three had multiple phases. Assembler G was Assembler F with enhancements from the University of Waterloo.

Assembler XF was mostly upward compatible with F, had some extensions to the macro language and had the same phase structure; I'm confidant that it started from the same code base as F.

Assembler H was a completely new assembler with enhanced macro facilities. It was mostly compatible with F and, later, with XF. Assembler H V2 and HLASM started from the H code base.

The article should go into this in more detail, absent the conjecture about the XF code base. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:06, 5 September 2023 (UTC)

Problems with external links

I've run into some issues with #external links:

1. IBM High Level Assembler manual
   • doesn't indicate which manual
   • Should be ... General Information
2. High Level Assembler for z/OS & z/VM & z/VSE Language Reference
   • Unable to connect
   • There's a 2017 copy at [6]
   • I'm pretty sure that there's a more recent one online
3. Web enabled IBM Assembler F compiler for small experiments
   • 404 compliant
4. ASSIST – Assembler System for Student Instruction & Systems Teaching
   • 404 compliant

I'll look around and see what I can find to update these, but if someone else gets there first I'll be happy. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:54, 29 September 2023 (UTC)

Nomenclature - truncated addressing

@Peter Flass: Should the article use the generic term of art "truncated addressing", or should it use the term "base-displacement addressing" introduced with System/360?

Wow, some pretty old manuals! Unfortunately they’re not searchable, so I wasn’t able to easily find references to “truncated.” In any case, the article is about software for System/360, so I think the IBM terminology makes more sense. Peter Flass (talk) 17:48, 18 October 2023 (UTC)

References