Problem with run /detach /output file

[berlioz]

Hello,

In my application, i'm starting all my process with such a following script :

$ run /detach -
/AUTHORIZE -
/INPUT = $diskloc:[commande]run_gest_contexte.com -
/OUTPUT = $fic_trace:gest_contexte.dat -
/PROCESS = GASP_gest_cont -
/NORESOURCE_WAIT-
/priority = 6 -
/working_set = 8192 -
/maximum_working_set = 32768 -
/extent = 32768 -
SYS$SYSTEM:LOGINOUT.EXE

Problem : (i use printf in program for tracing) this file is ever growing...

Is it possible to switch to a new output file without restarting the process ? (for example weekly or when reaching a certain size...)

Thanks in advance for all...

Philippe

[Karl Rohwedder]

Philippe,

you could use the /OUTPUT for errormessages and open/write/reopen the 'real' output file from your application, either on a regurlar basis, or on a trigger.

regards Kalle

[berlioz]

kalle,

I know that it's the good way.

But, in fact, it is a very old application (in exploitation since 1995) that I support.

Before making modifications of source code, I seek a simple solution (based on the operating system for exemple)

[Karl Rohwedder]

You didn't specify the VMS version, but V8.2 introduced CREATE/MAILBOX. So you could
- create a mailbox before starting the detached process
- specifiy this mailbox as /OUTPUT
- start another detached process which reads the mailbox and writes to an output file, which can be repopened at your will


regards Kalle

[Ian Miller.]

Best would be to change the application to periodically reopen the file. Previous versions could then be backed up and deleted as required.

A mailbox and a reader program would work. Before VMS V8.2 to create the mailbox use
MBU
ftp://ftp.process.com/vms-freeware/fileserv/mbu.zip

or other program of your choice.

[berlioz]

the VMS version is 7.3-2

[berlioz]

Must I understand that there is no solution based on the operating system making it possible to close and reopen the file without stopping the process?

[Duncan Morris]

Philippe,

that is correct. There is no way for the operating system to force closing/opening the file.

It will be necessary to amend the application is some way to achieve the result which you desire.

Duncan

[labadie_1]

May be a simple solution is to check in your com file/.exe if a certain logical name (name it gest_exit for example, defined /System/exec), when it has a certain value (reopen), closes and re-opens the logfile, and deassigns the logical name. So when you need it, you define this logical.

Of course it needs a minor modification.

[Heinz W Genhart]

hi Philippe

I think, if you have the source of the application, it would not be to difficult to do some changes to renew the
logfile on a dayli base.

If You dont want to change the source, then you could use the solution with the mailbox. Then you do not have to change
the source of the application, but the way you start it. A possibility to do this is as follows:


$! create mailbox
$! --------------
$ 'command_to_create_mailbox'
$!
$! start the application process
$! -----------------------------
$ run /detach -
/AUTHORIZE -
/INPUT = $diskloc:[commande]run_gest_contexte.com -
/OUTPUT = MBAxxx: -
/PROCESS = GASP_gest_cont -
/NORESOURCE_WAIT-
/priority = 6 -
/working_set = 8192 -
/maximum_working_set = 32768 -
/extent = 32768 -
SYS$SYSTEM:LOGINOUT.EXE
$!
$! open the mailbox for read
$! -------------------------
$ OPEN/READ mbx MBAxx:
$!
$! write to a logfile. renew it dayli
$! ----------------------------------
$log_loop:
$ logfile="application_output_''F$CVTIME("","Comparison","DATE").log"
$ IF F$SEARCH(logfile) .EQS. "" CREATE 'logfile'
$ OPEN/APPEND log 'logfile'
$ READ/END_OF_FILE=clean_up mbx record
$ WRITE log record
$ CLOSE log
$ GOTO log_loop
$clean_up:
$ close mbx
$ exit


You could also combine this solution with the suggestion of labadie and use a logical name to reopen the logfile

Regards

Heinz

[IFX_1]

Hi Berlioz,
Another simple way of getting around it is to reset the execution of the program every week. You can add in your main COM file a validation or condition to check when to stop and start again your program.

$!Check if it's sunday and if the time is between 12:00 and 12:04 ...
$! .... if it is, resubmit job to clear process IO count, reset logs, etc. etc. etc.
$ if f$cvtime("TODAY",,"WEEKDAY") .eqs. "Sunday"
$ then
$ if f$extract(11,5,f$cvtime()) .ges. "12:00"
$ then
$ if f$extract(11,5,f$cvtime()) .les. "12:04" then GOTO RESUBMIT
$ endif
$ endif


Hope it will help.

regards,
ronald

[Wim Van den Wyngaert]

Note that if you use the mailbox and the mailbox reader aborts, the mailbox write process will go into RWMBX until something reads the mailbox.
If the reader is too slow, it might delay the writer process.

Wim

[Jess Goodman]

As an aside, this part of your RUN command is ignored:
/working_set = 8192 -
/maximum_working_set = 32768 -
/extent = 32768

Since you are using RUN /AUTHORIZE the working set and other quotas are obtained from the SYSUAF account settings instead of RUN command qualifiers.

[Jess Goodman]

If your command file diskloc:[commande]run_gest_contexte.com just RUNs an .EXE which nornally doesn't exit, and if there is a time of day/week when it is safe to restart this program, then I would recommend...

* Set up another process such as a periodic batch job that does a STOP/IMAGE for your application process. STOP /IMAGE will abort the program (force exit) but not kill the process. RMS rundown occurs and exit handlers run.

* Modify the command file to check for when the program has been aborted like this:

$ RUN application.exe
$ STATUS = $STATUS
$ IF F$MESSAGE(STATUS,"IDENT").EQS."FORCEX"
$ THEN
$ SET PROCESS/NAME=OLD_'F$GETJPI(0,"PID")'
$ RUN/detach/authorize !Full run command
$ EXIT !Old process dies here
$ ENDIF

[Richard J Maher]

Hi Philippe,

> Must I understand that there is no
> solution based on the operating
> system making it possible to close
> and reopen the file without stopping
> the process?

Your question made me curious as to why this useful utility didn't already exist. My best guess is that it is because Knuckles and Guido have ordained that "Anyone who logs information to sys$output should be sleepin' with the fishes!".

But if we can entertain the idea of a log-file-cycler a little longer: -

. The RMS bits seem pretty straight-forward.
. The fact that DCL's need to keep track of what's going on could be the problem.
. The VMS code in LOGICAL.LIS suggests it should be as simple as: -

dcl$open_output
dcl$close_old_output
dcl$create_output

Then again, I don't know how DCL hangs together and have never written a Supervisor mode RTL in my life so what do I know?

But don't dispair! I know a man who can and if he get's a chance in the next few days he'll have a look.

Even if it was doable, would you just close the log-file and have it look like someone $STOP/IDed the process? Are you happy to output some sort of "Log-switch in progress" message which may be far from the last data written to the log? What's written at the beginning of the New log?

Still, if there was truly scope for fruitful discussion on the subject then I'm sure that one of the DCL gurus at HP with nothin' to do, and all day to do it in, would have contributed already.

Regards Richard Maher