(Mike Luther wrote to David Noon on 02-13-01, topic: "Translating Case
From Bas")

Hi Mike--

Having written all that, I cannot let pass the
opportunity to point out that you have chosen the
wrong language for your task. PL/I is supported on all
the platforms you have mentioned and its SELECT
statement allows everything BASIC's does and more. For
me, the choice of PL/I would have taken very few brain
cycles.

> \ ?
>Did *NOT* realize PL/I is in DOS ??? (!) <- Pup scratching ear

David really works hard at proselytizing for PL/I :-). He got me
hooked in 1995 and I've never turned back; I have forgotten most of the
C that I ever knew.

I'm not sure about a PL/I for DOS, but there is a subset of PL/I for
CP/M, if you are still using that system, somewhere :-).

However, if you are not in too much of a hurry at run time, you
could write your application in REXX. (Due to unfortunate circumstances
that should have been under my control, I now need Object Rexx for
Windows in a Win98 partition; you will find it on one of the DevCon
discs in that suitcase.) REXX has the same SELECT construct as does
PL/I. (REXX was derived, in part, from PL/I; in the same sense that the original line-by-line-compiled Dartmouth BASIC was derived from
FORTRAN.) I got my copy of REXX for DOS (Personal REXX v 3.0 by Quercus Systems) in 1991. It may still be available.

It is fairly easy to port applications between PL/I and REXX,
although there are constructs in REXX that are not available in PL/I
(e.g., I had to write a PL/I subroutine using a KBD API call to get an equivalent to SysGetKey('noecho') in order to program "Press any key to continue" in PL/I).

Oh yes: I have a few programs written in BASIC PDS 7.1, compiled for
DOS, that run fine under OS/2 in a VDM. One of these days, if I live
long enough, I will reprogram them in PL/I for OS/2.

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * Which direction is forward?

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Oh boy! More wisdom cometh Murray!

David really works hard at proselytizing for PL/I :-). He got me hooked in 1995 and I've never turned back; I have forgotten most of the
C that I ever knew.

That's a strong statement.

I'm not sure about a PL/I for DOS, but there is a subset of PL/I for CP/M, if you are still using that system, somewhere :-).

As a matter of fact, my H-89 has CP/M as well as HDOS, I think! You know that Gordon Letwin who was the architect for the original OS/2 foray over at M/S was
snatched away from Heathkit, where he wrote MSDOS, if my memory is correct!

I sort of thing that the Z100 I have will also run on CP/M and I also have the M/S basic compiler for CP/M if my memory is correct!

However, if you are not in too much of a hurry at run time, you
could write your application in REXX.

I investigated that .. but actually gave up on it, as one reason, for precisely
the exact same reason you noted above. I carefully avoided all CHAIN operations and chose to carry all the required parameters for control passage between executables as disk I/O. I thought that made more sense in planning for portability. Thus executable shifting and load time is important.

That is also one of the reasons I winced when I tried Visual Age for Basic in OS/2 which I bought and have! Sure the ball bounces! But by the time you ever
see it bounce, your opponent has already stolen the interpreter and scored ten goals with the silly compiled ball!

If, a la as PowerBASIC finally did for WIN-ugh, M/S and IBM had ever released a
full compiler version of VB, that would have run on both OS/2 and WIN-ugh, the world would have been VERY different today!

(Due to unfortunate circumstances
that should have been under my control, I now need Object Rexx for
Windows in a Win98 partition; you will find it on one of the DevCon
discs in that suitcase.)

Giggle.

REXX has the same SELECT construct as does
PL/I. (REXX was derived, in part, from PL/I; in the same sense that the original line-by-line-compiled Dartmouth BASIC was derived from
FORTRAN.) I got my copy of REXX for DOS (Personal REXX v 3.0 by Quercus Systems) in 1991. It may still be available.

Here comes the education! Yes, if true, a part of portability sure might be made between OS/2 and back-level DOS!

But now Professor Murray, student raises hand in back of class ..

It is fairly easy to port applications between PL/I and REXX,
although there are constructs in REXX that are not available in PL/I (e.g., I had to write a PL/I subroutine using a KBD API call to get an equivalent to SysGetKey('noecho') in order to program "Press any key to continue" in PL/I).

Hold that for a moment, the next part you wrote is the key to why I'm sort of stuck ..

Oh yes: I have a few programs written in BASIC PDS 7.1, compiled for DOS, that run fine under OS/2 in a VDM. One of these days, if I live
long enough, I will reprogram them in PL/I for OS/2.

Here is where, in my own really rather uninformed view, and I'm not that good a
programmer at all, this whole game of portability went BONK! And not Son of Bonk either!

When Gordon Letwin crafted the foundation for OS/2 he also happened to be the Chief Architect of the PDS Compiler! Somewhere in my printed text I happen to
have read his remark, I think it's his, that, "The arrival of a new language is
marked by the arrival of the first true compiler." That's, in my feeble understanding of things, a very correct statement.

Because of the way that PDS 7.1 was written to integrate the assembler operations for the HEX21 interrupt work so well into BASIC, we got two very,very important things cross-referenced to both OS/2 and DOS! We got a terribly simple-to-implement full network file I/O system with file lock,record
lock; shared multi-user tools. And to a lesser note, we also got the entire ISAM file engine buttoned up so that even a dunce like Mikey could learn to use
and implement full networked file I/O with deadlock intervention and all that!

You know that insane feeling, the whirl of the dance, it plays with you, it plays with you. And when the room quits spinning, "Morning is breaking, comes the first morning ..." Gee, playing that hymn on a Baldwin concert grand is just like the computer keyboard when I first discovered INT21, I swear it! I swear it! We have no way to share emotions unless we have shared them, perhaps
that try at it will do.

INT21 opened up both a concomitant OS/2 development operation in DOS-VDM's together with a way to supply code that worked perfectly under Novell, even to the ability to adjust timing priorities to optimize it all! So, my suite suddenly became a full fledged network-aware and totally functional game. But only under Novell; nobody would listen to OS/2... sigh. They all insisted on
QEMM, and Desqview, and so did I, in support of things, for a long time.

I still have somewhere, I think, the FidoNet post Bob Juge posted that chided me for even comparing DesqView to OS/2. I think that is one of the landmark posts I've ever had addressed to me. I listened CAREFULLY to what Bob said, took his advice. But ... in doing so, the superb work of Gordon Letwin with PDS 7.1's FAMILY approach to programs and, specifically,the business of full network aware I/O, has been, to me a mess elsewhere.

Where do I go to get the complete cadre of INT21 network tools, in such a concise form as I've learned and written stuff for shared-locked file I/O with other than C? Remember! It isn't that it can't be done in other languages that are available in OS/2!

It's that I have to be able to extend the services *BACKWARDS* in DOS, yes,pure
DOS for another seven damned years after I make the toolset switch!

That and another of Gordon's diamond sharp gifts, variable length string arrays
with the assembly language automatic trashman! I listened! I listened! I learned a little, enough to know I ain't very smart.


I need two things, big time! I need multi-dimensional variable-length string arrays, that, in fact, can be dimensioned, not as you might suppose most folks do, but as DIM A$(-150 to +150, 10), or the like, and full network aware file I/O shared read-write lock and deadlock protectable. I flip entire facility control template array logic to the reverse dimension in the arrays for slush and comparative purposes, from data in full shared mode network files. It's more of this complex go-no-go logic enabled in the suite here.


Can REXX, for example, and PL/1, in one easy common source code caper,provide me with full support for OS/2, WIN-ugh, and DOS, for these?

And don't you, huge grin, tell me like Paul Sittler used to and keeps telling me, "Write your own functions, stupid!" I won't live long enough!

I've spent many hours with Ileff vectors, all that. I still can't quite get Watcom C++ to let me get through the string game, but I'm close. I think that's doable, and I know the file I/O bit is.

PL/1(i), whatever, OS/2, Win-ugh, DOS .. and REXX, are they really suitable tools for poor Mikey?


Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

