Application programming on z/OS
Previous topic | Next topic | Contents | Glossary | Contact z/OS | PDF

The Assembler language on z/OS

Application programming on z/OS

Assembler language is a symbolic programming language that can be used to code instructions instead of coding in machine language.

The Assembler language is the symbolic programming language that is closest to the machine language in form and content, and therefore is an excellent candidate for writing programs in which:
  • You need control of your program, down to the byte or bit level.
  • You must write subroutines1 for functions that are not provided by other symbolic programming languages, such as COBOL, FORTRAN, or PL/I.

Assembler language is made up of statements that represent either instructions or comments. The instruction statements are the working part of the language, and they are divided into the following three groups:

  • A machine instruction is the symbolic representation of a machine language instruction of instruction sets, such as:
    • IBM® Enterprise Systems Architecture/390 (ESA/390)
    • IBM z/Architecture®

    It is called a machine instruction because the assembler translates it into the machine language code that the computer can execute.

  • An assembler instruction is a request to the assembler to do certain operations during the assembly of a source module; for example, defining data constants, reserving storage areas, and defining the end of the source module.
  • A macro instruction or macro is a request to the assembler program to process a predefined sequence of instructions called a macro definition. From this definition, the assembler generates machine and assembler instructions, which it then processes as if they were part of the original input in the source module.

The assembler produces a program listing containing information that was generated during the various phases of the assembly process.2 It is really a compiler for Assembler language programs.

The assembler also produces information for other processors, such as a binder (or linker, for earlier releases of the operating system). Before the computer can execute your program, the object code (called an object deck or simply OBJ) has to be run through another process to resolve the addresses where instructions and data will be located. This process is called linkage-editing (or link-editing, for short) and is performed by the binder.

The binder or linkage editor uses information in the object decks to combine them into load modules. At program fetch time, the load module produced by the binder is loaded into virtual storage. After the program is loaded, it can be run.

Figure 1 shows these steps.

Figure 1. Assembler source to executable module
Assembler source to executable module

Related reading: You can find more information about using Assembler language on z/OS in the IBM publications, HLASM General Information, GC26-4943, and HLASM Language Reference, SC26-4940.

1 Subroutines are programs that are invoked frequently by other programs and by definition should be written with performance in mind. Assembler language is a good choice for a subroutine.
2 A program listing does not contain all of the information that is generated during the assembly process. To capture all of the information that could possibly be in the listing (and more), the z/OS® programmer can specify an assembler option called ADATA to have the assembler produce a SYSADATA file as output. The SYSADATA file is not human-readable—its contents are in a form that is designed for a tool to process. The use of a SYSADATA file is simpler for tools to process than the older custom of extracting similar data through "listing

Go to the previous page   |   Go to the next page

Copyright IBM Corporation 1990, 2010