derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") (09/29/89)
Here's a minor SR10 gotcha to be aware of, if you do software development. Someone at Apollo apparently likes the common C paradigm of defining a compiler pre-processor variable in header files, then testing the variable to avoid repeated use of the contents of that file. At SR10, all the /sys/ins/?*.ins.pas files have such a variable. If the same file is included more than once in the same program, the second and subsequent includes are effectively ignored. Of course, this is NOT upward compatible! The scope of compiler variables is not the same as the scope of identifiers in a Pascal program; hence programs which were just fine at SR9.7 may not compile at SR10. Now, this isn't a real big deal - it just took the engineer involved a couple hours to fix the code ONCE he figured out what was going on. And I can see where someone might argue that this is enough of a beneficial change to justify some inconvienence. But it'd sure be nice if the release notes said something. In generl, though, I can't complain too much about migrating to SR10. We've converted about 200,000 lines of code without too much difficulty - the one major problem (and one which we still have not totally resolved) is that the radical changes in how virtual memory is implemented cause major consternation for some of our applications (Pre-empting the obvious question, by radical changes I am refering to the fact that at SR10 address space is mapped to disk at time of creation, rather than at use. If you have data structures designed for the former paradigm, you're not sitting too well for the change). Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com