[TUHS] FORTRAN

[TUHS] FORTRAN

[Johnny Billquist]

On 2018-03-21 14:48, Paul Winalski<paul.winalski at gmail.com> wrote:
> 
> On 3/20/18, Clem Cole<clemc at ccc.com>  wrote:
>> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
>> originally - IIRC the one I used came from the universities.   I think the
>> first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
>> 'laboratory' systems and those systems were dominated by Fortran back in
>> the day - so DEC marketing thought in those terms.
>>
> DEC did do a Pascal for RSX.  I don't remember if it supported RT11 or
> RSTS.  DEC did a BASIC compiler for RSTS and RSX.  RSX and especially
> RT were designed mainly for real-time process control in laboratories.

DEC did both COBOL, DIBOL, PASCAL, FORTRAN (-IV, -IV-PLUS, -77), C as 
well as Datatrieve for RSX and RSTS/E. Some of these were also available 
for RT-11. Admittedly, the C compiler was very late to the game.

>     A lot of the programming was in assembler for efficiency reasons
> (both time and space).

Yes. And MACRO-11 is pretty nice.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

[TUHS] FORTRAN

[Charles Anthony]

On Wed, Mar 21, 2018 at 7:51 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: "Steve Johnson"
>
> So, I have this persistent memory that I read, in some early Multics
> (possibly
> CTSS, but ISTR it was Multics) document, a footnote explaining the origin
> of
> the term 'daemon'. I went looking for it, but couldn't find it in a 'quick'
> scan.
>

From multician.org: http://multicians.org/mgd.html:

" daemon

A beneficent spirit. A process, not associated with a human operator, that
runs all the time and waits for requests to do something for a user. This
term is respectable English; the application to computer processes is
usually credited to M. J. Bailey, working on the design of CTSS in the
early 60s.

[JHS] "I'm working from memory here, but I think this is the story.
Although the word 'process' wasn't in the vocabulary yet, we had just
figured out that what one would now call 'system processes' were a solution
to several problems, and we were looking for a good label for them. A
British gentleman named Michael (Mick) Bailey, working on the CTSS
programming staff at MIT, suggested the word 'daemon' and quoted the OED in
support of both the meaning and spelling. Bailey's etymology was so
impeccable that questions as to whether the spelling should be simplified
to 'demon' went on for only about 30 seconds. On both CTSS and Multics, the
documentation and the process names use the spelling 'daemon.' I suspect
that the date on the memo that first used the term would be in 1962 or
1963."(note to Kirk McKusick, 24 Aug 1988)"

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/0af1ebd2/attachment.html>

[TUHS] FORTRAN

[Dennis Boone]

 > >Yes, Fortran is as awful for system programming as C is for numeric
 > >programming that involves throwing multidimensional arrays around.

 > Note that Pr1meOS was written in Fortran.  I did study it but no
 > longer recall what extensions it had to make that practical.

It's just PRIMOS, no E.  And the '1' in place of 'i' thing was just a
marketing/logo gimmick.

Surprisingly few language extensions.  Octal constants (:1234567).  A
file inclusion facility ($INSERT FILE>PATH>XYZ.INS.FTN).  Not much else.

Originally, much of PRIMOS was in FORTRAN, with some assembler (PMA).
Later, significant rewrites and extensions were done in PL/1 derived
systems languages (PLP and SPL), and even later some in Modula.

Awfulness is relative.  Bill Poduska has said that writing most of the
system in a higher level language saved them a lot of time, over using
assembler.

De

[TUHS] FORTRAN

[Ron Natalie]

> Note that Pr1meOS was written in Fortran.  I did study it but no longer
recall what extensions it had to make that practical.

Prime was the company that tried to trademark English as the name of their
programming language, wasn't it?

[TUHS] FORTRAN

[Ron Natalie]

>    DEC did a BASIC compiler for RSTS and RSX

BasicPlus was about the only good thing about RSTS.    In fact, we were allowed to replace the RSTS with UNIX at JHU if we could get BASIC PLUS ported over.
Fortunately, RSTS used EMT instructions for system calls (bizarre if you read the PDP-11 Processor Handbook) where as UNIX used the expected TRAP instruction.   All we had to do was add a "nostack" system call (I think we put it in, it might have already been there) to disable UNIX's idea of how a stack should work.

[TUHS] FORTRAN

[Noel Chiappa]

    > From: "Steve Johnson"

So, I have this persistent memory that I read, in some early Multics (possibly
CTSS, but ISTR it was Multics) document, a footnote explaining the origin of
the term 'daemon'. I went looking for it, but couldn't find it in a 'quick'
scan.

I did find this, though, which is of some interest: R. A. Freiburghouse, "The
Multics PL/1 Compiler" (available online here:

  http://multicians.org/pl1-raf.html

if anyone is interested).

    > There was a group that was pushing the adoption of PL/1, being used to
    > code Multics, but the compiler was late and not very good and it never
    > really caught on.

So, in that I read:

  The entire compiler and the Multics operating system were written in EPL, a
  large subset of PL/1 ... The EPL compiler was built by a team headed by
  M. D. McIlroy and R. Morris ... Several members of the Multics PL/1 project
  modified the original EPL compiler to improve its object code performance,
  and utilized the knowledge acquired from this experience in the design of
  the Multics PL/1 compiler.

The EPL compiler was written when the _original_ PL/1 compiler (supposedly
being produced by a consulting company, Digitek) blew up. More detail is
available here:

  http://multicians.org/pl1.html

I assume it's the Digitek compiler you were thinking of above?

	Noel

[TUHS] FORTRAN

[Paul Winalski]

On 3/20/18, Clem Cole <clemc at ccc.com> wrote:
>
> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
> originally - IIRC the one I used came from the universities.   I think the
> first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
> 'laboratory' systems and those systems were dominated by Fortran back in
> the day - so DEC marketing thought in those terms.
>
DEC did do a Pascal for RSX.  I don't remember if it supported RT11 or
RSTS.  DEC did a BASIC compiler for RSTS and RSX.  RSX and especially
RT were designed mainly for real-time process control in laboratories.
   A lot of the programming was in assembler for efficiency reasons
(both time and space).

-Paul W.

[TUHS] FORTRAN

[Peter Jeremy]

On 2018-Mar-20 16:21:12 -0400, Paul Winalski <paul.winalski at gmail.com> wrote:
>Yes, Fortran is as awful for system programming as C is for numeric
>programming that involves throwing multidimensional arrays around.

Note that Pr1meOS was written in Fortran.  I did study it but no longer
recall what extensions it had to make that practical.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180321/05cf7c64/attachment.sig>

[TUHS] FORTRAN

[Bakul Shah]

On Mar 20, 2018, at 2:36 PM, Clem Cole <clemc at ccc.com> wrote:
> 
> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS originally - IIRC the one I used came from the universities.   I think the first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were 'laboratory' systems and those systems were dominated by Fortran back in the day - so DEC marketing thought in those terms.

True re TOPS-10.

The TOP-10 Pascal compiler was ported from the one for
CDC-6000 (authors: Urs Amman, Kesav Nori and may be others).
The CDC version was what was described in the Pascal User
Manual and Report by Jensen and Wirth. IIRC, someone at Purdue
was maintaining it. I knew it well as I had added formatted IO
for scalars, sets & a few more things that I forget now + I
was studying it with an aim to write my own compiler. I 
believe this was the port:

https://www.researchgate.net/publication/220846309_A_pascal_compiler_bootstrapped_on_a_DEC-System_10

[Even the portable "P4" Pascal compiler must've been derived
from the same original code as I recognize its code shape and
random stuff like variable names etc.  p4 sources are online
but I don't see the tops-10 ones]

[TUHS] FORTRAN

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]



> Paul can correct me, but I don't think DEC even developed a Pascal for TOPS originally - IIRC the one I used came from the universities.   I think the first Pascal sold was targeted for the VAX.  
We made heavy use of PASCAL on the TOPS10 system at JHU, but I don't know what the origin of it was.    I'd be surprised if it wasn't DEC.   That shop wasn't overly innovative. 
>>  but its character handling was awful.  
​> Yep - but as others have pointed out, with something like RATFOR it could be made usable and that's what a lot of people I know did when they had too.   As I said, the FPS folks wrote a parallelizing, Fortran for the FPS-164 in Ratfor A compiler, to me, is the definition if a character based application if I can name one.

Ratfor got you decent control structures but it didn't get around the fortran data model suckage.
 
 
ᐧ
ᐧ
ᐧ

[TUHS] FORTRAN

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

On Tue, Mar 20, 2018 at 3:55 PM, Ron Natalie <ron at ronnatalie.com> wrote:

> Having worked on system programming for UNIX and a few of the PDP-11 DEC
> OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> abhorrent.
>
> Sure it was the only high-level language I had on the RT and RSX systems,
>
​And that was the problem... DEC did not market good tools besides
assembler and FTN for RT and RSX.   3rd parties like Oregon SW and
Whitesmiths' eventually produced good Pascal and C implementation
respectfully.   But, like you, most people I knew, and in my own
experience; nothing but asm and FTN was there.

Paul can correct me, but I don't think DEC even developed a Pascal for TOPS
originally - IIRC the one I used came from the universities.   I think the
first Pascal sold was targeted for the VAX.  Also, RT11 and RSX were
'laboratory' systems and those systems were dominated by Fortran back in
the day - so DEC marketing thought in those terms.

I remember that CMU's Mellon Institute built an automated realtime
newspaper sorting/delivery system for the Pittsburgh Press and a number of
other newspapers and ended up using FORTRAN - because that's all they had
for RT11 that they trusted (thankfully that project started after I had
left, although I helped with the bidding and assessment). We had wanted to
use BLISS but that meant cross compiling from the 10's and the customer
wanted the system self hosting as I recall. By the time the Mellon folks
completed the project, OMSI's Pascal compiler for RT11 was available, but
the water was under the bridge.



> but its character handling was awful.
>
​Yep - but as others have pointed out, with something like RATFOR it could
be made usable and that's what a lot of people I know did when they had
too.   As I said, the FPS folks wrote a parallelizing, Fortran for the
FPS-164 in Ratfor A compiler, to me, is the definition if a character based
application if I can name one.




>   I ended up writing almost all that stuff in assembler
> ​ ​
> (which fortunately the PDP-11 is wonderful for).
>
> ​You and many others ;-)

Clem​
ᐧ
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/35237ea8/attachment.html>

[TUHS] FORTRAN

[Warner Losh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Tue, Mar 20, 2018 at 2:21 PM, Paul Winalski <paul.winalski at gmail.com>
wrote:

> On 3/20/18, Ron Natalie <ron at ronnatalie.com> wrote:
> > Having worked on system programming for UNIX and a few of the PDP-11 DEC
> > OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> > abhorrent.
> >
> Yes, Fortran is as awful for system programming as C is for numeric
> programming that involves throwing multidimensional arrays around.
> Screwdrivers always make bad hammers.
>

With care, and the right additional pseudo-primitives, you can do quite
interesting systems-programming-like things in Fortran. But they are
usually a variation on RATFOR and often involve more pain than would
otherwise have been needed, but it's possible. I once did some low-level
systems stuff in FORTRAN-66 that lived under a psuedo Fortran 77
pre-processor that had some CPP-like macro features....

And I will never, ever, do it again :). I might do Turbo-PASCAL again, but
no system's programming in Fortran.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/9d76599d/attachment.html>

[TUHS] FORTRAN

