topic Re: Problem with run /detach /output file in Operating System - OpenVMS

Problem with run /detach /output file

berlioz — Thu, 11 May 2006 08:00:37 GMT

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

Re: Problem with run /detach /output file

Karl Rohwedder — Thu, 11 May 2006 09:19:32 GMT

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

Re: Problem with run /detach /output file

berlioz — Thu, 11 May 2006 09:48:45 GMT

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)

Re: Problem with run /detach /output file

Karl Rohwedder — Thu, 11 May 2006 10:05:39 GMT

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

Re: Problem with run /detach /output file

Ian Miller. — Thu, 11 May 2006 10:22:52 GMT

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.

Re: Problem with run /detach /output file

berlioz — Thu, 11 May 2006 10:28:50 GMT

the VMS version is 7.3-2

Re: Problem with run /detach /output file

berlioz — Fri, 12 May 2006 02:17:32 GMT

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?

Re: Problem with run /detach /output file

Duncan Morris — Fri, 12 May 2006 02:43:55 GMT

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

Re: Problem with run /detach /output file

labadie_1 — Fri, 12 May 2006 02:49:38 GMT

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.

Re: Problem with run /detach /output file

Heinz W Genhart — Fri, 12 May 2006 04:00:56 GMT

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

Re: Problem with run /detach /output file

IFX_1 — Mon, 15 May 2006 04:01:08 GMT

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

Re: Problem with run /detach /output file

Wim Van den Wyngaert — Mon, 15 May 2006 10:28:41 GMT

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

Re: Problem with run /detach /output file

Jess Goodman — Mon, 15 May 2006 17:04:33 GMT

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.

Re: Problem with run /detach /output file

Jess Goodman — Mon, 15 May 2006 17:22:56 GMT

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

Re: Problem with run /detach /output file

Richard J Maher — Tue, 16 May 2006 05:50:04 GMT

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