Re: Help Needed - Telesoft Telegen 3.2.5 expert VAX/VMS

[rieachus@comcast.net]

On Wednesday, June 15, 2016 at 5:12:56 PM UTC-4, Rick Cottle wrote:
> We need to touch an old project and of course there is very little documentation available (or readily found) and previous contributors move on a long time ago.
> 
> In short, the project is an embedded system built with Mil-Std-1750 built with ADA on a Vax.  We have recreated the project to the point of trying to link but do not have a linker map to go the final step.

If you take the source and feed it to gnatchop for any version of GNAT, you will get a set of files properly named for GNAT compilation.  If you then compile the main program, it will (recursively if necessary) compile all of the source files, and create a make file for that main program.

There may be more than one main program.  If so you can compile them all in a single project and get a make that will create each one.  (Compilation units used by multiple main programs will be compiled just once.)  Can't figure out from the documentation which are the main programs?  Just look for procedure bodies as files, probably without a corresponding specification.

If all of this is Greek to you?  Contact AdaCore (www.adacore.com) and hire them to do it for you.  Personally, I'm retired.  I assume you have access to the Telesoft compiler and a machine to run it on.  Note that if the source is classified that may be the major cost and schedule driver in getting the work done.  In other words, it might be much cheaper to educate one of your own software engineers to do the work.

If there are only a dozen or so source files, it will be an easy task. If there are hundreds?  One engineer can do it.  If there are thousands?  You will need to partition the work among multiple engineers--assuming you need to do more that retarget to a different CPU or operating system.  Why?  You need to recover the information about how the software works that was in the brains of the original project engineers to know how changes will affect the system.

As an anecdote to warn you about the effort involved.  I and another software engineer, both of us very familiar with the software, spent about a month on one change proposal.  After an intense review which lasted all afternoon, we made the software change--changing an "and" to an "or," and ran the test suite.  In other words, learning the software may be the biggest task in any change, and the time to do that will be proportional to the source code size, not the magnitude of the change.

If the source code contains useful comments it will help, even if you can't find the other project documentation. Again though, it will take time to read that documentation.