Tip of the day - USER command

[Brian K. White]

Jerry Rains wrote:
> Sent: Friday, March 19, 2004 2:33 PM
> Subject: Re: Tip of the day - USER command
>
>
>> Jerry Rains wrote:
>>>
>>> I've been working with the USER command a lot recently and was
>>> having problems with it either hanging or blowing up.  I determined
>>> that if the user presses Break just before the USER command was
>>> written to, it caused filePro to exit to the shell.
>> Ken Brody wrote:
>>
>> Only if your USER program exits when break is pressed.
>
> That's the problem.  It does, but it isn't my program and I don't
> have the source code so I can't fix it.

The program is just netcat (the classic "hobbit" nc-1.10) with a couple
patches I found on the net that add optional different behaviour when one or
the other side of the connection closes it's stdin/stdout, and a little
change I added myself to stop it from saying "punt!" when receiving a hup,
specifically to try and address this issue. If you don't have the source,
it's because you migrated boxes and failed to bring it along from the old
box.
The source is widely available and should be in /usr/local/src on your box,
and barring that I can supply it again once you tell me the result of
 "ksh -e cat `whence pcms` and in there is either a command "nc" or possibly
nc112" (the number I gave my patched version) whatever is used in that shell
script, run that (nc or nc112 etc) with -V or --version or -h or --help (one
of those, try all untill you get a version number) and post the version info
and I'll supply that source. _Don't_ just run "nc --help" because it's
fairly likely that your linux box has a "nc" that may or may not be what my
script is using. So read the script and post the version of nc that IT uses.
... just remembered something else, you might not be using the shell script
ata all any more, the entire "nc options" command might be right in the user
command.

It may in fact be the straight unpatched version, since I tried many
slightly different things andno longer remember what exactly was the last
thing I settled on, and wherever possible I try to use the most generic
default things to minimize situations exactly like the one you only _think_
you are in. :)

This program gets called a *lot* and needs to talk to a server and correctly
parse it's responses and it's been shown that it's responses are not 100%
regular.

Be careful if, where, & when you add any "close pcms" in that table, as the
first instance initiates a session with the remote server similar to (ok,
exactly like) a telnet session, and you don't want to break that session
until you are all done sending and receiving commands and responses for that
job.

for the list at large...

the problem seems to be:

1) There is a call table that uses netcat to tak to a remote server.

2) there are a few input tables where the user spends several uninterrupted
hours in the same instance of rclerk input processing moving from record to
record doing work all day long.

3) these input tables call this call table a lot.

This should be allowed. This is a good sane arrangement and a good case of
writing code once and having it used a lot. The code in the call table is
very fussy (the interaction with USER and the remote server is very
exacting) So this is code that is very Very Really easy to break, took a
long time to get right, and so you really don't want to mess with it once
it's working, and so it's extremely good that it's possible to make it into
a call table since it gets used from at least a few different input tables
and is intended/desired to be used in more new places by the in-house
programmers (nods to jr) as they develop new things.

What happens is, user hits a hot-key or moves through a @we/lf and the call
table gets called in the background. The call table runs the user command.

Even while in the same update session in the same record the user may
trigger this call table several times.
Each time the call table is called, the embedded user command starts a new
child process.
The user saves the record and moves to some other record without ever
leaving rclerk. In the new record the fire off the call table one or more
times... all day long.

The user processes never go away until the user _exits rclerk_

If the user simply backs out to the menu, thus exiting rclerk, any user
processes they started go away.

If they only back out far enough to move to another record, they don't
actually exit rclerk, the processes hamg around accumulating. Last I knew,
these "dead but waiting to really die" were all zombie processes that used
up only process stack slots, but no actual cpu or ram. (but of course on a
multi-user system, even a slow one, and theirs isn't, even that could
quickly cause new processes to start failing to run.

I thought this was sucessfully cleared up on the original linux/as400 box I
set up. If things have been moved to a generic intel linux box since then,
possibly it's broken again, or maybe it was never fully cleared up even on
the original box.

If you are in fact using something that calls itself "nc 1.12" then you have
a couple command line options you can play with (in /usr/local/bin/pcms or
the user command line) that supposedly change nc's behaviour when the call
table says "close pcms". I beleive I already played with everything possible
in that program but it can't hurt for someone else to test all options
again.

Lastly, since then, a couple new netcat options have arisen that might work
out better for this usage.

You should be able to get the new gnu netcat(gnu enhanced hobbit nc110) and
"socat" and modify /usr/local/bin/pcms to use one of them instead of the old
nc at least for a test. I have socat built for SCO at
http://www.aljex.com/bkw/sco not that that matters much to you.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani