Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Looking for a real Fortran-66 compatible PC compiler (CP/M or DOS or Windows, doesn't matter)

78 views
Skip to first unread message

Peter Dassow

unread,
Dec 26, 2010, 6:04:52 AM12/26/10
to
Hi,

I have to compile some very old Fortran-66 programs, but I do not have
an IBM host or a TOPS-10/VMS machine.
So I am looking for a real compatible compiler for these old sources,
Fortran-80 (CP/M) is one of the candidates, but there are problems with
the data types. Are there any other PC compatible Fortran-66 compilers
out there ?

Regards
Peter

Peter Flass

unread,
Dec 26, 2010, 7:46:33 AM12/26/10
to

What do you want to do? Do you need to generate PC code, or just run on
a PC? There are PC-based emulators for IBM 360/370, VAX/VMS, and
TOPS-10. I know at least the IBM and DEC-10 emulators have FORTRAN
compilers, and I expect the VAX does also.

Peter Dassow

unread,
Dec 26, 2010, 10:23:32 AM12/26/10
to

Peter,

I want to give them as .EXE / .COM away, so others without an emulator
can run these executables also.
Also, an emulator runs only perfect if you have the OS also installed,
VMS should be difficult (it must be licen$ed and the license is time
limited).

Regards
Peter

Dave Wade

unread,
Dec 26, 2010, 1:01:14 PM12/26/10
to

"Peter Dassow" <z8...@arcor.de> wrote in message
news:4d175df4$0$6888$9b4e...@newsspool2.arcor-online.net...

The IBM really old IBM Operating systems are all copywrite free and you can
bundle up a Hercules that will run batch jobs, but I agree its over kill for
a few Fortran programs. The oldest compiler I know of that available for
download that runs on a PC is FTN-77 from here:-

http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx

but its really strict. I actually found that Open Watcom was a better bet
and has compiled most of the Fortran-66 without too many issues...

http://www.openwatcom.org/index.php/Main_Page

>
> Regards
> Peter

Dave
G4UGM

Peter Dassow

unread,
Dec 26, 2010, 2:29:04 PM12/26/10
to
On 26.12.2010 19:01, Dave Wade wrote:
>
> I actually found that Open Watcom was a better
> bet and has compiled most of the Fortran-66 without too many issues...
>
> http://www.openwatcom.org/index.php/Main_Page
>
Dave, thanks for both URLs.
Watcom is really "fat" (~50MB) and the documentation is an endless PDF
file collection also. At the moment I am a bit concerned about such a
flood of files (compiler and docs).

Regards
Peter

Anne & Lynn Wheeler

unread,
Dec 26, 2010, 2:36:00 PM12/26/10
to

"Dave Wade" <dave....@gmail.com> writes:
> The IBM really old IBM Operating systems are all copywrite free and
> you can bundle up a Hercules that will run batch jobs, but I agree its
> over kill for a few Fortran programs. The oldest compiler I know of
> that available for download that runs on a PC is FTN-77 from here:-
>
> http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx
>
> but its really strict. I actually found that Open Watcom was a better
> bet and has compiled most of the Fortran-66 without too many issues...
>
> http://www.openwatcom.org/index.php/Main_Page

aka ... the company was somewhat forced into unbundling announced
23jun69 ... and starting to charge for (application) software (among
other things); however the company did managed to make the case that
kernel software should still be free. misc. past posts mentioning
23jun69 unbundling & starting to charge for software
http://www.garlic.com/~lynn/submain.html#unbundle

the company then started the Future System effort, somewhat motivated by
clone controllers ... but it failed w/o even being announced. During
Future System ... much of the other activity was killed off ... allowing
the 370 hardware&software product pipelines to go dry ... then when
Future System was killed ... there was made rush to get stuff back into
the 370 hardware&software product pipeline. recent post mentioning
Future System
http://www.garlic.com/~lynn/2010q.html#33 IBM Future System

shutting down 370 "competition" for FS and then having a dry 370
(hardware) product pipeline (when FS was killed) is credited with clone
processors getting a foothold in the market.

Rushing to get stuff back into the 370 product pipeline ... and facing
the clone processors is possible motivation for the transition to
starting to (also) charge/license kernel software (as well as the
transition to object-code-only).

above Future System post also references these web page:
http://www.cs.clemson.edu/~mark/fs.html
and
http://www.jfsowa.com/computer/memo125.htm

as well as other past posts mentioning FS
http://www.garlic.com/~lynn/2010q.html#32

--
virtualization experience starting Jan1968, online at home since Mar1970

William Hamblen

unread,
Dec 26, 2010, 4:14:47 PM12/26/10
to

How well goes gnu fortran77 work? You might be able to link with mingw32
to get a Microsoft Windows executible.

Bud

Tim Shoppa

unread,
Dec 26, 2010, 4:48:41 PM12/26/10
to

Fortran 66 wasn't especially portable as usually written. You may have
to hack some of the source code up anyway. Why not just port it over
to 77? This is sort of stuff a Fortran programmer does over a lunch
break (e.g. not a big deal.)

Tim.

Peter Dassow

unread,
Dec 26, 2010, 4:53:25 PM12/26/10
to
On 26.12.2010 22:48, Tim Shoppa wrote:
>
> Fortran 66 wasn't especially portable as usually written. You may have
> to hack some of the source code up anyway. Why not just port it over
> to 77? This is sort of stuff a Fortran programmer does over a lunch
> break (e.g. not a big deal.)
>
Yes, meanwhile that's what I thought also.
I have a collection of links already published at
http://www.z80.eu/for-compiler.html
but this was more CP/M centric ;-)

Regards
Peter

Tim Shoppa

unread,
Dec 26, 2010, 8:08:39 PM12/26/10
to
On Dec 26, 4:53 pm, Peter Dassow <z8...@arcor.de> wrote:
> On 26.12.2010 22:48, Tim Shoppa wrote:
>
> > Fortran 66 wasn't especially portable as usually written. You may have
> > to hack some of the source code up anyway. Why not just port it over
> > to 77? This is sort of stuff a Fortran programmer does over a lunch
> > break (e.g. not a big deal.)
>
> Yes, meanwhile that's what I thought also.
> I have a collection of links already published athttp://www.z80.eu/for-compiler.html

> but this was more CP/M centric ;-)

IMHO:

Writing portable Fortran, is far easier than writing portable C.

That doesn't mean it's often done :-)

Most CP/M machines will be "too small" to run any but the most trivial
Fortran applications anyway. The threaded code PDP-11 compilers could
let you do interesting stuff in 64K (especially with overlays - wow,
overlays were so important in that memory model) but I never saw any
x80 compilers do anything nearly so usable.

Gnu fortran77, mentioned elsewhere in this thread, takes an
interesting tack: AFAIK it doesn't support anybody's F77 extensions.
Having grown up in a world defined by F77 extensions (especially VAX/
PDP-11 and DOD extensions) this was a cultural shock when I first saw
it, but I now appreciate Gnu fortran77's stoicness as a way of
enhancing portability.

Tim.

H Vlems

unread,
Dec 27, 2010, 3:36:26 AM12/27/10
to
>   Peter- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

A (free, hobbyist) VMS license obtained thru the Montagar program
lasts a year.
All you need is an Encompass associate membership, which is free as
well.
If you need media then ask on c.o.v. and a kind soul will help you.
Hans

Peter Flass

unread,
Dec 27, 2010, 8:22:04 AM12/27/10
to

You could always convert it to PL/I ;-)

http://www.iron-spring.com/free.html

jmfbahciv

unread,
Dec 27, 2010, 8:49:45 AM12/27/10
to

What CPU do you want this to run on? an old compiler would generate
286 machine instructions?

/BAH

Tim Shoppa

unread,
Dec 27, 2010, 12:32:57 PM12/27/10
to
On Dec 26, 4:53 pm, Peter Dassow <z8...@arcor.de> wrote:
> On 26.12.2010 22:48, Tim Shoppa wrote:
>
> > Fortran 66 wasn't especially portable as usually written. You may have
> > to hack some of the source code up anyway. Why not just port it over
> > to 77? This is sort of stuff a Fortran programmer does over a lunch
> > break (e.g. not a big deal.)
>
> Yes, meanwhile that's what I thought also.
> I have a collection of links already published athttp://www.z80.eu/for-compiler.html

> but this was more CP/M centric ;-)

Peter -
I originally the thread was about crufty old Fortran 66 code, but
now I see that you are bringing in
crufty old CP/M platform Fortran 77 compilers too :-).

Most generically you will be more productive dealing with crufty
code, than with crufty compilers.

IMHO the compilers you name were crufty even when they were brand
new :-). Nothing against the attempt to put Fortran on an 8-bit micro,
just that from my 2010 perspective they missed the mark every time.

Tim.

Message has been deleted

Dave Wade

unread,
Dec 27, 2010, 5:49:39 PM12/27/10
to

"jmfbahciv" <See....@aol.com> wrote in message
news:PM0004986...@aca210e1.ipt.aol.com...

Both WATCOM and FTN77 generate 286 instructions but the code runs fine on
XP. I haven't tried on Windows/7 or 64 bit OS...


> /BAH

Charles Richmond

unread,
Dec 27, 2010, 11:26:23 PM12/27/10
to
On 12/26/10 7:08 PM, Tim Shoppa wrote:
> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>
>>> Fortran 66 wasn't especially portable as usually written. You may have
>>> to hack some of the source code up anyway. Why not just port it over
>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>> break (e.g. not a big deal.)
>>
>> Yes, meanwhile that's what I thought also.
>> I have a collection of links already published athttp://www.z80.eu/for-compiler.html
>> but this was more CP/M centric ;-)
>
> IMHO:
>
> Writing portable Fortran, is far easier than writing portable C.
>

I can only compare the porting of FORTRAN/66 or FORTRAN IV code to
porting programs written in C. In this comparison, ISTM that C is
much more portable. Perhaps FORTRAN 77 or later *is* more portable...

FORTRAN/66 and FORTRAN IV have *no* standard way to handle
character data in variables. This led to many non-portable
"tricks" to store character data.


--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+

Charles Richmond

unread,
Dec 27, 2010, 11:28:45 PM12/27/10
to

Just out of curiosity, what are these FORTRAN/66 programs doing
that is important enough to warrant compiling on a PC???

Dave Wade

unread,
Dec 28, 2010, 5:36:15 AM12/28/10
to

"Charles Richmond" <fri...@tx.rr.com> wrote in message
news:ifboth$d3$1...@news.eternal-september.org...


> On 12/26/10 7:08 PM, Tim Shoppa wrote:
>> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>>
>>>> Fortran 66 wasn't especially portable as usually written. You may have
>>>> to hack some of the source code up anyway. Why not just port it over
>>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>>> break (e.g. not a big deal.)
>>>
>>> Yes, meanwhile that's what I thought also.
>>> I have a collection of links already published
>>> athttp://www.z80.eu/for-compiler.html
>>> but this was more CP/M centric ;-)
>>
>> IMHO:
>>
>> Writing portable Fortran, is far easier than writing portable C.
>>
>
> I can only compare the porting of FORTRAN/66 or FORTRAN IV code to porting
> programs written in C. In this comparison, ISTM that C is much more
> portable. Perhaps FORTRAN 77 or later *is* more portable...
>
> FORTRAN/66 and FORTRAN IV have *no* standard way to handle character data
> in variables. This led to many non-portable "tricks" to store character
> data.
>

Fortran 77 has proper charter data. I spent about 10 years working on a file
transfer and job management package. The Salford Portable Communications
Package (SPCP) (any one still got a copy) was written in Fortran 77 because
at the time there were many machines without a "C" compiler. However the
code posed many challenges as there is no dynamic memory management in
Fortran 77. The solution was to use a couple of large arrays, one of
integers and one of characters. Among other things the integer array was
used to manage the entires in the character variables. The data in the
character variables was "structured" by use of contestants that delimited
the substrings. However this did require the use of the INCLUDE statement
which was an extension. I think we had a macro processor that could be used
if we met a compiler without INCLUDE...


>
> --
> +----------------------------------------+
> | Charles and Francis Richmond |
> | |
> | plano dot net at aquaporin4 dot com |
> +----------------------------------------+


Dave
G4UGM

jmfbahciv

unread,
Dec 28, 2010, 9:17:42 AM12/28/10
to
Charles Richmond wrote:
> On 12/26/10 7:08 PM, Tim Shoppa wrote:
>> On Dec 26, 4:53 pm, Peter Dassow<z8...@arcor.de> wrote:
>>> On 26.12.2010 22:48, Tim Shoppa wrote:
>>>
>>>> Fortran 66 wasn't especially portable as usually written. You may have
>>>> to hack some of the source code up anyway. Why not just port it over
>>>> to 77? This is sort of stuff a Fortran programmer does over a lunch
>>>> break (e.g. not a big deal.)
>>>
>>> Yes, meanwhile that's what I thought also.
>>> I have a collection of links already published
athttp://www.z80.eu/for-compiler.html
>>> but this was more CP/M centric ;-)
>>
>> IMHO:
>>
>> Writing portable Fortran, is far easier than writing portable C.
>>
>
> I can only compare the porting of FORTRAN/66 or FORTRAN IV code to
> porting programs written in C. In this comparison, ISTM that C is
> much more portable. Perhaps FORTRAN 77 or later *is* more portable...
>
> FORTRAN/66 and FORTRAN IV have *no* standard way to handle
> character data in variables.

That's because characters weren't considered data back then.

> This led to many non-portable
> "tricks" to store character data.
>
>

Which should work, albeit slowerly.

/BAH

jmfbahciv

unread,
Dec 28, 2010, 9:17:41 AM12/28/10
to


If the code had been running on a PDP-10, I'd have suggested using
the switch which causes the compiler to revert to an old standard.
However, I don't know if any of those PC compilers ever bothered
to support backwards compatible FORTRAN code.

/BAH

Dave Wade

unread,
Dec 28, 2010, 10:30:07 AM12/28/10
to

"jmfbahciv" <See....@aol.com> wrote in message

news:PM0004987...@aca2ecfe.ipt.aol.com...

FTN77 isn't a "PC Compiler" its a Portable Fortran 77 Compiler that has been
ported to the PC environment. It started out life as a Fortran 77 compiler
for ICL 1900. ICL had refused to develop a Fortran 77 compiler for the 1900
Series and tried to get Universities to switch to 2900 series. When Salford
University "jumped ship" and switched from ICL1900 to PR1MOS, the PR1ME
machines they bought were benchmarked using the PR1ME Fortran 66 compiler as
the Fortran 77 compiler wasn't available when the machines were ordered.
When the PR1ME Fortran 77 compiler finally appeared its performance was dire
,and so FTN was ported to PR1MOS. Later as PCs became widely used within the
University an MS-DOS port was also produced, For many years the compilers
were formally ANSI certified but these days this doesn't happen for cost
reasons. Logically the compiler supports some extensions to allow Fortran 66
code to compile, refer to the user guide for details.

http://www.silverfrost.com/53/ftn77/ftn77_dbos_history.aspx

In a similar manner the Open WATCOM compilers are descended from earlier
mainframe tools, but in this case the lineage is not so clearly traceable.
Looking at the source code for V1.2 of OpenWatcom remnants of the IBM/360
code generation were still present but I never managed to get it to emit
"Mainframe" code. I note that it also supports Hollerith constants for
Fortran 66 compatability, but could not find the other options.

> /BAH

Dave
G4UGM

Peter Dassow

unread,
Dec 28, 2010, 12:28:48 PM12/28/10
to
On 28.12.2010 05:28, Charles Richmond wrote:
>> I have to compile some very old Fortran-66 programs, but I do not
>> have an IBM host or a TOPS-10/VMS machine.
>>
>
> Just out of curiosity, what are these FORTRAN/66 programs doing that is
> important enough to warrant compiling on a PC???
>
These programs calculate the attenuation of an oscillation, and it's not
only a sinus which calms down to zero ;-)

Regards
Peter

Peter Flass

unread,
Dec 28, 2010, 5:20:57 PM12/28/10
to
^^^^^^^^ Great word! I'll have to
remember it.

>
> /BAH

ArarghMai...@not.at.arargh.com

unread,
Dec 28, 2010, 6:19:48 PM12/28/10
to

The IBM Fortran compiler for the PC (from 1982) has some support for
Fortran 66 compatability, but I don't know how much.

--
ArarghMail012 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 extra stuff from the reply address.

Charles Richmond

unread,
Dec 28, 2010, 8:40:30 PM12/28/10
to

Yes, I used and liked FORTRAN 77. I just *never* had to port any
of the FORTRAN 77 code. At a PPoE that was a defense contractor,
we had to rehost some simulations on a Harris 800/1200 from a CDC
6600. These were what might be termed "legacy" FORTRAN code... in
FORTRAN/66 or FORTRAN IV.

Rich Alderson

unread,
Dec 28, 2010, 10:29:47 PM12/28/10
to
Peter Dassow <z8...@arcor.de> writes:

> Hi,

> I have to compile some very old Fortran-66 programs, but I do not have
> an IBM host or a TOPS-10/VMS machine.

I was going to point out that Tops-10, TOPS-20, and VMS accounts are available
for free at Living Computer Museum, but having read the entire thread to this
point before responding, I see that that will not solve your issue.

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

Peter Flass

unread,
Dec 29, 2010, 8:29:11 AM12/29/10
to

The comments about FORTRAN portability are interesting. ISTR before
"C", most programs intended to be portable were written in FORTRAN as
the mos standard and widely-used language.

jmfbahciv

unread,
Dec 29, 2010, 9:38:03 AM12/29/10
to

Do you know any physicists?

/BAH

jmfbahciv

unread,
Dec 29, 2010, 9:38:02 AM12/29/10
to
Rich Alderson wrote:
> Peter Dassow <z8...@arcor.de> writes:
>
>> Hi,
>
>> I have to compile some very old Fortran-66 programs, but I do not have
>> an IBM host or a TOPS-10/VMS machine.
>
> I was going to point out that Tops-10, TOPS-20, and VMS accounts are
available
> for free at Living Computer Museum, but having read the entire thread to
this
> point before responding, I see that that will not solve your issue.
>

He could try to compile the code with a /[can't remember exact spelling]
FORTRAN66 switch. Well, I just found a FORTRAN manual and it doesn't
mention this switch. drat.

I was going to say to compile the code on a -10 of any flavor just
to see what kinds of problems the code will have. There is a compiler
/SYNTAX switch which won't output any rel code but do a syntax only
check of the FOR code.

If he could generate a PDP-10 exe, is it possible to do a conversion
of PDP-10 instructions to 286 instructions?

Monitor interface code would be later project. But at least he
could find out how much of the FORTRAN code is incompatible with
/F77.

/BAH

Bill Leary

unread,
Dec 29, 2010, 11:20:24 AM12/29/10
to
"Peter Flass" <Peter...@Yahoo.com> wrote in message
news:iffd37$hrc$1...@news.eternal-september.org...

> The comments about FORTRAN portability are interesting. ISTR before "C",
> most programs intended to be portable were written in FORTRAN as the mos
> standard and widely-used language.

This was my experience.

The problem was that, for business applications, which is mostly what I did,
there was a different way to handle character data for each implementation.
Well, not literally of course, but it sure seemed like it every time I had
to port something.

- Bill

sidd

unread,
Dec 29, 2010, 1:20:34 PM12/29/10
to
On Tuesday 28 December 2010 12:28, Peter Dassow wrote:


>>
> These programs calculate the attenuation of an oscillation, and it's
not
> only a sinus which calms down to zero ;-)

i take it that you are solving a differential equation ?
A Runge-Kutta by any chance ?

hanc...@bbs.cpcn.com

unread,
Dec 29, 2010, 2:24:04 PM12/29/10
to
On Dec 28, 12:28 pm, Peter Dassow <z8...@arcor.de> wrote:

> > Just out of curiosity, what are these FORTRAN/66 programs doing that is
> > important enough to warrant compiling on a PC???
>
> These programs calculate the attenuation of an oscillation, and it's not
> only a sinus which calms down to zero ;-)

If there isn't a great deal of code involved, it may be easier to
rewrite the programs into a modern Fortran that can be more easily
compiled to create .EXE files. The rewrite effort might be easier
than trying to find a usable compiler and making it work. I wonder
how much code there is overall, and how much of it is specific to
Fortran/66 and not compatible with later versions. I am in no way a
physicist, but I wonder if such a program is mostly some DO LOOPs with
a bunch of calculation statements.

If the overall code is relatively small, it might be easier to get a
QuickBasic (or BASIC PDS) compiler and rewrite the code for them. As
a last resort, you could use your QBASIC interpreter which should
still be part of your Windows CD, and just send that out with the
code.

I presume the program runs in batch mode. How would the I/O be--
specifying the input and output files for a PC?

Message has been deleted

Peter Flass

unread,
Dec 29, 2010, 3:56:51 PM12/29/10
to

Dredging back in my memory, input and output was to nAm where m was the
number of characters per word, and n was the number of words. If you
specified A1 you got one character per word - portable but not very
efficient.

Peter Flass

unread,
Dec 29, 2010, 3:59:14 PM12/29/10
to
On 12/29/2010 2:31 PM, Morten Reistad wrote:
> In article<PM0004988...@ac81a7a6.ipt.aol.com>,

> jmfbahciv<See....@aol.com> wrote:
>> Rich Alderson wrote:
>>> Peter Dassow<z8...@arcor.de> writes:
>>>
>>>> Hi,
>>>
>>>> I have to compile some very old Fortran-66 programs, but I do not have
>>>> an IBM host or a TOPS-10/VMS machine.
>>>
>>> I was going to point out that Tops-10, TOPS-20, and VMS accounts are
>> available
>>> for free at Living Computer Museum, but having read the entire thread to
>> this
>>> point before responding, I see that that will not solve your issue.
>>>
>>
>> He could try to compile the code with a /[can't remember exact spelling]
>> FORTRAN66 switch. Well, I just found a FORTRAN manual and it doesn't
>> mention this switch. drat.
>>
>> I was going to say to compile the code on a -10 of any flavor just
>> to see what kinds of problems the code will have. There is a compiler
>> /SYNTAX switch which won't output any rel code but do a syntax only
>> check of the FOR code.
>>
>> If he could generate a PDP-10 exe, is it possible to do a conversion
>> of PDP-10 instructions to 286 instructions?
>
> I have used g77 with some success on old, well tested f66 programs.
> You can give switches to allow always-execute do, use arithmetic
> if, computed goto, hollerith constants, f66 formatting, old
> equivalence semantics, classic type defaults, and f66 format
> handling. Plus computed assign; a.k.a. "comefrom".

Wouldn't it have been easier if they'd had a -F66 switch?

>
>> Monitor interface code would be later project. But at least he
>> could find out how much of the FORTRAN code is incompatible with
>> /F77.
>

> It is easy to spot, but a lot harder to fix. A lot of these
> programs are state machines that step along using arithmetic
> if statement. easy to spot, a lot harder to port.

Why?


Message has been deleted

Quadibloc

unread,
Dec 29, 2010, 10:56:23 PM12/29/10
to
On Dec 29, 11:20 am, sidd <s...@situ.com> wrote:

> i take it that you are solving a differential equation ?
> A Runge-Kutta by any chance ?

If anyone is fooling around with stuff like that, there's a famous
book I think I will recommend. It's titled "Numerical Methods That
Work".

Apparently, when trying to solve differential equations by computer,
it's all too easy to use, by mistake, numerical methods that _don't_
work. Good wishes, good luck - and take care.

John Savard

Quadibloc

unread,
Dec 29, 2010, 11:05:40 PM12/29/10
to
On Dec 29, 6:29 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> The comments about FORTRAN portability are interesting.  ISTR before
> "C", most programs intended to be portable were written in FORTRAN as
> the mos standard and widely-used language.

It is definitely true that FORTRAN was a widely-used language. And it
wasn't a super-fancy language - it didn't come with huge class
libraries - so when programs did have portability problems, it wasn't
like trying to port a C++ program from Windows to the Macintosh or to
the X Window System.

Instead, think of the early dialects of BASIC that required you to put
a line number in front of each line.

FORTRAN was better than that, but it was still in that general class.
You could write programs that did fancy mathematics, and which then
printed simple output. Your installation might have provided you with
special subroutines to draw pictures on a pen plotter, probably made
by Calcomp. Otherwise, well, there was a "tab" function in the FORMAT
statement, so you could draw graphs where the position of an * along
the line of text marked the line you were drawing.

Portability consisted of things like the program depending strongly on
whether single-precision floating-point numbers had 6.23 digits of
precision or 6.56 digits of precision on the machine on which it was
used.

Since time on mainframes was charged for by the second, and they were
usually about as powerful as something like a 386 or a 486 DX, writing
as close to the hardware as possible for maximum efficiency was both a
virtue and a necessity.

John Savard

H Vlems

unread,
Dec 30, 2010, 2:43:24 AM12/30/10
to

The Numerical Algorithms Group (located in the UK IIRC) published a
manual for its software package.
The introduction clearly stated that all library programs had been
well designed and thoroughly tested along with the warning that
despite that the user was responsible for selecting the correct
routine for solving a problem. Wasting cpu cycles was considered bad
form in these days ;-)
Hans

Peter Flass

unread,
Dec 30, 2010, 8:04:35 AM12/30/10
to
On 12/29/2010 7:36 PM, Morten Reistad wrote:
> In article<ifg7f2$oua$2...@news.eternal-september.org>,

> Peter Flass<Peter...@Yahoo.com> wrote:
>> On 12/29/2010 2:31 PM, Morten Reistad wrote:
[snip}

>>> It is easy to spot, but a lot harder to fix. A lot of these
>>> programs are state machines that step along using arithmetic
>>> if statement. easy to spot, a lot harder to port.
>>
>> Why?
>

> This is a class of programming that was popular sometime around
> 1970 with the right people. They didn't think procedurally, they
> thought in mathematical flows and dependencies.
>
> Some of this code has "exploding call flow", using computed gotos
> and arithmetic ifs to their full potential, using state variables,
> often several; where each statement may have many next hops all
> depending on this state. Add assigned gotos (aka "comefrom") and
> you must rewrite, not port.
>

I'm amazed they'd get rid of this. Like it or not, this stuff was
widely used and still would seem to have a place.

I don't see that an arithmetic IF would be any more problematic than a
logical IF.

Everyone rags on GOTOs, too, but there are places where they're the most
appropriate solution. Assigned GOTOs are the most efficient way to
solve a number of problems. Take the case of a program that has a
number of options. You can have a switch that you test each time thru
the loop to see if a particular option is active, or you can have
assigned GOTOs that are set once in initialization and incurs no
additional overhead to test and branch later. If you need debugging,
have a text field in addition to the assigned GOTO that says what the
setting is without costing much in extra instructions.

For the record I usually try to program as straightforwardly as
possible, and if I do something exotic I usually decorate it with lots
of comments, but it's nice to know you can do the exotic stuff when
necessary.

jmfbahciv

unread,
Dec 30, 2010, 9:15:52 AM12/30/10
to

I'm assuming that the OP wants to know the outcome of the existing
code, not an unknown output of a rewrite using a different FORLIB
library.

/BAH

Walter Bushell

unread,
Dec 30, 2010, 2:40:38 PM12/30/10
to
In article
<807cdf77-7e4c-48ae...@o4g2000yqd.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:

People use these without a sanity clause. Hilarity ensues.

--
The Chinese pretend their goods are good and we pretend our money
is good, or is it the reverse?

Walter Bushell

unread,
Dec 30, 2010, 2:49:18 PM12/30/10
to
In article
<c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:

> FORTRAN was better than that, but it was still in that general class.
> You could write programs that did fancy mathematics, and which then
> printed simple output. Your installation might have provided you with
> special subroutines to draw pictures on a pen plotter, probably made
> by Calcomp. Otherwise, well, there was a "tab" function in the FORMAT
> statement, so you could draw graphs where the position of an * along
> the line of text marked the line you were drawing.

You had the "tab" function -- luxury!

But we had data techs who took the printouts and plotted the results by
hand, of course.

Dave Wade

unread,
Dec 30, 2010, 4:43:43 PM12/30/10
to

"H Vlems" <hvl...@freenet.de> wrote in message
news:9449daac-5ec3-4c40...@o14g2000yqe.googlegroups.com...

We still get this today. I subscribe to the LTSpice list. LTSpice is a
customized version of the Berkley Spice circuit simulation program. It has
several algorithms for solving the differential equations. Its interesting
to see folks complaining about the simulation breaking down and having to
change the algorithm...

> Hans

Dave

Charlie Gibbs

unread,
Dec 30, 2010, 2:08:30 AM12/30/10
to
In article
<c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
jsa...@ecn.ab.ca (Quadibloc) writes:

> It is definitely true that FORTRAN was a widely-used language.

Stan Kelly-Bootle described it as "transportable as syphilis".

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Chris Barts

unread,
Jan 1, 2011, 7:28:45 PM1/1/11
to
Peter Flass <Peter...@Yahoo.com> writes:

> On 12/29/2010 7:36 PM, Morten Reistad wrote:
>> In article<ifg7f2$oua$2...@news.eternal-september.org>,
>> Peter Flass<Peter...@Yahoo.com> wrote:
>>> On 12/29/2010 2:31 PM, Morten Reistad wrote:
> [snip}
>
>>>> It is easy to spot, but a lot harder to fix. A lot of these
>>>> programs are state machines that step along using arithmetic
>>>> if statement. easy to spot, a lot harder to port.
>>>
>>> Why?
>>
>> This is a class of programming that was popular sometime around
>> 1970 with the right people. They didn't think procedurally, they
>> thought in mathematical flows and dependencies.
>>
>> Some of this code has "exploding call flow", using computed gotos
>> and arithmetic ifs to their full potential, using state variables,
>> often several; where each statement may have many next hops all
>> depending on this state. Add assigned gotos (aka "comefrom") and
>> you must rewrite, not port.
>>
>
> I'm amazed they'd get rid of this. Like it or not, this stuff was
> widely used and still would seem to have a place.
>
> I don't see that an arithmetic IF would be any more problematic than a
> logical IF.

The problem with arithmetic IF these days, of course, is that
approximately nobody knows what they are or how they work. All they see
is an IF statement that can magically choose from three different code
paths, as opposed to every other IF statement in every other language
they've ever seen in their entire lives. This can be solved with a
mini-lecture in a comment, but that kind of implies you add that lecture
to just about every piece of code that uses them. Maybe a macro would
help with this... ;)

> Everyone rags on GOTOs, too, but there are places where they're the
> most appropriate solution. Assigned GOTOs are the most efficient way
> to solve a number of problems. Take the case of a program that has a
> number of options. You can have a switch that you test each time thru
> the loop to see if a particular option is active, or you can have
> assigned GOTOs that are set once in initialization and incurs no
> additional overhead to test and branch later.

So... how do you get a compiler to optimize a branch that can be changed
semi-arbitrarily at runtime? This might be a non-issue in your specific
example, but once you introduce the possibility that all branches of a
certain type are no longer safe to optimize because you can't guarantee
where they'll point, you can't do the kind of static analysis even C
compilers are capable of these days.

> For the record I usually try to program as straightforwardly as
> possible, and if I do something exotic I usually decorate it with lots
> of comments, but it's nice to know you can do the exotic stuff when
> necessary.