[Paul Winalski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On 3/20/18, Ron Natalie <ron at ronnatalie.com> wrote:
> Having worked on system programming for UNIX and a few of the PDP-11 DEC
> OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was
> abhorrent.
>
Yes, Fortran is as awful for system programming as C is for numeric
programming that involves throwing multidimensional arrays around.
Screwdrivers always make bad hammers.

-Paul W.

[TUHS] FORTRAN

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Having worked on system programming for UNIX and a few of the PDP-11 DEC OS’s (DOS, RT, RSX, and in passing RSTS), I can tell you Fortran was abhorrent.

Sure it was the only high-level language I had on the RT and RSX systems, but its character handling was awful.    I ended up writing almost all that stuff in assembler

(which fortunately the PDP-11 is wonderful for).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/e88c9b9a/attachment.html>

[TUHS] FORTRAN

[Dan Cross]

On Mon, Mar 19, 2018 at 12:58 PM, Steve Johnson <scj at yaccman.com> wrote:

> [...]
> So the point is, FORTRAN was dominant at Bell Labs for most of the time
> that C was being developed.  There was a group that was pushing the
> adoption of PL/1, being used to code Multics, but the compiler was late and
> not very good and it never really caught on.  The GE compiler was one of
> the three that I abstracted the machine independent code from for PCC (the
> other two were PDP-11 and IBM 360).
>
[...]
>

Thanks Steve.

Ok, so if we take a step back, could it be said that one of the reasons for
the initial scuttled attempt at Fortran as a Unix systems programming
language was that it was the local "language of record" at the time? I'm
curious how far the effort got...was it just the proverbial cat reading the
paper, "I should really do a Fortran dialect..." or was there actual code?
Did anything survive into the modern era?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180320/42cd3b35/attachment.html>

[TUHS] FORTRAN

[George Michaelson]

I have some sympathy with the compiler writers, because if you have
invested in passing compliance and test suites, to make code which NAG
will then be compiled through, somebody out there is going to use this
code to test the strain in a bridge (topical...) or something similar,
and when it fails under load because the loop terminated the way you
didn't expect, things are very ugly.

If you know your compiler is what you stand behind, it makes sense to
push for it to be the one adopted. The likelihood the linker causes
the problem feels lower.

Actually I think it was just not-invented-here, but I do have some sympathy.

-G

On Tue, Mar 20, 2018 at 5:42 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> Another bit of history of Fortran on UNIX:
>
> DEC initially offered f77 on Ultrix, its commercial UNIX release for
> the VAX.  When the decision to market Ultrix was made, our engineering
> group, which developed the compiler and software development tools
> suite for VAX/VMS, offered to port some of our products, including VAX
> Fortran, to Ultrix.  The Ultrix engineering group fought the proposal
> tooth and nail, and so we dropped the idea.
>
> f77 was never taken very seriously by the Fortran user community,
> whereas VAX Fortran was considered the gold standard for the language.
> There were repeated calls from potential Ultrix customers for DEC to
> make VAX Fortran available on that platform.  Eventually circa 1985
> there was a panic rush project to port VAX Fortran to Ultrix.  It was
> decided that, if we were to meet the short time-to-market goal,
> modifying the VAX Fortran code generator to emit zmagic object files
> was out of the question.  Instead, we would have it continue to
> produce VMS object files, and we would port the VMS linker to Ultrix
> and teach it to understand zmagic, stab-style debug information, and
> ar archives.  I led the team that produced the lk linker, which could
> take in either zmagic or VAX object files and produced a.out-style
> images.  lk didn't implement some of the esoteric features of ld, but
> it got the job done.  The Fortran RTL was shipped as VMS-style object
> files.
>
> One feature of VMS object files is that the name of the compiler that
> produced them is recorded.  The lk linker reported this in the link
> maps it produced.  VAX Fortran for Ultrix customers were rather
> surprised to see the variety of languages (BLISS, Pascal, BASIC,
> Fortran, assembler, etc.) that had been used to implement the Fortran
> RTL.
>
> -Paul W.

[TUHS] FORTRAN

[Paul Winalski]

Another bit of history of Fortran on UNIX:

DEC initially offered f77 on Ultrix, its commercial UNIX release for
the VAX.  When the decision to market Ultrix was made, our engineering
group, which developed the compiler and software development tools
suite for VAX/VMS, offered to port some of our products, including VAX
Fortran, to Ultrix.  The Ultrix engineering group fought the proposal
tooth and nail, and so we dropped the idea.

f77 was never taken very seriously by the Fortran user community,
whereas VAX Fortran was considered the gold standard for the language.
There were repeated calls from potential Ultrix customers for DEC to
make VAX Fortran available on that platform.  Eventually circa 1985
there was a panic rush project to port VAX Fortran to Ultrix.  It was
decided that, if we were to meet the short time-to-market goal,
modifying the VAX Fortran code generator to emit zmagic object files
was out of the question.  Instead, we would have it continue to
produce VMS object files, and we would port the VMS linker to Ultrix
and teach it to understand zmagic, stab-style debug information, and
ar archives.  I led the team that produced the lk linker, which could
take in either zmagic or VAX object files and produced a.out-style
images.  lk didn't implement some of the esoteric features of ld, but
it got the job done.  The Fortran RTL was shipped as VMS-style object
files.

One feature of VMS object files is that the name of the compiler that
produced them is recorded.  The lk linker reported this in the link
maps it produced.  VAX Fortran for Ultrix customers were rather
surprised to see the variety of languages (BLISS, Pascal, BASIC,
Fortran, assembler, etc.) that had been used to implement the Fortran
RTL.

-Paul W.

[TUHS] FORTRAN

[Larry McVoy]

On Mon, Mar 19, 2018 at 09:58:48AM -0700, Steve Johnson wrote:
> Here is the FORTRAN story as I remember it.
> 
> [much removed for brevity]

> By 1986 it became clear to me that I loved development but that AT&T
> was never going to make it in the computer business.?? I accepted a
> job in California at a startup.?? Less than a month after I left, the
> FORTRAN optimizer (by now almost ready to ship) was cancelled.?? ??A
> couple of months later, it was revived and finally went to market.
> 
> I'm told that six months after that it was the best selling language
> product...

Isn't it amusing (aka depressing) how some stuff has to be crammed down
people's throats?

[TUHS] FORTRAN

[Jon Forrest]

In roughly 1977 I was trying to use the 'fc' Fortran compiler
that came with Version 6 Unix at UC Santa Barbara. I needed to
do some binary I/O to read digitized speech data. That compiler
was very limited so I did what anybody would do back then - I called
Dennis Ritchie, who had written 'fc', to ask him what to do. I remember
he was surprisingly gracious but I don't remember what he said to do.

Version 7 Unix came to UCSB soon afterwards and I started using it.
It was easy to call C routines from it, which I did for a number of
low level purposes. However, I soon discovered some 'f77' bugs.
Fortunately Stu Feldman was visiting UCSB so I was able to demonstrate
the bugs to him personally. Again, I don't remember what came of this
but the Unix world was so small back then that it was common to be able
to communicate with many of the key developers.

Jon Forrest

[TUHS] FORTRAN

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4675 bytes --]

