Tip of the day - USER command

[Jerry Rains]

Brian,

Thanks for the info.  I'll check this stuff out when I get to work Monday.

Jerry

On Sunday 21 March 2004 03:28, Brian K. White wrote:
> 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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list