IBM Mainframe Forum

for example, if the size of one virtual storage is X'7FFFFFFF', the storage from X'00000000' to X'00FFFFFF' was called by us 'below the line'(in other words, these storages can be indicated by using 24 bits), and the rest of the storage(X'01FFFFFF--X'7FFFFFFF') was called 'above the line', right?

if so, "DCB must resides below the line", this sentence means DCB must resides the storage from X'00000000' to X'00FFFFFF'.

above is what i thought about the 'line', i am not sure whether it's right or not, can somebody confirm it? thx in advance.

Bob

The Line

The designers of System/360 made a serious mistake. The PSW and a number of other system data areas had just 24-bits to represent a data area address.

The designers of OS/360 compounded this mistake by providing 24-bit data areas for addresses all over their system. At one level they can hardly be blamed; they were fighting to get the basic version of OS/360 to run – and do something useful – in 32K bytes of storage. One data area that got their attention was the DCB. The most common form of the DCB was 96 bytes, and contained at least 4 of these 24-bit address areas. To gain a little storage, some DCB expansions started – I kid you not – with
The manuals had warnings about placing DCB macros close to the start of a DSECT or DSECT. To this day, the "12 bytes of DCB data" are radically transformed when the DCB is opened.

In 1964, 16 meg seemed plenty. Only the never built Models 60 and 70 had as much as 1 meg. It was not until the late 1970s that the 16 meg limit was breached with the 3033MP.

When IBM developed their “Extended Architecture” systems in the early 1980s, they had to do something about these historical artifacts. There were tons of programs that depended on these data areas. Ultimately they did this.

• They implemented the 24-bit addressing mode which did addressing just like System/360 and the original System/370 though, of course, programs running AMODE 24 could not address storage above THE LINE..
• They published documentation warning that some common 24-bit coding conventions were dangerous.
• In early versions of MVS/XA, I believe most data management macros only worked in the 24-bit addressing mode. This restriction was eventually removed, but I don't recall when.

These users thanked the author steve-myers for the post:

drclough (Sun Mar 30, 2014 2:42 am)

bobguo wrote:... and the rest of the storage(X'01FFFFFF--X'7FFFFFFF') was called 'above the line', right? ...

Not quite. Storage "above the line" is X'01000000' to X'7FFFFFFF'.

These users thanked the author steve-myers for the post:

bobguo (Thu Oct 24, 2013 10:14 am)

steve-myers wrote:

bobguo wrote:... and the rest of the storage(X'01FFFFFF--X'7FFFFFFF') was called 'above the line', right? ...

Not quite. Storage "above the line" is X'01000000' to X'7FFFFFFF'.

yeah, my mistake! lol

There are two "lines." One at 16MB and another at 2GB. These exist due to addressing modes of 24 and 31 bits.

Here's why:

The original 360 systems only had 24 bit memory addressing and therefore a max of 16MB or real memory. In reality most of the old machines had 512K or maybe 2MB. At that time (1970s) 16MB just seemed astronomical.
The second generation of machines could support up to 2GB of ram and used 31 bit addresses, but could also be run 24-bit mode. This new use 24 and 31 bit modes affected instructions like LA and BALR. BALR/BAL is now depreciated to BASR/BAS & friends.

The latest systems now support 24/31/64 bit addresses. No machine yet exists that has 2^64 bytes of real memory, but that's just a matter of time.
===
Many old programs (and IBM-supplied macros) had code like this:

PROG CSECT
...
L R15,WORD
BALR R14,R15
...

and WORD was

WORD DS 0F
DC AL1(somebits),AL3(FUNCTION)
...

FUNCTION DS 0A
... USING FUNCTION,R15
... code....
... BR R14 Return

...

And that was considered good programming practice since you were saving a byte. When the L R15, is done we get "somebits" into the left byte 0 of R15 and the address of the FUNCTION into bytes 1,2,3. Since the machine was running in 24-bit mode then byte 0 of R15 was ignored by the BALR.
If such a program were to be run in 31 bit mode then 7 the "somebits" would (erroneously) be used as an address.

Today, if the program is loaded "above the line" then the address of the DCB would not fit into the DC AL3(DCB) anymore and thus this is not allowed. A similar problem exists with 31-bit addressing.

This leads to the need for the assembler's AMODE and RMODE pseudo-ops.

AMODE is a hint to the Assembler and Linkage Editor to tell the OS to EXECUTE the program in 24/31/64 bit.
RMODE is a hint to the Assembler and Linkage Editor to tell the OS to LOAD the program below 16M or 2G, if needed.

In the above case you would need AMODE 24 and RMODE 24 for the program to work reliably.

These users thanked the author TallBob for the post:

bobguo (Thu Oct 24, 2013 2:49 pm)

"This new use 24 and 31 bit modes affected instructions like LA and BALR."

at that time(1970s), the machine just has 24 bit memory addressing(real memory), so instruction LA must loads 24 bits into one register's bytes 1 2 3, and left byte 0(if the length of one register is 4 bytes at that time), in other words, it can load 31 bits into one register.

but now, the instruction LA can load 31 bits(or 32 bits, i'm not sure) into one register, so does LA change during these 40 years? Otherwise, we can not explain why it can load 31/32 bits now from original 24 bits.

bobguo wrote:but now, the instruction LA can load 31 bits(or 32 bits, i'm not sure) into one register, so does LA change during these 40 years? Otherwise, we can not explain why it can load 31/32 bits now from original 24 bits.

In the System/360, and the System/370 (and in the 24-bit AMODE), LA does the 24-bit address computation, stores the result in bits 8 through 31, and sets the high order bits of the register to 0. It was common to see LA x,0(,x) used to set bits 0 through 7 of a register to 0. Instructions like EDMK and TRT stored an address in bits 8 to 31 and did not alter bits 0 through 7 of register 1. In the 31-bit addressing mode, LA does the 31 bit address computation, stores the calculated address in bits 1 through 31, and sets bit 0 to 0. In the 31-bit addressing mode, TRT and EDMK store the 31-bit address and do not alter bit 0.

BAL/BALR also changed, and the BAS/BASR instructions were added. I first encountered BAS/BASR on the Model 20 and were also added to the Model 67. BAS/BASR were RPQ instructions in the 370/168 so TSS/370, the System/370 version of the TSS/360 more or less failed operating system could run. In the System/360, and the original System/370, BAL/BALR store the entire low order 32 bits of the PSW into the link register, so bits 0 through 7 were set to the instruction length code, the condition code, and the interrupt mask. In the 24-bit addressing mode, these data areas are collected and stored into the link register.

A quick quiz for you. In the R form GETMAIN macro, you seeWhy is the instruction there? What happens in the 31-bit addressing mode?

TallBob wrote:...
Many old programs (and IBM-supplied macros) had code like this:

Select all

PROG    CSECT
 ...
            L    R15,WORD
            BALR  R14,R15
...

and WORD was

Select all

WORD    DS   0F
            DC  AL1(somebits),AL3(FUNCTION)
...

The DCB was (and still is) notorious for this. The OS/360 GET/PUT/READ/WRITE/CHECK macros all had
This, of course, was changed to
This makes some things difficult for an RMODE 31/ANY program. For examplejust does not work well. Granted, by using the DCBE you can handle EODAD and SYNAD pretty easily, but the exit list and its 24-bit addresses are painful. Another surprise is the DCB open exit routine is always entered AMODE 24.

A quick quiz for you. In the R form GETMAIN macro, you see
BAL 1,*+4
Why is the instruction there? What happens in the 31-bit addressing mode?

sorry, i am not sure about the answer. can you explain it? thanks!

besides, i don't know the meaning of 'R'(within your sentence 'In the R form GETMAIN macro')

by doing this, the size of DCB was expanded by 40 bytes, from 96 to 136 bytes, so there is enough room to store 31 bits addresses, right?

"* 12 bytes of DCB data"
Do you mean at the beginning of the original DCB, there are 4 addresses, and each one is 24 bits?