Here is the FORTRAN story as I remember it.

At Bell Labs, during the 7094 days a lot of code was written with FAP
macros.   I remember a LISP compiler that could go 150 levels
deep.  There was an excellent simulation package for filters that was
all assembler and macros.

When we switched to the GE (later Honeywell), all that work was
lost.   It was very painful, and a majority of people swore "never
again" and switched to FORTRAN.  A symbolic algebra program in
assembler, ALPACK, was slowly recreated in FORTRAN by a team of about
five of us.  That was the first time I worked with Dennis, who was
able to make a dynamic storage allocator and support recursive calling
in FORTRAN, a tour de force.  We were acutely aware that not all
FORTRAN compilers were compatible, and Barbara Ryder wrote a PFORT, a
program that validated that our programs fell into the subset of
FORTRAN that actually worked on the six major manufacturers'
FORTRANs.  PFORT was one of the inspirations for Lint.  Many of the
differences were completely bizarre -- one FORTRAN would abort if you
began a program with more than fifty comment lines...

At the time, the main computing center was actually run by the
Research department, using a kludged-up OS on the GE--one that had
originally been intended to run the much-delayed Multics.    When
they finally set up a separate computing dept., I was asked to move
over for a couple of years to make sure things went well.   I found
that I needed to write some service programs for the GE, and didn't
want to learn assembly language.  By this time, Dennis had B running
on the PDP-11, and I suggested he port it to the GE.   He said the
sentence that changed my life -- "Why don't you do it.  After all,
it's just a program!".   B was well suited to the GE, being a
word-addressed machine.and soon I was adding features such as a way to
make character constants for the GE's 6-bit character set.  And I
added the ability to call FORTRAN programs, with a FORTRAN keyword. 
(Though it would have been useful, FORTRAN calling B was tricky
because of the need to set up the stack...)

So the point is, FORTRAN was dominant at Bell Labs for most of the
time that C was being developed.  There was a group that was pushing
the adoption of PL/1, being used to code Multics, but the compiler was
late and not very good and it never really caught on.  The GE
compiler was one of the three that I abstracted the machine
independent code from for PCC (the other two were PDP-11 and IBM 360).

Stu Feldman decided to do F77 -- I'm not sure what his motivation was,
but there were a number of compelling ones available.  We talked
about what would be needed in the code generator and it wasn't much. 
 F77 pretty much used the C calling sequence and runtime library,
with added functions to do format statements, etc.  And knowing Stu,
it was as close to the standard as he could make it.

Fast forward a few years.   Unix and C were widely used in the Labs,
and while FORTRAN was still important for heavy numerical work, it was
waning in popularity.  I had accepted a job in development, being in
charge of System V languages -- C, Pascal, FORTRAN,Ada, and later the
first commercial C++ compiler..  It was obvious that F77 was losing
business bigtime to DEC VMS because their FORTRAN was better.  In
particular, the VMS programs ran faster.  So I put together a small
team of some of my best people to write a FORTRAN optimizer.

That project was very difficult to save -- every six weeks or so,
people would look at it, decide FORTRAN was passe, and cut it out of
the budget.  I would go to the mat and insist that it was important
and get it put back in.   We almost put entries in our calendars
every six weeks -- time to save FORTAN again.  The AT&T marketing
department treated languages as completely unimportant, and kept
assigning their newest hire to interface with me.  I had the same
meeting every month for a half-year or more, each with a different
newbie with no idea what a computer language was.  

By 1986 it became clear to me that I loved development but that AT&T
was never going to make it in the computer business.  I accepted a
job in California at a startup.  Less than a month after I left, the
FORTRAN optimizer (by now almost ready to ship) was cancelled.   A
couple of months later, it was revived and finally went to market.

I'm told that six months after that it was the best selling language
product...

Steve


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180319/189d314f/attachment.html>