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