Previous: Reasons for Porting Up: Introduction Next: TBD List
When porting an application or subroutine, keep portability uppermost in your mind. In some cases, this will mean sacrificing some performance to achieve portable code. As long as the performance sacrifice isn't too great, this is acceptable. CPUs are getting faster and faster all the time. A typical Unix workstation has several times the CPU performance of the VAX 8650s that MIPL currently uses. Some pretty big performance hits could be taken before they would be noticed.
On the other hand, in the near term, MIPL must still use the VAX 8650s. Since code you port goes immediately into the development system when you deliver it, and eventually becomes operational, it will be used on the same hardware as it is currently. Slowdowns here will be noticed. Some VICAR subsystems have performance requirements; these must continue to be met. This may be modified somewhat based on circumstances, but try to keep performance in mind. If you cannot bring performance up to the required level, then you might need to consider two separate versions, one for VMS only and one that's portable. This is highly discouraged, as it makes maintenance twice as hard, but it may be an option in some cases. Eventually, when MIPL gets faster VAXes and more use is made of Unix machines, the performance hit of the portable version will be acceptable and the VMS-only version will be removed. Note, however, that even if you do create a VMS-only version of the program, it still must be able to read files written on foreign machines, as all programs must. Therefore, you cannot always just use the current VICAR code as the VMS-specific version.
A secondary goal of the port is to improve the maintainability of VICAR programs, including the cleaning out of the SUBLIB subroutine library. A little time spent making a program more maintainable will pay off many times over in reduced maintenance costs in the future. Don't just throw away old code gratuitously. There is much to be said for keeping code that works and has been tested over 15 years. However, if a genuine opportunity arises to improve the code, please do so.
There are many routines in the current SUBLIB that are not really needed, or that almost duplicate other routines. For this reason, a wholesale conversion of all SUBLIB routines is not being performed. Rather, subroutines will be ported as they are needed during the conversion of application programs. That way, SUBLIB will get cleaned out in a relatively painless way.