Every programmer seems to think like this, but the caveat is that I, for
example, think that creating a jump table out of function pointers is
perfectly straightforward, but someone coming from a different
background might see it as unholy and bizarre voodoo, an abuse of the
language worthy of the International Obfuscated C Code Competition.

Quadibloc

unread,
Jan 1, 2011, 11:00:11 PM1/1/11
to
On Jan 1, 5:28 pm, Chris Barts <chbarts+use...@gmail.com> wrote:

> So... how do you get a compiler to optimize a branch that can be changed
> semi-arbitrarily at runtime?

Remember, to facilitate optimization, an assigned GOTO statement must
also list its possible branch targets - after the variable containing
the pointer, instead of, as in a computed GOTO statement, before the
variable containing the index.

Therefore, the compiler is given the information it needs to do
optimization.

John Savard

Peter Flass

unread,
Jan 2, 2011, 7:13:09 AM1/2/11
to

Taken to an extreme, this would imply we should get rid of anything that
isn't C (or Java). Many languages have features that appear odd to
someone who isn't used to them. Rather than a problem, this is an
opportunity for programmers to lose their tunnel vision.

>
>> Everyone rags on GOTOs, too, but there are places where they're the
>> most appropriate solution. Assigned GOTOs are the most efficient way
>> to solve a number of problems. Take the case of a program that has a
>> number of options. You can have a switch that you test each time thru
>> the loop to see if a particular option is active, or you can have
>> assigned GOTOs that are set once in initialization and incurs no
>> additional overhead to test and branch later.
>
> So... how do you get a compiler to optimize a branch that can be changed
> semi-arbitrarily at runtime? This might be a non-issue in your specific
> example, but once you introduce the possibility that all branches of a
> certain type are no longer safe to optimize because you can't guarantee
> where they'll point, you can't do the kind of static analysis even C
> compilers are capable of these days.
>
>> For the record I usually try to program as straightforwardly as
>> possible, and if I do something exotic I usually decorate it with lots
>> of comments, but it's nice to know you can do the exotic stuff when
>> necessary.
>
> Every programmer seems to think like this, but the caveat is that I, for
> example, think that creating a jump table out of function pointers is
> perfectly straightforward, but someone coming from a different
> background might see it as unholy and bizarre voodoo, an abuse of the
> language worthy of the International Obfuscated C Code Competition.

You mean there are people who don't think it's straightforward?
[ :-) ]. This is the problem that arises when people don't have an
assembler background. Again, it's not something I'd do too often, but
it's something that's nice to have in your bag of tricks when it's
appropriate. Often the alternatives require a lot more code.

Your point about optimization is a good one, but, little as I know about
optimization, I'd think a more straightforward test and conditional
branch could cause as many problems.

Walter Bushell

unread,
Jan 2, 2011, 10:05:39 AM1/2/11
to
In article <495.50T150...@kltpzyxm.invalid>,
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:

> In article
> <c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) writes:
>
> > It is definitely true that FORTRAN was a widely-used language.
>
> Stan Kelly-Bootle described it as "transportable as syphilis".

Whereas C and C++ are more like AIDS.

Charlie Gibbs

unread,
Jan 2, 2011, 1:38:33 PM1/2/11
to
In article <proto-358D87....@news.panix.com>, pr...@panix.com
(Walter Bushell) writes:

> In article <495.50T150...@kltpzyxm.invalid>,
> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> In article
>> <c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
>> jsa...@ecn.ab.ca (Quadibloc) writes:
>>
>>> It is definitely true that FORTRAN was a widely-used language.
>>
>> Stan Kelly-Bootle described it as "transportable as syphilis".
>
> Whereas C and C++ are more like AIDS.

:-) At this point I usually switch to the automotive analogies
that were making the rounds a while ago. Here's an excerpt:

Assembler: a Formula 1 race car. Very fast, but difficult to
drive and expensive to maintain.

Fortran II: a model T Ford. Once it was king of the road.

Fortran IV: a model A Ford.

Fortran 77: a six-cylinder Ford Fairlane with standard
transmission and no seat belts.

C: a black Firebird - the all-macho car. Comes with
optional fuzzbuster (escape to assembler).

Charlie Gibbs

unread,
Jan 2, 2011, 1:29:58 PM1/2/11
to
In article <8739pcd...@chbarts.motzarella.org>,
chbarts...@gmail.com (Chris Barts) writes:

> Peter Flass <Peter...@Yahoo.com> writes:
>
>> For the record I usually try to program as straightforwardly as
>> possible, and if I do something exotic I usually decorate it with
>> lots of comments, but it's nice to know you can do the exotic stuff
>> when necessary.
>
> Every programmer seems to think like this, but the caveat is that I,
> for example, think that creating a jump table out of function pointers
> is perfectly straightforward, but someone coming from a different
> background might see it as unholy and bizarre voodoo, an abuse of the
> language worthy of the International Obfuscated C Code Competition.

Ironically, the latter programmer probably engages in practices which
the former programmer would find equally unholy. Not only that, the
latter programmer probably doesn't bother commenting any of it,
because "my code is so readable that it doesn't need comments."

Peter Flass

unread,
Jan 2, 2011, 2:24:03 PM1/2/11
to
On 1/2/2011 10:05 AM, Walter Bushell wrote:
> In article<495.50T150...@kltpzyxm.invalid>,
> "Charlie Gibbs"<cgi...@kltpzyxm.invalid> wrote:
>
>> In article
>> <c883c421-322d-4d98...@w2g2000yqb.googlegroups.com>,
>> jsa...@ecn.ab.ca (Quadibloc) writes:
>>
>>> It is definitely true that FORTRAN was a widely-used language.
>>
>> Stan Kelly-Bootle described it as "transportable as syphilis".
>
> Whereas C and C++ are more like AIDS.
>

Straightforward C is pretty simple to port and/or translate.
Unfortunately these days everyone seems to be looking for opportunities
to show how clever they are, and include lots of tricks. Gnu code is
sometimes the worst. A lot of current stuff is unreadable,

Anne & Lynn Wheeler

unread,
Jan 2, 2011, 2:26:25 PM1/2/11
to
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:
> :-) At this point I usually switch to the automotive analogies
> that were making the rounds a while ago. Here's an excerpt:
>
> Assembler: a Formula 1 race car. Very fast, but difficult to
> drive and expensive to maintain.
>
> Fortran II: a model T Ford. Once it was king of the road.
>
> Fortran IV: a model A Ford.
>
> Fortran 77: a six-cylinder Ford Fairlane with standard
> transmission and no seat belts.
>
> C: a black Firebird - the all-macho car. Comes with
> optional fuzzbuster (escape to assembler).

just reading Iconoclast ...
http://www.amazon.com/Iconoclast-Neuroscientist-Reveals-Think-Differently/dp/1422115011

mentions that Ford was working in electrical industry and standard
wisdom was that electricity was going to win as power source. Ford
decided leave electricity and develop gasoline engine. Got a two
cylinder engine developed for Model A and sold less than 1000 ... enuf
to stay in business. The major break came by adapting new "french" steel
that was three times stronger with the addition of vanadium (or only
needed 1/3rd the steel and therefor 3 times lighter):
http://en.wikipedia.org/wiki/Vanadium

Reducing the weight by 2/3rds with two cylinder engine ... made the
Model T a significantly more attractive vehicle.
http://en.wikipedia.org/wiki/Model_T

--
virtualization experience starting Jan1968, online at home since Mar1970

Charles Richmond

unread,
Jan 2, 2011, 2:47:34 PM1/2/11
to
On 1/2/11 6:13 AM, Peter Flass wrote:
> On 1/1/2011 7:28 PM, Chris Barts wrote:
>>
>> [snip...] [snip...] [snip...]

>>
>> Every programmer seems to think like this, but the caveat is
>> that I, for example, think that creating a jump table out of function
>> pointers is perfectly straightforward, but someone coming from a different
>> background might see it as unholy and bizarre voodoo, an abuse
>> of the language worthy of the International Obfuscated C Code Competition.
>
> You mean there are people who don't think it's straightforward?
> [ :-) ]. This is the problem that arises when people don't have an
> assembler background. Again, it's not something I'd do too often,
> but it's something that's nice to have in your bag of tricks when
> it's appropriate. Often the alternatives require a lot more code.
>

ISTM that many C compilers would compile a "switch()" statement
with four or more cases... into a jump table in the generated
assembly. With three or less cases, it is *not* too inefficient to
generate the string of "if -- elseif -- elseif".


--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+

Peter Grange

unread,
Jan 2, 2011, 2:49:17 PM1/2/11
to
On 02 Jan 11 10:29:58 -0800, "Charlie Gibbs" <cgi...@kltpzyxm.invalid>
wrote:

>In article <8739pcd...@chbarts.motzarella.org>,
>chbarts...@gmail.com (Chris Barts) writes:
>
>> Peter Flass <Peter...@Yahoo.com> writes:
>>
>>> For the record I usually try to program as straightforwardly as
>>> possible, and if I do something exotic I usually decorate it with
>>> lots of comments, but it's nice to know you can do the exotic stuff
>>> when necessary.
>>
>> Every programmer seems to think like this, but the caveat is that I,
>> for example, think that creating a jump table out of function pointers
>> is perfectly straightforward, but someone coming from a different
>> background might see it as unholy and bizarre voodoo, an abuse of the
>> language worthy of the International Obfuscated C Code Competition.
>
>Ironically, the latter programmer probably engages in practices which
>the former programmer would find equally unholy. Not only that, the
>latter programmer probably doesn't bother commenting any of it,
>because "my code is so readable that it doesn't need comments."

Back in the days of assembler on the Honeywell 6000 a friend swears he
saw some code which executed backwards, using an XEC (execute single
instruction) and a decrementing index. Of no practical use, except to
make it properly unreadable.

Ahem A Rivet's Shot

unread,
Jan 2, 2011, 2:57:56 PM1/2/11
to
On Sun, 02 Jan 2011 19:49:17 +0000
Peter Grange <pe...@plgrange.demon.co.uk> wrote:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

It probably saved a word somehow.

--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/

Peter Grange

unread,
Jan 2, 2011, 3:12:09 PM1/2/11
to
On Sun, 2 Jan 2011 19:57:56 +0000, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

>On Sun, 02 Jan 2011 19:49:17 +0000
>Peter Grange <pe...@plgrange.demon.co.uk> wrote:
>
>> Back in the days of assembler on the Honeywell 6000 a friend swears he
>> saw some code which executed backwards, using an XEC (execute single
>> instruction) and a decrementing index. Of no practical use, except to
>> make it properly unreadable.
>
> It probably saved a word somehow.

