DCL scripting - using WRITE to file

[robert70]

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

[Hoff]

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]

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]

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? ;-)

[robert70]

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]

"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.