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

Conference noted::hackers_v1

Title:-={ H A C K E R S }=-
Notice:Write locked - see NOTED::HACKERS
Moderator:DIEHRD::MORRIS
Created:Thu Feb 20 1986
Last Modified:Mon Aug 03 1992
Last Successful Update:Fri Jun 06 1997
Number of topics:680
Total number of notes:5456

665.0. "O/P from detached processes" by 38167::BHAVNANI (Real programmers don't blame the compiler.) Sun Jan 17 1988 02:23

	I  have a simple (what else!) program that I run as a detached process
	by doing  $ RUN /PROC="FOO" FOO.  I'm having a hard time trying to get
	FOO.EXE to write stuff to SYS$OUTPUT.  The program basically does

		do
		{
		  sleep (10);
		  printf ("From detached process...\n");
		}
		while (1);

	The  program simply creates an empty file called SYS$OUTPUT.;   When I
	try to redirect the  o/p using /OUTPUT=foo.bar, I don't get a FOO.BAR.
	However, at least no SYS$OUTPUT.; is created in this case.

	I even tried doing  fprintf (stdout), fprintf (stderr) and fprintf (f)
	[after doing a fopen(ttyname(),"w") which returned a non-NULL pointer]
	but  have  had no luck.  I probably should throw the o/p (error diags)
	to an explicitly opened .LOG file.   Any  pointers  (no  pun intended)
	would be appreciated.  Tnx much,

	/ravi
T.RTitleUserPersonal
Name		DateLines
665.1JON::MORONEYRedundancy example: Criminal lawyer.Sun Jan 17 1988 13:0110
Include your SYS$ERROR file.  Your program works fine as is, and I've
been doing similar things from C for a while.  Remember, it takes a
little while for the data to get written out to the file (it's probably
in RMS buffers) and the file is locked until the program terminates.

Run the program interactively for obvious errors.  You'll get an error on
your terminal if something's wrong, but the RUN/PROC process sometimes
disappears without a peep for some errors.

-Mike
665.2SMAUG::MENDELPessimists Always Get Good News.Mon Jan 18 1988 12:577
    Did you try pointing FOO at your terminal when you ran it?
    
    $ RUN FOO/OUT='f$log("TT")' 
    
    Unadorned printf's should work. (tell me if they don't?)
    
    Kevin
665.3SMAUG::MENDELPessimists Always Get Good News.Mon Jan 18 1988 13:019
    RE .-1
    
    ... I just re-read .0, and I guess I jumped to the conclusion that
    you wanted to have you're detached process write to you're terminal.
    (That's what SYS$OUTPUT means to me ... )
    
    So ignore my ramblings ...
    
    P.S. *DID* you point /OUTPUT to somewhere?
665.4Redirecting FOO's output38167::BHAVNANIMust be the compiler...Tue Jan 19 1988 00:2920
	On  closer inspection I found I indeed had a SYS$ERROR.; created in
	my dir, along with a plethora of SYS$OUTPUT.;s.  However, all files
	were zero block files.  I tried /OUT=OUTPUT.LOG, /ERR=ERROR.LOG but
	still  got  zero length files.  I even killed the sleep(10), but no
	luck.

	In  any  case, I'm going to go with an explicitly created .LOG file
	opened  as shareable for read, so I can monitor the progress of the
	detached  process.   I  strongly suspect it's meaningless to expect
	output  at  a  device as there (apparently) is no device associated
	with the process (hence "detached"?)

	Now only if someone wrote me a friendly C-callable $SNDJBC routine,
	I'd be thrilled...  :-)

	/ravi

	PS: My  detatched  process runs a pgm that isn't supposed to terminate
	    until external control directs it to do so - that's why I couldn't
	    just wait till the program ended, to view the O/P file.
665.5Blame the run-time systemSQM::HALLYBYou have the right to remain silent.Tue Jan 19 1988 21:424
    Perhaps you should try including a $FLUSH, which will force out
    the buffers immediately.  I don't know how you do it from C.
    
      John
665.6Flushing SYS$OUTPUTFOO::BHAVNANIMust be the compiler...Tue Jan 19 1988 22:576
	That's an idea.  I haven't tried it yet, but I guess what I should.
	Btw, flushing SYS$OUTPUT's buffer in C is easy:

		fflush (stdout);

	/ravi
665.7special case?OVDVAX::LENNIGDave, SWS, @CYO CincinnatiWed Jan 20 1988 11:399
    This has hit upon something I've always wondered about.
    
    There is a DCL command SET OUTPUT_RATE[=delta-time] which causes
    these flushes to occur automagically (for batch jobs, it says).
    
    Q1 - does this only apply to batch? (How about 'NETWORK')
    Q2 - how does one do this for processes that don't have a CLI?
    
    Dave
665.8PASTIS::MONAHANI am not a free number, I am a telephone boxWed Jan 20 1988 22:096
    	There is a flush service that anything that owns an output file can
    use. DCL owns the batch log file for a process that has DCL as its CLI.
    
    	I am not sure which other CLIs can be persuaded to do regular
    flushes. In a process without a CLI the application programme owns all
    output files, so it can decide if or when it wants to do a flush.
665.9I think it's broader in definitionMDVAX3::COARM��se ChoreographerThu Jan 21 1988 12:039
    SET OUTPUT_RATE applies to all process log files, including (I'm
    pretty sure) the file you just DEFINEd SYS$OUTPUT to go to.  That
    is, all output files that are process-permanent and opened by DCL.
    Which makes me think that it would also apply to files you might
    be using with OPEN and WRITE (as long as you said /SHARE=READ).
    
    Someone from VMS-land want to toss in a couple of �?  Jon?
    
    #ken	:-)}
665.10PLDVAX::ZARLENGALost the will to compromiseSun Jan 24 1988 14:437
    	How does a _detached_ process know that SYS$OUTPUT is the same
    SYS$OUTPUT of the initiating process?
    
    	A subprocess can always assume it's available, but this doesn't
    seem like a wise assumption for a detached process.
    
    -mike z
665.11Unwise? I think I agreeDPDMAI::BEATTIEBut, Is BLISS ignorance?Mon Jan 25 1988 10:3824
RE: .10
    
    As far as I know, a DETACHED process need have nothing of any
    consequence in common with the initiating process; It must contend
    for and consume resources all by itself.  It has it's own process and 
    job logical tables, and in particular, it's own translation of 
    SYS$OUTPUT:.
    
    If the device to which its SYS$OUTPUT logical points is currently
    allocated to another process (even the initiator), communications
    are limited in the same way that they would be limited if the device
    was allocated to ANY other process.  SYS$GETDVI will return the owner 
    of a device (DVI$_OWNUIC, DVI$_PID) but you're going to have
    difficulty finding the owner process translation of SYS$OUTPUT:
    
    I would say that if you detach a program of your own, you could
    code in the ASSUMPTION that your detached process will be directing
    its output to a device allocated to another process.  I would expect
    you'd need to in order to provide for use of SYS$BRKTHRU, or overriding
    device protections, or something like that...
    
    						-- Brian