This file contains information about: PRINT : Network Printing ******** THD202.DBF ******** Msg#: 159681 Date: 10-Oct-91 Fm: Roger Bischoff [Fox] 76004,1651 To: Mike Mitchell 70353,3651 -Mike: On a Novell Netork you can use the following Syntax for the SET PRINTER TO command: SET PRINTER TO \\SPOOLER\F=\B=\C=\Q= In your instance, you would issue the command like: SET PRINTER TO \\SPOOLER\F=\B=\C=\Q=PRINTQ_0\NB Let me know if this helps. Roger [Fox] Msg#: 142778 Date: 03-Sep-91 Fm: John Flynn Matthew 72450,2162 To: jason jones 70670,3023 Try using the set printer to //spooler option. Foxpro finally supports network queues on novell (if thats what you are using). FP will release the job when a new set printer to command is issued, or a TI is hit. An example would be: set printer to \\spooler\q=&MyQueue\s=&MyServer report form set printer to I have used this an it works really well, you ought to try it out. Msg#: 170362 Date: 31-Oct-91 Fm: Charles Nelson 75170,777 To: Lisa Slater 72077,2417 The printer is physically attached to the file server's LPT or COM port(PC other than your wstn). For the LaserWriter, you would attach it to the COM port since it is a serial device. When you configure the server's operating system (NetWare), you specify the number of printers attached to the server and you configure each one with respect to serial or parallel. In the case of serial, you then must provide the speed, parity, stop bits, etc. The operating system then assumes repsonsibility for properly initializing the ports when the server and operating system is booted. No MODE command as we know it on a standalone PC is required. You then assign each printer to be serviced by a server queue. In the simplest terms, each printer has it's own queue. At the wstn, you are never concerned about how the printers are attached to the file server...that is the responsibility of the server operating system. What you do need to know, tho, is what server queue the printer is attached to, and you prepare your wstn by executing a 'command line' command which states that you want all print output for an LPT port to be redirected to the apporpriate server queue. The server operating system knows that the queue is servicing a specific printer, and knows the port and communication paramters. Let's say that you have a Laser NT attached to COM1 on the file server. You configure the operating system with 9600, N, 8, 1 comm parameters. This is only done once...when you configure the operating systems printers. Then you set up a QUEUE called LASERNT and assign it to the Laser NT printer. Again, this relates to the operating system...not the wstn. Now, let's say that you want a FoxPro app to print to LPT2 and you want the output to go to the Laser NT. You must of course set up the Fox drivers to send Postscript instructions and issue the SET PRINTER TO LPT2 command. You must have also issued a network command called CAPTURE which instructs the network shell residing in the wstn to The CAPTURE command will redirect all app LPT2 output to the assigned server queue, the server knows that printer attached to the queue, and then sends the print info in the queue to the correct printer. BTW, you do not need to have a physical LPT2 port in the wstn. The print output for LPT2 is intercepted by the network shell and redirected to the network printer. On the other hand, if you do have a physical LPT2 printer on your wstn, you can choose not to have the LPT2 output redirected to the server queue/printer, but instead sent to the local printer. In this case you would issue and ENDCAP LPT2 at the command line, and the network shell will stop it's redirection. Whew...I'm not sure what I just said or whether it made sense. Anyway, let me know if I can clarify anything. <> Msg#: 163390 Date: 17-Oct-91 Fm: Martin C Smith 100015,3255 To: Gregory Van Boven 71571,2726 (X) I've got (as of today & your note!!) two partial solutions, though I understand this is now a recognised 'bug' and will be fixed. 1. Automating release of print jobs. FP2 won't accept a TI (timeout) clause on SET PRINTER TO \\SPOOLER, but it respects any existing timeout on the relevant local LPT port, so setting any old CAPTURE on LPT1 with eg TI=5 will allow print jobs to be released without further effort. 2. The only solution I've found to undoing the 'trampling' is to do a CAPTURE SHOW to file on application startup, then using low-level file funtions to pull it apart to generate a RUN CAPTURE command on closedown. _VERY_ kludgy, not quite working right yet and hopefully to be superseded by Fox's bug fix, but it can be done . Not much help I know, but at least Fox are onto it. MCS PS I hadn't noticed this before, because all the systems I develop are the sole reason for the existence of the network, so nothing else is ever run on them by the users. So I never realised what was happening - many thanks for pointing it out. MCS Msg#: 165363 Date: 22-Oct-91 Fm: David D. Brown 76244,1602 To: Roger Bischoff [Fox] 76004,1651 (X) Roger, I think what might be helpful to all Netware FOXPRO users is a discussion of how the SET PRINTER TO \\SPOOLER command is supposed to function. The manual is not very descriptive. I have been using Netware for over 5 years now, and am very comfortable with the old Netware 2.0a SPOOL command and the later CAPTURE command and their various parameters. What I perceive is that FOXPRO is bypassing normal processing that would take place if I used a CAPTURE command at the DOS prompt in favor of some direct interface into the Netware print queues. My experimentation so far has had varied results. When I issued a SET PRINTER TO \\SPOOLER\B=ST0001\NB\F=4\C=2, I get a request to mount form #4, but when the job is queried using the PCONSOLE Netware command, the form number shows as (T:), which I think is a truncation of the 'LST:' source which would appear on the banner page. It is legal to issue a \B=xxxxx\NB command, as this allows a description to show on the file server console when the queue is displayed, but will not print a banner page. If I have already issued a CAPTURE command to a print queue, the SET PRINTER TO \\SPOOLER\Q=xxxxx command will alter the queue of LPT1. Is it supposed to do that? Or should I expect that any CAPTURE settings created at the DOS prompt will remain untouched by FOXPRO? It also seems that the printed output will not be released to the queue until another SET PRINTER TO command is issued, regardless of any CAPTURE TI=nn command issued from DOS? Is that true also? As you can see, there are some questions that could stand further discussions. Maybe someone from FOX could upload a more detailed discussion of the SET PRINTER TO \\SPOOLER command operation as it relates to Netware print queues and what the expected behavior (and appearance to Netware) should be. Thanks for your aid so far... David Msg#: 165766 Date: 23-Oct-91 Fm: John Hawkins [DBA] 75300,575 To: DERMOTT RENNER 75130,1246 Thanks for the message. However, it's not the aspect I'm asking about. SET PRINTER TO does close the queue (like Timeout does), but it does not seem to do the same thing as ENDCAP. Instead, it seems to close the queue and immediately reopen it. This is essentially the same way it behaved in FoxBASE+ and FoxPro 1. I'm not trying to force a queue to be close, I'm looking for a way to perform ENDCAP, to *completely* terminate NetWare's redirection of printing. My experiments with FP 2 and NetWare 3.11 haven't been successful. Msg#: 165894 Date: 23-Oct-91 Fm: Roger Bischoff [Fox] 76004,1651 To: John Hawkins [DBA] 75300,575 -John: We changed the SET PRINTER TO command because many users requested that it NOT terminate the CAPTURE, as it did in FoxBASE+ and FoxPro 1.x. I can submit an enhancement request to add a parameter to the command which has the same functionality as ENDCAP. Roger [Fox] Msg#: 167213 Date: 25-Oct-91 Fm: John Hawkins [DBA] 75300,575 To: Roger Bischoff [Fox] 76004,1651 I don't recall a discussion of remodeling SET PRINTER TO during beta, but it's wrong to change behavior from FoxBASE+ and FoxPro 1 in FoxPro 2 unless absolutely necessary. It breaks several applications (like a label printing routine that no longer works because the label printer is local to a single machine, while all other printers are on the network). Better is to have SET PRINTER TO work as documented (truly close the queue, ending capture as ENDCAP does). The queue can easily be reopened by issuing a subsequent SET PRINTER TO \\SPOOLER, or a flag option can be added to close and reopen the queue simultaneously. A very poor second choice would be to add a flag that restores the previous behavior and/or performs an ENDCAP. That should be the default, since it is consistent with prior behavior of the command when issued without parameters. Now's the time to fix it, before too many people realize they have to rewrite their apps to handle the new behavior and implement kludges to do ENDCAP. ******** THD203.DBF ******** Msg#: 176882 Date: 13-Nov-91 Fm: GENE GOLDHAMMER 71160,2564 To: Tim Boustead 72701,1732 (X) Tim - Maybe you have some special requirements with printing. We find that about the highest we have to set the LPT timeout to is 10 seconds, maybe 30 seconds in some cases. LPT timeout is for the longest PAUSE within a particular print job, not to set the time that it takes to print your longest print job. We can be printing a report that takes a long time, and when it is done, the next job will print immediately. Also, with Lanpup, you can put a long job on hold, send other jobs to the printer, and then come back to your long print job. I don't see the advantage of using the net lpt seperate and combine commands - What do you gain from them? Gene G. Msg#: 176963 Date: 13-Nov-91 Fm: Tim Boustead 72701,1732 To: GENE GOLDHAMMER 71160,2564 (X) Gene: A few benefits I have found to using net lpt combine/separate/flush commands are : 1. Get rid of the annoying 'Beep' that signals the buffer is flushed 2. Eliminate the 30 seconds (in your case) you may have to wait needlessly before printing. 3. Be able to group multiple reports from a program into 1 printjob. This is helpful because I have a Fox program which generates 4 reports with various queries and delays in between. I also have reports that have multiple queries in them. As each query finishes, it prints its results to the printer and the next query begins. I don't know how long the time between queries and printing is going to be. This depends on # of dbase entries in the selected month, plus who is doing what on the network at print time. Tim. Msg#: 177525 Date: 14-Nov-91 Fm: Pete Goubert 72020,751 To: GENE GOLDHAMMER 71160,2564 (X) Gene, I use that approach myself, and it works fine except for cases when you want the output to go to the printer ASAP (like when printing sample labels so they can align the printer). Sure, I put a message on the screen telling the user to press CTRL-ALT-* to truncate the print stream, but this is a less than ideal solution. Telling them to press CTRL-ALT-anything is dangerous; I've already seen several cases of accidental reboots by less than computer literate users. What I would really like to be able to do is turn off print spooling from within my application, print my "quick" reports, and turn spooling back on again. Second choice would be to truncate the print stream from within a application. Any ideas on how to do either of those? pete Msg#: 177977 Date: 15-Nov-91 Fm: Tim Boustead 72701,1732 To: GENE GOLDHAMMER 71160,2564 (X) Gene, You got me to thinking, you may be right, I probably don't need the separate and combine commands since the info doesn't go to the spooler until its flushed. I'll try using just the 'flush' command and see what happens. Tim. Msg#: 177979 Date: 15-Nov-91 Fm: GENE GOLDHAMMER 71160,2564 To: Pete Goubert 72020,751 (X) Pete - Just use Lanpup - We use it, and show all of our Lantastic customers how to use it. In our shop, we are jumping around from a 24 pin to a laser, and to different servers all the time. If your printer is local, you can 'unuse' it and halt the queue, and you then have your local printer back. If you are sending print jobs to a another server, obviously you must use the spooler - unless you use the 'net run' command, which would let you activate a print job on another machine. Where immediate acces to a printer is required, such as in our P/Sale system, there is simply no substitute for using a local, non-shared printer. Other uses, such as labels, simply require access to a printer that you can 'take over' during the lable print. In some cases, there are just no elegant solutions to printer sharing - but there is a lot more flexibility with Lantastic than with Netware. Also, we may write an FP2 API for Lantastic network services - if there is a market for it. Gene G. Msg#: 173343 Date: 05-Nov-91 Fm: Ross Fraser 71161,454 To: Cathy Selhorst [Fox] 76177,3002 Cathy: Time to lay this "try increasing the TIME= setting in your CONFIG.FP file" advice to rest. Try it yourself on a 33MHz 386. Because it specifies retries and not seconds to wait, even huge settings do not solve the full buffer problem. When a laser printer's buffer fills, it can take more than half a minute for the buffer to clear (depending on the amount of memory installed on the printer). On my computer, FP cycles through all 1000000 retries (the maximum setting) in just under 24 seconds. Isn't technology wonderful? So on a 33MHz 386 (to say nothing of faster machines), the TIME= setting is *worthless*! -- Ross Faser Msg#: 183035 Date: 26-Nov-91 Fm: Cathy Selhorst [Fox] 76177,3002 To: Rein Lemberg 70164,2666 Rein, Yes I did receive your message and I did respond on November 1st, message number 171015. Basically your printer is telling FoxPro that it is ready to receive data, however, when FoxPro sends a character, the printer then says that it cannot accept it because the print buffer is full. FoxPro therefore responds with the "Printer not Ready" error. To avoid this message you can use the following command in DOS. MODE LPT1,,P Cathy Msg#: 173670 Date: 06-Nov-91 Fm: montana opi 70334,2416 To: DAN CUMMINGS 72470,2325 (X) We have found that CTRL + ALT + * (on the num pad) releases the print jobs on the OS/2 LAN Server v1.X. We have also written a .BIN file and Program to release the print Jobs on Network printers. If you would like me to send you a copy of what we us let me know. :-) Msg#: 173835 Date: 06-Nov-91 Fm: Barry Glick 100036,155 To: Montana Opi 70334,2416 I came in on the tail of your Lan printing thread and hope I've got the correct gist of it. We have also experienced the phenomenon - Spool all day and never print. I've tried the "Ctrl" "Alt" and "*" with no real success. We are running LAN Manager 1.0 and were pleased to see it wasn't just us. We tried all sorts of things and discovered that if you print one report and then quit Fox, all works, but if you print more than one report and exit, you get an error message "Unable to read drive M:" - sort of thing. The work around we have used is as follows and may help others. Its pretty ugly in concept, but for now, it WORKS. Write the report to a file. Use SYS(3) to get a randomly generated filename. This is important when developing multi-user systems. Use the "RUN /128 COPY filename LPTx: /B" command to copy the report file to the printer. When the "RUN" returns you can delete the file. Don't forget that the extension ".TXT" has been added to your filename. One other point. When you do this, DOS displays "one file copied...". If you don't want this to show, you might try placing the cursor at co-ord 0,0 which will hide under the menu - if one exists. This will only work when the active window is the desktop - if it's a window - it probably won't. Can you also send me a copy of your BIN release prog - it might just be what we need. Thanks, Barry Msg#: 175681 Date: 11-Nov-91 Fm: George Sexton 73237,1665 To: Glenn Casteran, Laguna V 71750,2555 The correct syntax you need on the server is: SPOOL 1 TO QUEUE LASER SPOOL 2 To QUEUE OTHER... This needs to be in your netware AUTOEXEC file so that it gets executed every time you start the server up. One down side to this is you can only spool 5 printers (I think). You might want to refer to the netware CONSOLE commands book under spool. Once you execute the commands at the server, your foxbase apps can then SET PRINTER TO \\SPOOLER\P=2, and everything will work fine. ******** THD205.DBF ******** Fm: Chris Pudlicki [Fox] 76702,1237 To: Bob Reagan 75236,1430 (X) -Bob PRINT is a TSR that is still running when you try to erase the file that it is printing. Hence, the Sharing Violation. --Chris Msg#: 203063 Date: 13-Jan-92 Fm: Bob Reagan 75236,1430 To: Y. Alan Griver 71541,3150 (X) Yag, Tried it again and !COPY ... LPT1 works fine, no sharing violation. ******** THD206.DBF ******** Msg#: 216961 Date: 11-Feb-92 Fm: Rob Ferguson 70534,3420 To: Joe O'Connor 70451,255 (X) Thanks for your reply re capturing to a network printer. This application taught me a great deal about networks as far as locking issues and just when I started getting cocky this comes up. So if I SET PRINTER TO ... will I still need to set an ENDCAP command (I assume that's simply RUN ENDCAP)? - Rob Msg#: 217640 Date: 13-Feb-92 Fm: Joe O'Connor 70451,255 To: Rob Ferguson 70534,3420 Rob, No, you shouldn't need an ENDCAP. On my network, I have a CAPTURE command in all the login scripts (except mine, I use a local printer). The SET PRINTER TO... sends all output to the network printer. A word of caution. I use only two network printers, a check printer and a report printer. Also, I have only two network print ques, one for each printer. If you have alot of printer traffic, (I have very little), you may want to set up a print que for each workstation, otherwise some users may start stepping all over other users print jobs. If two or more workstations are printing to the same print que, and one station pauses to 'think', one of the other workstations may insert output into the middle of the first stations print job. (Actually, the first print job will close, the second workstation will close its print job, and the original workstation will continue the rest of its report in a new print job. The sequence in which they are printed will give the 'illusion' that one stations output is insert into the other stations output.) Since there is _very_ little traffic on my network I don't worry about it, but you may have to! --- Joe %^) Msg#: 215120 Date: 08-Feb-92 Fm: Calvin Hsia 72251,1725 To: JIM HENDRICKS 70313,2123 (X) Jim, <> Actually, SET PRINT TO \\spooler\nb\nff\q= Here notice the nff parameter for noformfeed. Also notice direct output to a queue, for which there doesn't have to be a timeout clause: Novell will fill the queue, and submit it to the printer only at the end of the job (SET PRINT TO). Timeout is only used to tell Novell when to decide that the print job is done, and to submit it to the printer. Msg#: 215171 Date: 08-Feb-92 Fm: JIM HENDRICKS 70313,2123 To: Calvin Hsia 72251,1725 (X) Going without a timeout then queues the whole print job then and doesn't start printing until the job is done being sent. Specifying a timeout seems to cause the job to start printing even before the whole job is in. This is very important for some of our reports since some of these reports take hours to process and print if the printing is occurring simultanious(or almost) to the processing than the printing has a couple hours head start instead of 2 hours process, 3 hours print, you get 3 1/2 hours process and print. The timeout seems to provide for this. putting in \nff in the spooler command didn't do me a bit of good. If I issue a capture and then set print on ? 'this is a test' and set print off, I get one line to the printer. using set printer to \\spooler\nb\nff\q=printq_0 still puts a form feed after the "this is a test". By the way, this is on the Nov 11 build. Msg#: 215245 Date: 08-Feb-92 Fm: Calvin Hsia 72251,1725 To: JIM HENDRICKS 70313,2123 Jim, The purpose of the queue not printing til endjob is so that jobs don't get interrupted by other users sending jobs. Using timeout will tell Novell that the job is done, somebody else can sneak a job in, and your long report continues output, and you get merged printjobs! Are you using a FP Print driver? Seems like some sort of config problem here.Msg#: 215706 Date: 10-Feb-92 Fm: John Sinnott 72461,2751 To: JIM HENDRICKS 70313,2123 (X) Jim, a quick thought. If you don't mind the report coming out in pieces, try a counter in your "new page" routine. After every 20 pages, say, reissue your "set printer to \\spooler\etcetc" statement and reset the counter. If your are using "report form" etc., the counter and "set printer" stuff will have to be in a UDF. You might want a page count at the end of the report to remind the user to look for any tag ends. Msg#: 220954 Date: 20-Feb-92 Fm: Andrew Hargreave [RDI] 72520,3705 To: Jim Verret 73670,1361 (X) Jim, I uploaded a file yesterday into lib 2 (i think) called ENDSP.ZIP. It contains a file called ENDSPOOL.PLB and you use by: SET LIBR TO ENDSPOOL =EndSpool() This works for non-novell networks that are similiar to 3Com, mainly LanMan. D/L it and see if it solves your problem. agh3 ******** THD07.DBF ******** Msg#: 270456 Date: 06-Jun-92 Fm: Eddie Wright 100012,1743 To: Ron Bequette 70400,1715 Ron, In addition to the points above, if you are using Netware you can add a TI=nn parameter to your capture command to set the time-out value (in seconds) that netware should use. This tells Netware that if it receives no printing for nn seconds, it should consider that particular job finished. You didn't mention whether you're using Netware, but I hope this is useful information, Eddie Wright Msg#: 264103 Date: 22-May-92 Fm: David Wohlferd-Pinnacle 72600,137 To: Bob Fronke 73020,3613 When you send a job to a printer on a Novell network, the job is captured to a file. When the print job is complete, the entire job is sent to the printer. As far as your program can see, the print job completed successfully as soon as it goes to the file. The network will then start printing the file to the printer. If it runs out of paper, it does _not_ communicate that fact back to the program. Therefor it seems unlikely that the error you are getting is truly an out_of_paper error. What I would guess is that you are running out of disk space. Remember, Novell is queueing these files to disk. By your description, you are printing 'multiple copies of many documents.' Can you check from another machine to see what is happening to disk space? dw Msg#: 271449 Date: 08-Jun-92 Fm: Calvin Hsia 72251,1725 To: Martin Schiff [CONSULT] 76702,1355 (X) Hi Martin, Maybe you could try this: set print to \\spooler\nb\nff\q=pan1 && note lower case ?? This works for me, although using Novell 2.15c It seems that this is different across Novell versions. Also, you may want to check if you have a default print job, that issues a Banner?? Msg#: 272301 Date: 10-Jun-92 Fm: Dave Watkins [Fox] 76004,2575 To: Nick Scariti 73427,115 Nick, Sorry for the delay in my response, but I have been trying to catch up since getting back from vacation. Concerning the NFF option, it has been submitted, but I obviously don't have any say as to what goes into patches. Concerning the Netware default QUEUE settings being ignored. I tested this out on our Netware 2.15 with DOS 5, and didn't see any problems with it. Could you be a little more specific as to what you mean by default queue? Finally, I have been running some tests on SET PRINTER TO \\SPOOLER\q=tech\NB etc.., and there seems to be some major problems if you don't first issue a CAPTURE command. The NB, C, B=, F, parameters seem to be ignored, regardless of the version. I have submitted these as bugs to the developers. If I missed something, please let me know. Dave Msg#: 262410 Date: 19-May-92 Fm: Joe Gotthelf [DSA] 74017,3670 To: Dave Watkins [Fox] 76004,2575 (X) Greg, If you want to flush the Network buffer, =fclose(fopen("lpt1:")) works nicley (at least with Novell...) --Joe G.