DOS/360: Forty years
Peter...@yahoo.com
(DOS/VS, DOS/VSE, DOS/ESA, z/VSE) in its current issue. Can we expect
a birthday party from IBM?
For many of us, "DOS" will always conjure up memories of 32K 360/30's,
7.25MB 2311's, 1401 emulation, and lots of punched-cards. The first
thing that comes to mind is *not* that imposter "DOS" that runs on toy
PCs today.
Lets tip a cold one to DOS' 40th.
Nick Spalding
<1114449488.2...@l41g2000cwc.googlegroups.com>:
DOS was a johnny-come-lately, real men ran their /30s on BOS.
--
Nick Spalding
jsa...@ecn.ab.ca
> that runs on toy
> PCs today.
Now you just wash your mouth!
PC-DOS may be an impostor compared to DOS/360, but today's PCs are not
toys.
Was a 360/195 a toy?
It had a 32K cache, 4 megabytes of 750ns RAM (slowed to 780ns because
of the 60ns cycle time), pipelines, and an accelerated arithmetic unit
that sped up multiplication and division by working on more than one
bit at a time...
in other words, a 16.67 MHz Pentium with a clock multiplier of 13. And
not even the same width of address bus as a 386SX, which was capable of
handling the entire 16M of address space the 360 architecture allowed.
If today's PCs are toys, it isn't the fault of the *hardware*.
John Savard
Eric Sosman
How long is the "Program[*] Temporary Fix" tape these days?
[*] Cynics pronounced this word as "Permanent."
Peter...@yahoo.com
Alan Balmer
I remember a user's conference button that said:
OS goes Whee! Bump.Whee! Bump.
DOS goes Hummmm.....
Or something like that. Anybody still have one of those buttons?
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
hanc...@bbs.cpcn.com
Peter_Fl...@Yahoo.com wrote:
> For many of us, "DOS" will always conjure up memories of 32K
360/30's,
> 7.25MB 2311's, 1401 emulation, and lots of punched-cards. The first
> thing that comes to mind is *not* that imposter "DOS" that runs on
toy
> PCs today.
I remember that if you happened to work in a DOS shop, you
had trouble getting a job in OS shops. They saw you as being
too weak and needing extensive training. (Learning OS JCL
was no big deal).
I remain impressed that our DOS ran in all of 16K (of our 192k
machine), but was enough to run a hospital information system.
My hat goes off to those IBMers who slaved away at developing
it at the last minute, when they discovered OS just wouldn't
work on small machines.
Joe Morris
Don't forget TOS, the bastard cousin of DOS. Either could be generated
from the same set of distribution libraries; once just for the hell of it
I built a TOS system, IPL'ed it, then watched in horror as it ran the
tape all over the place like a parent frantically searching for a lost
child.
I do need to admit that the tape was absolutely unoptimized (I recall
sweating over the old IBSYS system tape layouts to cut down on time
lost during re- or pre-positioning), and we were an OS shop, not DOS.
Our original plan (for installation of a /40 in mid-1967) was to
be running DOS because of memory constraints, but eventually concluded
that we could successfully run our typical FORTRAN G (IEYFORT) jobs
in an MFT partition of only 86K.
H'mmm...I think that somewere I've got the fiche with the announcement
of OS/360 version 1; I'm not sure if it also has the original announcement
for DOS as well.
Joe Morris
hanc...@bbs.cpcn.com
jsav...@ecn.ab.ca wrote:
> If today's PCs are toys, it isn't the fault of the *hardware*.
Certainly the CPUs are very much faster than the old S/360.
However, IMHO, the PC hardware remains inferior to S/360.
The big difference is how S/360 handled multi-programming,
IMHO much better than a PC. The I/O was kept properly separated.
Further, S/360 was able to handle far more I/O devices and
activity than a PC can. I doubt even today's sophisticated
desktop PCs could handle multiple users banging away on them,
along with multiple high speed printers, readers and punches.
But our DOS S/360-40 handled it smoothly. (Admittedly our 2415
tape drivers were incredibly slow).
Unfortunately, as PCs have grown in size and horsepower, their
operating systems have grown along with them. It frustates me
to no end that my home PC--an old Pentium 120 is faster than my
work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
on the work unit. I try to use older MS programs (ie Word 6.0
instead of Word 2000) because they run so much faster and don't
have unnecessary bloat.
Our S/360-40 had enough core to handle good, well written
COBOL programs--we didn't have to resort to memory tricks
to save space. The resultant programs were maintainable
but ran well. (Our substantial Autocoder emulation apparently
didn't take advtg of the available core and ran rather slowly).
We had enough CPU cycles and core for spooling and a small
online system as well.
Roland Hutchinson
> Unfortunately, as PCs have grown in size and horsepower, their
> operating systems have grown along with them. It frustates me
> to no end that my home PC--an old Pentium 120 is faster than my
> work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
> on the work unit. I try to use older MS programs (ie Word 6.0
> instead of Word 2000) because they run so much faster and don't
> have unnecessary bloat.
The very fact that someone can seriously regard Word 6 as relatively
bloat-free itself speaks volumes about our current expectations and
tolerance level for bloat.
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Patrick Scheible
> If it doesn't fill a room, it's a toy;-)
Which room? The closet under the stairs (TM J.K. Rowling) or the
Superdome?
-- Patrick
Morten Reistad
<hanc...@bbs.cpcn.com> wrote:
>
>jsav...@ecn.ab.ca wrote:
>
>> If today's PCs are toys, it isn't the fault of the *hardware*.
>
>Certainly the CPUs are very much faster than the old S/360.
>However, IMHO, the PC hardware remains inferior to S/360.
>
>The big difference is how S/360 handled multi-programming,
>IMHO much better than a PC. The I/O was kept properly separated.
>
>Further, S/360 was able to handle far more I/O devices and
>activity than a PC can. I doubt even today's sophisticated
>desktop PCs could handle multiple users banging away on them,
>along with multiple high speed printers, readers and punches.
>But our DOS S/360-40 handled it smoothly. (Admittedly our 2415
>tape drivers were incredibly slow).
I think some of you need to see a modern server PC with a decent OS.
Modern servers have 3-6 PCI busses, 2-8 processors, possibly with
hyperthreading, and handle 256 or more interrupts or DMA channels.
The long, painful road to Linux 2.6 was all about supporting this.
Memory bandwidth is somewhere around 800 megawords per second, where
the word is 32 to 128 bits in size. They usually have 2-15 network
interfaces, and can handle multiple gigabits worth of network
bandwidth. Raw, aggregate, old-time MIPS rating is somewhere around
5-25 BIPS integer and 2-14 BIPS floating point. Disks are usually
handled in separate RAID/mirror clusters. Disks tend to be the slow
components. Nothing new there.
Caches are large, and popular programs (like KLH10) run all in cache.
They cost more than a stock PC, around $3000. I am truly impressed
at their load-taking capabilities. You can let loose a thousand
database connections, or a few tens of thousands web users on one of
these.
They don't have serial ports. Nor floppy drives.
>Unfortunately, as PCs have grown in size and horsepower, their
>operating systems have grown along with them. It frustates me
>to no end that my home PC--an old Pentium 120 is faster than my
>work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
>on the work unit. I try to use older MS programs (ie Word 6.0
>instead of Word 2000) because they run so much faster and don't
>have unnecessary bloat.
That the desktop is unacceptably bloated is not the fault of
the PC designer. They have made a stellar job of migrating
the old 8088 design into something really good.
>Our S/360-40 had enough core to handle good, well written
>COBOL programs--we didn't have to resort to memory tricks
>to save space. The resultant programs were maintainable
>but ran well. (Our substantial Autocoder emulation apparently
>didn't take advtg of the available core and ran rather slowly).
>
>We had enough CPU cycles and core for spooling and a small
>online system as well.
I have a different recollection of CPU availability. CPU cycles
were scarce and rationed until sometime in 1996, when the idle
process suddenly became the main CPU user.
-- mrr
Eric Smith
> z/Journal (http://www.zjournal.com) is celebrating 40 years of DOS/360
> (DOS/VS, DOS/VSE, DOS/ESA, z/VSE) in its current issue. Can we expect
> a birthday party from IBM?
Does anyone still have a copy of DOS/360 (or BOS or TOS) that will run
on a 360/30? The Computer History Museum has a 360/30. It is not
currently operational, and there are currently no official (or even
unofficial) plans to restore it, but I'm hoping that someday we can do
it.
I'm not sure how much core this particular 360/30 has, but since it
can't be more than 64KB, I'm guessing that there weren't too many
choices for operating systems for it. Was there anything other than
BOS, TOS, or DOS?
The museum has some 2311 disk drives and some 24xx tape drives with it,
but it appears that the control units for those are not present.
I hope that we can find suitable control units, but if not, at least
the channel interface is very well documented, so as a last resort
we could either try to use more modern channel devices, or engineer
new peripherals with channel interfaces. It would be amusing to use
a tiny little SD card as a DASD on the 360.
Eric
Anne & Lynn Wheeler
hanc...@bbs.cpcn.com writes:
> Further, S/360 was able to handle far more I/O devices and activity
> than a PC can. I doubt even today's sophisticated desktop PCs could
> handle multiple users banging away on them, along with multiple high
> speed printers, readers and punches. But our DOS S/360-40 handled
> it smoothly. (Admittedly our 2415 tape drivers were incredibly
> slow).
to some extent it was transfered bytes per mip ... and/or arm accesses
per mip.
in the late 70s ... i started making some observation that disk
relative system performance had declined by something like a factor of
ten times (by the early 80s, cpus, memories, etc had increased by a
factor of 50 times while disk arm performance had only increased by a
factor of five times or less ... therefor the disk arm performance had
a relative system performance decline of a factor of ten times).
we had a 360/67 that support 70-80 cp67/cms users ... and much later
there was a processor with nearly fifty times the processing power
supporting 300 vm370/cms users. It turns out the disk arm performance
had possibly improved by a factor of four times.
One of the things you really started seeing was trying to leverage
various kinds of caching (explosion in the availability of memory
sizes) to compensate for the lack of disk performance improvements.
Other approaches that tended to trade-off electronic memory vis-a-vis
disk arm performance was to transfer in significantly larger blocks
(which could make sense for some application environments).
In any case, my assertions upset some number of people in the disk
division ... and their performance modeling group got assigned to
refute it. After a couple months, they came back and effectively said
that I somewhat understated the decline in disk relative system
thruput. They then turned the study into SHARE presentation ... where
they described disk strategies to help overall system thruput.
some random past postings mentioning the decline in disk relative
system performance:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2001m.html#23 Smallest Storage Capacity Hard Disk?
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2004n.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005f.html#55 What is the "name" of a system?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Lawrence Wilkinson
> I'm not sure how much core this particular 360/30 has, but since it
> can't be more than 64KB, I'm guessing that there weren't too many
> choices for operating systems for it. Was there anything other than
> BOS, TOS, or DOS?
It probably has 64k, it certainly has 2 modules, see the first photo at
http://www.ljw.me.uk/ibm360/photos (it could be 48k). Not that that
helps much!
Incidentally BPS was released in March '65 (does it count as an OS?) but
DOS didn't emerge until June '66 (according to Pugh/Johnson/Palmer).
--
Lawrence Wilkinson lawr...@ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
Alan Balmer
<firs...@lastname.pr1v.n0> wrote:
>In article <1114458704.5...@z14g2000cwz.googlegroups.com>,
> <hanc...@bbs.cpcn.com> wrote:
>>
>>jsav...@ecn.ab.ca wrote:
>>
>>> If today's PCs are toys, it isn't the fault of the *hardware*.
>>
>>Certainly the CPUs are very much faster than the old S/360.
>>However, IMHO, the PC hardware remains inferior to S/360.
>>
>>The big difference is how S/360 handled multi-programming,
>>IMHO much better than a PC. The I/O was kept properly separated.
>>
>>Further, S/360 was able to handle far more I/O devices and
>>activity than a PC can. I doubt even today's sophisticated
>>desktop PCs could handle multiple users banging away on them,
>>along with multiple high speed printers, readers and punches.
>>But our DOS S/360-40 handled it smoothly. (Admittedly our 2415
>>tape drivers were incredibly slow).
>
>I think some of you need to see a modern server PC with a decent OS.
>
>Modern servers have 3-6 PCI busses, 2-8 processors, possibly with
>hyperthreading, and handle 256 or more interrupts or DMA channels.
>The long, painful road to Linux 2.6 was all about supporting this.
For most people, I don't think you are describing a Personal Computer.
Peter Flass
>
> I'm not sure how much core this particular 360/30 has, but since it
> can't be more than 64KB, I'm guessing that there weren't too many
> choices for operating systems for it. Was there anything other than
> BOS, TOS, or DOS?
>
BPS, I believe, although that's not really an OS, more like an IOCS,
unless that was model 20 only. Otherwise not (AFAIK) from IBM. Search
the Yahoo Hercules-390 group. Some people have mentioned the "Telpar
OS", and "VM/PE", for example.
dr...@timesten.com
Wait a few months.
Intel said at their recent IDF that by the end of the decade, typical
desktop computers will process 8 instruction streams simultaneously.
Their first dual-core LAPTOP chipset will ship next year.
Edgar Wolphe
>
>
>Further, S/360 was able to handle far more I/O devices and
>activity than a PC can. I doubt even today's sophisticated
>desktop PCs could handle multiple users banging away on them,
>along with multiple high speed printers, readers and punches.
>But our DOS S/360-40 handled it smoothly. (Admittedly our 2415
>tape drivers were incredibly slow).
You might not have been introduced to Microsoft's Terminal Server...
or better yet, Citrix. A decent dual-processor server with a couple
gig RAM can easily handle over 100 simultaneous connections, each
runnning it's own environment on the server, and at the same time
handle mutiple local and/or network attached printers.
EW
If you add up all known religions
and cancel the contradictions, you are left with only one invariant
universal message: God needs *your* money.
----Uncle Al
rpl
> Furiously scratching in the sand, hanc...@bbs.cpcn.com wrote:
>
>
>>
>>Further, S/360 was able to handle far more I/O devices and
>>activity than a PC can. I doubt even today's sophisticated
>>desktop PCs could handle multiple users banging away on them,
>>along with multiple high speed printers, readers and punches.
>>But our DOS S/360-40 handled it smoothly. (Admittedly our 2415
>>tape drivers were incredibly slow).
>
>
> You might not have been introduced to Microsoft's Terminal Server...
> or better yet, Citrix. A decent dual-processor server with a couple
> gig RAM can easily handle over 100 simultaneous connections, each
> runnning it's own environment on the server, and at the same time
> handle mutiple local and/or network attached printers.
I've heard some good things about Citrix, but (no offense) there's still
no equality comparison between a microcomputer and a mainframe, even an
old mainframe...
(circa 1980)
IBM 360/148 with IIRC 512K (maybe 256) of core memory, running a couple
hundred terminals (under VIDEO subsystem), CICS (another 30 terminals),
RJE-SPF, another 25 terminals for developers, a big printer, 3 or 4
little printers, a couple card readers, a card puncher, 10-12 disk
drives and half a dozen tape drives.
rpl
Morten Reistad
If you compare with a 360/195 I gather using a PC server is a fair
comparison. I would doubt very much that a 360/195 ever was installed
as a personal machine; such as a lot of 1130's were. Some 360/40's may
have been run as standalone, personal machines; but I doubt they
many.
-- mrr
rpl
370/148 256K
370/168 512K
rihgt?
rpl
jmfb...@aol.com
>
>> If today's PCs are toys, it isn't the fault of the *hardware*.
>
>Certainly the CPUs are very much faster than the old S/360.
>However, IMHO, the PC hardware remains inferior to S/360.
>
>The big difference is how S/360 handled multi-programming,
>IMHO much better than a PC. The I/O was kept properly separated.
Which shows how much work is left to be done before PCs grow up.
<snip>
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
Peter...@Yahoo.com wrote:
>If it doesn't fill a room, it's a toy;-)
>
If it fills a room, it's a man's toy.
Steve O'Hara-Smith
jmfb...@aol.com wrote:
> In article <1114452644.3...@o13g2000cwo.googlegroups.com>,
> Peter...@Yahoo.com wrote:
> >If it doesn't fill a room, it's a toy;-)
> >
>
> If it fills a room, it's a man's toy.
If it fills a womb it's a woman's toy.
Steve O'Hara-Smith
jsa...@ecn.ab.ca wrote:
> PC-DOS may be an impostor compared to DOS/360, but today's PCs are not
> toys.
Well yes - but running PC-DOS on a modern PC is kinda silly.
jmfb...@aol.com
jmfb...@aol.com
And also prevents playing. Which prevents learning. Which prevents
producing useful stuff. I am looking forward to when most PCs
do become toys.
Roland Hutchinson
And running Windows isn't???
Anne & Lynn Wheeler
rpl <plinnan...@NOSPAMyahoo.com> writes:
> 370/148 256K
> 370/168 512K
lots of 370/148 were 512k and sometimes even a mbyte (memory
technology getting used was cheaper) and 370/168 wasn't unusual to
have 4mbytes.
i worked on microcode for virgil/tully (aka 138/148) associated with
the vm performance assist. another feature of 148 was that it had
significantly faster floating point than 145 ... and was targeted as
competitive machine in world trade markets against clone 370s.
recent posts mentioning 148 microcode assists
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
as part of the effort, i got to spend quite a bit of time running
around the world doing 138/148 business forcast analysis with various
organizations. There was some big difference between how the sales and
marketing business was done in the US and how sales and marketing
business was done in the rest of the world.
In the US, yearly business forcasts rolled up from the branch offices
to the regions and then to DP hdqtrs ... and that information was
provided to the manufactoring plants for resource and capacity
planning for the upcoming year. If sales business people were wrong,
the manufactoring plants were responsible for the difference.
In world trade, the country sales forcasts were basis for placing
orders with the manufactoring plants (each country bought machines
from manufactoring). The machines were then built and shipped to the
countries ordering them. If forcasts were too high ... the unsold
machines were on the books of the country that ordered them ... not on
the books of the manufactoring plant.
One of the things that became very apparent was the people doing sales
forcasts in world trade countries were quite a bit more dllligent than
the people doing sales forcasts in the US; aka in world trade their
jobs could ride on how accurate the forcasts were (since world trade
countries bought and carried the inventory corresponding to the sales
forcasts)).
In the US, since the forcasts were not held accountable against the
marketing/sales organization (i.e. manufactoring plants carried the
inventory not the sales organizaiton) ... there was much less
erquirement for accuracy in the forcasts. US sales forcasts tended to
be much more aligned with corporate strategic statements than possibly
with what they felt customers might actually be expected to buy. The
result was manufactoring tended to discount the accuracy of US sales
forcasts and tended to duplicate the forcasting effort for US sales
i.e. to try and come up with accurate numbers ... rather than numbers
that possibly tended to support the current corporate strategic
thinking.
Allodoxaphobia
rwong? -- unless _my_ bitrot is as severe as yours. :-)
T'wern't any Sys/370 148's. The 145 had a DAT box from Day 1,
and that model number endured.
Jonesy
--
| Marvin L Jones | jonz | W3DHJ | linux
| Gunnison, Colorado | @ | Jonesy | OS/2 __
| 7,703' -- 2,345m | config.com | DM68mn SK
spam-e...@the-shredder.invalid
wrote:
>On Tue, 26 Apr 2005 05:10:26 -0400, rpl wrote:
>> gotta do something about bitrot...
>>
>> 370/148 256K
>> 370/168 512K
>>
>> rihgt?
>
> rwong? -- unless _my_ bitrot is as severe as yours. :-)
>T'wern't any Sys/370 148's. The 145 had a DAT box from Day 1,
>and that model number endured.
Looks like you've got some bitro then. 370/135 and 370/145 had no
"DAT box" and were not field upgradeable (by IBM) . They were
replaced with 370/138 and 370/148. The 370/155 and 370/165 were
upgradeable with DAT box by IBM, but for new purchase 370/158 and
370/168 were available.
See http://www.thegalleryofoldiron.com/ for 135, 138, 145 and 148.
--
anton
Jay Maynard
> On 26 Apr 2005 17:11:49 GMT, Allodoxaphobia <bit-b...@config.com>
> wrote:
>> rwong? -- unless _my_ bitrot is as severe as yours. :-)
>>T'wern't any Sys/370 148's. The 145 had a DAT box from Day 1,
>>and that model number endured.
> Looks like you've got some bitro then. 370/135 and 370/145 had no
> "DAT box" and were not field upgradeable (by IBM) . They were
> replaced with 370/138 and 370/148. The 370/155 and 370/165 were
> upgradeable with DAT box by IBM, but for new purchase 370/158 and
> 370/168 were available.
You're both right. The 370/135 and /145 had DAT built in, with no need for
an additional box to provide the functionality. There were indeed /138 and
/148 follow-on systems, but the difference was mainly speed. The /155 and
/165 needed a DAT box to do virtual addressing, and, IIRC, they were
standard on the /155-II and /165-II. The /158 and /168, as you say, did come
with it built in.
Anne & Lynn Wheeler
> rwong? -- unless _my_ bitrot is as severe as yours. :-) T'wern't
> any Sys/370 148's. The 145 had a DAT box from Day 1, and that model
> number endured.
(customer) 145s had DAT from day 1 ... but it wasn't enabled until
virtual memory was announce (at which time, the 145s got new microcode
loads to enable virtual memory). the 145s did have front panel with
lots of lights and "rollers" with crypted designation about the
meanings of the lights. all 145s shipped to customers had the physical
rollers ... and included a "xlat" designation for one of the lights.
this resulted in some speculation in the press prior to 370 virtual
memory announcement.
165s had to have (fairly large) hardware retrofit in the field.
138, 148, 158, and 168s were all new technology and models to the
previous 135, 145, 155, and 165.
virgil/tully (138/148) besides being faster & typically more memory
than their predecessor ... had operating system microcode performance
assists (vs1 and vm) ... and the 148 had significantly faster floating
point than the 145 (much faster than the nominal overall speedup of
the 148 over the 145).
besides ecps project mentioned in previous postings
http://www.garlic.com/~lynn/2005g.html#16 DOS/360: Forty years
http://www.garlic.com/~lynn/2005d.html#59 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005f.html#59 Where should the type information be: in tags and descriptors
the science center:
http://www.garlic.com/~lynn/subtopic.html#545tech
had an earlier joint project with endicott. this was to create
software virtual machine (cp67 running 360/67) that emulated the 370
architecture (including virtual memory), as oppsed to emulating 360/67
architecture. 370 architecture had some number of new instructions not
found in 360 ... and the virtual memory tables had a number of
differences from those defined in 360/67. this was running in regular
use at least a year before the first engineering 370/145 with virtual
memory was operational.
various past postings on cp67h & cp67i activities:
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post)
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and virtualization in general
http://www.garlic.com/~lynn/2005d.html#58 Virtual Machine Hardware
http://www.garlic.com/~lynn/2005d.html#66 Virtual Machine Hardware
Anne & Lynn Wheeler
> as part of the effort, i got to spend quite a bit of time running
> around the world doing 138/148 business forcast analysis with
> various organizations. There was some big difference between how the
> sales and marketing business was done in the US and how sales and
> marketing business was done in the rest of the world.
it turns out that i was doing virgil/tully (138/148) at about the
same time I was doing vamps
http://www.garlic.com/~lynn/subtopic.html#bounce
and the resource manager:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
there were some interesting strategic marketing meetings at various
locations that were looking at vamps vis-a-vis 148 (before vamps got
killed). to some extent they were targeted at the same market segment
and therefor were viewed was somewhat competitive. the strategic
marketing meetings were to look at which should be chosen (if
necessary) ... and so the meetings pitted the 148 in competition with
vamps. the problem in these meetings was that i had to fairly
represent both factions ... since i was doing a lot of work on both
products ... and would represent both products at such meetings (in
theory i was suppose to argue the pros & cons of both products with
myself).
Charlie Gibbs
(Eric Smith) writes:
> I'm not sure how much core this particular 360/30 has, but since it
> can't be more than 64KB,
Unless it has a third-party add-on. A PPOE rented time on a /30
with 128K, although the switches and indicators for the extra
memory had a bit of a home-brewed look.
Companies like Greyhound bought up 360/30s that came off lease,
refurbished them, and leased them out to companies who didn't
want to make the jump to the 370 line. IIRC they were hanging
as much as 512K on them.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charlie Gibbs
(jmfbahciv) writes:
> In article <20050426120655....@eircom.net>,
> Steve O'Hara-Smith <ste...@eircom.net> wrote:
>
>> On 25 Apr 2005 10:40:08 -0700
>> jsa...@ecn.ab.ca wrote:
>>
>>> PC-DOS may be an impostor compared to DOS/360, but today's PCs
>>> are not toys.
>>
>> Well yes - but running PC-DOS on a modern PC is kinda silly.
The same could be said about Windows.
> And also prevents playing.
You really need a front panel. You can play so much better with
a front panel.
> Which prevents learning.
I'm willing to believe you when you say that there are people
who want to learn. But a depressing majority doesn't want to
"waste" their time learning - they just want to know which button
to press to do the thing they want Right Now.
> Which prevents producing useful stuff.
A lot of today's software is a sad example of this.
> I am looking forward to when most PCs do become toys.
In one sense, at least. On the other hand, I'm looking forward
to when they _stop_ being toys and become useful tools. This
will require a change in the mindset of users, which will in
turn drive software developers to provide those tools. (They
are capable of doing so now, but they need incentive.)
Henk Stegeman
Please see: http://www.piercefuller.com/library/ibmdos.html?id=ibmdos
Regards Henk Stegeman
Eric Smith <er...@brouhaha.com> wrote in message news:<qhd5sif...@ruckus.brouhaha.com>...
Anne & Lynn Wheeler
> 370/148 256K
> 370/168 512K
for a little more topic drift ... look at the
definition for "remap" in this copy of ibm jargon:
http://www.212.net/business/jargonr.htm
hanc...@bbs.cpcn.com
Eric Smith wrote:
> I'm not sure how much core this particular 360/30 has, but since it
> can't be more than 64KB, I'm guessing that there weren't too many
> choices for operating systems for it. Was there anything other than
> BOS, TOS, or DOS?
Why couldn't it be more than 64k? Was that all the /30 could
hold? I would presume at least 128. Our 40 could hold up to 256k
(we had 192). We had to put another box on it, but nothing else.
As to operating systems, that's it. You probably would be best
with DOS for fastest performance. IIRC, supposedly OS/PCP
greatly scaled down would work, but not really in practice.
> The museum has some 2311 disk drives and some 24xx tape drives with
it,
> but it appears that the control units for those are not present.
> I hope that we can find suitable control units, but if not, at least
> the channel interface is very well documented, so as a last resort
> we could either try to use more modern channel devices, or engineer
> new peripherals with channel interfaces. It would be amusing to use
> a tiny little SD card as a DASD on the 360.
As a former S/360 user, at first I would love the idea of key-
punching a COBOL program, zipping it through the reader, and
watching the tapes and 1403 printer fly by. But then, I must
admit, reality sets in. (Just as it does when I use a typewriter).
An 029 doesn't have a cursor backspace. It doesn't show a screen
of cards and easily correct them all, but one card at a time with
hard to read writing. The special chars were in weird places.
If I leave out a comma, I still have to wait for a whole compile
to be run and printed just to learn that. Today I wait seconds
and look at the results on my screen. I think my patience would
run out quickly doing as was done in the past.
Running compiles and tests went through a lot of paper and
cards. Keeping the 1403 going will be costly.
Jay Maynard
> on a 360/30? The Computer History Museum has a 360/30. It is not
> currently operational, and there are currently no official (or even
> unofficial) plans to restore it, but I'm hoping that someday we can do
> it.
I'd love to see a 360 run.
As Henk noted, DOS/360 (and TOS/360, too) exist today, and there's a small
but dedicated group of folks using it with Hercules.
>> I'm not sure how much core this particular 360/30 has, but since it
>> can't be more than 64KB, I'm guessing that there weren't too many
>> choices for operating systems for it. Was there anything other than
>> BOS, TOS, or DOS?
I suppose you could run a very small OS/360 PCP configuration on it, and a
hydraulic ram could stuff a one- or two-partition MFT into it, but I would
expect it to run very, very, very slowly.
>> The museum has some 2311 disk drives and some 24xx tape drives with it,
>> but it appears that the control units for those are not present.
>> I hope that we can find suitable control units, but if not, at least
>> the channel interface is very well documented, so as a last resort
>> we could either try to use more modern channel devices, or engineer
>> new peripherals with channel interfaces. It would be amusing to use
>> a tiny little SD card as a DASD on the 360.
The problem is that you'd have to modify DOS/360 to recognize and deal with
the more modern devices. I doubt DOS/360 could even use 3330s, let alone
anything modern. You'd have to develop a replacement for the controller -
but I can't tell from the online stuff if the 2311 *had* a seprate
controller, or if it was built into the box. (It was on the 2314.) If you
don't have a 2803 or 2804 tape controller, you'll have to develop one of
those too, and that might get Really Interesting.
Kevin G. Rhoads
Not if you want to work with floppies. NT-ish OSes can't deal with
many floppy formats, so-called formatting under those OSes is a horror,
and if there are any bad sectors, forget it. At least under PC-DOS, MS-DOS,
FreeDOS, DR-DOS or some such, you have a fighting chance of reading data
off old floppies.
Anne & Lynn Wheeler
and a small sample of 148s on the internal network:
REKVM1 * RESPOND/2 148/VM EMEA Reykjavik,Iceland 354-1-27700x25
TUCVMJ * TUCVMI/5 148/VM GPD Tucson, Arizona 8-562-7100
BOEVM13 * BOEVM4/9 148/VM EMEA Boeblingen,Ger. 49-7031-16-8903
spam-e...@the-shredder.invalid
<jmay...@thebrain.conmicro.cx> wrote:
[snip]
>The problem is that you'd have to modify DOS/360 to recognize and deal with
>the more modern devices. I doubt DOS/360 could even use 3330s, let alone
>anything modern. You'd have to develop a replacement for the controller -
>but I can't tell from the online stuff if the 2311 *had* a seprate
>controller, or if it was built into the box. (It was on the 2314.) If you
>don't have a 2803 or 2804 tape controller, you'll have to develop one of
>those too, and that might get Really Interesting.
The 2311 required 2841 control unit which had to be connected on /360
selector channel.
--
anton
arargh5...@now.at.arargh.com
<jmay...@thebrain.conmicro.cx> wrote:
<snip>
>>> The museum has some 2311 disk drives and some 24xx tape drives with it,
>>> but it appears that the control units for those are not present.
>>> I hope that we can find suitable control units, but if not, at least
>>> the channel interface is very well documented, so as a last resort
>>> we could either try to use more modern channel devices, or engineer
>>> new peripherals with channel interfaces. It would be amusing to use
>>> a tiny little SD card as a DASD on the 360.
>
>The problem is that you'd have to modify DOS/360 to recognize and deal with
>the more modern devices. I doubt DOS/360 could even use 3330s, let alone
>anything modern. You'd have to develop a replacement for the controller -
>but I can't tell from the online stuff if the 2311 *had* a seprate
>controller, or if it was built into the box. (It was on the 2314.) If you
>don't have a 2803 or 2804 tape controller, you'll have to develop one of
>those too, and that might get Really Interesting.
And where are you going to find CKD drives? Maybe old MFM or ESDI
drives could be used that way. :-)
--
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Eric Smith
> Unless it has a third-party add-on. A PPOE rented time on a /30
> with 128K, although the switches and indicators for the extra
> memory had a bit of a home-brewed look.
>
> Companies like Greyhound bought up 360/30s that came off lease,
> refurbished them, and leased them out to companies who didn't
> want to make the jump to the 370 line. IIRC they were hanging
> as much as 512K on them.
I've heard of that before. Must have been an amazing hack, since the
hardware and microcode of the 360/30 are completely designed around use
of 16-bit addresses.
Eric
Eric Smith
> The museum has some 2311 disk drives and some 24xx tape drives with it,
> but it appears that the control units for those are not present.
> I hope that we can find suitable control units, but if not, at least
> the channel interface is very well documented, so as a last resort
> we could either try to use more modern channel devices, or engineer
> new peripherals with channel interfaces. It would be amusing to use
> a tiny little SD card as a DASD on the 360.
Jay Maynard <jmay...@thebrain.conmicro.cx> writes:
> The problem is that you'd have to modify DOS/360 to recognize and deal with
> the more modern devices. I doubt DOS/360 could even use 3330s, let alone
> anything modern.
I thought the newer DASD controls used a superset of the channel commands
of the older ones?
> but I can't tell from the online stuff if the 2311 *had* a seprate
> controller, or if it was built into the box. (It was on the 2314.)
AFAICT, it needed a 2841 storage control unit, which was also used for
the 2303 drum, 2302 disk, or 2321 data cell.
> If you don't have a 2803 or 2804 tape controller,
Speaking of which, what is the difference between the 2803 and 2804?
Eric
Eric Smith
> Why couldn't it be more than 64k? Was that all the /30 could
> hold?
Yes, that's the maximum. The 2030 address paths only have 16 bits.
> I would presume at least 128. Our 40 could hold up to 256k
> (we had 192). We had to put another box on it, but nothing else.
I'm not sure what the hardware limitation of the 2040 was, but 256K
wouldn't be surprising.
Eric
Allodoxaphobia
Remember the Itel debacle? _That_ definitely did _not_ help my
retirement nest egg.
Peter Flass
>
> Please see: http://www.piercefuller.com/library/ibmdos.html?id=ibmdos
>
Wow! That's one I missed. Thanks.
Lawrence Greenwald
Jay Maynard <jmay...@thebrain.conmicro.cx> wrote:
I don't know if it would work on a /30, but you might consider an
alternative - Software Pursuits had a modified DOS/VSE called MVT/VSE -
it's DOS/VS but behaves more like OS/MVT (not sure about this).
Don't know if it still exists, or if it would run on the older /30.
--LG
Lawrence Greenwald
Allodoxaphobia <bit-b...@config.com> wrote:
> On Tue, 26 Apr 2005 05:10:26 -0400, rpl wrote:
> > gotta do something about bitrot...
> >
> > 370/148 256K
> > 370/168 512K
> >
> > rihgt?
>
> rwong? -- unless _my_ bitrot is as severe as yours. :-)
> T'wern't any Sys/370 148's. The 145 had a DAT box from Day 1,
> and that model number endured.
>
> Jonesy
Oh yes, there were 370/148s. Looked like the 158.
No flashing lights and a 3270 replaced the 3210/3215 console.
--LG
Rich Alderson
> The very fact that someone can seriously regard Word 6 as relatively
> bloat-free itself speaks volumes about our current expectations and
> tolerance level for bloat.
Indeed. I remember an April issue of BYTE in the late 80s (early 90s?) that
showed a mock-up of the screen for a far-future version of Word (say year 2000
or the like); imagine my dismay a few months later when the BYTE review of a
new version of Word showed a screen shot that was more crowded than their worst
nightmare had been. :-(
--
Rich Alderson | /"\ ASCII ribbon |
ne...@alderson.users.panix.com | \ / campaign against |
"You get what anybody gets. You get a lifetime." | x HTML mail and |
--Death, of the Endless | / \ postings |
Mike Ross
Beg to differ; the 148 did have fairly minimal blinkenlights:
http://www.thegalleryofoldiron.com/370_148_OPEN.JPG
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Anne & Lynn Wheeler
> Oh yes, there were 370/148s. Looked like the 158.
>
> No flashing lights and a 3270 replaced the 3210/3215 console.
here is 145 (although not very good closeup of front panel)
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH3145.html
and 148
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_2423PH3148.html
from the "mainframe photo album"
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_album.html
some 370 machine characteristics
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS370B.html
370 announce & shiip dates
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS370.html
note in the above ... there possibly is some problem with 145 & 145-3
dates. first it claims that 145 was "withdrawn" only a couple months
after it started shipping. also the 145-3 date shows it was announced
on the same date as the 148.
this has somewhat more consistant dates for 145 (although the site it
was taken from no longer seems to have the information available)
http://www.garlic.com/~lynn/99.html#209
it does say virtual memory was announced for 370 8/72 and shipped
8/73. also that the 135-3 & 145-3 were announce on 8/72 also and
shipped 8/73. They do appear to have some gotchas ... with some of the
boxes and/or software associated with virtual memory available prior
to 8/73 (that virtual memory supposedly was available) .... "virtual
storage" (the name at the time for virtual memory) would be prereq for
any software that used virtual storage. Also 158 had virtual memory
... and so couldn't ship before virtual memory was officially
available.
this reference has a lot of dates ... but also some inconsistancies
with 145 & 148:
http://www2.marist.edu/~vmshare/browse?fn=IBMHIST&ft=NOTE&args=4341
some 370 machine characteristics are here:
http://www.beagle-ears.com/lars/engineer/comphist/model360.htm
some ibm dates from 1964-1974 (with a lot of other dates)
http://febcm.club.fr/english/information_technology/information_technology_3.htm
Steve O'Hara-Smith
"Kevin G. Rhoads" <kgrh...@alum.mit.edu> wrote:
> > Well yes - but running PC-DOS on a modern PC is kinda silly.
>
> Not if you want to work with floppies. NT-ish OSes can't deal with
> many floppy formats, so-called formatting under those OSes is a horror,
I've never had trouble reading floppies with FreeBSD - except
when I discovered that the floppy drive had died in the years since it
was used :)
Steve O'Hara-Smith
Roland Hutchinson <my.sp...@verizon.net> wrote:
> Steve O'Hara-Smith wrote:
>
> > On 25 Apr 2005 10:40:08 -0700
> > jsa...@ecn.ab.ca wrote:
> >
> >> PC-DOS may be an impostor compared to DOS/360, but today's PCs are not
> >> toys.
> >
> > Well yes - but running PC-DOS on a modern PC is kinda silly.
>
> And running Windows isn't???
Running Windows is always silly - but sometimes unavoidable.
Running modern Windows on an old PC is *really* silly :)
--
Must restore sig.
Kevin G. Rhoads
I've heard that it is possible to squeeze a useable Linux or FreeBSD install onto
a single HD floppy which can be booted, but I don't know how to do it. Nowadays
when you can boot from a CD on so many systems, I suppose it is less a concern,
but for decades, being able to boot some form of x86 DOS from a floppy has been
incredibly useful to me -- not to mention that I can get working installs of
QPRO for DOS, MS Fortran 5.1 and WordPerfect 5.1 each on a single HD floppy --
four floppies and I can boot, wordprocess, number crunch and compile all without
needing to "install" anything on a HD -- there were several years when I was consulting
where I found that incredibly useful.
Just as work expands to fill the time available to it, computer programs seem to
expand to fill the resources (RAM, processor bandwidth &c) available to them. Whether
we talk of DOS/360 or PC-DOS, those days of lean, mean programming are (unfortunately,
to my mind) pretty much long gone. Yeah, a few embedded systems things are still resource
parsimonious, but that's the exception not the rule. It can be nice at times to have
fancy, resource rich (and resource hogging) systems -- but I don't want to never have the
choice ... and, dang, if it don't feel like that's the way we's agoin'
And having just turned 54, it is nearly 40 years I've been programming. At least I
still get to do some embedded systems stuff as well as bloatware coding. These
days much of the time you can't even justify coding one-of number crunches in Fortran much
of the time, incstead use IDL or a spreadsheet or Octave or somesuch.
Too many newbies who never experienced the feeling of unlimited freedom that coding into
64k (of 60 bit words) on a CDC-6400 or 512k on a 360/65 or even the relative spaciousness
of 16k (12 bit words) on a PDP-8 (it has been too long, I've forgotten the RIM loader, I
nearly lost my green card (and, yes, I have one of the old *green* ones))
(and it was uphill both ways to and from school, in the snow, and we had no zeroes and
had to use "O"s and we cut our paper tapes and unit records with pocket knives, ...)
Rob Warnock
+---------------
| Unfortunately, as PCs have grown in size and horsepower, their
| operating systems have grown along with them. It frustates me
| to no end that my home PC--an old Pentium 120 is faster than my
| work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
| on the work unit. I try to use older MS programs (ie Word 6.0
| instead of Word 2000) because they run so much faster and don't
| have unnecessary bloat.
+---------------
I have a 33 MHz '486 with only 32 MB of RAM at home that is
perfectly happy running a relatively-recent FreeBSD. And it
almost *never* crashes, either!!
slow% w
3:57AM up 861 days, 22:06, 1 user, load averages: 0.15, 0.03, 0.01
USER TTY FROM LOGIN@ IDLE WHAT
rpw3 p0 fast 3:57AM - w
slow%
Yes, that "861 days" is no lie!! That's exactly how long it's
been since I installed the small UPS in my home office... ;-} ;-}
My main web/mail/DNS server (also running FreeBSD) is an el-cheapo
Athlon XP 1600+ (1.4 GHz) desktop that's been up for "only" 250 days
[since the last major system software upgrade]...
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Steve O'Hara-Smith
"Kevin G. Rhoads" <kgrh...@alum.mit.edu> wrote:
> >I've never had trouble reading floppies with FreeBSD
>
> I've heard that it is possible to squeeze a useable Linux or FreeBSD install onto
> a single HD floppy which can be booted, but I don't know how to do it.
For minimal values of useable - yes. OTOH it's on the hard disc of
almost all my boxes.
> Nowadays
> when you can boot from a CD on so many systems, I suppose it is less a concern,
Yes a useable CD booting live system is easy.
> but for decades, being able to boot some form of x86 DOS from a floppy has been
> incredibly useful to me -- not to mention that I can get working installs of
> QPRO for DOS, MS Fortran 5.1 and WordPerfect 5.1 each on a single HD floppy --
> four floppies and I can boot, wordprocess, number crunch and compile all
Heh - you're reminding me of the floppy based C development system I
used to carry around - one to boot and hold sources and objects, one to
install editing tools into a RAMdisc and the third to hold the compiler.
> And having just turned 54, it is nearly 40 years I've been programming.
I'm just a youngster with those age digits reversed and a mere
three decades of programming under my belt.
> (and it was uphill both ways to and from school, in the snow, and we had no zeroes and
> had to use "O"s and we cut our paper tapes and unit records with pocket knives, ...)
You had pocket knives! you were lucky we had to use pointy sticks
sharpened on the pavement.
Steve O'Hara-Smith
rp...@rpw3.org (Rob Warnock) wrote:
> <hanc...@bbs.cpcn.com> wrote:
> +---------------
> | Unfortunately, as PCs have grown in size and horsepower, their
> | operating systems have grown along with them. It frustates me
> | to no end that my home PC--an old Pentium 120 is faster than my
> | work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
> | on the work unit. I try to use older MS programs (ie Word 6.0
> | instead of Word 2000) because they run so much faster and don't
> | have unnecessary bloat.
> +---------------
>
> I have a 33 MHz '486 with only 32 MB of RAM at home that is
> perfectly happy running a relatively-recent FreeBSD. And it
> almost *never* crashes, either!!
Now try using KDE or OpenOffice[1] on it - for that matter try
building either of them :)
Still it is nice that the unnnecessary bloat is only in the
optional applications and not in OS.
[1] OK I confess I wouldn't use them even on my AMD64 box let alone the
older boxes :)
jmfb...@aol.com
You had pavement?
/BAH
Subtract a hundred and four for e-mail.
jmfb...@aol.com
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>In article <xr-dnWH1XZo...@rcn.net>, jmfb...@aol.com
>(jmfbahciv) writes:
>
>> In article <20050426120655....@eircom.net>,
>>> jsa...@ecn.ab.ca wrote:
>>>
>>>> PC-DOS may be an impostor compared to DOS/360, but today's PCs
>>>> are not toys.
>>>
>>> Well yes - but running PC-DOS on a modern PC is kinda silly.
>
>
>> And also prevents playing.
>
>You really need a front panel. You can play so much better with
>a front panel.
Oh, definitely. Getting instant _physical_ feedback teaches
how a real computer works. Just seeing little picture on
a TV gives no feel to the computing. I also would prefer
the toy to be slow in today's terms. People aren't learning
that electricity is slow and not an instantaneous form of
comm.
<snip>
Joe Morris
>hanc...@bbs.cpcn.com writes about the 360/30 memory size limit:
>> I would presume at least 128. Our 40 could hold up to 256k
>> (we had 192). We had to put another box on it, but nothing else.
Interesting; I don't recall ever hearing of a GF model. Was this an RPQ?
>I'm not sure what the hardware limitation of the 2040 was, but 256K
>wouldn't be surprising.
Right (at least according to my memory); 256K was the H model. My PPOE
ran a 2040G (128K) for three years; I'm still impressed at how
tightly we were able to pack MFT to give us a batch partition plus
an 18K (later 16K after release 14's nucleus grew by 2K) utility
partition that we used to process SYSIN/SYSOUT tapes for a 7040...and
still be able to run FORTRAN G. (The only compiler we couldn't run
in the 86K partition was FORTRAN H.)
Joe Morris
Barry
> Peter...@Yahoo.com wrote, in
> <1114449488.2...@l41g2000cwc.googlegroups.com>:
>
>
>
> DOS was a johnny-come-lately, real men ran their /30s on BOS.
I remember calling it COS, for "Card Operating System."
Barry in Indy
Patrick Scheible
> <hanc...@bbs.cpcn.com> wrote:
> +---------------
> | Unfortunately, as PCs have grown in size and horsepower, their
> | operating systems have grown along with them. It frustates me
> | to no end that my home PC--an old Pentium 120 is faster than my
> | work PC (Pentium 4 1.5 GHz) because of the bloated junk loaded
> | on the work unit. I try to use older MS programs (ie Word 6.0
> | instead of Word 2000) because they run so much faster and don't
> | have unnecessary bloat.
> +---------------
>
> I have a 33 MHz '486 with only 32 MB of RAM at home that is
> perfectly happy running a relatively-recent FreeBSD. And it
> almost *never* crashes, either!!
>
> slow% w
> 3:57AM up 861 days, 22:06, 1 user, load averages: 0.15, 0.03, 0.01
> USER TTY FROM LOGIN@ IDLE WHAT
> rpw3 p0 fast 3:57AM - w
> slow%
>
> Yes, that "861 days" is no lie!! That's exactly how long it's
> been since I installed the small UPS in my home office... ;-} ;-}
When I see uptimes like that, I always wonder how you blow the dust
out of the case with the computer still up. The computers in our
house get horribly dusty if I don't blow them out with a can of
compressed air at least once a year or so.
-- Patrick
Henk Stegeman
I was ever told by an old CE that there was a oem solution to go to
128k
(adding an extra MSB bit) on the /30, but I never found any other
source that could confirm this.
Regards Henk
Stan Barr
I opened the case of this Dell a few weeks back, the last time was
nearly two years before. It looked tile it was fur lined! :-)
I'd heve long uptimes too if I had a UPS or I didn't keep tripping the
circuit-breaker while messing about with stuff :-)
63 days since the last faux pas...
--
Cheers,
Stan Barr stanb .at. dial .dot. pipex .dot. com
(Remove any digits from the addresses when mailing me.)
The future was never like this!
Walter Bushell
Rich Alderson <ne...@alderson.users.panix.com> wrote:
> Roland Hutchinson <my.sp...@verizon.net> writes:
>
> > The very fact that someone can seriously regard Word 6 as relatively
> > bloat-free itself speaks volumes about our current expectations and
> > tolerance level for bloat.
>
> Indeed. I remember an April issue of BYTE in the late 80s (early 90s?) that
> showed a mock-up of the screen for a far-future version of Word (say year
> 2000
> or the like); imagine my dismay a few months later when the BYTE review of a
> new version of Word showed a screen shot that was more crowded than their
> worst
> nightmare had been. :-(
It is 5 years later. But life does catch up with satire.
--
Guns don't kill people; automobiles kill people.
Stan Barr
>
>I opened the case of this Dell a few weeks back, the last time was
>nearly two years before. It looked tile it was fur lined! :-)
I don't know how I managed to type that instead of "like"!
Put it down to suffering from the pain of a cortisone injection in my
left hand earlier today, it's still *&%$! painful :-(
Eric Sosman
Stan Barr wrote:
> On 27 Apr 2005 18:18:33 GMT, Stan Barr <sta...@dial.pipex.com> wrote:
>
>>I opened the case of this Dell a few weeks back, the last time was
>>nearly two years before. It looked tile it was fur lined! :-)
>
> ^^^^
>
> I don't know how I managed to type that instead of "like"!
> Put it down to suffering from the pain of a cortisone injection in my
> left hand earlier today, it's still *&%$! painful :-(
And here I'd assumed you'd somehow reverted to EBCDIC,
and then fed the card upside-down and wrong edge first ...
Lawrence Greenwald
Mike Ross <mi...@corestore.org> wrote:
Yeah, you're right. Saw the pics at old iron gallery site. I do know the
158 (which I thought was neat looking) went away from the wall of
blinking lights that a /155 had.
--LG
Charlie Gibbs
(jmfbahciv) writes:
It was so hard to get keypunch time that I fantasized about
grinding one of my teeth to the shape of an 80-column punch
so I could chew holes in cards.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
jmfb...@aol.com
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>In article <eoadnZqXN9D...@rcn.net>, jmfb...@aol.com
>(jmfbahciv) writes:
>
>> In article <20050427122650....@eircom.net>,
>> Steve O'Hara-Smith <ste...@eircom.net> wrote:
>>
>>> On Wed, 27 Apr 2005 10:33:04 +0000
>>> "Kevin G. Rhoads" <kgrh...@alum.mit.edu> wrote:
>>>
>>>> (and it was uphill both ways to and from school, in the snow, and
>>>> we had no zeroes and had to use "O"s and we cut our paper tapes
>>>> and unit records with pocket knives, ...)
>>>
>>> You had pocket knives! you were lucky we had to use pointy
>>> sticks sharpened on the pavement.
>>
>> You had pavement?
>
>It was so hard to get keypunch time that I fantasized about
>grinding one of my teeth to the shape of an 80-column punch
>so I could chew holes in cards.
>
peon. :-))) You get to play without having all of those
responsibilities.
sqrfolkdnc
from 64K to 128K. It did not work well (the system crashed several
times per day) and was removed after a few weeks, and was replaced with
a model 40.
IIRC, the benchmarks on the upgraded /30 also showed it was a little
slower. We ran check sorters so we needed the max speed we could get
out of the /30. Once the check started moving, you could not stop it,
and you had ony so many milliseconds to read and select which pocket to
route the check to.
What about BPS? I think it was less than BOS. IIRC, I loaded BPS,
then loaded an emulator program (all on cards) and could run TWO 1401
microcode based emulations on a 32K 360/30. The BPS and 360 program
handled the time sharing between the two 1401 emulations. That was
needed after DOS grew 2K and the emulator program we ran all day under
DOS would no longer fit to allow running 1401 programs under DOS batch.
Anne & Lynn Wheeler
> What about BPS? I think it was less than BOS. IIRC, I loaded BPS,
> then loaded an emulator program (all on cards) and could run TWO 1401
> microcode based emulations on a 32K 360/30. The BPS and 360 program
> handled the time sharing between the two 1401 emulations. That was
> needed after DOS grew 2K and the emulator program we ran all day under
> DOS would no longer fit to allow running 1401 programs under DOS batch.
the univ. had a 709 with a 1401 doing ur<->tape front-end with program
deck called MPIO. the univ. got a 360/30 replacing the 1401 (on its
way to getting a 360/67 replacing the 709).
They gave me a summer job writting MPIO program for 360/30 assembler.
I got to design/write my own storage manager, device drivers,
interrupt handler, task manager, etc. I did implementation with
conditional assembler test that did either DCBs and ran under os/360
... or a stand-alone version ... that you could load with the BPS
loader.
I would get the machine room for the weekend for development and test
(8am sat. until 8am monday). The program took nearly 30 minutes to
assemble (standalong version ... or around 50 minutes for the os/360
version ... each DCB macro taking approx. 5 minutes elapsed time to
process).
Before I learned that the BPS loader supported "REP" cards ... I
would do quicky program patches by repunching the "TXT" cards (along
the way, i had to learn to read punch-codes ... since there was no
character code for the hex printed at the top of the TXT decks).
misc. past references to BPS loader:
http://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would you ask?
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#26 HELP
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
http://www.garlic.com/~lynn/2002n.html#62 PLX
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002n.html#72 bps loader, was PLX
http://www.garlic.com/~lynn/2002n.html#73 Home mainframes
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#62 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
http://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
http://www.garlic.com/~lynn/2004b.html#33 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004f.html#11 command line switches [Re: [REALLY OT!] Overuse of symbolic
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
Eric Smith
> What about BPS? I think it was less than BOS. IIRC, I loaded BPS,
> then loaded an emulator program (all on cards) and could run TWO 1401
> microcode based emulations on a 32K 360/30.
Speaking of which, according to the 360/30 documentation there is a
card deck that has to be read to initialize the "bump" memory of the
processor for 1401 emulation to work. Does anyone still have a copy
of this deck? As I understand it, standard practice was to put a copy
of it in front of each 1401 program deck that was going to be used
routinely.
I don't yet know whether the 360/30 at the Computer History Museum
has the 1401 emulation option, but if it does, we'll definitely want
a copy of that card deck at some point.
Did the 360/30 1401 emulation feature include any extra hardware not
present without that option, aside from additional CCROS microcode?
What about the 1620 emulation option?
Eric
Joe Morris
>the univ. had a 709 with a 1401 doing ur<->tape front-end with program
>deck called MPIO. the univ. got a 360/30 replacing the 1401 (on its
>way to getting a 360/67 replacing the 709).
>They gave me a summer job writting MPIO program for 360/30 assembler.
>I got to design/write my own storage manager, device drivers,
>interrupt handler, task manager, etc. I did implementation with
>conditional assembler test that did either DCBs and ran under os/360
>... or a stand-alone version ... that you could load with the BPS
>loader.
I wonder how many shops reinvented that wheel. My PPOE had a 1401
running IOUP (Input/Output Utility Program) to process SYSIN/SYSOUT
tapes for our 7040 (IBSYS) system; by the time the 1401 finally left
one of our really great 1401 programmers had pretty much rewritten
it from scratch, producing LOUP (Louie's Own Utility Program) with
lots of bells and whistles.
When the 1401 was replaced with a 360/40 running MFT the sysprog
team wrote a utility that stayed active while batch jobs were
running (the equivalent of a TSR in PC-DOS terminology), complete
with a round-robin internal scheduler to allow simultaneous
tasks and centralized storage allocation. All sorts of hacks were
included, of course (this was in the 1967 time frame), but it
was stable and it worked.
Joe Morris
ly...@garlic.com
> I wonder how many shops reinvented that wheel. My PPOE had a 1401
> running IOUP (Input/Output Utility Program) to process SYSIN/SYSOUT
> tapes for our 7040 (IBSYS) system; by the time the 1401 finally left
> one of our really great 1401 programmers had pretty much rewritten
> it from scratch, producing LOUP (Louie's Own Utility Program) with
> lots of bells and whistles.
>
> When the 1401 was replaced with a 360/40 running MFT the sysprog
> team wrote a utility that stayed active while batch jobs were
> running (the equivalent of a TSR in PC-DOS terminology), complete
> with a round-robin internal scheduler to allow simultaneous
> tasks and centralized storage allocation. All sorts of hacks were
> included, of course (this was in the 1967 time frame), but it
> was stable and it worked.
there was share contributed program, LLMPS (lincoln labs
multiprogramming system) which was a lot of unit record and tape
applications (I have the share contribution document in a box
someplace).
lincoln labs was the 2nd installation after the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
to have cp67 running on 360/67.
the folklore is also that MTS (michigan terminal system) for 360/67
(and virtual memory support) start out with LLMPS at its core.
misc. past postings mentioning LLMPS
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#25 MTS & LLMPS?
http://www.garlic.com/~lynn/93.html#26 MTS & LLMPS?
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems
geneaology
http://www.garlic.com/~lynn/2000g.html#0 TSS ancient history, was X86
ultimate CISC? designs)
http://www.garlic.com/~lynn/2000.html#89 Ux's good points.
http://www.garlic.com/~lynn/2001m.html#55 TSS/360
http://www.garlic.com/~lynn/2001n.html#45 Valid reference on lunar
mission data being unreadable?
http://www.garlic.com/~lynn/2001n.html#89 TSS/360
http://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
http://www.garlic.com/~lynn/2002n.html#64 PLX
http://www.garlic.com/~lynn/2003f.html#41 SLAC 370 Pascal compiler
found
http://www.garlic.com/~lynn/2004d.html#31 someone looking to donate IBM
magazines and stuff
http://www.garlic.com/~lynn/2004l.html#16 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004o.html#20 RISCs too close to hardware?
hanc...@bbs.cpcn.com
Joe Morris wrote:
> Eric Smith <er...@brouhaha.com> writes:
>
> >hanc...@bbs.cpcn.com writes about the 360/30 memory size limit:
>
> >> I would presume at least 128. Our 40 could hold up to 256k
> >> (we had 192). We had to put another box on it, but nothing else.
>
> Interesting; I don't recall ever hearing of a GF model. Was this an
RPQ?
No. This happened in 1977 and our machine was a 3rd-party owned
lease, though we did contract to IBM for maintenance.
They (I think the leasing company) put on a big box (supposedly
built for a model 50) on the edge of the machine. We needed
another 64k (to go from 128 to 192) and that's what we got.
Initiallyt they wired it in wrong and the CPU 'thought' we had
256k and certain programs (like SORT which used all the core
available to it) fouled (they ran fine but the output was garbage).
I noticed the 256k reference in the COBOL compile and a screwed
up xref listing.
IBM was reportedly very upset with my employer when they ceased
renting directly from IBM and went to a 3rd party lease, but
apparently the cost savings were significant. Some of our
software was rented from IBM (such as the better COBOL [F?]
compiler instead of the 'default' one [D?].) But AFAIK most
of the systems and application software remained free (DOS/Rel 26) and
"SHAS", a hospital accounting system. I never understood why IBM
didn't charge us for all of the IBM software we were using since
we didn't rent the machine from them. Apparently IBM let a lot
of stuff become free.
We also had a card sorter. I never understood why they kept
that and pre-sorted certain input decks (for 1401 applications)
rather than sorting them within the computer. Maybe for 1401
stuff it was too cumbersome. I know emulated 1311 disks wasted
a heck of a lot of space on our 2314s.
We ran a batch background, "POWER" a spooler in one foreground,
and a cheapo imitation CICS (from IBM) in the other foreground.
I forgot the product name, but I remember the manual was
written in a very informal style which was strange for an IBM
publication.
The throughput improvement from the spooler was tremendous.
Almost all of our work didn't use many CPU cycles and was
limited by card reader and printer speed.
I made the mistake of developing a system using our two tapes.
Our 2415 was horribly slow. It annoyed me that only one tape
of the pair would run at a time, I couldn't understand why
there wasn't overlap and more buffering. In other words,
while it was writing a new record, why couldn't it be
simultaneously reading the next record.
(I understand today everything is a la carte and rather
expensive. My present employer would love to reduce the
many CA- products we rent but most are too deeply embedded
and conversion would be terribly costly. It was rough
just getting rid of old DYL260 and use only DYL280. We
also use Easytrieve and SAS. But we are a consolidation
of four once-independent data centers and each data center
had their own preferences for support software products.
Two were ROSCOE, one was VM/CP, one TSO, for example. They
wanted to dump VM, but again it was too embedded.)
John R. Levine
>> can't be more than 64KB, I'm guessing that there weren't too many
>> choices for operating systems for it. Was there anything other than
>> BOS, TOS, or DOS?
>
>Why couldn't it be more than 64k? Was that all the /30 could
>(we had 192). We had to put another box on it, but nothing else.
I happen to have a copy of the mod 30 functional characteristics manual
here. (At IBM some things never seem to go out of print.)
It is quite clear that the minimum storage on a /30 was 8K, and the
maximum was 64K. I would be surprised if you could get more even as
an RPQ since I think there were only 16 address lines.
Lawrence Wilkinson
> It is quite clear that the minimum storage on a /30 was 8K, and the
> maximum was 64K. I would be surprised if you could get more even as
> an RPQ since I think there were only 16 address lines.
I don't think this was ever an IBM item.
There is effectively a 17th address line in the Main/Local storage
selection (Local storage was for the registers and multiplexor channel
state ). Since the Local 'bump' storage used a few kB, this might
explain why you could only have 96k and not 128k (but maybe there was no
physical space for more).
I doubt that the 96k was directly addressable, this would have been too
major a change to the microcode and other hardware, but maybe they
modified the address wrap handler to do a sort of page fault. It was
probably just bank switched into the top 32k.
I would be interested in knowing what software support there was for
this, but it was probably relatively simple to implement as a separate
partition.
Ok, now someone can tell me I've got it all wrong!
--
Lawrence Wilkinson lawr...@ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
Joe Morris
>IBM was reportedly very upset with my employer when they ceased
>renting directly from IBM and went to a 3rd party lease, but
>apparently the cost savings were significant. Some of our
>software was rented from IBM (such as the better COBOL [F?]
>compiler instead of the 'default' one [D?].)
Can't be either one: neither the F or D versions of the COBOL
compiler were ever "rented" -- for that matter, neither one
was even copyrighted.
Other than a few specialized applications, the majority of software
packages written by IBM were available at no charge to IBM customers,
and non-IBM customers could either get copies from other shops, or
pay for the reproduction costs and get them from IBM. All this
changed, of course, with New World (June 1969), but that didn't
alter the status of products relased prior to that date.
> But AFAIK most
>of the systems and application software remained free (DOS/Rel 26) and
>"SHAS", a hospital accounting system. I never understood why IBM
>didn't charge us for all of the IBM software we were using since
>we didn't rent the machine from them. Apparently IBM let a lot
>of stuff become free.
See the above: pre-New World, for most software IBM didn't charge
anyone.
>We also had a card sorter. I never understood why they kept
>that and pre-sorted certain input decks (for 1401 applications)
>rather than sorting them within the computer. Maybe for 1401
>stuff it was too cumbersome. I know emulated 1311 disks wasted
>a heck of a lot of space on our 2314s.
I never worked with the 1401 emulator; how did the emulated 1311s
map to a 2314? I do recall (under OS/360) needing to recover files
from a DASDR dump of a 2311, and did so by restoring the 2311 image
to the 2314, then under OS/360 patching the device characteristics to
match the 2311's geometry. This wasted a lot of space, but needed
to persist only long enough for me to copy the files onto a normal
2314.
>I made the mistake of developing a system using our two tapes.
>Our 2415 was horribly slow.
You are being *FAR* too kind to the 2415. It was, of course, the
S/360 version of the 7330 tape drive, which was
Umm...perhaps I shouldn't use the words that truly describe the
7330 or 2415 in a family newsgroup.
> It annoyed me that only one tape
>of the pair would run at a time, I couldn't understand why
>there wasn't overlap and more buffering. In other words,
>while it was writing a new record, why couldn't it be
>simultaneously reading the next record.
That's an issue with the channel architecture. A tape drive
would be placed on a selector channel, which permitted only
a single operation to be active. Once something causes I/O
to start on a selector, no other I/O operation can be started
until the first has terminated and the trailing interrupts
serviced. Assuming that your two tape drives were on the same
control unit and channel, in this case your problem isn't the
tape drives' fault.
Joe Morris
hanc...@bbs.cpcn.com
Joe Morris wrote:
> Can't be either one: neither the F or D versions of the COBOL
> compiler were ever "rented" -- for that matter, neither one
> was even copyrighted.
It's been a long time, but my recollection was that the
"better" COBOL compiler was rented for a nominal fee from
IBM. I think I saw it listed on the monthly invoice.
This was in 1976 and using a machine from a 3rd party lease.
> All this
> changed, of course, with New World (June 1969), but that didn't
> alter the status of products relased prior to that date.
I don't understand why IBM didn't start charging for software
after June 1969 for older stuff.
> I never worked with the 1401 emulator; how did the emulated 1311s
> map to a 2314?
Unfortunately my memory is vague on that. It was pretending
to be a 1311--did that hold 2 Meg? I think they may have put
the equivalent of four 1311s on one 2314. That was still inefficient
because you used 8 Meg (4x2) on a 29 Meg diskpack. (Even if
the 1311 held 4 meg it was still 16 meg on a 29 meg pack).
We had a called routine (DAMCOM?) that allowed modern COBOL
programs to read 1401 files. Some systems became a mix of
1401 and COBOL.
1401 stuff ran slow. The patient billing system (an IBM
product) was pretty sophisticated though, esp given it was
written for 16k.
> Umm...perhaps I shouldn't use the words that truly describe the
> 7330 or 2415 in a family newsgroup.
Glad I'm not the only one who feels that way.
> > It annoyed me that only one tape
> >of the pair would run at a time, I couldn't understand why
> >there wasn't overlap and more buffering. In other words,
> >while it was writing a new record, why couldn't it be
> >simultaneously reading the next record.
>
> That's an issue with the channel architecture. A tape drive
> would be placed on a selector channel, which permitted only
> a single operation to be active. Once something causes I/O
> to start on a selector, no other I/O operation can be started
> until the first has terminated and the trailing interrupts
> serviced. Assuming that your two tape drives were on the same
> control unit and channel, in this case your problem isn't the
> tape drives' fault.
I'm confused on this. Our tapes were 281 and 282, so I presume
both were on selector 2. (Selector 1 was for disks, channel
0 for read/punch/printer).
Anyway, I can understand the first read being a delay since
the tape must be read. But for the write, why couldn't the
output data be buffered some place so that the program could
continue? In other words, the physical write would from off
the buffer and the tape would write while the input tape was
reading.
P.S. I learned we had to be careful about blocking. We
used about 5,000 chars per block. Any more than that was
counter-productive. (I remember Deltak course saying so.)
Today I just say BLKSIZE=0 and let the system figure itself,
and I hope whatever max it uses is efficient. (They tell
me, anyway). I have no idea what cartridge or disk I write
to today; indeed, they tell us not to use cartridge but
disk for everything and let "SMS" figure out what to back
up to cartridge.
ararghmai...@now.at.arargh.com
<snip>
>Unfortunately my memory is vague on that. It was pretending
>to be a 1311--did that hold 2 Meg? I think they may have put
20,000 sectors at either 100 chars per sector in move mode, or 90
chars per sector in load mode.
Up to 5 drives on a 1401 system, IIRC.
<snip>
--
ArarghMail505 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Walter Bushell
Lawrence Wilkinson <lawr...@ljw.me.uk> wrote:
Isn't amazing how much computing was done on machines that would not be
powerful enough for a toddler's computer^W toy today.
Brian Inglis
hanc...@bbs.cpcn.com wrote:
>Joe Morris wrote:
>> > It annoyed me that only one tape
>> >of the pair would run at a time, I couldn't understand why
>> >there wasn't overlap and more buffering. In other words,
>> >while it was writing a new record, why couldn't it be
>> >simultaneously reading the next record.
>>
>> That's an issue with the channel architecture. A tape drive
>> would be placed on a selector channel, which permitted only
>> a single operation to be active. Once something causes I/O
>> to start on a selector, no other I/O operation can be started
>> until the first has terminated and the trailing interrupts
>> serviced. Assuming that your two tape drives were on the same
>> control unit and channel, in this case your problem isn't the
>> tape drives' fault.
>
>I'm confused on this. Our tapes were 281 and 282, so I presume
>both were on selector 2. (Selector 1 was for disks, channel
>0 for read/punch/printer).
>
>Anyway, I can understand the first read being a delay since
>the tape must be read. But for the write, why couldn't the
>output data be buffered some place so that the program could
>continue? In other words, the physical write would from off
>the buffer and the tape would write while the input tape was
>reading.
Selector channels/devices were non-multiplexed, one half-duplex txn to
one device at a time, hogging the channel: you issued a tape command,
and the channel was tied up until the drive finished executing the
command and presented status; IIRC even with 3420s rewind, or forward
space on a blank tape, locked up the channel until the BOT/EOT was
reached.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Joe Morris
>Joe Morris wrote:
>> Can't be either one: neither the F or D versions of the COBOL
>> compiler were ever "rented" -- for that matter, neither one
>> was even copyrighted.
>It's been a long time, but my recollection was that the
>"better" COBOL compiler was rented for a nominal fee from
>IBM. I think I saw it listed on the monthly invoice.
>This was in 1976 and using a machine from a 3rd party lease.
OK; if it's after New World the rules change for newly-introduced
products. Do you recall the product number? If it was something
looking like
360S-CB123
it's pre-New World (yes, the number above is bogus. I don't recall
what the ID was for the COBOL compilers shipped with OS/360). If
the number was something like
5740-CB1
then it's a program product, and not free.
Another clue was the color of the manual covers: at least in that period
as a general rule purple covers were (usually? always?) a flag that the
product was billable.
>> All this
>> changed, of course, with New World (June 1969), but that didn't
>> alter the status of products relased prior to that date.
>I don't understand why IBM didn't start charging for software
>after June 1969 for older stuff.
I have no idea what discussions went on about that at Galactic
Headquarters, but some possible points:
* Pre-New World, customers were sold machines with explicit
statements that the currently-available software (and updates)
came at no charge
* The existing software was shipped with no copyright notices,
which under the copyright law in effect at that time had the
effect of placing the material in the public domain
>> I never worked with the 1401 emulator; how did the emulated 1311s
>> map to a 2314?
>1401 stuff ran slow. The patient billing system (an IBM
>product) was pretty sophisticated though, esp given it was
>written for 16k.
It's amazing how much function we could pack into what today would
be an impossibly small memory space. Kids today casually talk
about their systems with over a gig of memory; one of my lecture
stories describes getting a box with 256 KB of memory at the bargain
price of $330,000 *after* educational discount...we had a REAL
incentive to write memory-efficient programs.
>> Umm...perhaps I shouldn't use the words that truly describe the
>> 7330 or 2415 in a family newsgroup.
>Glad I'm not the only one who feels that way.
<grin>
>> That's an issue with the channel architecture. A tape drive
>> would be placed on a selector channel, which permitted only
>> a single operation to be active. Once something causes I/O
>> to start on a selector, no other I/O operation can be started
>> until the first has terminated and the trailing interrupts
>> serviced. Assuming that your two tape drives were on the same
>> control unit and channel, in this case your problem isn't the
>> tape drives' fault.
>I'm confused on this. Our tapes were 281 and 282, so I presume
>both were on selector 2. (Selector 1 was for disks, channel
>0 for read/punch/printer).
That was a common assignment on a 3-channel machine. Channel
zero was always a byte multiplexor (slow, but supported multiple
simultaneous operations); channel 1 had the disks (by convention,
19x for 2311s ... which is where the standard addresses in VM
originated), and channel 2 was used for tapes. Are you sure
your tapes were 281 and 282, and not 280/281?
>Anyway, I can understand the first read being a delay since
>the tape must be read. But for the write, why couldn't the
>output data be buffered some place so that the program could
>continue? In other words, the physical write would from off
>the buffer and the tape would write while the input tape was
>reading.
You *could* have done anything with enough money and time, but
the result would probably have been a rather messy hack. The
channel architecture of the S/360 certainly had its limitations
and was hideously expensive to implement (look at the signal
timing relationships and tolerances vs. the available technology,
especially in the early days), but it provided a clean,
standardized design for both the physical and programming
interfaces. Not only that, but the control unit would have had
to be redesigned to hold an arbitrarily-long block of data, and
would need internal paths to support the simultaneous data flows.
This *was* implemented in some cases with the "read-while-writing"
option, but it was predicated on having two control units on
the tape string, attached to different selector channels. If you've
got only three channels you're out of luck since 0 is a byte mux,
1 is used for DASD, and you're left with only the second selector
for tapes. (And while I never researched the issue, I doubt
that the 2415 ever support read-while-writing.)
Joe Morris
Joe Morris
>Selector channels/devices were non-multiplexed, one half-duplex txn to
>one device at a time, hogging the channel: you issued a tape command,
>and the channel was tied up until the drive finished executing the
>command and presented status; IIRC even with 3420s rewind, or forward
>space on a blank tape, locked up the channel until the BOT/EOT was
>reached.
Um...for the rewind operations, not according to my memory. A REW
(or RUN) returned ending status as soon as it was accepted by the
control unit. (Recall the dramatic activity at EOJ when all the
drives rewind at the same time.)
A forward space operation ... h'mmm, I'm not sure; my guess would be
that it would tie up the control unit (since the CU needs to monitor
the data being presented under the head), but there would be no
need for the channel to be kept active, so it should still present
ending status when the CCW is accepted.
Now...if you mean "forward space on blank tape" to mean a read
operation on unrecorded media, this would hold the channel busy
because the CU can't know that no data will arrive before the
end of the tape comes off the supply reel.
Joe Morris
CBFalconer
>
... snip ...
>
> It's amazing how much function we could pack into what today would
> be an impossibly small memory space. Kids today casually talk
> about their systems with over a gig of memory; one of my lecture
> stories describes getting a box with 256 KB of memory at the bargain
> price of $330,000 *after* educational discount...we had a REAL
> incentive to write memory-efficient programs.
Actually there wasn't that much that was impossible on an 8080 with
64k and some floppy disks. The great luxury of a fast (70 mS avg
seek) hard drive opened things up. It would be slow, but the owner
could usually afford to do something else while the system ground
it out.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Charlie Gibbs
pr...@panix.com (Walter Bushell) writes:
> Isn't amazing how much computing was done on machines that would not
> be powerful enough for a toddler's computer^W toy today.
It's even more amazing - and depressing - how much computing is
_not_ done on those powerful toddlers' toys today. (Some of those
toddlers would be highly insulted by that term, too - we'd better
stick with calling them "lusers".)
hanc...@bbs.cpcn.com
Joe Morris wrote:
> OK; if it's after New World the rules change for newly-introduced
> products. Do you recall the product number? If it was something
> looking like > 360S-CB123
> it's pre-New World (yes, the number above is bogus. I don't recall
> what the ID was for the COBOL compilers shipped with OS/360). If
> the number was something like > 5740-CB1
> then it's a program product, and not free.
I don't remember the number.
FWIW, is there a breakdown to the following?
PP 5688-197 IBM COBOL for MVS and VM 1.2.0 9603
(This is what we're using as we speak.)
> Another clue was the color of the manual covers: at least in that
period
> as a general rule purple covers were (usually? always?) a flag that
the
> product was billable.
I'm pretty sure they were purple.
> * Pre-New World, customers were sold machines with explicit
> statements that the currently-available software (and updates)
> came at no charge
>
> * The existing software was shipped with no copyright notices,
> which under the copyright law in effect at that time had the
> effect of placing the material in the public domain
Thanks for the explanation. That makes more sense.
Speaking of copyrights, do copyrights of old stuff automatically
renew forever (in 'perpetuity'?) I have an IBM book "Men Minutes
Money" by TJ Watson copyright 1934. In the past copyrights would
eventually expire (only allowed a finite time even with renewals);
but IIRC the copyright law was changed. I'm just curious if this
book is still under copyright protection.
> It's amazing how much function we could pack into what today would
> be an impossibly small memory space. Kids today casually talk
> about their systems with over a gig of memory; one of my lecture
> stories describes getting a box with 256 KB of memory at the bargain
> price of $330,000 *after* educational discount...we had a REAL
> incentive to write memory-efficient programs.
They told me the system (IIRC it was "PAL" for patient billing)
used homerolled on-disk subroutines as well as a homerolled database
on disk. I guess by today's standards it wasn't that complex, but
for 16k and running a whole enterprise it seemed powerful. It did
handle a high volume of transactions against a large table of
billable items.
> Are you sure
> your tapes were 281 and 282, and not 280/281?
I think you're right 281/282. I think the disk was 13n. I
think the IPL setting was 131, but we rarely changed that.
Once the C/Es IPL'd from the card reader for special diagnostics.
(As an aside, why does IBM call it "IPL" when everyone says
"boot up"?)
> (And while I never researched the issue, I doubt
> that the 2415 ever support read-while-writing.)
When I changed jobs it blew my mind the incredibly fast
time of newer tape jobs, esp ones that handled 6250.
I liked when cartridges came out because they were stored in
the computer room and we no longer had to send in a tape pull slip
to the tape librarian. Even better was the "silo" since mounts
were automated. Still better was tons and tons of disk space
eliminating the need for cart altogether. However, sometimes
our jobs crash for inadequate free disk space when too many
things are running at once and SMS can't handle it.
It's funny--our peak machine time used to be 9-5 due to on-line
needs, but now we peak overnight with lots of heavy duty batch
jobs. Our old IMS database is split into ten separate databases
for handling efficiency and simultaneous use. I don't know if
that would be done today. Is IMS even used for new work or is it
all DB2?
Morten Reistad
>
>Thanks for the explanation. That makes more sense.
>
>Speaking of copyrights, do copyrights of old stuff automatically
>renew forever (in 'perpetuity'?) I have an IBM book "Men Minutes
>Money" by TJ Watson copyright 1934. In the past copyrights would
>eventually expire (only allowed a finite time even with renewals);
>but IIRC the copyright law was changed. I'm just curious if this
>book is still under copyright protection.
The original convention stated that copyrights lasted 50 years from
the death of the last author; or a flat 50 if the author was not a
physical human. It was then extended for the "time lost in wars", WW1
and WW2, and was then again extended to 70 years. The implmentations
of this varies from country to country, and lots of delays and
possible extensions were introduced. Mickey Mouse is still not
liberated from Disney, and he appeared in 1924. Edvard Grieg's music
was unambigously free of copyright only last year, and he died in
1907.
So, I think I can say clearly that a book from 1934, written in the
US and published by the boss of a lawyer-savvy organization like IBM
is still under copyright. But I may be wrong, they actually have had
to file for an extension.
-- mrr
Eric Smith
> That was a common assignment on a 3-channel machine. Channel
> zero was always a byte multiplexor (slow, but supported multiple
> simultaneous operations); channel 1 had the disks (by convention,
> 19x for 2311s ... which is where the standard addresses in VM
> originated), and channel 2 was used for tapes.
I've never having much experience with a 360 or 370 other than submitting
jobs via RJE, but I've become interested in hardware and system configuration
recently.
What were typical assignments on systems with more than three channels?
Where do block multiplexor channels (e.g. 2880) enter the picture? I'm
guessing that they are for DASD; are they used for anything else? Did
any machines have integral block multiplexor channels?
What was the interface between standalone channel processors (2860, 2870,
2880) and the host system?
Eric
ararghmai...@now.at.arargh.com
<jcmo...@mitre.org> wrote:
<snip>
>it's pre-New World (yes, the number above is bogus. I don't recall
>what the ID was for the COBOL compilers shipped with OS/360). If
CB545
Peter Flass
> Joe Morris wrote:
>
>>That was a common assignment on a 3-channel machine. Channel
>>zero was always a byte multiplexor (slow, but supported multiple
>>simultaneous operations); channel 1 had the disks (by convention,
>>19x for 2311s ... which is where the standard addresses in VM
>>originated), and channel 2 was used for tapes.
>
>
> I've never having much experience with a 360 or 370 other than submitting
> jobs via RJE, but I've become interested in hardware and system configuration
> recently.
>
> What were typical assignments on systems with more than three channels?
I'll leave this one to someone else. I think you usually just used
channel 3, 4, etc.
>
> Where do block multiplexor channels (e.g. 2880) enter the picture? I'm
> guessing that they are for DASD; are they used for anything else? Did
> any machines have integral block multiplexor channels?
As you probably know, byte multiplexor channels interleaved data from
several I/O operations on a byte basis. Think "one byte from the card
reader, one to the printer, ...". Selector channels only carried out
one operation at a time. Block multiplexor channels interleaved data by
blocks, that is, the channel could start several I/O operations going,
and the CPU or control unit would only tie up the channel when it
actually had a block of data to transfer.
Selector channels (IIRC) pretty much died out with the 360. After that
all non character-type I/O was done by the block multiplexors, DASD,
Tape, and what-have-you. Not as useful for tapes, but the channel could
profitably disconnect for REW, FSF, etc.
Peter Flass
> (And while I never researched the issue, I doubt
> that the 2415 ever support read-while-writing.)
It's lucky the 2415 could read what it wrote. What I still remember
best about them is how they'd honk like a goose in heat when they loaded
a tape. No vacuum columns on those babies.
Peter Flass
> Um...for the rewind operations, not according to my memory. A REW
> (or RUN) returned ending status as soon as it was accepted by the
> control unit. (Recall the dramatic activity at EOJ when all the
> drives rewind at the same time.)
My recollection is that REW kept the channel tied up to signal BOT, but
RUN released it, though I wouldn't bet my life on it. I seem to recall
that we coded some option on the COBOL 'CLOSE' statement or what passed
for JCL to make sure we unloaded the tapes.
William Hamblen
<firs...@lastname.pr1v.n0> wrote:
>So, I think I can say clearly that a book from 1934, written in the
>US and published by the boss of a lawyer-savvy organization like IBM
>is still under copyright. But I may be wrong, they actually have had
>to file for an extension.
The law in the USA was that a copyright lasted 28 years and could be
renewed for an additional 28 years. Some long-lived authors did
outlive the copyrights on their early books. If more than a
relatively small number of foreign books were imported without
applying for a US copyright, the work lost its US copyright. This did
happen to J. R. R. Tolkien and The Lord of the Rings. His literary
agent was not alert to the problem and when Ace Books noticed the work
had gone into the public domain in the USA, it brought out a paperback
edition that Tolkien did not get any royalties for. This was in 1965
or '66. Tolkien did make a deal with Avon books for an authorized
edition and then came to some arrangement with Ace.
rpl
Hmm... (COBOL) "CLOSE" rewound, IIRC. You'd probably have to put a
DISPLAY command in the source, or write a JCL command to remind the
operator to physically remove the tape. I'm a bit confused here because
if you wanted to remount the file, you'd have to rethread the tape
using that logic.
rpl