herb@blender.uucp (Herb Peyerl) (01/16/91)
I'm involved in writing a driver for prsvr that will re-route prf jobs to a remote TCP node running lpd. I've got it pretty much working however there's a few pieces to the puzzle missing. In the "Printing in the Domain/OS environment" manual there is mention of a number of databases that are accessable by drivers and filters. 2 of these databases are described in the manual (Interface database and the job database) but there is mention of the user database which contains user specified items however this database isn't described so consequently I don't know what fields are available and consequently don't know how to access them. Specifically, I need the following bits of information: the name of the user who submitted the job the node the job was submitted from. the filename being printed. and the exact size of the file. I require the first three for submission to the lpd daemon so that the banner page contains appropriate information. However, I need the exact size of the file because the lpd on the remote host needs to know how many bytes to read from the network. Without an explicit size, lpd just keeps waiting until the arbitrarily specified (hardcoded by me temporarily) number of bytes arrives. I had thought of reading from the stream into malloc'ed memory or creating a temporary file, however, this is a big waste of performance and it's also not uncommon for some of our postscript files to approach 5 or 6 MB in size. (A lot of the jobs for this printer will come from Mentor Applications). So, can anyone help me out here? Specifically someone at Apollo or even someone else who's done this. If you already have a prsvr driver that will submit jobs to a remote 'lpd' then I'd appreciate having a look at that. If no one has it and there's enough interest in it (I can see a lot of uses for this sort of thing) then I'll gladly post the source when I get it running. (assuming I can get the thing running properly.) Anyhow, thanx in advance to anyone who can help me out here. This seems to be the sort of thing that David Krowitz would have done so maybe he can help me out. -- -------------------------------------------------------------------------- UUCP: herb@blender.UUCP || #define Janitor Administrator ICBM: 51 03 N / 114 03 W || Apollo System_Janitor, Novatel Communications "I spilled spot remover on my dog and now he's gone..." <Steven Wright>
krowitz@RICHTER.MIT.EDU (David Krowitz) (01/24/91)
Frankly, I would advise against using the Apollo prsvr/prmgr/prf software. In general, it is undocumented. In general, minor OS versions (SR10.1, SR10.2, SR10.3) change the method of operation of the printer software in incompatible ways. In general, the only documentation you have for any particular OS rev. is the /sys/ins/prsvr.ins.pas (and/or /sys/ins/prsvr.ins.c file), and the actual executable behaviour of the /sys/hardcopy/prsvr program. Now, down to business ... Unless I was hallucenating again ;-) , I remember seeing the name of the user who submitted the print job in one of the databases. However, the versions of the insert files I have on my SR10.2 systems don't show any such database key. The insert files *do* show a key for the name of the file being printed (although this is usually /sys/print/spooler/...). I do *not* remember ever seeing the name of the node from which the job was submitted. You can find out what the version of "prsvr" you have on your system is doing by using the "print_entries" routine defined in the insert file(s). This routine will dump out all of the keys in the database that you pass to the routine along with the current value of the key and the key's datatype (which is *very* useful, as any key can be accessed as any datatype -- most of which give you garbage). You should be able to get the size of the file being printed via the IOS_$ and/or Unix file I/O calls. The top-level Apollo print server (ie. /sys/hardcopy/prsvr) will pass your print-driver either an IOS stream ID or a GPR bitmap handle along with the job database when it (prsvr) calls the driver's rendering routine. You can pass the stream ID directly to IOS_$ calls (well, actually, you have to use the PTR2IOS function described in the insert files) to get the file size. I can't find any IOS_$ calls that directly return the size of the file, but you could probably to a seek to EOF, followed by an inquire-key to get the byte offset of the EOF from the BOF (which *is* the file size). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (01/29/91)
In article <9101231737.AA22881@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes:
I can't find any IOS_$ calls that directly return the size of the file...
That would be ios_$inq_byte_pos. Or, for you portability freaks, fstat().