conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (11/18/89)
A query ... An executable (lets call it enp) developed and maintained on an SR9.7 system currently executes in both SR9.7 and SR10.n (n > 0). The application originally allowed users to "taylor" the executable by binding object modules with the executable, resolving previously unresolved names. Routines that were undefined and thus unreachable became reachable if successfully compiled and bind'ed with the base executable. Now, hoever, in the mixed op sys environment, such tayloring is not possible if the user runs in SR 10. My question is: if a user uses the SR9.7 ftn compiler and bind, and if no other libraries need to be resolved, will a "good" executable be generated, even if the user IS RUNNING IN SR 10?? I think so, but don't know if there are some hideous "gotchas" out there, and need some verification before releasing this "solution" to a bunch of students trying to get homework assignments done! Thanks in advance for any insights. -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (11/22/89)
WRT posting <46e6018f.f088@beck.engin.umich.edu>: > An executable (lets call it enp) developed and > maintained on an SR9.7 system currently executes > in both SR9.7 and SR10.n (n > 0). > ... > My question is: > if a user uses the SR9.7 ftn compiler and bind, > and if no other libraries need to be resolved, > will a "good" executable be generated, even if > the user IS RUNNING IN SR 10?? Yes, it can be done; Yes, there are a few "gotchas". We have several packages that do things like this, most commonly it is used in simulation programs. A user interface will collect parameters and then create a Fortran subroutine with them, compile and bind it with a simulation engine, and run the whole mess. Boeing's Easy5w is one example of this. You have to use the sr9.7 version of ftn & bind, of course. To facilitate this, we've installed sr9.7_compatibility versions on the sr10 machines and they end up named ftn_sr9.7 & bind_sr9.7, on the sr9.7 machines, we just create links in /com named ftn_sr9.7 & bind_sr9.7 that point to ftn & bind. Then in the shell scripts we only need to refer to ftn_sr9.7 & bind_sr9.7 and they will work regardless of machine OS type. "gotchas": 1) No imbedded uppercase path names allowed. Fortran programmers are notorious for using the CAPS LOCK key. If you have a sr9.7 program that has these, you may be lucky and be able to find them and zap it with db to convert the text to lower case. In worst case you may need to wrap the program in a shell script with the DOWNCASE crutch set to true. 2) Some unreleased system calls broke between sr9.7 & sr10. User programs weren't supposed to use these, but if they did, then they're dead. 3) There are some potential compatability problems with Fortran unformatted data files created by sr9.7 programs and those run on newer systems. 4) There is a problem (bug ?) with sr9.7 Fortran programs trying to open "unstruct" type text files for formatted sequential reads that causes them to crash. As "unstruct" is the default text file type under sr10, this can be a real problem. There may be a patch out for it. 5) Disk space can be a problem. Under sr9.7 a programmer could dimension a huge array to hold worst case size data, and if the user only actually used a small part of it, it would run with minimal disk space requirements. I saw one program that had 256 Mbytes worth of working arrays, but the typical case that our students ran only needed 4 Mbytes. Under sr10 you need to have all the disk space free up-front or the program won't even start. Dave Funk