MMS V3.9-00 v. "^" in file specifications

[Steven Schweda]

MMS V3.9-00, part of "DECSET128E version CO.2",
(possibly intended to be "DECSETECO2 version
12.8") exhibits some new and interesting (not
to mention undocumented and annoying) behavior.

The old way (shown here on Alpha, V8.3):

ALP $ type descrip.mms
target : a^.b.c
@ write sys$output "Success."

a^.b.c :
copy nl: a^.b.c

ALP $ mms /iden
%MMS-I-IDENT, MMS V3.8-2 © Copyright 2007 Hewlett-Packard Development Company, L.P.

ALP $ mms

Success.


The new way (shown here on IA64, V8.3-1H1):

IT $ mms /iden
%MMS-I-IDENT, MMS V3.9-00 © Copyright 2009 Hewlett-Packard Development Company, L.P.

IT $ mms
%MMS-E-CDDACCERR, CDD access error on path A
-CDD-F-CDDNOTINS, VAX-11 CDD is not installed on your system
%MMS-F-CDDPRIERR, Prior severe CDD error has occurred.


Apparently, a caret ("^") anywhere now implies
CDD, where before, a caret at the end of a
token was needed. As the manual says, ...

In a dependency rule, you follow the path name of an Oracle CDD/Repository
definition with the caret (^) to inform MMS that the source is stored in Oracle
CDD/Repository. For example:
A.OBJ : A.PAS, CDD$TOP.B.C.D.E^ ! CDD record referred to in A.PAS
PASCAL A.PAS


Is this a known problem? (Or am I exploring
brave new worlds, ...?) Or does this new
behavior actually make sense in some way which
is not immediately obvious to me?

Coming soon: GnuPG 1.4.10b kits (with MMS
description files which don't refer to files
by names like "pubring^.pkr.asc" or
"secring^.skr.asc").

Perhaps easy patch access isn't worth so much
as I had thought.

[Steven Schweda]

> target : a^.b.c

Note that for a simple file name, replacing
"a^.b.c" with "a.b.c" should work, but a
directory spec like, say, "[.d^.e]" can't be
changed to "[.d.e]" without completely
changing its meaning. In the old days, the
caret was ok:

ALP $ type descrip_dir.mms
target : [.d^.e]a.b.c
@ write sys$output "Success."

[.d^.e]a.b.c :
if (f$search( "d^.e.dir") .eqs "") then create /directory [.d^.e]
copy nl: $@

ALP $ mms /des = descrip_dir.mms

if (f$search( "d^.e.dir") .eqs "") then create /directory [.d^.e]
copy nl: [.D^.E]A.B.C
Success.

But that's been "fixed":

IT $ mms /des = descrip_dir.mms
%MMS-E-CDDACCERR, CDD access error on path [.D
-CDD-F-CDDNOTINS, VAX-11 CDD is not installed on your system
%MMS-F-CDDPRIERR, Prior severe CDD error has occurred.


If there's a comparably simple work-around
for that one, then I haven't spotted it yet.


More fun from the MMS/VMS experts (_not_ new
with MMS V3.9-00):

alp $ help mms
[...]
Additional information available:
[...]
/SHOW_DESCRIPTION_FILE /SKIP_INTERMEDIATE /VERIFY
Generating_Description_Files Description_File Examples CMS
FMS MMS$STATUS MMS$SEVEREST_STATUS Oracle_CDD/Plus
Release_Notes

MMS Subtopic?

Ok. Let's just copy+paste one of those Subtopics:

MMS Subtopic? Oracle_CDD/Plus

MMS

Oracle_CDD/Plus
Sorry, no documentation on MMS ORACLE_CDD /PLUS


So, was the Subtopic with the slash added by
someone with twenty years of VMS experience?
And who's testing this stuff?

[Jeremy Begg]

I had wondered if this was perhaps being parsed as an attempt to define a default rule for processing modules stored in CDD, but "a^.b.c" isn't valid syntax for a default rule (because of the leading "a").

So I'd say this is a bug, and one that breaks the support for extended filename syntax that was introduced in MMS 3.8.

Regards,
Jeremy Begg

[Steven Schweda]

> So I'd say this is a bug, [...]

It's certainly a change (which didn't help
me).

HP's been notified. The "business feedback"
Web form still seems to emulate a black hole,
but e-mail to OpenVMS.Programs did get a
response (with a promise of more to come)

Naturally, complaints from paying victims
would get priority over complaints from me.