Very Computer

Problem:        remote printing in UNIX SVR 4.0 1.0 i860

a) local system is BSD, remote system is SVR4:

   The command

        $ lpr -P_remote_system_ _file_

   will send the job to the remote system. No  local  queue  or  log
   files  are kept. If you want to know about the status of your job
   you have to issue

        $ lpq -P_remote_system_

   This will send a "send queue state" request to the remote system.
   If your job is still queued you will see it; if it is not  it  is
   expected to be done.

   There are no problems in this direction.

b) local system is SVR4, remote system is BSD:

   The command

        $ lp -c -d_remote_system_ _file_

   will send the job to the remote system.  The  job  stays  in  the
   local queue marked as "request accepted on remote system". A

        $ lpstat -tl

   will report "_remote_system is idle", "_jobid_ queued  remotely".
   No  attempt is made to ask the remote system about this job. This
   state  will  never  change  since  lpsched/lpNet  will  never  do
   anything  with  this job. You can't even cancel it. You will have
   to remove it by hand.

c) local system is SVR4, remote system is SVR4:

   same problems as b)

--------------------------------------------------------------------

How is this supposed to work? I could think of two ways how  this
could be done:

(1) lpsched/lpNet should wait for the completion of the  job  and
    then  cleanup their log files. It was easy to locate the code
    where the RS_SENT bit is set. I was not able to find out when
    this bit would be reset or the RS_PRINTED,  RS_DONE  or  such
    bits would be set so that the local queue would become empty.

    There is no provision for a "job done" message in the  (BSD-)
    lpd-protocol.  Thus  "waiting"  means that lpsched/lpNet will
    have to send "send queue state" requests from time to time to
    see if the job is done.

(2) lpsched/lpNet should delete all local queue entries when  the
    remote  system  has  accepted the job. A call to lpstat would
    cause lpsched/lpNet to transmit a "send queue state"  request
    to the remote system.

Is there anybody who has an idea how it SHOULD work? Or who
even got it working? Any help appreciated!

Thanks in advance,

Wolfgang

==================================================================
Name    : Wolfgang Denk
Company : PCS GmbH, Pfaelzer-Wald-Str. 36, 8000 Munich W-Germany.
UUCP    : ..[pyramid ;uunet!unido]!pcsbst!wd  (PYRAMID PREFERRED!!)

###################################################################
####    The first thing we do is kill all the lawyers.         ####
####    (Shakespeare. II Henry VI, Act IV, scene ii)           ####
###################################################################

Hi,

I am relatively new to UNIX serial I/O at the application level.  I am
currently porting a fairly involved UNIX (Apollo SYSV based) product (Many
processes, SYSV IPC w/ message queues).  I am having some problems
doing serial Input/Output using the read(2) and write(2) system calls.

System
------
Open Desktop 1.0.1 and Open Desktop 1.1.1
i386 with 25Mhz
20 MB RAM
Standard COM1: and COM2:
                - Using the non-flow control devices tty1a and tty2a
                - XON and XOFF not used
Ethernet (wd8013E)
Super VGA (Tecmar VGA/AD)
Adaptec SCSI and 300MB Hard Drive

The system is communicating at 9600 baud with a fast hardware device.  I have
heard rumors that ODT may have problems with 9600 baud modems.  If this
is true, a reply from SCO would be appreciated.

Symptom(s)
----------
write(2) is not returning a -1 but is also not sending all of the data
I ask it to.  The next call to write(2) never succeeds in sending data
(verified with data line monitor).

Possible Causes
---------------
        - Serial overflow (Docs. indicate I/O can be lost, is* also
                           a symptom).
        - Multiple writers to same COM: port.
        - SCO Serial driver bug
        - Some sort of flow control is being used even though it is disabled.

Code in question
----------------

 alarm(30);
  if ( (rc = write(fd, &buf->pad[VTK_PAD_SIZE-1], size)) != size)
    {
      /* log the error and return */
      if (rc == -1) {
        fprintf(stderr,"\n\rvtko: Write Failure\n\r");
        perror("vtko");
      } else {  <-------- rc == 0, errno == 0
        fprintf(stderr,
                "\n\rvtko: Tried to write %d bytes, only sent %d bytes\n",
                size, rc);
      } /* else */
      alarm(0);
      uel_log(vtk_my_name, VTK_COM_WRITE_FAIL, ZERO, params);
      return;
    } /* if */
  alarm(0);

Any possible help and/or suggestions and/or authoritative answers from SCO
would be appreciated.

Reply via net, fax,  and/or phone.

                                                        Jerold A. Abramson

                                                        Software Engineer
                                                        Voicetek Corp.

                                                        ! addr: ...!uunet!world

                                                        FAX: 1 (508) 250-9378
                                                        Voice: 1 (508) 250-7957

Quote:>         fprintf(stderr,"\n\rvtko: Write Failure\n\r");
>         perror("vtko");

Alternative: save errno before the fprintf and restore it afterwards.

Moral: never call perror() except immediately after a failed system call.
--
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

One other thing:  using COM1 and/or COM2 on a PClone requires the main
processor to handle it.  At 9600 baud, you're asking for real trouble.  A
"smart port board" would be a better choice... that is, if you can find one
that's reliable enough.

++Brandon
--
Me: Brandon S. Allbery                   KF8NH: DC to LIGHT!  [44.70.4.88]

uunet!usenet.ins.cwru.edu!ncoast!allbery