Gosh I'd almost forgotten scrimping for memory. The GCOS operating
system had Slave Service Area programs which had to fit in a very
small space (512 words?) I can't remember exactly. I can remember some
of them being re-orged to get the word back which held the datestamp.

Joe Morris

unread,
Jan 2, 2011, 4:27:32 PM1/2/11
to
"Peter Grange" <pe...@plgrange.demon.co.uk> wrote:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

If you want to see some ... um, "interesting" coding techniques that make
analysis difficult, read a book (or better, take a class) in malware
detection and analysis. Alternatively, read competently-written
investigation reports of some of the more recent major attacks where
obfustication is repeatedly piled on top of obfustication, foiling (or at
least impeding) signature-based detection, and making it very difficult to
determine just what the attacker actually did.

Joe Morris


Dave Wade

unread,
Jan 2, 2011, 5:44:41 PM1/2/11
to

"Peter Grange" <pe...@plgrange.demon.co.uk> wrote in message
news:0gl1i6t7984s2ql7o...@4ax.com...

Probably provided by Honeywell. There was some really weird code in GCOS3.

Peter Grange

unread,
Jan 2, 2011, 6:45:49 PM1/2/11
to
On Sun, 2 Jan 2011 22:44:41 -0000, "Dave Wade" <dave....@gmail.com>
wrote:

Where do you know GCOS3 from? I worked in Systems Test and Engineering
in Newhouse and later in GC0S3, GCOS8 (briefly), CP6 and even a
smidgeon of Multics support in the UK.

Charlie Gibbs

unread,
Jan 3, 2011, 4:30:51 PM1/3/11
to
In article <0gl1i6t7984s2ql7o...@4ax.com>,
pe...@plgrange.demon.co.uk (Peter Grange) writes:

> Back in the days of assembler on the Honeywell 6000 a friend swears he
> saw some code which executed backwards, using an XEC (execute single
> instruction) and a decrementing index. Of no practical use, except to
> make it properly unreadable.

I once wrote a program that executed backwards by filling memory with
copies of an instruction that decremented the program counter by 8
bytes (the instruction was 4 bytes long). In low memory I placed
a branch to the end of memory so that it looped backwards.

Peter Flass

unread,
Jan 3, 2011, 4:57:32 PM1/3/11
to
On 1/3/2011 4:30 PM, Charlie Gibbs wrote:
> In article<0gl1i6t7984s2ql7o...@4ax.com>,
> pe...@plgrange.demon.co.uk (Peter Grange) writes:
>
>> Back in the days of assembler on the Honeywell 6000 a friend swears he
>> saw some code which executed backwards, using an XEC (execute single
>> instruction) and a decrementing index. Of no practical use, except to
>> make it properly unreadable.
>
> I once wrote a program that executed backwards by filling memory with
> copies of an instruction that decremented the program counter by 8
> bytes (the instruction was 4 bytes long). In low memory I placed
> a branch to the end of memory so that it looped backwards.
>

Too much time on your hands?

Dave Wade

unread,
Jan 3, 2011, 6:50:10 PM1/3/11
to

"Peter Grange" <pe...@plgrange.demon.co.uk> wrote in message

news:6u22i6la3vp0aijec...@4ax.com...

I worked at Refuge Assurance in Manchester for five years, three on their
L66/10, then I went to the Natural Environment Research Council at Bidston,
Birkenhead where they had a L66/60 (I think memory is dim) later upgraded to
a DPS300. NERC was real fun as we had lots of mods in GCOS so we could
connect to JANET and use the local editing facilities in our HP26xx
terminals which made the system some what unreliable.

I went to training at Hammersmith, and also to the TSS internals course in
Amsterdam. When I cam back from that I took one line from out TSS
modifications and the system failures went from one an hour to one a week.
When NERC changed their Honeywell to IBM VM/CMS I was dragged across to IBM.

Vince (Martin?) who used to work in the Phoenix performance labs but left to
set up his own company told me about the gearshift fudge.
He also explained a lot to me about performance and the importance of I/O
tunning. He ran a performance course, also in Amsterdam!.

I do miss those days, computing was fun, and we knew the internals of the
systems in detail.

Dave

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:25:54 PM1/3/11
to
On Dec 29 2010, 11:05 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> Since time on mainframes was charged for by the second, and they were
> usually about as powerful as something like a 386 or a 486 DX, writing
> as close to the hardware as possible for maximum efficiency was both a
> virtue and a necessity.

People who did some serious number crunching on old machines told me
the machines, even an 1130, were quite powerful and could do an awful
lot of work.

The big advantage of PCs when they came out was that they were
personal and dedicated to your use, no waiting, no sharing.

If you were lucky enough to get priority use of a mainframe, you could
get a great deal of work done quickly.

Anybody check out the Principles of Operation for today's IBM
mainframes? Lots of new instructions. I would hope the current
Fortran compilers make good use of them.

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:30:44 PM1/3/11
to
On Dec 30 2010, 8:04 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > Some of this code has "exploding call flow", using computed gotos
> > and arithmetic ifs to their full potential, using state variables,
> > often several; where each statement may have many next hops all
> > depending on this state. Add assigned gotos (aka "comefrom") and
> > you must rewrite, not port.
>
> I'm amazed they'd get rid of this.  Like it or not, this stuff was
> widely used and still would seem to have a place.

Computed GO TOs, like the ALTER statement in COBOL, were very
difficult for other people to maintain the problem if changes or
debugging were necessary.


> I don't see that an arithmetic IF would be any more problematic than a
> logical IF.

A logical IF allows multiple tests and does not require math tricks to
reduce a test to neg, zero, or pos. It's easier to understand.

> Everyone rags on GOTOs, too, but there are places where they're the most
> appropriate solution.  Assigned GOTOs are the most efficient way to
> solve a number of problems.  Take the case of a program that has a
> number of options.  You can have a switch that you test each time thru
> the loop to see if a particular option is active, or you can have
> assigned GOTOs that are set once in initialization and incurs no
> additional overhead to test and branch later.  If you need debugging,
> have a text field in addition to the assigned GOTO that says what the
> setting is without costing much in extra instructions.

Assigned GO TOs are notoriously hard to debug.

Even plain GO TOs are disliked by almost everyone. I'm one of the
very few who think they're okay to use in certain limited
circumstances--I'd rather see a GOTO to get out of a complex nexted IF
situation than multiple layers of ELSEs. However, the go to should be
only to the end of the paragraph.


>
> For the record I usually try to program as straightforwardly as
> possible, and if I do something exotic I usually decorate it with lots
> of comments, but it's nice to know you can do the exotic stuff when

> necessary.-

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:32:31 PM1/3/11
to
On Dec 30 2010, 9:15 am, jmfbahciv <See.ab...@aol.com> wrote:

> I'm assuming that the OP wants to know the outcome of the existing
> code, not an unknown output of a rewrite using a different FORLIB
> library.

Why would the FORLIB make a difference in output using the same
statements?

If something is that 'dependent' then one would probably need the same
kind of machine architecture.

hanc...@bbs.cpcn.com

unread,
Jan 3, 2011, 10:35:45 PM1/3/11
to
On Jan 2, 1:38 pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> In article <proto-358D87.10053902012...@news.panix.com>, pr...@panix.com
>
> (Walter Bushell) writes:
> > In article <495.50T1504T13885...@kltpzyxm.invalid>,

> > "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
> >> In article
> >> <c883c421-322d-4d98-bd92-cc22bb84a...@w2g2000yqb.googlegroups.com>,

> >> jsav...@ecn.ab.ca (Quadibloc) writes:
>
> >>> It is definitely true that FORTRAN was a widely-used language.
>
> >> Stan Kelly-Bootle described it as "transportable as syphilis".
>
> > Whereas C and C++ are more like AIDS.
>
> :-)  At this point I usually switch to the automotive analogies
> that were making the rounds a while ago.  Here's an excerpt:
>
> Assembler: a Formula 1 race car.  Very fast, but difficult to
> drive and expensive to maintain.
>
> Fortran II: a model T Ford.  Once it was king of the road.
>
> Fortran IV: a model A Ford.
>
> Fortran 77: a six-cylinder Ford Fairlane with standard
> transmission and no seat belts.
>
> C: a black Firebird - the all-macho car.  Comes with
> optional fuzzbuster (escape to assembler).

What was COBOL--a Buick Roadmaster? Your father's Oldsmobile?

Anne & Lynn Wheeler

unread,
Jan 3, 2011, 11:13:31 PM1/3/11
to
hanc...@bbs.cpcn.com writes:
> What was COBOL--a Buick Roadmaster? Your father's Oldsmobile?

re:
http://www.garlic.com/~lynn/2011.html#7 Looking for a real Fortran-66 compatible PC compiler (CP/M or DOSor Windows

step up from rpg?? which was step up from plug-board

pierce arrow?
http://en.wikipedia.org/wiki/Pierce-Arrow
pierce arrow did some number of trucks
http://www.pierce-arrow.org/history/hist7.php

white motor truck?
http://en.wikipedia.org/wiki/White_Motor_Company

mack truck?
http://www.macktrucks.com/default.aspx?pageid=40

international harvester?
http://en.wikipedia.org/wiki/International_Harvester
did some trucks
http://en.wikipedia.org/wiki/List_of_International_Harvester_vehicles
100 yrs of IH trucks
http://ihtrucks100.ning.com/

i learned to drive @eight on '38 flatbed chevy ... old picture
http://www.garlic.com/~lynn/38yellow.jpg

Quadibloc

unread,
Jan 3, 2011, 11:25:57 PM1/3/11
to
On Jan 3, 8:25 pm, hanco...@bbs.cpcn.com wrote:

> People who did some serious number crunching on old machines told me
> the machines, even an 1130, were quite powerful and could do an awful
> lot of work.

That's true enough. A modern-day Pentium, in theory, ought to be more
powerful than an IBM 360/195.

In practice, though, it's likely to have one hard disk. This means
that copying data from one file to another proceeds at mechanical
speeds, as the head moves back and forth between the two files. Memory
buffering reduces how often this has to happen, but copying a file to
a partition on a different hard drive is still noticeably faster - and
safer.

And while OS/360 was criticized in its day as a resource-wasting CPU
hog, it has nothing on Windows in that department. But then, it didn't
have to provide any users with a GUI.

The CPU on your desk could do an awful lot of work too, with the right
operating system and the right application software. It's a shame how
much power is going to waste, but then, how many of us need to do CFD
in our daily lives, as opposed to surfing the web and sending E-mail?

John Savard

Ben Pfaff

