Path: utzoo!attcan!uunet!aplcen!samsung!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B Funk)
Newsgroups: comp.sys.apollo
Subject: Re: Rebind of SR9.7 object in SR10.n environment.
Message-ID: <8911220821.AA00632@icaen.uiowa.edu>
Date: 22 Nov 89 07:36:17 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 51

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