|
HI Joseph, I am currently in the process of evaluating FOIA VistA on GT.M. I have a great deal of experience with GT.M, though I'm a bit rusty with VistA. I ran into a snag with e-mail, which of course is also using a socket connection. I found two things that needed to be changed to get e-mail to work. One was an actual code problem (fix shown below), and the other was in the in the COMMUNICATIONS PROTOCOL file (also shown below). As I get more info, I'll certainly pass it along. If you have anything to add, I would greatly appreciate hearing about it. In the routine ^%ZOSV, I added the items highlighted in red. The RETURN function is used to issue an O/S command and grab the results. Since it opens/closes a file and it does not store $I before doing so, when the function completes as originally coded, it sometimes leaves $I with the wrong value. If the HL7 interface is calling out to the O/S, this fix could address at least part of the problem. RETURN(%COMMAND) ; ** Private Entry Point: execute a shell command & return the resulting value ** ; ; %COMMAND is the string value of the Linux command ; APON - need to save current I/O device so it will be in use when the file is closed N %VALUE,IO S %VALUE="" ; value to return N %FILE S %FILE=$$TEMP_"RET"_$J_".txt" ; temporary results file ZSYSTEM %COMMAND_" > "_%FILE ; execute command & save result S IO=$I O %FILE:(REWIND) U %FILE R:'$ZEOF %VALUE U IO C %FILE:(DELETE) ; fetch value & delete file ; QUIT %VALUE ; return value I made the changes highlighted in red in the COMMUNICATIONS PROTOCOL file. Originally, SEND and REC were being called instead of SNDGTM and RECGTM. If the HL7 interface is using something from the COMMUNICATIONS PROTOCOL file, it may be worth checking to make sure SNDGTM and RECGTM are called instead of SEND and REC. VA FileMan 22.0 Select OPTION: INQUIRE TO FILE ENTRIES OUTPUT FROM WHAT FILE: VOLUME SET// COMMUNICATIONS PROTOCOL Select COMMUNICATIONS PROTOCOL NAME: TCP/IP-MAILMAN ANOTHER ONE: STANDARD CAPTIONED OUTPUT? Yes// (Yes) Include COMPUTED fields: (N/Y/R/B): NO// - No record number (IEN), no Computed Fields NAME: TCP/IP-MAILMAN SEND: D SNDGTM^XMLTCP I $G(XM)["D" S XMTRAN="S: "_$E(XMSG,1,242) D TRAN^XMC1 RECEIVE: D RECGTM^XMLTCP I $G(XM)["D" S XMTRAN="R: "_$E(XMRG,1,242) D TRAN^XMC1 OPEN: S (X,XMLINE,XMLCHAR,XMLER,XMLST,XMNO220)=0,XMLTCP="",XMSTIME=60 CLOSE: K XMLTCP L -^XMBX("TCPCHAN",XMHOST) Q DESCRIPTION: This protocol is for MailMan to use across a TCP/IP channel. Important things to know about this channel: 1. A "!" puts the last written characters into the TCP/IP buffer Alan O'Neill Pathology Data Systems The Johns Hopkins Hospital Baltimore, MD Joseph Puthooran wrote: (Resent as the original mail was witheld since I had sent it from another e-mail address)I wonder if there could be more clarity on the proportion of work done in the task of porting VistA on Cache to Linux & GT.M. Perhaps someone could educate us, lesser mortals, on what was the total work content in the task of porting VistA Cache to OpenVistA/GT.M. Perhaps a classification of the areas of work needed and the work actually done would be very educative. I feel that chunks of work may have been left out. Perhaps someone more knowledgeable could correct me if I am wrong. One positive sign is that Mexico appears to have implemented OpenVistA. But what they have really done is not fully clear. They are not exactly shouting from the housetops. Others are! But there are gnawing issues that are unanswered. The first is that most successful vendors, from Medsphere to Elsie Casugay, seem to work exclusively on Cache. Medsphere was actively involved in the porting and so lack of familiarity or experience with GT.M cannot be an argument. It is sometimes claimed that it is because Cache has a strong branding, or that there a strong customer preference, or are there commissions to the suppliers to work on Cache? I suspect that the real reason is that some of the key functionality of VistA has not been reproduced on the GT.M version. Because having a free database like GT.M enables a significant saving on cost and competitiveness. And we all know that GT.M is as stable and robust a Cache, Secondly I wonder what is the agenda of the exclusive OpenVistA R&D coding worshops. Is it to address some of these issues that were left out at the OpenVistA porting exercise? Thirdly there are issues, which we directly face. My colleague Usha tried unsuccessfully to get an answer to a specific question on Hardhats on the problem of HL7 connectivity from an OpenVistA installation we had done on Suse Linux using the latest Pacific Hui version 3.0. In the case of the Cache implementation of VOE, the TCP/IP listener could be setup, by configuring the logical links, and we could send and receive HL7 messages between two Cache implementations. The same setup procedure does not activate the listener in GT.M. According to the output of Netstat on the VistA server, no service seems to listening on the corresponding port. I would appreciate if someone who has implemented HL7 on OpenVista could come forward rather than make a speculation that it must have been done in Mexico. The reason for my special interest is that those of us who are not experts on VistA but believe in its potential will benefit considerably if the correct status of OpenVistA is known. If there is transparency, we will not need to struggle on issues, which we know have not been addressed and spend our time based on assumptions that are incorrect. I suspect that some of us may be looking in a dark room for a black cat that is not there. Joseph Puthooran Edgeware Technologies (India) Pvt Ltd E-537 Greater Kailash II New Delhi 110048 India E-mail: [EMAIL PROTECTED] Phone: +91-11-55633899 Mobile: +91-9810284528 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members |
_______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