unread,
Jan 4, 2011, 12:55:56 AM1/4/11
to
Quadibloc <jsa...@ecn.ab.ca> writes:

> That's true enough. A modern-day Pentium, in theory, ought to be more
> powerful than an IBM 360/195.
>
> In practice, though, it's likely to have one hard disk. This means
> that copying data from one file to another proceeds at mechanical
> speeds, as the head moves back and forth between the two files. Memory
> buffering reduces how often this has to happen, but copying a file to
> a partition on a different hard drive is still noticeably faster - and
> safer.

If I'm reading the Wikipedia article on the IBM System 360
correctly, though, a 360/195 had only in the hundreds of
megabytes of storage, at most. That's so little that a
modern-day computer could keep it all in main memory.
--
Ben Pfaff
http://benpfaff.org

Message has been deleted

John Levine

unread,
Jan 4, 2011, 2:22:35 AM1/4/11
to
>> That's true enough. A modern-day Pentium, in theory, ought to be more
>> powerful than an IBM 360/195.
>>
>> In practice, though, it's likely to have one hard disk. This means
>> that copying data from one file to another proceeds at mechanical
>> speeds, as the head moves back and forth between the two files. Memory
>> buffering reduces how often this has to happen, but copying a file to
>> a partition on a different hard drive is still noticeably faster - and
>> safer.

I never used a /195 but I did use Princeton's /91. It had 2MB of core
(no virtual memory, so jobs that used a lot of it only ran late at night)
and as I recall two banks of 2314 disks, which would be a total of 320MB
of disks online at once. They had tape drives and large libraries
of tapes and disks that the operators mounted as needed. The cycle time
was 60ns, i.e. 17MHz.

These days a $200 netbook has more RAM than the /91 had total online
storage, and runs a lot faster, too. No tapes, though.

R's,
John


Dave Wade

unread,
Jan 4, 2011, 2:57:16 AM1/4/11
to
"Quadibloc" <jsa...@ecn.ab.ca> wrote in message
news:676b3c2e-c80d-4d12...@t8g2000prh.googlegroups.com...

> On Jan 3, 8:25 pm, hanco...@bbs.cpcn.com wrote:
>
>> People who did some serious number crunching on old machines told me
>> the machines, even an 1130, were quite powerful and could do an awful
>> lot of work.
>
> That's true enough. A modern-day Pentium, in theory, ought to be more
> powerful than an IBM 360/195.
>
> In practice, though, it's likely to have one hard disk. This means
> that copying data from one file to another proceeds at mechanical
> speeds, as the head moves back and forth between the two files. Memory
> buffering reduces how often this has to happen, but copying a file to
> a partition on a different hard drive is still noticeably faster - and
> safer.

Too many folks assume a different partition on the same drive or raid array
makes a difference....
... but the hard drives on a modern PC are still several times faster than
those you got on a 360/195

Dave Wade

unread,
Jan 4, 2011, 2:59:02 AM1/4/11
to
"John Levine" <jo...@iecc.com> wrote in message
news:ifuhrr$1o0f$2...@gal.iecc.com...

You can get USB to SCSI if you really need tapes.

>
> R's,
> John
>
>

Peter Flass

unread,
Jan 4, 2011, 8:12:49 AM1/4/11
to

A big horse-cart load of manure;-)

[Actually, I enjoyed coding in COBOL back in the day.]

Peter Flass

unread,
Jan 4, 2011, 8:16:42 AM1/4/11
to
On 1/3/2011 11:25 PM, Quadibloc wrote:
>
> The CPU on your desk could do an awful lot of work too, with the right
> operating system and the right application software. It's a shame how
> much power is going to waste, but then, how many of us need to do CFD
> in our daily lives, as opposed to surfing the web and sending E-mail?
>

You got it. 90% of PC usage is probably as a "net appliance" or as
storage for things like photos, Christmas Lists, etc. I'd say that's a
lot of my usage too, though I do occasional programming;-)

Peter Flass

unread,
Jan 4, 2011, 8:22:15 AM1/4/11
to
On 1/4/2011 12:55 AM, Ben Pfaff wrote:
>
> If I'm reading the Wikipedia article on the IBM System 360
> correctly, though, a 360/195 had only in the hundreds of
> megabytes of storage, at most. That's so little that a
> modern-day computer could keep it all in main memory.

I don't remember megabytes at all from that era, although I'm sure large
users maxed out their machines. Core used a lot of power and generated
a lot of heat. You didn't get much in a frame, and there were limits on
how many frames could be strung together due to delays in propagation of
signals. That's why stuff like LCS was introduced, providing lots of
slower memory.


jmfbahciv

unread,
Jan 4, 2011, 8:32:18 AM1/4/11
to

Model T truck.

/BAH

jmfbahciv

unread,
Jan 4, 2011, 8:32:26 AM1/4/11
to
hanc...@bbs.cpcn.com wrote:
> On Dec 30 2010, 8:04 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>
>> > Some of this code has "exploding call flow", using computed gotos
>> > and arithmetic ifs to their full potential, using state variables,
>> > often several; where each statement may have many next hops all
>> > depending on this state. Add assigned gotos (aka "comefrom") and
>> > you must rewrite, not port.
>>
>> I'm amazed they'd get rid of this.  Like it or not, this stuff was
>> widely used and still would seem to have a place.
>
> Computed GO TOs, like the ALTER statement in COBOL, were very
> difficult for other people to maintain the problem if changes or
> debugging were necessary.
>
>
>> I don't see that an arithmetic IF would be any more problematic than a
>> logical IF.
>
> A logical IF allows multiple tests and does not require math tricks to
> reduce a test to neg, zero, or pos. It's easier to understand.

No, it's not easier to understand.

>
>
>
>> Everyone rags on GOTOs, too, but there are places where they're the most
>> appropriate solution.  Assigned GOTOs are the most efficient way to
>> solve a number of problems.  Take the case of a program that has a
>> number of options.  You can have a switch that you test each time thru
>> the loop to see if a particular option is active, or you can have
>> assigned GOTOs that are set once in initialization and incurs no
>> additional overhead to test and branch later.  If you need debugging,
>> have a text field in addition to the assigned GOTO that says what the
>> setting is without costing much in extra instructions.
>
> Assigned GO TOs are notoriously hard to debug.
>
> Even plain GO TOs are disliked by almost everyone.

this is completely bullshit. GOTOless code was a fade promoted by
a harebrained professor who didn't do production work nor understood
production work.

> I'm one of the
> very few who think they're okay to use in certain limited
> circumstances--I'd rather see a GOTO to get out of a complex nexted IF
> situation than multiple layers of ELSEs. However, the go to should be
> only to the end of the paragraph.

You haven't done much OS development, have you? Dealing with interrupts
or catastrophic failures cannot "wait" until the end of the paragraph
to branch. Errors returns from system calls were not at the end of
paragraphs.

<snip>

/BAH

Ahem A Rivet's Shot

unread,
Jan 4, 2011, 8:30:55 AM1/4/11
to

That'd be Java and associated class libraries.

jmfbahciv

unread,
Jan 4, 2011, 8:51:12 AM1/4/11
to

Note quite specific enough. Horse-cart loaded with manure which contains
100 weed seeds/cc.

/BAH

>

jmfbahciv

unread,
Jan 4, 2011, 8:57:54 AM1/4/11
to

COBOL was extremely useful for doing decimal arithmetic,
especially money-based arithmetic and report writing
while inputting raw data which had to be sorted every
which way but loose. FORTRAN couldn't do that kind of
work and machine lanugage would have been horrid.

/BAH

Ahem A Rivet's Shot

unread,
Jan 4, 2011, 9:20:06 AM1/4/11
to
On 4 Jan 2011 13:32:26 GMT
jmfbahciv <See....@aol.com> wrote:

> hanc...@bbs.cpcn.com wrote:

> > Assigned GO TOs are notoriously hard to debug.
> >
> > Even plain GO TOs are disliked by almost everyone.
>
> this is completely bullshit. GOTOless code was a fade promoted by
> a harebrained professor who didn't do production work nor understood
> production work.

Nope it's true very little modern code contains GOTOs, it does
contain continues, breaks and try/catch/finally constructs instead which
are in effect hidden GOTOs but easier to read because you can tell where
the target is.

> > I'm one of the
> > very few who think they're okay to use in certain limited
> > circumstances--I'd rather see a GOTO to get out of a complex nexted IF
> > situation than multiple layers of ELSEs. However, the go to should be
> > only to the end of the paragraph.
>
> You haven't done much OS development, have you? Dealing with interrupts
> or catastrophic failures cannot "wait" until the end of the paragraph
> to branch. Errors returns from system calls were not at the end of
> paragraphs.

I think you misread that - I read it as the GOTO could be anywhere
but the destination should be at the end of the paragraph which is not
unreasonable.

Scott Lurndal

unread,
Jan 4, 2011, 11:09:25 AM1/4/11
to
jmfbahciv <See....@aol.com> writes:
>hanc...@bbs.cpcn.com wrote:
>> On Dec 30 2010, 8:04 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>>
>>> > Some of this code has "exploding call flow", using computed gotos
>>> > and arithmetic ifs to their full potential, using state variables,
>>> > often several; where each statement may have many next hops all
>>> > depending on this state. Add assigned gotos (aka "comefrom") and
>>> > you must rewrite, not port.
>>>
>>> I'm amazed they'd get rid of this.  Like it or not, this stuff was
>>> widely used and still would seem to have a place.
>>
>> Computed GO TOs, like the ALTER statement in COBOL, were very
>> difficult for other people to maintain the problem if changes or
>> debugging were necessary.
>>
>>
>>> I don't see that an arithmetic IF would be any more problematic than a
>>> logical IF.
>>
>> A logical IF allows multiple tests and does not require math tricks to
>> reduce a test to neg, zero, or pos. It's easier to understand.
>
>No, it's not easier to understand.

Of course it is.

>>> Everyone rags on GOTOs, too, but there are places where they're the most
>>> appropriate solution.  Assigned GOTOs are the most efficient way to
>>> solve a number of problems.  Take the case of a program that has a
>>> number of options.  You can have a switch that you test each time thru
>>> the loop to see if a particular option is active, or you can have
>>> assigned GOTOs that are set once in initialization and incurs no
>>> additional overhead to test and branch later.  If you need debugging,
>>> have a text field in addition to the assigned GOTO that says what the
>>> setting is without costing much in extra instructions.
>>
>> Assigned GO TOs are notoriously hard to debug.
>>
>> Even plain GO TOs are disliked by almost everyone.
>
>this is completely bullshit. GOTOless code was a fade promoted by
>a harebrained professor who didn't do production work nor understood
>production work.

