Yes, it is going to be interesting to see what happens if many offices
adopt VistAOffice, and don't have the support that is standard in a
hospital setting.
I understand your feeling of staying well away from issues that caused
problems in the past.
I'll check with Bhaskar whether or not there is any risk in storing
non-printable characters in a global. I did some testing and filled a
global with $char(0) and it didn't seem to loose them, or cause the
underlying string to terminate (i.e. null-terminated strings).
Actually I would consider it a bug of the M implementation if a user
could put a character into a global that would cause problems on
retrieval etc. I don't know about this issue in subscripts. I
suspect that it would be difficult to figure out what character had
been put in there, and thus be difficult to get back out. But you
could $order through it to get the hidden subscript name and then
delete the node.
But then things don't always work like they are supposed to, do they?
Thanks for your feedback.
Kevin
On 8/21/05, smcphelan <[EMAIL PROTECTED]> wrote:
> Non-printable ASCII characters in either the data or the global subscripts
> can and has caused problem depending upon the M implementation and the
> vehicle you are using to access the M account. If your data is on a global
> node that only your specific application will touch, then you may get by
> with it. But if you have to use any of the M vendor's tools, you may
> encounter difficulty. I have had direct experience in both cases where
> non-printable control codes were in the subscripts and data. I had a DSM
> system once that was down for almost a day because of one control character
> in one subscript in one global. Even DSM's FIX utility could not fix it.
> We had to have DEC dial in and fix it. Of course that was years ago and I
> am sure things are better now. But I, for one, am not interested in
> anything which intentionally stores non-printable ASCII characters. There
> are a few exceptions. I have never had show stopper problems with ASCII
> 7,9,10,11, and 13 as well as some others.
>
> Without having a DEC support contract, I do not know what we would have
> done. I guess we could have paid hourly rates to DEC. You go through a
> few
> experiences like this actually experiencing major impact upon your facility
> providing patient care and possibly jeopardizing a patient's well being,
> you
> will never want to be in the situation where you do not have some sort of
> maintenance support immediately available. Small doctor offices maybe can.
> But I cannot imagine any hospital going without all the support contracts
> in
> place.
>
> ----- Original Message -----
> From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, August 21, 2005 9:05 AM
> Subject: [Hardhats-members] Re: Is $$GTF~%ZISH() binary friendly?
>
>
> A more fundamental question is whether M globals are binary friendly?
> I know that the underlying data is stored as strings. So would the
> storage of a $char(0) crash the data?
>
> I just tested this, and it doesn't. Thus I could store the actual
> binary data in the global instead of converting each byte to a hex
> equivalent and storing that.
>
> I could therefore read in 256 bytes at a time and store the data
> directly into the global. It would be much faster.
>
> But since my goal is to use the RPCBroker functionality that can
> transfer globals, I will next need to investigate what would happen if
> the global contained a control character (i.e. bytes 0-31).
>
> I think that when a WP field is transferred to Delphi via RPCBroker,
> it is put into a TMemo field. Each of the lines in a TMemo is a
> zero-terminated string (I think), so binary data might run into
> problems there.
>
> I'll have to think more about this, but any input would be appreciated.
>
> Kevin
>
>
> On 8/21/05, Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> > Here is the code. I will also attach it incase wrapping ruins it here...
> >
> >
> > ;"TMG BIN <-->GBL FUNCTION
> > ;"Kevin Toppenberg MD
> > ;"GNU General Public License (GPL) applies
> > ;"8-20-2005
> >
> > ;"=======================================================================
> > ;" API -- Public Functions.
> > ;"=======================================================================
> > ;"$$BIN2GBL^TMGBINF(path,filename,globalRef,incSubscr)
> > ;"$$GBL2BIN^TMGBINF(globalRef,incSubscr,path,filename)
> >
> > ;"=======================================================================
> > ;"PRIVATE API FUNCTIONS
> > ;"=======================================================================
> >
> >
> >
> > ;"=======================================================================
> > BIN2GBL(path,filename,globalRef,incSubscr)
> > ;"Purpose: To load a binary file from the host filesystem into
> > a WP field, storing
> > ;" the composit bytes as ascii hex codes.
> > ;"Input: path -- full path, up to but not including the
> > filename (required)
> > ;" filename -- name of the file to open (required)
> > ;" globalRef-- Global reference to WRITE the host
> > binary file to, in fully resolved
> > ;" (closed root) format. This
> > function does not kill the global before
> > ;" writing to it. (required)
> > ;" Note:
> > ;" At least one subscript must be
> > numeric. This will be the incrementing
> > ;" subscript (i.e. the subscript
> > that $$BIN2WP^TMGBINWP will increment
> > ;" to store each new global node).
> > This subscript need not be the final
> > ;" subscript. For example, to load
> > into a WORD PROCESSING field, the
> > ;" incrementing node is the
> > second-to-last subscript; the final subscript
> > ;" is always zero.
> > ;" incSubscr-- (required) Identifies the incrementing
> > subscript level. For example, if you
> > ;" pass ^TMP(115,1,1,0) as the
> > global_ref parameter and pass 3 as the
> > ;" inc_subscr parameter, $$BIN2GBL
> > will increment the third subscript, such
> > ;" as ^TMP(115,1,x), but will WRITE
> > notes at the full global reference, such
> > ;" as ^TMP(115,1,x,0).
> > ;"Result: 1=success, 0=failure
> > ;"
> > ;"Note: Each line of the global will contain up to 128 bytes
> > (256 characters)
> > ;" (2 ascii hex characters = 1 source byte)
> > ;"Example:
> > ;"
> > ^TMP(115,1,1,0)="A12C4F12E2791D9723C3297D3C30B73C1532A1...(continues
> > to 256 characters)"
> > ;"
> > ^TMP(115,1,2,0)="91D9723C3297D314ADF31B85F41A12C4F12E27...(continues
> > to 256 characters)"
> > ;"
> > ^TMP(115,1,3,0)="3A12C4F12E271B85F4C2ED9723C3297D314ADF...(continues
> > to 256 characters)"
> > ;"
> > ^TMP(115,1,4,0)="85F73C1532AA12C4F12E2791D9723C3297D314...(continues
> > to 256 characters)"
> > ;" ^TMP(115,1,5,0)="61A85C30B73C1532AA12C4F12E2791D972" <--
> > not padded with terminal zeros
> >
> > new result set result=0 ;"default to failure
> > new handle set handle="TMGHANDLE"
> > new abort set abort=0
> > new byteIn
> > new $ETRAP
> > new oneLine set oneLine=""
> > new curRef set curRef=globalRef
> >
> > set path=$$DEFDIR^%ZISH($get(path))
> > do OPEN^%ZISH(handle,path,filename,"R")
> > if POP goto B2GDone
> > set $ETRAP="set abort=1,$ECODE="""" quit"
> > use IO
> > for do quit:($ZEOF)!(abort=1)!(byteIn=-1)
> > . read *byteIn:2
> > . if (byteIn=-1) quit
> > . set oneLine=oneLine_$$HEXCHR(byteIn,2)
> > . if $length(oneLine)>255 do
> > . . set @curRef=oneLine
> > . . set curRef=$$NEXTNODE(curRef,incSubscr)
> > . . set oneLine=""
> > if (oneLine'="")&(abort=0) do
> > . set @curRef=oneLine
> > . set oneLine=""
> >
> > if (abort'=1) set result=1 ;"SUCCESS
> > do CLOSE^%ZISH(handle)
> >
> >
> > B2GDone
> > quit result
> >
> >
> > NEXTNODE(curRef,incSubscr)
> > ;"Purpose: to take a global reference, and increment the node
> > specified by incSubscr
> > ;"Input: curRef -- The reference to alter, e.g.
> > '^TMP(115,1,4,0)'
> > ;" incSubscr--The node to alter, e.g.
> > ;" 1-->^TMG(x,1,4,0) x would
> > be incremented
> > ;" 2-->^TMG(115,x,4,0) x would be
> > incremented
> > ;" 3-->^TMG(115,1,x,0) x would be
> > incremented
> > ;" 4-->^TMG(115,1,4,x) x would be
> > incremented
> > ;"Note: the node that incSubscr references should be numeric
> > (i.e. not a name)
> > ;" otherwise the alpha node will be treated as a 0
> > ;"result: returns the new reference
> >
> > new i,result
> >
> > set result=$qsubscript(curRef,0)_"("
> > for i=1:1:$qlength(curRef) do
> > . new node
> > . if i'=1 set result=result_","
> > . set node=$qsubscript(curRef,i)
> > . if i=incSubscr set node=node+1
> > . if (node'=+node) set node=""""_node_""""
> > . set result=result_node
> > set result=result_")"
> >
> > quit result
> >
> >
> > HEXCHR(n,digits)
> > ;"Purpose: convert n to hex characters
> > ;"Input: n -- the number to convert
> > ;" digits: (optional) number of digits in output.
> > Leading 0's padded to
> > ;" front of answer to set number of digits.
> > ;" e.g. if answer is "A", then
> > ;" 2 -> mandates at least 2 digits ("0A")
> > ;" 3->3 digits ("00A")
> >
> > new lo
> > new result set result=""
> > new ch
> > set digits=$get(digits,1)
> >
> > for do quit:(n=0)
> > . set lo=n#16
> > . if (lo<10) set ch=+lo
> > . else set ch=$char(55+lo)
> > . set result=ch_result
> > . set n=n\16
> >
> > for quit:($length(result)>(digits-1)) do
> > . set digits=digits-1
> > . set result="0"_result
> >
> > quit result
> >
> >
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Hardhats-members mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/hardhats-members
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
