Put out to Pasture ? - Programming Languages

multicsfan wrote:
[color=blue]
> FYI: you can put 3330 disk drives on 360's but it must be a model 50 or
> faster. On a model 50 the I/O rate takes, IIRC, about half the memory
> bandwidth on a model 50. RPI ([url]www.rpi.edu[/url]) replaced their model 50 with
> a 67 and bought calcomp 3330's and aa brand X box to allow the 3330's to
> talk to a 360. This kinda forced IBM to admit it could be done and they
> later did offer IBM 3330's for the 360.[/color]

The ones I remember were Itel 7330's.

I didn't remember IBM selling them for the 360, but it may be that they did.

-- glen

"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:446F4FD8.6040205@comcast.net...[color=blue]
> Peter Flass wrote:
>
> Also WATFIV produced far more comprehensible error and warning messages
> than did IBM FORTRAN.[/color]

Are you sure?
IIRC it was just the error number.
You then looked up the number in the list of error messages.
That's why the WATFOR/WATFIV books produced the complete
list in an appendix.
[color=blue]
> This was a big help to students who were just
> learning the language. IIRC, most of IBM's error messages consisted of
> "IExx" followed by some number or other. When one looked up the number
> in the appropriate IBM manual (which were off-limits to most beginning
> students), it usually had a code of 3 or 4 zeros in one column followed
> by text containing the remedial action in the next column. In most
> cases, the 3- or 4-zero code translated to "probable user error" and the
> text read "Fix program and resubmit". The other suggested remedial
> action was to reinstall or reboot the system taking complete dumps
> before and after and then send those dumps to IBM -- hardly useful in a
> batch environment with a looming homework due date.
>
> The same was true of PL/C error and warning messages as compared with
> those for IBM PL/I (F)[/color]

The PL/I-F messages were generally helpful and explanatory,
though there were a few cryptic ones.
[color=blue]
> though I believe the Checkout compiler was more
> informative.[/color]

"Peter Flass" <Peter_Flass@Yahoo.com> wrote in message
news:dBDbg.267$W97.124@twister.nyroc.rr.com...[color=blue]
> robin wrote:[color=green]
> > Commercial PL/I work was done from the beginning.
> > RECORD isn't necessary for commercial work.
> > PUT EDIT (R) (A);
> > was sufficient, and was simply replaced by a WRITE
> > when required.[/color]
>
> I disagree. The overhead of stream I/O would have been unacceptable on
> the old boxes.[/color]

I repeat. RECORD isn't necessary.
Early commercial I/O could use stream.
[color=blue]
> Record had the advantage that the data was read by the
> channel and dropped directly into the buffer where PL/I then read it.
> For stream, you're looking at, at a minumum, moving each record once
> from the file buffer to the programmer's data area.[/color]

Though it takes longer, as there was no alternative.
(RECORD) I/O using stream was fine.

However, you're overlooking blocked records,
which helped minimise the effects of moving twice,
as the major time was the I/O transfer, not the move.
Blocking records could achieve a 10 times increase in speed.
[color=blue][color=green]
> > I did some timing tests with IBM FORTRAN and PL/I.
> > PL/I and FORTRAN compilers were about the same speed;
> > however, IIRC the link time for
> > PL/I was about twice that of Fortran, so that
> > CLG was a tad longer for PL/I.[/color]
>
> That's why most colleges didn't use IBM FORTRAN either.[/color]

They could do that only if there was enough memory.
There wasn't enough on ours, so we couldn't use it.
[color=blue]
> WATIV, as a
> load and go compiler that could process a complete batch of student jobs
> in one execution, was preferred.[/color]

Only if there was sufficient memory.
Both the compiler and compiled code had to reside
in memory side-by-side.
[color=blue]
> You also said:[color=green]
> >
> > The H compiler?
> > It did "see the light of day".
> > We used the H compiler after we got our LCS.
> >[/color]
> You didn't happen to save a copy of the source by any chance, did you?[/color]

Nothing remains.

"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:446F5070.3040906@comcast.net...[color=blue]
> robin wrote:[color=green]
> > "Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
> > news:446DBC76.90205@comcast.net...
> >[color=darkred]
> >>Then, too, the CDC CYBER design was a RISC design long before the term
> >>became popular. OTOH, they had 6-bit characters, one's-complement
> >>arithmetic,[/color]
> >
> > (groan)
> >
> > and 65 characters for those 6 bits!
> >[/color]
> I only remember the 63-character set and the 64-character set (well,
> there were some others, but those were the most common). How did you
> get 65 characters? Were you counting the 2- to 11-colon sequence
> indicating end of line as the 65th?[/color]

