Operating System - OpenVMS
1745822 Members
4130 Online
108722 Solutions
New Discussion

DCL scripting - using WRITE to file

 
robert70
Valued Contributor

DCL scripting - using WRITE to file

Using WRITE to a file in a command eg.

 

$ OPEN/WRITE HFILE D:[USER]TEST.TXT

$ WRITE HFILE " FAILURE @ ''TIME' , "

$ WRITE HFILE " DATE IS  ''DATE'"

 

For reasons I wont go into here I must outpout the file test.txt in 2 seperate write statements but I want both outputs to appear on the same line

 

eg

 

FAILURE @ 13:03:33 , DATE is 12-10-11

 

and not what I am getting eg

 

FAILURE @ 13:03:33 ,

DATE is 12-10-11

 

Can you write an ascii backspace at the start of the 2nd WRITE perhaps?

 

I tried with

 

$WRITE HFILE "{ESC}[1D"

 

But this dosent appear to work

 

Thanks

 

 

 

5 REPLIES 5
Hoff
Honored Contributor

Re: DCL scripting - using WRITE to file

DCL does not work the way you want and need here, so you're going to have to re-open the file and rewrite the records within the file to account for that second WRITE statement.  

 

Or migrate to a language that can manage the records in the fashion you seek here; Python, Perl, php, Lua, etc.  

 

Or figure out some other way to modify the existing record in the existing file; on Unix, I'd use sed here, and while editing a file from within a DCL procedure is feasible on VMS, it's unfortunately somewhat more effort than sed, and gnv is wonky at best.  If you have a good solid target, then the VMS SUMSLP editor would potentially work.

 

And in general, you will always want to issue the matching CLOSE /NOLOG just before an OPEN command:

 

CLOSE /NOLOG HFILE

 

This ensures the I/O channel is always closed, as these can be left open and dangling from a previous error.

 

"For reasons I wont go into here"?   So then relevent management is either complicit in or ignorant of the decision, eh?

H.Becker
Honored Contributor

Re: DCL scripting - using WRITE to file

As we know from Down Under, you can force the output file to stream_lf. Then, after the first write, you can adjust EOF and overwrite the '\n' with the second write. Whether this is worth the effort is a different question and very likely depends on reasons you didn't want to go into. 
$ create/fdl=sys$input test.txt
record
        format stream_lf
$ OPEN/append HFILE TEST.TXT
$ WRITE HFILE " FAILURE @ ''TIME' , "
$ close hfile
$ ffb=f$file ("test.txt","ffb")
$ ebk=f$file ("test.txt","eof")
$! in this example ffb is 21, but in general:
$ if ffb .eq. 0
$ then
$ ffb= 511
$ ebk= ebk-1
$ else
$ ffb= ffb-1
$ endif
$ set file/attr=(ffb='ffb,ebk='ebk) test.txt
$ open/append hfile test.txt
$ WRITE HFILE " DATE IS  ''DATE'"
$ close hfile
John Gillings
Honored Contributor

Re: DCL scripting - using WRITE to file

You can play around hacking at the file attributes as described by Hartmut (neat hack!), but it might be better to change your I/O model. Build yourself a module of routines surrounding the output file which implement the operations you want to be able to perform. This can be as elaborate as you want, or as simple as possible.

 

FILEOPEN

   OPEN/WRITE file name

   buffer=""

 

FILECLOSE

   FILEWRITELN

   CLOSE file

 

FILEWRITE

   buffer=buffer+text

 

FILEWRITELN 

   FILEWRITE text

   WRITE file buffer

   buffer=""

 

(Object oriented DCL? ;-)

A crucible of informative mistakes
robert70
Valued Contributor

Re: DCL scripting - using WRITE to file

thanks

2 good suggestions

I have implemented simply creating a text string with the

 

buffer = buffer + text

 

and then write that to the file on completion

 

cheers

 

Hoff
Honored Contributor

Re: DCL scripting - using WRITE to file

"Completion" implies some form of logging and potentially scheduling and job control tasks are involved.

 

Guessing...

 

The VMS job control and job scheduling implementation is unfortunately very weak and only getting weaker in comparison with other platforms, but there are ways to implement your own on VMS.  And there are also open-source and third-party commercial job scheduling options.

 

Available options can include using OPCOM and post-processing OPERATOR.LOG as a potential solution, or using a sequential or indexed RMS file as a status database (that's fairly common, and fairly quick to implement), or using user-generated accounting messages, or various other available solutions.   I've also seen folks use logical names and sometimes logical names in shared tables here in place of the symbols you're now targetting, too. 

 

I'd look to use a scheduling package of some sort, as re-implementing your own isn't particularly cost-effective.  And you get to solve problems folks have already solved.  Failing that option, a simple RMS database is probably the best choice.