CPAN shell with HP Perl on an OpenVMS platform

[john nicoara]

Somebody already (successffully) using the CPAN interactive shell? I cannot get rid of a configuration issue, the external gzip and tar programs.

Doing the manual configuration (o conf init) one have to answer the questions:
"Where is your gzip program?", "Where is your tar program?".
Answering with the path where these programs are, does not work: any 'get' attempt (for downloading a module) fails with "CPAN.pm needs either both external programs tar and gzip installed".
Configuring the two programs with the full pathname (directory+executable name) does not help neither.

AND: on VMS we have vmstar, not tar, and the call syntax is different compared to a unix platform, for eg. the ODS2 switch. How could I tell CPAN which switches to use?

[Steven Schweda · Accepted solution]

I know nothing, but I'd assume that if some
program expects a _command_ to work, then
you'd need to do something like defining an
appropriate foreign command symbol. For
example:

gzip :== $ DEV:[DIR]gzip.exe

> AND: on VMS we have vmstar, [...]

Isn't there a GNU "tar" in the GNV package?
Otherwise, you might be able to define:

tar :== @ DEV:[DIR]vgtar.com

where vgtar.com is a command procedure which
runs VMSTAR after rearranging the arguments
appropriately. (Given DCL's limitations,
this might be tough to do except in simple
cases.)

And if the program expects to build a working
gzip-tar pipeline, as would be common on a
UNIX(-like) system, then you're probably in
even more trouble.

[Willem Grooters]

What PERL version?

It seesm that this CPAN modules are included in the latest version (5.10?)

[john nicoara]

@Willem:
HP is still at 5.6.8 perl version... CPAN module does belong to the package, but is hard to make work its shell...


@Steven:
The global sysmbols for gzip and tar are well defined, but it doesn't help!
In fact the shell configurator asks "Where is your gzip program?" and not "What is the command for?"
I tried all possible answer alternatives:
-symbol names
-directory where the executable is located
-define commands (by means of .CLD file) for them.
Trying a 'get' of a module ends up with different explanations (depending of the chosen alternative) such as "CPAN.pm needs either both external programs tar and gzip installed", "%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character", etc.
I fear, your prevision "...then you're probably in even more trouble" is more than true! and the best way to go through is manual installation of every module I ever need (as I've done till now...)

[Craig A Berry]

In the last ten years or so, I've heard only very rare reports of getting the CPAN module to work on VMS, and only after extensive additional custom development. My suggestion with CPAN and the HP-supplied Perl 5.8.6 (not 5.6.8, which never existed) is to simply not use it. Just build whatever modules you need one at a time, and if you need to write a little DCL to semi-automate it for a particular set of modules, then so be it.

With Perl 5.10.0 on an ODS-5 build disk with OpenVMS Alpha v8.3, I've had some success with CPANPLUS. For example, I did

$ cpanp install "DBI"

and had the most painless experience I've ever had getting that module to build.

[Hoff]

I've had some success with loading perl modules using the standard CPAN tools. Yes, during a reasonable chunk of the perlmod installations I'd tried, something somewhere within the particular perlmod did blow its cookies, and I'd then to tweak a script or two. But it was usually tweaks. Not zip and such.

I did have zip, gzip and the various and sundry other current pieces located in the default path. Usually, I treat these tools as standard system images, and accordingly load them into sys$common:[sysexe] and set up the DCL$PATH list accordingly. Where that is not permissible, I've used another (shared) directory and loaded that into the DCL$PATH list.

In aggregate, this DCL$PATH definition means that stuff that issues "zip" finds zip.exe, and the procedure then (for this part) just works.

I've gotten away from the DCL foreign-command symbols, as they're seemingly more often more trouble than they're worth. (And that these and other table-stakes tools are not in SYS$SYSTEM in the standard distro was why I had been contemplating creating a PCSI tool kit for Freeware V.next, was the "exclusion" of these to be continued within the OpenVMS base distro. But that's now fodder for another and parallel universe.)

[Craig A Berry]

Just wanted to clarify that "the standard CPAN tools" do generally work. In this context, CPAN is the Comprehensive Perl Archive Network. Specifically, here's how those tools work:

$ perl Makefile.PL
$ mms
$ mms test
$ mms install

for each module you want to install. Or a particular module may have a Build.PL instead of a Makefile.PL, and may need to have Module::Build installed (which does mostly work on VMS but is not in the HP-supplied Perl).

The thing that I recommended not trying to use (and the thing that John is looking for) is CPAN the module, which comes with its own little command language for downloading, building, testing and installing modules. It does dependency tracking, so if you want a module that depends on six other modules, you can download, build, test, and install all of them with one command. Or you could if it worked on VMS.

If that type of capability is important, you'll want Perl 5.10.x and the CPANPLUS module that is included in the standard distribution.

[john nicoara]

Thanks to all these people debating around the VMS universe of Perl & co!
Indeed, it was/it is for me the most painful task I ever had, doing a real application work in such an environment. I've painly walked through "perl Makefile.PL, mms/mmk, test and install" sequence for the extra-modules I needed; never having a test succeeded 100%. And I was such naive hoping CPAN would have a better fate?

As I'm tight with the scheduling, I have to keep my old way, continuing to experiment with alternatives in my pastime. How soon HP will come out with a (Perl 10.x + error-free working CPANPLUS) on her VMS platform, it's another suspenseful question?

[Craig A Berry]

John,

Neither CPAN nor CPANPLUS will help you with test failures -- they just run automatically all the same steps you would run manually. If tests fail, they will not (by default) let you install a module.

As far as HP ever releasing a newer version of Perl, they appear to be out of the Perl on VMS business as far as I can tell. At least anyone I know who use to work on it isn't with HP any more.

[john nicoara]

Craig,

Thanks for the "encouragement" of playing Perl on VMS. Would I have known before starting how the real stakes are, I would have chosen another way (read: platform)... but now I must climb my Golgotha up to the end. Things are worse as ones could imagine, a lot of high-prized, self-coding-time-sparing modules do not run correctly on VMS, so again you're punished to hardly work for re-discovering the wheel. I will surely belong to the people category you mentioned in your last sentence.