Hi
I did not notice the '`' before the DUZ 138 before. Now when I try
to set the DUZ to the one mentioned I get the following
GTM>S DUZ=`138
%GTM-E-EXPR, Expression expected but not found
S DUZ=`138
^-
GTM>
Any suggestions?
Thanks
Usha
- Or
I can assure you that the SACC would like nothing more than to avoid
placing unnecessary burdens on the user/programmer. The issue here is
whether relaxing limits like the restriction on string lengths would
break existing applications.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Design quali
Kevin;
I'm not sure which MUMPS engine you arte running, but I believe you have
to turn off IO termination on control characters. Looks like the fixed
reads are being terminated early.
Chris
- Original Message -
From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
The key word (not the keyword) here is "encoded". Fileman actually
provides utilities for hexadecimal encoding that I've found useful on
more than one occasion. There are really two issues here: whether the
M implementation can handle binary data (not necessarily), and
whether applications
IANAL (I am not a lawyer), but forbidding links to copyrighted
material would pretty much rule out linking to ANYTHING. I would say
the answer is generally no, and that hyperlinks should, in most
cases, be treated as references (e.g., in footnotes or endnotes).
===
Gregory Woodhouse
[EMAIL P
Good question. Generally speaking job announcements posted to lists
not specifically intended for that purpose are considered spam. I
don't know that this is what Greg K. had in mind, it's a matter for
us to discuss.
For what it's worth, it is common practice to have separate mailing
list
Kevin;
The point I was making was that there are a lot of assumptions being made
about the environment, MUMPS has been abstraction which avoids a lot of the
assumptions. A character can be 8, 16 or 32 bits. To MUMPS, they are just
characters. The standard was written to try to avoid the bit
Rsync is part of the SAMBA project. So - it essentially uses SMB
(Windows file sharing). Your initial comment was that you didn't want
to use file sharing because it couldn't be easily tunneled over RPC.
I think the recommendation was made out of context.
The context is: I want to tunnel a file
Let's be practical. There seem to be only a few M environments. Are
any of them using 6 bit bytes etc? Do any of the underlying file
systems server other than an 8 bit byte when asked to read one unit
(byte) from a file?
Yes, there are widecharacter strings, but the underlying filesystem
still
That I can't answer.
No pipe? No File Pipe?
Ruben
On Sun, 2005-08-21 at 19:20 -0400, Kevin Toppenberg wrote:
> I am already using rsync to upload my backup data to our Windows
> server, and include VistA data with our financial data backup.
>
> But I still don't see how I would incorporate that
I am already using rsync to upload my backup data to our Windows
server, and include VistA data with our financial data backup.
But I still don't see how I would incorporate that into an image
viewer that needs to request a specific file from a server.
Kevin
On 8/21/05, Ruben Safir <[EMAIL PROTE
On Sun, 2005-08-21 at 18:50 -0400, David Sommers wrote:
> Rsync is a tool used to synchronize or replicate files. In terms of
> sending a single file from server to client upon request, a tool is
> not
> recommended but a protocol. Whether it be Secure FTP, BitTorrent,
> SMB,
> or the like.
This
Kevin, it may be easier to encode the binary into a subset of ASCII/ANSI
that is supported by M "string". There are many definitions on what a
string *is* depending on the language and system - but I'm sure you can
find a codeset that fits. Base64 in the worse case.
/David.
David Sommers, Arch
Rsync is a tool used to synchronize or replicate files. In terms of
sending a single file from server to client upon request, a tool is not
recommended but a protocol. Whether it be Secure FTP, BitTorrent, SMB,
or the like.
/David.
David Sommers, Architect | Dialog Medical
-Original Mes
On Sun, 2005-08-21 at 12:57 -0700, Chris Richardson wrote:
> Ah, but how big is a character? MUMPS deals in characters reguardless of
> the number of octets required to represent it.
>
>1Octet = 8 bits
>
>Ascii - 1 octet/character
>Unicode, Kanji,Katakana,etc - 2 octets/character
>
Ah, but how big is a character? MUMPS deals in characters reguardless of
the number of octets required to represent it.
1Octet = 8 bits
Ascii - 1 octet/character
Unicode, Kanji,Katakana,etc - 2 octets/character
ISO-10646 - 4octets/character
Then there were 36 bit words (6 (6-bit) c
On Sun, 2005-08-21 at 15:13 -0400, smcphelan wrote:
> Here, here. Chris also stated this. ANSI standard M is not really designed
> to handle binary data. This is one reason Intersystems added extensions (if
> you wish to call it that). But then you are bound to a specific M vendor's
> implement
The difference was in the PACKAGE PREFIX field value. I do not remember what
was the PACKAGE PREFIX value for the "ONCE" entry (I am not at my VistA
system). I set the value for the "ONE TIME" entry PACKAGE PREFIX to "LR"
and it worked. Not sure if changing the "ONCE" entry package prefix value
Kevin;
The point I was making was that there are things that MUMPS does really
well and there are things that it does not perform well at. In such cases,
one needs to use other tools. The endian issue is one of underlying
operating system and hardware architecture. This is an area that MUMP
8. DO NOT spam the list with your advertising message. You will be banned
from the list if you do so.
If a company has a position open for a VistA knowledgeable person, is
placing a job announcement considered SPAM?
12. Do not forward copyrighted material or information you do not have
permissi
FreeSWan is just a VPN standard implementation.
Ruben
On Sun, 2005-08-21 at 14:19 -0400, Kevin Toppenberg wrote:
> Thanks Ruben,
>
> Are any of these options something that could be put into a $Windoze
> client so that it could securely request images from server, or would
> it involve settin
Is your browser encoding the "_" in "mailing_list"?
===
Gregory Woodhouse
[EMAIL PROTECTED]
"A hero is no braver than an ordinary
man, but he is brave five minutes longer."
-- Ralph Waldo Emerson
On Aug 21, 2005, at 4:11 AM, smcphelan wrote:
I got the same results as Kevin, I could not get t
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
Today the linked worked without any changes to the browser. I do not know
why it did not work the other day.
- Original Message -
From: "Gregory Woodhouse" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 21, 2005 2:27 PM
Subject: Re: [Hardhats-members] Rules for the List
Here, here. Chris also stated this. ANSI standard M is not really designed
to handle binary data. This is one reason Intersystems added extensions (if
you wish to call it that). But then you are bound to a specific M vendor's
implementation, in this case, Cache.
If you are going to stay strict
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
On Sun, 2005-08-21 at 14:19 -0400, Kevin Toppenberg wrote:
> Thanks Ruben,
>
> Are any of these options something that could be put into a $Windoze
> client so that it could securely request images from server, or would
> it involve setting up an environment for the client to run int?
>
I'm not
Chris,
I am having trouble getting a buffered read to work.
GTM>set path="/tmp/"
GTM>set fname="killthis"
GTM>do OPEN^%ZISH("Handle",path,fname,"R")
GTM>w POP
0
GTM>F Q:($ZEOF) U IO:(NOTERMINATOR) R X#255:5 U $P W $L(X),"; "
51; 17; 21; 24; 51; 52; 56; 27; 51; 38; 0;
%GTM-E-IOEOF, Attempt to re
Thanks Ruben,
Are any of these options something that could be put into a $Windoze
client so that it could securely request images from server, or would
it involve setting up an environment for the client to run int?
Thanks
Kevin
On 8/21/05, Ruben Safir <[EMAIL PROTECTED]> wrote:
> On Sun, 2005
On Sun, 2005-08-21 at 13:42 -0400, Kevin Toppenberg wrote:
> Hmm... if I had an ftp server, I would want to be sure that only those
> authorized to request a file were sent the file. Perhaps I need to
> look more into the secure FTP options
rsync through ssh or FreeSWan...
Hmm... if I had an ftp server, I would want to be sure that only those
authorized to request a file were sent the file. Perhaps I need to
look more into the secure FTP options.
I had thought that the server could just load up the file for the
client, and then send it out via RPC. Perhaps its goi
- Original Message -
From: "Kevin Toppenberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, August 21, 2005 12:00 PM
Subject: [Hardhats-members] Re: more M read questions
> Maury,
>
> Thanks for your feedback. I agree that they byte-by-byte approach
> will have to be change
Kevin;
You are working way too hard. Do a buffered read and then use $ASCII to
take it apart one octet at a time. The encoding is much easier than you
have made it. Each octet will be something like this;
N BUF,C,B1,B2,OBUF
S OBUF=""
R BUF#255
F I=1:1:$L(BUF) D
. S C=$ASCII(BUF,
Maury,
Thanks for your feedback. I agree that they byte-by-byte approach
will have to be changed.
I am doing it for a couple of reasons. First, I think it is a severe
limitation of Kernel if it can't read in a binary file.
Second, because I want to allow the server to send CPRS, or other
imagi
Kevin,
You are on the right track. Increasing the number of characters per READ is by
far the most significant thing you can do to speed up your routine. Reading
one character at a time using a star-Read is very slow. Each M implementation
has a way to do binary reads -- ie, a read which doe
Are you making this more difficult that it has to be? (I can't
*imagine* you doing that! :-) )
I don't know about the big/little endian issues. I am not planning to
store two-byte words, so I don't think this comes into play. I will
just store the bytes as they come in the stream.
And I don'
Kevin;
There is only a single data-type in MUMPS, strings. What you are doing
is a fixed length buffer read of characters (real characters or binary
data). You are opening up a big bag of issues which the MDC argued over for
decades. If you are talking about binary, are you talking about big
The read command in M seems to be the most complicated function it has.
I am trying to perform a binary read. I do it this way:
read blockIn#255
The problem is that as I debug the code, $length(blockIn) does not always=255.
I think this is because sometimes the stream contains a "terminator"
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 b
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.
;"==
http://www.hardhats.org/mailing_list.html#RULES
Still works for me - both click and paste.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:hardhats-
> [EMAIL PROTECTED] On Behalf Of Greg Kreis
> Sent: Saturday, August 20, 2005 6:57 AM
> To: hardhats-members@lists.sourceforge.net
>
I got the same results as Kevin, I could not get to the page.
- Original Message -
From: "Thurman Pedigo" <[EMAIL PROTECTED]>
To:
Sent: Saturday, August 20, 2005 2:29 PM
Subject: RE: [Hardhats-members] Rules for the List
> I checked - short, succinct, and useful.
>
> I wouldn't mind se
42 matches
Mail list logo
