Discussion:
The System/360 Model 20 Wasn't As Bad As All That
(too old to reply)
John Savard
2006-07-04 13:52:09 UTC
Permalink
On April 7, 1964, International Business Machines announced System/360.

The initial announcement comprised models 30, 40, 50, 60, 62, and 70.

The last three models were replaced by models 65 and 75 prior to
delivery; the front panels looked pretty much the same, but the
performance was improved over what had been announced originally.

IBM extended the series upwards later, with the model 91, followed by
the 85 and the 195 (not to mention the two model 95s sold to NASA, IBM's
one and only thin-film computer).

There was a special-purpose machine in the middle of the series, the
model 44, which had particularly high floating-point performance.

And, of course, there was the model 67, which offered Dynamic Address
Translation in what was otherwise a model 65.

They also extended the series at the low end, with the models 22 and 25.

Then there was the Model 20.

Not only couldn't you get floating-point for it, but it didn't even have
all the standard System/360 instructions: it wouldn't do arithmetic on
32-bit integers.

The popularity of the IBM 360 inspired imitations... and
near-imitations.

The closest of the near-imitations were the RCA Spectra 70 computers.
Only those portions of the instruction set that required privileged mode
to use were different. Presumably, this was intended to ensure they
didn't need to fear a lawsuit by encouraging people to pirate IBM's
operating system software.

Usually not even counted as an imitation at all were the Sigma
computers. These computers had instructions that were all 32 bits in
length; register-to-register operations were provided by means of
assigning memory addresses to the registers. But the features offered
were intentionally matched to those of the System/360, and the data
formats were the same - with the exception of floating-point numbers, if
they were negative.

In data formats, the PDP-6 had the same sort of relation to the IBM 7090
and its relatives, but even the fact that the KA-10 version of the
PDP-10 had a front panel with a sloped front, and a near-horizontal
extension with the rows of rocker switches on it doesn't really lead me
to think of the PDP-6 and PDP-10 as imitations of the 7090. Had it not
used two's complement arithmetic for integers, I might have reconsidered
that.

Then there were the minis from Interdata.

But back to the System/360 Model 20. I listed what it didn't have. But I
didn't list what it _did_ have. Because it didn't _just_ do halfword
arithmetic. It also came with the full decimal arithmetic instruction
set.

That meant that it wasn't just a minicomputer at mainframe prices. It
was a practical and useful machine, avoiding un-needed features, which
was very attractive to a certain market.

It doesn't seem to have offered, unlike the Model 30 (or the Model 25,
which came later) the option of 1401 emulation. But it was still very
useful to meet the data processing needs of 1401 customers.

And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine, it would have been possible, at least in
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
2006-07-04 14:15:07 UTC
Permalink
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine, it would have been possible, at least in
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
Truth is stranger than fiction. A web search allowed me to discover at
least one person who seems to be claiming he learned FORTRAN II on a
360/20 at Iowa State University (perhaps the 360/20 was their *main*
computer at the time, but he learned FORTRAN II on some other less
regarded computer they also had, however)... and that IBM *did* make
available the PL/I level D compiler for the 360/20.

And Al Kossow even has the *manual*. I'll see what kind of
floating-point it supported, if any.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
2006-07-04 15:26:05 UTC
Permalink
Post by John Savard
And Al Kossow even has the *manual*. I'll see what kind of
floating-point it supported, if any.
Excess-50 exponent as two decimal digits, followed by a signed-decimal
normalized mantissa which occupied four or eight bytes, for six (not
seven!) or fifteen digits of precision.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Walter Bushell
2006-07-06 16:36:59 UTC
Permalink
Post by John Savard
Post by John Savard
And Al Kossow even has the *manual*. I'll see what kind of
floating-point it supported, if any.
Excess-50 exponent as two decimal digits, followed by a signed-decimal
normalized mantissa which occupied four or eight bytes, for six (not
seven!) or fifteen digits of precision.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Ah, the first nibble could be as low as 1 so one less digit than one
might expect.

To bad they didn't allow for arbitrary precision. Run with one more
digit (and less) and if your results vary you got numerical problems.
--
"The power of the Executive to cast a man into prison without formulating any
charge known to the law, and particularly to deny him the judgement of his
peers, is in the highest degree odious and is the foundation of all totali-
tarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Peter Flass
2006-07-04 20:09:30 UTC
Permalink
Post by John Savard
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine, it would have been possible, at least in
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
Truth is stranger than fiction. A web search allowed me to discover at
least one person who seems to be claiming he learned FORTRAN II on a
360/20 at Iowa State University (perhaps the 360/20 was their *main*
computer at the time, but he learned FORTRAN II on some other less
regarded computer they also had, however)... and that IBM *did* make
available the PL/I level D compiler for the 360/20.
And Al Kossow even has the *manual*. I'll see what kind of
floating-point it supported, if any.
John Savard
Even harder to believe, apparently they had a PL/I compiler fot the /20.
Anne & Lynn Wheeler
2006-07-04 16:05:37 UTC
Permalink
Post by John Savard
The popularity of the IBM 360 inspired imitations... and
near-imitations.
The closest of the near-imitations were the RCA Spectra 70 computers.
Only those portions of the instruction set that required privileged mode
to use were different. Presumably, this was intended to ensure they
didn't need to fear a lawsuit by encouraging people to pirate IBM's
operating system software.
Usually not even counted as an imitation at all were the Sigma
computers. These computers had instructions that were all 32 bits in
length; register-to-register operations were provided by means of
assigning memory addresses to the registers. But the features offered
were intentionally matched to those of the System/360, and the data
formats were the same - with the exception of floating-point numbers, if
they were negative.
In data formats, the PDP-6 had the same sort of relation to the IBM 7090
and its relatives, but even the fact that the KA-10 version of the
PDP-10 had a front panel with a sloped front, and a near-horizontal
extension with the rows of rocker switches on it doesn't really lead me
to think of the PDP-6 and PDP-10 as imitations of the 7090. Had it not
used two's complement arithmetic for integers, I might have reconsidered
that.
Then there were the minis from Interdata.
I've frequently mentioned story about when I was adding tty/ascii
terminal support to cp67, i couldn't quite get the ibm 2702
telecommunication controller to do what i wanted. this somewhat
prompted the univ. to start a project to build our own controller.
initially a reverse-engineered channel board was added to a
interdata/3 programmed to emulate 2702 (but do things like automatic
buad rate recognition). later it was enhanced with an interdata/4
programmed to emulate 2702 with multiple interdata/3 as dedicated
linescanners.

recent post on the subject in FS thread:
http://www.garlic.com/~lynn/2006m.html#44 Musings on a holiday weekend

something similar by Umich using PDP1 in conjunction w/MTS
http://www.garlic.com/~lynn/2006m.html#42 Why Didn't The Cent Sign or the Exclamation Mark Print?

collected posts mentioning the effort and plug compatible controllers
http://www.garlic.com/~lynn/subtopic.html#360pcm

interdata simulator reference
http://simh.trailing-edge.com/interdata.html
Anne & Lynn Wheeler
2006-07-04 16:08:39 UTC
Permalink
Post by John Savard
The initial announcement comprised models 30, 40, 50, 60, 62, and 70.
The last three models were replaced by models 65 and 75 prior to
delivery; the front panels looked pretty much the same, but the
performance was improved over what had been announced originally.
60 and 70 were with 1mic memory ... before machines were shipped the
memory was upgraded to 750ns and the models renamed 65 and 75.

instruction timings in the functional specification ... i.e.
http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/

for the machines based on 750ns memory, It was 8byte-wide
(interleaved) fetch. part of the instruction timings were the prorated
instruction fetch times i.e. two-byte instructions included 1/4 750ns,
four-byte instructions included 1/2 750ns, and six-byte instructions
included 3/4 750ns (prorated double word instruction fetch).

gory details for 360/65 timings start on page 20
http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/A22-6884-3_360-65_funcChar.pdf
John Savard
2006-07-04 18:43:48 UTC
Permalink
On Tue, 04 Jul 2006 10:08:39 -0600, Anne & Lynn Wheeler
Post by Anne & Lynn Wheeler
60 and 70 were with 1mic memory ...
No! No! The 60 was with 2 microsecond memory, the 62 was the one with 1
microsecond memory!

I happened to just be reading the original version of the System Summary
to try to find out the identity of a mystery front panel, one side of
which I saw in an old DATAMATION ad, and which also appeared in the
front of the following photo:

Loading Image...

note the model 75 - or, I suspect, the model 70 prototype - in the
background.

Perhaps it was an alternate version of the Model 30, with styling
similar to what would later be used for the Model 20.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Anne & Lynn Wheeler
2006-07-04 20:26:03 UTC
Permalink
Post by John Savard
No! No! The 60 was with 2 microsecond memory, the 62 was the one with 1
microsecond memory!
I happened to just be reading the original version of the System Summary
to try to find out the identity of a mystery front panel, one side of
which I saw in an old DATAMATION ad, and which also appeared in the
http://archive.computerhistory.org/resources/still-image/IBM/IBM_360/IBM.360.19xx.102657020.lg.jpg
mea culpa ... i just remember being told as undergraduate that the
360/65 as an (750ns memory) "upgrade" of an earlier announced model
with 1mic memory that didn't ship.

when somebody referenced that there was a 360/62, i jumped to the
conclusion that it might have also been 360/67 with one mic. memory
... in part because I have some vague recollection of reading an early
overview pub on machine with virtual memory that was being offered in
single (uniprocessor), two processing and four processor models (i.e.
smp, multiprocessor) ... and some vague impression that it might have
been a different model number.

later when 360/67 showed up there was no longer a four processor
model.

there was a custom three procesor model version built for MOL (manned
orbital laboratory) project delivered to lockheed ... whiched then
seem to disappear. i stumbled across some reference to it showing
up again (or at least part of it) at ncss
...

ncss reference here at computer history museum
http://www.computerhistory.org/corphist/view.php?s=select&cid=4

here is the reference:
http://www.computerhistory.org/corphist/view.php?s=events&id=330

from above:

Installation of first operational duplex 67 (actually 2/3's of the MOL
triplex system). The team came up with a simplifying algorithm that
increased perfomance over the initial algorithm very significantly.

... snip ...
John Savard
2006-07-04 21:48:23 UTC
Permalink
On Tue, 04 Jul 2006 14:26:03 -0600, Anne & Lynn Wheeler
Post by Anne & Lynn Wheeler
when somebody referenced that there was a 360/62, i jumped to the
conclusion that it might have also been 360/67 with one mic. memory
I always used to think that the difference between the 60 and 62 was the
same as between the 65 and 67 as well, previously, but now I realize
*they* were differentiated by memory speed - and Dynamic Address
Translation was something that came along much later.

And progress was pretty fast back then too... main memory on the 370/115
was faster than main memory on the 360/195!

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
2006-07-06 07:56:12 UTC
Permalink
On Tue, 04 Jul 2006 14:26:03 -0600, Anne & Lynn Wheeler
Post by Anne & Lynn Wheeler
mea culpa ... i just remember being told as undergraduate that the
360/65 as an (750ns memory) "upgrade" of an earlier announced model
with 1mic memory that didn't ship.
Don't feel too bad. I just came across what seems to be a Wikipedia
mirror which still refers to the System/360 Model 64 and System/360
Model 66, supposedly the DAT versions of models 60 and 62. Maybe IBM did
announce the DAT option before switching from models 60 and 62 to 65,
although that doesn't correspond to anything I remember reading.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
2006-07-04 23:40:37 UTC
Permalink
Post by John Savard
I happened to just be reading the original version of the System Summary
to try to find out the identity of a mystery front panel, one side of
which I saw in an old DATAMATION ad, and which also appeared in the
http://archive.computerhistory.org/resources/still-image/IBM/IBM_360/IBM.360.19xx.102657020.lg.jpg
note the model 75 - or, I suspect, the model 70 prototype - in the
background.
Perhaps it was an alternate version of the Model 30, with styling
similar to what would later be used for the Model 20.
It could also be another type of remote control panel, one of those
being in the middle.

Incidentally, the *person* in the photograph is Dr. Frederic P. Brooks,
Jr., author of "The Mythical Man-Month", deriving from his experiences
in leading the development of OS/360.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Anne & Lynn Wheeler
2006-07-05 01:45:36 UTC
Permalink
Post by John Savard
http://archive.computerhistory.org/resources/still-image/IBM/IBM_360/IBM.360.19xx.102657020.lg.jpg
It could also be another type of remote control panel, one of those
being in the middle.
Incidentally, the *person* in the photograph is Dr. Frederic P. Brooks,
Jr., author of "The Mythical Man-Month", deriving from his experiences
in leading the development of OS/360.
i thot for a moment that it might be 2914 ... but they are typically
only found in multiple machine environment
http://www.labx.com/v2/spiderdealer2/vistaSearchDetails.cfm?LVid=3017353

this has picture of multiple control consoles for 360/91 ....
http://www.columbia.edu/acis/history/36091.html

but the one "control console" is shown from the rear
Loading Image...

360 system summary
http://bitsavers.trailing-edge.com/pdf/ibm/360/A22-6810-0_360sysSummary64.pdf

figure 6 has poor image of 360/40 and 360/70 with a 2150 console
on pg. 12

pg. 20 mentions 2150 console duplicating operators' controls

pg. 21 has figure 11 with another poor imageof 2150

......

for some drift, from 360/195 functional characteristics
http://bitsavers.trailing-edge.com/pdf/ibm/360/funcChar/A22-6943-0_360-195_funChar.pdf

pg.23 shows control panel with space for 2nd cpu control.

past posts that mention dual i-stream (hardware threading) project for
370/195 (which never shipped) which looked like 2nd cpu to software
http://www.garlic.com/~lynn/94.html#38 IBM 370/195
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/99.html#73 The Chronology
http://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
http://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
http://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
http://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
http://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
http://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
http://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
John Savard
2006-07-05 02:07:13 UTC
Permalink
On Tue, 04 Jul 2006 19:45:36 -0600, Anne & Lynn Wheeler
Post by Anne & Lynn Wheeler
pg. 20 mentions 2150 console duplicating operators' controls
pg. 21 has figure 11 with another poor imageof 2150
Well, there *is* a 2150 console pictured quite clearly in the picture as
well, between the machine I'm interested in, in the foreground with only
its right edge visible, and the apparent model 75 in the background.

I suspect this is a very early photograph, prepared for the initial
announcement, making the processor in the background the model 70
prototype. At least, that would have to be true if the machine in the
foreground is what I think it is - a prototype of a lower-end machine,
likely the model 30, with a completely different front panel style.

But it doesn't have to be that. It could be something quite different.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Nick Spalding
2006-07-04 17:27:25 UTC
Permalink
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine, it would have been possible, at least in
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
What they did provide was an RPG compiler which was a near-enough replica of
that for the 1401.
--
Nick Spalding
Peter Flass
2006-07-04 20:17:24 UTC
Permalink
Post by Nick Spalding
What they did provide was an RPG compiler which was a near-enough replica of
that for the 1401.
The installations I saw, RPG was the primary language, as it was for the
other "small" computers: s/36, s/38, AS/400. There was a COBOL, but the
performance and/or overhead was apparently bad enough thet I don't think
I ever saw it used. As I mentioned, there was PL/I, which I just found
out about recently, 35 years after the fact. There was assembler, of
course, but I don't believe that this level of customer or application
made much use of it. RPG was a perfect fit.

I liked the idea that the instruction set was a near-perfect 16-bit
subset of full 360. From a hardware standpoint, I think you could have
run a compiled program on a larger machine. Aspects of software
compatibility would probaby have prevented actually doing this.

