tim@brspyr1.BRS.Com (Tim Northrup) (03/15/90)
Does anyone know if there are any compatibility issues between Pyramid models? We develop all of our software on a 90x (and a rather oldish one at that); is there anything that we would generate on that box that would not work on any other Pyramid system (MIServer, 9040, etc.)? We do all of our work in C, currently in the att universe under OSx 4.4c. Thanx in advance. -- Tim -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!crdgw1!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+
karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (03/15/90)
tim@brspyr1.BRS.Com writes:
Does anyone know if there are any compatibility issues between Pyramid
models?
For what it's worth, we run one each of 90x, 98xe, 98x, and 9825, and
have no qualms at all about moving software among them. In fact, when
installing the 9825, I simply restored dump tapes from the 90x, which
was the first to go to 4.4.
--karlcsg@pyramid.pyramid.com (Carl S. Gutekunst) (03/16/90)
In article <6707@brspyr1.BRS.Com> tim@brspyr1.BRS.Com (Tim Northrup) writes: >We develop all of our software on a 90x (and a rather oldish one at that); >is there anything that we would generate on that box that would not work on >any other Pyramid system (MIServer, 9040, etc.)? There are no *problems* that I've ever heard of, but there are a few consider- ations. OSx upgrades tend not to be downward compatible, meaning that an OSx 5.0 binary will not run on an OSx 4.0 system. But the reverse is usually no problem, so long as it isn't a binary that requires intimate knowledge of the kernel. I have OSx 2.5 binaries that work just fine, but an OSx 2.5 version of ps(1) is not going to run on OSx 3.0, let alone 5.0. And since OSx 4.1, the compilers have generated some opcodes that don't exist in machines without data cache; so you cannot run OSx 4.1 on those machines. And *prior* to OSx 4.1, the compilers generated some opcodes that do not exist in the MIServer, and are simulated by kernel traps (and hence, very slow). <csg>
wendyt@cs.washington.edu (Wendy Thrash) (03/17/90)
In article <105575@pyramid.pyramid.com> csg@pyramid.pyramid.com (Carl S. Gutekunst) writes: >There are no *problems* that I've ever heard of, but there are a few consider- >ations. More considerations: 1) The floating-pont format changed slightly from the older machines to the newer ones. This means that some numbers (those with maximum exponent) that were perfectly ordinary numbers on the oldest machines are now NaN or Inf on the newer ones. If you do not have mountains of floating-point data (with fairly wide range) this will probably not be a problem, but it is a consideration. 2) The newer machines round to nearest by default, whereas the older ones always truncated. For details, do man math (or was it man float . . . well, something like that) on a reasonably recent release of OSX. This means that some programs will get slightly different results on the newer hardware.
jenkins@esquire.UUCP (Colin Jenkins) (03/22/90)
In article <6707@brspyr1.BRS.Com> tim@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 do all of our work in C, currently in the att universe under OSx 4.4c. 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. 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...). Signals between 4.1 and 5.0 have changed- under OSx4.1, SIGLOST is 31, but under OSx5.0, SIGLOST=SIGURG, and signal 31 is SIGWINCH. I would guess that 4.1 binaries looking for SIGLOST on a 5.0 system would be looking for window size change signals erroneously and acting on them incorrectly. 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. 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. 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). Colin jenkins@dpw.com jenkins@cs.purdue.edu uunet!esquire!jenkins cmcl2!esquire!jenkins
eric@pyramid.pyramid.com (Eric Bergan) (03/23/90)
In article <1871@esquire.UUCP> jenkins@esquire.UUCP (Colin Jenkins) writes: >In article <6707@brspyr1.BRS.Com> tim@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