Capturing spooled output

[Jack Trachtman]

We have an old application that we cannot modify, which uses what I'll call the old LAT style of printing. We create a LAT device and set it spooled to a print que. When the app wants to print, it opens the LAT device and wirtes to it. VMS captures the output to a temporary file which it creates. When the app close the file, VMS creates an entry in the print que associated with the LAT device. The temporary file then gets printed and deleted.

We need to capture these files after they are closed so that we can reformat them with added printer control information. But VMS creates these files with only a FID entry but no file name, making it impossible to directly find them.

How can I (preferably with DCL only) get to these files so that I can open them and read through them to them to create new versions with the changes I want to add?

TIA

[Ian Miller.]

you need a server symboint. See the freeware on the hp vms site for examples

[Volker Halle]

Jack,

don't think you could do this from DCL.

But there exists some freeware tool called EXECSYMB, which may be able to help (from reading the documentation).

Volker.

[Uwe Zessin]

Correct, I have done it in the past, but I used 'CTLSMB' (on VAX, only). For today's use it would need some work, because it uses a little Macro code to alter things like the process' username cell.

The server symbionts (at least CTLSMB) can be set up so that they start a separate process with DCL access for each job.

I am afraid that even if you use a different workaround:
- keep the queue stopped
- make a copy of each entry's data
- move the job into the real output queue

you cannot do this with DCL alone, because a spooled file, as you have already discovered, is not entered into a directory. You would need at least a little image that knows how to open a file by device name and FID to make a copy of the data.

[John Gillings]

Jack,

A rather ugly alternative is to use spare serial ports and a short patch cable. Send the jobs out one port, and just loop it back into another. Start a process that listens for input on the second port. Hopfully you can distinguish the beginning and end of the job. Use a reset module with an unique string if necessary.

Your reader could be in DCL if there are no other options. Make sure flow control is enabled and resist the temptation to crank the speed up too high. Many systems have unused ports, or you could use LAT terminal server ports if there aren't any on the host.

[Tom O'Toole]

You could also do periodic anal/disk/rep on your spool disk, which would move those files into [syslost], where you can manipulate them. If you can allocate a small volume for use strictly as spool, this might not be too bad.

[Jack Trachtman]

Looks like EXECSYMB might be the way to go for me.

I'm curious to hear from people who are using it: for what purpose(s), and any problems they've had (on doing a WEB search for EXECSYMB I see that someone posted a problem with the SET USER function.)

Thanks

[Jan van den Ende]

Jack,

maybe off-topic, but from your profile:

"I have assigned points to 26 of 124 responses to my questions."

Would you please find some time to catch up somewhat?

Look, I am __NOT__ saying that you should award more points, but just asking to get rid of the UNassigned.
If there are answers that __YOU__ feel (and on your questions you are the only one who decides) merit NO points, it is simply possible to assign ZERO points.
At least it tell the person trying to answer, that that answer HAS been evaluated, but was considered irrelevant.

It is considered forum-etiquette.

If you want quick access to the questions in case, click your own name to get your statistics, and at the bottom choose "questions or topics with unassigned points"


Proost ( = Cheers!)

Have one (or more) on me.

Jan

[Robert Gezelter]

Jack,

Three options, one that I will admit that I have not investigated, and one that I know from experience should work.

- Stop the queue, use a command file to scan the queue, and then copy the files to somewhere else (and remove them from the queue). As was said in a movie, "Crude but effective". This should be implementable using nothing but DCL.

- Without doing any programming, I would take a look at the possibility of using C-Kermit and its scripting language to manage an incomming LAT port.

- A clean (well cleaner) implementation would be to write a program which uses the incomming LAT connection support on a VMS system to fake a printer.

For cleanliness, I would probably chose option 3, otherwise my first choice might very well be option 1.

In both cases, they guarantee that you will only process files that are in that queue, no accidental inclusions of other files.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

-

[Jan van den Ende]

Jack,

another possibility, which (as far as I can see now :-) ) even less potential timeing problems, would be to simply STOP the target queue.

Then have a batch job periodically scan the queue for jobs, and test for the file being closed. Get the file info, do whatever required manipulations, and actually PRINT them on another queue.

Hope this helps.

Proost.

Have one on me.

Jan