Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/09/2007
   at 09:25 AM, "Mark H. Young" <[EMAIL PROTECTED]> said:

>Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor
>with a DAT box?

As shipped, OS/VS1 and OS/VS2 R1 (SVS) ran only on a S/370 with a DAT
box[1]. I can't address the question of IBM using a modified S/360 or
a 2067 for development work.

>Or did MVT or MFT run native on those systems with a DAT box?

A S/370 with a DAT box could still run the old S/370 software native.
You needed a release of OS/360 that supported the S/370, but that was
mostly because of MCH. Vanilla OS/360 was strictly real mode.

[1] Slightly misleading, as the DAT support for the 3145 was just
a new floppy disk.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Bob Halpern wrote:

Tss was implemented at Computer Scieces Corp


ref:
http://www.garlic.com/~lynn/2007f.html#7 IBM S/360 series operating systems 
history

at one time there was this joke about there possibly being 1200 people in mohansic 
working on tss/360 and total of 12 people at the cambridge science center working 
on cp67/cms (and aggregate productivity of the science center exceeding the 
aggregate productivity of the 1200 people in mohansic).


tss/360 did have a few loyal customers that hung on ... like GM research ... 
and after
tss/360 product was canceled there was enuf interest for keeping a small group in place 
supporting some existing customers, including doing a conversion to 370.


tss/370 saw some return to life at AT&T where there was a UNIX kernel built on
top of a stripped down tss/370 kernel (only available for internal AT&T)

at some point, IBM Germany looked at putting out a similar tss/370 mainframe 
unix product
and put in place an official (new) product group ... bringing some number of the
tss/370 people over from the states ... however this never made it out the door.

There were also number of vm-based unix projects under way in the early to mid 
80s which
also never made it out the door. 


There was big started to do BSD offering on vm370 ... but part way thru, it got
retargeted to the PC/RT and released as a product for the PC/RT called AOS (not 
to
be confused with the AOS SVC prototype).

What finally made it out the doors was (unix-like) UCLA's "LOCUS" offered as
AIX/370 (under VM) and AIX/PS2 ... providing single-system-image type operation,
not only across mainframe systems ... but also between mainframes and PS2s
(sort of what SAA from the period claimed to aspire to).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Bob Halpern]

Tss was implemented at Computer Scieces Corp

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Anne & Lynn Wheeler
Sent: Friday, March 09, 2007 11:17 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history


Rick Fochtman wrote:
> MVT and MFT never knew anything about DAT boxen. IIRC, the only 360 
> with
> a DAT box was the 67, mainly for running CP67/CMS, the predecessor to 
> VM. The early 370 machines, 155 and 165 had no DAT box but they could be 
> upgraded to 155-II and 165-II by adding a DAT box, along with some other 
> features.

recent post in this thread: http://www.garlic.com/~lynn/2007f.html#6 IBM
S/360 series operating systems history

DAT Hardware for 165-II was especially big hit ... there was bunch of stuff
in 370 virtual memory architecture (i.e. "redbook" was cms script file,
depending on the options set, it either produced the full architecture
redbook or the subset 370 principle of operations). at one point there was
an escalation meeting where the 165 engineers proposed dropping a bunch of
stuff from the DAT architecture on the grounds that they could get virtual
memory hardware out six months earlier if they didn't have to do all the
extra stuff. It was eventually agreed to ... and then all the other products
that already had full 370 virtual memory architecture implemented ... had to
go back and remove all the stuff dropped to help 165 improve their delivery
schedule.

360/67 was originally for something called tss/360 ... which never really
got out of development ... there were all these release 0.xx something in
customer shops ... but the performance was really horrible (among other
issues). cp67/cms started as bootlegged project at the cambridge science
center http://www.garlic.com/~lynn/subtopic.html#545tech

and eventually found customer installation at a lot of places that had
orderd 360/67 for tss/360. another project that saw some amount of
installations was MTS (michigan terminal system) done at UofM ... that made
use of the 360/67 dat box.

The morph from cp67 to vm370 had barely made it into customer installations
and POK discovered that it had enormous problem with MVS/XA development
schedule. POK was able to convince corporate to kill off the vm370 product
and have all of the vm370/cms development group transferred to POK to help
with MVS/XA development. At the last minute, Endicott managed to salvage a
little of the vm370 product development mission and acquire a small part of
the development staff ... in order to keep the product going. 

for a lot more on the early 360/67 period, including science center
implementing early virtual machine cp40 & cms on a custom modified 360/40
(with virtual memory hardware added) before 360/67 machines became available
... see Melinda's history http://www.princeton.edu/~melinda

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the
archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Rick Fochtman wrote:
MVT and MFT never knew anything about DAT boxen. IIRC, the only 360 with 
a DAT box was the 67, mainly for running CP67/CMS, the predecessor to 
VM. The early 370 machines, 155 and 165 had no DAT box but they could be 
upgraded to 155-II and 165-II by adding a DAT box, along with some other 
features.


recent post in this thread:
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems 
history

DAT Hardware for 165-II was especially big hit ... there was bunch of stuff
in 370 virtual memory architecture (i.e. "redbook" was cms script file,
depending on the options set, it either produced the full architecture redbook
or the subset 370 principle of operations). at one point there was an
escalation meeting where the 165 engineers proposed dropping a bunch of
stuff from the DAT architecture on the grounds that they could get
virtual memory hardware out six months earlier if they didn't have to
do all the extra stuff. It was eventually agreed to ... and then all the
other products that already had full 370 virtual memory architecture 
implemented ...
had to go back and remove all the stuff dropped to help 165 improve
their delivery schedule.

360/67 was originally for something called tss/360 ... which never really got
out of development ... there were all these release 0.xx something in customer
shops ... but the performance was really horrible (among other issues). cp67/cms
started as bootlegged project at the cambridge science center
http://www.garlic.com/~lynn/subtopic.html#545tech

and eventually found customer installation at a lot of places that had orderd
360/67 for tss/360. another project that saw some amount of installations
was MTS (michigan terminal system) done at UofM ... that made use of the
360/67 dat box.

The morph from cp67 to vm370 had barely made it into customer installations and
POK discovered that it had enormous problem with MVS/XA development schedule.
POK was able to convince corporate to kill off the vm370 product and have all
of the vm370/cms development group transferred to POK to help with MVS/XA
development. At the last minute, Endicott managed to salvage a little of the
vm370 product development mission and acquire a small part of the development
staff ... in order to keep the product going. 


for a lot more on the early 360/67 period, including science center
implementing early virtual machine cp40 & cms on a custom modified
360/40 (with virtual memory hardware added) before 360/67 machines
became available ... see Melinda's history
http://www.princeton.edu/~melinda

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Rick Fochtman]

---
Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor with 
a DAT box? Or did MVT or MFT run native on those systems with a DAT box?


MVT and MFT never knew anything about DAT boxen. IIRC, the only 360 with 
a DAT box was the 67, mainly for running CP67/CMS, the predecessor to 
VM. The early 370 machines, 155 and 165 had no DAT box but they could be 
upgraded to 155-II and 165-II by adding a DAT box, along with some other 
features.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Rick Fochtman]

In a message dated 3/8/2007 2:05:22 P.M. Central Standard Time, 
_patrick.okeefe @  WAMU.NET_ (mailto:[EMAIL PROTECTED])  writes:
 


