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

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

383.0. "How to communicate with a subprocess while a Logout ?" by PADKOA::COSTEUX (Le Plat Pays qui est le mien...) Wed Mar 26 1997 08:39

    A custoemr wishes the following:
    - after login with his account he runs a program (a menu entries) and
    select one which does a LIB$SPAWN with nowait of an executable image.
    - he then exit from his menu and so gets the VMS prompt (the spawned
    image is still running)
    -> when he logs out from his session he would like to 'tell' the
    spawned process that he is doing a Logout before that subprocess is
    'killed' by the system. He wishes that to allow the spawned process to
    correctly end his job by doing some works before being 'killed'
    
    What is the best way to do that ? I was thinking about mailboxes but
    the customer would to avoid running an other executable image while
    doingg the Logout which would send message to the spawned process. 
    If this is the solution can a DCL procedure send messages to a mailbox 
    for a spawned process ?
    
    Any hint is welcome.
    
    Jean-Pierre

T.R	Title	User	Personal Name	Date	Lines
383.1	Best to relocate recovery, and use locks...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed Mar 26 1997 09:01`	20
	The customer cannot reliably achieve this goal, as the process rundown sequence involves the deletion of all subprocesses for any given process. Workarounds, such as a variant logout image, can certainly be achieved. Regardless of the variant of the logout image, the subprocess will still need to deal with unexpected logouts, and will thus need code that will allow it to "clean up" on execution of commands (in the parent) such as STOP/ID=0, or on system crash. Rather than the communications sequence proposed, it would likely be best for the menu or the subprocess to "check in" with a detached server process located somewhere in the local VMScluster (or on the local node). The server process could then detect the subprocess exit via locks or similar, and perform the necessary cleanup for the subprocess. DCL can certainly send messages to mailboxes, and it can perform DECnet task-to-task. DCL cannot -- without program assistance -- create or delete mailboxes.
383.2	Or...	EVMS::DAVIDB::DMILLER	This bug fix broke what???????	`Wed Mar 26 1997 15:04`	6
	Another option would be to SPAWN a new command process and let the former subprocess act as the main process. Or SPAWN both processes and let the main process be the master. -Dave
383.3		AUSS::GARSON	DECcharity Program Office	`Wed Mar 26 1997 17:02`	16
	re .* Other options... 1. Don't let the user out of the menu to DCL while subprocesses are running. The menu could include a "logout" or "exit" option, either of which would take the necessary cleanup actions for any active subprocesses. The menu could also include a "spawn" option to allow some DCL commands without putting the subprocess at risk. (I think this is what .2 is proposing.) 2. Create detached processes for an executing menu command. That way the process will be unaffected by logout.
383.4	Steve is right, use locks ...	COL01::VSEMUSCHIN	Duck and Recover !	`Thu Mar 27 1997 04:15`	8
	1. "$ open/noshare __tmpfile__ <Your PID>.TMP" at login time. 2. Let the spawned process to queue a lock to this resource. (File lock, Appendix H.6.1 in Black Book, that is no more black) 3. "$ close __tmpfile__" during the logoff sequence. 4. Let the spawned process, when it got the AST telling that the ressource is free, to trigger its shutdown sequence. =Seva