I actually *liked* the machine, although we 1130 programmers looked down
on it as a toy for glorified "tab" shops.
A***@NOT.AT.Arargh.com
2006-07-04 20:40:47 UTC
Permalink
On Tue, 04 Jul 2006 20:17:24 GMT, Peter Flass <***@Yahoo.com>
wrote:

<snip>
Post by Peter Flass
I liked the idea that the instruction set was a near-perfect 16-bit
subset of full 360. From a hardware standpoint, I think you could have
run a compiled program on a larger machine.
Excluding I/O, which wasn't even close.
Post by Peter Flass
Aspects of software
compatibility would probaby have prevented actually doing this.
I think so.
Post by Peter Flass
I actually *liked* the machine, although we 1130 programmers looked down
on it as a toy for glorified "tab" shops.
--
ArarghMail606 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.
Eugene Miya
2006-07-05 17:23:07 UTC
Permalink
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Post by John Savard
On April 7, 1964, International Business Machines announced System/360.
...
Post by John Savard
Then there was the Model 20.
Not only couldn't you get floating-point for it, but it didn't even have
all the standard System/360 instructions: it wouldn't do arithmetic on
32-bit integers.
Not everything is arithmetic. TAOCP vol. 2 for instance is an
interesting borderline case.

Ramble snipped.
Post by John Savard
But back to the System/360 Model 20.
That meant that it wasn't just a minicomputer at mainframe prices. It
was a practical and useful machine, avoiding un-needed features, which
was very attractive to a certain market.
It doesn't seem to have offered,
the option of 1401 emulation. But it was still very
useful to meet the data processing needs of 1401 customers.
Hmmm, eeee.
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine,
And that's supposed to be good?
Post by John Savard
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
Well, not every thing his Fortran.

--
Rostyslaw J. Lewyckyj
2006-07-06 05:46:42 UTC
Permalink
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
What language was your program written in?
Why didn't you use a DEC? (was it perhaps before DECs)?

As I understand it the mod20 was also called the Multifunction Card
Machine. I.e. that was its intended purpose, although it was more
versitile.
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
Post by Eugene Miya
Post by John Savard
On April 7, 1964, International Business Machines announced System/360.
...
Post by John Savard
Then there was the Model 20.
Not only couldn't you get floating-point for it, but it didn't even have
all the standard System/360 instructions: it wouldn't do arithmetic on
32-bit integers.
Not everything is arithmetic. TAOCP vol. 2 for instance is an
interesting borderline case.
Ramble snipped.
Post by John Savard
But back to the System/360 Model 20.
That meant that it wasn't just a minicomputer at mainframe prices. It
was a practical and useful machine, avoiding un-needed features, which
was very attractive to a certain market.
It doesn't seem to have offered,
the option of 1401 emulation. But it was still very
useful to meet the data processing needs of 1401 customers.
Hmmm, eeee.
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine,
And that's supposed to be good?
Ah.., What was the intended purpose design goal for the IBM 1620?
Post by Eugene Miya
Post by John Savard
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
Well, not every thing his Fortran.
--
Rostyk
Charles Richmond
2006-07-06 07:12:32 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
What language was your program written in?
Why didn't you use a DEC? (was it perhaps before DECs)?
As I understand it the mod20 was also called the Multifunction Card
Machine. I.e. that was its intended purpose, although it was more
versitile.
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
Back in the halcyon days of the Commodore 64, hobbyests used to
write programs to run on the VIC-1541 floppy disk drive unit. The
disk drive was sort of an independent unit that had its own 6502
processor and memory built in. The disk drive was daisy-cheined
on some kind of buss with the Commodore 64. Most programs on the
disk drive addressed better floppy disk performance though.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Eugene Miya
2006-07-06 16:59:37 UTC
Permalink
Post by Charles Richmond
Back in the halcyon days of the Commodore 64, hobbyests used to
Buy one of my friend Jeri's C1s.

--
Charles Richmond
2006-07-07 22:51:55 UTC
Permalink
Post by Eugene Miya
Post by Charles Richmond
Back in the halcyon days of the Commodore 64, hobbyests used to
Buy one of my friend Jeri's C1s.
I have a couple of C64's and a C128. I can get along without the C1.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Peter Flass
2006-07-06 11:01:36 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
As I understand it the mod20 was also called the Multifunction Card
Machine. I.e. that was its intended purpose, although it was more
versitile.
Not exactly. The MFCM (Multifunction Card Machine, but feel free tom
use one of many less favorable definitions of the acronym) was a popular
peripheral for the model 20. I mentioned the attraction of the /20 from
the "card whallopers." The MFCM could read, punch, and interpret card
decks under program control; it replaced a whole roomful of tab equipment.

