I would like to create a queue, writing the data to a file. The date is in ASCII. The output file is in dka0:[test]test.dat

Thanks for your answers and tipps

wulli

I am not sure that I understand your question. Which programming language are you writing in? Why do you say "writing a queue"? Are you writing a file, which is to be indexed by date, and processed by date?

To write a simple sequential text file from DCL (the command language), use the OPEN, WRITE, and CLOSE commands (see the HELP text for details). If you are appending to the file, you can use the OPEN/APPEND command. Creating an indexed file is not difficult, however, you must declare the characteristics and location of the index key(s).

For example:

$ CREATE DKA:[TEST]TEST.DAT
$ OPEN/APPEND FILE DKA:[TEST]TEST.DAT
$ WRITE FILE "20040928060000KUMQUAT"
$ CLOSE FILE

Would write a file with the leading Time of Year in the first 14 characters. This file COULD be created using an FDL (CREATE/FDL) specifying the file as an indexed file.

For a file indexed by date, I would suggest that you convert the ASCII date into a more consistent format, namely YYYYMMDD. Personally, I would add the time of day to that key, generating YYYYMMDDHHMMSS as the key (the F$CVTIME lexical function, documented under the HELP for LEXICAL) can do much of the conversion from ASCII dates to a comparison friendly date.

The HELP text is extensive. The entire OpenVMS documentation set is available via the HP OpenVMS www site (http://www.hp.com/go/openvms). Most of the manuals are available in both PDF and HTML.

I hope that the above is helpful. If I have been unclear, please let me know.

- Bob Gezelter

Thanks for your help.
Sorry, my explanation of the problem was a bit short. I'll try it again: An automated test system creates a data file while a test is running, which will be printed out of the printer queue sys&print on the local printer. Now, I would like to change the printer queue or create a new one to write the date in an external file so I can store it on a disk. The problem is, the date file created from the test system will be deleted after finishing the test, that's why I can's use it directly.

Thanks for your answer

Jan

Jan,

That is a bit of different question. The answer depends upon how the Automated test system is writing the file and generating the request to send it for printing.

In the worst case, it can get pretty ugly (though rarely used, it is possible to spool files directly to the printer). However, if the automated process is using more common methods, it is possible to intercept the print request and copy/save the file.

How much information do you have about the automated test system and its implementation?

- Bob
P.S. If you want to do this offline, you can certainly contact me via email.

Jan,

If I understand well, the test system creates a file and then sends it to SYS$PRINT.
That means, the file exists.
Now, depending how the test system gets this file printed, you can take measures to prevent the file being deleted.
If in DCL, or even programmed to be sent to JobControl, prevent the file being deleted aftre print. In DCL, it may take the /DELETE aulifier, you'll need to remove that. If programmed, you'll need to check the program to see if this option is part of the call and if so, to remove it (see System Services manual on $SNDJBC service for details, I havn't them at hand).
If output is directly spooled to the printer (which is, as Bob correctly stated, 'pretty ugly' (I think this an understatement...)) you definitely have to either change the program to write to a file instead. anyway: take a CLOSE look to the test procedure: it may indeed create a (temporary) file which is spooled - using SNDJBC, or, as I've seen, SPAWN a subprocess executing a PRINT command
(Bob, do you agree that THAT is ugly?)

Willem

Willem Grooters

Yes, Willem, that is the type of thing that I was referring to as ugly.

If he has the sources, or the procedure for running the job and queueing the test results is in DCL, then yes, changing the qualifier is no problem. If he does not have the sources, then things get messier.

It is possible to write directly to a spooled device, in which case you will likely get a temporary file queued for printing by File ID.

I can think of ways to re-capture the information, but I do not wish to raise more complexity than is necessary to solve the problem. If all we have to do is remove the /DELETE qualifier from a line of DCL, that is easy. If it is more involved, I would rather get the answer correct in as few iterations as possible.

- Bob

Thanks for your infos and tipps!

I have bad news:
- there are no DCL procedures creating the print process!
- the source of the programm isn't available.
- the manufacturer of the testsystem, Lockheed Martin, programmed, to spool the data to the printer.

I think, the easiest way to get the data is to connect a PC to the printercable and capturing it with a hyperterminal.

Jan

Jan,

Ok, that makes things difficult, not impossible.

Manually using Hyperterm is a possibility, but it is tedious and error prone on a regular basis.

I can think of several ways to capture the print stream, but they are beyond what I am comfortable suggesting in an open forum (I do not mind suggesting straightforward solutions and answering questions, but involved answers are beyond the scope of my contribution to public well-being).

If an automatic solution is of interest, please drop me a note via email and we can speak further. I believe that the problem has an efficient solution, but it is a bit longer than a couple of lines of code.

- Bob

If you just want to capture this file.......
Stop the queue SYS$PRINT, Run the test, save the file, delete the entry and start the queue SYS$PRINT again.

Maybe I'm not understand the problem.......

regards,

Hakan

Perhaps it is as simple as defining a symbol under which that process runs as follown

print:=="print/nodelete"

Since you do not have the source, perhaps it does a lib$spawn to do the print via dcl

Just a suggestion

Larry