The double colon at the end of a word
was interpreted as end of line.
When there was an actual double colon in the
output data, we got a spurious line feed
in the middle of the line, and the remainder
of the text on the following line.

"Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
news:446F5070.3040906@comcast.net...
[color=blue]
> With 64 distinct bit patterns in 6 bits, the original 63-character set
> used zero as a sort of line terminator and the other 63 bit patterns as
> printable characters. I've never been able to track down the definitive
> origins of the 64-character set, but it was rumored that some competitor
> of CDC somehow persuaded some government agency to include a requirement
> for a character set containing at least 64 printable characters into
> some RFP somewhere in an attempt to shut CDC out of any future bid.
>
> The 64-character set, rather than adding the new character in at
> character code zero, reassigned the colon (':') from octal 63 (IIRC) to
> octal 00 and replaced octal 63 with the percent sign ('%'). This
> presented them with the problem of indicating end of line. Since the
> CYBERs had a 60-bit (10-character) word size, they chose to interpret
> any sequence of 2 or more zero characters ending on a word boundary as
> an end of line. Thus, in the simplest cases, a printable line was
> represented by a string of characters with the last word padded on the
> right with zeros. A problem arose if the last word in the line
> contained 9 characters leaving room for only one character of zero
> padding. In this case, the entire following word needed to be zero for
> a total of 11 zero characters at the end of the line. In order to
> represent a colon at the end of a line, it was necessary to follow it
> with a blank before the terminating sequence of zero characters (in
> which case, of course, the colon would not be at the end of the line,
> strictly speaking).
>
> Of course the character set didn't match any of BCD, EBCDIC, or ASCII
> because standards were so important that everyone needed to have one.
> But one interesting feature of both the 63- and 64-character sets was
> that one's complement addition or subtraction performed on two character
> strings of decimal digits produced a character string result equal to
> the equivalent of 9's complement arithmetic operation performed on the
> decimal strings. I don't know whether that was deliberate or whether it
> was ever exploited by their COBOL compiler.
>
> I remember being extremely annoyed by the Pascal language and academia's
> love affair with St. Nik and one aspect of the CDC character set
> emphasized one of the reasons. The Pascal language definition was so
> vague and sloppy it could hardly be called a language definition.
> Nowhere was this more evident than in its definition of a set or the
> requirements for implementation thereof. Thus, the CDC version of the
> compiler had an upper bound on the size of a set of something like 58
> elements and the same upper bound on the number of distinct elements in
> any set universe. This let them represent any individual element and
> any set with a single word and left a couple of bit patterns available
> for "uninitialized" or to avoid using the messy sign bit. But since
> both the 63- and 64-character sets used octal 77 to represent a
> semicolon (';'), this precluded using a set of characters in the parser
> -- yet it was still compatible with the Pascal language definition and
> standard.
>
> Of course, the inability of either the 63- or 64-character set to
> represent lower-case characters left CDC at a serious competitive
> disadvantage. I remember when I worked for CDC in the early '80s when
> we had to buy some Wang word processors to write up our proposals for
> contracts because our own CDC machines (which we touted as more powerful
> than, or at least as powerful as, anybody else's mainframe) couldn't
> handle lower-case letters.
>
> CDC "solved" this by reinterpreting some of the characters as escape
> characters. I think the caret ('^') was one of them and used (among
> other things) to convert the following character to lower case or for
> some control characters. Thus, the printable word "Case" would be
> represented by the character string "C^A^S^E" and any line containing
> lower-case letters could be up to twice as long as the same line if all
> the characters were upper-case. I believe they also used the at sign
> ('@') as an additional escape character and I believe caret ('^') and at
> ('@") were represented as '^^' and '^@' respectively. This "solution"
> gave CDC an expanded character set which they used to define additional
> characters to cover the entire 256-character ASCII character set.[/color]

Yes, wasn't that fun!

The other PITA was the multiplier.

Not having a spare op code, the question was
how to do integer multiplication when all there
was was a float multiplier.

A:- If the exponent field was zero or all ones,
do an integer multiply,
otherwise do a float multiply.
Thus, if your integer was more than 48 bits,
you got a garbage result because the integer
was interpreted as a float. All without warning,
of course.

glen herrmannsfeldt wrote:[color=blue]
> John W. Kennedy wrote:
>[color=green]
>> glen herrmannsfeldt wrote:[/color]
>[color=green][color=darkred]
>>> Most likely PCP would IPL on later S/370, as I believe it doesn't do
>>> storage protection.[/color][/color]
>[color=green]
>> It did if you sysgenned it to.[/color]
>
> I think it wasn't the default, though. The later starter system is
> an MFT without storage protection.[/color]

Not all 360's /had/ storage protection. On some models, it was optional,
and OS/360 respected that.

The sheer lunacy of the design, however, soon became evident. By the
time multiprogramming was added to DOS/360 (and TOS/360), they required
storage protection first.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

glen herrmannsfeldt wrote:[color=blue]
> multicsfan wrote:
>[color=green]
>> FYI: you can put 3330 disk drives on 360's but it must be a model 50
>> or faster. On a model 50 the I/O rate takes, IIRC, about half the
>> memory bandwidth on a model 50. RPI ([url]www.rpi.edu[/url]) replaced their
>> model 50 with a 67 and bought calcomp 3330's and aa brand X box to
>> allow the 3330's to talk to a 360. This kinda forced IBM to admit it
>> could be done and they later did offer IBM 3330's for the 360.[/color]
>
> The ones I remember were Itel 7330's.
>
> I didn't remember IBM selling them for the 360, but it may be that they
> did.[/color]

They were certainly available on the 360/85 and 360/195. On other 360s,
they would have taken a considerable performance hit from the lack of a
block multiplexor channel.

--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"

robin wrote:
[color=blue]
> "Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
> news:446F4FD8.6040205@comcast.net...
>[color=green]
>>Peter Flass wrote:
>>
>>Also WATFIV produced far more comprehensible error and warning messages
>>than did IBM FORTRAN.[/color]
>
>
> Are you sure?
> IIRC it was just the error number.
> You then looked up the number in the list of error messages.
> That's why the WATFOR/WATFIV books produced the complete
> list in an appendix.[/color]

I'm sure although there may have been an implimentation option in WATFIV
to reduce memroy needs by only printing an error code. I've got a
printed copy of the WATFIV source around somewhere as I did an undergran
project to modify the source to make WATFIV more interactive user
friendly from its batch only orientation.

robin wrote:[color=blue]
> "Bob Lidral" <l1dralspamba1t@comcast.net> wrote in message
> news:446F4FD8.6040205@comcast.net...
>[color=green]
>>Peter Flass wrote:
>>
>>Also WATFIV produced far more comprehensible error and warning messages
>>than did IBM FORTRAN.[/color]
>
>
> Are you sure?
> IIRC it was just the error number.
> You then looked up the number in the list of error messages.
> That's why the WATFOR/WATFIV books produced the complete
> list in an appendix.
>[/color]
I used to be a TA for introductory FORTRAN classes using WATFIV. I
don't remember having to look up errors in the book and I'm pretty sure
I would have remembered that. OTOH, I never used WATFOR and there may
have been compiler installation options that affected the level of
information in error and warning messages.
[color=blue]
>[color=green]
>> This was a big help to students who were just
>>learning the language. IIRC, most of IBM's error messages consisted of
>>"IExx" followed by some number or other. When one looked up the number
>>in the appropriate IBM manual (which were off-limits to most beginning
>>students), it usually had a code of 3 or 4 zeros in one column followed
>>by text containing the remedial action in the next column. In most
>>cases, the 3- or 4-zero code translated to "probable user error" and the
>>text read "Fix program and resubmit". The other suggested remedial
>>action was to reinstall or reboot the system taking complete dumps
>>before and after and then send those dumps to IBM -- hardly useful in a
>>batch environment with a looming homework due date.
>>
>>The same was true of PL/C error and warning messages as compared with
>>those for IBM PL/I (F)[/color]
>
>
> The PL/I-F messages were generally helpful and explanatory,
> though there were a few cryptic ones.
>[/color]
I may be mistaken; it has been a very long time since I used PL/I on a
360 (early 1978). I do remember the Messages and Codes manual for
utilities and similar sections of other manuals containing similar
information specific to other products. Maybe my memory is a little off
on this issue.


Bob Lidral
lidral at alum dot mit dot edu