--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
> ...
> But no one has been able to tell me where the message is stored. Is
> it in the data dictionary? Is it in a *.m file (stored separately
> from the database on GT.M).
>
Sorry, I didn't realize you were looking for help in tracking down th
The beginning of the thread was my comment that Fileman was WRITEing
(not READing) comments about social security numbers during an
apparent input transform.
But no one has been able to tell me where the message is stored. Is
it in the data dictionary? Is it in a *.m file (stored separately
from
--- Steven McPhelan <[EMAIL PROTECTED]> wrote:
> Mike explained the problem again. The problem is not with READing
> from the
> null device, it has to do with what does the application do if it
> gets a
> value from the READ. Fileman and other applications display a
> message a prompt again. S
Mike explained the problem again. The problem is not with READing from the null device, it has to do with what does the application do if it gets a value from the READ. Fileman and other applications display a message a prompt again. Since M answers the READ command, one cannot check for $T eit
On Feb 6, 2006, at 8:24 PM, Gregory Woodhouse wrote:
Under Unix, at least, the null device is supposed to look like it's
perpetually at EOF when you try to read from it. Now, at the MUMPS
level, the behavior is evidently different.
Hmm...Any attempt to read from /dev/null does seem to fa
On Feb 6, 2006, at 7:45 PM, Palmer, Mike wrote:
Actually I believe that all reads from a null device immediately
receive
a terminating character (CR). All writes also complete successfully
without problems. That's the purpose of the null device.
The thing that often causes looping code is a
onday, February 06, 2006 8:08 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] "Silent" Fileman calls not silent
On Feb 6, 2006, at 6:45 PM, Gregory Woodhouse wrote:
> On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote:
>
>> You never want to
On Feb 6, 2006, at 6:45 PM, Gregory Woodhouse wrote:
On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote:
You never want to READ from the NULL device, especially with
something like "Press return to continue" as the application may
get stuck in a infinite READ loop especially if the READ ans
On Feb 6, 2006, at 6:02 PM, Steven McPhelan wrote:
You never want to READ from the NULL device, especially with
something like "Press return to continue" as the application may
get stuck in a infinite READ loop especially if the READ answer is
required.
I see what you mean. Even with a *
You never want to READ from the NULL device, especially with something like "Press return to continue" as the application may get stuck in a infinite READ loop especially if the READ answer is required.
On 2/6/06, Greg Woodhouse <[EMAIL PROTECTED]> wrote:
--- Steven McPhelan <[EMAIL PROTECTED]> wro
--- Steven McPhelan <[EMAIL PROTECTED]> wrote:
> Opening a NULL device is an option if you are certain all your IO is
> in the
> form of Reads.
>
I guess I don't understand. If you USE the null device, your WRITEs
will go to the null device, too. Are you thinking about multiplexing
devices her
Opening a NULL device is an option if you are certain all your IO is in the form of Reads.
On 2/5/06, Gregory Woodhouse <[EMAIL PROTECTED]> wrote:
> Kevin,> Try setting ZTQUEUED (to anything) right before making the DB> call. Yeah, a kludge - but it might stop some of the messages.
Don't do that.
On Feb 5, 2006, at 11:35 AM, chuck5566 wrote:
On Feb 2, 2006, at 9:29 PM, Kevin Toppenberg wrote:
When I try to do updates to SS Numbers with Fileman "silent" DB API
calls, I occasionally still get messages written to the screen, such
as:
Note: This is a RR Retirement SSN
or
The SSN must n
On Feb 2, 2006, at 9:29 PM, Kevin Toppenberg wrote:
When I try to do updates to SS Numbers with Fileman "silent" DB API
calls, I occasionally still get messages written to the screen, such
as:
Note: This is a RR Retirement SSN
or
The SSN must not begin with 9
Kevin,
Try setting ZTQUEUED (t
Yes and No.
The bug is in the data definition for that field, not necessarily in the API.
Bugs arise in old code as expectations and uses of that code change. This code
was likely
written before the concept of a user interface had become well known.
Kevin wrote:
>When I try to do updates to SS N
day, February 03, 2006 12:59 PM
Subject: Re: [Hardhats-members] "Silent" Fileman calls not silent
--- James Gray <[EMAIL PROTECTED]> wrote:
Philosophical point. If someone put a write statement into a cross
reference before it was against the standard is it still a bug?
Jim Gr
--- James Gray <[EMAIL PROTECTED]> wrote:
> Philosophical point. If someone put a write statement into a cross
> reference before it was against the standard is it still a bug?
>
> Jim Gray
>
Yes! It may not have been a standards violation, but it still has a
side effect that interacts in an u
t: Re: [Hardhats-members] "Silent" Fileman calls not silent
On Feb 2, 2006, at 8:23 PM, Kevin Toppenberg wrote:
Thanks Gary.
By the way, do you have any idea where that output goes when there is
no user session (i.e. with RPC broker calls)?
Thanks
Kevin
That's one of the things t
The write statement may or may not be in a cross reference. The VHA DBA and SACC did come out with a standard stating that there should be now direct WRITE statements in any DD data elements. If WRITE statements are required, then the application is suppose to use EN^DDIOL.
Thus you could have
Well, from what I am seeing, i.e. output during a silent-db-call,
doesn't that mean that there is an output in a cross-reference?
I guess I could do a text-file search for the offending output, but I
wouldn't new if it was OK to change it.
Kevin
On 2/2/06, Gregory Woodhouse <[EMAIL PROTECTED]>
On Feb 2, 2006, at 8:23 PM, Kevin Toppenberg wrote:
Thanks Gary.
By the way, do you have any idea where that output goes when there is
no user session (i.e. with RPC broker calls)?
Thanks
Kevin
That's one of the things the NULL device is for.
BTW, If someone put a WRITE statement in a cros
Thanks Gary.
By the way, do you have any idea where that output goes when there is
no user session (i.e. with RPC broker calls)?
Thanks
Kevin
On 2/2/06, Gary Monger <[EMAIL PROTECTED]> wrote:
> Not necessarily.
> Updates will fire cross references, even when made with the silent calls.
> Cross
Not necessarily.
Updates will fire cross references, even when made with the silent calls.
Cross references can execute MUMPS code and from there nearly anything is
possible.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kevin
Toppenberg
Sent: Thursday,
23 matches
Mail list logo