I believe the 20 might have been the first minicomputer, although it was
still bigger than a desk, even without the peripherals. Unlike systems
today which have gron "up", so that, for example, 16-bit quantities are
called "words" in Intel-speak, so 32-bit quantities then have to be
"doublewords", the /20 was a "shrunk" 360, with only the halfword (and
decimal apparently) instructions.
Post by Rostyslaw J. Lewyckyj
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
A real programmer will program anything. If there isn't a computer
handy, use a printer, programmmable calculator, or cell-phone!
Walter Bushell
2006-07-06 16:29:01 UTC
Permalink
Post by Peter Flass
Post by Rostyslaw J. Lewyckyj
As I understand it the mod20 was also called the Multifunction Card
Machine. I.e. that was its intended purpose, although it was more
versitile.
Not exactly. The MFCM (Multifunction Card Machine, but feel free tom
use one of many less favorable definitions of the acronym) was a popular
peripheral for the model 20. I mentioned the attraction of the /20 from
the "card whallopers." The MFCM could read, punch, and interpret card
decks under program control; it replaced a whole roomful of tab equipment.
I believe the 20 might have been the first minicomputer, although it was
still bigger than a desk, even without the peripherals. Unlike systems
today which have gron "up", so that, for example, 16-bit quantities are
called "words" in Intel-speak, so 32-bit quantities then have to be
"doublewords", the /20 was a "shrunk" 360, with only the halfword (and
decimal apparently) instructions.
Post by Rostyslaw J. Lewyckyj
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
A real programmer will program anything. If there isn't a computer
handy, use a printer, programmmable calculator, or cell-phone!
In the beginning the printer had an advanced cpu compared to the
computer. Mac 68000, printer 68020 (early LaserWriter.) And, I believe
more memory.
--
"The power of the Executive to cast a man into prison without formulating any
charge known to the law, and particularly to deny him the judgement of his
peers, is in the highest degree odious and is the foundation of all totali-
tarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
Eugene Miya
2006-07-06 19:00:19 UTC
Permalink
Post by Walter Bushell
Post by Peter Flass
mod20 was also called the Multifunction Card Machine.
Not exactly. The MFCM (Multifunction Card Machine, but feel free tom
a popular peripheral for the model 20.
I believe the 20 might have been the first minicomputer, although it was
Not likely.
CDC 160, PDP-1, LINC, TX-2, etc.
Post by Walter Bushell
Post by Peter Flass
still bigger than a desk, even without the peripherals. Unlike systems
today which have gron "up", so that, for example, 16-bit quantities are
called "words" in Intel-speak, so 32-bit quantities then have to be
"doublewords", the /20 was a "shrunk" 360, with only the halfword (and
decimal apparently) instructions.
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
A real programmer will program anything. If there isn't a computer
handy, use a printer, programmmable calculator, or cell-phone!
Can be interesting.
Post by Walter Bushell
In the beginning the printer had an advanced cpu compared to the
computer. Mac 68000, printer 68020 (early LaserWriter.) And, I believe
more memory.
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.


CPU?

Exercise: program a seemingly innocuous device like a printer (thought
as an output only) to subvert and control an air defense system.

--
Rostyslaw J. Lewyckyj
2006-07-06 23:01:32 UTC
Permalink
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Also wasn't that a long gap between the 1403 and the 3800?
Post by Eugene Miya
CPU?
Exercise: program a seemingly innocuous device like a printer (thought
as an output only) to subvert and control an air defense system.
Eugene Miya
2006-07-07 15:45:38 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Also wasn't that a long gap between the 1403 and the 3800?
I think the character set would have been called pica type (12 pt).
I never dealt with the ALA until the 90s, but was aware of them and have
attended ALA meetings.

I can rememebr UCSB (ARPA site host #3 because of Glenn Culler) before
and after the TN train. I used it for Club mailing list gummed labels.
That was mid-70s. I think I saw my first 3800 when I was working for
JPL located at Caltech part time and Tech had a 3800, but I never used it.

Gary Starkweather (ex-PARC, Apple, now MS) gave the first Museum talk
at Moffett on the 1st laser printer and a 30 Mb/s data link using Edmund
Scientific parts. He mentioned the history leading up to the IBM 3800.
I am not certain we taped that, but that was an awesome talk.

The only people who knew about fonts in the computer world in 1975 were
basically PARC and Bell Labs. Knuth had not yet started TeX and
Metafont (I just got a note from him in Oxford). People don't realize
that word processing and document processing weren't wide spread in that era.
Those guys produced very impressive papers at that time which made every
one else in CS jealous. Long stories there.

--
Brian Inglis
2006-07-08 00:39:16 UTC
Permalink
On 7 Jul 2006 08:45:38 -0700 in alt.folklore.computers,
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Also wasn't that a long gap between the 1403 and the 3800?
I think the character set would have been called pica type (12 pt).
I never dealt with the ALA until the 90s, but was aware of them and have
attended ALA meetings.
I can rememebr UCSB (ARPA site host #3 because of Glenn Culler) before
and after the TN train. I used it for Club mailing list gummed labels.
also Universal Character Set Buffer on IBM printers with loadable
character sets; from CP LOADBUF command docs:

"IBM supplies the following UCS buffer images for the 3203 model 5
printer:

Name Meaning
AN Normal alphanumeric notation character set arrangement
HN Normal hexadecimal notation character set arrangement
PCAN Preferred alphanumeric notation character set arrangement
PCHN Preferred hexadecimal notation character set arrangement
QN PL/I--60 graphics
QNC PL/I--60 graphics
RN FORTRAN, COBOL commercial
YN High-speed alphanumeric
TN Text printing 120 graphics
PN PL/I--60 graphics
SN Text printing 84 graphics

IBM supplies the following UCS buffer images for a device that
emulates the 3211 printer:

Name Meaning
A11 Standard commercial
H11 Standard scientific
G11 ASCII
P11 PL/I
T11 Text printing

IBM supplies the following UCS buffer images for the 3262 printer:

Name Meaning
P48 48-character belt
P52 52-character belt (Austria/Germany)
P63 63-character belt, optimized
P64 64-character belt
P96 96-character belt
P116 116-character belt (French-Canadian)
P128 128-character belt (Katakana)"
Post by Eugene Miya
That was mid-70s. I think I saw my first 3800 when I was working for
JPL located at Caltech part time and Tech had a 3800, but I never used it.
Gary Starkweather (ex-PARC, Apple, now MS) gave the first Museum talk
at Moffett on the 1st laser printer and a 30 Mb/s data link using Edmund
Scientific parts. He mentioned the history leading up to the IBM 3800.
I am not certain we taped that, but that was an awesome talk.
Did a bunch of work to make other laser printers look like super-3800s
to SCRIPT and GDDM under CMS as the 3800 was the only supported
multi-font and APA/pixel graphics printer.
Post by Eugene Miya
The only people who knew about fonts in the computer world in 1975 were
basically PARC and Bell Labs. Knuth had not yet started TeX and
Metafont (I just got a note from him in Oxford). People don't realize
that word processing and document processing weren't wide spread in that era.
Those guys produced very impressive papers at that time which made every
one else in CS jealous. Long stories there.
I was lucky to work on a product in that timeframe to replace IBM
MagCard Selectrics used for preparing UK MoD submissions and docs with
something better than runoff/nroff, support character and line
printers, daisy wheel printers up to dual wheel double wide platen,
and phototypesetters. It was built for internal use, but also marketed
around UK MoD contractors as a turnkey system and sold some copies,
but I emigrated shortly after the initial external install.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

***@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
j***@aol.com
2006-07-08 10:24:44 UTC
Permalink
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Also wasn't that a long gap between the 1403 and the 3800?
I think the character set would have been called pica type (12 pt).
I never dealt with the ALA until the 90s, but was aware of them and have
attended ALA meetings.
I can rememebr UCSB (ARPA site host #3 because of Glenn Culler) before
and after the TN train. I used it for Club mailing list gummed labels.
That was mid-70s. I think I saw my first 3800 when I was working for
JPL located at Caltech part time and Tech had a 3800, but I never used it.
Gary Starkweather (ex-PARC, Apple, now MS) gave the first Museum talk
at Moffett on the 1st laser printer and a 30 Mb/s data link using Edmund
Scientific parts. He mentioned the history leading up to the IBM 3800.
I am not certain we taped that, but that was an awesome talk.
The only people who knew about fonts in the computer world in 1975 were
basically PARC and Bell Labs.
Wrong. I posted a blurb from a Colophon of a mystery novel I'd
read. I don't remember when I did...January, 2006.

<snip>

/BAH
Anne & Lynn Wheeler
2006-07-08 20:11:47 UTC
Permalink
Post by Eugene Miya
I think the character set would have been called pica type (12 pt).
I never dealt with the ALA until the 90s, but was aware of them and have
attended ALA meetings.
I can rememebr UCSB (ARPA site host #3 because of Glenn Culler) before
and after the TN train. I used it for Club mailing list gummed labels.
That was mid-70s. I think I saw my first 3800 when I was working for
JPL located at Caltech part time and Tech had a 3800, but I never used it.
Gary Starkweather (ex-PARC, Apple, now MS) gave the first Museum talk
at Moffett on the 1st laser printer and a 30 Mb/s data link using Edmund
Scientific parts. He mentioned the history leading up to the IBM 3800.
I am not certain we taped that, but that was an awesome talk.
The only people who knew about fonts in the computer world in 1975 were
basically PARC and Bell Labs. Knuth had not yet started TeX and
Metafont (I just got a note from him in Oxford). People don't realize
that word processing and document processing weren't wide spread in that era.
Those guys produced very impressive papers at that time which made every
one else in CS jealous. Long stories there.
2741 had a number of different fonts as different typeballs ... cms
script ... originally runoff-like "dot" commands ... but
then GML
http://www.garlic.com/~lynn/subtopic.html#sgml

was invented at the science center in 1969 and GML support was added
to cms script. when different font was specified in a script document
... it had feature that would pause the 2741 to allow the user to
change the typeball.

Some number of final draft quality documents were produced on 2741
using (new) film ribbon ... rather than standard fabric ribbon (film
ribbon resulted in much sharper edge in the typed characters).

3800 came out in 1975 ... previous post reference
http://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That

and 3800 reference here:
http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV3103.html

and essentially script/gml stuff that had been used for 2741 typeball
font specification, was mapped to 3800 font capability.
kkt
2006-07-08 22:46:00 UTC
Permalink
Post by Eugene Miya
The only people who knew about fonts in the computer world in 1975 were
basically PARC and Bell Labs.
Are you excluding dedicated word processors? I'm pretty sure Wang had
some, and there were probably others as well.

Also on the commercial printing end there were computer-aided
phototypesetters much earlier than that. But they were intended to
make the professional typesetter's job easier, rather than to allow
amateurs to self-publish.

-- Patrick

Brian Inglis
2006-07-07 23:14:20 UTC
Permalink
On Thu, 06 Jul 2006 19:01:32 -0400 in alt.folklore.computers,
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Designed in 1968 for MARC format catalog records in any of the Roman
based languages.
Post by Rostyslaw J. Lewyckyj
Also wasn't that a long gap between the 1403 and the 3800?
The 3203 (370 ~1970?) replaced the 1403 (1959), and the 3800 came out
in the 1980s: there were other common printers such as the 3211, 4245,
and 6670 in the 1970-1980 timeframe.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

***@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Rostyslaw J. Lewyckyj
2006-07-08 00:42:38 UTC
Permalink
Post by Brian Inglis
On Thu, 06 Jul 2006 19:01:32 -0400 in alt.folklore.computers,
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
What was the character set on an ALA (?) The modern languages, or
was it the Librarian Association print train?
Designed in 1968 for MARC format catalog records in any of the Roman
based languages.
So It wasn't really a problem to print lower case with a 1403 printer.
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
Post by Brian Inglis
Post by Rostyslaw J. Lewyckyj
Also wasn't that a long gap between the 1403 and the 3800?
The 3203 (370 ~1970?) replaced the 1403 (1959), and the 3800 came out
in the 1980s: there were other common printers such as the 3211, 4245,
and 6670 in the 1970-1980 timeframe.
A***@NOT.AT.Arargh.com
2006-07-08 04:35:36 UTC
Permalink
On Fri, 07 Jul 2006 20:42:38 -0400, "Rostyslaw J. Lewyckyj"
<***@bellsouth.net> wrote:

<snip>
Post by Rostyslaw J. Lewyckyj
So It wasn't really a problem to print lower case with a 1403 printer.
Not on a 360 or later. However, it would have been a bit of a pain on
a 1401, if at all possible. Or any other of the 6-bit character
systems. 64 character set. Upper case only. There was probably some
way to get a 1407 (the console typewriter) to do upper & lower, but if
so, I never learned it. The 1401 I used didn't have one.
Post by Rostyslaw J. Lewyckyj
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
<snip>
--
ArarghMail606 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.
Rostyslaw J. Lewyckyj
2006-07-08 05:13:47 UTC
Permalink
Post by A***@NOT.AT.Arargh.com
On Fri, 07 Jul 2006 20:42:38 -0400, "Rostyslaw J. Lewyckyj"
<snip>
Post by Rostyslaw J. Lewyckyj
So It wasn't really a problem to print lower case with a 1403 printer.
Not on a 360 or later. However, it would have been a bit of a pain on
a 1401, if at all possible. Or any other of the 6-bit character
systems. 64 character set. Upper case only. There was probably some
way to get a 1407 (the console typewriter) to do upper & lower, but if
so, I never learned it. The 1401 I used didn't have one.
Post by Rostyslaw J. Lewyckyj
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
<snip>
You are confounding printer hardware and computer software capabilities :)
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
Brian Inglis
2006-07-08 05:56:32 UTC
Permalink
On Sat, 08 Jul 2006 01:13:47 -0400 in alt.folklore.computers,
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
On Fri, 07 Jul 2006 20:42:38 -0400, "Rostyslaw J. Lewyckyj"
<snip>
Post by Rostyslaw J. Lewyckyj
So It wasn't really a problem to print lower case with a 1403 printer.
Not on a 360 or later. However, it would have been a bit of a pain on
a 1401, if at all possible. Or any other of the 6-bit character
systems. 64 character set. Upper case only. There was probably some
way to get a 1407 (the console typewriter) to do upper & lower, but if
so, I never learned it. The 1401 I used didn't have one.
Post by Rostyslaw J. Lewyckyj
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
<snip>
You are confounding printer hardware and computer software capabilities :)
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
IIRC all those chain/train/band printers had 240 characters, and you
could customize the chain/train by ordering different 3 character
slugs to replace some of the standard ones, and modify the UCB/UCSB to
reflect the different character sets available.
Custom chains, trains, and bands could also be ordered, but the custom
bands would probably be much more expensive.
My other post lists the standard printer character sets provided by
IBM.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

***@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
A***@NOT.AT.Arargh.com
2006-07-08 07:23:23 UTC
Permalink
On Sat, 08 Jul 2006 01:13:47 -0400, "Rostyslaw J. Lewyckyj"
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
On Fri, 07 Jul 2006 20:42:38 -0400, "Rostyslaw J. Lewyckyj"
<snip>
Post by Rostyslaw J. Lewyckyj
So It wasn't really a problem to print lower case with a 1403 printer.
Not on a 360 or later. However, it would have been a bit of a pain on
a 1401, if at all possible. Or any other of the 6-bit character
systems. 64 character set. Upper case only. There was probably some
way to get a 1407 (the console typewriter) to do upper & lower, but if
so, I never learned it. The 1401 I used didn't have one.
It's actually a 1447 console, not 1407. And the command used to write
to it doesn't know about case selection. There may be a shift
character, but I would have to find a 1447 book to find out.
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
Post by Rostyslaw J. Lewyckyj
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
<snip>
You are confounding printer hardware and computer software capabilities :)
Not entirely. The 1403 came in a bunch of different models. I don't
know, but don't think that the models that could be hung on a 14xx
could be hung on a 360. From the 1400 series books that I have, the
1403 models 1, 2, 3, 4 & 5 could be used on 1401/40/60 system. The
only 1403 I ever saw on a 360 was a 1403-N1, connected via a 2848?
2484? control unit.
Post by Rostyslaw J. Lewyckyj
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
AFAIK, yes.
Post by Rostyslaw J. Lewyckyj
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
--
ArarghMail606 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.
Nick Spalding
2006-07-08 09:15:31 UTC
Permalink
Post by A***@NOT.AT.Arargh.com
On Sat, 08 Jul 2006 01:13:47 -0400, "Rostyslaw J. Lewyckyj"
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
On Fri, 07 Jul 2006 20:42:38 -0400, "Rostyslaw J. Lewyckyj"
<snip>
Post by Rostyslaw J. Lewyckyj
So It wasn't really a problem to print lower case with a 1403 printer.
Not on a 360 or later. However, it would have been a bit of a pain on
a 1401, if at all possible. Or any other of the 6-bit character
systems. 64 character set. Upper case only. There was probably some
way to get a 1407 (the console typewriter) to do upper & lower, but if
so, I never learned it. The 1401 I used didn't have one.
It's actually a 1447 console, not 1407. And the command used to write
to it doesn't know about case selection. There may be a shift
character, but I would have to find a 1447 book to find out.
I looked after a couple of them attached to 1440s and I have no recollection
of any such thing.
Post by A***@NOT.AT.Arargh.com
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
Post by Rostyslaw J. Lewyckyj
It was just that at the printer which Eugene chose to use they normally
provided (mounted) the TN train. The hardware was versitile enough and
there was support for umpteen different print trains.
Also the 3800 appears to have been (still is ??) awesome. 20,000 LPM.
or some 150 pages/min. pulling paper from a 5 foot diameter paper roll.
Definitely a print shop production machine, not for mailing labels at
a University computing center job shop.
<snip>
You are confounding printer hardware and computer software capabilities :)
Not entirely. The 1403 came in a bunch of different models. I don't
know, but don't think that the models that could be hung on a 14xx
could be hung on a 360. From the 1400 series books that I have, the
1403 models 1, 2, 3, 4 & 5 could be used on 1401/40/60 system. The
only 1403 I ever saw on a 360 was a 1403-N1, connected via a 2848?
2484? control unit.
Post by Rostyslaw J. Lewyckyj
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
AFAIK, yes.
Post by Rostyslaw J. Lewyckyj
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
--
Nick Spalding
Anne & Lynn Wheeler
2006-07-08 15:14:15 UTC
Permalink
Post by A***@NOT.AT.Arargh.com
Not entirely. The 1403 came in a bunch of different models. I don't
know, but don't think that the models that could be hung on a 14xx
could be hung on a 360. From the 1400 series books that I have, the
1403 models 1, 2, 3, 4 & 5 could be used on 1401/40/60 system. The
only 1403 I ever saw on a 360 was a 1403-N1, connected via a 2848?
2484? control unit.
My first student job was to port a 1401 MPIO program to 360/30. MPIO
did the unit record (cards) to tape and tape to unit record
(print/punch) front end for the univ. 709. For a while they had both
the 1401 and the 360/30 side-by-side ... and then they removed the
real 1401 and would switch the 360/30 back-and-forth between 360 mode
and 1401 hardware emulation mode.

controller reference:
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm

from above:

2803
Tape Control Unit for S/360.

Used to attach 2401 drives.

2821
Unit Record Preipheral Control Unit for S/360. Used to attach 1403
and 2540 to multiplexer channel. Typically, the 1052 console
typewriter would be at I/O address 009, the printer would be at
00F and a second printer at 00E.

2822
Tape reader control unit used to attach 2671 to S/360.

2841
DASD Control Unit for S/360.

Used to attach 2303 drum, 2311 disk and 2321 Data Cell.

2848
Display cluster controller for 2260 display heads.

Used an acoustic delay line to hold the screen buffer. The
character generator used a magnetic core ROM to hold the character
dot matrix lookup table.

... snip ...

1401 reference:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html

In the above, it talks about 1403 operating at 600 lines/minute. I think
this is the 1403-7 ... it still had manual cover lift and the paper
box feed was exposed.

The 360/30 had a 1403-N1 that operated at 1100 lines/minute, and had a
hydraulic lift cover ... that completely enclosed the paper box feed.
The top of the 1403-N1 was convenient height for placing things
(coffee cups, card trays, etc), however, the 1403-N1 had this habit of
automatically raising the cover when it ran out of paper. This top was
hinged on the back so as the cover raised, the top went from
horizontal to nearly veritical position.

The univ. 360/30 had 1052-7 operators console at address '009', the
2540 card reader at address '00C', the 2540 punch at address '00D',
and the 1403 at address '00E'.

For the MPIO port, I got to design and implement my own stand-alone
monitor, interrupt handlers, device drivers, storage management,
task management, etc.

previous 1403 post
http://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That

random past posts mentioning MPIO port:
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/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
http://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#59 Living legends
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
http://www.garlic.com/~lynn/2001k.html#31 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002b.html#13 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002b.html#15 Infiniband's impact was Re: Intel's 64-bit strategy
http://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002f.html#48 How Long have you worked with MF's ? (poll)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002o.html#19 The Hitchhiker's Guide to the Mainframe
http://www.garlic.com/~lynn/2002q.html#29 Collating on the S/360-2540 card reader?
http://www.garlic.com/~lynn/2003h.html#30 Hardware support of "new" instructions
http://www.garlic.com/~lynn/2003i.html#8 A Dark Day
http://www.garlic.com/~lynn/2003i.html#12 Which monitor for Fujitsu Micro 16s?
http://www.garlic.com/~lynn/2003i.html#51 Oldest running software
http://www.garlic.com/~lynn/2004f.html#49 can a program be run withour main memory?
http://www.garlic.com/~lynn/2004g.html#39 spool
http://www.garlic.com/~lynn/2004k.html#40 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2004q.html#66 Will multicore CPUs have identical cores?
http://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
http://www.garlic.com/~lynn/2005g.html#52 Software for IBM 360/30
http://www.garlic.com/~lynn/2005n.html#3 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006b.html#2 Mount a tape
http://www.garlic.com/~lynn/2006g.html#43 Binder REP Cards (Was: What's the linkage editor really wants?)
http://www.garlic.com/~lynn/2006l.html#64 Large Computer Rescue
A***@NOT.AT.Arargh.com
2006-07-08 20:28:51 UTC
Permalink
On Sat, 08 Jul 2006 09:14:15 -0600, Anne & Lynn Wheeler
Post by Anne & Lynn Wheeler
Post by A***@NOT.AT.Arargh.com
Not entirely. The 1403 came in a bunch of different models. I don't
know, but don't think that the models that could be hung on a 14xx
could be hung on a 360. From the 1400 series books that I have, the
1403 models 1, 2, 3, 4 & 5 could be used on 1401/40/60 system. The
only 1403 I ever saw on a 360 was a 1403-N1, connected via a 2848?
2484? control unit.
Ok, a 2821. :-) Never could remember all those numbers.
Post by Anne & Lynn Wheeler
My first student job was to port a 1401 MPIO program to 360/30. MPIO
did the unit record (cards) to tape and tape to unit record
(print/punch) front end for the univ. 709. For a while they had both
the 1401 and the 360/30 side-by-side ... and then they removed the
real 1401 and would switch the 360/30 back-and-forth between 360 mode
and 1401 hardware emulation mode.
<snip controller ref>
Post by Anne & Lynn Wheeler
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html
In the above, it talks about 1403 operating at 600 lines/minute. I think
this is the 1403-7 ... it still had manual cover lift and the paper
box feed was exposed.
I think that all of models 1-6 looked like that. Merging data from
several old 1400 series books:

1403 model LPM #Cols
1 600 ? not given but probably 132
2 600 132
3 1100 132
4 465 100
5 465 132
6 340 120

So, I would guess a 1403-2 for the above.
Post by Anne & Lynn Wheeler
The 360/30 had a 1403-N1 that operated at 1100 lines/minute, and had a
hydraulic lift cover ... that completely enclosed the paper box feed.
The top of the 1403-N1 was convenient height for placing things
(coffee cups, card trays, etc), however, the 1403-N1 had this habit of
automatically raising the cover when it ran out of paper. This top was
hinged on the back so as the cover raised, the top went from
horizontal to nearly veritical position.
I remember already! Once I caught a disk pack on the way to the
floor, and a couple of times, listings. And missed listings several
times. Usually core dumps.
Post by Anne & Lynn Wheeler
The univ. 360/30 had 1052-7 operators console at address '009', the
2540 card reader at address '00C', the 2540 punch at address '00D',
and the 1403 at address '00E'.
For the MPIO port, I got to design and implement my own stand-alone
monitor, interrupt handlers, device drivers, storage management,
task management, etc.
IIFC, I knew someone who modified that (or something that did the same
thing) to run 2 1401 sessions at the same time.
Post by Anne & Lynn Wheeler
previous 1403 post
http://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That
<snip>
--
ArarghMail606 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.
David Wade
2006-07-08 10:47:53 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
<snip>
You are confounding printer hardware and computer software capabilities :)
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
The big problem with the TN train was that it slowed the printer down. I
can't remember how many actual slugs there are on the train, but I guess
around 300 (2 time times 120 plus extra for the drive drum). So with a 64
character set there would have been 5 copies of the charcert set, with the
TN only 2 or 3. This means you had to wait longer for characters to come
round slowiung the printer down. When I was at University using the TN chain
made you very unpopular...
Rostyslaw J. Lewyckyj
2006-07-08 18:40:36 UTC
Permalink
Post by David Wade
Post by Rostyslaw J. Lewyckyj
Post by A***@NOT.AT.Arargh.com
<snip>
You are confounding printer hardware and computer software capabilities :)
The 1403 printer was certainly capable of printing whatever characters
were on the slugs of the print train, and certainly one could use
print trains with more than 64 different characters, as proved on the
360. If and how they might have used that from an IBM 1401 series
computer, I don't know. But supposedly the printer was introduced before
the 360. So ...
Now I don't know how many different characters could be on a print
train. i.e. number of slugs x characters/slug. Nor do I know whether,
if this was >256, they could all be somehow controlled.
Anyway Eugene did say "barely capable" of lower case, though he did
say (with the TN train. :) ).
The big problem with the TN train was that it slowed the printer down. I
can't remember how many actual slugs there are on the train, but I guess
around 300 (2 time times 120 plus extra for the drive drum). So with a 64
character set there would have been 5 copies of the charcert set, with the
TN only 2 or 3. This means you had to wait longer for characters to come
round slowiung the printer down. When I was at University using the TN chain
made you very unpopular...
Yes, sure. But unpopular is different from barely capable.
Certainly printing output that required :
Special forms and special print loop and mounting an alternate
print train and which perhaps did overprinting would be unpopular
for a production (unscheduled job shop) environment.
Oh and I forgot to include use of a fresh, special ribbon.
--
Rostyk

Just be sure to remove your coffee mug from on top of the automatic
printer lid. :)
j***@aol.com
2006-07-07 10:28:22 UTC
Permalink
Post by Eugene Miya
Post by Walter Bushell
Post by Peter Flass
mod20 was also called the Multifunction Card Machine.
Not exactly. The MFCM (Multifunction Card Machine, but feel free tom
a popular peripheral for the model 20.
I believe the 20 might have been the first minicomputer, although it was
Not likely.
CDC 160, PDP-1, LINC, TX-2, etc.
Post by Walter Bushell
Post by Peter Flass
still bigger than a desk, even without the peripherals. Unlike systems
today which have gron "up", so that, for example, 16-bit quantities are
called "words" in Intel-speak, so 32-bit quantities then have to be
"doublewords", the /20 was a "shrunk" 360, with only the halfword (and
decimal apparently) instructions.
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
A real programmer will program anything. If there isn't a computer
handy, use a printer, programmmable calculator, or cell-phone!
Can be interesting.
Post by Walter Bushell
In the beginning the printer had an advanced cpu compared to the
computer. Mac 68000, printer 68020 (early LaserWriter.) And, I believe
more memory.
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
CPU?
Exercise: program a seemingly innocuous device like a printer (thought
as an output only) to subvert and control an air defense system.
ROTFLMAO. Dump the printer, and code the -11 it was hung on.

/BAH
Eugene Miya
2006-07-07 15:47:05 UTC
Permalink
Post by j***@aol.com
Post by Eugene Miya
Exercise: program a seemingly innocuous device like a printer (thought
as an output only) to subvert and control an air defense system.
ROTFLMAO. Dump the printer, and code the -11 it was hung on.
The trick is the dump.
Then you can take over a country.

--
Anne & Lynn Wheeler
2006-07-07 19:33:54 UTC
Permalink
Post by Eugene Miya
I don't know about you guys but the 1403 printer I used barely had the
ability to print lower case (TN train). I did see a 3800 later.
1403 was from 1401 comptuer and adopted for 360. there were several
1403 models. 3211 printer followed the 1403 ... before the 3800 came
along in the mid-70s. part of the issue was that datacenters sometimes
only loaded TN train for special print jobs ... since the
non-lower-case chain would print much faster (i.e. the characters were
repeated more often ... so the latency for specific character slug to
come under hammer was less).

following from old posting mentioning 3800
http://www.garlic.com/~lynn/2005f.html#48 1403 pirnters

note that this was much more "personal" laser printer. from the
mid-70s, there had been the 3800 datacenter laser printer ... which
had paper feed rates measured in feet per second. some datacenters
bypassed the boxed paper feed ... and had huge paper rolls feeding
directly into 3800 (4-5 ft in diameter). this shouldn't be confused
with the later 3820 laser printer ... which was desktop unit.

minor ref:
http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV3103.html

from above:

The IBM 3800 laser-electrophotographic printer of 1975 had a speed of
20,000 lines a minute in preparing bank statements, premium notices
and other high-volume documents. Laser beam paths were altered
millions of times a second and were reflected from an 18-sided mirror
that spun at 12,000 revolutions per minute. (VV3103)

... snip ...

some pictures:
http://ukcc.uky.edu/~ukccinfo/ibm3800.html
http://www-03.ibm.com/ibm/history/history/year_1976.html
http://pw1.netcom.com/~zmoq/pages/ibm370.htm
A***@NOT.AT.Arargh.com
2006-07-06 18:38:13 UTC
Permalink
On Thu, 06 Jul 2006 11:01:36 GMT, Peter Flass <***@Yahoo.com>
wrote:

<snip>
Post by Peter Flass
Not exactly. The MFCM (Multifunction Card Machine, but feel free tom
use one of many less favorable definitions of the acronym) was a popular
peripheral for the model 20. I mentioned the attraction of the /20 from
the "card whallopers." The MFCM could read, punch, and interpret card
decks under program control; it replaced a whole roomful of tab equipment.
ISTR, "Mother Fletchers Card Mangler"
Post by Peter Flass
I believe the 20 might have been the first minicomputer, although it was
still bigger than a desk, even without the peripherals. Unlike systems
today which have gron "up", so that, for example, 16-bit quantities are
called "words" in Intel-speak, so 32-bit quantities then have to be
"doublewords", the /20 was a "shrunk" 360, with only the halfword (and
decimal apparently) instructions.
Yes, and IIRC, only regs 8 to 15, and I think that they were 16 bit.

<snip>
--
ArarghMail606 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.
John Savard
2006-07-08 00:37:28 UTC
Permalink
Post by Peter Flass
I believe the 20 might have been the first minicomputer, although it was
still bigger than a desk, even without the peripherals.
Why? There were plenty of smaller computers before it.

The Packard-Bell 250, for example.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Eugene Miya
2006-07-06 16:42:18 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
What language was your program written in?
I didn't program it.
I can't remember precisely what data I was using, but I can remember
that it was at least a full step about mere sorting because otherwise
I could have just used the IBM card sorter at the time
Post by Rostyslaw J. Lewyckyj
Why didn't you use a DEC? (was it perhaps before DECs)?
No, I had access to a PDP-8I in a different dept. (psych) at the time.
But that was the dominant culture at the time: IBM shop.
You really have to realize IBM's dominance. DEC systems were seen as
for toy problems.
Interaction was very expensive at the time (but I was lucky in our IBM
environment and not TSO [I had to learn 2 obscure languages never to be
seen again {special hardware, more is not better}]).
My limited ARPAnet DEC-10/ASCII experience had not yet educated me to
rigid thinking IBM has/had (there were IBM hackers, Lynn was one).
Post by Rostyslaw J. Lewyckyj
As I understand it the mod20 was also called the Multifunction Card
Machine. I.e. that was its intended purpose, although it was more
versitile.
Though I have heard of people even programming computation tasks
in postscript to be run on printer engines. :)
MCM is a good characterization.
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
Ramble snipped.
Post by John Savard
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine,
And that's supposed to be good?
Ah.., What was the intended purpose design goal for the IBM 1620?
The corporate line (which I remember from friends who programmed them
when in high school over at the local comm. college):
targeted to mid-sized businesses and educational environments
as an affordable computing adjunct, etc etc etc.
Emphasis on affordable.
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
Post by John Savard
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
Well, not every thing is Fortran.
Very few people use mantissas of 16 digits.
Very few people think about numeric precision in long iteration problems.

--
j***@aol.com
2006-07-07 10:31:31 UTC
Permalink
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
What language was your program written in?
I didn't program it.
I can't remember precisely what data I was using, but I can remember
that it was at least a full step about mere sorting because otherwise
I could have just used the IBM card sorter at the time
Post by Rostyslaw J. Lewyckyj
Why didn't you use a DEC? (was it perhaps before DECs)?
No, I had access to a PDP-8I in a different dept. (psych) at the time.
But that was the dominant culture at the time: IBM shop.
You really have to realize IBM's dominance. DEC systems were seen as
for toy problems.
<GRIN> And physicists loved playing with those toys. So
did dirty production floors.


<snip>

/BAH
Eugene Miya
2006-07-07 15:55:02 UTC
Permalink
Post by j***@aol.com
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Why didn't you use a DEC? (was it perhaps before DECs)?
No, I had access to a PDP-8I in a different dept. (psych) at the time.
But that was the dominant culture at the time: IBM shop.
You really have to realize IBM's dominance. DEC systems were seen as
for toy problems.
<GRIN> And physicists loved playing with those toys.
So did dirty production floors.
Not all physicists.
And that was not a typo.
It was the psychology dept. where I later became a work study student
for 3 years.

Getting physicists to use computers is worse than pulling teeth.
Tim Berners-Lee learned that. Computers and computer people are merely
pawns to them.

Some physics problems even with computers are just hard.
Where DEC excelled was in biology, neurology, real-time process control
(we could have had a Data General future [one 80s DG ad was almost as
good as the Apple 1984 ad in my view, except lost to some older
generation managers]).

In part that's what killed DEC, you guys, as a firm. DEC was never able
to get out of its "mini-"computer mode. Even midis like the 20 and
planned Jupiter could not have helped. Watson did a real number on his
competition and internally. For me, thankfully, I followed the Cray line.
He didn't give a shit about compatibility. If you wanted the fastest
machines in the world, bar none, you took what he gave you.
And he never underestimated the numbers of needed cycles.
He was able to follow a niche. Different times.
And now Gates is attempting to learn from Watson's mistakes
and the mistakes of Netscape, the Web, etc. which the brick and mortar
world remains clueless to him.

--
Anne & Lynn Wheeler
2006-07-07 17:23:11 UTC
Permalink
Post by Eugene Miya
Getting physicists to use computers is worse than pulling teeth.
Tim Berners-Lee learned that. Computers and computer people are merely
pawns to them.
Some physics problems even with computers are just hard. Where DEC
excelled was in biology, neurology, real-time process control (we
could have had a Data General future [one 80s DG ad was almost as
good as the Apple 1984 ad in my view, except lost to some older
generation managers]).
we had some success at slac ... we use to have monthly meetings there
... slac & cern are sister organizations ... and the first webserver
in the US was at SLAC on a vm system
http://www.slac.stanford.edu/history/earlyweb/history.shtml

and http traces it history back thru a copy of waterloo's cms script
clone supporting sgml/gml (which was in heavy use at cern)
http://infomesh.net/html/history/early/

which had originally been invented at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

misc. gml, sgml, etc posts
http://www.galric.com/~lynn/subtopic.html#sgml

Series/1 saw some large deployment in sensor markets. There is joke
about the "standard" operating system for Series/1, RPS ... being a
bunch of old os/360 "MFT" developers moving to boca and attempting to
re-invent MFT on series/1.

Some physicists at san jose research ... attempting to use Series/1
for various physics applications ... eventually came up with "EDX" as
a replacement for RPS (mid-70s?).
David Wade
2006-07-08 10:52:34 UTC
Permalink
Post by Anne & Lynn Wheeler
Post by Eugene Miya
Getting physicists to use computers is worse than pulling teeth.
Tim Berners-Lee learned that. Computers and computer people are merely
pawns to them.
Some physics problems even with computers are just hard. Where DEC
excelled was in biology, neurology, real-time process control (we
could have had a Data General future [one 80s DG ad was almost as
good as the Apple 1984 ad in my view, except lost to some older
generation managers]).
we had some success at slac ... we use to have monthly meetings there
... slac & cern are sister organizations ... and the first webserver
in the US was at SLAC on a vm system
http://www.slac.stanford.edu/history/earlyweb/history.shtml
and http traces it history back thru a copy of waterloo's cms script
clone supporting sgml/gml (which was in heavy use at cern)
http://infomesh.net/html/history/early/
which had originally been invented at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
misc. gml, sgml, etc posts
http://www.galric.com/~lynn/subtopic.html#sgml
Series/1 saw some large deployment in sensor markets. There is joke
about the "standard" operating system for Series/1, RPS ... being a
bunch of old os/360 "MFT" developers moving to boca and attempting to
re-invent MFT on series/1.
The certainly ran all the door badge readers in IBM UK for many years....
Post by Anne & Lynn Wheeler
Some physicists at san jose research ... attempting to use Series/1
for various physics applications ... eventually came up with "EDX" as
a replacement for RPS (mid-70s?).
We used RPS because it had X.25 support build in and 360 channel
connectivity....
The door machines used EDX and every one wondered why I could never fix
them...
s***@situ.com
2006-07-07 22:41:11 UTC
Permalink
In article <44ae83d6$***@darkstar>, Eugene Miya <***@cse.ucsc.edu> wrote:

snip--
Post by Eugene Miya
Getting physicists to use computers is worse than pulling teeth.
as a once and sometime fizicist, i feel compelled to claim that
however grave our shortcomings might be at using computers,
we have few peers at abusing them

my attitude about computers used to be: trust, but verify.
these days, i have dropped the 'trust' part

i find it deeply satisfying to directly measure the deflection of
a light beam bounced off a mirror on a twisting quartz fiber using my
eyeball, and to then compare the number with the purported result of a
photocell voltage massaged through many layers of hardware and software
logic.

or illogic as i have often found...

snip--
Post by Eugene Miya
Some physics problems even with computers are just hard.
for some reason that sentence caused me to giggle

on a more serious note: i believe it was Chandrashekhar who lamented
the decay of analytic skills among physicists, in favor of numerical
methods. while it is dangerous to disagree with him, as Eddington found,
Chandrashekhar also remarked that it took him a hundred and fifty pages
of calculation to proceed from a certain equation to the next in his
classic on the radiative hydrodynamics of stars.

sidd
j***@aol.com
2006-07-08 10:05:37 UTC
Permalink
Post by s***@situ.com
snip--
Post by Eugene Miya
Getting physicists to use computers is worse than pulling teeth.
as a once and sometime fizicist, i feel compelled to claim that
however grave our shortcomings might be at using computers,
we have few peers at abusing them
my attitude about computers used to be: trust, but verify.
these days, i have dropped the 'trust' part
Right. The old DEC used to do a lot of the verification
before shipping. As time went on, only TOPS-10 continued
to do this.
Post by s***@situ.com
i find it deeply satisfying to directly measure the deflection of
a light beam bounced off a mirror on a twisting quartz fiber using my
eyeball, and to then compare the number with the purported result of a
photocell voltage massaged through many layers of hardware and software
logic.
or illogic as i have often found...
snip--
Post by Eugene Miya
Some physics problems even with computers are just hard.
for some reason that sentence caused me to giggle
on a more serious note: i believe it was Chandrashekhar who lamented
the decay of analytic skills among physicists, in favor of numerical
methods. while it is dangerous to disagree with him, as Eddington found,
Chandrashekhar also remarked that it took him a hundred and fifty pages
of calculation to proceed from a certain equation to the next in his
classic on the radiative hydrodynamics of stars.
This may make an argument for not making computers "easier" to
use. About 9 years ago, I tried to do an unscientific survey
in newsgroups to see how many college kiddies were creating
their own sanity check software package which they would continue
to add, improve, and carry with them throughout their future
work years. Not many. And no profs seemed to be mentioning
this.

We are still suffering from "the computer said so" mentality.
The attitude has become so pervasive that the people who make
the gear and software assume it. As a result, this assumption
is built into the work processes and procedures.

/BAH
Rostyslaw J. Lewyckyj
2006-07-08 17:41:08 UTC
Permalink
Post by j***@aol.com
This may make an argument for not making computers "easier" to
use. About 9 years ago, I tried to do an unscientific survey
in newsgroups to see how many college kiddies were creating
their own sanity check software
Oh dear. How ever did you think that you could get valid results
about sanity checks, on usenet newsgroups. :)
Newsgroups, sanity?, newsgroups?? ... BWAHAHAha. :)
Post by j***@aol.com
package which they would continue
to add, improve, and carry with them throughout their future
work years. Not many. And no profs seemed to be mentioning
this.
We are still suffering from "the computer said so" mentality.
Nah.. they are now in the state of believing 'a prolific pundit
(talking Politics) in a technical newsgroup' who wrote last week.
Post by j***@aol.com
The attitude has become so pervasive that the people who make
the gear and software assume it. As a result, this assumption
is built into the work processes and procedures.
-- Rostyk :)
Post by j***@aol.com
/BAH
b***@myrealbox.com
2006-07-08 18:56:27 UTC
Permalink
In article <e8o01h$***@s895.apx1.sbo.ma.dialup.rcn.com>,
<***@aol.com> wrote:

[ snip ]
Post by j***@aol.com
This may make an argument for not making computers "easier" to
use. About 9 years ago, I tried to do an unscientific survey
in newsgroups to see how many college kiddies were creating
their own sanity check software package which they would continue
to add, improve, and carry with them throughout their future
work years. Not many. And no profs seemed to be mentioning
this.
Well, I might give it (mentioning this to students) a try sometime,
but I'm not clear on what you mean by "sanity check software package".
Maybe an example or two of kinds of things such a package would do?
The kinds of sanity checks that mostly come to my mind are ones in
which a human evaluates whether the answer provided by a computer or
calculator is reasonable .... ?

[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Brian Inglis
2006-07-08 00:42:59 UTC
Permalink
On 7 Jul 2006 08:55:02 -0700 in alt.folklore.computers,
Post by Eugene Miya
And now Gates is attempting to learn from Watson's mistakes
and the mistakes of Netscape, the Web, etc. which the brick and mortar
world remains clueless to him.
ISTM Gates has given up the keys to Ballmer and got a life:
even the gaming biz doesn't seem to have held his attention for long.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada

***@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
j***@aol.com
2006-07-08 09:55:48 UTC
Permalink
Post by Eugene Miya
Post by j***@aol.com
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Why didn't you use a DEC? (was it perhaps before DECs)?
No, I had access to a PDP-8I in a different dept. (psych) at the time.
But that was the dominant culture at the time: IBM shop.
You really have to realize IBM's dominance. DEC systems were seen as
for toy problems.
<GRIN> And physicists loved playing with those toys.
So did dirty production floors.
Not all physicists.
And that was not a typo.
It was the psychology dept. where I later became a work study student
for 3 years.
I didn't misread what you wrote.
Post by Eugene Miya
Getting physicists to use computers is worse than pulling teeth.
I know. There is also a good way to train them. The key
was timesharing and allowing them to shut their office and make
the stupid mistakes all newbies make.
Post by Eugene Miya
Tim Berners-Lee learned that. Computers and computer people are merely
pawns to them.
What they need is a tool that does not require 100 hr/day wrestling
to get their real work done. VMS provided this service. In addition,
when help was needed, it provided it but ONLY when requested.
That is what delivery of computing services is supposed to be. All
the biz has now is crap and this includes the beloved Unix...so far.
It'll take Unix about 5? years to catch up, iff the tradeoffs are
for timesharing and delivery of computing services. If it starts
to favor presenting pretty pictures instead of real work, it'll be
in the same category as micshit.
Post by Eugene Miya
Some physics problems even with computers are just hard.
Of course. They are ones who do the stuff first in the history
of mankind. That's why they need a tool that requires 0% wrestling
and 100% delivery of services with help only when requested.
Post by Eugene Miya
Where DEC excelled was in biology, neurology, real-time process control
(we could have had a Data General future [one 80s DG ad was almost as
good as the Apple 1984 ad in my view, except lost to some older
generation managers]).
In part that's what killed DEC, you guys, as a firm. DEC was never able
to get out of its "mini-"computer mode.
Haven't I been saying this for 10 years? Everytime I wrote the
phrase "small computer thinking" I was talking about this
woodenheadedness.
Post by Eugene Miya
Even midis like the 20 and
planned Jupiter could not have helped.
We knew that. But we couldn't fix the arrogance.
Post by Eugene Miya
Watson did a real number on his
competition and internally. For me, thankfully, I followed the Cray line.
He didn't give a shit about compatibility.
And that's why not many people have access to that computing service.
Crays were not designed for data processing. The were compute devices
and should have been used as such.
Post by Eugene Miya
If you wanted the fastest
machines in the world, bar none, you took what he gave you.
And he never underestimated the numbers of needed cycles.
He was able to follow a niche. Different times.
And now Gates is attempting to learn
Gates does not learn from mistakes. This is his arrogance; he
believes he knows better than everybody else.
Post by Eugene Miya
from Watson's mistakes
and the mistakes of Netscape, the Web, etc. which the brick and mortar
world remains clueless to him.
/BAH
Charles Richmond
2006-07-06 07:06:23 UTC
Permalink
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.


--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
John Savard
2006-07-06 07:53:58 UTC
Permalink
On Thu, 06 Jul 2006 02:06:23 -0500, Charles Richmond
Post by Charles Richmond
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.
My original defense of the Model 20, such as it was, was a reaction to
some articles I read that took the view that its incompatibility with
the regular System/360, and, more specifically, the limitations on the
data types it could work with, made it nearly useless.

In fact, its instruction set, because it did include the decimal
instructions, was large enough to do useful work, particularly for
people who had been using a 1401 or related computer before.

And the other major incompatibility - the availability of an instruction
format that avoided using a base register - wasn't a bad idea, and, in
fact, could have been used to good effect on some of their other models
that had maximum memory capacities of 32 Kbytes or less. (The Model 25
would support switching into "Model 20 mode", in fact.)

The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Microprogramming a big-computer instruction set certainly wasn't the
cheapest way to build a small-size computer, and that was a valid
price/performance criticism of all the lower-end models in the 360
family. But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.

Computer-savvy engineers could switch over from a PDP-15 with a
floating-point attachment to a PDP-10 when they needed to. They didn't
need to pay PDP-11 prices for a box with PDP-8 performance pretending to
be a PDP-10.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Nick Spalding
2006-07-06 08:07:37 UTC
Permalink
Post by John Savard
On Thu, 06 Jul 2006 02:06:23 -0500, Charles Richmond
Post by Charles Richmond
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.
My original defense of the Model 20, such as it was, was a reaction to
some articles I read that took the view that its incompatibility with
the regular System/360, and, more specifically, the limitations on the
data types it could work with, made it nearly useless.
In fact, its instruction set, because it did include the decimal
instructions, was large enough to do useful work, particularly for
people who had been using a 1401 or related computer before.
And the other major incompatibility - the availability of an instruction
format that avoided using a base register - wasn't a bad idea, and, in
fact, could have been used to good effect on some of their other models
that had maximum memory capacities of 32 Kbytes or less. (The Model 25
would support switching into "Model 20 mode", in fact.)
That was one of the selling points of the 25, it was a bridge for 20 users
to trade up to a real 360. It wasn't simply a matter of switching, you had
to load a different microprogram off a card deck to make it look like either
a 20 or more-or-less a 30.
Post by John Savard
The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Microprogramming a big-computer instruction set certainly wasn't the
cheapest way to build a small-size computer, and that was a valid
price/performance criticism of all the lower-end models in the 360
family. But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
Computer-savvy engineers could switch over from a PDP-15 with a
floating-point attachment to a PDP-10 when they needed to. They didn't
need to pay PDP-11 prices for a box with PDP-8 performance pretending to
be a PDP-10.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
--
Nick Spalding
Walter Bushell
2006-07-06 16:25:20 UTC
Permalink
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
--
"The power of the Executive to cast a man into prison without formulating any
charge known to the law, and particularly to deny him the judgement of his
peers, is in the highest degree odious and is the foundation of all totali-
tarian government whether Nazi or Communist." -- W. Churchill, Nov 21, 1943
AZ Nomad
2006-07-06 17:22:53 UTC
Permalink
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
Microsoft's fetish is *against* backwards compatibility. Every time
microsoft has had a major release (3.1->9x->W2k), microsoft has expected
everybody to replace all their software to have it work well
with the new OS. Try running a win31 app on win9x and the whole system will
stop everytime the win31 app fails to make a timely pause. Try running a
win9x application in XP and you'll find you have to be logged in as an
administrator or the app won't run. Even office2K can't install so much as
a language dictionary without the user being an admin.
Roland Hutchinson
2006-07-06 18:33:51 UTC
Permalink
Post by AZ Nomad
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
Microsoft's fetish is *against* backwards compatibility. Every time
microsoft has had a major release (3.1->9x->W2k), microsoft has expected
everybody to replace all their software to have it work well
with the new OS. Try running a win31 app on win9x and the whole system
will stop everytime the win31 app fails to make a timely pause. Try
running a win9x application in XP and you'll find you have to be logged in
as an
administrator or the app won't run. Even office2K can't install so much
as a language dictionary without the user being an admin.
Just because the backward compatibility is designed broken doesn't mean it's
not a fetish.

I suspect that the actual design goal is to provide a plausible pretext of
backward compatibility: the new OS runs not much worse than the old when
running old apps, but never well enough to keep you from wanting to upgrade
the apps.

Apple has historically handled backward compatibility a bit more smoothly
than MS while running through four major changes of processor architecture
overlapping with (and independent of) a similar number of radical OS
revisions. But there have been plenty of new software purchases needed for
that platform, too, as the OS changes rolled forward.
--
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.
AZ Nomad
2006-07-06 21:19:48 UTC
Permalink
Post by Roland Hutchinson
Apple has historically handled backward compatibility a bit more smoothly
than MS while running through four major changes of processor architecture
So has DEC. So did digital research. So does every flavor of UNIX. Ditto
for linux.
In fact, just about everybody handles backward compatibility better
than microsoft.
Post by Roland Hutchinson
overlapping with (and independent of) a similar number of radical OS
revisions. But there have been plenty of new software purchases needed for
that platform, too, as the OS changes rolled forward.
Roland Hutchinson
2006-07-06 22:55:07 UTC
Permalink
On Thu, 06 Jul 2006 18:33:51 GMT, Roland Hutchinson
Post by Roland Hutchinson
Apple has historically handled backward compatibility a bit more smoothly
than MS while running through four major changes of processor architecture
So has DEC. So did digital research. So does every flavor of UNIX.
Ditto for linux.
In fact, just about everybody handles backward compatibility better
than microsoft.
Indeed. My point (if I had one) perhaps being that Apple did less well in
this regard than the Real Operating Systems (especially during Apple's
pre-Real Operating System period), but still better than MS.
Post by Roland Hutchinson
overlapping with (and independent of) a similar number of radical OS
revisions. But there have been plenty of new software purchases needed
for that platform, too, as the OS changes rolled forward.
--
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.
Charlie Gibbs
2006-07-07 00:04:42 UTC
Permalink
On Thu, 06 Jul 2006 18:33:51 GMT, Roland Hutchinson
Post by Roland Hutchinson
Apple has historically handled backward compatibility a bit more
smoothly than MS while running through four major changes of
processor architecture
So has DEC. So did digital research. So does every flavor of UNIX.
Ditto for linux.
In fact, just about everybody handles backward compatibility better
than microsoft.
Now that's just plain unfair. Microsoft has been very good about
preserving backward compatibility, as long as it maximizes damage.
Hence we still have that 0x1a character causing data to be lost
from the end of text files, file systems that lock up so tight
that you have to reboot to replace running programs, scroll bars
that slip out of your grasp and snap back to their original position
if your mouse wanders too far away even if you keep the button
depressed... Yes, Microsoft has a long and glorious history of
fixing everything except the things that need to be fixed. Or,
to recycle a phrase I normally use on Intel:

"Microsoft put the 'backward' in 'backward compatibility'."
--
/~\ ***@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!
Rostyslaw J. Lewyckyj
2006-07-06 22:25:00 UTC
Permalink
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names, be able to have
a long window (screen history) that one could scroll, and a few more
such improvements, it would sure be nice. :)
m***@aol.com
2006-07-06 23:56:06 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names,
You mean like this?

C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.

C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E

Directory of C:\Python24\user\long_file_names

07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Post by Rostyslaw J. Lewyckyj
be able to have
a long window (screen history) that one could scroll,
Like this?

"goto Python24: Properties
Layout: Screen Buffer Size
Width: 132
Height: 1000
Window Size
Width: 132
Height: 60
Post by Rostyslaw J. Lewyckyj
and a few more
such improvements, it would sure be nice. :)
Maybe you need to upgrade. Or maybe you aren't aware of all
the undocumented improvements.
Rostyslaw J. Lewyckyj
2006-07-07 02:15:07 UTC
Permalink
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E
Directory of C:\Python24\user\long_file_names
07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Yeah. The file name in the leftmost column gets converted an
8.3 form with ~nnn type names. And if you want to use the long
form name of a directory or file it gets messy with "" enclosures
and sometimes inconsistant. e.g. C:\"program files" or
c:\progra~1 , My Download files becomes Mydown~1 etc.
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
be able to have
a long window (screen history) that one could scroll,
Like this?
"goto Python24: Properties
Layout: Screen Buffer Size
Width: 132
Height: 1000
Window Size
Width: 132
Height: 60
That's one I don't know. Which version of DOS is it available on?
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
and a few more
such improvements, it would sure be nice. :)
Maybe you need to upgrade. Or maybe you aren't aware of all
the undocumented improvements.
Indeed, possibly i'm not. So if they are undocumented, how do
I find the documentation? :)
I'll keep you in mind for questions. :)
AZ Nomad
2006-07-07 02:39:16 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E
Directory of C:\Python24\user\long_file_names
07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Yeah. The file name in the leftmost column gets converted an
8.3 form with ~nnn type names. And if you want to use the long
form name of a directory or file it gets messy with "" enclosures
and sometimes inconsistant. e.g. C:\"program files" or
c:\progra~1 , My Download files becomes Mydown~1 etc.
You both are confusing the microsoft windows NT/WK/XP "command prompt"
windows with a DOS session. They're not DOS. Run command.com instead of
cmd.exe, rerun that long filename test, and you'll see how DOS has no
capability to handle long filenames.
m***@aol.com
2006-07-07 05:55:38 UTC
Permalink
Post by AZ Nomad
Post by Rostyslaw J. Lewyckyj
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E
Directory of C:\Python24\user\long_file_names
07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Yeah. The file name in the leftmost column gets converted an
8.3 form with ~nnn type names. And if you want to use the long
form name of a directory or file it gets messy with "" enclosures
and sometimes inconsistant. e.g. C:\"program files" or
c:\progra~1 , My Download files becomes Mydown~1 etc.
You both are confusing the microsoft windows NT/WK/XP "command prompt"
windows with a DOS session.
Not really.
Post by AZ Nomad
They're not DOS.
So?
Post by AZ Nomad
Run command.com instead of
cmd.exe, rerun that long filename test, and you'll see how DOS has no
capability to handle long filenames.
You are confusing the concept of a command line interface with a
particular implementaion. I got the impression that the OP still finds
a command line interface useful and wishes more could be done.
The very things he's complaining about have been added to the
cmd.exe implementation of the Windows command line interface.
I thought perhaps he may have been unaware you could do things
like have a 1000 line screen buffer.
Rostyslaw J. Lewyckyj
2006-07-07 16:31:45 UTC
Permalink
Post by m***@aol.com
Post by AZ Nomad
Post by m***@aol.com
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded.
This at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone
and so is the source code. No body knows what assumptions were made
then, but our company politics will undoubtedly be shaken by changing
them.
Yeah the basic (well Dos 3.x & > at least) MS DOS utility programs
and the DOS window with command mode are still most usefull.
If only they updated them to do things like handle long file names,
better.
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E
Directory of C:\Python24\user\long_file_names
07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Yeah. The file name in the rightmost column of the dir command
output gets converted to an 8.3 form with ~nnn type names.
And if you want to use the long form name of a directory or file
it gets messy with "" enclosures and is sometimes inconsistant.
e.g. C:\"program files" --> c:\progra~1 ,
My Download files becomes Mydown~1 etc.
You both are confusing the microsoft windows NT/WK/XP
"command prompt" windows with a DOS session.
Not really.
Post by AZ Nomad
They're not DOS.
So?
Post by AZ Nomad
Run command.com instead of cmd.exe,
rerun that long filename test, and you'll see how DOS has no
capability to handle long filenames.
You are confusing the concept of a command line interface with a
particular implementaion. I got the impression that the OP still finds
a command line interface useful and wishes more could be done.
The very things he's complaining about have been added to the
cmd.exe implementation of the Windows command line interface.
I thought perhaps he may have been unaware you could do things
like have a 1000 line screen buffer.
Mensanator has the right interpretation of my comments.
I want to be able to use (if possible improved versions)
of the commands and utilities that are described in the
old Disk Operating System , User's Guide and Reference.
in the Windows (now at W98) command prompt window.
--
Rostyk
MSCHAEF.COM
2006-07-07 17:11:00 UTC
Permalink
In article <h4wrg.43437$***@bignews5.bellsouth.net>,
Rostyslaw J. Lewyckyj <***@bellsouth.net> wrote:
...
Post by Rostyslaw J. Lewyckyj
Mensanator has the right interpretation of my comments.
I want to be able to use (if possible improved versions)
of the commands and utilities that are described in the
old Disk Operating System , User's Guide and Reference.
in the Windows (now at W98) command prompt window.
This is on a Windows 98 box? MS didn't invest much in DOS
after 6.2. Since that version of Windows depended on DOS
for its CLI, it suffered badly, as you're aware. WinNT
has much more powerful CLI support.

However, it would have been possible to add LFN support
to DOS based utilities. DOS, running on Windows95, had
a number of software interface services that were the long
file name equivalent of the usual DOS file system API. These
were built using a fairly general mechanism microsoft had in
place to allow 32-bit code in the VMM layer of the OS to
hook into DOS interrupts.

Int 21/AX=7139h - Windows95 - LONG FILENAME - MAKE DIRECTORY
Int 21/AX=713Ah - Windows95 - LONG FILENAME - REMOVE DIRECTORY
Int 21/AX=713Bh - Windows95 - LONG FILENAME - CHANGE DIRECTORY
Int 21/AX=7141h - Windows95 - LONG FILENAME - DELETE FILE
Int 21/AX=7143h - Windows95 - LONG FILENAME - EXTENDED GET/SET FILE ATTRIBUTES
Int 21/AX=7147h - Windows95 - LONG FILENAME - GET CURRENT DIRECTORY
Int 21/AX=714Eh - Windows95 - LONG FILENAME - FIND FIRST MATCHING FILE
Int 21/AX=714Fh - Windows95 - LONG FILENAME - FIND NEXT MATCHING FILE
Int 21/AX=7156h - Windows95 - LONG FILENAME - RENAME FILE
Int 21/AX=7160h/CL=00h - Windows95 - LONG FILENAME - TRUENAME - CANONICALIZE PATH
Int 21/AX=7160h/CL=01h - Windows95 - LONG FILENAME - GET SHORT (8.3) FILENAME FOR FILE
Int 21/AX=7160h/CL=02h - Windows95 - LONG FILENAME - GET CANONICAL LONG FILENAME OR PATH
Int 21/AX=716Ch - Windows95 - LONG FILENAME - CREATE OR OPEN FILE
Int 21/AX=71A0h - Windows95 - LONG FILENAME - GET VOLUME INFORMATION
Int 21/AX=71A1h - Windows95 - LONG FILENAME - FindClose - TERMINATE DIRECTORY SEARCH
Int 21/AX=71A2h - Windows95 - internal - LONG FILENAME - FIND NEXT MATCHING FILE
Int 21/AX=71A6h - Windows95 - LONG FILENAME - GET FILE INFO BY HANDLE
Int 21/AX=71A7h/BL=00h - Windows95 - LONG FILENAME - FILE TIME TO DOS TIME
Int 21/AX=71A7h/BL=01h - Windows95 - LONG FILENAME - DOS TIME TO FILE TIME
Int 21/AX=71A8h - Windows95 - LONG FILENAME - GENERATE SHORT FILENAME
Int 21/AX=71A9h - Windows95 - LONG FILENAME - SERVER CREATE OR OPEN FILE
Int 21/AX=71AAh/BH=00h - Windows95 - LONG FILENAME - CREATE SUBST
Int 21/AX=71AAh/BH=01h - Windows95 - LONG FILENAME - TERMINATE SUBST
Int 21/AX=71AAh/BH=02h - Windows95 - LONG FILENAME - QUERY SUBST

There was also support for DOS applicaions that could interoperate
with the Windows clipboard.

Int 2F/AX=1701h - MS Windows WINOLDAP - OPEN CLIPBOARD
Int 2F/AX=1702h - MS Windows WINOLDAP - EMPTY CLIPBOARD
Int 2F/AX=1703h - MS Windows WINOLDAP - SET CLIPBOARD DATA
Int 2F/AX=1704h - MS Windows WINOLDAP - GET CLIPBOARD DATA SIZE
Int 2F/AX=1705h - MS Windows WINOLDAP - GET CLIPBOARD DATA
Int 2F/AX=1708h - MS Windows WINOLDAP - CloseClipboard
Int 2F/AX=1709h - MS Windows WINOLDAP - COMPACT CLIPBOARD

The references are all from Ralf Brown's interrupt list:

http://www.ctyme.com/rbrown.htm

-Mike
--
http://www.mschaef.com
m***@aol.com
2006-07-07 06:21:28 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
C:\Python24\user\long_file_names>dir
Volume in drive C is XXXXPXXABA
Volume Serial Number is 90C0-740E
Directory of C:\Python24\user\long_file_names
07/06/2006 06:44p <DIR> .
07/06/2006 06:44p <DIR> ..
07/06/2006 06:41p 6 four_score_and_seven_
years_ago_our_fathers_brought_forth_on_this_continent_a_new_
nation_conceived_in_liberty_and_dedicated_to_the_proposition
_that_all_men_are_created_equal.txt
07/06/2006 06:44p 6 the_ice_was_here_the_
ice_was_there_the_ice_was_all_around_it_crackled_and_groaned
_and_shrieked_and_howled_like_noises_in_a_swound.txt
2 File(s) 12 bytes
2 Dir(s) 2,117,055,488 bytes free
Yeah. The file name in the leftmost column gets converted an
8.3 form with ~nnn type names. And if you want to use the long
form name of a directory or file it gets messy with "" enclosures
and sometimes inconsistant. e.g. C:\"program files" or
c:\progra~1 , My Download files becomes Mydown~1 etc.
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
be able to have
a long window (screen history) that one could scroll,
Like this?
"goto Python24: Properties
Layout: Screen Buffer Size
Width: 132
Height: 1000
Window Size
Width: 132
Height: 60
That's one I don't know. Which version of DOS is it available on?
As pointed out elsewhere, they are in the cmd.exe on Win 2000/XP,
not command.com. That's irrelevant to me because I only use cmd.exe.
If you run cmd.exe in a window, click the [C:\] icon in the upper left
and select Properties from the menu.
Post by Rostyslaw J. Lewyckyj
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
and a few more
such improvements, it would sure be nice. :)
Maybe you need to upgrade. Or maybe you aren't aware of all
the undocumented improvements.
Indeed, possibly i'm not. So if they are undocumented, how do
I find the documentation? :)
Use HELP. Stuff you remember from DOS 3.3 may have been
extended, like the FOR command (note reference to command
line extensions):

C:\Documents and Settings\mensanator\Desktop\long>help for
Runs a specified command for each file in a set of files.

FOR %variable IN (set) DO command [command-parameters]

%variable Specifies a single letter replaceable parameter.
(set) Specifies a set of one or more files. Wildcards may be
used.
command Specifies the command to carry out for each file.
command-parameters
Specifies parameters or switches for the specified
command.

To use the FOR command in a batch program, specify %%variable instead
of %variable. Variable names are case sensitive, so %i is different
from %I.

If Command Extensions are enabled, the following additional
forms of the FOR command are supported:

FOR /D %variable IN (set) DO command [command-parameters]

If set contains wildcards, then specifies to match against
directory
names instead of file names.

FOR /R [[drive:]path] %variable IN (set) DO command
[command-parameters]

Walks the directory tree rooted at [drive:]path, executing the FOR
statement in each directory of the tree. If no directory
specification is specified after /R then the current directory is
assumed. If set is just a single period (.) character then it
will just enumerate the directory tree.

FOR /L %variable IN (start,step,end) DO command [command-parameters]

The set is a sequence of numbers from start to end, by step amount.
So (1,1,5) would generate the sequence 1 2 3 4 5 and (5,-1,1) would
generate the sequence (5 4 3 2 1)

FOR /F ["options"] %variable IN (file-set) DO command
[command-parameters]
FOR /F ["options"] %variable IN ("string") DO command
[command-parameters]
FOR /F ["options"] %variable IN ('command') DO command
[command-parameters]

or, if usebackq option present:

FOR /F ["options"] %variable IN (file-set) DO command
[command-parameters]
FOR /F ["options"] %variable IN ('string') DO command
[command-parameters]
FOR /F ["options"] %variable IN (`command`) DO command
[command-parameters]

filenameset is one or more file names. Each file is opened, read
and processed before going on to the next file in filenameset.
Processing consists of reading in the file, breaking it up into
individual lines of text and then parsing each line into zero or
more tokens. The body of the for loop is then called with the
variable value(s) set to the found token string(s). By default, /F
passes the first blank separated token from each line of each file.
Blank lines are skipped. You can override the default parsing
behavior by specifying the optional "options" parameter. This
is a quoted string which contains one or more keywords to specify
different parsing options. The keywords are:

eol=c - specifies an end of line comment character
(just one)
skip=n - specifies the number of lines to skip at the
beginning of the file.
delims=xxx - specifies a delimiter set. This replaces the
default delimiter set of space and tab.
tokens=x,y,m-n - specifies which tokens from each line are to
be passed to the for body for each iteration.
This will cause additional variable names to
be allocated. The m-n form is a range,
specifying the mth through the nth tokens.
If
the last character in the tokens= string is
an
asterisk, then an additional variable is
allocated and receives the remaining text on
the line after the last token parsed.
usebackq - specifies that the new semantics are in
force,
where a back quoted string is executed as a
command and a single quoted string is a
literal string command and allows the use of
double quotes to quote file names in
filenameset.

Some examples might help:

FOR /F "eol=; tokens=2,3* delims=, " %i in (myfile.txt) do @echo %i %j
%k

would parse each line in myfile.txt, ignoring lines that begin with
a semicolon, passing the 2nd and 3rd token from each line to the
for
body, with tokens delimited by commas and/or spaces. Notice the
for
body statements reference %i to get the 2nd token, %j to get the
3rd token, and %k to get all remaining tokens after the 3rd. For
file names that contain spaces, you need to quote the filenames
with
double quotes. In order to use double quotes in this manner, you
also
need to use the usebackq option, otherwise the double quotes will
be
interpreted as defining a literal string to parse.

%i is explicitly declared in the for statement and the %j and %k
are implicitly declared via the tokens= option. You can specify up
to 26 tokens via the tokens= line, provided it does not cause an
attempt to declare a variable higher than the letter 'z' or 'Z'.
Remember, FOR variables are single-letter, case sensitive, global,
and you can't have more than 52 total active at any one time.

You can also use the FOR /F parsing logic on an immediate string,
by
making the filenameset between the parenthesis a quoted string,
using single quote characters. It will be treated as a single line
of input from a file and parsed.

Finally, you can use the FOR /F command to parse the output of a
command. You do this by making the filenameset between the
parenthesis a back quoted string. It will be treated as a command
line, which is passed to a child CMD.EXE and the output is captured
into memory and parsed as if it was a file. So the following
example:

FOR /F "usebackq delims==" %i IN (`set`) DO @echo %i

would enumerate the environment variable names in the current
environment.

In addition, substitution of FOR variable references has been enhanced.
You can now use the following optional syntax:

%~I - expands %I removing any surrounding quotes (")
%~fI - expands %I to a fully qualified path name
%~dI - expands %I to a drive letter only
%~pI - expands %I to a path only
%~nI - expands %I to a file name only
%~xI - expands %I to a file extension only
%~sI - expanded path contains short names only
%~aI - expands %I to file attributes of file
%~tI - expands %I to date/time of file
%~zI - expands %I to size of file
%~$PATH:I - searches the directories listed in the PATH
environment variable and expands %I to the
fully qualified name of the first one found.
If the environment variable name is not
defined or the file is not found by the
search, then this modifier expands to the
empty string

The modifiers can be combined to get compound results:

%~dpI - expands %I to a drive letter and path only
%~nxI - expands %I to a file name and extension only
%~fsI - expands %I to a full path name with short names only
%~dp$PATH:I - searches the directories listed in the PATH
environment variable for %I and expands to the
drive letter and path of the first one found.
%~ftzaI - expands %I to a DIR like output line

In the above examples %I and PATH can be replaced by other valid
values. The %~ syntax is terminated by a valid FOR variable name.
Picking upper case variable names like %I makes it more readable and
avoids confusion with the modifiers, which are not case sensitive.
Post by Rostyslaw J. Lewyckyj
I'll keep you in mind for questions. :)
Charlie Gibbs
2006-07-07 06:36:22 UTC
Permalink
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded.
This at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone
and so is the source code. No body knows what assumptions were
made then, but our company politics will undoubtedly be shaken
by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and
the DOS window with command mode are still most usefull. If only
they updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
While this example does prove that long file names are supported,
it illustrates another major "broken as designed" feature: the
acceptance of "CON" as the console, without requiring a trailing
colon to identify a separate device name space. The system is
smart enough to distinguish between a file called A and drive A: -
why not other devices as well? Ironically, the colon is optional;
CON: works just as well, and I use it just to maintain good habits.
Even more ironically, people who loudly disparage the use of reserved
words in COBOL will just as loudly defend the use of reserved file
names such as CON. These people deserve to have someone go into
their directory with a file zapper to rename a file to CON, so they
can be laughed at as they try to figure out how to delete that file.

The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command. There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
be able to have
a long window (screen history) that one could scroll,
Like this?
"goto Python24: Properties
Layout: Screen Buffer Size
Width: 132
Height: 1000
Window Size
Width: 132
Height: 60
F3 was pretty pitiful, but some systems support up-arrow to recall
recent (with the emphasis on "recent") commands. Command history
under Windows has always been pretty pathetic compared to what's
available under Unix; perhaps a replacement shell is in order.
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
and a few more
such improvements, it would sure be nice. :)
Like maybe wildcard handling that isn't severely broken?
Go ahead, show me how to find all files whose names begin
with "ab" and end with "c". (Hint: ab*c won't work; once
a Windows shell sees an asterisk, that's all she wrote.)
Post by m***@aol.com
Maybe you need to upgrade. Or maybe you aren't aware of all
the undocumented improvements.
There's a reason that the few improvements that have appeared
are undocumented. Microsoft seems to have some hidden agenda
to force people's hands off the keyboard and onto the mouse.
Few things that make a command-line interface easier to use
have been introduced since MS-DOS. Hanlon's Razor states:
"Never ascribe to malice that which can adequately be explained
by stupidity." To which a little voice in the back of mind
replies: "But Microsoft isn't stupid!"
--
/~\ ***@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!
m***@aol.com
2006-07-07 06:55:34 UTC
Permalink
Post by Charlie Gibbs
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded.
This at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone
and so is the source code. No body knows what assumptions were
made then, but our company politics will undoubtedly be shaken
by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and
the DOS window with command mode are still most usefull. If only
they updated them to do things like handle long file names,
You mean like this?
C:\Python24\user\long_file_names>copy con the_ice_was_here_t
he_ice_was_there_the_ice_was_all_around_it_crackled_and_groa
ned_and_shrieked_and_howled_like_noises_in_a_swound.txt
test
^Z
1 file(s) copied.
While this example does prove that long file names are supported,
When Microsoft refers to a feature like that, they say
"This behaviour is by design."
Post by Charlie Gibbs
the
acceptance of "CON" as the console, without requiring a trailing
colon to identify a separate device name space. The system is
smart enough to distinguish between a file called A and drive A: -
why not other devices as well? Ironically, the colon is optional;
CON: works just as well, and I use it just to maintain good habits.
Even more ironically, people who loudly disparage the use of reserved
words in COBOL will just as loudly defend the use of reserved file
names such as CON.
For the record, I wasn't defending any MS design features,
merely pointing out that the current CLI is a little different
from the old DOS 3.3 CLI.
Post by Charlie Gibbs
These people deserve to have someone go into
their directory with a file zapper to rename a file to CON, so they
can be laughed at as they try to figure out how to delete that file.
You don't have to go to that much trouble. When I was doing
network administration, the users managed to get LPT1 files
sprinkled all over the network without any help.
Post by Charlie Gibbs
The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command.
In this case, the ^Z was NOT appended to the file. You snipped
it but the directory listing showed the file to be exactly 6 bytes,
the word "test" and a <cr><lf> (please don't open that can of
worms again).
Post by Charlie Gibbs
There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Did the ^Z actually get appended to the file in DOS 3.3?
I know the odditities still exist because I just ran some
tests recently, but I had to use a binary editor to put the
^Z into the test files.
Post by Charlie Gibbs
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
be able to have
a long window (screen history) that one could scroll,
Like this?
"goto Python24: Properties
Layout: Screen Buffer Size
Width: 132
Height: 1000
Window Size
Width: 132
Height: 60
F3 was pretty pitiful, but some systems support up-arrow to recall
recent (with the emphasis on "recent") commands. Command history
under Windows has always been pretty pathetic compared to what's
available under Unix; perhaps a replacement shell is in order.
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
and a few more
such improvements, it would sure be nice. :)
Like maybe wildcard handling that isn't severely broken?
Go ahead, show me how to find all files whose names begin
with "ab" and end with "c". (Hint: ab*c won't work; once
a Windows shell sees an asterisk, that's all she wrote.)
Post by m***@aol.com
Maybe you need to upgrade. Or maybe you aren't aware of all
the undocumented improvements.
There's a reason that the few improvements that have appeared
are undocumented. Microsoft seems to have some hidden agenda
to force people's hands off the keyboard and onto the mouse.
Few things that make a command-line interface easier to use
"Never ascribe to malice that which can adequately be explained
by stupidity." To which a little voice in the back of mind
replies: "But Microsoft isn't stupid!"
--
\ / 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!
j***@aol.com
2006-07-07 10:26:16 UTC
Permalink
In article <***@kltpzyxm.invalid>,
"Charlie Gibbs" <***@kltpzyxm.invalid> wrote:
<snip>
Post by Charlie Gibbs
There's a reason that the few improvements that have appeared
are undocumented. Microsoft seems to have some hidden agenda
to force people's hands off the keyboard and onto the mouse.
Few things that make a command-line interface easier to use
"Never ascribe to malice that which can adequately be explained
by stupidity." To which a little voice in the back of mind
replies: "But Microsoft isn't stupid!"
They aren't stupid. That is how arrogant the company's folklore is.
DEC had similar arrogant people; they were successful in destroying
the best work of the computing biz [DEC bias alert!].

This is just plain arrogance. "We know better than everyone
else in the solar system. There is only one way to use
computers--our way." The reason things are completely broken
is that *ALL* tradeoffs are based on ease of distribution.
This is why any OS work they do do is a complete disaster.

/BAH


/BAH
Rostyslaw J. Lewyckyj
2006-07-07 18:29:17 UTC
Permalink
Post by Charlie Gibbs
The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command. There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Thanks. and :( groan!
Perhaps that's why some recovered pieces of a semi-binary file
from a corrupted disk, won't concatenat properly. :(
I have recovered pieces of a yenc file xx0.txt ... xx9.txt
which look good in the text editor BUT when I concatenate them
via copy/b xx?.txt yyy.txt the yyy.txt file won't decode.
Now I'll try hunting down and eliminating those ^Zs
(if the system doesn't get them when it's doing the copy),
and perhaps the mess will decode.
--
Rostyk
m***@aol.com
2006-07-07 20:09:30 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Charlie Gibbs
The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command. There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Thanks. and :( groan!
Perhaps that's why some recovered pieces of a semi-binary file
from a corrupted disk, won't concatenat properly. :(
I have recovered pieces of a yenc file xx0.txt ... xx9.txt
which look good in the text editor BUT when I concatenate them
via copy/b xx?.txt yyy.txt the yyy.txt file won't decode.
Now I'll try hunting down and eliminating those ^Zs
(if the system doesn't get them when it's doing the copy),
and perhaps the mess will decode.
A copy/b command should not add any ^Z. The /b switch
tells the copy process to continue past any ^Z in the source file
and out to the number of bytes indicated in the file length and
does not add a terminating ^Z to the new file.

Without the /b switch, copy terminates a file read at a ^Z even
if there are more bytes as indicated by file length. Two text
files of 7 bytes (last being ^Z) concatenate to 13 bytes (the
^Z from the first file is discarded). If neither file had any ^Z
terminator (6 bytes each), the concatenated file would still
be 13 bytes since a ^Z would be added at the end of the copy
process.

With the /b switch, the two 7 byte files concatenate to 14 bytes
(the ^Z's in the source file are preserved) and the two 6 byte files
concatenate to 12 bytes (no ^Z is added by the copy).

BUT - if you were to try to TYPE the two files created with the /b
option, the 14 byte file will only output 6 bytes because TYPE
stops when it encounters a ^Z.

It sounds like using the /b option is the right thing to do to
concatenate recovered file fragments, especially if they may have
had binary data, so you may not want to go eliminate ^Z from
the files.

However, if the xx?.txt are recovered file fragments, you may have
a different problem. Often, recovered file fragments are the entire
allocation block. This is generally ok for all fragments except the
last one. The original file may have used only 100 bytes of the last
allocation block but your recovered fragment may be the full size
of an allocation block. Thus, when you use the /b switch, the entire
contents of the last file fragment are appended instead of only the
first 100 bytes.

But if you don't use /b, any binary data that happens to be ^Z will
terminate the read of the file it's in. What I would do is try to
identify where the end of the last block is. Look for gort in xx9.txt
when you open it with a text editor and try to delete the garbage
and re-save the file (on copies of the original files, of course).
A text editor may not be reliable for this purpose. A binary editor
would be better.

Now IF the last block actually has a ^Z where the end of the file
should be, you could use the /b switch for fragments 1 through 8
and then turn the /b switch off to concatenate the last fragment.
That would prevent the gort from being appended.

Here's a trick to tell if a file contains a ^Z. A simple copy of a file
will not stop if the file contains embedded ^Z, only when appending.
Thus, two 13 byte ^Z terminated files append to a 26 byte file when
using /b. The 26 byte file has a ^Z in the middle. Simply copying
the 26 byte file doesn't reveal the embedded ^Z.

But, if you make a 0 byte file...

C:\Python24\user\long_file_names>copy con zzz
^Z
1 file(s) copied.

...and append that to the 26 byte file (without /b), you get a 13
byte file. This is because during an append without /b, the 26 byte
file stops copying when it hits the embedded ^Z (12 bytes),
appends 0 bytes fromm zzz and finally adds a ^Z terminator.

So if appending a zero length file to a non-zero length file without
/b causes the copy to be smaller than the original, then the original
contained an embedded ^Z.
Post by Rostyslaw J. Lewyckyj
--
Rostyk
Rostyslaw J. Lewyckyj
2006-07-08 00:18:24 UTC
Permalink
Post by m***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Charlie Gibbs
The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command. There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Thanks. and :( groan!
Perhaps that's why some recovered pieces of a semi-binary file
from a corrupted disk, won't concatenat properly. :(
I have recovered pieces of a yenc file xx0.txt ... xx9.txt
which look good in the text editor BUT when I concatenate them
via copy/b xx?.txt yyy.txt the yyy.txt file won't decode.
Now I'll try hunting down and eliminating those ^Zs
(if the system doesn't get them when it's doing the copy),
and perhaps the mess will decode.
A copy/b command should not add any ^Z. The /b switch
tells the copy process to continue past any ^Z in the source file
and out to the number of bytes indicated in the file length and
does not add a terminating ^Z to the new file.
Without the /b switch, copy terminates a file read at a ^Z even
if there are more bytes as indicated by file length. Two text
files of 7 bytes (last being ^Z) concatenate to 13 bytes (the
^Z from the first file is discarded). If neither file had any ^Z
terminator (6 bytes each), the concatenated file would still
be 13 bytes since a ^Z would be added at the end of the copy
process.
With the /b switch, the two 7 byte files concatenate to 14 bytes
(the ^Z's in the source file are preserved) and the two 6 byte files
concatenate to 12 bytes (no ^Z is added by the copy).
BUT - if you were to try to TYPE the two files created with the /b
option, the 14 byte file will only output 6 bytes because TYPE
stops when it encounters a ^Z.
It sounds like using the /b option is the right thing to do to
concatenate recovered file fragments, especially if they may have
had binary data, so you may not want to go eliminate ^Z from
the files.
However, if the xx?.txt are recovered file fragments, you may have
a different problem. Often, recovered file fragments are the entire
allocation block. This is generally ok for all fragments except the
last one. The original file may have used only 100 bytes of the last
allocation block but your recovered fragment may be the full size
of an allocation block. Thus, when you use the /b switch, the entire
contents of the last file fragment are appended instead of only the
first 100 bytes.
But if you don't use /b, any binary data that happens to be ^Z will
terminate the read of the file it's in. What I would do is try to
identify where the end of the last block is. Look for gort in xx9.txt
when you open it with a text editor and try to delete the garbage
and re-save the file (on copies of the original files, of course).
A text editor may not be reliable for this purpose. A binary editor
would be better.
Now IF the last block actually has a ^Z where the end of the file
should be, you could use the /b switch for fragments 1 through 8
and then turn the /b switch off to concatenate the last fragment.
That would prevent the gort from being appended.
Here's a trick to tell if a file contains a ^Z. A simple copy of a file
will not stop if the file contains embedded ^Z, only when appending.
Thus, two 13 byte ^Z terminated files append to a 26 byte file when
using /b. The 26 byte file has a ^Z in the middle. Simply copying
the 26 byte file doesn't reveal the embedded ^Z.
But, if you make a 0 byte file...
C:\Python24\user\long_file_names>copy con zzz
^Z
1 file(s) copied.
...and append that to the 26 byte file (without /b), you get a 13
byte file. This is because during an append without /b, the 26 byte
file stops copying when it hits the embedded ^Z (12 bytes),
appends 0 bytes fromm zzz and finally adds a ^Z terminator.
So if appending a zero length file to a non-zero length file without
/b causes the copy to be smaller than the original, then the original
contained an embedded ^Z.
Well, it's like this:
xx0.txt .. xx9.txt are what my Nortons file recovery program named
the fragments. Norton did not return the thing as a single file
because ??? whatever it does, it didn't recognize the pieces to fit
together. So I don't right now (yet) know if they have extraneous
trailing ^Zs.
The returned files are pieces of a yenc encoded file.
the xx0.txt file contains the yenc header =yenc ... and the last
file (I called it) xx9.txt for posting contains the =yend ...
text. Since it was a yenc encoded file, that had been downloaded
off of a newsgroup, it was 8bit text with lines terminated
by CRLFs. but should not contain any control characters.
I look at the pieces in Vim which can work with binary.
ie. Vim doesn't mung file content like Word or other text editors.
After cleaning the xx files up as best I can, I concatenated the pieces
and tried to decode the beast. yenc32 said that the file was corrupted.
Well the comments about a trailing ^Z alerted me to, just something
else, to check trying to clean the mess up.
Thanks for your interest.

Ps. I have looked for cmd.exe retrofitted to W98, and in the process
learned some interesting details. Everybody discusses the 'for'
command but not any other enhancements to any other utilities.
--
Rostyk
Rostyslaw J. Lewyckyj
2006-07-08 05:27:50 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Rostyslaw J. Lewyckyj
Post by Charlie Gibbs
The above example also indirectly demonstrates another breakage
of design. The ^Z is appended to the end of the file, rather than
just serving as an EOF signal to the COPY command. There is no
reason to have a special end-of-file character; the file size is
stored to the byte in the directory. The ^Z is a throwback to CP/M
(this discussion is about backward compatibility, right?) and it has
caused nothing but problems ever since.
Thanks. and :( groan!
.........................
Post by Rostyslaw J. Lewyckyj
xx0.txt .. xx9.txt are what my Nortons file recovery program named
the fragments. Norton did not return the thing as a single file
because ??? whatever it does, it didn't recognize the pieces to fit
together. So I don't right now (yet) know if they have extraneous
trailing ^Zs.
The returned files are pieces of a yenc encoded file.
the xx0.txt file contains the yenc header =yenc ... and the last
file (I called it) xx9.txt for posting contains the =yend ...
text. Since it was a yenc encoded file, that had been downloaded
off of a newsgroup, it was 8bit text with lines terminated
by CRLFs. but should not contain any control characters.
Well so much for assumptions. DAMN.
yenc encoded files, do use ^Z in them.
I looked at a freshly downloaded newsgroup yenc file, and it
do have embedded ^Zs :( :( :(
--
Rostyk
j***@aol.com
2006-07-07 10:15:46 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names, be able to have
a long window (screen history) that one could scroll, and a few more
such improvements, it would sure be nice. :)
Those additions would have been a very bad mistake. Not
even DEC would done something that stupid.

/BAH
Rostyslaw J. Lewyckyj
2006-07-07 18:39:56 UTC
Permalink
Post by j***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names, be able to have
a long window (screen history) that one could scroll, and a few more
such improvements, it would sure be nice. :)
Those additions would have been a very bad mistake. Not
even DEC would done something that stupid.
/BAH
Mizz Barbara, please defend your claim(s).
j***@aol.com
2006-07-08 10:47:24 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by j***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names, be able to have
a long window (screen history) that one could scroll, and a few more
such improvements, it would sure be nice. :)
Those additions would have been a very bad mistake. Not
even DEC would done something that stupid.
/BAH
Mizz Barbara, please defend your claim(s).
Sigh! Why? You don't believe people who have experience.

Look, to put in long-file name support in a previous
version implies a different version. This implies that
there will be two version to "support" in the company's
infrastructure. Site-specific support is completely
orthogonal to general distributions and support.


/BAH
Rostyslaw J. Lewyckyj
2006-07-08 18:24:41 UTC
Permalink
Post by j***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by j***@aol.com
Post by Rostyslaw J. Lewyckyj
Post by Walter Bushell
Post by John Savard
But IBM's chief customers were businesses, which had both
growing data processing requirements, and which put a value on
convenience and help using the computer.
They did not repeat _not_ want to reprogram stuff as they expanded. This
at least partially explains Microsoft's fetish for backwards
compatibility. Wasn't there a stink about 16 bit programs no longer
working in XP. Hey, the programmers who wrote them are long gone and so
is the source code. No body knows what assumptions were made then, but
our company politics will undoubtedly be shaken by changing them.
Yeah the basic (well Dos 3.x at least) MS DOS utility programs and the
DOS window with command mode are still most usefull. If only they
updated them to do things like handle long file names, be able to have
a long window (screen history) that one could scroll, and a few more
such improvements, it would sure be nice. :)
Those additions would have been a very bad mistake. Not
even DEC would done something that stupid.
/BAH
Mizz Barbara, please defend your claim(s).
Sigh! Why? You don't believe people who have experience.
Look, to put in long-file name support in a previous
version implies a different version. This implies that
there will be two version to "support" in the company's
infrastructure. Site-specific support is completely
orthogonal to general distributions and support.
/BAH
Won't buy that!
You originally have a system S1 with features (p,q)
and a program A with some functions (x,y,z)
You release S2 with features (p,q,r)
Now what do you do about A?
1) drop it, and write some completely different prog X
with functions (x,y,z) supporting (p,q, and r).
2) add hooks for A in S2, but don't add support for r
3) add the hooks for A in S2, and add support for r

In all three cases you have created a second program B.
You are advocating 2) I'm advocating 3). From 2) --> to 3)
is the natural route of version progress, and improvement
of function. Moreover if 3) is done in time for release
with S2 then there are not two programs A & B to support,
but just one B version for S2. A is an existing obsolete
program that belongs with the obsolete system S1 and
remains with that system.

You could of course just not provide any prog with
functions (x,y,z) for S2. But I don't think that you'd
advocate that. :)

Please refute my argument(s)
--
Rostyk
Eugene Miya
2006-07-06 18:52:28 UTC
Permalink
Post by John Savard
The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Not quite.
Maybe from some marketing person's view.
IBM had too many incompatible computer lines and the duplication costs
were killing them as a company. No one in this industry can even agree
on bit ordering in a word. People in the IBM and DEC communities can't
fathom byte-less architectures. The logic of packing 5 characters in a
36-bit word mistified something very smart people. Etc. From all that
RISC was "obivous." And you also find very few to admit to using a
Series 1.

The really interesting architectural history took place in the less than
giants in order for them to survive against giants. Giants, in the past,
could afford to sit on their behinds. Bill Gates know this.

--
j***@aol.com
2006-07-07 10:36:45 UTC
Permalink
Post by Eugene Miya
Post by John Savard
The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Not quite.
Maybe from some marketing person's view.
I sure wouldn't say that. The whole point was that more and
more people figured out that they could use computing services.
Not even mid-sized businesses could afford to rent a real
IBM machine. And they didn't want outside people to have
access to their records, even though ADP made money doing
this stuff.

Besides, having your own computer was better boasting material
than owning a Ferrari.

<snip>

/BAH
Eugene Miya
2006-07-07 16:04:20 UTC
Permalink
Post by j***@aol.com
Post by Eugene Miya
Post by John Savard
The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Not quite.
Maybe from some marketing person's view.
I sure wouldn't say that. The whole point was that more and
more people figured out that they could use computing services.
Kicking and screaming.
Post by j***@aol.com
Not even mid-sized businesses could afford to rent a real
IBM machine. And they didn't want outside people to have
access to their records, even though ADP made money doing
this stuff.
True as a factor.
But IBM was more a set of fiefdoms back then as it is now.
It's harder for newer gens. to think about renting computers
as they were harder to maintain back then for their expense.
Security even back then was minimal despite what Lynn says.
Computers weren't given host or node names back then.

Upgrading wasn't high on new buyers lists. Customers rarely thought about
strategies. When the 780 came out, for instance, I worked for 1 org
where all the various sub orgs scraped to get money to buy a minimal one
(like 256 KB main memory, like 1/2 my first Mac). I moved to an org
where one guy made a shares market, but insisted on maxing out machines
and insisting on DECnet. And it managed to work. He had the biggest
DECnet early on outside the Enet. I used it to read punch cards onto an
RSX-11M/PDP-11 onto a VAX, across the ARPAnet to ucbarpa to uucp to NCAR.
That was the 2nd. gen of the nuclear winter code.
Post by j***@aol.com
Besides, having your own computer was better boasting material
than owning a Ferrari.
Some times. That what the corp. windows were for.

--
j***@aol.com
2006-07-08 10:34:01 UTC
Permalink
Post by Eugene Miya
Post by j***@aol.com
Post by Eugene Miya
Post by John Savard
The whole idea behind System/360 was that people could invest in a
smaller model, and then easily upgrade as their needs grew.
Not quite.
Maybe from some marketing person's view.
I sure wouldn't say that. The whole point was that more and
more people figured out that they could use computing services.
Kicking and screaming.
Not at all. Begging and pleading.
Post by Eugene Miya
Post by j***@aol.com
Not even mid-sized businesses could afford to rent a real
IBM machine. And they didn't want outside people to have
access to their records, even though ADP made money doing
this stuff.
True as a factor.
But IBM was more a set of fiefdoms back then as it is now.
I know.
Post by Eugene Miya
It's harder for newer gens. to think about renting computers
as they were harder to maintain back then for their expense.
Security even back then was minimal despite what Lynn says.
You are young. Security was "easier" because you could
guarantee that bits never left the room. That was because
bits had to be transferred with sneaker power. There were
still oodles of other kinds of security. A lot of it had
to do with the cold war.
Post by Eugene Miya
Computers weren't given host or node names back then.
Sure they were. The biz didn't have an industry back then.
That is what the early 70s was doing. We were trying to
figure out what would work well.
Post by Eugene Miya
Upgrading wasn't high on new buyers lists.
Sigh! YOu are speaking with an IBM-centric viewpoint.
Post by Eugene Miya
Customers rarely thought about
strategies.
Now that is just completely, utterly, 100% wrong.
Post by Eugene Miya
When the 780 came out, for instance, I worked for 1 org
where all the various sub orgs scraped to get money to buy a minimal one
(like 256 KB main memory, like 1/2 my first Mac). I moved to an org
where one guy made a shares market, but insisted on maxing out machines
and insisting on DECnet. And it managed to work. He had the biggest
DECnet early on outside the Enet. I used it to read punch cards onto an
RSX-11M/PDP-11 onto a VAX, across the ARPAnet to ucbarpa to uucp to NCAR.
That was the 2nd. gen of the nuclear winter code.
Perhaps you also are speaking from a view thru mini-computer glasses.
Post by Eugene Miya
Post by j***@aol.com
Besides, having your own computer was better boasting material
than owning a Ferrari.
Some times. That what the corp. windows were for.
Nah, most of the time. The only function the gear didn't
have was babe magnetism.

/BAH
Anne & Lynn Wheeler
2006-07-08 15:33:24 UTC
Permalink
Post by Eugene Miya
But IBM was more a set of fiefdoms back then as it is now.
It's harder for newer gens. to think about renting computers
as they were harder to maintain back then for their expense.
Security even back then was minimal despite what Lynn says.
Computers weren't given host or node names back then.
different operating systems were structured in different ways ... most
of the "batch" systems tended to have minimal security, in part
because there was little direct access to the actual machine by the
people using them.

the time-sharing systems
http://www.garlic.com/~lynn/subtopic.html#timeshare

tended to have somewhat more robust security ... and, in fact, saw
some uses in organizations that tended to have somewhat stringent.
this has a reference to some use from the late 60s and early 70s:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

I've repeated several times the effort at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

where the "unannounced" 370 virtual memory was emulated on the science
center's 360/67. this had some number of issues since the corporation
treated the unannounced 370 virtual memory as extremely sensitive
corporate information ... and the science center's 360/67 was also
providing online service to a number of non-employees in the boston
area, including some number of students from various boston area
institutes of higher education (bu, mit, harvard, etc).

another activity was that in the initial port apl\360 to cms\apl on
the cambridge system, it opened up the APL workspace size from
something like 32kbytes (real) to several megabytes (virtual). the
corporate hdqtrs people found it attractive for doing business
modeling and had the absolutely most sensitive of all corporate
information loaded on the cambridge machine so they could do business
modeling remotely from corporate hdqtrs. Being able to provide the
highest level of data protection was a real issue ... especially with
all the non-employee and student access to the same machine
concurrently.

misc. past posts mentioning the effort virtualizing unannounced 370
virtual memory ... which was also one of the first distributed
development projects using the internal network (between cambridge and
endicott) ... and of course the cambridge host name was cambrdige:
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
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/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers

past posts mentioning the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
Nick Spalding
2006-07-06 07:57:15 UTC
Permalink
Post by Charles Richmond
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.
It was widely considered to be pretty primitive then too!
--
Nick Spalding
Eugene Miya
2006-07-06 16:57:27 UTC
Permalink
Post by Charles Richmond
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.
I had to think about that one.
Original Macs had a 68K at 8 MHz. My friend Patty was the Mac Group's
Librarian (the original one). I remember ours was a small machine in
the same room as the key entry people. Mac clearly had and addressed
more memory that old 20s.

I'm sure PDP-1s were smaller and more primitive. Even 8s.

You didn't have a 20 to do big honking simulations.
I would ride a shuttle down to UCLA and use their 91 if I was part of that.
Or a CDC 6400 (SCOPE).

For a more forward looking perspective, IBM used to hold conferences
on the uses of their sorting machines in scientific computation.
And not just because you dropped your card deck.
But those conferences were before my time in the late 40s and 50s.

--
Rostyslaw J. Lewyckyj
2006-07-06 22:43:52 UTC
Permalink
Post by Eugene Miya
But those conferences were before my time in the late 40s and 50s.
Er.. Did you mean " But those conferences were in the late 40s and 50s.
Before my time" ? :)
Eugene Miya
2006-07-07 15:37:37 UTC
Permalink
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
But those conferences were before my time in the late 40s and 50s.
Er.. Did you mean " But those conferences were in the late 40s and 50s.
Before my time" ? :)
Ambiguity and human projection are wonderful interrogation tools.

--
Rostyslaw J. Lewyckyj
2006-07-07 19:27:40 UTC
Permalink
Post by Eugene Miya
Post by Rostyslaw J. Lewyckyj
Post by Eugene Miya
But those conferences were before my time in the late 40s and 50s.
Er.. Did you mean " But those conferences were in the late 40s and 50s.
Before my time" ? :)
Ambiguity and human projection are wonderful interrogation tools.
I agree that your statement is ambiguous.
What projection was intended?
John Byrns
2006-07-07 22:04:17 UTC
Permalink
Post by Charles Richmond
Post by Eugene Miya
Why would it be bad except in roles which it was poorly designed?
I even think I had call to use one when I was an u-grad when I didn't
want to bother with the 75. And it was free.
Back in 1979, I heard that a Motorola MC68000 at 8 MHz was slightly
higher in processing capability than an IBM 360 Model 20. That may
mean that the IBM 360 Model 20 was "not as bad as all that", but
it still seems this 360 model was pretty primitive by today's
standards.
I kind of doubt the 360/20 was even in the same league as an 8 MHz
MC68000. IIRC the 8 MHz MC68000 had a 0.5 usec. memory cycle time
accessing 16 bits at a time, the ALU was 16 bits wide, and the general
purpose registers were stored in a semiconductor scratchpad memory. Not
having a clue what sort of hardware was inside a 360/20, I would have to
guess that the MC68000 had to be at least an order of magnitude faster
than the 360/20 on integer problems, and probably more given the
lackluster performance of the other low end 360s. I could imagine that on
the bread and butter decimal jobs the 360/20 might have offered about the
same performance as the MC68000 since it had micro code to do decimal
arithmetic while the MC68000 didn't.

Does anyone have any idea what sort of hardware was inside a 360/20? What
did the data paths look like? What was the memory cycle time and access
width? Are instruction timings available for the 360/20? There is a lot
of this sort of hardware data easily available for the 360/30 and 360/40,
but the guts of the 360/20 appear to be pretty much of a mystery, at least
to me.


Regards,

John Byrns


Surf my web pages at, http://users.rcn.com/jbyrns/
John Savard
2006-07-08 01:07:42 UTC
Permalink
Post by John Savard
Then there was the Model 20.
Not only couldn't you get floating-point for it, but it didn't even have
all the standard System/360 instructions: it wouldn't do arithmetic on
32-bit integers.
I thought I would closely re-examine the manual for the Univac 9200 and
9300 that I downloaded from Al Kossow's site. Those computers also had
that limitation.

AND they had the difference that the base register was only used when
the first bit of an address field was 1; so general registers 8 through
15 were base registers, and the other choice was to have a 15-bit
absolute address.

So the 9200 and 9300 weren't 360 clones... they were 360/20 clones!

Univac had only *one* computer, the 9400, to abandon when it picked up
the Spectra 70!

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
John Savard
2006-07-08 01:45:50 UTC
Permalink
Post by John Savard
So the 9200 and 9300 weren't 360 clones... they were 360/20 clones!
Univac had only *one* computer, the 9400, to abandon when it picked up
the Spectra 70!
And, according to one web reference - this could be a mistake - the 9400
did not have the BXLE instruction which assisted in looping on the 360.

John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
David Wade
2006-07-08 10:37:17 UTC
Permalink
Post by John Savard
On April 7, 1964, International Business Machines announced System/360.
The initial announcement comprised models 30, 40, 50, 60, 62, and 70.
The last three models were replaced by models 65 and 75 prior to
delivery; the front panels looked pretty much the same, but the
performance was improved over what had been announced originally.
IBM extended the series upwards later, with the model 91, followed by
the 85 and the 195 (not to mention the two model 95s sold to NASA, IBM's
one and only thin-film computer).
There was a special-purpose machine in the middle of the series, the
model 44, which had particularly high floating-point performance.
And, of course, there was the model 67, which offered Dynamic Address
Translation in what was otherwise a model 65.
They also extended the series at the low end, with the models 22 and 25.
Then there was the Model 20.
Not only couldn't you get floating-point for it, but it didn't even have
all the standard System/360 instructions: it wouldn't do arithmetic on
32-bit integers.
The popularity of the IBM 360 inspired imitations... and
near-imitations.
The closest of the near-imitations were the RCA Spectra 70 computers.
Only those portions of the instruction set that required privileged mode
to use were different. Presumably, this was intended to ensure they
didn't need to fear a lawsuit by encouraging people to pirate IBM's
operating system software.
At the time the OS was free and uncopyrighted so thats unlikley.
A more credible reason is that they wanted to avoid paying patent fees to
IBM and some aspect of "privileged mode" was patented.
Post by John Savard
Usually not even counted as an imitation at all were the Sigma
computers. These computers had instructions that were all 32 bits in
length; register-to-register operations were provided by means of
assigning memory addresses to the registers. But the features offered
were intentionally matched to those of the System/360, and the data
formats were the same - with the exception of floating-point numbers, if
they were negative.
In data formats, the PDP-6 had the same sort of relation to the IBM 7090
and its relatives, but even the fact that the KA-10 version of the
PDP-10 had a front panel with a sloped front, and a near-horizontal
extension with the rows of rocker switches on it doesn't really lead me
to think of the PDP-6 and PDP-10 as imitations of the 7090. Had it not
used two's complement arithmetic for integers, I might have reconsidered
that.
Then there were the minis from Interdata.
But back to the System/360 Model 20. I listed what it didn't have. But I
didn't list what it _did_ have. Because it didn't _just_ do halfword
arithmetic. It also came with the full decimal arithmetic instruction
set.
That meant that it wasn't just a minicomputer at mainframe prices. It
was a practical and useful machine, avoiding un-needed features, which
was very attractive to a certain market.
It doesn't seem to have offered, unlike the Model 30 (or the Model 25,
which came later) the option of 1401 emulation. But it was still very
useful to meet the data processing needs of 1401 customers.
And, since IBM *did* provide a FORTRAN compiler for the 1401, infamous
for requiring a record number of passes, and FORTRAN ran on the IBM
1620, another decimal machine, it would have been possible, at least in
theory, for someone to write a FORTRAN compiler for Model 20 owners.
Floating-point numbers could have been represented by a 16-bit binary
exponent accompanying a BCD mantissa of up to 16 digits ... the number
of digits being susceptible, as with 1401 FORTRAN, to arbitrary
specification. I doubt, of course, that anyone *did* that, but it was
certainly possible.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account
Continue reading on narkive:
Loading...