I really, really agree.
> -----Original Message-----
> From: Schouten, Frits JF [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, March 23, 2000 2:42 PM
> To: 'Foxboro DCS Mail List'
> Subject: RE:Script Execution
>
> > Quite right about the "&" Alex,
> > I made a typo in the e-mail. I do use the "&" in the applic command.
> That is fairly well highlighted in the dm command manual.
> > You know what I really hope this whole intermezzo does to our
> subscribers? I hope they just pick up the bits that are useful to them.
> > I also hope that people on our list don't feel inhibited by thinking "O,
> I might make a fool of myself". Because they don't.
> > Just spill out all those thoughts floating around in the grey matter. It
> is really good to bounce off ideas.
> > I, for one, might benefit from it. My ego is getting a bashing here :-)
> >
> > Thanks for listening and responding.
> > Kinda lonely out here.
> > Better do some work too....
> >
> > Cheers,
> > Frits Schouten.
> >
> >
> >
> > -----Original Message-----
> > From: Johnson,Alex [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, 23 March 2000 13:51
> > To: Foxboro DCS Mail List
> > Subject: RE: Script Execution
> >
> > I'm really glad you brought up applic. It has a really nasty side
> effect.
> >
> > There are two obvious ways to run a program from a WP:
> >
> > 1) dmcmd applic <pgm> <arg1>...<argn>
> > 2) dmcmd run <pgm> <arg1>...<argn>
> >
> > The first command writes the argument of applic to a named pipe on the
> > logical host of the WP. Attached to the named pipe is (basically) a
> Bourne
> > shell which reads the commands and executes them using the system(3s)
> call.
> >
> > The second command causes the DM to fork into two processes. The second
> > (child) process
> > then execls into <pgm> and passes itself the arguments.
> >
> > The main difference between the two appears to be that the first command
> > executes on the logical host of the WP and the second executes on the WP
> > itself.
> >
> > However, there is another subtle difference and it can cause very
> > significant problems.
> >
> > Remember that the first command is fed to a shell process and it uses
> > system(3s) to run the command? Well, what happens if the command does
> not
> > complete? For example, if it is used to run 'textedit' and the user
> never
> > quits textedit?
> >
> > The answer is that no more commands are read from the named pipe until
> > textedit completes! No matter how many are sent or which WP sends it.
> >
> > However, this does not stop other commands from being placed in the
> pipe!
> > Theoretically, the pipe could fill and cause visible problems on the
> DM/FV
> > side, but I've never seen that happen.
> >
> > So, what happens to the users is:
> >
> > 1) Textedit starts.
> > 2) Many other programs do not start.
> > 3) Users call support because 'applic' does not work anymore! TAC works
> like
> > mad.
> > 4) Textedit exits hours later quite by accident.
> > 5) Lots of programs run when they are not supposed to and do bad things.
> > 6) Everyone is confused and unhappy.
> >
> > [How do I know? I had it happen in a major refinery. Fortunately, the
> > problems were minor, but...]
> >
> > There are two ways to avoid this feature (and it might be for some
> > customers):
> >
> > 1) Put the & at the end of all commands that are invoked by applic. In
> your
> > example, you should
> > write:
> > :C0WP04DMCMD := "dmcmd applic /opt/home/frits/hello.scr &";
> > not
> > :C0WP04DMCMD := "dmcmd applic /opt/home/frits/hello.scr &";
> > 2) Use
> > dmcmd run /bin/rexec $TMHST <pgm> <arg1> ... <argn>
> >
> > I rather like the second one because I am quite likely to forget to add
> an
> > ampersand (&) to the end of
> > ALL of my applics. This failure would result in a subtle error. I hate
> > subtle errors!
> >
> > Whereas, the second approach does not lend itself to subtle errors. Only
> > major ones which are easy to find ones.
> >
> > So, your test program which is now out for all to see has two flaws:
> >
> > 1) Lack of error trapping and
> > 2) The possibility of causing quite significant problems to each WP
> sharing
> > a host.
> >
> > Now, aren't you sorry that I read this list? :)
> >
> > BTW: This is all covered in my book. To bad, it is not published.
> >
> >
> >
-----------------------------------------------------------------------
This list is neither sponsored nor endorsed by the Foxboro Company. All
postings from this list are the work of list subscribers and no warranty
is made or implied as to the accuracy of any information disseminated
through this medium. By subscribing to this list you agree to hold the
list sponsor(s) blameless for any and all mishaps which might occur due to
your application of information received from this mailing list.
To be removed from this list, send mail to
[EMAIL PROTECTED]
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]