I remember 3 different BPSloaders - 3-card, 7-card, and 12-card  versions.
   


There very well could have been a 6-card loader, too.

I may have had a brain check.  I thought it was 6, but it must have  been 7.  
3 seems like too few.  And it was all too many decades  ago.
 


--
I remember seeing a loader that consisted of only two cards, once. The 
second card was a channel program that read length/address information 
into a third CCW, ran it and TIC'd back to the beginning again.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Mark H. Young wrote:

Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor with a
DAT box?  Or did MVT or MFT run native on those systems with a DAT box?


SVS prototype started out as adding virtual tables and CCWTRANS (from cp67) cut
into the side of MVT ... with otherwise minimumal changes to how MVT otherwise
operated (i.e. minimum amount of work and effort to get MVT running with
virtual memory turned on). So nearly all EXCP channel programs had to get
translated via CCWTRANS ... very much as if MVT was running in virtual machine.
Lots of MVT kernel was fixed so that kernel code didn't have to worry about
page faults. Application page faults were handled at very low level with
least amount of disturbance to the application ... again almost as if MVT
was running in a virtual machine. Recent post mentioning Ludlow working
on SVS prototyping ... somewhat hacking various pieces from CP67 into
MVT kernel.
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems 
history

so you could sort of say that MVT ran native with a DAT box with a bunch of 
stuff
from CP67 hacked into the MVT kernel ... but they changed its name to SVS.

Something similar but different had been done earlier to MVT by some customers 
... but running in virtual machine under CP67 called "hand shaking" ... CP67 would

present a page fault interrupt to MVT under certain conditions
(i.e. virtual problem state, non-key-zero) ... which allowed MVT to perform
a task-switch. Later when missing page had been fetch ... MVT would be
presented a new kind of interrupt as indication that missing page was
now in real storage.

Later the VM370 and VS1 would have similar modifications as part of VS1 
"handshaking"
support. In this case, something like a 4mbyte virtual machine would be defined
for VS1. VS1 would then build a 4mbyte virtual address space table ... where 
there
was a one-for-one mapping between each VS1 virtual page and the virtual machine
page. In effect, VS1 would no longer have any paging responsibility ... having
turned it all over to the VM370 kernel. VM370 would present page interrupt
to VS1,  allowing VS1 to perform task switch ... while waiting for vm370
to perform the page operation. when the page operation was complete, vm370
would present a psuedo page i/o complete interrupt to vs1. For a lot of
workloads ... this (and misc. other stuff) allowed VS1 to run faster in a 
vm370 virtual machine than it did running directly on the hardware w/o vm370

... at least on processors with the ECPS VM microcode assists (started with
370 138s & 148s) ... old post discussing ECPS
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

There actually had been an earlier modification to MVT release 13 done by
Boeing Huntsville running on 360/67 SMP ... (I believe partitioned running
as two uni-processors). MVT had virtual address space the same size as
real storage (slightly analogous to the VS1 configuration) ... and did no 
paging and/or page fault operations. The issue was to handle storage fragmentation.

MVT had horrendous problem with storage fragmentation ... especially with
long running applications. Boeing Huntsville machines were primarily being
used for long-running 2250 display/design applications ... would would
experience large amounts of storage fragmentation. The use of virtual
address space ... wasn't to make it look like there was more memory
than really available ... but to re-arrange storage locations to appear
contiguous. recent posting mentioning Boeing Huntsville hack to MVT-13.
http://www.garlic.com/~lynn/2007b.html#45 Is anyone still running

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Mark H. Young]

On Wed, 7 Mar 2007 17:33:04 -0500, Shmuel (Seymour J.) Metz 
<[EMAIL PROTECTED]> wrote:

>>SVS was MVT with Virtual Storage (a 16Meg Machine).
>
>>VS1 was similarly MFT with VS.
>
> Shmuel (Seymour J.) Metz, SysProg and JOAT
> Atid/2

Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor with a
DAT box?  Or did MVT or MFT run native on those systems with a DAT box?


THANX,
Mark H. Young
FFX County Gov't VA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Patrick O'Keefe wrote:

I remember 3 different BPSloaders - 3-card, 7-card, and 12-card versions.
There very well could have been a 6-card loader, too.  I have no idea what
the differences were but I bet the 3-card loader didn't uspport REP cards. 


IPL does a "02" read operation of 24 bytes at location zero

followed by TIC CCW to location "8" (assuming it is a CCW) and when
the I/O operation completes does a LPSW on location zero.

for three card loader, you would have

first card read by IPL button with 24 bytes containing

8 byte PSW
8 byte READ CCW for 80 bytes of 2nd card, command chained to
8 byte READ CCW for 80 bytes of 3rd card

with TIC operation to +8, the first read CCW.

you now have a 160byte program+data and the PSW is setup to start with
the first instruction just read. this small program would loop reading
(following) cards until it got to last card and then branch to the
start of the program just read.

all of this came out of BPS. In fact, the CP67 kernel process was to
collect all the CP67 kernel TXT files and slap BPS loader on the
front. The BPS loader resolves all the ESD symbols and when finished
branchs to the address/symbol in the LDT card ... which pointed to the
"SAVECP" entry point. SAVECP would take the freshly loaded
core/storage image and write it to disk.

The CCWs were compatible between cards and tape ... so you could have
actual physical cards ... and/or have placed card image on tape and
performed the IPL operation on tape drive (instead of card reader).

in cp67 and vm370, the 3card loader was used to slap on the front of
single module "stand alone" utilities (like DDR, physical tape<->disk
copy routine).

3card loader could handle card deck containing single assemble, TXT
file.

BPS loader could handle card deck with multiple TXT decks ... needing
to resolve ESDs adcons between TXT decks

a couple old posts mentioning 3card loader:
http://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would 
you ask?
http://www.garlic.com/~lynn/2001c.html#87 "Bootstrap"

CP67 didn't originally ship with source for the BPS loader (although
it shipped with source for everything else). One of the modifications
I made at the university involved changes to support "paging" portions
of the (fixed) cp67 kernel ... the process I used created a quite a
few new ESD entry symbols. Basic BPS loader provided with CP67 only
supported 256 ESD symbols ... which I managed to exceed. It was real
pain trying to deal with the number of ESD limitation until i found a
copy of the BPS loader source that i could fix/modify.

The simplest way then to create a "new" BPS loader was to assemble the
source and slap a 3card loader on the front of the BPS TXT file.

Even easier was to include 3 assembler "PUNCH" statements in the source 
of the stand-alone utility (including the BPS assembler source) 
that punched hex image for the 3card loader (in front of the TXT deck 
being generated).


this has discussion of 3card loader in conjunction with DDRXA
http://www.cbttape.org/~jjaeger/cdrom.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Chris Langford]

VM has always shipped with '3CARD LOADER S2'
With the advent of XA the number of cards increased to 5.

(IBM Mainframe Discussion List) wrote:
 
 
In a message dated 3/8/2007 2:05:22 P.M. Central Standard Time, 
_patrick.okeefe @  WAMU.NET_ (mailto:[EMAIL PROTECTED])  writes:
  

I remember 3 different BPSloaders - 3-card, 7-card, and 12-card  versions.


There very well could have been a 6-card loader, too.
 
I may have had a brain check.  I thought it was 6, but it must have  been 7.  
3 seems like too few.  And it was all too many decades  ago.
 
Bill  Fairchild

Plainfield, IL

"Criticism and dissent are the indispensable  antidote to major delusions." 
[Alan Barth, 1951; The Loyalty of Free  Men]



** AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
..
For: [EMAIL PROTECTED]



  


--
Chris Langford,
Cestrian Software:
Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. 


z/FM  - A toolbox for VM & MVS at http://zfm.cestrian.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[(IBM Mainframe Discussion List)]

 
 
In a message dated 3/8/2007 2:05:22 P.M. Central Standard Time, 
_patrick.okeefe @  WAMU.NET_ (mailto:[EMAIL PROTECTED])  writes:
>I remember 3 different BPSloaders - 3-card, 7-card, and 12-card  versions.
There very well could have been a 6-card loader, too.
 
I may have had a brain check.  I thought it was 6, but it must have  been 7.  
3 seems like too few.  And it was all too many decades  ago.
 
Bill  Fairchild
Plainfield, IL

"Criticism and dissent are the indispensable  antidote to major delusions." 
[Alan Barth, 1951; The Loyalty of Free  Men]


** AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel (Seymour J.) Metz]

In <[EMAIL PROTECTED]>, on 03/03/2007
   at 12:31 AM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> said:

>SVS was MVT with Virtual Storage (a 16Meg Machine).

To some extent, but there were some significant changes to exploit
paging, e.g., SVS was TACTless.

>so there was a limit on the total combined size of 
>the running programs).

You're overlooking TSO.

>VS1 was similarly MFT with VS. 

With changes more significant than those from MVT to SVS, e.g., JES,
RES.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/01/2007
   at 09:09 AM, "Shmuel Metz (Seymour J.)"
<[EMAIL PROTECTED]> said:

>My recollection is that the original virtual storage announcement for
>S/370 already used the term MVS for OS/VS2 R2.

C 'MVS' 'AOS'
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/02/2007
   at 11:35 PM, "Robert A. Rosenberg" <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Patrick O'Keefe]

On Sat, 3 Mar 2007 07:55:03 -0500, Charles Mills <[EMAIL PROTECTED]> wrote:

>...
>And I *think* that DOS was always DOS. I *think* that BOS was something
>else.
>...

I know/knew nothing of BOS internals, but the JCL looked nothing like DOS
JCL.  (I think a JCL statement started with a single slash.)  If the 
original BOS became DOS, then something else took the name BOS.  DOS and 
BOS coexisted for a while before BOS died.  And DOS still have an 8K
Supervisor version for a couple years after it became DOS (if it was ever
anything else).

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Anne & Lynn Wheeler wrote:
the consolidation of some of the HONE vm370 datacenters provided 
opportunity for development of vm370 "single-system-image" support with 
front-end load-balancing and availability infrastructure directing 
branch office logon to specific processor. The mechanism utilized a 
special CKD sequence that performed a logical "compare&swap" channel 
program to correctly syncronize logins across all processors in the 
complex. The "compare&swap" channel program had originally been 
developed by the people at the Uithorn HONE system in Europe ... for 
coordinating logins across all processors in loosely-coupled complex. I 
believe that JES2 multi-access spool then started using a similar 
logical "compare&swap" channel program for its loosely-coupled 
operation. This was to avoid the heavy penalty and overhead of doing 
full device reserve/release sequence.


Later the US hone complex was replicated first in Dallas and then a 3rd 
in Boulder (and could provide geographic availability to US branch offices 
logins across all three datacenters).


to slightly wander back to the original thread ... the US HONE VM/370 complex
in the late 70s was possibly the largest single system image operation in
the world.

there were some large ACP/TPF single system image clusters deployed ... but 
since
ACP/TPF didn't symmetrical multiprocessor support until much later ... HONE
could actually do larger number of processors. Because large portion of HONE
applications were APL based, HONE was an extremely computational intensive 
operation.
Multiple "AP" multiprocessors (with only one of the processors in the 
configuration having
I/O channels) could be configured in loosely-coupled operation. You could get
eight "AP" multiprocessors in loosely-coupled configuration (16 processors 
total)
with 3830 four-channel switch ... and two-way 3330 string-switch (i.e. each 3330
string connected to two different 3830 controllers).

For additional topic drift, a large body of internal software enhancements never
made it into the product. In the early 80s there was a study done of the 
WATERLOO/SHARE
tape and the collection of internal corporate software enhancements. The amount 
of
source code on the WATERLOO/SHARE tape and the internal corporate software 
enhancements
were comparable in size and both estimated to be larger than the amount of 
source
code in the base vm/cms product.

Part of the problem (as I've previously posted) was that in the mid-70s, POK 
had convinced
the corporation to kill the vm370 product and move all the people to POK to 
support
MVS/XA development ... as part of the only way to get MVS/XA product out the 
door.
Endicott managed to get something of a reprieve and save a fraction of the 
people
from being re-assigned to supporting MVS/XA development. Somewhat as a result, 
there was
a significant bottleneck created getting enhancements for vm/cms out-the-door 
...
and a extremely large body of software enhancements accumulated for the product 

both at the large number of internal corporate datacenters and also from 
customer
datacenters.

For completely other drift ... my wife had served in the g'burg JES development 
group
before being con'ed into going to POK to be in charge of loosely-coupled 
architecture.
While in POK, she originated peer-coupled shared data architecture ... lots of 
past
posts with references
http://www.garlic.com/~lynn/subtopic.html#shareddata

... for various reasons ... except for IMS hot-standby ... saw very little 
uptake until sysplex
(and large reason she didn't stay in the position for long).

However, for further drift ... a little walk down dbms memory lane from this 
thread
from comp.database.theory
http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#36 Quote from comp.object
http://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object

which, in turn wandered into referencing this wiki page about IMS
http://en.wikipedia.org/wiki/Information_Management_System

mentioning Vern Watts as the granddad of IMS still being around. Vern was
one of the people my wife work with regarding IMS hot-standby.

however, this other old email reference ...
http://www.garlic.com/~lynn/2007.html#email801016

mentioning Jim passing off some number of things to me as part of his
leaving for Tandem ... includes mention of joint lunch with IMS
developers and telling them to call me after Jim's departure. I can't
remember for sure if Vern was at that lunch meeting or not. I have
some recollection of a German (Hans something?) ... who later left 
to work for Amdahl.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Charles Mills]

Are you sure? I don't believe BPS became TOS. I think TOS was DOS stripped
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:[EMAIL PROTECTED] On Behalf
Of Robert A. Rosenberg
Sent: Friday, March 02, 2007 11:36 PM
To: IBM-MAIN@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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Robert A. Rosenberg]

At 18:53 -0500 on 02/28/2007, (IBM Mainframe Discussion List) wrote 
about Re: IBM S/360 series operating systems history:



MVT was first virtualized in early 1974 as OS/VS2 Release 1, better known  as
SVS (Single Virtual Storage).  A fuller version, OS/VS2 Release  2, was
available a year or so later, and it was quickly renamed MVS  for 
Multiple Virtual Storages.  MFT evolved into VS1.


SVS was MVT with Virtual Storage (a 16Meg Machine). MVS split the 
16Meg into 3 Areas - At the bottom and top of the memory space was 
the Operating System and memory shared between the running Address 
Spaces/Programs (the same mapping as with MVT and SVS). The big 
difference from SVS was the 3rd area where the Programs ran - In MVS, 
each program had its own copy of this address range so that it had 
access to all the memory that was not reserved for the Operating 
System (in MVT, SVS, and MFT/VS1 this area was shared between all the 
running programs so there was a limit on the total combined size of 
the running programs).


VS1 was similarly MFT with VS. The Program Area was divided into 
Partitions (which were used to hold the running programs). When you 
wanted to run a program, you scheduled it to run in a Partition that 
was large enough to provide enough memory but not one that was much 
larger (if possible) since once in use, you could find that all of 
the large partitions were running small programs. Creating a Large 
Partition by combining the memory from multiple small partitions, 
required that they were adjacent.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Robert A. Rosenberg]

At 15:08 -0800 on 02/20/2007, Charles Mills wrote about Re: IBM S/360 
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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Robert A. Rosenberg]

At 13:05 -0500 on 02/19/2007, Shmuel Metz (Seymour J.) wrote about 
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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Robert A. Rosenberg]

At 20:55 -0500 on 02/20/2007, Thompson, Steve wrote about Re: IBM 
S/360 series operating systems history:



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).


IMPOSSIBLE. TOS did not have ANY DASD support (it was a TAPE ONLY 
system with no DASD DTFs or xxMOD macros [although you could in 
theory add them by copying them from a DOS system so you could 
assemble your program] nor any support to access DASD from user 
programs). If you wanted DASD support, you needed to switch to DOS 
which had the DASD IO support, Macros, and had a DASD SYSRES.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Robert A. Rosenberg]

At 18:22 +1100 on 02/19/2007, Ken Brick wrote about Re: IBM S/360 
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.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Blaicher, Chris]

