Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!ucsd!ucbvax!RICHTER.MIT.EDU!krowitz
From: krowitz@RICHTER.MIT.EDU (David Krowitz)
Newsgroups: comp.sys.apollo
Subject: Re:  accessing user_db for prsvr driver: HELP.
Message-ID: <9101231737.AA22881@richter.mit.edu>
Date: 23 Jan 91 17:37:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 43

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)