Creating a PCSI installation kit for Alpha and IA64

[Jeremy Begg]

Hi,

I have been working on an application which is very close to being ready to ship, and the only things remaining are the documentation (!) and the installation kit. I have decided to use PCSI for installation purposes. I have used VMSINSTAL in the past but PCSI looks like it is easier to use for both the developer and the system manager.

The problem I've run into is, how do I provide a single PCSI kit for both Alpha and IA64 but which gives the installer the option of installing only the architecture-specific components? One way would be to provide two kits but that approach doesn't really suit my purposes very well.

There doesn't appear to be an IF test or an OPTION test which allows you to check the hardware architecture. You can check the "HARDWARE PROCESSOR" which corresponds to the HW_MODEL item for $GETSYI, but as far as I can tell you can only test for specific values, not for a range of values. (VAX is 0-1023, Alpha is 1024-4095, and IA64 is 4096.)

I worked around this by having an EXECUTE PRECONFIGURE step to run a DCL procedure which checks f$getsyi("ARCH_NAME") and ask some questions of the user, but this leads to confusion because PCSI then says "This product has no options" (or something similar).

And the EXECUTE PRECONFIGURE didn't quite work anyway: I wanted it to define some logicals to direct PCSI, but it seems the logicals aren't seen by PCSI -- so what table should I be defining them in?


Thanks,
Jeremy Begg

[David B Sneddon · Accepted solution]

Jeremy,

I believe that the latest LD driver kit is
multi-platform, maybe grab that and have a look
at the contents.
As far as logicals, PCSI uses subprocesses so I
would expect that you would need to use the JOB
table.

Dave

[Jeremy Begg]

Hi Dave,

Thanks for the LD suggestion, I'll try doing it that way. (It checks which operating system has been installed, i.e. "DEC AXPVMS VMS" or "HP I64VMS VMS".)

Thanks too for the logical names suggestion, yes you're probably right and I should have realised it would have to use the JOB table.

(As always, what isn't documented would fill books :-)

Regards,
Jeremy Begg

[Jeremy Begg]

Just FYI (or FMI) ... the test seems to be useless unless you want to test for a particular VAX model -- because the PRODUCT PACKAGE command rejects any attempt to refer to a model number greater than 255!

[Hoff]

The VDE kit on the Freeware is triple architecture, IIRC. You should be able to see the relevant pieces of the kit, though the PCSI package command isn't there.

The key for getting the kit to work for some of the PCSI releases was to avoid using the blocks beyond if-then-endif; to avoid the else structures. (That may well have gotten fixed.) And I preferred to have architecture in the kit stored in a subdirectory, and the source of the file is visible in the kit files. This means the PRODUCT PACKAGE command was fairly involved.

If you're stumped and can't sort this out, let me know; I've a multi-architecture product kit I've been working on for Lua and can post up the relevant pieces of that to the web site.

Stephen Hoffman
HoffmanLabs LLC

[Jeremy Begg]

Thanks Hoff, the VDE kit is a good example although it doesn't quite do what I want.

My application has a directory structure like this:

[product]
[product.COM]
[product.DOC]
[product.LOG]
[product.ALPHA_EXE]
[product.IA64_EXE]

and the intention is that the installer will specify /DESTINATION=dev:[000000] (so that the application lives directly under the MFD).

It seems to me there are four scenarios and all of them have problems!

1. Always install both IA64 and Alpha images, regardless of the system architecture and cluster membership. (Not desirable in a standalone node or a single-architecture cluster.)

2. Use a PRE-CONFIGURE procedure to determine what images to install and define a logical name to direct the installation process. This works but PCSI tells the user "This product does not have any installation options" after the user has already answered my questions, which is confusing.

3. Always ask if Alpha or IA64 images should be installed (e.g. via a pair of OPTION statements). This works and is simple, but potentially annoying. I'm not against the idea however, especially if the defaults for each OPTION are set appropriately.

4. Have the FILE statements for each architecture specified twice in the PCSI file: once for the "native" architecture and once for the "other" architecture. This is probably best from the user experience perspective (only one question to answer) but a potential maintenance problem.

Regards,
Jeremy Begg

[Hoff]

[Reposting this message, as ITRC tossed the first submit of this posting.]

Somewhat counterintuitively, it can sometimes be quite beneficial to take away installation options. To force a particular configuration or location, or directory structure. (OpenVMS lacks a bundle construct, which would be another approach to this end.) This tends to make it easier to support and configure and test the package, and easier to code the package, and (usually) makes the package more reliable.

Here, I've tended to install once per system disk, and to "lock" the installation target and directory structure. To use a facility prefix for a couple of core files (usually some combination of product login, startup or shutdown tools) and to have the rest in "private" directories out of the main system directories and (usually) either a top-level on the system disk or within the system common and specific root structures. For some applications and requirements, there might be the need to run a configure tool on each node in a rooted cluster.

Some thoughts on kitting and kitting tools and kitting procedures:

http://labs.hoffmanlabs.com/node/861

For the shared files that might be used "across" system disks in a cluster, those are accessed via logical names akin to SYSUAF and RIGHTSLIST and other such. The same way that OpenVMS itself deals with this case.

I've tended to have tools that build the kit files from a database; to get rid of the manual steps and the multiple data sources where I can. This also makes it easier to embed generation numbers and ECO kits, and (if you get to needing to detect corruptions or deletions or such) to have an easily-automated way to verify using SHA-2 or such with what's installed. For a semi-related discussion of how this might be implemented from XML, see:

http://labs.hoffmanlabs.com/node/52

It's trivial to create the PCSI installation files entirely under program control, and to then trigger the appropriate PCSI PRODUCT PACKAGE stuff.

The one-plus here with the design of your kit and your installation directories is to follow the model that Oracle Rdb has set forth with its multiversion support; that's the best approach I've seen (on OpenVMS) that deals with multiple versions within one environment. If that sort of capability is required in your environment, of course.

Stephen Hoffman
HoffmanLabs LLC

[Jeremy Begg]

Thanks Hoff, that's food for thought. I had been wondering about automated tools for this stuff and the XML looks like an interesting approach.

Regards,
Jeremy Begg