[Info-vax] Itanic is a dead end : IBM

[Keith Cayemberg]

On May 31, 5:19 pm, "Richard B. Gilbert" <rgilber... at comcast.net>
wrote:
> On 5/31/2011 10:02 AM, Bob Koehler wrote:
>
> > In article<1ca5f619-fc08-4f65-be4c-b66129575... at x1g2000yqb.googlegroups.com>, IanMiller<g... at uk2.net>  writes:
>
> >> HP will continue to support HP-UX and OpenVMS compilers for FORTRAN
> >> and C/C++ on I64.
>
> >     That's good.  How about develop?  Fortran-95 is getting a little long
> >     in the tooth.
>
> What do you need to do that Fortran-95 cannot/will not do?

Our OpenVMS manufacturing customer has a continuous code development/
enhancement/maintenance history starting in 1987 to the present day
using Fortran 77, COBOL, C, C++ (often using 3 or more languages to
program the same image), and Perl, DCL, RDML, SQL BASEstar, and
Datatrieve. And, we have at least 2 years of development/enhancement
projects in the pipeline. Regardless of the public opinion over
whether any of these languages "are getting long in the tooth", the
applications they build for our client represent man-centuries of
investment in special purpose built and vetted functionality that
works exactly as needed.

The bits making up the code, compilers and images do not age, and do
not have an age.

"Bit decay" is a popular myth that helps the standard software sales
carousel to keep turning.

The fitness of the application functionality to "changing business and
manufacturing condition"s can cause the "functionality" to age in the
sense that code enhancements are needed (providing my company with
projects), but the functional enhancements themselves rarely if ever
dictate a migration to a newer version of a tool or language. Such
upgrades are almost always dictated by outside circumstances such as
the need to migrate to newer HW platform. Because the applications are
continually enhanced, their functionality is actually "state-of-the-
art" even when many of the tools and code modules used to build them
are decades old. In fact the custom functionality still beats the
popular industry standard applications that some SW vendors try to
leverage into the factory.

For example:

One of our customer's factories were scheduled to replace a production
planning application on OpenVMS with an SAP module in April. After a
couple of months of production losses due to relatively poor SAP-based
planning, the customer has now returned to the custom built OpenVMS
based solution (which is also partly developed in Fortran 77). They
now intend to stay with the more efficient reliable and cost-effective
old mission-critical solution for the foreseeable future.  Only an
extreme outside circumstance (i.e. uninformed deluded manager, or
sales inspired vendor support decision) has a chance of changing this
status quo anytime in the future. SAP has no chance to offer an
equivalent capability without a major overhaul of their production
planning architecture to match the special needs of our customer. If
SAP were to do this for every customer, they will have a product too
complex and heavy to adapt or compete with the custom solution. Many
would say that SAP already (long ago) went much too far in making many
of their functional modules much too complex for many individualized
solutions.

Cheers!

Keith Cayemberg