IBM S/360 series operating systems history
Patrick Mulvany
operating systems. This is a very large task especially as a lot of the
information about the early operating systems is quickly disappearing.
A major part of this is the IBMs S/360 family of hardware and the operating
systems that have running on it over the years.
http://www.oshistory.net/metadot/index.pl?id=2195
I have quite a lot of information on the releases of :-
MVS - Mainly missing clarification of the 1960-1972 period
http://www.oshistory.net/metadot/index.pl?id=2238;isa=Category;op=show
VM - Missing information prior to 1987
http://www.oshistory.net/metadot/index.pl?id=2236;isa=Category;op=show
VSE - Missing very early history DOS/VSE and before. Not sure if this is the
same DOS and TOS as in the MVS history.
http://www.oshistory.net/metadot/index.pl?id=2237;isa=Category;op=show
TPF - Almost completely missig ACP
http://www.oshistory.net/metadot/index.pl?id=2229;isa=Category;op=show
All information welcome, especially corrections, ommisions and
clarifications of the early history of S/360 series.
Thanks in advance
Patrick Mulvany
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Anne & Lynn Wheeler
> Over the past few years I have been putting together a history timeline of
> operating systems. This is a very large task especially as a lot of the
> information about the early operating systems is quickly disappearing.
>
> A major part of this is the IBMs S/360 family of hardware and the operating
> systems that have running on it over the years.
> http://www.oshistory.net/metadot/index.pl?id=2195
>
> I have quite a lot of information on the releases of :-
>
> MVS - Mainly missing clarification of the 1960-1972 period
> http://www.oshistory.net/metadot/index.pl?id=2238;isa=Category;op=show
>
> VM - Missing information prior to 1987
> http://www.oshistory.net/metadot/index.pl?id=2236;isa=Category;op=show
>
> VSE - Missing very early history DOS/VSE and before. Not sure if this is
> the
> same DOS and TOS as in the MVS history.
> http://www.oshistory.net/metadot/index.pl?id=2237;isa=Category;op=show
>
> TPF - Almost completely missig ACP
> http://www.oshistory.net/metadot/index.pl?id=2229;isa=Category;op=show
>
> All information welcome, especially corrections, ommisions and
> clarifications of the early history of S/360 series.
lots of vm history in melinda's share paper: VM and the VM Community: Past, Present, and Future ...
http://www.princeton.edu/~melinda
old email that has been posted/archived ... some of which relates to vm
http://www.garlic.com/~lynn/lhwemail.html
for instance Melinda's paper talks about TSM (renamed ADSM) originating as CMSBACK starting in 1983. However, by 1983, cmsback was already into its 3rd or 4th version ... old email about CMSBACK ... predating 1983
http://www.garlic.com/~lynn/lhwemail.html#cmsback
In fact, the two people mentioned for CMSBACK in Melissa's paper weren't even hired at the time CMSBACK was originally done.
another source of VM historical information is the VMSHARE archive
http://vm.marist.edu/~vmshare/
on online VM related online computer conferencing originated in the mid-70s
http://vm.marist.edu/~vmshare/
offered as a SHARE service by Tymshare corporation. Tymshare was a commercial vm370-based online timesharing service bureau ... misc. past posts mentioning online vm370-based commercial timesharing service operations
http://www.garlic.com/~lynn/subtopic.html#timeshare
also some old email specifically mentioning vmshare
http://www.garlic.com/~lynn/lhwemail.html#vmshare
if you want a little topic drift ... lots of past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech
which is where the original virtual machine operating system originated (cp67, precursor to vm370).
it is also where GML was invented ... precursor to SGML and antecedent to HTML, XML, etc
http://www.garlic.com/~lynn/subtopic.html#sgml
and also where the internal network originated ... lots of past posts observing that the internal network was larger than the arpanet/internet from just about the beginning until sometime mid-85
http://www.garlic.com/~lynn/subnetwork.html#internalnet
and a derivative of the internal networking software was also used for BITNET/EARN
http://www.garlic.com/~lynn/subnetwork.html#bitnet
misc. old email with some mention of VNET
http://www.garlic.com/~lynn/lhwemail.html#vnet
Gilbert Saint-Flour
> (...) A major part of this is the IBMs S/360 family of hardware and
> the operating systems that have running on it over the years.
> http://www.oshistory.net/metadot/index.pl?id=2195
>
> All information welcome, especially corrections, ommisions and
> clarifications of the early history of S/360 series. (...)
I suggest reading "IBM's 360 and Early 370 Systems",
an 800-page book published in 1991 by Pugh, Johnson
and Palmer, particularly chapter 6 "Software Support".
--
Gilbert Saint-Flour
GSF Software
http://gsf-soft.com/
Clark Morris
>Over the past few years I have been putting together a history timeline of
>operating systems. This is a very large task especially as a lot of the
>information about the early operating systems is quickly disappearing.
>
>A major part of this is the IBMs S/360 family of hardware and the operating
>systems that have running on it over the years.
>http://www.oshistory.net/metadot/index.pl?id=2195
>
>I have quite a lot of information on the releases of :-
>
>MVS - Mainly missing clarification of the 1960-1972 period
>http://www.oshistory.net/metadot/index.pl?id=2238;isa=Category;op=show
I believe that MFT and MVT went unsupported in 1977. My shop ran
unsupported until the 1980's (Westinghouse Lamp Divisions, yes the
plural is accurate for at least some of the period). Due to water on
our mod 65 we also ran MVT on a 4341.
Ken Brick
> Over the past few years I have been putting together a history
> timeline of
> operating systems. This is a very large task especially as a lot of the
> information about the early operating systems is quickly disappearing.
> /unsip
> VSE - Missing very early history DOS/VSE and before. Not sure if this
> is the
> same DOS and TOS as in the MVS history.
> http://www.oshistory.net/metadot/index.pl?id=2237;isa=Category;op=show
>
DOS r26 was the last real memory DOS
DOS/VS R27 1972-73 timeframe - check when the small 370'e (135 & 145)
become available
Last DOS/VS R35 probably 1982 to be followed by the VSE series (probably
when the 4331/4341 become available)
Been a long time
Ken
Ken Brick
TPS (Tape Programming System)
DPS (Disk Programming System)
BPS (Basic Programming System although it might have been CPS for Card )
These all run on the System360/20 machines.
Ken
rkue...@ibm-main.lst
7074. (36 bit word machine)
There was an early version(s) of OS that ran on the 7094.
The original "production" version of OS was PCP (primary control
program?). It was used on the 360/75 at Oak Ridge National Laboratory
(1966-?). For more info ask Robert Rannie.
There were two version of MFT -- one with multitasking and one without.
The FE manual S229-3169-3 (1971July) refers to a manual "OS planning for
MFT II" GC27-6939.
IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU> wrote on 02/18/2007
03:24:02 PM:
-----------------------------------------
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. The information may also constitute a legally
privileged confidential communication. If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited. If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message. Thank you
john gilmore
>
>IBSYS was the operating system of the IBM 7094 and probably the 7090 7070
>7074. (36 bit word machine)
>
>There was an early version(s) of OS that ran on the 7094.
>
Two corrections:
o Strike IBM 7070 and 7074; they were very different, business not
scientific machines; and
o A simulator/emulator of the System/360, SUPPAK, not OS, ran of the 7090-4.
John Gilmore
Ashland, MA 01721-1817
USA
_________________________________________________________________
Don’t miss your chance to WIN 10 hours of private jet travel from Microsoft®
Office Live http://clk.atdmt.com/MRT/go/mcrssaub0540002499mrt/direct/01/
john gilmore
authlorization.
John Gilmore
Ashland, MA 01721-1817
USA
_________________________________________________________________
Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month.
Intro*Terms http://www.NexTag.com
Shmuel Metz , Seymour J.
at 06:22 PM, Ken Brick <kbr...@NETSPACE.NET.AU> said:
>Last DOS/VS R35 probably 1982 to be followed by the VSE series
>(probably when the 4331/4341 become available)
Yes; DOS/VSE was announced concurrently with ECPS:VSE, which was
initially only available on the 4341.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Shmuel Metz , Seymour J.
02/18/2007
at 08:24 PM, Patrick Mulvany <pmul...@GMAIL.COM> said:
>MVS - Mainly missing clarification of the 1960-1972 period
>http://www.oshistory.net/metadot/index.pl?id=2238;isa=Category;op=show
There are some serious errors.
First, while OS/360 derived some concepts from IBSYS, it did not
evolve from it.
Second, you list "releases" of OS/360 that have nothing to do with
OS/360: "OS/360 BOS-8k", "OS/360 BPS", "OS/360 TOS", "OS/360 BOS-16k"
and "OS/360 DOS-16k". BPS/360 was not much more than a loader, BOS/360
was a separate system and TOS/360 was the same code base as DOS/360
with a tape loader instead of a disk loader. If you can get the dates
I'd advise listing the releases of DOS/360 in the VSE timeline.
PCP, MFT and MVT were all SYSGEN options of OS/360 rather than
separate systems. MFT-II replaced MFT in Release 15/16.
OS/VS2 R2 was the first release of MVS.
Missing are MVS/SE and MVS/SE2. Related to that is the question of
listing sub-releases; MVS went up to OS/VS2 R3.8, which with the
appropriate Selectable Units was the base for MVS/SE2.
It might be appropriate to include ACF/TCAM, ACF/VTAM, DF/DS, DS/EF,
DFP, DFSMS, SU7, SU64, TCAM 10, TSO/E, VSAM, VTAM and VTAM 2 in a
parallel timeline.
>VSE - Missing very early history DOS/VSE and before. Not sure if
>this is the same DOS and TOS as in the MVS history.
DOS/360, DOS/VS and DOS/VSE are predecessors to VSE/ESA; there are
several more after DOS/VSE, and I believe that they were VSE/AF and
VSE/SP. TOS/360, as noted above, is essentially the same as DOS/360.
>TPF - Almost completely missig ACP
>http://www.oshistory.net/metadot/index.pl?id=2229;isa=Category;op=show
PARS?
What about TSS 360 and the TSS/370 PRPQ?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Charles Mills
Only if a tape is essentially the same as a disk!
TOS's code base was largely common with DOS, and the programming APIs were a
subset -- but the SYSRES was on tape! Believe it or not. The equivalent of
an S806 took about ten minutes: spinning the SYSRES tape looking for the
program.
Not IBM's most successful product, neither technically nor commercially.
It shows how far we have come: once, disk was so expensive that people
contemplated mainframes with no disk at all. Now, personal music players
come with 4GB or more of storage.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Shmuel Metz (Seymour J.)
Sent: Monday, February 19, 2007 10:06 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history
>VSE - Missing very early history DOS/VSE and before. Not sure if
>this is the same DOS and TOS as in the MVS history.
DOS/360, DOS/VS and DOS/VSE are predecessors to VSE/ESA; there are
several more after DOS/VSE, and I believe that they were VSE/AF and
VSE/SP. TOS/360, as noted above, is essentially the same as DOS/360.
----------------------------------------------------------------------
Clark Morris
>IBSYS was the operating system of the IBM 7094 and probably the 7090 7070
>7074. (36 bit word machine)
I think you mean 7040 (there may have been a 7044). The 707x series
was based on a 10 decimal digit word.
Anne & Lynn Wheeler
>> TOS/360, as noted above, is essentially the same as DOS/360.
>
> Only if a tape is essentially the same as a disk!
>
> TOS's code base was largely common with DOS, and the programming APIs were a
> subset -- but the SYSRES was on tape! Believe it or not. The equivalent of
> an S806 took about ten minutes: spinning the SYSRES tape looking for the
> program.
>
> Not IBM's most successful product, neither technically nor commercially.
>
> It shows how far we have come: once, disk was so expensive that people
> contemplated mainframes with no disk at all. Now, personal music players
> come with 4GB or more of storage.
>
> Charles
i had summer student programming job ... developing 360 port of 1401 MPIO front-end
for 709 (univ. used 1401 for cardreader -> tape and tape -> printer/pubnch front-end
for 709 ibsys). as part of move to 360 ... the 1401 was replaced with 64kbyte 360/30.
it started out running mostly in 1401 (hardware) emulation mode. I was given the
job of rewritting MPIO in 360 assembler. I got to design and implement my own
monitor, interrupt handlers, device drivers, error recovery, storage management,
dispatching, etc. The assembler program grew to about 2000 cards. I eventually
had assembler switch that generated two different versions 1) completely stand
alone program that was loaded with the BPS stand alone loader an 2) version
that ran under os/360 (at the time release 6, pcp).
The stand-alone flavor two about 25 minutes to assemble and generate text
deck. The option to run under os/360 took an additional 25 minutes to assemble
because it had five DCB macros that needed to be expanded ... and it took
approx. five minutes elapsed time for the assembler to expand each DCB macro
(you could watch the 30's front panel lights and tell when the assembler
was expanding DCB macro because the front panel light pattern was distinct).
Before i learned about "REP" cards, i got quite proficient at reading punch
holes for the hex in "TXT" (binary) decks ... and being able to do code
patches by doing card duplication on 026 keypunch ... and multi-punch the
hole patterns for the hex patch (significantly faster than updating the
assembler card source and getting a new clean assembly).
Steve Myers
system for 7040 and 7044.
Actually, there were more like 3 MFT systems. MFT had multi-programming
with a fixed number of partitions, MFT-II was basically the same, but
with what amounted to the MVT scheduler patched into it rather than a
bastardized version of the PCP scheduler used with MFT to allow several
partitions to be scheduled rather than what amounted to one partition in
the original MFT. Late in the history - Rel 19, if I remember
correctly, MFT was extended to provide multi-tasking within a partition.
Clark Morris wrote:
> On 19 Feb 2007 10:08:45 -0800, in bit.listserv.ibm-main you wrote:
>
>> IBSYS was the operating system of the IBM 7094 and probably the 7090 7070
>> 7074. (36 bit word machine)
> I think you mean 7040 (there may have been a 7044). The 707x series
> was based on a 10 decimal digit word.
>> There was an early version(s) of OS that ran on the 7094.
>>
>> The original "production" version of OS was PCP (primary control
>> program?). It was used on the 360/75 at Oak Ridge National Laboratory
>> (1966-?). For more info ask Robert Rannie.
>>
>> There were two version of MFT -- one with multitasking and one without.
>> The FE manual S229-3169-3 (1971July) refers to a manual "OS planning for
>> MFT II" GC27-6939.
>>
>> IBM Mainframe Discussion List <IBM-...@BAMA.UA.EDU> wrote on 02/18/2007
>> 03:24:02 PM:
[snip]
Steele, Phil
versiond of the card based BPS.)
As I recall BPS stood for Basic Programming Support, ( not System) As
an operator, I did use BPS ( comlete with 3 card loader!). Although
when I started, our installation was already converting from the more
advanced BOS to the even MORE advanced DOS. ( error messages in english
even !!!) we only used BPS for some old (!) programs.
Phil Steele
>
>
>>From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Ken Brick
>Sent: Monday, 19 February 2007 6:26 PM
>To: IBM-...@BAMA.UA.EDU
>Subject: Re: IBM S/360 series operating systems history
>
>You have also missed some small relatively insignificant OS's.
>
>TPS (Tape Programming System)
>DPS (Disk Programming System)
>BPS (Basic Programming System although it might have been CPS for Card
)
>
>These all run on the System360/20 machines.
>
>Ken
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
the archives at http://bama.ua.edu/archives/ibm-main.html
*******************************************************
PLEASE NOTE: This internet email message has been checked for viruses
and appropriate content to ensure it complies with TABCORP's electronic
communication policy.
*******************************************************
***********************************************************************************
The information in this e-mail message and any files transmitted with it
are intended to be confidential and for the use of only the individual or
entity to whom they are addressed. The message and files may be
protected by legal professional privilege, or other legal rules. The
confidentiality of and privilege applying to this message and
files is not waived if this message or files has been sent to you by mistake.
If the reader of this message or files is not the intended recipient, you are
notified that retention, distribution or copying of this message and files are
strictly prohibited. If you receive this message or files in error, please
notify us immediately by telephone or return e-mail and delete all copies
from your computer system. It is the recipient's responsibility to check this
message and files for viruses.
Thank you.
***********************************************************************************
Steven Arnett
> i had summer student programming job ... developing 360 port of 1401
> MPIO front-end
> for 709 (univ. used 1401 for cardreader -> tape and tape ->
> printer/pubnch front-end
> for 709 ibsys). as part of move to 360 ...
So, you are the one! When I got to FNB Lubbock in the late 70s, they
had the 1401 Emulator coded
into the supervisor for DOS 31. They had two 1401 programs still
running. One to read cards and
write them to tape and the second to copy the tape to a second tape and
print a count of the records
copied.
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Ken Brick
Sent: Monday, February 19, 2007 1:26 AM
To: IBM-...@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history
You have also missed some small relatively insignificant OS's.
TPS (Tape Programming System)
DPS (Disk Programming System)
BPS (Basic Programming System although it might have been CPS for Card
)
These all run on the System360/20 machines.
<snip>
CPS Card Processing System (I think that was the name - it's only been a
few years). And somebody walked off with my original Yellow card (now a
booklet if IBM will even ship it). Yes, the S/360-20 had a Yellow card,
not a Green Card.
My first paying job in data processing was on a S/360-20 (8K, with the
I/O & Compute feature!) with 4 tape drives, a 2501, a 1442, a slide bar
printer (just can't remember the model). And we had 2 072 card sorters,
026 punches, 129 punch/verifiers, and some other things I just can't
remember model numbers for and for which I just couldn't wrap my head
around programming (plug boards). I had come from a college environment
where we had a S/360-30 with 2314 disk drives, so I was rather shocked
to see SYSRES on a tape for when we ran TPS.
We had 8K and we ran payroll for a few fairly large companies (we were a
circus bureau) among other accounting stuff. Let's see you do that today
on a PC (which probably has more horse power, and I/O speeds) with less
than 256MB! [Can you say, code bloat?]
And for a final laugh, we did it all with RPG (not RPG-II) or BAL IFF it
couldn't fit in memory as RPG!!!
Later,
Steve.T
bbreynolds
>
> There was an early version(s) of OS that ran on the 7094.
>
The full name of that was "7090/7094 Support Package for IBM System/
360". The first S/360 assembler language student text "A Programmer's
Introduction to the IBM System/360 Architecture, Instructions, and
Assembler Language" (C20-1646-0) had all of its samples created on the
7090/7094 support package. The introduction to the manual lists the
following as S/360 programming systems:
- Basic Progamming Support
- Basic Operating System/360
- Operating System/360
- 7090/7094 Support Package for IBM System/360
Bruce B. Reynolds, Trailing Edge Technologies, Glenside PA (who
remembers moving engineering programs such as ICES/STRUDL and COGO
from the 7044 to the 360/67)
Rick Fochtman
You have also missed some small relatively insignificant OS's.
TPS (Tape Programming System)
DPS (Disk Programming System)
BPS (Basic Programming System although it might have been CPS for Card)
These all run on the System360/20 machines.
---------------------------<unsnip>------------------------
BPS also ran on the 360/44, from that little single-platter disk is the
side of the CPU.
Shmuel Metz , Seymour J.
at 12:11 PM, Charles Mills <char...@MCN.ORG> said:
>Only if a tape is essentially the same as a disk!
The loader, library routines et al are only a tiny fraction of the
code base.
>but the SYSRES was on tape!
Isn't that what I wrote? "with a tape loader instead of a disk
loader."
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
<A02685FB4CF6CE488E6E...@BOWNEX001V02.corpad.net.local>,
on 02/20/2007
at 10:05 AM, "Steele, Phil" <ste...@TABCORP.COM.AU> said:
>As I recall BPS stood for Basic Programming Support, ( not System)
That's certainly true for BPS/360, but the 360/20 was not a S/360 and
needed its own software. Are you sure that the 360/20 BPS had the same
expansion as BPS/360?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
<OFD0634D5E.2867736A-ON852572...@tsys.com>,
on 02/19/2007
at 01:08 PM, Kirk Talman <rkue...@TSYS.COM> said:
>IBSYS was the operating system of the IBM 7094 and probably the 7090
>7070 7074. (36 bit word machine)
Nope; the 709, 7040, 7044, 9090 and 7094 weree 36 bit machines and ran
IBSYS; the 7070, 7072 and 7074 were decimal machines and there was no
IBSYS for them. Perhaps you're thinking of the 1410 and 7010, but
those are also not 36-bit machines.
>There was an early version(s) of OS that ran on the 7094.
There was a S/360 simulator that ran on the 7094. Perhaps that's what
you're thinking of.
>There were two version of MFT -- one with multitasking and one
>without.
Note my reference to MFT II supplanting MFT. They did not exist
concurrently in a single release of OS/360, the way that PCP, MFT and
MVT did.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Patrick Mulvany
Reviewing the information I currently have I realised that I have been
approaching the very early OSes in slightly the wrong way and have added a
new page covering early OSes on IBM hardware. I will work on merging the new
information into the magor timeline shortly.
http://www.oshistory.net/metadot/index.pl?id=2290;isa=Category;op=show
As before please feel free to tell me any corrections, ommisions or other
information you have.
Paddy
--
LiffOff Energy Anywhere: www.fizz2focus.com
For health and wellness solutions : www.shapingwellness.com
Opportunity : www.excitingformula.com
Charles Mills
qualifier about the loader. In my haste I saw only the second.
I think there may have been some other subsetting also. For example, I
suspect there was no problem program disk support either. (No "QSAM.") We're
on the same page -- same OS but with a tape SYSRES.
TOS was a piece of work! Every time you linkedited a program (all executable
programs in DOS/TOS in those days lived in SYSRES) it copied the SYSRES from
tape to tape, kind of like a "good old days" update of the customer master
file.
I don't recall if TOS supported overlay structures. That is not an idea
whose time has come: loading overlay segments from tape.
Charles
P.S. Aren't we supposed to be avoiding quoting peoples' e-mail addresses?
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, February 20, 2007 12:53 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history
In <01dc01c75462$148b7340$6401a8c0@Charles2006>, on 02/19/2007
at 12:11 PM, Charles Mills <x...@xxx.ORG> said:
>Only if a tape is essentially the same as a disk!
The loader, library routines et al are only a tiny fraction of the
code base.
>but the SYSRES was on tape!
Isn't that what I wrote? "with a tape loader instead of a disk
loader."
----------------------------------------------------------------------
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Behalf Of Charles Mills
Sent: Tuesday, February 20, 2007 5:08 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history
<SNIP>
TOS was a piece of work! Every time you linkedited a program (all
executable
programs in DOS/TOS in those days lived in SYSRES) it copied the SYSRES
from
tape to tape, kind of like a "good old days" update of the customer
master
file.
I don't recall if TOS supported overlay structures. That is not an idea
whose time has come: loading overlay segments from tape.
<SNIP>
TPS supported overlay structures (loaded them from the SYSRES tape), so
I just figured its bigger brother, TOS would do the same. I had a friend
who worked for Holiday Inns at Holiday City in Memphis back about 1977
where they were still running TOS (I think he had 128K) with 2311 disk
drives (if I remember the model correctly). I do not know if they
supported ISAM, BDAM or just SAM back then (what a waste of DASD if they
could only do SAM).
And why a copy of the SYSRES puzzles me. TPS actually updated the SYSRES
during a "GEN" process (where I would add in a module or replace one),
not during a run where modules were being pulled in to core.
And to someone else's post about this, an assembly took all 4 of our
tape drives, and the minimal assembly (NO macros) took 30 minutes (give
or take about 15 seconds). Most of that was just initializing things on
the work tapes!!! I say that because I used:
TEST START x'1000'
USING *,R3
NOPR 0
END TEST
A real assembly (that would expand to about 1K in size) with 3 DTFs took
about an hour. One learned to use REP cards, and clearly notate on the
listings what was zapped and why.
Later,
Steve Thompson
Ken Brick
> /snip
> And to someone else's post about this, an assembly took all 4 of our
> tape drives, and the minimal assembly (NO macros) took 30 minutes (give
> or take about 15 seconds). Most of that was just initializing things on
> the work tapes!!! I say that because I used:
> TEST START x'1000'
> USING *,R3
> NOPR 0
> END TEST
>
> A real assembly (that would expand to about 1K in size) with 3 DTFs took
> about an hour. One learned to use REP cards, and clearly notate on the
> listings what was zapped and why.
>
>
The site I worked at learnt early to split the DTFs out from the
application logic aand include them via a link edit. We also never used
the common macros eg, OPEN, CLOSE, GET, PUT, and couple of printer
positioning macros but hand coded the expansions. All in the name of
getting assemblies done in a reasonable time. The "sysres" tape had at
leat two sections to it, a "Core Image Library" for laod modules at the
beginning and at the end a "Source Statement Library" for the macros and
copy books. You knew during an assembly when it had found a macro as the
tape started spinning to the back of the tape. From memory the 2415
drives where 20KB/sec.
Shmuel Metz said
That's certainly true for BPS/360, but the 360/20 was not a S/360 and
needed its own software.
IBM called it a System 360. It had many things in common with other
S/360's and many peculiarities of it's own. It wasn't the only S/360
that had differences from the norm.
It was sufficiently S/360 for my wife to write a program to convert our
entire application library, 100% assembler, from what assembled and
worked on the model 20 to work under DOS/VS on a S370/125. Probably 99%
of the work was done by the conversion program AND it highlighted the
remaining 1% for human attention. Having said that neither she or I or
any of the other 3 programmers would ever have written code that looked
like the converted code.
Ken
Shmuel Metz , Seymour J.
at 03:08 PM, Charles Mills said:
>I think there may have been some other subsetting also. For example,
>I suspect there was no problem program disk support either. (No
>"QSAM.")
I don't know about BPS and BOS, but DOS and TOS had access methods.
The source code, however, was device dependant. Even if you used the
more recent DTFDI, which was nominally device dependent, you couldn't
use the sane DTF for UR equipment and blocked files.
>(all executable programs in DOS/TOS in those days lived in SYSRES)
Likewise macro and subroutine libraries.
>P.S. Aren't we supposed to be avoiding quoting peoples' e-mail
>addresses?
Or manually remove them when they're automatically added.
I wonder whether there's enough commonality in the syntax of
attribution lines for the list software to automatically strip the
e-mail addresses and leave the names?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 06:21 PM, Ken Brick <kbr...@NETSPACE.NET.AU> said:
>IBM called it a System 360. It had many things in common with other
>S/360's and many peculiarities of it's own. It wasn't the only S/360
>that had differences from the norm.
It was the only one that was grossly incompatible. The others may have
been missing instructions but the instructions they did have behaved
in accordance with S/360 PoOps.
>It was sufficiently S/360 for my wife to write a program to convert
>our entire application library,
That means nothing; I wrote a program to convert UNIVAC 1005 code to
S/360 assembler.
>Having said that neither she or I or any of the other 3 programmers
>would ever have written code that looked like the converted code.
That's typical for machine translation between dissimilar computers.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Anne & Lynn Wheeler
> From an unreliable memory.
>
> DOS r26 was the last real memory DOS
> DOS/VS R27 1972-73 timeframe - check when the small 370'e (135 & 145)
> become available
> Last DOS/VS R35 probably 1982 to be followed by the VSE series (probably
> when the 4331/4341 become available)
old "E-architecture" reference
From: wheeler
Date: 09/16/82 08:31:14
re: e-architecture; E-architecture is the internal name for the 370
architecture extension that came out with the (original) 4300 series
machines. It is supported by VS1E & DOS/VSE. It's primary feature is
it moves the equivalent of the page & swap tables to below the
microcode interface. There are new instructions to validate, connect,
invalidate, & disconnect page frames. This architecture as developed
primarily by Germany during the middle 70s & basicly is an attempt to
move "troublesome" pieces (for DOS) of the system down into the
hardware.
XA architecture is a completely different architecture extension. It
was developed in POK and primarily represents their (similar) goal to
migrate "troublesome" pieces of MVS down into the hardware ... giving
the hardware engineers opportunities to solve MVS system problems that
the MVS software programmers have found difficult to deal with.
Both the E & XA architecture share the feature that they are
architecture extensions tailored for a specific operating system (DOS
& MVS respectively). Both the E & XA architecture share the feature
that neither support virtual machines. POK has managed to bypass the
problem by defining a new instruction in XA called SIE which is
defined to do "whatever is necessary to run a virtual machine". On the
other hand, 4300s are primarily run in 370 mode.
... snip ...
"E" ... i.e. "e" for vs1 and dos/vs
past posts in this thread:
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems history
for other (SIE) topic drift ... recent cross-over post
http://www.garlic.com/~lynn/2007d.html#61 ISA Support for Multithreading
lots of other old email discussing 43xx boxes
http://www.garlic.com/~lynn/lhwemail.html#4341
Patrick O'Keefe
ma...@PATRIOT.NET> wrote:
>...
>It was the only one that was grossly incompatible. The others may have
>been missing instructions but the instructions they did have behaved
>in accordance with S/360 PoOps.
>...
As I recall, some of the "registers" actually had hard-coded values;
they could be used as base registers but little else. I have no idea
what happened if you tried storing into them. That alone supports your
"grossly incompatable" assertion.
It didn't even bother to pretend its linkage conventions were the same as
s/360. It used something other than the s/360 linkage instructions BAL
and BALR (BAS and BASR, as I recall).
Pat O'Keefe
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On
Behalf Of Patrick O'Keefe
Sent: Thursday, February 22, 2007 2:56 PM
To: IBM-...@BAMA.UA.EDU
<snip>
As I recall, some of the "registers" actually had hard-coded values;
they could be used as base registers but little else. I have no idea
what happened if you tried storing into them. That alone supports your
"grossly incompatable" assertion.
It didn't even bother to pretend its linkage conventions were the same
as
s/360. It used something other than the s/360 linkage instructions BAL
and BALR (BAS and BASR, as I recall).
<snip>
I rarely called other programs, but when I did, I used the basic
protocols (R0-R1, R13-R15) with STM/LM, but using halfwords.
The BAL/R did not work, because the registers were only halfword size
which meant you had no place to store the linkage information.
R3-R6 (as I recall, I don't happen to have my Model 20 card/booklet
handy) were fixed, R3= x'1000', R4= x'2000' ... I can't remember what
happened if you stored into them either (I'm not sure if you got a
"HALT" of the SPEC type or what).
R1-R2 worked exactly like the PoOP says for the other S/360s when it
came to TRT and EDMK.
I must disagree with the idea that it was "grossly incompatable" for
several reasons:
a) BAL code could be moved between the two environments with a few
changes (mainly, the half-word register conventions, and using preset
registers, which is where I think the R3 for base got started...). And
we used a BAL/BALR macro so that we didn't have to change our thinking
all the time.
b) EBCDIC is EBCDIC between the two machines (no funny stuff as happened
between Burroughs' EBCDIC and IBM's)
c) RPG moved directly from the Model 20 to any other DOS machine (H & F
specs may have needed one or two changes)
d) Tapes had the same internal formats between the two systems.
e) If you had a large enough model (sufficient memory and some channel
feature(s)), you could hang 2311 disks on them and then exchange those
with a S/360 using 2311s
f) Decimal instructions worked exactly the same, including ED and EDMK
Many years after working in a circus bureau, I had the pleasure of being
at a certain US Gov't shop, they had two model 20s where they were still
exchanging 800/1600 BPI tapes using SL with a JES3 environment. I was
the only person there that had any real experience with a 20 to do
program patches.
Perhaps my definition of gross incompatible is different. But I would
call a UNIVAC 1100 grossly incompatible with a S/360 (no real EBCDIC
support, data interchange needed to be via 9 bit ASCII, COBOL had to
converted to run on IBM from UNIVAC (or Honeywell), CARDs punched on
UNIVAC may not even be readable by IBM...).
Regards,
Steve Thompson
Steve Myers
> -----Original Message-----
[snip]
> The BAL/R did not work, because the registers were only halfword size
> which meant you had no place to store the linkage information.
> Steve Thompson
The Mod 20 used BAS/BASR for linkage, and beat the /67 for these
instructions, as well as the /370XA machines. The difference: BAL/BALR
saved the condition code, instruction length code and program mask in
the high order 8 bits of the link register. BAS/BASR uses the entire
link register for the return address. 16 bits was plenty of storage for
a Mod 20 return address.
I'm not sure about preset addresses in regs 2 through 4. I do know the
Mod 20 did not need to actually set a base register for program
addressability (though you might want to define it in a USING), which
bought back a register, and reduced the pain of losing registers 0
through 7 as general purpose registers a little bit.
Most of my experience with /20s was as HASP RJE terminals, first with
the original STR code and later with the BSC code. The /20-2 was so
fast (sic) that in BSC mode, using multi-leaving, it could not keep the
printer and reader going at anything like full speed because it gassed
the CPU. The /20-5 was much faster and didn't have this problem.
Ken Brick
> As I recall, some of the "registers" actually had hard-coded values;
> they could be used as base registers but little else. I have no idea
> what happened if you tried storing into them. That alone supports your
> "grossly incompatable" assertion.
> It didn't even bother to pretend its linkage conventions were the same as
> s/360. It used something other than the s/360 linkage instructions BAL
> and BALR (BAS and BASR, as I recall).
>
>
that has nothing to do with the s/360 machine architecture. There are
differences between DOS/VSE and MVS as far as the linkage conventions
are concerned.
Looking at typical commercial applications probably 80-90% of the
instructions behaved identically.
In converting programs among the items that caused concern:
1. The pseudo registers. Many of our programs automatically used 0-7.
Obviously in a DOS/VS or MVS environment conversion it wasn't possible
to programatically (sic) use these registers. In addition instructions
that became available, eg EDMK and TRT added further restrictions.
2. It was a 16 bit based machine, no fullwords and indeed no Load
Address instruction, however in a conversion exercise you just changed
LH reg,=Y(address)
to
L reg,=A(address)
Didn't substitute the Load Address in case (address) was an external
reference.
These were probably the major conversion considerations in regard to
differences between S260/20 and S370/125.
Most of our conversion problems arose from the fact that we didn't use
the provided macros eg. PUT GET etc because they caused the assemblies
to take 10->100 times as long.
And I reiterate it was S/360 because IBM said it was.
Ken
Ken Brick
> I rarely called other programs, but when I did, I used the basic
> protocols (R0-R1, R13-R15) with STM/LM, but using halfwords.
>
>
address but I forget how parameters could be passed. I suspect that we
used EXTRN/ENTRY
> The BAL/R did not work, because the registers were only halfword size
> which meant you had no place to store the linkage information.
>
> R3-R6 (as I recall, I don't happen to have my Model 20 card/booklet
> handy) were fixed, R3= x'1000', R4= x'2000' ... I can't remember what
> happened if you stored into them either (I'm not sure if you got a
> "HALT" of the SPEC type or what).
>
>
R1 = x'1000'
R2 =X'2000'
thru to
R7 = x'7000'
> R1-R2 worked exactly like the PoOP says for the other S/360s when it
> came to TRT and EDMK.
>
>
My recollection is that S/360/30 didn't support EDMK and TRT
> I must disagree with the idea that it was "grossly incompatable" for
> several reasons:
>
> a) BAL code could be moved between the two environments with a few
> changes (mainly, the half-word register conventions, and using preset
> registers, which is where I think the R3 for base got started...). And
> we used a BAL/BALR macro so that we didn't have to change our thinking
> all the time.
>
> b) EBCDIC is EBCDIC between the two machines (no funny stuff as happened
> between Burroughs' EBCDIC and IBM's)
>
> c) RPG moved directly from the Model 20 to any other DOS machine (H & F
> specs may have needed one or two changes)
>
> d) Tapes had the same internal formats between the two systems.
>
> e) If you had a large enough model (sufficient memory and some channel
> feature(s)), you could hang 2311 disks on them and then exchange those
> with a S/360 using 2311s
>
My recollection is that the 2311 attached to the Model 20 were uniquely
model 20. There where 2 models, I think model 1 and model 11, The
difference was that the model 1 had 100 cylinders and a total capacity
of 2.7 MB, 100 cyl*10tracks*27000, and the model 2 had 200 cylinders
giving a capacity of 5.4MB. The different models, I'm sure about, the
actual figures are lost in time.
My first "sysprog" type program was writing a program to backup a 200
Cyl. pack on a system that had 2 drives, a Model 1 and a model 2. It
taught me a lot about the use of CCWs and EXCP
Ken
Anne & Lynn Wheeler
> My recollection is that S/360/30 didn't support EDMK and TRT
functional characteristics documents from bitsavers:
http://www.bitsavers.org/pdf/ibm/360/funcChar/
and 360/30 functional characteristics
http://www.bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-30_funcChar.pdf
lists timing instructions for all the 360 instruction ... so I assume
they were supported ... including ..
instruction FORMAT MNEMONIC TIME
Edit SS ED 38+7N1+9N2
Edit and Mark SS EDMK 45+7N1+9N2
Translate SS TR 31+6N
Translate and Test SS TRT 39+6N
N: total number of bytes in field
N1: total number of bytes in 1st operand
N2: total number of bytes in 2nd operand
... snip ..
other posts in this thread:
http://www.garlic.com/~lynn/2007d.html#48 IBM S/360 series operating
systems history
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating
systems history
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating
systems history
Tom Marchant
>kbr...@ibm-main.lst (Ken Brick) writes:
>> My recollection is that S/360/30 didn't support EDMK and TRT
>
>functional characteristics documents from bitsavers:
>http://www.bitsavers.org/pdf/ibm/360/funcChar/
>
>and 360/30 functional characteristics
>http://www.bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-
30_funcChar.pdf
>
>lists timing instructions for all the 360 instruction ... so I assume
>they were supported ... including ..
I think Ken meant to say 360/20, since that's what the sub-thread has
been about. Indeed, he mentions the model 20 elswhere in his post.
--
Tom Marchant
Thompson, Steve
From: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] On
Behalf Of Tom Marchant
Sent: Friday, February 23, 2007 1:08 PM
To: IBM-...@BAMA.UA.EDU
On Fri, 23 Feb 2007 11:03:10 -0700, Anne & Lynn Wheeler wrote:
<snip>
>and 360/30 functional characteristics
>http://www.bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-
30_funcChar.pdf
>
>lists timing instructions for all the 360 instruction ... so I assume
>they were supported ... including ..
I think Ken meant to say 360/20, since that's what the sub-thread has
been about. Indeed, he mentions the model 20 elswhere in his post.
<snip>
Yes, and I found the 360/20 Func Char manual at one of those sites. I
guess my memory is going, because it does not list TRT or EDMK which I
thought I used (particularly EDMK) -- I did a lot of payroll and
accounting in those days.
I remember another system (Galaxy/5) that did not have a macro processor
and also didn't have an "EDMK" type instruction because it was ASCII w/
BCD type arithmetic. I hated floating in "$" in that code. Again,
payroll and accounting.
Later,
Steve Thompson
Patrick O'Keefe
wrote:
>Patrick O'Keefe wrote:
>>...
>> It didn't even bother to pretend its linkage conventions were the same
as
>> s/360. It used something other than the s/360 linkage instructions BAL
>> and BALR (BAS and BASR, as I recall).
>>
>>
>
>that has nothing to do with the s/360 machine architecture. There are
>differences between DOS/VSE and MVS as far as the linkage conventions
>are concerned.
My experience with DOS preceeded DOS/VSE (and DOS/VS), but as I recall,
the linkage conventions for DOS and OS (including pre-MVS) were identical.
The difference was that the main routine was entered using a different
set (or maybe no set) of conventions - no R13 for save area and no R15
for the entry point. (R15 may have been iffy in subroutines, too, but
R13 ad R14 were savearea and return addresses.)
But that wasn't the level I meant. I was refering to the instruction used
for linkage and the values set by those instructions, the registers that
could be used for linkage, etc.; things that explicitly had to do with the
architectural differences between the mod 20 and all other models.
>
>Looking at typical commercial applications probably 80-90% of the
>instructions behaved identically.
And the other 10-20% support my point. If you used the basic set of
s/360 instructions (avoiding floating point, decimal, vector, etc.
instructions) you could run your program on any s/360 model. If you
needed decimal instructions you could run the program on any model that
had the decimal instruction set. To move programs to/from a mod 20 you
had to convert them.
>...
>These were probably the major conversion considerations in regard to
>differences between S260/20 and S370/125.
>...
I'm not sure why you mentioned the s370/125. As far as I know the s360/25
ad the s370/125 were true members of the s/360 and s/370 families ... for
some value of "true". (I never met a 125 so I'm on shaky ground there.)
As with all of the microprogrammed s/360 models the mod 25 was whatever
its microcode said it was, and when you loaded it with an s/360 emulator
it was a true s/360. For all I know it also had a mod 20 emulator, and
if you loaded that, it was a true mod 20. But those were different
architecture.
>...
>And I reiterate it was S/360 because IBM said it was.
>...
Marketing noise. There s/4pi was more of a 360 than the mod 20 was.
They should have called the mod 20 s/180.
Pat O'Keefe
Anne & Lynn Wheeler
> I'm not sure why you mentioned the s370/125. As far as I know the s360/25
> ad the s370/125 were true members of the s/360 and s/370 families ... for
> some value of "true". (I never met a 125 so I'm on shaky ground there.)
> As with all of the microprogrammed s/360 models the mod 25 was whatever
> its microcode said it was, and when you loaded it with an s/360 emulator
> it was a true s/360. For all I know it also had a mod 20 emulator, and
> if you loaded that, it was a true mod 20. But those were different
> architecture.
modulo a m'code bug .... recent cross-over post discussing some 115 &
125 characteristics
http://www.garlic.com/~lynn/2007d.html#71 Cycles per ASM instruction
I had originally done "pageable kernel" support in cp67 ... to help cut
down on fixed real-storage requirements ... this was never shipped in
cp67 product ... but was picked up as part of vm370 kernel. however,
over a period ... the standard fixed vm370 kernel storage requirements
grew ... even having implemented pageable kernel support.
I was asked to look at vm370 on a customer's 256kbyte s370/125 (even tho
vm370 hadn't been announced for 125). One of the things i did was do
about 40kbyte trimming on the fixed vm370 kernel requirements ...
getting it down into the 80kbyte range. I could do this (in virtual
machine) before actually touching a real 125.
When I went to real 125 ... and had problem getting vm370 to actually
boot. The problem was how the "long" instructions (clcl/mvcl)
instructions were originally/implemented on 125. all the 360
instructions would check starting and ending address of operands before
starting instruction execution (i.e. if both starting and ending didn't
check out, it wouldn't even start the instruction execution). That was
changed for "long" instructions ... where only the operand addresses
were checked as they were processed .... ignoring the precheck on ending
operand
address.
The 125 mvcl implementation had a "bug" ... it would precheck ALL
operand ending addresses before starting the instruction (even the long
instructions) ... and if there was a problem not continue. vm370 boot
had some code that would setup mvcl instruction with maximum length
(16mbytes) for the "to" operand and zero length for "from" ...
effectively clear all of storage and terminate with the address of end
of real storage. The 125 mcode "bug" resulted in not even starting the
instruction ... so vm370 boot thot there was effectively no real storage
and aborted.
misc. past posts mentioning the 125 long instruction mcode problem
http://www.garlic.com/~lynn/2000g.html#8 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001f.html#69 Test and Set (TS) vs Compare
and Swap (CS)
http://www.garlic.com/~lynn/2002i.html#9 More about SUN and CICS
http://www.garlic.com/~lynn/2003j.html#27 A Dark Day
http://www.garlic.com/~lynn/2006.html#12 Zeroing core
http://www.garlic.com/~lynn/2006n.html#46 Why is z series so CPU poor?
http://www.garlic.com/~lynn/2006q.html#49 Was FORTRAN buggy?
Shmuel Metz , Seymour J.
at 03:02 PM, "Patrick O'Keefe" <patrick...@WAMU.NET> said:
>I'm not sure why you mentioned the s370/125. As far as I know the
>s360/25 ad the s370/125 were true members of the s/360 and s/370
>families ...
The 360/25 was a true S/360. The only S/370 model that deviated was
the 370/195.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------
Steven Arnett
>My experience with DOS preceeded DOS/VSE (and DOS/VS), but as I recall,
>the linkage conventions for DOS and OS (including pre-MVS) were identical.
>The difference was that the main routine was entered using a different
>set (or maybe no set) of conventions - no R13 for save area and no R15
>for the entry point. (R15 may have been iffy in subroutines, too, but
>R13 ad R14 were savearea and return addresses.)
>
>
Yea, it has taken me years to replace:
NAME BALR,R12,R0
BCTR R12,R0
BCTR R12,R0
USING NAME,R12
NAME STM R14,R12,12(R13)
LR R12,R15
USING NAME,R12
etc....
It is amazing how just just eight or so years on DOS could do that to a
person.
Randy Hudson
Anne & Lynn Wheeler <ly...@garlic.com> wrote:
> kbr...@ibm-main.lst (Ken Brick) writes:
>> My recollection is that S/360/30 didn't support EDMK and TRT
^^^^^^
I think that was a typo for 360/20, as the thread up to that point was
referring to the 360/20 and its use of hard-coded values in the low-numbered
registers. Certainly if register 1 was hard-coded to always return X'1000',
and register 2 to always return X'2000', then the EDMK and TRT will not be
able to function as they are specified in PrincOps. My green card has a
lettered footnote that those instructions were not available on the 360/20.
> http://www.bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-30_funcChar.pdf
> lists timing instructions for all the 360 instruction ... so I assume
> they were supported
http://www.bitsavers.org/pdf/ibm/360/funcChar/A26-5847-3_360-20_funChar_Apr67.pdf
does not include the EDMK nor TRT instructions; the table on page 18
includes the ED and TR instructions but not their register-using cousins.
--
Randy Hudson
Robert A. Rosenberg
Re: IBM S/360 series operating systems history:
>Second, you list "releases" of OS/360 that have nothing to do with
>OS/360: "OS/360 BOS-8k", "OS/360 BPS", "OS/360 TOS", "OS/360 BOS-16k"
>and "OS/360 DOS-16k". BPS/360 was not much more than a loader, BOS/360
>was a separate system and TOS/360 was the same code base as DOS/360
>with a tape loader instead of a disk loader. If you can get the dates
>I'd advise listing the releases of DOS/360 in the VSE timeline.
DOS/360 started with the name BOS-16k and was renamed as DOS at some
release level. The same thing happened with BPS-16k which got renamed
to TOS at the same release level. The BOS-8k and BPS-8k were renamed
to just BOS and BPS at that release level and then dropped totally.
Robert A. Rosenberg
series operating systems history:
>TOS was a piece of work! Every time you linkedited a program (all executable
>programs in DOS/TOS in those days lived in SYSRES) it copied the SYSRES from
>tape to tape, kind of like a "good old days" update of the customer master
>file.
And the first thing you then did was run a copy or two of the new
SYSRES Tape. I seem to remember that the life time of the media that
was used to hold the SYSRES was about a month or so (it wore out from
all the constant back-and-forth movement). You had to trace the
amount of usage it got so you could replace it with one of the copies
before it totally wore out.
Robert A. Rosenberg
series operating systems history:
>DOS/VS R27 1972-73 timeframe - check when the small 370'e (135 & 145)
>become available
That was DOS/370 R27. It was NOT a VS system (that was R28 I think).
This ran on 370 135/145 BEFORE the release of the VS Microcode.
Basically it was DOS/360 with the new 370 instructions and the 370
CPU Support.
Note: If R27 was DOS/VS than it was DOS R26 which was DOS/370 and the
last real memory operating system. Which ever release was DOS/370, it
was a single release between the last DOS/360 and the first DOS/VS.
Charles Mills
of DASD support and with a tape SYSRES.
BPS was not really an operating system, as I recall. It was a bunch of I/O
routines that could be linked with a user program such that the application
programmer did not have to write "to the metal." It was not (AFAIR) an
operating system in the sense of providing program-to-program transition or
resource arbitration. It was not programming compatible with D/TOS.
And I *think* that DOS was always DOS. I *think* that BOS was something
else.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@ibm-main.lst
Of Robert A. Rosenberg
Sent: Friday, March 02, 2007 11:36 PM
To: IBM-...@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history
DOS/360 started with the name BOS-16k and was renamed as DOS at some
release level. The same thing happened with BPS-16k which got renamed
to TOS at the same release level. The BOS-8k and BPS-8k were renamed
to just BOS and BPS at that release level and then dropped totally.
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 11:35 PM, "Robert A. Rosenberg" <hal...@PANIX.COM> said:
>DOS/360 started with the name BOS-16k and was renamed as DOS at some
>release level.
My recollection is that DOS/360 was intended as an interim system
until BOS-16K was stable, but that "interim" worked out the same way
as "short range" at CODASYL.
>The same thing happened with BPS-16k which got renamed to TOS at
>the same release level.
Do you have any documentation for that? It certainly doesn't jibe with
what I know about BPS and TOS.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
----------------------------------------------------------------------