All right.  Damn extra keystroke.  Should have checked that. :(

Nothing like embarrassing yourself to the world.

Christopher Y. Blaicher
BMC Software, Inc.
Austin Development Labs
(512) 340-6154
The comments made are my personal opinions. BMC Software, Inc. makes no
representations or promises regarding the reliability, completeness, or
accuracy of the information provided in this discussion; all readers
agree not to rely on this information or take any action against BMC
Software in response to this information.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark L. Wheeler
Sent: Friday, March 02, 2007 7:46 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FBA rant was Re: IBM S/360 series operating systems history

IBM Mainframe Discussion List  wrote on 03/02/2007
04:35:23 PM:

> The limit for CKD volumes is a little more than 54GB.  I come up with
a
> number closer to 500GB.  Past that and IBM will need to go to logical
> volumes on a physical volume.  The reason is the CCHHR count field.
>
> Max CC is , which give 65536 cylinders (don't forget cylinder 0)
> Max HH is E, which gives 15 tracks per cylinder
>
> That gives:
> 65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *
> 56664
> 983040 tracks * 56664 = 557,053,378,560

Hmmm. My calculator says 983040*56664=55,702,978,560.

Mark Wheeler, 3M Company

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Clark Morris]

On 2 Mar 2007 14:42:07 -0800, [EMAIL PROTECTED] (Blaicher,
Chris) wrote:

>The limit for CKD volumes is a little more than 54GB.  I come up with a
>number closer to 500GB.  Past that and IBM will need to go to logical
>volumes on a physical volume.  The reason is the CCHHR count field.
>
>Max CC is , which give 65536 cylinders (don't forget cylinder 0)
>Max HH is E, which gives 15 tracks per cylinder
>
>That gives: 
>65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *
>56664
>983040 tracks * 56664 = 557,053,378,560
>
>My question is who is going to want that much data on a single volume?
>In 10 years someone may want that much.  I'll be glad to not have to
>wait for that volume restore as I hope to be long retired.

I have seen ads for 500 gigabyte disks for PCs and PCs with 500
gigabyte disks.  At the rate databases are growing and the product
files have more and more pictures for Internet sales, I am sure
someone will find uses and ways to back them up.

In response to another posting, I realize that you could change some
of the limits so that track size and cylinder size are larger but if
pain is going to be caused, why perpetrate a file organization that is
optimal only for sequential files?  We are awkwardly shoe horning FBA
access methods - VSAM, PDSE, and the various Unix file systems are all
FBA oriented and fit awkwardly on CKD devices (using 4K or 8K blocks
you utilize only 48k out the 56K theoretical maximum).  There is
additional path length in both the mainframe and the controller to
accommodate CKD.  The basic changes that would be needed in order to
"functionally stabilize" CKD are finding a new spool arrangement
(snitch one from Unix), enhancing ESDS so that it can be on tape (RCA
did this with the Spectra 70) and have GDG like capability, allowing
PDSE to be in the IPL link and LPA lists, coming up with new VTOC
capabilities, a new IPL text mechanism and an upgraded way of handling
SYS1.NUCLEUS.  This could be the excuse to expand the data set name
length and member name length as well as get rid of a lot of baggage.
In the restructuring they should look at what the other IBM operating
systems do and snitch any good ideas.
>
>Christopher Y. Blaicher
>BMC Software, Inc.
>Austin Development Labs
>(512) 340-6154
>The comments made are my personal opinions. BMC Software, Inc. makes no
>representations or promises regarding the reliability, completeness, or
>accuracy of the information provided in this discussion; all readers
>agree not to rely on this information or take any action against BMC
>Software in response to this information.
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
>Behalf Of Edward Jaffe
>Sent: Friday, March 02, 2007 4:13 PM
>To: IBM-MAIN@BAMA.UA.EDU
>Subject: Re: FBA rant was Re: IBM S/360 series operating systems history
>
>
>I agree with you Clark re: the short-sightedness of not supporting FBA 
>in MVS. Because of that dumb decision, z/OS is the only mainframe 
>operating system left in the 21st century that can't handle SCSI. :-( 
>That situation should be rectified!
>
>But, why do you say we need FBA in order to support volumes greater than
>
>54GB? Why can't ECKD be extended to support larger volumes?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Mark L. Wheeler]

IBM Mainframe Discussion List  wrote on 03/02/2007
04:35:23 PM:

> The limit for CKD volumes is a little more than 54GB.  I come up with a
> number closer to 500GB.  Past that and IBM will need to go to logical
> volumes on a physical volume.  The reason is the CCHHR count field.
>
> Max CC is , which give 65536 cylinders (don't forget cylinder 0)
> Max HH is E, which gives 15 tracks per cylinder
>
> That gives:
> 65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *
> 56664
> 983040 tracks * 56664 = 557,053,378,560

Hmmm. My calculator says 983040*56664=55,702,978,560.

Mark Wheeler, 3M Company

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Tom Marchant]

On Fri, 2 Mar 2007 16:35:23 -0600, Blaicher, Chris <[EMAIL PROTECTED]>
wrote:

>The limit for CKD volumes is a little more than 54GB.  I come up with a
>number closer to 500GB.  Past that and IBM will need to go to logical
>volumes on a physical volume.  The reason is the CCHHR count field.
>
>Max CC is , which give 65536 cylinders (don't forget cylinder 0)
>Max HH is E, which gives 15 tracks per cylinder

Only if 3390 geometry us maintained.

>
>That gives:
>65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *
>56664
>983040 tracks * 56664 = 557,053,378,560
>

There's where your arithmetic went wrong.
983,040 * 56,664 = 55,702,978,560
983,949 * 566,664 = 557,053,378,560

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Edward Jaffe]

Blaicher, Chris wrote:

The limit for CKD volumes is a little more than 54GB.  I come up with a
number closer to 500GB.  Past that and IBM will need to go to logical
volumes on a physical volume.  The reason is the CCHHR count field.

Max CC is , which give 65536 cylinders (don't forget cylinder 0)
Max HH is E, which gives 15 tracks per cylinder

That gives: 
65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *

56664
983040 tracks * 56664 = 557,053,378,560
  


Max CC I agree is . That's obvious. But, max HH = E? My hex 
calculator disagrees. This is not a CKD restriction. It is a 
self-imposed restriction by those not wishing to change the trk/cyl 
constant. I guess you're one of them.


Remember, 3350s had 30 trk/cyl. Since there are no SLEDs any more, 
there's no reason we cant have HH = 7FFF or even HH =  except for 
the 3390 geometry compatibility issue. And, nothing says we can't make 
bytes/track larger either.


Even if 15 trk/cyl must be retained, then why not steal the four 
"wasted" bits from the HH and use it to extend CC?


It seems to me that there are several practical alternatives...

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Richard Peurifoy]

Blaicher, Chris wrote:

The limit for CKD volumes is a little more than 54GB.  I come up with a
number closer to 500GB.  Past that and IBM will need to go to logical
volumes on a physical volume.  The reason is the CCHHR count field.

Max CC is , which give 65536 cylinders (don't forget cylinder 0)
Max HH is E, which gives 15 tracks per cylinder

That gives: 
65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *

56664
983040 tracks * 56664 = 557,053,378,560



Actually it is much larger. You can have more than 15 tracks per
cylinder. I think 3330's had 30. HH can also be , and R can
be FF. So the max records per volume is   FF or 16**10.

If you ignore data chaining, the max record size is  (CCW
length field). This make the max size 16**14 bytes or approx.
7 * 10**16 if I did my conversion correctly.

There is also the BB part of the address which is currently
unused (as far as I know).

Any such change also requires a lot of software changes by
IBM, ISVs, and customers.

Other than increasing the number of cylinders, there has not
been a change in MVS disk geometry in quit some time.
I remember having problems going from 2314 to 3330 to 3350.
We found code that hard coded the values for track capacity
and had to be changed. Hopefully most of that kind of code
is gone know, but who knows.

This is probably easier than FBA at this point, but I don't
really know. Any choice will cause some problems, but something
will have to be done eventually.

--
Richard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Blaicher, Chris]

The limit for CKD volumes is a little more than 54GB.  I come up with a
number closer to 500GB.  Past that and IBM will need to go to logical
volumes on a physical volume.  The reason is the CCHHR count field.

Max CC is , which give 65536 cylinders (don't forget cylinder 0)
Max HH is E, which gives 15 tracks per cylinder

That gives: 
65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks *
56664
983040 tracks * 56664 = 557,053,378,560

My question is who is going to want that much data on a single volume?
In 10 years someone may want that much.  I'll be glad to not have to
wait for that volume restore as I hope to be long retired.

Christopher Y. Blaicher
BMC Software, Inc.
Austin Development Labs
(512) 340-6154
The comments made are my personal opinions. BMC Software, Inc. makes no
representations or promises regarding the reliability, completeness, or
accuracy of the information provided in this discussion; all readers
agree not to rely on this information or take any action against BMC
Software in response to this information.

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward Jaffe
Sent: Friday, March 02, 2007 4:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: FBA rant was Re: IBM S/360 series operating systems history


I agree with you Clark re: the short-sightedness of not supporting FBA 
in MVS. Because of that dumb decision, z/OS is the only mainframe 
operating system left in the 21st century that can't handle SCSI. :-( 
That situation should be rectified!

But, why do you say we need FBA in order to support volumes greater than

54GB? Why can't ECKD be extended to support larger volumes?

-- 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: FBA rant was Re: IBM S/360 series operating systems history

[Edward Jaffe]

Clark Morris wrote:

So the jackasses will have cost the company far more than the 20
million dollars by their opposition.  Does anyone really think that 54
gigabytes per volume is going to be other than totally inadequate in
the next ten years?  Laptops now have 100 gigabytes and up on a single
drive.  FBA will require major changes to spool management but we
might be able to get away from the one track IPL text.  I can see
various FBA types such as: ones with file systems with all
directory/file name/member name information in Unicode, ones with just
z/FS or successor file systems and looking like true Unix volumes, and
ones that are structured to be only VSAM/PDSE related volumes.  There
might be other variants once the bottleneck of CKD is broken.  MVS
might even be able to recognize a DVD.
  


I agree with you Clark re: the short-sightedness of not supporting FBA 
in MVS. Because of that dumb decision, z/OS is the only mainframe 
operating system left in the 21st century that can't handle SCSI. :-( 
That situation should be rectified!


But, why do you say we need FBA in order to support volumes greater than 
54GB? Why can't ECKD be extended to support larger volumes?


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

FBA rant was Re: IBM S/360 series operating systems history

[Clark Morris]

On Fri, 02 Mar 2007 08:29:28 -0700, in bit.listserv.ibm-main you
wrote:

>Phil Payne wrote:
>> They had Memorex Double Density 3350s with IDI - "Intelligent Dual 
>> Interface".  Was ever
>> anything so inappropriately named?  A status bus parity check - a common 
>> occurence - caused
>> all IDI-linked controllers to forget all owed interrupts.  Total system 
>> hang.  SVS had a MIH,
>> but its channel redrive was - IMO - incorrect.  I can't remember after a 
>> quarter of a century,
>> but it did a Clear IO when it should have done a Clear Channel or vice 
>> versa. I zapped the
>> opcode
>
>for other topic drift ... san jose had done a 3350 (prior to 3380) with twice 
>the number of cylinders ... but they couldn't get MVS to provide the device 
>support ... so they shipped it as two emulated regular 3350s ... which didn't 
>see a lot of uptake, partially because the two independent optimized seek 
>queues would be contending for single arm (resulting in relatively random arm 
>motion).
>
>this was an ongoing problem. MVS also wouldn't do FBA 
>(fixed-block-architecture) device support. It was even offered to provide them 
>with the fully tested code ... and the reply was there would still be a twenty 
>some million change bill (documentation, training, etc). Needed to demonstrate 
>real incremental ROI for the  (i.e. real additional new sales as opposed to 
>customers buying FBA in-lieu of CKD).

So the jackasses will have cost the company far more than the 20
million dollars by their opposition.  Does anyone really think that 54
gigabytes per volume is going to be other than totally inadequate in
the next ten years?  Laptops now have 100 gigabytes and up on a single
drive.  FBA will require major changes to spool management but we
might be able to get away from the one track IPL text.  I can see
various FBA types such as: ones with file systems with all
directory/file name/member name information in Unicode, ones with just
z/FS or successor file systems and looking like true Unix volumes, and
ones that are structured to be only VSAM/PDSE related volumes.  There
might be other variants once the bottleneck of CKD is broken.  MVS
might even be able to recognize a DVD. 
>
>> rest snipped

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Rick Fochtman]

Phil, I'd LOVE to find the source code for those systems, to add to my 
"archives". 



Phil Payne wrote:


SVS was bizarrely popular in Germany, and lived on there for longer than almost 
anywhere.  IBM
Bonn produced an _excellent_ SVS 1.7K DLIB tape that really was well sorted out 
and I had over
a dozen customers using it.

One customer - Maizena in Heilbronn, part of Knorr and manufacturers of the 
German Army's pea
soup tablets - converted from MFT to SVS in 1982 - well after stable MVS was 
available.

They had two systems programmers - Herr Jung and Herr Joshonek.  Their IT 
manager called them
together after the MFT ---> SVS migration and said something to the effect that 
MFT had served
them well for ten years and he expected SVS to do the same.  One quarter later 
he was asking
us for a remote support contract because both had left the company.

We (Itel) sold them a 370/145 with a 3205-5 (? 4?) IPA-attached printer.  
Lovely little
thing - built-in vacuum cleaner, etc.  IMO one of IBM's best ever line printers.

I went down one day and they weren't using it.  I asked why, and opened a 
hornet's nest.  SVS
HASP didn't support it, and there were legal proceedings in progress about the 
mis-sale.  I
pointed out that HASP always assembled one spare printer device support block, 
and you just
had to zap in the FCB CCW and the UCS load CCW.  We had it working perfectly 
within an hour -
very, very happy data centre.  I also patched the HASP source to reassemble it 
correctly if
they reinstalled.

When I got back to Frankfurt from Heilbronn, I got roasted.  The management 
were hoping to
"ride" the court case and place a /158 - I'd blown their deal.

Another SVS customer was Kommunalesgebietsrechenzentrum Kranichstein.  You 
can't make names
like that up.

They had Memorex Double Density 3350s with IDI - "Intelligent Dual Interface".  
Was ever
anything so inappropriately named?  A status bus parity check - a common 
occurence - caused
all IDI-linked controllers to forget all owed interrupts.  Total system hang.  
SVS had a MIH,
but its channel redrive was - IMO - incorrect.  I can't remember after a 
quarter of a century,
but it did a Clear IO when it should have done a Clear Channel or vice versa. I 
zapped the
opcode

SUCCESS!!!  No more system hangs.  A MIH message, and off it went again.  
Happy, happy
operators.  Claps on the back and lots of beer.

Then their management reassigned all of the outages to a "software fault" and 
billed us for
them.

TOS error recovery brings back nightmares.  Ford of Europe had a small /360 - 
perhaps a 25 -
at Warley used for shipping data to Germany.  It ran TOS - but on 2415s.  If 
you've ever
watched error recovery running off 2415s, you know what it's really like 
watching paint dry.
Literally HOURS.

I always though COS stood for Card Operating System.  ISTR it was very similar 
in practical
ways to the BPS card loader, but 8 cards instead of 6.  You just loaded the 8 
cards, and then
it watched for not-ready to ready transitions at the loading card reader

 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Phil Payne wrote:

They had Memorex Double Density 3350s with IDI - "Intelligent Dual Interface".  
Was ever
anything so inappropriately named?  A status bus parity check - a common 
occurence - caused
all IDI-linked controllers to forget all owed interrupts.  Total system hang.  
SVS had a MIH,
but its channel redrive was - IMO - incorrect.  I can't remember after a 
quarter of a century,
but it did a Clear IO when it should have done a Clear Channel or vice versa. I 
zapped the
opcode


for other topic drift ... san jose had done a 3350 (prior to 3380) with twice 
the number of cylinders ... but they couldn't get MVS to provide the device 
support ... so they shipped it as two emulated regular 3350s ... which didn't 
see a lot of uptake, partially because the two independent optimized seek 
queues would be contending for single arm (resulting in relatively random arm 
motion).

this was an ongoing problem. MVS also wouldn't do FBA 
(fixed-block-architecture) device support. It was even offered to provide them 
with the fully tested code ... and the reply was there would still be a twenty 
some million change bill (documentation, training, etc). Needed to demonstrate 
real incremental ROI for the  (i.e. real additional new sales as opposed to 
customers buying FBA in-lieu of CKD).

lots of past posts about hacking around in the disk engineering and test labs 
(bldgs 14&15)
http://www.garlic.com/~lynn/subtopic.html#disk

From: wheeler
Date: 09/07/82 12:16:54
 
IBM double density (double the number of tracks) are here also. The

engineers have been fighting with the OS people (completely
unsuccessfully) to support the box in native mode .. i.e. one device
with twice the number of cylinders as a 3350. OS data management
people would have nothing of it. Several engineers who had MVT
experience said that they could go in and do it easily just by
defining a new device type and updating a couple of tables (almost as
trivial as what it takes for VM). OS data management replied that
things have completely changed since then, implying that they might
not even know all the routines that may have tables now. Result is
that the engineers have been forced into simulating two 3350 drives on
a single double density 3350 because the OS crowd is completely
incapable of getting their act together. As a result any performance
optimization techniques are going to be blown almost completely out of
the window (in some ways worse than effect of multi-track search). Not
only is two device simulation going to completely lay to waste any
ordered seek queueing algorithms (as bad as what happens in a multiple
CPU, shared DASD situation) ... but VM is stuck with the design also.

Based on the current record so far ... any investigation into MVS
support of FBA is going to be little more than another throw-away task
force report w/o any productive results.

... snip ...

for FBA/CKD topic drift ... recent post about heavy performance penalty 
multi-track CKD extracted long after the memory/io trade-off had changed
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction

and lots of past posts on the CKD performance trade-off subject ... using 
excess I/O capacity in the 60s to compensate for scarce real-storage ... but by 
the mid-70s, configurations were changing from real-storage constrained to I/O 
constrained ... making the CKD trade-off totally the wrong thing.
http://www.garlic.com/~lynn/subtopic.html#dasd

other old email about early difficulty with MVS RAS for 3380 ... which got me 
into loads of hot water with the MVS RAS manager ... not because of the tests 
... but for having sent an email mentioning the results of the tests.
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"

when I had originally started playing around in the disk engineering labs ... the 
"testcells" (i.e. development devices) were being scheduled for stand-alone testing on 
dedicated processors. They had attempted to run under MVS in an operating system environment ... 
but experienced 15 min MTBF for MVS (i.e. MVS was crashing or hanging because of errors and/or 
incorrect operations of the devices under development). I undertook to completely redo the i/o 
subsystem to make it bullet-proof ... allowing multiple concurrent testcells to be tested 
"on-demand" ... rather than having to resort to dedicated, stand-alone scheduled testing 
time.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Randy Hudson]

In article <[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:

> Don't know about MFT, but MVT was reclassified as Class C (meaning frozen,  
> no more new releases, no more fixes) in November, 1977.  I continued  working 
> with it and other OS/360 variants off and on until late 1983.

It wasn't completely frozen, because I learned sysgen assisting a 1978
sysgen of MVT 21.8E, and in 1979 led a sysgen of MVT 21.8F, which had come
out in the meantime.  (Got a huge increase in batch throughput by making the
tape error recovery routine resident instead of transient.)

-- 
Randy Hudson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Steven Arnett]

