Can anyone comment on IBM Xenix v2.0?

[Bill Vermillion]

In article <FEZAY05 at xds13.ferranti.com> peter at ficc.ferranti.com (Peter da Silva) writes:
>In article <1991Apr24.051935.17997 at bilver.uucp> bill at bilver.uucp (Bill Vermillion) writes:
>> I specifically remember that in the ioctl area you could not 'and'
>> values with existing values, you had to set them explicity.
 
>I can't parse this. Could you explain?

 Hm.  I must be talking in shorthand again.

 Now this is from memory, and it was about 4 years ago.  I wrote the code
 on uPort's SysV.2 and ported it to the IBM Xenix box.  (the code also ran
 on SCO Xenix).

 I was saving the state of a tty and then setting new values.  In fact I
 was using the Bach book as a guideline, as I was trying to talk to a radio
 modem.

 I just looked for the sources and can't find them handy.  Probably stored
 on some disk somewhere.  This was a couple of machines ago.

 In the ioctl area I was taking the state of the tty and anding 
 with something like.

     newtty.c_(someflag) &= (somevalue).

This worked on both the uPort and SCO but failed on IBM.  After setting two
machine up side by side, running the code and then doing a stty
<that_terminal   we found that the new values were being anded with the
original values on uPort and SCO, but the new values were replacing the old
values on the IBM version.  It did not work as documented.  Took some
hairpulling to find that one.

>> Also the creat call wouldn't use it's arguments properly.
>
>Details?

>
Later on, same machine and same program, we were taking the values that
were coming in continually from the radio modem, and writing them to files.
These modems were battery power, and perhaps had solar recharge.  They were
used to send transmissions from oil pipeline transmission stations out in
the boonies back to civilization.

Using the creat call  like this

  fd = creat("file",0666)

  The file wasn't being created with those permissions.  This time we
  found that the creat call was being anded with the permissions of the
  user running the progam.   So to get around this one we save umask, set
  umask to 000, ran the program, and restored umask.

This code ran fine on the two other machines.  I just couldn't figure out
what I was going wrong, because it would work away from the site and not at
the site.   The "desperation attempt" of bringing in the other machine was
what pointed out the problem.

The only other thing that ever go me as bad was working on an old Z8000
based machine with Unix III, whose compiler would NOT strip the high bits
on incoming serial from serial device metering delivery on a propane truck.
Believe the machine was an Onyx if memory serves.

This one would sign extend all the odd (or perhaps it was even) characters
from a 7bit to 16 bits with the high bit set.   So every other character in
the set was a negative number

 
>I believe IBM Xenix 2.0 is based on System III, so you might just be
>seeing older behaviour and interpreting it as being broken.

Okay - now that I have described it, was it broken or older behaviour.  I
suspet the former.    I remember being at one of the introduction of Xenix
2, and IBM was proud of the fact that is was "supported".  Xenix 1.0 was
issued as is, no support. No nothing.   As I mentioned in the preivious
post however, their manuals were among the nicest.

Multi color printing and the order and action of all the switches was
diagramed.    Very nice.  The AIX manuals I have seen are similar in
concept but much more poorly executed.


-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill at bilver.UUCP