(Mike Luther wrote to Murray Lesser on 02-15-01, topic: "Translating
Case From Ba")

Hi Mike--

Due to the coincidental initials, I have transliterated the code
that identifies things of mine that you quoted in yours, to "ml."

David really works hard at proselytizing for PL/I :-). He got me hooked in 1995 and I've never turned back; I have forgotten most of the
C that I ever knew.

That's a strong statement.

It is a fact. I never liked C, although I had to use Leor Zollman's
8-bit subset (instead of a macro language) to customize my CP/M word
processor (MINCE and SCRIBBLE, by Mark of the Unicorn), and had been
playing with the "full" language ever since Microsoft started to peddle Lattice's C compiler for DOS in a Microsoft box. Once, I rewrote one of
my DOS compiled BASIC utilities in C; both the new source code and the executable code files turned out be be about double the size of their
BASIC equivalents, which taught me that C was a lousy language for data-processing applications. When C++ came along, I read a couple of
books about it and decided that it was not for me.

In 1995, after following some discussion by David and friends in the
OS/2 programming conference of the old IBM PC Co. BBS, I bought the
Personal edition of PL/I for OS/2 for about a hundred bucks. (You can
still buy a "download only" edition for just a little more, but the
newer, costlier, version does not include the foot-long shelf of
hard-copy documentation that came with the original.) Since
multithreading is built into the "workstation" versions of the language,
my first "learning" program written in PL/I was multithreaded, just to
make sure I understood how it worked. I also wrote the PL/I subroutine
that called the KBD API to allow the "Press any key to continue"
construct at the time.

Truly, I haven't turned back. I haven't written a program in C
since 1995.

As a matter of fact, my H-89 has CP/M as well as HDOS, I think! You

>know that Gordon Letwin who was the architect for the original
>OS/2 foray over at M/S was snatched away from Heathkit,
>where he wrote MSDOS, if my memory is correct!

Gates bought the origin of MDOS from a Seattle outfit called Seattle Computer Products. It was a 16-bit port from Digital Research's 8-bit
CP/M. Letwin glides gracefully around this fact in his book on OS/2. Do
not believe much, if any, of the Microsoft propaganda about "Microsoft Innovations!"

The Forward to Gordon Letwin's "Inside OS/2" (ISBN 1-55615-112-9),
signed by Bill gates, carefully states that Letwin was "Microsoft's
architect for OS/2." The only place in that book that says that IBM
personnel contributed to the design (architecture) of the product is in
the Introduction. In spite of what you may have heard, or understood
from what you read in that book, Microsoft did not write OS/2 1.0 all by itself. After MS picked up its marbles and left the game, IBM wrote
OS/2 1.3, and all following versions, without any help from Microsoft.
(Next time you boot Warp 4, note that "OS/2" is a registered IBM
trademark!)

I don't want to denigrate Letwin's contributions. After all, the
patent for HPFS was issued to Letwin and assigned to Microsoft. (It is
too bad that Microsoft has abandoned it for its own products.)

Oh yes: I have a few programs written in BASIC PDS 7.1, compiled for DOS, that run fine under OS/2 in a VDM. One of these days, if I live
long enough, I will reprogram them in PL/I for OS/2.

What I didn't say, but should have, is that I had to rewrite a few
of those BASIC programs slightly to remove the "clever" programming that
called on DOS functions (usually in assembled procedures) that are not supported by OS/2 for "system integrity" reasons. You can find out
which DOS constructs are not supported in an OS/2 VDM if you can find a
copy of the out-of-print "OS/2 2.0 Technical Library" manual
"Application Design Guide" (IBM p/n 10G6260).

Because of the way that PDS 7.1 was written to integrate the

>assembler operations for the HEX21 interrupt work so well into
>BASIC, we got two very,very important things cross-referenced to
>both OS/2 and DOS!...

One could "integrate" assembly-language subroutines into programs
written in the original MS BASIC compiler for CP/M, by linking them as
called subroutines. Similarly, you could link assembled subroutines
calling INT 21h functions in the first MS compiler for DOS. (To my
knowledge, the later "MS Business BASIC" was the first MS BASIC compiler
that let you call separately-compiled, as well as assembled, procedures,
as either functions or subroutines.)

