Why are some products still using VMSINSTAL.COM

[whcox53]

Given that the Polycenter install program was introduced 19+ years ago I find it confusing that some products have still not been converted to use it. It means having to check two places to get an inventory of product information. And two methods of official installation. I am fairly familiar with VMS and I find it confusing. My concern is that it sends the wrong message to any new prospective customers as well as existing ones that there is no long term strategy for VMS. Of course, HP should have solved this problem, but they clearly weren't interested in long term. I worry that some customers may feel the same way about VSI.

I do understand that it all comes down to resources, but it seems like simplicity should pay off in the long term.

[whcox53]

I would have to agree with you. As I said in my initial post I understand it all comes down to resources and prioritization. Except perhaps for system managers it is something that most customers never see. I was trying to understand the reason it was never resolved .

[roberbrooks]

> Given that the Polycenter install program was introduced 19+ years ago I find it confusing that some
> products have still not been converted to use it.

It was about 30 years ago that PCSI was released.

The short answer is "don't fix something that isn't broken".
Yeah, PCSI is more versatile than VMSINSTAL, but who really cares how the bits get on the system?

It's the same reason that when VSI got all the code from HP in 2014, I was surprised to learn that many (most?) layered products were still being built for IA64 with an Alpha-hosted cross-compiler. It really made little difference back then, because the cross-compilers, using the GEM back end, were optimizing (a marked difference than what we have with
the non-optimizing cross-compilers for X86).

The cross-built stuff worked, and it wasn't viewed as a good use of resources to spend the time to convert the builds to be native.

VSI (mostly me) did convert all those cross builds to native for IA64.

Which, of course, was a requirement for getting them to X86.

The use of VMSINSTAL on X86 led us to discover a weird problem in X86 process scheduling after a resource wait.

VMSINSTAL will create a subprocess for certain operations, and all DCL symbols are copied to the subprocess via a mailbox. Under certain conditions, the subprocess would run out of BYTLIM and would need to be stalled until the reader emptied some of the mailbox. However, what we discovered was that the process was never restarted, due to an error in the scheduler.

Yeah, we would have found this problem eventually, but it was the installation of FMS-RT via VMSINSTAL that alerted us to the problem.