We are frequently required to kill the ports for our branch stores who are connected by TCP/IP. We can either shell out to linux, find the process and kill it, often along with a second process which I believe to be the Pick process or I can find the process by typing lu at the pick prompt. There is a "Kill" program in DM which works by typing KILL P23 to kill the linux process for the pick port 23 in showing my age and lack of programming skills, how can I run the program from our application account and secondly, we freqently have to kill the process number, one less than that shown using lu in addition to that process. Would there be a danger in modifying the "KILL" program to kill that previous port as well. It would just be simpler to be able to type KILL P23 from TCL rather than typing sh <return>, finding the port and the related process(s) and then killing them and lastly, typing exit to return to Pick.
Thanks for you help or any other suggested remedies.
Bob Marik

JUst copy KILL into your application account's MD --> job done .....
and I'd use

kill -9 P23

just to make sure you DO kill the process. I definately would NOT
modify kill to knock off processes that "might" (or might not) be
related

Hello Ross:
Thanks for the reply. When I shell out to linux there is almost always a parent process that has to be killed as well and it is always the process number, 1 less than the process which appears in list-users (lu) AND I don't believe that there is ever a case where a non-related process would have that process number. That is why I would like to kill both processes at once (unless the kill p23 actually kills both the processes.
Also, this should be trivial but I don't remember how to copy the basic program from the DM account to our application or user account.
If you (or someone) can help me with this, I would appreciate it.
Thanks
Bob Marik

rmarik wrote:
users. If for any reason they get knocked of without exiting, I have to
kill the Linux process for the port they're on. I keep wondering if I
shouldn't go through D3 for a more controlled exit.
I "nail" the ssh ports by putting a script in their profile, when they
login, the script connects them to a specific D3 port. If the port is
unavailable they get bounced right out.

Bruce, have you tried the auto-xinet script in dm,bp,? You need to run
it from a d3 session started from root with the "-l" option, and you
will need to modify it for ssh instead of telnet (is ssh really
necessary for local users?). I used auto-xinet (with telnet) to set up
nailed ports at several sites with minimal problems (also I put 'dcd-on'
in the logon procs (and usually also start d3 with the -dcdon option),
and 'trap dcd exit' in user-coldstart). There are the occasional
problems with the d3 session not disconnecting, but infrequent enough
that it isn't a big problem; I show someone on site (like the office
manager?) how to use my "fix.port" tool:

* clear hung telnet port
* 07-12-02 asb
tclread buf
buf = trim(buf)
port = field(buf," ",2)
if port eq "" or not(port matches "0n") then
print
print "Enter port number to fix: ":
prompt ""
input port
call input.test(port)
if port eq "" or port eq "quit" then stop
if port matches "0n" else
print "Port number must be a NUMBER"
stop
end
end
if port eq system(22) then
print "You cannot fix.port on yourself!"
stop
end
cmd = "reset-user "ort
**print cmd
execute cmd
cmd = "kill p"ort
**print cmd
execute cmd capturing xxx
call get.user.srt(user)
date.time = date():".":time()
open "asb,fix.ports," to fix.ports then
rec = port
rec<2> = user
write rec on fix.ports,date.time
end


/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

bruce ackman wrote:

from tcl in your data account:

copy dm,, kill
tomd

job done!

I'll have a dig through some old D3 documentation I did up when I was
working in that industry and see if I have anything that may help as I do
remember coming across this problem with a machine and I do remember solving
it.

andrew

"bruce ackman" <lewissupply (AT) copper (DOT) net> wrote

Thanks Again Ross:
Actually, there was an entry in the MD of our data account prior to this but when I tried running the program I got the msg "not supported on this implementation". After doing the copy again as you suggested above, the same entry was in the MD and we still get the same message. I can run the program from dm and it works fine but not from the data account. In looking at the basic program for "kill", there are some includes. Would they have to be copied to the data account as well?
Bob

Thanks Scott,

I'll look at that. I use ssh because my outside salesmen and I are
allowed to log in remotely and I don't feel safe making my server
accessible over the Internet with telnet.

Bruce

Scott Ballinger wrote: