gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software) (05/01/90)
I, too, am having trouble with my parallel printer using PC/ix, and Interactive is stumped. The problem is that output is >>>EXTREMELY<<< slow... like about 10 chars/sec max. This behavior is seen when doing `cat file > /dev/lp1', so it isn't a spooler problem. A few weeks ago I saw the tail end of a discussion of a similar problem, ending with `don't use keymap'. I don't, unless it's buried in a standard distribution .????rc file which I can't find. Of course, if I boot DOS, the printer works just fine, thanks. AAARRRGGHH. Any enlightenment appreciated. thanks, geoff steckel (gwes@wjh12.harvard.EDU) (...!husc6!wjh12!omnivor!gws) Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line. This posting is entirely the author's responsibility.
mason@oct1.UUCP (David Mason) (05/03/90)
In article <15427@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >My advice: If you're not really running multi-user, ditch the spooler. >It's a pain in the caboose. Just pump to /dev/lp and have a nice day. There is also a signifiacant saving in main memory if you don't use the spooler. On ISC 2.0.2 it takes 181k every time you type "lp". On straight AT&T 3.2 it's about 244k. On the other hand, I have never had more support hassles than from packages that try to get smart and talk straight to a SERIAL printer port. Try explaining "stty -a" to an accountant. -------------------- David | mason@oct1 (David M. Mason) | ...!ddsw1!olsa99!oct1!mason
ade@clark.uucp (Adrian Miranda) (05/04/90)
In article <708@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: >In article <511634@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes: >>In article <1990Apr29.020243.20270@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: >>> You need to modify /usr/spool/lp/interface/{queue_name}} >> >>Since I don't have that directory, I assume you are referencing >>/usr/spool/lp/model/<printer name> - where in my case it is dumb. .... >That IS strange. You really should have in interface directory there. The >model directory is the directory from which the admin utility picks the base >script to install in the interface directory. Interface is the directory >into which this model is copied, along with the appropriate name you have >given it. .... >Look again - and check to see that you have dirs for class, interface, member, >model, and request. >Bill Vermillion - UUCP: uunet!tarpit!bilver!bill Well, at least on ESIX system V r3.2 rev C, the interface directory got moved to /usr/spool/lp/admins/lp/interfaces. Perhaps this is true of other recent versions of System V as well (I have no idea)? Adrian Miranda uunet!clark!ade
dpi@loft386.UUCP (Doug Ingraham) (05/04/90)
In article <1820@east.East.Sun.COM>, gsteckel@diag2.East.Sun.COM (Geoff Steckel - Sun BOS Software) writes: > I, too, am having trouble with my parallel printer using PC/ix, and Interactive > is stumped. The problem is that output is >>>EXTREMELY<<< slow... like about > 10 chars/sec max. This behavior is seen when doing `cat file > /dev/lp1', > so it isn't a spooler problem. This sounds like the driver isn't getting any interrupts. I have seen lpt ports that didn't bother to connect to the interrupt line. This seems to be mostly the port on a monochrome card. It is also possible that the card is interrupting on a line other than the one the driver expects and so is still ignored. Try a different parallel port. Remember that the two common interrupts used for lpt devices are 7 and 5. 7 is the one you want to use because 5 is used by mice and lan cards and streaming tape controllers. I am always fighting the lack of available interrupt lines especially on 8 bit cards. Another possibility is that you have 2 cards driving the same interrupt line. > A few weeks ago I saw the tail end of a discussion of a similar problem, > ending with `don't use keymap'. I don't, unless it's buried in a standard > distribution .????rc file which I can't find. I really can't believe this could have anything to do with the printer. At least it shouldn't. > Of course, if I boot DOS, the printer works just fine, thanks. AAARRRGGHH. Of course. Dos doesn't use interrupts (for the parallel port). It is single tasking and just waits for the printer to accept a character. You would complain worse if Unix operated this way although your complaint would be about how Unix locks up while printing. > Any enlightenment appreciated. > thanks, > geoff steckel (gwes@wjh12.harvard.EDU) > (...!husc6!wjh12!omnivor!gws) > Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line. > This posting is entirely the author's responsibility. Suggestions: Try a different parallel port. Check the existing port to make certain the card is configured correctly. Make certain you don't have an interrupt conflict with some other card. If you have a second parallel port try using that. What is probably happening is the driver is sleeping waiting for the busy line interrupt. There is a timer set so that if the interrupt is missing eventually the driver task wakes up and sends another character. -- Doug Ingraham (SysAdmin) Lofty Pursuits (Public Access for Rapid City SD USA) uunet!loft386!dpi
john@design.axis.fr (John H) (05/05/90)
In article <1990Apr21.033100.19633@pegasus.com>, richard@pegasus.com (Richard Foulk) writes: > In article <134576@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: > >+-- In <3@ttc.UUCP> marc@ttc.info.com (Marc O'Krent) writes > >| I have a Toshiba P1340 running under 386ix, and can't get the tabs > >| to be expanded. Consequently every file with tabs in it causes the > >+-- > > > >In the /usr/spool/lp/interface/mumble file you need to change the line > >that currently reads something like > > cat $FILE > >to something like > > expand $FILE > > He'll first have to get a copy of "expand" which doesn't come with 386/ix. > > -- > Richard Foulk richard@pegasus.com I know this isn't right (it isn't even well written) but it works! #include <stdio.h> main (int argn, char *argv []) { /* Expand tabs in input file */ int ch; int pos = 0; int tab = 8; if (argn > 1) { tab = atoi (argv [1]); if (tab <= 0 || argn > 2) { puts ("Usage: expand [ tab_pos ] <in >out"); exit (0); } } while ((ch = getchar ()) != EOF) { if (ch == '\n') { pos = 0; putchar (ch); } else if (ch == '\t') { do { putchar (' '); pos += 1; } while (pos % tab != 0); } else { putchar (ch); pos += 1; } } } John Hughes.
karl@ddsw1.MCS.COM (Karl Denninger) (05/06/90)
In article <1990May3.111446.2879@oct1.UUCP> mason@oct1.UUCP (David M. Mason) writes: >In article <15427@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>My advice: If you're not really running multi-user, ditch the spooler. >>It's a pain in the caboose. Just pump to /dev/lp and have a nice day. > >There is also a signifiacant saving in main memory if you don't use the >spooler. On ISC 2.0.2 it takes 181k every time you type "lp". On >straight AT&T 3.2 it's about 244k. > >On the other hand, I have never had more support hassles than from >packages that try to get smart and talk straight to a SERIAL printer >port. Try explaining "stty -a" to an accountant. Yeah, no kidding. Put about 3/4 of the accounting packages in the WORLD in that basket. They deserve it. Then shoot the programmers -- they deserve it too. MCBA is an offender. They try to talk direct to serial printers. It doesn't work much of the time, since they aren't smart enough to do an ioctl() once they open the port! Guess what? You end up with a few processes "holding open" the port, which can cause other problems. That REALLY sucks, folks. What they should do is use the "class" features of the spooler if they're worried about special forms, or use the "forms" features in the SVR3 spooler. But no, they have to be "cute" and write direct. If I had a dollar for everytime I saw this........ And they wonder why people don't take Unix seriously in the business marketplace? It has nothing to do with the operating system, and everything to do with the monkeys who program the applications for it. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
pnessutt@dmshq.mn.org (Bob Monio) (05/07/90)
In article <1990May6.152012.14804@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >In article <1990May3.111446.2879@oct1.UUCP> mason@oct1.UUCP (David M. Mason) writes: >>In article <15427@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>>My advice: If you're not really running multi-user, ditch the spooler. >>>It's a pain in the caboose. Just pump to /dev/lp and have a nice day. >> >>There is also a signifiacant saving in main memory if you don't use the >>spooler. On ISC 2.0.2 it takes 181k every time you type "lp". On >>straight AT&T 3.2 it's about 244k. >> >>On the other hand, I have never had more support hassles than from >>packages that try to get smart and talk straight to a SERIAL printer >>port. Try explaining "stty -a" to an accountant. Not to be picky, guys, but Tom's message above referred to /dev/lp, not a tty. Unless Tom has his /dev/lp linked to a tty I doubt that he's referring to a serial printer, but rather a parallel port. >Yeah, no kidding. > >Put about 3/4 of the accounting packages in the WORLD in that basket. They >deserve it. Then shoot the programmers -- they deserve it too. It's not just accounting. The company I do some work for has a wholesale distribution package that does both; write directly to the serial printer and also use the spooler. I'm not sure why it was originally done this way, but we are in the process of changing it. >MCBA is an offender. They try to talk direct to serial printers. It >doesn't work much of the time, since they aren't smart enough to do an >ioctl() once they open the port! > >Guess what? You end up with a few processes "holding open" the port, which >can cause other problems. That REALLY sucks, folks. > >What they should do is use the "class" features of the spooler if they're >worried about special forms, or use the "forms" features in the SVR3 >spooler. But no, they have to be "cute" and write direct. Perhaps. When I asked the program's designer why he used a mixture of both, he responded by saying that there was no such capability available with the old spooler under SVR2. Modifying it now to support SVR3 would be a help, yes, but it would limit portability across versions of UNIX that do not have the same spooler capabilities. From what we've seen of AIX, it's even more different. >If I had a dollar for everytime I saw this........ It's caused a few headaches for me also. But lately it's been more of a problem with poor integration on the part of hardware/OS combinations that have hurt more than anything else. >And they wonder why people don't take Unix seriously in the business >marketplace? It has nothing to do with the operating system, and everything >to do with the monkeys who program the applications for it. Agreed. But remember that it's a rather rough job to provide portability in a program across different versions of spoolers on different flavors of UNIX. It's made harder in case of the above mentioned program when the 4GL that is being used doesn't support spooling of output at all... (ie: PROGRESS) -- Robert A. Monio "I've learned all my heroes and wanted Level I Systems, Inc. the same/To try out my hand at the pnessutt@dmshq.mn.org Patriot Game..." ..amdahl!bungia!dmshq!pnessutt -- Robby Jackson, 'Patriot Games'
pim@cti-software.nl (Pim Zandbergen) (05/07/90)
pnessutt@dmshq.mn.org (Bob Monio) writes: >Agreed. But remember that it's a rather rough job to provide >portability in a program across different versions of spoolers on >different flavors of UNIX. It's made harder in case of the above >mentioned program when the 4GL that is being used doesn't support >spooling of output at all... (ie: PROGRESS) That is incorrect. In Progress you can pipe to any UNIX command with the "write through" statement. Even the default printer is a pipe to "lp -s". -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
mbanan@bcsaic.UUCP (Mohsen Banan) (05/07/90)
In article <29404@cup.portal.com> Dante_A_Nicolello@cup.portal.com writes: >How do I make ISC 3.2 not print a banner page. What I want lpr to do is >just print the file, then send a form feed, that's all. (Like DOS's >PRINT command). Which file do I change? There seem to be so many files and >filters, etc for printting, I can't seem to find the correct one. Thanks. > > > Dante > >---------------------- >dante_a_nicolello@cup.portal.com ____ > \ // > \// I did this a while back, my memory is not all that great any more. So take the following recomendations with that in mine. For Per Invokation basis: lp -o nobanner For per Printer Basis: /usr/lib/lpadmin -P printerName -o nobanner For System Basis: create a file called /etc/default/lpd and put BANNERS=0 or BANNERS=1 in it. I think all of this is properly documented, so if these don't work RTFM.
wht@n4hgf.uucp (Warren Tucker) (05/08/90)
In article <7813@dmshq.mn.org> pnessutt@dmshq.mn.org (Bob Monio) writes: >In article <1990May6.152012.14804@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >>In article <1990May3.111446.2879@oct1.UUCP> mason@oct1.UUCP (David M. Mason) writes: >>>In article <15427@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>>>My advice: If you're not really running multi-user, ditch the spooler. >>>>It's a pain in the caboose. Just pump to /dev/lp and have a nice day. >It's not just accounting. The company I do some work for has a >wholesale distribution package that does both; write directly to the >serial printer and also use the spooler. I'm not sure why it was >originally done this way, but we are in the process of changing it. Most of the check writing programs I have run into want more a better feeling that check # blah-dee-blah has been printed than just knowing it has been spooled, especially when printing on checks with preprinted numbers. Now as to the usual MIS daily/weekly detail tomes people rarely look at, spoolers are more trusted :-). ------------------------------------------------------------------ Warren Tucker, TuckerWare gatech!n4hgf!wht or wht%n4hgf@gatech.edu McCarthyism did to cinema what ANSI did to C, cast a great number of characters into the void.
pnessutt@dmshq.mn.org (Bob Monio) (05/08/90)
In article <1990May7.134227.796@cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes: >pnessutt@dmshq.mn.org (Bob Monio) writes: > >>Agreed. But remember that it's a rather rough job to provide >>portability in a program across different versions of spoolers on >>different flavors of UNIX. It's made harder in case of the above >>mentioned program when the 4GL that is being used doesn't support >>spooling of output at all... (ie: PROGRESS) > >That is incorrect. In Progress you can pipe to any UNIX command >with the "write through" statement. Even the default printer >is a pipe to "lp -s". True. Progress's "write through" option does give that ability. But it still leaves the implementation of spooling and printer control to the programmer and the spooler on the OS that he is using. Is there a better way? I dunno. Is there anyone out there in netland who has developed an application that is portable across spoolers on a variety of UNIXes? That is, without using a spooler the vendor would supply with the application? -- Robert A. Monio "I've learned all my heroes and wanted Level I Systems, Inc. the same/To try out my hand at the pnessutt@dmshq.mn.org Patriot Game..." ..amdahl!bungia!dmshq!pnessutt -- Robby Jackson, 'Patriot Games'
les@chinet.chi.il.us (Leslie Mikesell) (05/08/90)
In article <7813@dmshq.mn.org> pnessutt@dmshq.mn.org (Bob Monio) writes: [Re: spooling vs. writing to device] >Agreed. But remember that it's a rather rough job to provide >portability in a program across different versions of spoolers on >different flavors of UNIX. It's made harder in case of the above >mentioned program when the 4GL that is being used doesn't support >spooling of output at all... (ie: PROGRESS) Rough??? All you have to do is allow the installer to specify the name of a program to pipe the output to, and let popen() handle the details. I have yet to see a situation where this is not the correct way to handle printing under unix, although there are rare cases where it would be useful to offer direct device access in addition (say you need to hand-feed paper and need to control output without leaving the application). Also the application should keep in mind that the output may be coming to the terminal's aux port and thus should not be done in the background unless the installer sets it up that way. If you are too lazy to read a per-user set-up file, at least leave PATH alone so that the program executed as the pipe can be modified per-user. Les Mikesell les@chinet.chi.il.us