That and another of Gordon's diamond sharp gifts, variable

>length string arrays with the assembly language automatic
>trashman! I listened! I listened! I learned a little,
>enough to know I ain't very smart.

You are too young :-). Variable-length string arrays were available
in CP/M BASCOM 7, as was built-in garbage collection. PL/I (and a few
other languages other than C) also provide for variable-length strings, although you may have to specify the _longest_ string length you expect
to see. The only "modern" language (other than BASIC) I know of that
provides for automatic garbage collection is Java.

Can REXX, for example, and PL/1, in one easy common source

>code caper,provide me with full support for OS/2, WIN-ugh,
>and DOS, for these?

Of course not. There is no such thing as true cross-platform
compatibility at the source-code level unless the language is simple
enough to not call on any operating system (or hardware) constructs that
are not available in all of the platforms under consideration, and
unless all the platforms use the same word length for arithmetic
operations. You probably don't remember the anguish expressed by some
users when they learned that their Fortran programs, when run on the new
32-bit (numeric word length) System/360 machines, produced different
results from when they had been run on the 36-bit 700/7000 series
machines. (This is largely a result of doing arithmetic in floating
point.) If you want more-or-less cross-platform capability, write
your application in Java. If you want arithmetic operations to be
independent of hardware word length, use REXX. Otherwise, you are on
your own.

PL/1(i), whatever, OS/2, Win-ugh, DOS .. and REXX, are they

>really suitable tools for poor Mikey?

A rhetorical question that only poor Mikey can answer :-).

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * One printed manual is worth a thousand INF files

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Smiling here, Murray..

Due to the coincidental initials, I have transliterated the code
that identifies things of mine that you quoted in yours, to "ml."

we'll get to see a proper caste relationship this time!:

ML> Murray Lesser
ml> Mike Luther
grin.

... Once, I rewrote one of
my DOS compiled BASIC utilities in C; both the new source code and the executable code files turned out be be about double the size of their BASIC equivalents, which taught me that C was a lousy language for data-processing applications. When C++ came along, I read a couple of books about it and decided that it was not for me.

It really becomes attention grabbing when a translator goes to work. With no offense to our Spanish culture friends, it's much like comparing romance to technology in language use. 'Cuidado con el serpeinte de hiero que marcha en frente del aeropuerto senor.' By then the pilote has hit the train.

Gates bought the origin of MDOS from a Seattle outfit called Seattle Computer Products. It was a 16-bit port from Digital Research's 8-bit CP/M. Letwin glides gracefully around this fact in his book on OS/2. Do not believe much, if any, of the Microsoft propaganda about "Microsoft Innovations!"

I said that wrong. Gordon wrote HDOS. Once I'd posted, I went back and read it again .. discovered I'd used MDOS or whatever instead of HDOS.

The Forward to Gordon Letwin's "Inside OS/2" (ISBN 1-55615-112-9), signed by Bill gates, carefully states that Letwin was "Microsoft's architect for OS/2." The only place in that book that says that IBM personnel contributed to the design (architecture) of the product is in the Introduction. In spite of what you may have heard, or understood
from what you read in that book, Microsoft did not write OS/2 1.0 all by itself. After MS picked up its marbles and left the game, IBM wrote
OS/2 1.3, and all following versions, without any help from Microsoft. (Next time you boot Warp 4, note that "OS/2" is a registered IBM trademark!)

Thinking about what I've thought about it all, I now realize that all along I've really understood Microsoft wasn't the soul (sic intended!) source for OS/2. However, since I am too young to know the animosity on a more personally
educated basis, I never really focused on the above, until I read your post. Of all honor tarnishment, I suspect intellectual dishonesty is, perhaps the worst. The distinguishing facet which establishes the human animal at the top of the chain is reasoning and emotional connections to that; it's the reason for my opinion.

I'll amend my comments about Gordon and OS/2 suitably in the future.

I don't want to denigrate Letwin's contributions. After all, the patent for HPFS was issued to Letwin and assigned to Microsoft. (It is too bad that Microsoft has abandoned it for its own products.)

Obviously .. perhaps Gates was just being too forward in that forward.

Of 'original sin', chuckle,

.. supported by OS/2 for "system integrity" reasons. You can find out which DOS constructs are not supported in an OS/2 VDM if you can find a copy of the out-of-print "OS/2 2.0 Technical Library" manual
"Application Design Guide" (IBM p/n 10G6260).

foggy memory says they might also be documented in the printed books for the PD7 compiler. Note the below is more appropriate syntax!:

ml> Because of the way that PDS 7.1 was written to integrate the
ml> assembler operations for the HEX21 interrupt work so well into
ml> BASIC, we got two very,very important things cross-referenced to
ml> both OS/2 and DOS!...

One could "integrate" assembly-language subroutines into programs written in the original MS BASIC compiler for CP/M, by linking them as called subroutines.

Sorry, Mikey is too young.

Similarly, you could link assembled subroutines
calling INT 21h functions in the first MS compiler for DOS. (To my knowledge, the later "MS Business BASIC" was the first MS BASIC compiler that let you call separately-compiled, as well as assembled, procedures, as either functions or subroutines.)

Ah so. So corrected here... ;)

But, OPEN ... for SHARED .. plus PUT and GET are easier, if they do the necessary things you'd have to code in assembler, than without them. In looking
at the assembler stuff, it just seemed obvious how the compiler got written, that's all.

You are too young :-).

Already admitted. Also, correctly analyzed by my Dad, may he rest in peace; too lazy and stubborn. ""But I don't WANT to do it that way.""

.. Variable-length string arrays were available
in CP/M BASCOM 7, as was built-in garbage collection. PL/I (and a few other languages other than C) also provide for variable-length strings, although you may have to specify the _longest_ string length you expect
to see.

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?

The only "modern" language (other than BASIC) I know of that

provides for automatic garbage collection is Java.

After being forced to take out the trash, and recalling all the bandwidth I've seen consumed discussing it in C discussions, life seems just simpler with a Data Disposal in the programmer's workbench! (Bad pun but whatever!)

I'm studying Java trying to make sense of all this. I wasn't pleased at the recent Microsoft - Sun settlement. It seemed to forecast yet another fractionated toolset, another log thrown in the road. Just more embrace, embellish and exclude for us poor OS/2 folks.

Can REXX, for example, and PL/1, in one easy common source
code caper,provide me with full support for OS/2, WIN-ugh,
and DOS, for these?

Of course not. There is no such thing as true cross-platform compatibility at the source-code level unless the language is simple enough to not call on any operating system (or hardware) constructs that are not available in all of the platforms under consideration, and
unless all the platforms use the same word length for arithmetic operations.

Of course yes. 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 ..

You probably don't remember the anguish expressed by some
users when they learned that their Fortran programs, when run on the new 32-bit (numeric word length) System/360 machines, produced different results from when they had been run on the 36-bit 700/7000 series machines. (This is largely a result of doing arithmetic in floating point.) If you want more-or-less cross-platform capability, write
your application in Java. If you want arithmetic operations to be independent of hardware word length, use REXX. Otherwise, you are on your own.

I don't know that specific illustrative example. I am familiar with more recent similar incidents. Appropriate parallel understanding comes from what was told me to be the key issue in focusing the current FDA thinking on medical
device licensing by Dr. Tom Shoppe. I think that name spelling is correct.

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. Obviously that's not exactly the same thing as the above differences, but perhaps it even
more sharply illustrates why I'm both concerned about all this, and at the same
time, torn about where to go in going forward to the next step.

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.

You are far better at all this than Mikey. But I don't think you would argue that if we *HAD* to stand on operating system certification, we sure could do it with OS/2. We'd, I think, never be able to certify on the basis of actual LINUX, since an open source compile operation would likely never be issued that
approval. Nor would we ever be able to certify on the basis of a Microsoft platform. Heck, you'd never be able to get the code past everyone in the certification game before it all changed and everything had to start all over!
But maybe I'm mis-thinking all this..

To corrupt Gamov ... 2001, 2002, 2003, 200oo .. ?

I've never been there, but I think it would be a priceless experience to be able to take the 45 minutes that Einstein took to climb the spire at Ulm, look out, as he did to survey all he saw of dimensions, and look over it not only in
that sense but with the language and experiece in dimensions of hardware interfacing that you have seen.


Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

(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.

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.

... 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).

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...

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)

I'll continue .. Murray .. your posts are very helpful in trying to reach a decision on where to go next ..

All "ML>" symbols mark your priceless advice.

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.

Yes, another mis-said or mis-phrased use of terminology. I suffer that I've never had formal training in any of this. Properly beaten early-on, my understanding of all this would be better. However, in this case, Lewis Carroll's comment, "He only does it to annoy ..", isn't true at all here.

I consider all of these (even BASIC) to be "modern"
languages. But then, I am very old.

So am I, and shopworn, too.

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.

These are things in which I have no experience. I know where I want to go. Getting closer to there has been fun. I really wish I'd had the formal training and schooling long ago and far away. But if I'd taken the time and gone down that road, I'd not have the other perceptions from experience that seem to be critical to the tasks, either..

It's almost back to Lewis Carroll again, "You are Old Father William, the Young
Man said.." ;(

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).

Which is exactly why I isolated the required communication to disk I/O. A long
time ago Paul Sittler taught me, "Let the operating system do the work!"

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!!

You understand perfectly. I understand, well enough, I think, your comment. I agree. Now, that said, I'll pass along Dr. Shoppe's instructions to me in roughly 45 minutes he gave me in October of 1996, I think. He has been remarkable accurate in some ways about where the Feds are going. As far as I can tell, it is the intent of the FDA that "certification" means proving the whole system is bug free!!!

Period.

They take the position that when they issue a certification for a `medical device', that's supposed to be the case. As a result of what happened in Tyler, Shoppe, as Chairman for the Software Standards committee told me, in essence, the following:

1.) If software and hardware combined, touch the body to either
take data from it or treat the body, it will be a licensed
medical device.

2.) If medical data of any kind is stored in a medical record
by hardware and software, we want to make sure that record
is seen exactly as it was placed there, by any qualified
medical practitioner who uses that data to make a future
determination on treatment.

That means that all forms of compression are of interest to
to the FDA. The FDA will insist that compression must be
loss-less in every case.

I was told that, at some point in the future, the results
of that position would become quite interesting. He told
me that, although most folks didn't think about it, all
modems use compression algorithms to move data. Thus,
at some point in the future, all modems used in medicine
would wind up being licensed, at least to the extent of
their compression techniques!

I was cautioned to stay completely out of the network game.
In that all networks use compression of some form for data
exchange and packetizing, at some point in the future all
networks used in medicine would become licensed. (!)

3.) In so far as medical record storage was concerned, at some
point in the future, push technology would be forbidden
for medical record modification. The position of the FDA
was and will become that only a qualified medical person
can make a decision as to what data goes into a medical
record at any specific facility. Multiple site storage
of records wasn't a problem, provided that the precise data
that was in that record was absolutely guaranteed to be
delivered in lossless fashion to some other place. However,
any use of a remote facility being able to alter other site
records on a remote-insertion basis, without the approval
of a qualified medical person on site to permit that, would
at some point in the future, be completely forbidden.

That was pretty darn specific, I thought. I also was on hand at the Houston HAL-PC when the president of Western Digital laid out the next five years of what we could expect in storage technology, as compared to the march of hardware evolution. I thought of the above comments by Schoppe and wondered if
it truly would work out that way. That was in mid-1998.

Now, if you have followed what has happened, particularly in the last two years
as to the Federal adoption of the new, now formally required AMC-X12 record transmission standard, what Schoppe told me is turning out to be dead on target, I think! Together with what is currently a mandated PKI identification and security blanket, within the next two years from October 16,
2000, for all large institutions, and three years for everyone, all forms of electronic exchange of medical data must comply to that standard.

The facility doesn't have to store in that exact format, but every single medical operation in the whole country has to talk it and be able to handle everything that is in the transmission format, even if it doesn't store it directly as such.

As of the Final NPRM that was only given 30 days for public comment which was issued on June 4, 1999, that standard encompassed, if my count was correct,938 different field definitions. Although the fields were fixed-length records in the raw workup, the transmission standard is variable length data, trailing spaces truncated, for transmission effectiveness. As well,it includes nested loops in those variable length layouts, total iterations not sent, if loop count isn't filled.

I've managed to code that 'standard' at least the proposed form from 1998,into BASIC's UDT's and "C" structures. That expands, as far as I can see into CLASS
concept for C++, in my training-starved programming mind-set. I've managed to cross-walk this to the current HCFA1500 form, as well as the more recent UB-92,
both of which are technically dead now. I've managed to cross-walk it to the roughly 1,000,000 lines of BASIC source in my real-time facility control template.

The test bed works. But it isn't WAN, nor in present form, what would be efficiently mirrorable on distance-separated big-iron sites. The massive binary logic keying operations also seem easiest to move from Btrieve to C-tree, if my current research looks correct. That's another whole different story. Large numbers of keys and where they point are crucial.

The only way to catch a run-away pony in the near future will be to get it as it leaves the barn, I think. And since we are operating in near-real time with
concurrent reasonable standard GAP accounting double-entry scorecard work, that's, as far as I can see, far beyond the intent or proposed scope of AMC-X12. If I don't stumble, we might be in the running for a pre-processor slot for our own way to obviate any need or third-party claims processing, removing that cost of business.

AMC-X12 provides for 'pointering' to remote site WAN deliverable embellished record content for what will be and become all the visual and audio detail content that will evolve in time. No, I can't provide interface to all that in
DOS, but then, exactly what Dr. Shoppe forecast isn't happening, in what's out there for medicine today, is it?

The trick, looks like, to me, in being able to make the right decision on the tools to implement what's been done in a WAN environment. Tools that also must
effectively move us off the current testbed crude way of doing what was done, the only way it could be done, I think, as it is now.

OS/2 sure looks good for that, given that it is reasonably stable, is reasonably free from pot-shots, and it *COULD* be certified as part of what FDA
might want as a medical device, if needed. I suspect Dr. Schoppe's full target display is beyond what FDA can every pay for, but maybe not.

Thus, we are here in the OS/2 programming echo!

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.

So noted.

Thank you very much for taking time with a very less capable person than either
of you two gents.

Mike @ 117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

On 02-19-1901, Mike Luther wrote to Murray Lesser about "Translating
Case From Ba:"

Hi Mike,

The only way to catch a run-away pony in the near future will be
to get it as it leaves the barn, I think. And since we are
operating in near-real time with concurrent reasonable standard GAP
accounting double-entry scorecard work, that's, as far as I can
see, far beyond the intent or proposed scope of AMC- X12.

That should be GAAP (Generally Accepted Accounting Principles) GAP I
believe sells blue jeans. <VBG>


Regards, Jim

___
■ KWQ/2 1.2i ■ I'm WARPed by choice

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

Yes, Jim ..

That should be GAAP (Generally Accepted Accounting Principles) GAP I believe sells blue jeans. <VBG>

I make lottsa errors, grin!

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

(Mike Luther wrote to Murray Lesser on 02-19-01, topic: "Translating
Case From Ba")

Hi Mike--

Thank you very much for taking time with a very less

>capable person than either of you two gents.

You are very welcome.

But, don't denigrate yourself. I, too, have never had any formal
training in programming. I started learning to program by solving
aeronautical engineering problems digitally in 1948, on an experimental
machine built by IBM for an aircraft company. Since then, I have
continued the learning process by reading, experimenting, and asking
questions of people who might know the answers. There is nothing like
having a real problem to solve that gives one an incentive to learn
something new :-).

Regards,

--Murray
<Team PL/I>
___
* MR/2 2.30 #120 * Have a frabjous day." he chortled in his joy

--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)