T.R | Title | User | Personal Name | Date | Lines |
---|
53.1 | Make it immune | MPO::MACONI | | Wed Nov 09 1988 16:21 | 23 |
| Honestly, I don't exactly understand your problem... But maybe
I can help anyways...
If you are running a product which creates a process on a remote
system and then remains idle until data is sent down the line, ZAP
will kill the idle processes unless it is protected. The procedure
that I would use is this:
1. Identify the UIC and IMAGE NAME of the remote process
which should be protected from ZAP.
2. Determine which MODE the program runs in. Is it
a DETACHED or NETWORK...
3. Add an exception record for the process to the ZAP
data file.
This should stop ZAP from killing the process. If you want, you
might put in a long time limit (like 4 hours) instead of making
it immune.
Keith Maconi
|
53.2 | not so easy... | BERN01::LEHMANN | the_bitbyter | Wed Nov 16 1988 08:53 | 77 |
| >>> 2. Determine which MODE the program runs in. Is it
>>> a DETACHED or NETWORK...
This proc. runs in normal interactive Mode but it does do a SET H/DTE down
to a specific server. So maybe this could cause a problem.
3. Add an exception record for the process to the ZAP
data file.
This is not easy - every time somebody logges in a new process (and No. is
created).
-----------------------------------------------------------------------------
Here some explanations on ACB (had the Docu allready on System).
There is one dial-in-line to a VAX.
ACB calls me back home trough an auto-dial-out line and kills incoming
connection. If the answer was accepted at home then ACB opens a reverse
LAT link to a server and from there the user connect to any VAX on ethernet.
So - I was connected to any other VAX on the ethernet and suddenly killed
out. After some more tries I killed ZAP on VAX (where ACB is running) and
nothing happend anymore.
Thanx anyway for your help.
andreas
------------------- print for better understanding ----------------------
ACB - Auto-Call-Back System
+---------------+
| V A X |
| |
| * O---<- dial-in-line ----[modem] from my home
| | (killed by ACB after ACB-LINK has been
| | established)
| |
| * +--O--->- auto-dial-out ---[modem] to my home
| ACB-LINK->| |
| * +--O-------------------------------+
| | |
| * +--O--->- auto-dial-out ---[modem] |
| ACB_LINK->| | |
| * +--O-----------------------+ |
| | | |
+---------------+ | |
| |
| |
| |
+---------------+ | |
| DS200/MC | | |
| -------- | | |
| port 1 O-----------------------+ |
| | |
| port 2 O-------------------------------+
ethernet | | Reverse-LAT-Links built by ACB
| | port 3 O
| | |
+-------+ port 4 O
| | |
| | port 5 O
| | |
| | port 6 O
| | |
connect from here | port 7 O
to any System | |
| port 8 O
| |
+---------------+
|
53.3 | Check for image name | MPO::MACONI | | Thu Nov 17 1988 14:56 | 16 |
| To create an exception record for this process, do the following:
1. Create an ACB link and then
2. Do a SHOW PROCESS/CON/ID=x of the ACB link process.
3. Determine the image name (shown at bottom)
4. Insert an exception record as:
[*,*] ACB_IMAGE all * /nomessage
This will stop ZAP from killing this image. If you want, you
could narrow it down to the type of terminal, but that is not required.
Keith Maconi
|
53.4 | it's CONNECT_DTE.EXE | BERN01::LEHMANN | the_bitbyter | Thu Nov 24 1988 16:54 | 15 |
|
>>>> [*,*] ACB_IMAGE all * /nomessage
The image used is called:
[*,*] CONNECT_DTE.EXE all * /nomessage
Thanks for the answer - but I still do not understand why this image is
idle during 'heavy work'... Can this not be checked by ZAP?
andreas
|