paul@moore.com (Paul Maclauchlan) (08/16/90)
[Note: posted for a friend...] Geoff Coleman (geoff@edm.uucp) wrote: >I came across a problem today with uux. On our System V (actualy CTIX 6) >we do remote prinitng by putting the line > > uux -c machine!lp !$file > >in the interface file in place of the usual cat $file line. > >When sending files to the 6000 for this it returns a message to uucp account >that the spooler can't find /usr/spool/uucp/.Xqtdir/<filename>. Any ideas on >this one. As well in there documentation they say that > >uux -C machine!command file operates on file on the local machine. Does it >not need a ! in front to tell it it's on the local machine????? > >p.s. the solution to my first problem was to have uux takes it input from stdin > >ie. cat $file | uux -c - machine!lp I have the exact same problem using UUX to print between two RT's!! The answer to your easy question is that putting the ! in front is optional since in a case like with printing, no "machine!" assumes the current machine. I have reported this to IBM as a problem with AIX 2.2.1, however since there is an effective work-around I don't think they are spending a lot of time trying to solve it. Some additional information that might help you is this: I determined that the file IS being copied across to the remote system to be printed because I started a small loop to copy all files in /usr/spool/uucp/.Xqtdir to somewhere else and THERE IT WAS! The problem seems to be that the uuxqt process passes the job over the print daemon and then removes the data file before the print daemon has a chance to print it. It also seems to be a timing thing since once in a while it did work for me. It seems now that it is a fundamental conflict between the uuxqt jobs and the queuing system since it has been propagated to the RS/6000. I suggest that you submit the problem to IBM for AIX v3 and see if they get any further with it. Scott McCambly The Braegen Group Inc. (...!uunet!attcan!telly!moore!bragrt!bragotrt!scott) -- .../Paul Maclauchlan Moore Corporation Limited, Toronto, Ontario (416) 364-2600 paul@moore.com -or- {...!uunet,...!telly}!moore!paul "If the groom would have known he'd have had a fit"/EJ&BT'83
lzm@mace.cc.purdue.edu (Chris McCoy) (08/20/90)
In <1990Aug15.221949.5492@moore.com> paul@moore.com (Paul Maclauchlan) writes: >[Note: posted for a friend...] >Geoff Coleman (geoff@edm.uucp) wrote: >>I came across a problem today with uux. On our System V (actualy CTIX 6) >>we do remote prinitng by putting the line >> >> uux -c machine!lp !$file >> >>in the interface file in place of the usual cat $file line. >> >>When sending files to the 6000 for this it returns a message to uucp account >>that the spooler can't find /usr/spool/uucp/.Xqtdir/<filename>. Any ideas on >>this one. As well in there documentation they say that >> ...[problem and analysis deleted]... >I determined that the file IS being copied across to the remote system to be >printed because I started a small loop to copy all files in >/usr/spool/uucp/.Xqtdir to somewhere else and THERE IT WAS! The problem seems >to be that the uuxqt process passes the job over the print daemon and then >removes the data file before the print daemon has a chance to print it. >It also seems to be a timing thing since once in a while it did work for me. >It seems now that it is a fundamental conflict between the uuxqt jobs and >the queuing system since it has been propagated to the RS/6000. I suggest >that you submit the problem to IBM for AIX v3 and see if they get any >further with it. We have done much with remote (UUCP) printing here and have had similar problems with other versions of UNIX. Our experiences (with other system V machines) have shown that the problem lies not in UUCP, but instead lies with 'lp'. In general the 'lp' command does nothing more than prepare a queue entry -- the lpsched does the printing. And 'lp' usually does not spool a copy of the file to be printed to an 'lp spool area'. So, in the above mentioned case what happens is that UUCP finishes the transfer, executes the command, then cleans up. Later, when lpsched tries to print the file, it's gone. On our other systems, we have 'lp' spool a copy of the file before printing. This also avoids the case of running 'lp' then 'rm' on a file. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris McCoy : INTERNET: mccoy@ecn.purdue.edu Communication Systems Programmer : UUCP: ...!ecn-ee!mccoy Ag. Computer Network, Purdue Univ. : VOICE: (317) 494-8339 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=