Machine-Level Assembly Language

John W Kennedy wrote:

> Jerry Peters wrote:

>> It always amazed me that anyone could have designed something as bad
>> as DOS/360; you had to tell the idiot OS where on the disk your file
>> was if you opened it for write, even though the information was in the
>> VTOC.

> Historically, DOS/360 was first announced as "BOS/360 16K Disk", an
> advanced form of "BOS/360 8K Disk" (later simplified to "BOS/360"). That
> says it all, really. At the 1964-66 epoch, there were still plenty of
> IBM customers who regarded operating systems, per se, as annoying wastes
> of hardware, and the minimum of 32K required for OS/360 as positively
> unconscionable.

I probably believe that DOS/360 was fine as a stepping stone
while small machines were affordable and large ones weren't.

I do believe DOS/360 and its descendants have survived
too long, though.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> John W Kennedy wrote:
>
>> Jerry Peters wrote:
>
>>> It always amazed me that anyone could have designed something as bad
>>> as DOS/360; you had to tell the idiot OS where on the disk your file
>>> was if you opened it for write, even though the information was in the
>>> VTOC.
>
>> Historically, DOS/360 was first announced as "BOS/360 16K Disk", an
>> advanced form of "BOS/360 8K Disk" (later simplified to "BOS/360"). That
>> says it all, really. At the 1964-66 epoch, there were still plenty of
>> IBM customers who regarded operating systems, per se, as annoying wastes
>> of hardware, and the minimum of 32K required for OS/360 as positively
>> unconscionable.
>
> I probably believe that DOS/360 was fine as a stepping stone
> while small machines were affordable and large ones weren't.
>
> I do believe DOS/360 and its descendants have survived
> too long, though.
>
> -- glen
>
Really small by today's standards. The bank I worked at had a 360/40
and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
OS/360 on them at one point, until going to a pair of 370/155's with
1mB each, WOW, a whole megabyte of storage! Running MVT BTW.

Much, much too long. It should have been killed of by say 1980 or so.

Jerry

I gotta agree the c***** features of DOS/360 should have been
fixed long ago (for all I know they have been fixed). I was
always an OS/360 type.
Jerry Peters wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> John W Kennedy wrote:
>>
>>> Jerry Peters wrote:
>>>> It always amazed me that anyone could have designed something as bad
>>>> as DOS/360; you had to tell the idiot OS where on the disk your file
>>>> was if you opened it for write, even though the information was in the
>>>> VTOC.
>>> Historically, DOS/360 was first announced as "BOS/360 16K Disk", an
>>> advanced form of "BOS/360 8K Disk" (later simplified to "BOS/360"). That
>>> says it all, really. At the 1964-66 epoch, there were still plenty of
>>> IBM customers who regarded operating systems, per se, as annoying wastes
>>> of hardware, and the minimum of 32K required for OS/360 as positively
>>> unconscionable.
>> I probably believe that DOS/360 was fine as a stepping stone
>> while small machines were affordable and large ones weren't.
>>
>> I do believe DOS/360 and its descendants have survived
>> too long, though.
>>
>> -- glen
>>
> Really small by today's standards. The bank I worked at had a 360/40
> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
> OS/360 on them at one point, until going to a pair of 370/155's with
> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
>
> Much, much too long. It should have been killed of by say 1980 or so.
>
> Jerry

Steve Myers wrote:
> I gotta agree the c***** features of DOS/360 should have been fixed long
> ago (for all I know they have been fixed). I was always an OS/360 type.

Many have, to the extent that it can be done without breaking
compatibility, and, of course, most new features that are added are as
similar to their MVS versions as possible. But, alas, the more systems
grow, the more labor has to be invested to convert, so it always seems
easier not to bite the bullet just yet.

We were lucky. We could see that we were growing quickly, and started
working on OS/360 conversion when we were still using a 360/30. It
helped that we had no pre-360 legacy to cause problems.
--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson

Jerry Peters wrote:
(snip)

> Really small by today's standards. The bank I worked at had a 360/40
> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
> OS/360 on them at one point, until going to a pair of 370/155's with
> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.

I thought 64K was a small 360/40.

> Much, much too long. It should have been killed of by say 1980 or so.

I remember some discussion on the overlay feature of
the link editor, and someone disagreed with a statement
I made about it. Sometime later I figured it must have
been the DOS/360 link editor that worked differently.

The OS/360 linker can read its own output (load module).
Can the DOS/360 linker do that?

-- glen

I can remember when a decision was made to upgrade a 370/168 from 2MB to
4MB. The systems programmers wanted to upgrade the default region size
from 108K to 384K. Operations practically revolted at the thought until
we were able to demonstrate that that there was plenty of memory to do
it and compiles and assemblies ran so much faster because they didn't
need to use spill files.

Then we proposed a conversion to SVS with HASP, the net effect was to
buy another 10 hours in a day, The previous systems programming manager
did not believe in virtual memory or HASP, the upgrade from MVT without
HASP resulted in an in incredible change in performance.

glen herrmannsfeldt wrote:
> Jerry Peters wrote:
> (snip)
>
>> Really small by today's standards. The bank I worked at had a 360/40
>> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
>> OS/360 on them at one point, until going to a pair of 370/155's with
>> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
>
> I thought 64K was a small 360/40.
>
>> Much, much too long. It should have been killed of by say 1980 or so.
>
> I remember some discussion on the overlay feature of
> the link editor, and someone disagreed with a statement
> I made about it. Sometime later I figured it must have
> been the DOS/360 link editor that worked differently.
>
> The OS/360 linker can read its own output (load module).
> Can the DOS/360 linker do that?
>
> -- glen
>

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Jerry Peters wrote:
> (snip)
>
>> Really small by today's standards. The bank I worked at had a 360/40
>> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
>> OS/360 on them at one point, until going to a pair of 370/155's with
>> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
>
> I thought 64K was a small 360/40.
>
>> Much, much too long. It should have been killed of by say 1980 or so.
>
> I remember some discussion on the overlay feature of
> the link editor, and someone disagreed with a statement
> I made about it. Sometime later I figured it must have
> been the DOS/360 link editor that worked differently.
>
> The OS/360 linker can read its own output (load module).
> Can the DOS/360 linker do that?
>
IIRC, no. It could only read object code, since it had no relocation
information and probably no symbol info either.
There was some utility that you used to "catalog" object decks to
produce a library of some sort. Don't remember what it was called.
I've worked very, very briefly in DOS/360 environments, many years
ago. Mostly I've worked in MVS environments.

Jerry

> -- glen
>

Jerry Peters wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>> Jerry Peters wrote:
>> (snip)
>>
>>> Really small by today's standards. The bank I worked at had a 360/40
>>> and a 360/50, IIRC the 40 has 128kB and the 50 256kB. We actually ran
>>> OS/360 on them at one point, until going to a pair of 370/155's with
>>> 1mB each, WOW, a whole megabyte of storage! Running MVT BTW.
>> I thought 64K was a small 360/40.
>>
>>> Much, much too long. It should have been killed of by say 1980 or so.
>> I remember some discussion on the overlay feature of
>> the link editor, and someone disagreed with a statement
>> I made about it. Sometime later I figured it must have
>> been the DOS/360 link editor that worked differently.
>>
>> The OS/360 linker can read its own output (load module).
>> Can the DOS/360 linker do that?
>>
> IIRC, no.

That is correct. That's why it was called the "core-image library" --
because contents were, bit for bit, what would be loaded into core.

> It could only read object code, since it had no relocation
> information and probably no symbol info either.

The DOS/360 linkage editor could read:
80-byte object decks, and
items from the "relocatable library".

The relocatable library mainly contained pre-assembled I/O modules and
compiler run-time libraries, plus customer-written code.

> There was some utility that you used to "catalog" object decks to
> produce a library of some sort.

MAINT -- which could:
add or replace in the relocatable and source libraries,
delete or rename in the core-image, relocatable, and source libraries,
and, later, update by line in the source library.

There were also CORGZ, which could compress and copy the libraries (DOS
libraries could be compressed from the start; OS did not get the ability
to compress a PDS until years later), and RSERV, SSERV, and, later,
CSERV to print and/or punch.
--
John W. Kennedy
"The first effect of not believing in God is to believe in anything...."
-- Emile Cammaerts, "The Laughing Prophet"

paul hinman <paul.hinman@shaw.ca> wrote:

>I can remember when a decision was made to upgrade a 370/168 from 2MB to
>4MB. The systems programmers wanted to upgrade the default region size
>from 108K to 384K. Operations practically revolted at the thought until
>we were able to demonstrate that that there was plenty of memory to do
>it and compiles and assemblies ran so much faster because they didn't
>need to use spill files.
>
.. . .

I was involved in upgrading the storage on a 155 (last IBM mainframe
to use magnetic core storage?). I think an extra 512K was involved,
but it took much careful consideration over several months.

I couldn't help thinking of that many years later when I needed to
upgrade a PC and I went to a store in the small town I was staying in,
paid cash for 1M of RAM and then walked out with it in a paper bag. I
could do something similar today, but now it might be 1G of RAM I
would walk out with.


Andy Wood
woodag@trap.ozemail.com.au

Andy Wood wrote:
> I was involved in upgrading the storage on a 155 (last IBM mainframe
> to use magnetic core storage?).

The 155 and 165 were contemporaries. The 360/22 came out after them, but
I'd say it doesn't count, since the 22s were just recycled 30s, marketed
as fill-ins until the 370/115 and 370/125 were ready.


--
John W. Kennedy
"There are those who argue that everything breaks even in this old
dump of a world of ours. I suppose these ginks who argue that way hold
that because the rich man gets ice in the summer and the poor man gets
it in the winter things are breaking even for both. Maybe so, but I'll
swear I can't see it that way."
-- The last words of Bat Masterson