KVC@ENGVAX.UUCP (Kevin Carosso) (02/25/86)
Ok, here's a nasty problem I hope someone has solved...
I've written a print symbiont using the PSM$ routines (if you don't know
what those are, you probably oughta skip the rest of this message) to enable
me to create a server queue on one machine that outputs across DECnet to
another machine that has all our printers on it. With the exception of
the following little problem, this is actually quite easy to do.
(PRINT/REMOTE doesn't do the job, it requires that the file already be on
the remote node.)
The way my code works is as follows:
When NETSMB.EXE is started up running as the symbiont processor for the
queue called REMOTE, it establishes a DECnet connection to a server I've
written. Now, when a file is printed it first tells the server what remote
queue to finally send the file to for printing, then it sends the data.
The server squirrels the data coming over the net into a temp file. At
the end of the file, the symbiont tells the server it's done and the server
then queues the temp file for printing on the requested remote printer.
The problem I've got is how can you get your PSM replacement routines to
know when the end of the print job has occured. If you think about it,
you never really need to know this if you are sending to a stupid printer,
you just output when it tells you to output. In my case, though, I have
to know. Now, I have managed to use PSM$REPLACE to replace
PSM$K_JOB_COMPLETION with my own routine. I duplicated what it does on
the fiche (only a few lines) and also set my own flag saying that after
the next PSM$K_WRITE call to my user-written output routine, we are done.
Unfortunately, JOB_COMPLETION is really file completion. If I print one
file, it works perfectly. Even if I have job separation trailers enabled,
I can correctly sense that I'm done after the job trailer page has been
sent. Unfortunately, if I print multiple files with a single print command
(which VMS calls a single print "job") I incorrectly detect completion of
the job after every file, except for the last file, for which I detect
completion after the job trailer page. Since the one on the fiche really
only prints a form-feed, it's not really a bug that it prints a form-feed
between each file in the job, though I think it is incorrect behaviour,
FILE_COMPLETION (or whatever) should do that!
While I can live with this behaviour, it is tacky, since I will be taking
one print job (with nice job headers and trailers and burst pages) and breaking
it up by file. When actually printed on the remote end, someone else's
print job could get mingled in between the files that constitute my remotely
printed job, making the job separation stuff worthless.
Anyone out there use the PSM stuff? Any suggestions?
/Kevin Carosso engvax!kvc @ csvax.caltech.edu
Hughes Aircraft Co.
ps. I refuse to look at the data I'm sending to see if it
resembles a VMS job trailer page in order to detect EOJ!!!
pps. Oh, and another thing... Anyone else get the standard VMS 4.2 print
symbiont into a COM bound loop using PRINT/PASSALL? Stopping the queue
doesn't help, you have to nail the SYMBIONT_xxxx process.rcb@RTI-SEL.UUCP (Random) (02/26/86)
I have seen your problem about the print symbionts. I wrote a symbiont to talk to an Imagen laser printer that talks a WEIRD packet protocol. The printer is also shared by many computers on our terminal switch, so I had to release the printer when I was done so that other computers could have it. The solution I found was a simple timer. In the output routine, I would cancel the timer and restart it just before returning. If the timer ever timed out (about 10 seconds was sufficient), I interpreted this as end of job and dropped the connection. If more than one job was in the queue, these would be sent without any pause but would have a packet sent with psm$k_start_task (A task being a full print job (all files)). This seems to work fairly well. Also, Any print/passall command will cause the symbiont to loop forever. However, if you can create or munge the file to be printed with /passall into a file with carriage control=none, It will have the same effect as /passall. Random (Randy Buckland) Research Triangle Institute ...!mcnc!rti-sel!rcb
dav@YETTI.UUCP (Dav Ung) (03/03/86)
In article <8602250741.AA05066@csvax.caltech.edu> KVC@ENGVAX.UUCP (Kevin Carosso) writes: >pps. Oh, and another thing... Anyone else get the standard VMS 4.2 print > symbiont into a COM bound loop using PRINT/PASSALL? Stopping the queue > doesn't help, you have to nail the SYMBIONT_xxxx process. Printing a file with variable length, fixed 2-byte header records and print file carriage control can throw PRTSMB into a COM loop, if the file had a request to print a record after advancing -5 lines. Such files are routinely created by COBOL programs and the -5 request may result from: WRITE record AFTER variable LINES and <variable> had a -5. Not sure if other negative numbers will cause the same behavior, but we can reproduce the problem consistently using -5. COBOL runtime routines do not stop you from requesting -5 line print control. CSC, Colorado Springs, knows of this problem. I had not heard back from them re a solution. If this is not the cause of your problem, HAPPY HUNTING...
vix@WELL.UUCP (Paul Andrew Vixie) (03/06/86)
Re: PRTSYM looping on files with long lines and no carriage control
Got our 4.3 tape yesterday; this problem is fixed, according to the release
notes.
Paul Vixie
{dual hplabs lll-crg ptsfa}!well!vix