Retrochallenge 2009
      Mark Wickens
      15-Jan-2009 22:48
                                        Programming 3

      A quick update as I've been programming over the past couple of evenings (on and
      off). Having looked around the internet for some good examples of TCP/IP
      programming using the QIO system services I ended up back on the VAX hard disk:
      examples are installed by default when you install the TCP/IP package in the
      directory pointed to by the logical TCPIP$EXAMPLES:


      $ dir tcpip$examples:*.c



      So I had a play with the QIO client and server example which worked fine out of
      the box. I then copied the client QIO example and started hacking it to pull
      back data from the mirrorbow interface.

      The data exchanged ended up like this:

      Initiated connection to host:, port: 80
      Data sent: GET /ports.xml HTTP/1.1
      Data received: HTTP/1.1 200 OK
      Connection: close
      Content-Type: text/xml
      Cache-Control: no-cache


      The 'Data Sent' line contains a request for the current port status from the IO
      controller. In my case I'm interested in the value set for port 4 as this is the
      port to which my power control box is connected. Each of the lines on this port
      controls a relay that in turn controls a 240 volt IEC connector.

      I wrote some code to decode the bits within the port value and hard coded the
      names of the current equipment connected to the ports to make sure the decode
      was working:

      DS10L    0 DEC3K600 0
      VAX4K90  1 VAX4K60  0
      EXTSCSI  0 ZX6000   0
      LINUX    1 ANCIL    0

      The only real issue I had with the communications I was already prepared for. I
      had looked into TCP/IP a while ago and discovered that coding for a general
      packet stream that can consist of multiple, variable-length packets making up a
      single message is non-trivial (even down to receiving zero length data but
      this still being valid). In the case of the mirrorbow the whole message comes
      through in a single packet - the next read returns a status of SS$_DISCONNECT
      which is the way in which the HTTP protocol works.

      I'll continue developing this application, but again after some initial
      frustrations it looks like it's coming together!