Subj : Translating Case From Ba
To : Mike Luther
From : Murray Lesser
Date : Sun Feb 18 2001 11:42 am
(Mike Luther wrote to Murray Lesser on 02-17-01, topic: "Translating
Case From Ba")
Hi Mike--
New "quote" convention for this one. There are none of my
previous-post quotes left in this reply. All "ML>" symbols mark your
deathless prose.
ML>Does PL/I have automatic garbage collection? Is the fact
>that you don't consider PL/I to be a "modern" language, the
>reason you didn't include it?
To my knowledge, PL/I does not have automatic garbage collection.
AFAIK, no language that requires a "FREE" (or equivalent) statement to
recover memory otherwise lost in "the heap" has automatic garbage
collection. I've never written a program (except in C) that required a
"free" statement, so I really don't know.
I'm not sure what constitutes a "modern" language; I suppose one
that is being used currently by many programmers and is still being
maintained by someone. (In that latter sense, nonVisual BASIC is no
longer a "modern" language!) Although Fortran was first devised many
years before PL/I and BASIC were, both of which were invented about a
decade before C came into being, Fortran is still being maintained. I
keep getting snail-mail spam from Microsoft trying to peddle their new
Fortran compiler to me, because I once bought a Fortran compiler for
CP/M from them! Even COBOL probably qualifies: Until very recently (at
least) there was more running code written in COBOL than in all the
other languages combined, and IBM is still selling a Visual Age COBOL
for WinNT! I consider all of these (even BASIC) to be "modern"
languages. But then, I am very old.
ML> ... I look at the issue of threading and DOS as probably
>the worst problem in going forward in OS/2 and so on, yet
>having to provide back-support DOS. There is no way to
>support it, that I can see, except for writing separate
>executables called in separate sessions, which pass data as
>disk related data, and include privately constructed
>semaphores to provide for proper synchronization of the
>disk data. Fortunately, what's currently of major
>importance to what I want, is pretty much sequential in
>nature - not speaking of the file operations, but pure
>logic ..
There is no multithreading built in to any programming language that
I know other than PL/I (for "workstations") and Java. (I'm not sure
that one can write a Java interpreter or a PL/I compiler with built-in
multithreading, that will work under an operating system that doesn't
intrinsically support multithreading. For other languages, one makes
calls on the operating-system API if one wishes to implement
multithreading. The PL/I manuals warn _not_ to make such calls; use the
appropriate PL/I functions, instead. IBM "host" [big iron] versions of
PL/I implement multitasking within the same application, rather than
multithreading, because the host hardware and operating systems support
such constructs.
DOS was first enabled to do multitasking with TSRs, then with IBM's
unlamented TOPVIEW, more successfully with Quarterdeck's DESQview (which
Quarterdeck has stated was an extension of TOPVIEW), and finally(?) with
Windows, which also uses some TOPVIEW "innovations." But I don't see
how DOS can support multitheading per se. OS/2 supports DOS
multitasking in separate VDMs, but communication between the DOS tasks
is (intentionally) very difficult (and somewhat dangerous to the health
of your system).
ML>He noted FDA didn't really think about what really had to be
>addressed for pure computer system use in medicine until the fatal
>accident cluster up in Tyler, Texas. A dosage calculation
>program for figuring out radiation levels needed for
>cyclotron treatment of cancer patients was coded for use
>with a numeric co-processor. Run on a box without one, the
>resulting errors in the math produced and overdose script
>which killed a number of patients...
ML>The application here is used, among other test-bed scenarios, in
>medical environments. If I get trapped in the business of
>licensing anything as a medical device, we'll have to not
>only proof each line of source, but also the full operating
>system down to the CPU level, so told me. From what I've
>been told, I see a very dark cloud still waiting for a
>number of folks writing toward medical use. I think they
>may be vastly under-estimating the real down-the-road
>intent to force the AMC-X12 new Federal transmission and
>communications standard, PKI, into what you will and will
>not be allowed to code as functional for such use.
If I understand what you are talking about, "certification" means
proving the whole system is bug free!!! For one thing, that is both
theoretically and practically impossible!! There has never been a
program that took more than 50 lines to code that was bug free in its
original release, no matter how carefully it had been tested :-). If
OS/2 were bug free, there wouldn't be any FixPaks! If you read the
README that comes with the FixPak carefully, you will find that very
little of the new code is to introduce new function. Some of it is to
delete function once allowed :-(. But most of it is bug fixes. A lot
of the bug fixes are to fix bugs introduced in previous FixPaks :-(.
For more on the themes you expressed, see my message to David,
topic: "Extending PL/I," that I am uploading to this same echo at the
same time as this one.
Regards,
--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * If it ain't broke, don't FixPak it.
--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)
