A.Eric@GSB-HOW.STANFORD.EDU (Eric M. Berg) (04/28/88)
Last week, I posted to this list several problems we have run into while
trying out AUFS in a mixed Macintosh and MS-DOS environment. This week,
I have a number of questions about the LWSRV program, based on things we've
noticed as we've been testing it more heavily.
First, a question about the AppleDict PostScript header files. We've noticed
that the files sometimes seem to have two sets of identifying numbers, e.g.
%%Title: "Laser Prep -- The Apple PostScript Dictionary (md)"
%%Creator: Apple Software Engineering
%%CreationDate: Thursday, March 19, 1987
%{appledict version #65 1
% ) CopyRight Apple Computer, Inc. 1984,1985,1986,1987 All Rights Reserved.
%%EndComments
%%BeginProcSet: "(AppleDict md)" 66
I initially thought this was #65, as it says on the fourth line, but it
seems to be #66, as it says on the last line. Also, the latest version
claims to be numbered "67 0", and I'm not sure I know how to supply a
version number with a space embedded in it as the argument to the "-a"
option of the lwsrv program.
Secondly, while files spooled throught lwsrv often print without problem,
on other occasions, they don't print at all, and we've been getting error
messages of the sort "p_fillbuf PAPRead error -3109" in our lwsrv log
files. Can someone help clarify what this means and what action to take
to correct it?
Thirdly, we're running MicroSoft Word on MS-DOS systems which are equipped
with AppleTalk cards and Apple's "AppleShare PC" software (which in fact
supports printing as well as file servers). We're seeing constant AppleTalk
checksum errors when the MS-DOS system tries to send a PostScript file to the
lwsrv process; here's a sample log entry:
Checksum error: Incoming: e969, calculated d017 [1326.27]
Dropping packet
(where 1326.27 is the AppleTalk net.node of the MS-DOS system). There don't
seem to be any problems when the DOS system sends directly over AppleTalk to
the LaserWriter, only when the output is spooled through lwsrv. Any ideas?
Fourthly, we occasionally see entries in the lwsrv logs which look like this:
Starting print job for Haiti-Spooler
Unknown AppleDict file for '66'
p_fillbuf PAPRead error -3109
Printing job: Query for Laser Prep, the Apple PostScript Dictionary; user ;
on Tue Apr 26 13:02:21 1988
We're not sure where the "Query for LaserPrep" jobs are coming from, but they
usually seem to be associated with the papif process on the CAP host dying
and having to be restarted with the lpc program. Can anyone explain what
might be going on here?
Many thanks to Charlie Kim for his response to my previous question (and for
the software !!!), and to him or anyone else who can shed some light on the
above.
Eric M. Berg
Computer Facility
Graduate School of Business
Stanford University
-------LENOIL@XX.LCS.MIT.EDU (Robert S. Lenoil) (05/10/88)
>Thirdly, we're running MicroSoft Word on MS-DOS systems which are equipped >with AppleTalk cards and Apple's "AppleShare PC" software (which in fact >supports printing as well as file servers). We're seeing constant AppleTalk >checksum errors when the MS-DOS system tries to send a PostScript file to the >lwsrv process; here's a sample log entry: > Checksum error: Incoming: e969, calculated d017 [1326.27] > Dropping packet >(where 1326.27 is the AppleTalk net.node of the MS-DOS system). There don't >seem to be any problems when the DOS system sends directly over AppleTalk to >the LaserWriter, only when the output is spooled through lwsrv. Any ideas? The AppleTalk PC Card had a bug in its ROM which generates incorrect DDP checksums on certain packets. An updated ROM (rev C) has been phased into production. It was supposed to coincide with the product name change from AppleTalk PC Card to LocalTalk PC Card, but due to delays, some LocalTalk PC Cards do have the rev B ROM (part no. 3420007-B). The reason you do not see a problem when printing directly to a LaserWriter is because the ATALK driver only sends a DDP checksum on an ATP response if the request had a checksum; most Macintoshes and LaserWriters do not use DDP checksums. You have two options to fix your problem: 1) Change lwsrv to not send DDP checksums. This will cause the PC card to send responses without DDP checksums, thus sidestepping the problem. 2) Upgrade your ROM. Apple has not yet established an upgrade policy, in part because it is not known how many users are affected. Making your situation known to your supplier will help in this regard. Robert Lenoil Apple Computer, Inc. Network Systems Development -------