I got the same results as Kevin, I could not get to the page.
- Original Message -
From: Thurman Pedigo [EMAIL PROTECTED]
To: hardhats-members@lists.sourceforge.net
Sent: Saturday, August 20, 2005 2:29 PM
Subject: RE: [Hardhats-members] Rules for the List
I checked - short, succinct,
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
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.
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,
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
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
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
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
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
- 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 changed.
I
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...
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 sure.
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
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
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
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
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 setting up
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 to the
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
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
would
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
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
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)
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
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
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,
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 is
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
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
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
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
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
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
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
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]
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
GTMS DUZ=`138
%GTM-E-EXPR, Expression expected but not found
S DUZ=`138
^-
GTM
Any suggestions?
Thanks
Usha
-
36 matches
Mail list logo