Patrick O'Keefe wrote:

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:

NAMEBALR,R12,R0
BCTR  R12,R0
BCTR  R12,R0
USING NAME,R12

NAME   STM  R14,R12,12(R13)
 LRR12,R15
 USING NAME,R12
etc

It is amazing how just just eight or so years on DOS could do that to a 
person.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Patrick O'Keefe]

On Wed, 28 Feb 2007 18:53:30 EST, IBM Mainframe Discussion List 
<[EMAIL PROTECTED]> wrote:

>...
>you put the 6-card BPS IPL deck ...

I remember 3 different BPSloaders - 3-card, 7-card, and 12-card versions.
There very well could have been a 6-card loader, too.  I have no idea what
the differences were but I bet the 3-card loader didn't uspport REP cards. 

...
>I heard about COS, for Compatibility Operating System, ...

I remember running COS back when I was an operator.  It was 1401, etc. 
compatability.  

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Tony Harminc]

Shmuel Metz wrote:

> My recollection is that the original virtual storage announcement for
> S/370 already used the term MVS for OS/VS2 R2.

My recollection is that IBM pushed the term OS/VS2 Release 2, to avoid
suggesting that it was much different from Release 1 (SVS).

> However, you will still see remnants in the code of the original names,
AOS/1 and AOS/2.

