Any compatibility issues between Pyramid systems?

[Eric Bergan]

In article <1871 at esquire.UUCP> jenkins at esquire.UUCP (Colin Jenkins) writes:
>In article <6707 at brspyr1.BRS.Com> tim at brspyr1.BRS.Com (Tim Northrup) writes:
>>Does anyone know if there are any compatibility issues between Pyramid
>>models? [...] is there anything that we would generate on that box that
>>would not work on any other Pyramid system (MIServer, 9040, etc.)?
>> 
>We have 98x's running 4.1 and MIServers running 5.0.  We do almost all of
>our work in the bsd universe.  Our exprerience is that most binaries will
>run on both OSx versions.  There are definite incompatibilities however.  We
>have a ksh (probably) compiled on 4.0 that works fine on OSx5.0 *except*
>under X windows.  A recompile seems to fix the problem.  Any low level "ps"
>type programs (that read kernel structures) probably won't work.  Any 
>program that tries to read /dev/drum will not work on OSx5.0.  Since tty 
>names have changed in OSx5.0, OSx4.x programs that have tty names hard 
>coded into them will break.  The format of device numbers has changed 
>between versions as well, however I know of no specific examples of binaries 
>breaking for this reason.  I know of at least one OSx2.5 binary that ran 
>fine on OSx4.x but not on OSx5.0.

	All of the above are potential cases for incompatibility. I should
point out that there are versions of ksh that seem to have problems, no
matter what. We will be shipping and supporting a version of ksh in
the next OSx release. (RSN)

>I believe that OSx5.0 supports dynamic sizing of open file descriptor tables,
>OSx4.x does not.  A process hoping to open a few hundred file descriptors
>on a 4.x system will be disapointed (yes, they do exist...).

	Actually, this will work in OSx 4.4 (that's when the feature went
in), but not in OSx 4.1 or earlier. All of the processflags() stuff
tends to be aware that it is on a system that can't support it, and
will return an error that the flags could not be set. So the binary
will work on earlier versions, but will not support the enhanced
functionality. Of course, if it has to have that support, then it
can't run at all. But at least we don't core dump or panic the machine.

>In addition, OSx5.0 adds at least one more system call (perhaps) more, and 
>running 5.0 binaries on lower releases is not something I'd recommend.

	I don't have a definitive list in front of me, but the system
calls that have been added in OSx 4.4 and OSx 5.0 have been cleverly
mapped on to trap vectors that on earlier versions of OSx will return
error codes, rather than a more obnoxious behaviour. The user side of
the system calls have been written to look for this. And things such
as the string manipulation and memory move routines adapt to what they
have to work with, and so will work on earlier versions of OS that do not
support the block move instruction.

>Also, there are bug fixes in the OSx5.0 libraries that may not have made it
>into your 4.x libraries.  If you don't recompile your programs for OSx5.0,
>you may be running with 4.x library bugs on the 5.0 system.

	Definitely. Also, an OSx 5.0 built binary is still subject to OSx 4.x
bugs in the kernel if run on OSx 4.x.

>My advice is to recompile for both systems and save yourself some potential
>headaches.  Even when something appears to be running well on both systems,
>you may find some special situation that causes a failure as we have with
>our ksh under X windows (as one example).  If you must mix binaries, don't
>do it downward (don't run 5.0 binaries on 4.x, run 4.x on 5.0).

	I should point out that most of the cases above are fairly rare.
There are many sites that are building under OSx 5.0, and successfully
running on OSx 4.x machines with those binaries. We've even QA'd products
like the DBMS's that were built under OSx 5.0, but re-QA'd under OSx 4.4
so we could certify that they would work on the earlier OSx. We also
routinely go the other direction, taking DBMS's built under, say OSx 4.4,
and were QA'd by Pyramid on OSx 5.0.

	Of course, device drivers, and other kernel installed modules are
an entirely different matter...

-- 

					eric
					...!pyramid!eric