Funny, then, how all modern code, for the last two decades has been
written and maintained without the use of an explicit "goto" construct.

>
>> I'm one of the
>> very few who think they're okay to use in certain limited
>> circumstances--I'd rather see a GOTO to get out of a complex nexted IF
>> situation than multiple layers of ELSEs. However, the go to should be
>> only to the end of the paragraph.
>
>You haven't done much OS development, have you? Dealing with interrupts
>or catastrophic failures cannot "wait" until the end of the paragraph
>to branch. Errors returns from system calls were not at the end of
>paragraphs.

An interrupt is _not_ a goto in the programatic sense. Error returns
from system calls are of course checked with an IF statemenet following
the system call. I don't see where a goto, explicitly added by the
programmer, is required to handle either case; any more than the
programmer must use a goto language construct to handle an asynchronous
event such as a signal (unix), AST (VMS) or ARM (MCP/VS).

There have been many operating systems written in higher level languages
(Sprite/SPRASM, C, C++ et. al.) which were written without the use
of goto.

Even linux only uses goto's in very prescribed circumstances (for early
function exits w/cleanup), and there sparingly.

I've done OS development since 1979 for mainframes(B), large scale SMP unix (SGI)
systems, large scale linux (ccNUMA, 256core) systems and hypervisors; with the
exception of assembler code, I very seldom used an explicit goto, perhaps
less than 10 times in 30+ years.

scott

Peter Grange

unread,
Jan 4, 2011, 12:03:10 PM1/4/11
to
On Mon, 3 Jan 2011 23:50:10 -0000, "Dave Wade" <dave....@gmail.com>
wrote:

Don't think I ever went to Refuge or NERC. Went to Littlewoods in the
days of 516s and again when they had a 66, AB foods a couple of times.
HSE in Sheffield had a CP6 system, as did Robert Gordons & Aberdeen
Uni in Aberdeen so went to those places quite a few times. We did a
Colour Books implementation for Aberdeen Uni on CP6 but by that time
Honeywell had sold out to the French, whose heart wasn't really into
buying business off the academic community, so I slid out of
poprietary systems & into Unix networking on the back of the IRON
(Inland Revenue Office of the Nineties) project.

As you said it was fun in those days, access to everything. We had all
the assembler listings for GCOS3 printed & hung in a big rack in the
office at Acton Data Centre in the 70s. Happy days!

Anne & Lynn Wheeler

unread,
Jan 4, 2011, 2:12:08 PM1/4/11
to
John Levine <jo...@iecc.com> writes:
> I never used a /195 but I did use Princeton's /91. It had 2MB of core
> (no virtual memory, so jobs that used a lot of it only ran late at night)
> and as I recall two banks of 2314 disks, which would be a total of 320MB
> of disks online at once. They had tape drives and large libraries
> of tapes and disks that the operators mounted as needed. The cycle time
> was 60ns, i.e. 17MHz.
>
> These days a $200 netbook has more RAM than the /91 had total online
> storage, and runs a lot faster, too. No tapes, though.

the 370/195 at SJR ran MVT batch ... and some stuff could have 3 month
turn-around. the 195 had 64 entry pipeline and peak thruput of 10mips
... but didn't have branch prediction and/or speculative execution ...
so typical branch would drain the pipeline ... and unless carefully
crafted for the pipeline ... most codes ran more like 5mips. 370/195
never did get virtual memory ... it was just the initial 370
announcement (w/o virtual memory) with a few new instructions ... and
some better hardware RAS.

palo alto science center (further up silicon valley) did some tweaks for
running batch under cms with checkpoint/restart ... and would run
application on their vm370/cms 145 in "background" ... mostly getting
its cpu cycles offshift and weekends. The 145 was about 1/30th the 195
... but they found they could get turn-around in a month on the 145,
that was taking 3 months on sjr's 195.

I mentioned that they let me play disk engineer across the street in
bldg 14&15. One of the things was that the labs over there had been
running dedicated, stand-alone (around the clock, 7x24) scheduled
machine for disk test & development. They had once tried MVS for
supporting multiple concurrent testing ... but found it had 15min MTBF
in that environment. I undertook to rewrite I/O supervisor so that it
would never fail or hang ... so they could do multiple, concurrent,
on-demand testing (greatly increasing their productivity). misc.
past posts getting to play disk engineer
http://www.garlic.com/~lynn/sutopic.html#disk

now, the disk labs tended to get #3 or #4 engineering processor ... as
soon as processor engineers had one to spare ... for disk testing
(i.e. not only did they test new disks with existing processors ... but
also did all sorts of disk testing with new processors).

bldg. 15 got engineering 3033 #3(?) ... which was approx. 4.5MIP
processor. now it turned out that disk testing ... even multiple
concurrent testing ... was very low cpu utilization ... possibly only a
percent or two ... leaving lots of compute power on the engineering
machines for doing other stuff.

now one of the relatively high priority jobs on SJR 195 was air-bearing
simulation ... part of designing new disk generation ("floating") heads
... but it was still getting something like a couple week turn around
(for hr or two of cpu, simulation run). so one of the things setup ...
was to get air-bearing simulation running on the 3033 in bldg. 15 ...
which would result in being able to get several turn-arounds a day.

misc. past posts mentioning air-bearing simulation:
http://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2002n.html#63 Help me find pics of a UNIVAC please
http://www.garlic.com/~lynn/2002o.html#74 They Got Mail: Not-So-Fond Farewells
http://www.garlic.com/~lynn/2003b.html#51 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2003j.html#69 Multics Concepts For the Contemporary Computing World
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
http://www.garlic.com/~lynn/2004b.html#15 harddisk in space
http://www.garlic.com/~lynn/2004o.html#15 360 longevity, was RISCs too close to hardware?
http://www.garlic.com/~lynn/2004o.html#25 CKD Disks?
http://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#5 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
http://www.garlic.com/~lynn/2006.html#29 IBM microwave application--early data communications
http://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#13 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006d.html#14 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006l.html#6 Google Architecture
http://www.garlic.com/~lynn/2006l.html#18 virtual memory
http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
http://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006u.html#18 Why so little parallelism?
http://www.garlic.com/~lynn/2006x.html#27 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2006x.html#31 The Future of CPUs: What's After Multi-Core?
http://www.garlic.com/~lynn/2007e.html#43 FBA rant
http://www.garlic.com/~lynn/2007e.html#44 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#83 Disc Drives
http://www.garlic.com/~lynn/2007j.html#13 Interrupts
http://www.garlic.com/~lynn/2007j.html#64 Disc Drives
http://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
http://www.garlic.com/~lynn/2008k.html#77 Disk drive improvements
http://www.garlic.com/~lynn/2008l.html#60 recent mentions of 40+ yr old technology
http://www.garlic.com/~lynn/2009c.html#9 Assembler Question
http://www.garlic.com/~lynn/2009k.html#49 A Complete History Of Mainframe Computing
http://www.garlic.com/~lynn/2009k.html#75 Disksize history question
http://www.garlic.com/~lynn/2009r.html#51 "Portable" data centers

Anne & Lynn Wheeler

unread,
Jan 4, 2011, 2:40:06 PM1/4/11
to

another 370/195 story is eastern airlines ran its res system (ACP)
System/One on 370/195. one of the "nails" in the Future System "coffin"
... a couple recent posts in (linkedin) IBM Historic Computing thread:
http://www.garlic.com/~lynn/2010q.html#32 IBM Future System
http://www.garlic.com/~lynn/2010q.html#64 IBM Future System
http://www.garlic.com/~lynn/2011.html#14 IBM Future System

was that if System/One was put on Future System implemented in fasting
existing technology (aka 370/195), it would have the thruput of 370/145
(aka about 30 times reduction in thruput, FS had a lot of hardware
peformance overhead). misc. past posts mentioning Future System
http://www.garlic.com/~lynn/submain.html#futuresys

Much later System/One was being used as the basis for (european res
system) "Amadeus" ... and my wife served short stint as chief architect.
She sided with the europeans for use of x.25 as accesss (against SNA)
... which resulted in the SNA forces getting her removed (it didn't
do them much good since Amadeus went with x.25 anyway. misc. past
posts mentioning Amadeus
http://www.garlic.com/~lynn/2001g.html#49 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2003n.html#47 What makes a mainframe a mainframe?
http://www.garlic.com/~lynn/2004b.html#6 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2004b.html#7 Mainframe not a good architecture for interactive workloads
http://www.garlic.com/~lynn/2005p.html#8 EBCDIC to 6-bit and back
http://www.garlic.com/~lynn/2007e.html#52 US Air computers delay psgrs
http://www.garlic.com/~lynn/2007h.html#12 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2008c.html#53 Migration from Mainframe to othre platforms - the othe bell?
http://www.garlic.com/~lynn/2008i.html#19 American Airlines
http://www.garlic.com/~lynn/2008i.html#34 American Airlines
http://www.garlic.com/~lynn/2008p.html#41 Automation is still not accepted to streamline the business processes... why organizations are not accepting newer technologies?
http://www.garlic.com/~lynn/2009j.html#33 IBM touts encryption innovation
http://www.garlic.com/~lynn/2009l.html#55 IBM halves mainframe Linux engine prices
http://www.garlic.com/~lynn/2009r.html#59 "Portable" data centers

Dave Wade

unread,
Jan 4, 2011, 2:40:17 PM1/4/11
to
"Peter Grange" <pe...@plgrange.demon.co.uk> wrote in message
news:bjj6i61amgu7tsums...@4ax.com...

I avoided Littlewoods like the plague. I knew the guys at AB Foods pretty
well...

> HSE in Sheffield had a CP6 system, as did Robert Gordons & Aberdeen
> Uni in Aberdeen so went to those places quite a few times.

I knew the guys at Aberdeen quite well as well, but the guy there's name
escapes me...

> We did a
> Colour Books implementation for Aberdeen Uni on CP6 but by that time
> Honeywell had sold out to the French, whose heart wasn't really into
> buying business off the academic community, so I slid out of
> poprietary systems & into Unix networking on the back of the IRON
> (Inland Revenue Office of the Nineties) project.
>

I implemented the Aberdeen Blue Book and Grey Book at NERC on GCOS 3 but it
was really slow. Not sure why, I think it was the PDP/11 front end, but I
never really understood how that code worked. It was written in "B"...

> As you said it was fun in those days, access to everything. We had all
> the assembler listings for GCOS3 printed & hung in a big rack in the
> office at Acton Data Centre in the 70s. Happy days!

Its funny how code lives on. I remember my wife (how worked in another
department at Refuge) askiing what the costing figures meant on a job, and
as I had written the .MBORT7 (is that right) user exit many years ago, I
actually knew...

Pity there is no emulator for L66 and the software is still proprietory....

Ahem A Rivet's Shot

unread,
Jan 4, 2011, 2:49:54 PM1/4/11
to
On Tue, 04 Jan 2011 17:03:10 +0000
Peter Grange <pe...@plgrange.demon.co.uk> wrote:

> so I slid out of
> poprietary systems & into Unix networking on the back of the IRON
> (Inland Revenue Office of the Nineties) project.

<Wave> from an old TOBBI project member.

Message has been deleted

Rich Alderson

unread,
Jan 4, 2011, 7:33:52 PM1/4/11
to
jmfbahciv <See....@aol.com> writes:

> COBOL was extremely useful for doing decimal arithmetic,
> especially money-based arithmetic and report writing
> while inputting raw data which had to be sorted every
> which way but loose. FORTRAN couldn't do that kind of
> work and machine lanugage would have been horrid.

Of course FORTRAN could do that kind of work, COBOL simply did it better (or
perhaps "did it better simply").

--
Rich Alderson ne...@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...

Andrew Swallow

unread,
Jan 4, 2011, 9:41:20 PM1/4/11
to
On 04/01/2011 03:35, hanc...@bbs.cpcn.com wrote:
{snip}

>
> What was COBOL--a Buick Roadmaster? Your father's Oldsmobile?

COBOL was a Transit van.

Andrew Swallow

Peter Grange

unread,
Jan 5, 2011, 5:10:52 AM1/5/11
to
On Tue, 4 Jan 2011 19:40:17 -0000, "Dave Wade" <dave....@gmail.com>
wrote:

Littlewoods was an experience. I did some testing/development there on
some startup resilience stuff we did for GCOS3. Probably the biggest
system we had in the UK.


>
>> HSE in Sheffield had a CP6 system, as did Robert Gordons & Aberdeen
>> Uni in Aberdeen so went to those places quite a few times.
>
>I knew the guys at Aberdeen quite well as well, but the guy there's name
>escapes me...

I can see the faces still, but the names have gone. Old age, 65
tomorrow!


>
>> We did a
>> Colour Books implementation for Aberdeen Uni on CP6 but by that time
>> Honeywell had sold out to the French, whose heart wasn't really into
>> buying business off the academic community, so I slid out of
>> poprietary systems & into Unix networking on the back of the IRON
>> (Inland Revenue Office of the Nineties) project.
>>
>
>I implemented the Aberdeen Blue Book and Grey Book at NERC on GCOS 3 but it
>was really slow. Not sure why, I think it was the PDP/11 front end, but I
>never really understood how that code worked. It was written in "B"...

What we did was mainly based on the Multics implementation. CP6 was
largely written in PL6, which was developed by Honeywell for writing
operating systems. Some of GCOS8 was done in it too. So. we used PL6
for the Colour Book stuff. One of the lighter memories was one of the
Los Angeles managers having a stab at spelling "Colour" and coming up
with "Coulor". Nice try but no cigar ;=)

>
>> As you said it was fun in those days, access to everything. We had all
>> the assembler listings for GCOS3 printed & hung in a big rack in the
>> office at Acton Data Centre in the 70s. Happy days!
>
>Its funny how code lives on. I remember my wife (how worked in another
>department at Refuge) askiing what the costing figures meant on a job, and
>as I had written the .MBORT7 (is that right) user exit many years ago, I
>actually knew...

If memory serves, .MBRT7 I think, but that's based more on everything
fitting into 6 BCD characters, ie one word, rather than positive
memories :-(


>
>Pity there is no emulator for L66 and the software is still proprietory....

There's hope yet, they put the Multics code in the public domain...

Peter Grange

unread,
Jan 5, 2011, 5:32:41 AM1/5/11
to
On Tue, 4 Jan 2011 19:49:54 +0000, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

>On Tue, 04 Jan 2011 17:03:10 +0000
>Peter Grange <pe...@plgrange.demon.co.uk> wrote:
>
>> so I slid out of
>> poprietary systems & into Unix networking on the back of the IRON
>> (Inland Revenue Office of the Nineties) project.
>
> <Wave> from an old TOBBI project member.

<Wave back>
Never did anything with TOBBI. My involvement with IRON was support of
the unix/PC platform. Don't think I ever spoke to any IR person
directly.

Tim Shoppa

unread,
Jan 5, 2011, 7:43:04 AM1/5/11
to
On Jan 3, 11:25 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Jan 3, 8:25 pm, hanco...@bbs.cpcn.com wrote:
>
> > People who did some serious number crunching on old machines told me
> > the machines, even an 1130, were quite powerful and could do an awful
> > lot of work.

>
> That's true enough. A modern-day Pentium, in theory, ought to be more
> powerful than an IBM 360/195.

Well, a 360/195 was quite nice at well over an honest MIPS in the
early 70's, but... by the late 80's scientific workstations with that
sort of speed were the norm. (Doesn't mean that departmental computers
didn't live on as well.)

My personal standard for a kick-ass number-crunching machine for a
long time was the Y/MP which could reach a gigaflop on vectorizable
code. When I got time on the Delta and Paragon I mentally translated
it into Y/MP perfromance equivalents. For the past decade gigaflop+
performance turned from the high end of PC's to below the low end of
PC's, and today PC's getting ten times that performance are regarded
as not-particularly-powerful and available at the mall. And some
teenage enthusiasts (e.g. Setiathome participants) have honest
teraflop range aggregations of PC's in their bedrooms.

Tim.

Charlie Gibbs

unread,
Jan 5, 2011, 3:10:10 PM1/5/11
to
In article
<1b969dd8-89ed-4aa0...@f8g2000yqd.googlegroups.com>,
hanc...@bbs.cpcn.com (hancock4) writes:

> On Jan 2, 1:38�pm, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> In article <proto-358D87.10053902012...@news.panix.com>,


>> pr...@panix.com
>>
>> (Walter Bushell) writes:
>>
>>> In article <495.50T1504T13885...@kltpzyxm.invalid>,

>>> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>>>
>>>> In article

>>>> <c883c421-322d-4d98-bd92-cc22bb84a...@w2g2000yqb.googlegroups.com>,
>>>> jsav...@ecn.ab.ca (Quadibloc) writes:
>>>>
>>>>> It is definitely true that FORTRAN was a widely-used language.
>>>>
>>>> Stan Kelly-Bootle described it as "transportable as syphilis".
>>>
>>> Whereas C and C++ are more like AIDS.
>>
>> :-) �At this point I usually switch to the automotive analogies
>> that were making the rounds a while ago. �Here's an excerpt:
>>
>> Assembler: a Formula 1 race car. �Very fast, but difficult to
>> drive and expensive to maintain.
>>
>> Fortran II: a model T Ford. �Once it was king of the road.
>>
>> Fortran IV: a model A Ford.
>>
>> Fortran 77: a six-cylinder Ford Fairlane with standard
>> transmission and no seat belts.
>>
>> C: a black Firebird - the all-macho car. �Comes with
>> optional fuzzbuster (escape to assembler).
>

> What was COBOL--a Buick Roadmaster?

A delivery van. Bulky and ugly, but it does the work.

> Your father's Oldsmobile?

No, that was more like BASIC: a second-hand Rambler with a
rebuilt engine and patched upholstery. Your dad bought it
for you to learn to drive. You'll ditch the car as soon as
you can afford a new one.

OK, here are the rest:

PL/I: A Cadillac convertible with automatic transmission,
two-tone paint, white-wall tires, chrome exhaust pipes,
and fuzzy dice hanging in the windshield.

PL/M: A Yugo with a voided warranty.

Algol 60: An Austin Mini. Boy, that's a small car!

Pascal: A Volkswagen beetle. It's small but sturdy.
Was once popular with intellectuals.

Modula-2: A Volkswagen Rabbit with a trailer hitch.

Algol 68: An Aston Martin. Impressive, but not just anyone
can drive it.

LISP: An electric car. Simple, but slow. No seat belts.

Prolog/Lucid: Prototype exotic concept cars.

Maple/Macsyma: All-terrain vehicles.

Forth: A go-cart.

Logo: A kiddie's replica of a Rolls-Royce.
Comes with a real engine and a working horn.

APL: A double-decker bus. It takes rows and columns of
passengers to the same place all at the same time, but
it only runs in reverse and the instruments are in Greek.

Ada: An army-green Mercedes-Benz staff car. Power steering,
power brakes, and automatic transmission are all standard.
No other colors or options are available. If it's good enough
for the generals, it's good enough for you. Manufacturing delays
due to difficulties reading the design specifications are starting
to clear up.

http://www.elsop.com/wrc/humor/sel_lang.htm

--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Dave Wade

unread,
Jan 5, 2011, 3:27:19 PM1/5/11
to

"Rich Alderson" <ne...@alderson.users.panix.com> wrote in message
news:mdd4o9o...@panix5.panix.com...


> jmfbahciv <See....@aol.com> writes:
>
>> COBOL was extremely useful for doing decimal arithmetic,
>> especially money-based arithmetic and report writing
>> while inputting raw data which had to be sorted every
>> which way but loose. FORTRAN couldn't do that kind of
>> work and machine lanugage would have been horrid.
>
> Of course FORTRAN could do that kind of work, COBOL simply did it better
> (or
> perhaps "did it better simply").

Whilst Fortran can do it, it rather tedious, especially if you need to check
for over flow, or if you need more precision than a standard integer. Many
programs I wrote when I worked for an Insurance company would have needed
multiple integers to cope. Doing this on Fortran 66 would be tedious. I do
note that some "C" compilers and libraries have support for decimal and
packed decimal types...

Patrick Scheible

unread,
Jan 5, 2011, 4:33:17 PM1/5/11
to
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> writes:

> No, that was more like BASIC: a second-hand Rambler with a
> rebuilt engine and patched upholstery. Your dad bought it
> for you to learn to drive. You'll ditch the car as soon as
> you can afford a new one.
>
> OK, here are the rest:

Icon: Mercedes S class. Big, comfortable, sophisticated, spoils you
for ever wanting to use a different car.

-- Patrick

Stan Barr

unread,
Jan 6, 2011, 4:31:05 AM1/6/11
to

Forth: A pile of auto parts from which you can build your own car.

(I'd forgotten about Icon, I used to do stuff in it years ago - I've
just installed v9.4.3 on this Ubuntu box, thanks for reminding me.)

--
Cheers,
Stan Barr plan.b .at. dsl .dot. pipex .dot. com

The future was never like this!

It is loading more messages.
0 new messages