And MVM (presumably Multiple Virtual Memories) - a name that never made it
into external doc. But it was on the header line of IEHDASDR for a long
time.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Rick Fochtman]

---
Unlike most new threads that end up in ancient history and then have to 
be killed, this one starts out with ancient history! What an opportunity 
for us Jurassic-types. Since I was non-email-capable for two weeks, I 
read all old posts before adding my 2 cents' worth, which embody 
responses to many previous posts.


Don't know about MFT, but MVT was reclassified as Class C (meaning 
frozen, no more new releases, no more fixes) in November, 1977. I 
continued working with it and other OS/360 variants off and on until 
late 1983. 


PCP did indeed stand for Primary Control Program.

I used BPS, TOS, and DOS from mid-1966 to late 1971. The worst thing 
that the tape-resident-SYSRES TOS had to do was to recover from an I/O 
error on the SYSRES tape itself - backspace or forwardspace to fetch the 
system module to do the recovery, whose logic said to retry the failing 
I/O, so move the tape back to where the error was, re-read ten times, 
then, if it still failed, move the tape way back to the beginning again 
to locate the system module to do the ABEND process. Truly heinous and 
egregious.


BPS had a 2-pass 8K card assembler available for hard-core warriors. You 
put the standard BPS self-loading IPL deck (all of 6 cards) in the card 
reader followed by the 8K card assembler phase 1 object deck followed by 
your source deck and IPLed from the card reader. The first phase punched 
one output card, containing intermediate Assembly data, for each input 
source card. Then you put the 6-card BPS IPL deck in the card reader 
followed by the 8K card assembler phase 2 object deck followed by all 
the cards punched out in phase 1 and IPLed from the card reader again. 
This second phase punched the final object deck. In order to run the 
program thus assembled, you again put the 6-card self-loading IPL deck 
in the card reader followed by this object deck and reIPLed from the 
card reader. So you had an "operating system" with major limitations: 
(1) only one program could run at a time, (2) you had to re-IPL whenever 
you wanted to run a different program, and (3) the operator performed 
the operating system's functions of running one job after another.


The first version of BPS did not support multiplexing on the multiplexor 
channel. Regardless of how cleverly you tried to overlap I/O, when you 
did the EXCP the supervisor would do a SIO to start the I/O and then a 
TIO loop until the I/O completed before returning control to the 
instruction just after the EXCP's SVC. More heinosity and egregiousness.


MVT was first virtualized in early 1974 as OS/VS2 Release 1, better 
known as SVS (Single Virtual Storage). A fuller version, OS/VS2 Release 
2, was available a year or so later, and it was quickly renamed MVS for 
Multiple Virtual Storages. MFT evolved into VS1.


I heard about COS, for Compatibility Operating System, but I'm not sure 
what was made compatible with what (maybe it was a 360/20 emulator 
running on a 360/30?).

--
We should get together sometime, Bill. I'm in Woodridge.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Shmuel Metz , Seymour J. wrote:

My recollection is that the original virtual storage announcement for
S/370 already used the term MVS for OS/VS2 R2. However, you will still
see remnants in the code of the original names, AOS/1 and AOS/2.


some number of customers had been doing stuff to make MVT run better in a cp67 
(on 360/67)
virtual machine ... including various things related to virtual memory.

there was a period when we were making regular trips from cambridge to pok to 
participate
in 370 architecture meetings ... especially related to virtual machine and 
virtual memory operation ... and would periodically knock around 706 machine 
room in the evenings where AOS prototype
was being built ... crafting virtual memory on the side of MVT for what was to 
become
SVS.

Ludlow(?, i'm pretty sure i remember his name) was doing a lot of the work. 
Part of the
effort involved taking the (virtual to real) channel program translator/builder 
from CP67 (CCWTRANS) and cobbling it into the side of MVT (i.e. a lot of AOS 
... instead of running MVT under cp67
virtual machine virtual memory ... was hacking various pieces of cp67 virtual 
memory support
into the side of a MVT kernel ... especially the channel program translator ... 
which was
some amount of fairly complicated code, involving interpreting the virtual channel program, making 
a shadow, finding all the "data" virtual pages, fixing them in core ... and using the 
"real" addresses).

recent thread discussing patching CCWTRANS to handle ISAM and other 
self-modifying channel programs
i.e. CCWTRANS built a "shadow" of the "applications" virtual channel program ... with "real" 
addresses ... and ran the "shadow" channel program ... any dynamic modifications that an application did to the 
"virtual" channel program wouldn't actually involve the channel program being executed.
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#17 A way to speed up level 1 caches
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction

A slightly different issue I had was with the POK performance modeling group that was 
trying to come up with virtual page replacement algorithms. They eventually decided on 
including some optimization feature that I claimed that would totally distort "least 
recently used" assumptions related to page replacement. They did it anyway ... and 
it wasn't until well into MVS release cycle in the late 70s ... that it dawn on them that 
they were selecting high-use LINKPACK shared executable pages for replacement before 
private, lower-used application data pages.

lots of past posts related to page replacement algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
as well as old email on the same subject
http://www.garlic.com/~lynn/lhwemail.html#globallru

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
http://www.garlic.com/~lynn/2007d.html#65 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#69 IBM S/360 series operating systems 
history
http://www.garlic.com/~lynn/2007d.html#72 IBM S/360 series operating systems 
history

misc. pasts posts taking ludlow's name in vain:
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for 
a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: 
Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable 
operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable 
operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging
http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or 
nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2004e.html#40 Infiniband - practicalities for small 
clusters
http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the 
line
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/28/2007
   at 06:53 PM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>Don't know about MFT, but MVT was reclassified as Class C (meaning
>frozen,   no more new releases, no more fixes) in November, 1977. 

MVT was just an OS/360 sysgen option. It was OS/360 in its entirety
that was frozen.

>MVT was first virtualized in early 1974 as OS/VS2 Release 1, better
>known  as  SVS (Single Virtual Storage).  A fuller version, OS/VS2
>Release  2, was  available a year or so later, and it was quickly
>renamed MVS  for Multiple Virtual  Storages.  MFT evolved into VS1.

My recollection is that the original virtual storage announcement for
S/370 already used the term MVS for OS/VS2 R2. However, you will still
see remnants in the code of the original names, AOS/1 and AOS/2.

>I heard about COS, for Compatibility Operating System, but I'm not 
>sure what  was made compatible with what (maybe it was a 360/20
>emulator running  on a  360/30?).

14xx Emulator running under DOS/360. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[(IBM Mainframe Discussion List)]

Unlike most new threads that end up in ancient history and then have to be  
killed, this one starts out with ancient history!  What an opportunity for  us 
Jurassic-types.  Since I was non-email-capable for two weeks, I read all  old 
posts before adding my 2 cents' worth, which embody responses to many  
previous posts.
 
