RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
It is to bad Bob could not do his presentation on Caché. It would have cleared up much of your understanding of Caché. There was a discussion about some of the differences between M and Caché awhile ago that led to Bob offering a class at Boston. Here is my simple answer to your comments. You can query the Vista database using SQL so from the outside it looks no different than a relational database. I use SQL all of the time. In fact Bob gave me a disk that had a very large part of Vista mapped (4777 classes) so that it can be queried. We had slowly been working on our own mapping of Vista. You ask about the underlying code for Caché. I'm not sure if you mean what Intersystems writes there routines in or what developers have to write in. Intersystems uses Cache Object Script. It is Object Orientated M with C like convention such as brackets. You could use standard M which we do or Cache Object Script which we do or Cache Basic which we have not used. The idea of Cache Basic is to eliminate the learning curve of a new language. With Cache we can write interfaces to Vista in SOAP, Java, EJB, COM, VB, .NET, C++, PHP or Cache Server Pages. I'm sure I left some things out. We can get to the data from ODBC or JDBC. We are looking at using an open source reporting tool that would connect via JDBC. From my point of view there is one thing that is missing that would make Cache a rapid development platform for Vista (It still maybe the fastest for GUI. I have not tried M2web. I do not think Jim has tried Cache so no way to know for sure. There are other reasons to use M2web.). We can read the data out of Vista fine. Cache will write the data fine into the globals bypassing Fileman, but if you do not want to bypass Fileman it presently requires silent calls to Fileman to store the data. This is not any harder than doing this in M, but not as fast as working with Cache Objects. If the Objects can take care of the storage of data in Fileman you will then see very rapid GUI development. If someone is working on this I think it will be a big plus for Vista. This was a weak explanation so be kind to me Bob. Ed Walton Western State Hospital -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy Anthracite Sent: Thursday, April 14, 2005 2:00 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es My understanding is that they are going to be using a relational database that Cache supposedly has in it ?? for now and ultimately the idea is that it should work with any relational database such as MySQL, etc. Note that I stated that it was an Oracle LIKE database. (Steve pointed out that this might not be the best choice of words. Oracle, the 1000 lb. gorilla, is something many people will have heard about and thus will recognize when relation database may mean nothing to them, which is why I chose the simile.) I persist in doubting that the speed of a relational database based system can match that of an M based system no matter who supplies it. In fact, I wonder what the underlying code for the Cache database is written in. Could it be an M based database with restrictions on how it can be populated? Oracle, from what I have heard, will be the basis of the national data repository. I could be all wet about any or all of this, however. I am just piecing together things I have heard at meetings or read in the press, etc. On Thursday 14 April 2005 10:44 am, David Sommers wrote: What I don't understand is that the VA has a national license with Microsoft to use any and all their products. If it truly is any relational database, who spent money on Oracle when SQL Server is free to use already? Sounds political to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steven mcphelan Sent: Thursday, April 14, 2005 8:26 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Very well stated. Nancy had also responded to this thread. She said ...It is the attempt to move VistA from Cache M based on to an Oracle like database... Let's agree with the VA on the use of terms. They claim that the rehosting is not exclusive to Oracle. Rob's term is relational database. I had asked the specific question as to what did he mean by relational, SQL compliant? He said yes. The fact that the VA is standardizing some of its enterprise wise solutions to the Oracle platform is strictly a business decision that they have made given their particular circumstances. So to constantly state that the VA is moving from M to Oracle can be perceived as prejudicial and inaccurate. Can we all agree to stop using terms like Oracle like database to a more correct analogy which would be something like SQL compliant database. Many people seeing the term Oracle may have
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
OK, true Binary Trees are a heirarchical record structure
which is ordered by some criteria, records after this one sort to the right and
lesser records sort to the left. Each new record walks the chain of
records until it finds the niche where the new record belongs. A pointer
is captured, a new record is created and pieced into the chain. OK, that
is the traditional Binary Tree.
In most MUMPS implementations, we have a global directory
block, which knows where all of the globals (persistent symbols) begin (their
head nodes). Each time a global diretory block gets full, it is extended
into a new global directoy extensionblock. Great, we have a quick
string of names of the globals and their pointers to their head blocks.
Each global has one head block. When it is first created with its first
data block, there are two blocks involved, the head block and one data
block. As more data is added and arranged, the data block fills up.
Soon it fills up and we need to add a new data block. Half of theone block
is moved to the new data block and there is a new type of block added, a pointer
block to now point to the two data blocks. The data blocks are
sequentially linked with at least a right pointer to the next data
block.
Now as the database grows with more data blocks added, pointer
blocks are added to the intermediate pointer structure between the head block
and the data blocks. The general rule of thumb is that the fan-out rate of
the pointer blocks to data blocks is about 1:50. This relationship is
retained as there are more pointer blocks are created. The structure grows
as the data is added. So the heirarchy is exceedingly wide and there are a
minimum number of pointer levels between the pointer blocks. I see that
Maury has added some external references which might help. I have to cut
it here for tonight.
Best wishes; Chris
- Original Message -
From:
Ron
Ponto
To: hardhats-members@lists.sourceforge.net
Sent: Thursday, April 14, 2005 9:29
PM
Subject: Re: [Hardhats-members] BIG NEWS
re HealtheVet- St. Petersburg Tim es
For us new Mumpies could you explain what B-trees are and what is
apointer split?
---Original
Message---
From: Chris Richardson
Date: 04/14/05
23:23:45
To: hardhats-members@lists.sourceforge.net
Subject: Re:
[Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim
es
Actually there is.
Most MUMPS implementations are multi-way
B-trees.Real true B-trees
suffer badly in real-life, nearly every action is a pointer
split.The
performance of MUMPS sparse arrays is in the shared buffer pools
and broad
pointer structures that get you to any data location in a 1,000,000
element
database in 7 physical disk accesses or less.
Best wishes;Chris
- Original Message -
From: "Thurman Pedigo" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Thursday, April 14, 2005 7:26 PM
Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St.
Petersburg Tim
es
Back to Donald E. Knuth eh? One would think that by now...
Guess there
isn't
much new under the Sun. ..tx/t
-Original Message-
From: [EMAIL PROTECTED]
[mailto:hardhats-
[EMAIL PROTECTED]]
On Behalf Of Greg Woodhouse
Sent: Thursday, April 14, 2005 6:14 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet-
St. Petersburg
Tim
es
Of course, when you really get down to basics, it's all
B-trees,
whether you're talking about MUMPS or your favorite
RDBMS.
s-members
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products
from real users.
Discover which products truly live up to the hype. Start
reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from
real users.
Discover which products truly live up t
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
From: Thurman Pedigo [EMAIL PROTECTED] Organization: [EMAIL PROTECTED] Reply-To: hardhats-members@lists.sourceforge.net Date: Fri, 15 Apr 2005 09:54:15 -0500 To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Wow! That explains why MUMPS is so much faster then the old KFAM I cut my teeth on - AND why MUMPS won a shoot-out I set up between it and the Pick operating system in the 80's(anyone remember Dick Pick?). I think my memory is correct that $O sorted 100,000 records in less than a minute and Pick was still going after 30 min. Now for the real question - where does SQL fall in this multi-way B-tree hierarchy? Thanks, thurman Thurman, the simple answer is SQL does not fall in the underlying B-tree hierarchy!!! You have been misdirected by the well meaning but equally misdirected discussion that appeared between my response and your question. The matter is suitable for several weeks of classes in a graduate level IT course, so I can't go from Kindergarten to 12th grade on this point in a short message here. Nonetheless, I will make a few statements at the risk of failing to clarify the matter for you, Thurman. 1. The MUMPS Global system is a relatively high level abstraction that describes the behavior of a system for managing persistent bindings between symbols and data. This system exists entirely in a conceptual domain that does not depend on any particular underlying implementation technology, be it B-tree or whatever else. 2. The relational data management system described by the Standard Query Language standard (SQL) is likewise a high level abstraction that exists conceptually in a layer that is independent of the underlying implementation technology, what ever that may be. 3. Discussions about relational database systems that become focused on such base layer technologies as B-trees have wondered off the reservation and are blindly stumbling around in the wilderness. 4. As for hierarchy in data management systems, the common 'relational database' system, also referred to as an SQL database system, is hierarchical! a. Any given hierarchy can be assigned a value that reflects the order of that hierarchy in an infinitely large family of hierarchies. There can be a hierarchy of order 5, or of order 2, or of order 1. b. A hierarchy of order 1 is the simplest order and is easily recognized by practically anyone as a table. A given table may have 1 or more rows and one or more columns. (Note a simplest table is a grocery list.) The relational database creators have chosen to limit that system to hierarchical order 1, the 'table' as the domain of elementary data structures. This decision opens up the possibility that such a system can include a calculus for manipulating the data in the system where that calculus is fully deterministic, hence completely predictable. c. VA FileMan can be used to create a system of 'files' that are restricted to file structures that simple tables. In this sense then this system of tables in FileMan corresponds structurally to a relational database. However, FileMan does NOT offer the calculus for operating on such a system of files using the SQL operations for manipulating the data in that system. If a FileMan system of files includes file structures that contain sub-files, and/or 'pointer' linkages among files, then this system of files is no longer of hierarchy order 1, and is not, therefore, similar to a 'relational database' structure. 5. In the context of superiority debates--my database management system can beat up on your database management system--it is important to carefully take into consideration the need to include mention of the underlying technology. ...and, to know when mention of the underlying technology is not relevant to the debate. ...and, further to be especially careful to prevent the mention of underlying technology from pushing aside the original discussion about the relative merits of high level abstractions like MUMPS globals and SQL tables. ... . .. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Wilderness pretty well describes where I am. I bought Knuth's Sorting and Searching something like 25 years ago, when I was working on KFAM, and never really understood what he was saying. This has been most helpful, though I obviously remain in kindergarten. Though it does appear we progressed beyond the index file addressing a separate flat file. I guess the nice part of that system was one could read the data in the flat file, even after pointers became corrupt, AND if the data was clean re-index it with a utility. I sometimes wish I had spent that programming time on MUMPS, however, $15,000 for a compiler in 1978 $ was a great leap. Thanks for the lesson, thurman -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Richard G. DAVIS Sent: Friday, April 15, 2005 10:22 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim 3. Discussions about relational database systems that become focused on such base layer technologies as B-trees have wondered off the reservation and are blindly stumbling around in the wilderness. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Right. The use of B-trees does not have to do with the abstraction (table, global) presented to the user, but how disk storage is managed under the hood. Gregory Woodhouse [EMAIL PROTECTED] On Apr 15, 2005, at 9:22 AM, Richard G. DAVIS wrote: From: Thurman Pedigo [EMAIL PROTECTED] Organization: [EMAIL PROTECTED] Reply-To: hardhats-members@lists.sourceforge.net Date: Fri, 15 Apr 2005 09:54:15 -0500 To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Wow! That explains why MUMPS is so much faster then the old KFAM I cut my teeth on - AND why MUMPS won a shoot-out I set up between it and the Pick operating system in the 80's(anyone remember Dick Pick?). I think my memory is correct that $O sorted 100,000 records in less than a minute and Pick was still going after 30 min. Now for the real question - where does SQL fall in this multi-way B-tree hierarchy? Thanks, thurman Thurman, the simple answer is SQL does not fall in the underlying B-tree hierarchy!!! You have been misdirected by the well meaning but equally misdirected discussion that appeared between my response and your question. The matter is suitable for several weeks of classes in a graduate level IT course, so I can't go from Kindergarten to 12th grade on this point in a short message here. Nonetheless, I will make a few statements at the risk of failing to clarify the matter for you, Thurman. 1. The MUMPS Global system is a relatively high level abstraction that describes the behavior of a system for managing persistent bindings between symbols and data. This system exists entirely in a conceptual domain that does not depend on any particular underlying implementation technology, be it B-tree or whatever else. 2. The relational data management system described by the Standard Query Language standard (SQL) is likewise a high level abstraction that exists conceptually in a layer that is independent of the underlying implementation technology, what ever that may be. 3. Discussions about relational database systems that become focused on such base layer technologies as B-trees have wondered off the reservation and are blindly stumbling around in the wilderness. 4. As for hierarchy in data management systems, the common 'relational database' system, also referred to as an SQL database system, is hierarchical! a. Any given hierarchy can be assigned a value that reflects the order of that hierarchy in an infinitely large family of hierarchies. There can be a hierarchy of order 5, or of order 2, or of order 1. b. A hierarchy of order 1 is the simplest order and is easily recognized by practically anyone as a table. A given table may have 1 or more rows and one or more columns. (Note a simplest table is a grocery list.) The relational database creators have chosen to limit that system to hierarchical order 1, the 'table' as the domain of elementary data structures. This decision opens up the possibility that such a system can include a calculus for manipulating the data in the system where that calculus is fully deterministic, hence completely predictable. c. VA FileMan can be used to create a system of 'files' that are restricted to file structures that simple tables. In this sense then this system of tables in FileMan corresponds structurally to a relational database. However, FileMan does NOT offer the calculus for operating on such a system of files using the SQL operations for manipulating the data in that system. If a FileMan system of files includes file structures that contain sub-files, and/or 'pointer' linkages among files, then this system of files is no longer of hierarchy order 1, and is not, therefore, similar to a 'relational database' structure. 5. In the context of superiority debates--my database management system can beat up on your database management system--it is important to carefully take into consideration the need to include mention of the underlying technology. ...and, to know when mention of the underlying technology is not relevant to the debate. ...and, further to be especially careful to prevent the mention of underlying technology from pushing aside the original discussion about the relative merits of high level abstractions like MUMPS globals and SQL tables. ... . .. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
From: Thurman Pedigo [EMAIL PROTECTED] Organization: [EMAIL PROTECTED] Reply-To: hardhats-members@lists.sourceforge.net Date: Fri, 15 Apr 2005 13:13:30 -0500 To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Wilderness pretty well describes where I am. I bought Knuth's Sorting and Searching something like 25 years ago, when I was working on KFAM, and never really understood what he was saying. This has been most helpful, though I obviously remain in kindergarten. As are most of us, Thurman. The question is: Are we willing to acknowledge that is so about ourselves. Years ago, David Van Hooser--the senior manager in the DVA-Dept of Medicine Surgery, responsible for the DHCP program--asked me why recommendations from one of his most senior managers of DHCP system development had proven to be without any merit. I pointed out to him that none of us (I was one of those senior managers) were professionally trained in information technology. Instead, we were self-declared IT professionals. Thus, we were already proven to be likely to self-declare expertise in IT when he asked us to express an opinion. This is an age old problem. I refer you to Amadeus, in which the king's court specialist in classical music was asked his opinion of the new Mozart work, and replied that it has too many notes!. Ask a fool a question, and you are at risk for getting a foolish answer. So remember Thurman, many of the voices you hear on this party line are similarly self-declared experts, when if fact we are mostly, myself included, just students in the world of IT. Though it does appear we progressed beyond the index file addressing a separate flat file. Well, I hate to deflate your balloon, and send you crashing on the Plain of Confusion, but the primary index of a VA FileMan file is in reality an 'index file' that 'addresses a separate flat file'. :-) The more things change, the more they stay the same. I guess the nice part of that system was one could read the data in the flat file, even after pointers became corrupt, AND if the data was clean re-index it with a utility. Yes, the VA FileMan has a utility that will re-index the name field (the so called .01 field) if that index ever becomes 'corrupt'. That index is merely a simple list of (read copy of) the up-right data in a sorted order, paired with the up-right data INTERNEL ENTRY NUMBER's (IEN), where the IEN are 'pointers'. I sometimes wish I had spent that programming time on MUMPS, however, $15,000 for a compiler in 1978 $ was a great leap. I know the feeling. It was with great trepidation that I signed the Request for Purchase of an Intersystems M-11 license for that exact amount in September of that year. As a person without any prior experience with MUMPS, and with a 'mandate' to deliver a patient care application to end-user's by May of 1979, and do that on a 'part-time' basis in addition to a full time job in that VA medical center, I was just a bit concerned. :-) So, imagine my shock and surprise when the application went live in May and worked as envisioned providing the means for doctors to prescribe diets for diabetic people in terms of nutrient profiles. Dietitians were able to take those nutrient profile 'prescriptions', and in collaboration with each patient, and using the MUMPS application I developed, produce meal plans for each patient that harmonized with the diet styles and preferences of the patient. I am certain that I could not have accomplished that task under the circumstances of that time with any other technology then available. I do not believe that there has been any new technology developed since then that could displace the advantages provided by M technology as available today. I must stress that this work was critically and specifically enabled for success by the use of a set of programmer development tools that eventually became known as the VA File Manager. George Timson personally 'saved my life that night' when he sent me a collection of MUMPS routines over a lowly dial-up connection at 1200 baud, for which I am eternally grateful. Thanks for the lesson, thurman I appreciate your thanks, T. Regards, Richard. P. S. It is worthwhile at this point, to make another comment about compare/contrast discussions concerning database management systems. Remember, I have just recently offered comments that distinguish among various layers of Abstraction. Thus, relational database concepts are at a relatively high level layer of abstraction vis-à-vis the atomic level of bits and bytes in some long term disk based storage system. The MUMPS global system is also a higher level of abstraction than at the disk storage level. Likewise, VA File Manager is a HIGH level abstraction as well. However, take special notice that the VA File Manager is a level of abstraction that is above the MUMPS global level of abstraction
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Many great applications are developed locally. True, great products such as BCMA, GUI Mail, etc. were developed by single developers, or small cadres of local developers. Which again, is a testament to the M environment and the fact that the source code is viewable, and therefore local developers can figure out how to seamlessly integrate their products with the main HIS. It is also a testament to the entrepreneurial spirit that exists at some field facilities that support local development with $$. But, if you've been following recent trends inside the VA, it has been biased towards discouraging local development, except for some rare exceptions. I hope the new service oriented architecture lives up to your expectations for it, and that it does not make it more difficult for local developers to service their customers requests. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of GARY MONGER Sent: Wednesday, April 13, 2005 9:39 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es I think easy is a relative thing. For folks with a background or education based on procedural languages, a transition to another procedural language may be much easier than a transition to an OO language. And a transition to a procedural language for the modern child of OO may be much tougher than a move to another OO language. Then there's Lisp and Prolog, each really in its own category. Its more than the language, it's the abstraction the language represents. Lisp is functional and recursive, and you must approach problems accordingly to be proficient. With MUMPS you have strong string manipulation and pattern matching, tremendous overloading of functions and operators, and a different concept of truth. Perl is the only thing I've seen come close. With MUMPS its also the globals, nothing really like that out there in the mainstream. You solve problems a different way when you have sparse arrays. With VistA, its Fileman. VistA data structure is a big step away from your typical MUMPS system, and it takes a while for even a strong M developer to come up to speed. Learning a language is one thing, being proficient in a new abstraction is another and takes time. I'd say a couple years for most people. I think I picked up Java pretty quickly, but I certainly could use a couple years experience before I'd consider myself solid. Anyway, I'm not so sure the new architecture for HEV VistA is such a huge miss. Certainly there are many advantages to M/Cache and to leveraging the M expertise VHA employs. One of the most important being that its how I pay the bills. But I don't need to enumerate the pros of M on this list. I will say that I think the success of DHCP/VistA has more to do with the framework that supports it than anything else. Fileman and Kernel allow so many possibilities. Many great applications are developed locally, or by outside vendors, or IHS, and seamlessly integrate with the national system. I think the Service Oriented Architecture of HEV may provide a similar framework once core services are in place. Anyone can build a service, and it can live on any platform, including Cache. The consumer of the service doesn't know and doesn't care. It seems to me this will allow the kind of development that has made VistA what it is today. It also seems to me that the platform most likely to support rapid development of new services is the cache system where the data already lives. Rehosting VistA applications is a tough task. Its going to take a long time, long enough for quite a lot of other things to be developed. (now donning flame proof suit) Maybe the new HEV VistA won't be such a bad thing after all. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 13, 2005 6:01 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es I think M is easier to learn than many computer languages. Certainly easier than ADA, and probably easier than Java, or Delphi/Pascal. The complex part about becoming a truly proficient Vista programmer is the shear size of it, under the hood. We're talking 12,000 files, 60,000 fields, and maybe 100,000 routines. Not all well-documented, and done in many different programming styles. Old style, new style, structured, unstructured, single-letter variable names, meaningful variable names. The toughest programming job in Vista is not writing new programs, but modifying existing programs and files in a way that does not cause unexpected side-effects, because things can be so intertwined, and not well-documented, under the hood. The thing I would have liked to have seen more of, as I've watched and participated (in a small way)in the evolution of Vista over the past 14 years, is more encapsulation, more api's
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
What I don't understand is that the VA has a national license with Microsoft to use any and all their products. If it truly is any relational database, who spent money on Oracle when SQL Server is free to use already? Sounds political to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steven mcphelan Sent: Thursday, April 14, 2005 8:26 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Very well stated. Nancy had also responded to this thread. She said ...It is the attempt to move VistA from Cache M based on to an Oracle like database... Let's agree with the VA on the use of terms. They claim that the rehosting is not exclusive to Oracle. Rob's term is relational database. I had asked the specific question as to what did he mean by relational, SQL compliant? He said yes. The fact that the VA is standardizing some of its enterprise wise solutions to the Oracle platform is strictly a business decision that they have made given their particular circumstances. So to constantly state that the VA is moving from M to Oracle can be perceived as prejudicial and inaccurate. Can we all agree to stop using terms like Oracle like database to a more correct analogy which would be something like SQL compliant database. Many people seeing the term Oracle may have an initial negative reaction because of the perceived costs involved. I am taking Rob's word as accurate and that the rehosted solution will run on any SQL database and not specifically on Oracle. However, I will believe when I see it. But the VA will have the proof in the pudding is some respects. The VA's HDR project will have the grand-daddy of all medical record databases residing in Austin in an Oracle database. But they will also have regional HDRs. Intersystems has already been awarded that contract to provide the relational database engine for the regional HDRs. - Original Message - From: GARY MONGER [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Wednesday, April 13, 2005 10:38 PM Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es I think easy is a relative thing. For folks with a background or education based on procedural languages, a transition to another procedural language may be much easier than a transition to an OO language. And a transition to a procedural language for the modern child of OO may be much tougher than a move to another OO language. Then there's Lisp and Prolog, each really in its own category. Its more than the language, it's the abstraction the language represents. Lisp is functional and recursive, and you must approach problems accordingly to be proficient. With MUMPS you have strong string manipulation and pattern matching, tremendous overloading of functions and operators, and a different concept of truth. Perl is the only thing I've seen come close. With MUMPS its also the globals, nothing really like that out there in the mainstream. You solve problems a different way when you have sparse arrays. With VistA, its Fileman. VistA data structure is a big step away from your typical MUMPS system, and it takes a while for even a strong M developer to come up to speed. Learning a language is one thing, being proficient in a new abstraction is another and takes time. I'd say a couple years for most people. I think I picked up Java pretty quickly, but I certainly could use a couple years experience before I'd consider myself solid. Anyway, I'm not so sure the new architecture for HEV VistA is such a huge miss. Certainly there are many advantages to M/Cache and to leveraging the M expertise VHA employs. One of the most important being that its how I pay the bills. But I don't need to enumerate the pros of M on this list. I will say that I think the success of DHCP/VistA has more to do with the framework that supports it than anything else. Fileman and Kernel allow so many possibilities. Many great applications are developed locally, or by outside vendors, or IHS, and seamlessly integrate with the national system. I think the Service Oriented Architecture of HEV may provide a similar framework once core services are in place. Anyone can build a service, and it can live on any platform, including Cache. The consumer of the service doesn't know and doesn't care. It seems to me this will allow the kind of development that has made VistA what it is today. It also seems to me that the platform most likely to support rapid development of new services is the cache system where the data already lives. Rehosting VistA applications is a tough task. Its going to take a long time, long enough for quite a lot of other things to be developed. (now donning flame proof suit) Maybe the new HEV VistA won't be such a bad thing after all. -Original Message- From: [EMAIL PROTECTED
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
My understanding is that they are going to be using a relational database that Cache supposedly has in it ?? for now and ultimately the idea is that it should work with any relational database such as MySQL, etc. Note that I stated that it was an Oracle LIKE database. (Steve pointed out that this might not be the best choice of words. Oracle, the 1000 lb. gorilla, is something many people will have heard about and thus will recognize when relation database may mean nothing to them, which is why I chose the simile.) I persist in doubting that the speed of a relational database based system can match that of an M based system no matter who supplies it. In fact, I wonder what the underlying code for the Cache database is written in. Could it be an M based database with restrictions on how it can be populated? Oracle, from what I have heard, will be the basis of the national data repository. I could be all wet about any or all of this, however. I am just piecing together things I have heard at meetings or read in the press, etc. On Thursday 14 April 2005 10:44 am, David Sommers wrote: What I don't understand is that the VA has a national license with Microsoft to use any and all their products. If it truly is any relational database, who spent money on Oracle when SQL Server is free to use already? Sounds political to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of steven mcphelan Sent: Thursday, April 14, 2005 8:26 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Very well stated. Nancy had also responded to this thread. She said ...It is the attempt to move VistA from Cache M based on to an Oracle like database... Let's agree with the VA on the use of terms. They claim that the rehosting is not exclusive to Oracle. Rob's term is relational database. I had asked the specific question as to what did he mean by relational, SQL compliant? He said yes. The fact that the VA is standardizing some of its enterprise wise solutions to the Oracle platform is strictly a business decision that they have made given their particular circumstances. So to constantly state that the VA is moving from M to Oracle can be perceived as prejudicial and inaccurate. Can we all agree to stop using terms like Oracle like database to a more correct analogy which would be something like SQL compliant database. Many people seeing the term Oracle may have an initial negative reaction because of the perceived costs involved. I am taking Rob's word as accurate and that the rehosted solution will run on any SQL database and not specifically on Oracle. However, I will believe when I see it. But the VA will have the proof in the pudding is some respects. The VA's HDR project will have the grand-daddy of all medical record databases residing in Austin in an Oracle database. But they will also have regional HDRs. Intersystems has already been awarded that contract to provide the relational database engine for the regional HDRs. - Original Message - From: GARY MONGER [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Wednesday, April 13, 2005 10:38 PM Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es I think easy is a relative thing. For folks with a background or education based on procedural languages, a transition to another procedural language may be much easier than a transition to an OO language. And a transition to a procedural language for the modern child of OO may be much tougher than a move to another OO language. Then there's Lisp and Prolog, each really in its own category. Its more than the language, it's the abstraction the language represents. Lisp is functional and recursive, and you must approach problems accordingly to be proficient. With MUMPS you have strong string manipulation and pattern matching, tremendous overloading of functions and operators, and a different concept of truth. Perl is the only thing I've seen come close. With MUMPS its also the globals, nothing really like that out there in the mainstream. You solve problems a different way when you have sparse arrays. With VistA, its Fileman. VistA data structure is a big step away from your typical MUMPS system, and it takes a while for even a strong M developer to come up to speed. Learning a language is one thing, being proficient in a new abstraction is another and takes time. I'd say a couple years for most people. I think I picked up Java pretty quickly, but I certainly could use a couple years experience before I'd consider myself solid. Anyway, I'm not so sure the new architecture for HEV VistA is such a huge miss. Certainly there are many advantages to M/Cache and to leveraging
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
From: Nancy Anthracite [EMAIL PROTECTED] Reply-To: hardhats-members@lists.sourceforge.net Date: Thu, 14 Apr 2005 17:00:12 -0400 To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es My understanding is that they are going to be using a relational database that Cache supposedly has in it ?? The CORE data system in Caché is the familiar global system descended from MUMPS. Caché exposes this core data storage system in several different ways. The procedure being executed can select the method of exposing data. One of these ways is an SQL compliant system. This 'layering' of a method of access over some other specific data storage system is not unusual. If you peel away the method of exposing data in Oracle, look under the hood, you will likely find that there too the data storage system is not intrinsically SQL, or relational. Caché offers the choice of access method that can be exercised according to the needs of each specific situation. In Caché an application can access the data storage system as a though it is a relational database or directly as global structures. The tradeoff is between speedy, powerful accesses or more general, slower accesses. Caché is unusual in the database world in that it offers the user the choice of high level SQL based access methods and at the same time, also offer direct access to the underlying data storage system. Other relational systems are closed to access methods that are more direct, a shortcoming many don't really recognize as such. for now and ultimately the idea is that it should work with any relational database such as MySQL, etc. Note that I stated that it was an Oracle LIKE database. (Steve pointed out that this might not be the best choice of words. Oracle, the 1000 lb. gorilla, is something many people will have heard about and thus will recognize when relation database may mean nothing to them, which is why I chose the simile.) I persist in doubting that the speed of a relational database based system can match that of an M based system no matter who supplies it. In fact, I wonder what the underlying code for the Cache database is written in. Could it be an M based database with restrictions on how it can be populated? Oracle, from what I have heard, will be the basis of the national data repository. I could be all wet about any or all of this, however. I am just piecing together things I have heard at meetings or read in the press, etc. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Back to Donald E. Knuth eh? One would think that by now... Guess there isn't much new under the Sun. ..tx/t -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Thursday, April 14, 2005 6:14 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Of course, when you really get down to basics, it's all B-trees, whether you're talking about MUMPS or your favorite RDBMS. s-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Actually there is. Most MUMPS implementations are multi-way B-trees. Real true B-trees suffer badly in real-life, nearly every action is a pointer split. The performance of MUMPS sparse arrays is in the shared buffer pools and broad pointer structures that get you to any data location in a 1,000,000 element database in 7 physical disk accesses or less. Best wishes; Chris - Original Message - From: Thurman Pedigo [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Thursday, April 14, 2005 7:26 PM Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Back to Donald E. Knuth eh? One would think that by now... Guess there isn't much new under the Sun. ..tx/t -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Thursday, April 14, 2005 6:14 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Of course, when you really get down to basics, it's all B-trees, whether you're talking about MUMPS or your favorite RDBMS. s-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
For us new Mumpies could you explain what B-trees are and what is apointer split? ---Original Message--- From: Chris Richardson Date: 04/14/05 23:23:45 To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Actually there is. Most MUMPS implementations are multi-way B-trees.Real true B-trees suffer badly in real-life, nearly every action is a pointer split.The performance of MUMPS sparse arrays is in the shared buffer pools and broad pointer structures that get you to any data location in a 1,000,000 element database in 7 physical disk accesses or less. Best wishes;Chris - Original Message - From: "Thurman Pedigo" [EMAIL PROTECTED] To: hardhats-members@lists.sourceforge.net Sent: Thursday, April 14, 2005 7:26 PM Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Back to Donald E. Knuth eh? One would think that by now... Guess there isn't much new under the Sun. ..tx/t -Original Message- From: [EMAIL PROTECTED] [mailto:hardhats- [EMAIL PROTECTED]] On Behalf Of Greg Woodhouse Sent: Thursday, April 14, 2005 6:14 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es Of course, when you really get down to basics, it's all B-trees, whether you're talking about MUMPS or your favorite RDBMS. s-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
These are references to the internal structure
ofa Mumps database (globals) andit isnot necessary to
understand these in order to program Mumps.
Look here for definitions of b-tree, balanced
tree, binary tree:
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?balanced+tree
If you google "balanced tree" you will find lots
of explanations. Ones with picture are probably the most helpful, like: www.cs.oberlin.edu/classes/dragn/labs/avl/avl5.html
Most Mumps implementations use some form of
b-tree (there are many), BUT theMumps global structure does not define a
b-tree. There still exist implementations that do not use b-trees.
Fortunately, you will probably never encounter one! The global structure
is a simple hierarchical database.
Block splits (not pointer splits) occur when
there isn't enough room to insert data into the appropriate block so some of the
data in that block must be moved to a new (unused) block -- thereby "splitting"
the old block in two. The pointers which formlinked lists of blocks
must be adjusted to incorporate the new block.
- Original Message -
From:
Ron
Ponto
To: hardhats-members@lists.sourceforge.net
Sent: Thursday, April 14, 2005 11:29
PM
Subject: Re: [Hardhats-members] BIG NEWS
re HealtheVet- St. Petersburg Tim es
For us new Mumpies could you explain what B-trees are and what is
apointer split?
---Original
Message---
From: Chris Richardson
Date: 04/14/05
23:23:45
To: hardhats-members@lists.sourceforge.net
Subject: Re:
[Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim
es
Actually there is.
Most MUMPS implementations are multi-way
B-trees.Real true B-trees
suffer badly in real-life, nearly every action is a pointer
split.The
performance of MUMPS sparse arrays is in the shared buffer pools
and broad
pointer structures that get you to any data location in a 1,000,000
element
database in 7 physical disk accesses or less.
Best wishes;Chris
- Original Message -
From: "Thurman Pedigo" [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Thursday, April 14, 2005 7:26 PM
Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St.
Petersburg Tim
es
Back to Donald E. Knuth eh? One would think that by now...
Guess there
isn't
much new under the Sun. ..tx/t
-Original Message-
From: [EMAIL PROTECTED]
[mailto:hardhats-
[EMAIL PROTECTED]]
On Behalf Of Greg Woodhouse
Sent: Thursday, April 14, 2005 6:14 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet-
St. Petersburg
Tim
es
Of course, when you really get down to basics, it's all
B-trees,
whether you're talking about MUMPS or your favorite
RDBMS.
s-members
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products
from real users.
Discover which products truly live up to the hype. Start
reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from
real users.
Discover which products truly live up to the hype. Start reading
now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
Does anyone know where I can obtain a copy of the original report. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Joseph ConnSent: Wednesday, April 13, 2005 7:06 AMTo: hardhats-members@lists.sourceforge.netSubject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg TimesOh, boy! Wish someone had leaked that report to me!! [EMAIL PROTECTED] 04/13/05 11:53AM VA faces another computer problemBy PAUL DE LA GARZA and STEPHEN NOHLGREN Published April 13, 2005 A report done for the administration suggests that the VA's multibillion-dollar plan to upgrade its system is "not realistic."A $3.5-billion computer overhaul at veterans hospitals across the country is poised to fail unless the Department of Veterans Affairs makes drastic changes, according to a closely guarded government study obtained by the St. Petersburg Times .http://www.sptimes.com/2005/04/13/Worldandnation/VA_faces_another_comp.shtml-- Nancy Anthracite---SF email is sponsored by - The IT Product GuideRead honest candid reviews on hundreds of IT Products from real users.Discover which products truly live up to the hype. Start reading now.http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click___Hardhats-members mailing listHardhats-members@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
John: Few really understand the VistA Enterprise View, Life Cycle Principles that the hardhats evolved while CMU SEI was evolving the Software Engineering Body of Knowledge (SWEBOK) which we wwere all part of when the concepts were mutually discussed in Sept 1998 at an MDC meeting. We just have to get that story told and the hardhats who made the VistA possible clearly recognized - and there are many, so we have lots f informing to do. On Wed, 13 Apr 2005, Clemens, John wrote: It has evolved over 25 years and was created piecemeal by VA doctors, nurses and technology wonks who swapped ideas from hospital to hospital. Oh, really? John Clemens IT Specialist, Software IRMS Veterans Affairs Medical Center (662) 4150 Clement Street San Francisco, CA 94121 Phone: 415.221.4810 x4540 (Tu,Wed,Thu) Digital Pager:415.303.0388 ( Mon,Fri) Fax: 415.750.2177 [EMAIL PROTECTED] _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseph Conn Sent: Wednesday, April 13, 2005 10:06 AM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Times Oh, boy! Wish someone had leaked that report to me!! [EMAIL PROTECTED] 04/13/05 11:53AM VA faces another computer problem By PAUL DE LA GARZA and STEPHEN NOHLGREN Published April 13, 2005 A report done for the administration suggests that the VA's multibillion-dollar plan to upgrade its system is not realistic. A $3.5-billion computer overhaul at veterans hospitals across the country is poised to fail unless the Department of Veterans Affairs makes drastic changes, according to a closely guarded government study obtained by the St. Petersburg Times . http://www.sptimes.com/2005/04/13/Worldandnation/VA_faces_another_comp.shtml -- Nancy Anthracite --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595 http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es
I think easy is a relative thing. For folks with a background or education based on procedural languages, a transition to another procedural language may be much easier than a transition to an OO language. And a transition to a procedural language for the modern child of OO may be much tougher than a move to another OO language. Then there's Lisp and Prolog, each really in its own category. Its more than the language, it's the abstraction the language represents. Lisp is functional and recursive, and you must approach problems accordingly to be proficient. With MUMPS you have strong string manipulation and pattern matching, tremendous overloading of functions and operators, and a different concept of truth. Perl is the only thing I've seen come close. With MUMPS its also the globals, nothing really like that out there in the mainstream. You solve problems a different way when you have sparse arrays. With VistA, its Fileman. VistA data structure is a big step away from your typical MUMPS system, and it takes a while for even a strong M developer to come up to speed. Learning a language is one thing, being proficient in a new abstraction is another and takes time. I'd say a couple years for most people. I think I picked up Java pretty quickly, but I certainly could use a couple years experience before I'd consider myself solid. Anyway, I'm not so sure the new architecture for HEV VistA is such a huge miss. Certainly there are many advantages to M/Cache and to leveraging the M expertise VHA employs. One of the most important being that its how I pay the bills. But I don't need to enumerate the pros of M on this list. I will say that I think the success of DHCP/VistA has more to do with the framework that supports it than anything else. Fileman and Kernel allow so many possibilities. Many great applications are developed locally, or by outside vendors, or IHS, and seamlessly integrate with the national system. I think the Service Oriented Architecture of HEV may provide a similar framework once core services are in place. Anyone can build a service, and it can live on any platform, including Cache. The consumer of the service doesn't know and doesn't care. It seems to me this will allow the kind of development that has made VistA what it is today. It also seems to me that the platform most likely to support rapid development of new services is the cache system where the data already lives. Rehosting VistA applications is a tough task. Its going to take a long time, long enough for quite a lot of other things to be developed. (now donning flame proof suit) Maybe the new HEV VistA won't be such a bad thing after all. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 13, 2005 6:01 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Tim es I think M is easier to learn than many computer languages. Certainly easier than ADA, and probably easier than Java, or Delphi/Pascal. The complex part about becoming a truly proficient Vista programmer is the shear size of it, under the hood. We're talking 12,000 files, 60,000 fields, and maybe 100,000 routines. Not all well-documented, and done in many different programming styles. Old style, new style, structured, unstructured, single-letter variable names, meaningful variable names. The toughest programming job in Vista is not writing new programs, but modifying existing programs and files in a way that does not cause unexpected side-effects, because things can be so intertwined, and not well-documented, under the hood. The thing I would have liked to have seen more of, as I've watched and participated (in a small way)in the evolution of Vista over the past 14 years, is more encapsulation, more api's, and more programmer's documentation. But, all in all I think M is an excellent database platform, and I would prefer to see the VA evolve the current product, rather than move to something completely different, for a main HIS. I think they should look at commercial ancillary systems, like: cardiology, GI, eye-care, PFT, Dialysis, etc. and make it easier to integrate them with Vista, but keep and evolve the core HIS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gordon Moreshead Sent: Wednesday, April 13, 2005 3:59 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] BIG NEWS re HealtheVet- St. Petersburg Times Nancy, That appears to me to be a highly perceptive take on the situation that includes considerable truth as well. I would second your observations and perceptions. Gordon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy Anthracite Sent: Wednesday, April 13, 2005 1:53 PM To: hardhats-members@lists.sourceforge.net Subject: Re: [Hardhats-members] BIG NEWS re HealtheVet
