[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference share::zap

Title:Zap Technical Conference
Notice:ZAP Version 5.3 is available. See note 1.1
Moderator:ZAPDEV::MACONI
Created:Mon Feb 24 1986
Last Modified:Mon May 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:170
Total number of notes:492

53.0. "ACB reverse LAT zapped?!" by BERN01::LEHMANN (the_bitbyter ) Mon Oct 10 1988 13:25

Could this be possible that I was ZAPed using ACB? 

I'm running ACB V1.0 on VMS V4.7 and ACB creates a Reverse-LAT connection. And 
exactly this reverse-LAT connection has been ZAPed.

Problem ???  Known ???


Thanx for any infos in the next few weeks.....  ;-)

andreas


T.RTitleUserPersonal
Name
DateLines
53.1Make it immuneMPO::MACONIWed Nov 09 1988 16:2123
    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.2not so easy...BERN01::LEHMANNthe_bitbyter Wed Nov 16 1988 08:5377
     >>>  	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.3Check for image nameMPO::MACONIThu Nov 17 1988 14:5616
    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.4it's CONNECT_DTE.EXEBERN01::LEHMANNthe_bitbyter Thu Nov 24 1988 16:5415
    
>>>>    	[*,*]	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