Don't know about MFT, but MVT was reclassified as Class C (meaning frozen,  
no more new releases, no more fixes) in November, 1977.  I continued  working 
with it and other OS/360 variants off and on until late 1983.
 
PCP did indeed stand for Primary Control Program.
 
I used BPS, TOS, and DOS from mid-1966 to late 1971.  The worst thing  that 
the tape-resident-SYSRES TOS had to do was to recover from an I/O error on  the 
SYSRES tape itself - backspace or forwardspace to fetch the system  module to 
do the recovery, whose logic said to retry the failing I/O, so move  the tape 
back to where the error was, re-read ten times, then, if it still  failed, 
move the tape way back to the beginning again to locate the system  module to 
do 
the ABEND process.  Truly heinous and egregious.
 
BPS had a 2-pass 8K card assembler available for hard-core warriors.   You 
put the standard BPS self-loading IPL deck (all of 6 cards) in the card  reader 
followed by the 8K card assembler phase 1 object deck followed by your  source 
deck and IPLed from the card reader.  The first phase punched one  output 
card, containing intermediate Assembly data, for each input source  card.  Then 
you put the 6-card BPS IPL deck in the card reader followed by  the 8K card 
assembler phase 2 object deck followed by all the cards punched out  in phase 1 
and IPLed from the card reader again.  This second phase punched  the final 
object deck.  In order to run the program thus assembled, you  again put the 
6-card self-loading IPL deck in the card reader followed by this  object deck 
and 
reIPLed from the card reader.  So you had  an "operating system" with major 
limitations:  (1) only one program  could run at a time, (2) you had to re-IPL 
whenever you wanted to run a  different program, and (3) the operator performed 
the operating system's  functions of running one job after another.
 
The first version of BPS did not support multiplexing on the multiplexor  
channel.  Regardless of how cleverly you tried to overlap I/O, when you did  
the 
EXCP the supervisor would do a SIO to start the I/O and then a TIO loop  until 
the I/O completed before returning control to the instruction just after  the 
EXCP's SVC.  More heinosity and egregiousness.
 
MVT was first virtualized in early 1974 as OS/VS2 Release 1, better known  as 
SVS (Single Virtual Storage).  A fuller version, OS/VS2 Release  2, was 
available a year or so later, and it was quickly renamed MVS  for Multiple 
Virtual 
Storages.  MFT evolved into VS1.
 
I heard about COS, for Compatibility Operating System, but I'm not  sure what 
was made compatible with what (maybe it was a 360/20 emulator running  on a 
360/30?).
 
Bill  Fairchild
Plainfield, IL

"Criticism and dissent are the indispensable  antidote to major delusions." 
[Alan Barth, 1951; The Loyalty of Free  Men]
** AOL now offers free 
email to everyone.  Find out more about what's free from AOL at 
http://www.aol.com.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/23/2007
   at 03:02 PM, "Patrick O'Keefe" <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Patrick O'Keefe]

On Fri, 23 Feb 2007 20:18:40 +1100, Ken Brick <[EMAIL PROTECTED]> 
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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Tom Marchant
Sent: Friday, February 23, 2007 1:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history

On Fri, 23 Feb 2007 11:03:10 -0700, Anne & Lynn Wheeler wrote:

>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.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Tom Marchant]

On Fri, 23 Feb 2007 11:03:10 -0700, Anne & Lynn Wheeler wrote:

>[EMAIL PROTECTED] (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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

[EMAIL PROTECTED] (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 ..

instruction FORMAT   MNEMONIC TIME
Edit  SSED   38+7N1+9N2
Edit and Mark SSEDMK 45+7N1+9N2

Translate SSTR   31+6N
Translate and TestSSTRT  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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Ken Brick]

Thompson, Steve wrote:
> I rarely called other programs, but when I did, I used the basic
> protocols (R0-R1, R13-R15) with STM/LM, but using halfwords.
>
>   
When calling subroutines, R15 was the entry point, R14 the return
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).
>
>   
R0 = x''
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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Ken Brick]

Patrick O'Keefe wrote:
> 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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Patrick O'Keefe
Sent: Thursday, February 22, 2007 2:56 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history



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).


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Patrick O'Keefe]

On Wed, 21 Feb 2007 12:27:59 -0500, Shmuel Metz (Seymour J.)  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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/21/2007
   at 06:21 PM, Ken Brick <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/20/2007
   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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Ken Brick]

Thompson, Steve wrote:
> /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. 
> /unsnip
>
>   
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

> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Charles Mills
Sent: Tuesday, February 20, 2007 5:08 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM S/360 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.

I don't recall if TOS supported overlay structures. That is not an idea
whose time has come: loading overlay segments from tape.


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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Charles Mills]

Ah! Mea culpa. You said what I quoted twice, the first time with the
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:[EMAIL PROTECTED] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, February 20, 2007 12:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM S/360 series operating systems history

In <[EMAIL PROTECTED]>, on 02/19/2007
   at 12:11 PM, Charles Mills <[EMAIL PROTECTED]> 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."

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Patrick Mulvany]

Thanks for all the feedback.

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

On 20/02/07, Rick Fochtman <[EMAIL PROTECTED]> wrote:


--
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.
---
BPS also ran on the 360/44, from that little single-platter disk is the
side of the CPU.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html





--
LiffOff Energy Anywhere: www.fizz2focus.com

For health and wellness solutions : www.shapingwellness.com
Opportunity : www.excitingformula.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 02/19/2007
   at 01:08 PM, Kirk Talman <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 02/20/2007
   at 10:05 AM, "Steele, Phil" <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/19/2007
   at 12:11 PM, Charles Mills <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[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.
---
BPS also ran on the 360/44, from that little single-platter disk is the 
side of the CPU.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Thompson, Steve]

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Ken Brick
Sent: Monday, February 19, 2007 1:26 AM
To: IBM-MAIN@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.



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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Steven Arnett]

Anne & Lynn Wheeler wrote:

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Steele, Phil]

I had not heard of TPS of DPS ( I dare say they were tape and disk
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:[EMAIL PROTECTED] On
Behalf Of Ken Brick
>Sent: Monday, 19 February 2007 6:26 PM
>To: IBM-MAIN@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 [EMAIL PROTECTED] 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.
***

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Charles Mills wrote:

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).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Clark Morris]

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  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
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Charles Mills]

> 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

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Monday, February 19, 2007 10:06 AM
To: IBM-MAIN@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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on
02/18/2007
   at 08:24 PM, Patrick Mulvany <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/19/2007
   at 06:22 PM, Ken Brick <[EMAIL PROTECTED]> 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  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[john gilmore]

My apologies to Kirk Talman for rechristening him Kurt without 
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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[john gilmore]

Kurt Talman wrote:



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/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Kirk Talman]

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.

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  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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Ken Brick]

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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Ken Brick]

Patrick Mulvany wrote:
> 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.
> /snip
> /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
>
>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)

Been a long time

Ken

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Clark Morris]

On 18 Feb 2007 12:24:48 -0800, in bit.listserv.ibm-main you wrote:

>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.
>
>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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Gilbert Saint-Flour]

On Sunday 18 February 2007 15:24, Patrick Mulvany wrote:

> (...) 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/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: IBM S/360 series operating systems history

[Anne & Lynn Wheeler]

Patrick Mulvany wrote:

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html