Subj : Translating Case From Ba To : Murray Lesser From : Mike Luther Date : Mon Feb 19 2001 01:35 am 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. ML> To my knowledge, PL/I does not have automatic garbage collection. ML> AFAIK, no language that requires a "FREE" (or equivalent) statement to ML> recover memory otherwise lost in "the heap" has automatic garbage ML> collection. I've never written a program (except in C) that required a ML> "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. ML> I consider all of these (even BASIC) to be "modern" ML> languages. But then, I am very old. So am I, and shopworn, too. ML> There is no multithreading built in to any programming language that ML> I know other than PL/I (for "workstations") and Java. (I'm not sure ML> that one can write a Java interpreter or a PL/I compiler with built-in ML> multithreading, that will work under an operating system that doesn't ML> intrinsically support multithreading. For other languages, one makes ML> calls on the operating-system API if one wishes to implement ML> multithreading. The PL/I manuals warn _not_ to make such calls; use the ML> appropriate PL/I functions, instead. IBM "host" [big iron] versions of ML> PL/I implement multitasking within the same application, rather than ML> multithreading, because the host hardware and operating systems support ML> 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.." ;( ML> But I don't see how DOS can support multitheading per se. ML> OS/2 supports DOS multitasking in separate VDMs, but communication ML> between the DOS tasks is (intentionally) very difficult (and somewhat ML> 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!" ML> If I understand what you are talking about, "certification" means ML> proving the whole system is bug free!!! For one thing, that is both ML> 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! ML> For more on the themes you expressed, see my message to David, ML> topic: "Extending PL/I," that I am uploading to this same echo at the ML> 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) .