MMS V3.8-2 v. MMS V3.9-00, re: User-defined_Rules

[Steven Schweda]

What am I missing here? (The actual source file is
"test1.c".)

ITS $ type descrip.mms
# Works with MMS V3.8-2.
# Fails with MMS V3.9-00.

.SUFFIXES_BEFORE .C .MMSD

.C.MMSD :
$(CC) $(MMS$SOURCE) /NOLIST /NOOBJ /MMS_DEP = (FILE = $(MMS$TARGET))

DESCRIP_DEPS.MMS : TEST1.MMSD
@ write sys$output "Done."
ITS $

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

ITS $ mms /list = 390.lis

%MMS-F-GWKNOPRN, There are no known sources for the current
target TEST1.MMSD

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

ALP $ mms /list = 382.lis

CC test1.c /NOLIST /NOOBJ /MMS_DEP = (FILE = TEST1.MMSD)
Done.

All the .SUFFIXES are the same:

ITS $ diff 382.lis 390.lis
************
File ITS$DKA1:[UTILITY.SOURCE.GNUPG.mms_bug_39]382.LIS;2
17 TEST1.MMSD : test1.c
18 $(CC) test1.c /NOLIST /NOOBJ /MMS_DEP = (FILE = $(MMS$TARGET))
******
File ITS$DKA1:[UTILITY.SOURCE.GNUPG.mms_bug_39]390.LIS;3
************

Number of difference sections found: 1
Number of difference records found: 2

DIFFERENCES /MERGED=1-
ITS$DKA1:[UTILITY.SOURCE.GNUPG.mms_bug_39]382.LIS;2-
ITS$DKA1:[UTILITY.SOURCE.GNUPG.mms_bug_39]390.LIS;3


Foolishly, after some years of satisfactory results, I had
assumed that all my dependency-generating description files
were correct (enough). This couldn't be an MMS bug, could
it? (Or is it some old bug, and I've simply forgotten all
about it?) Is there any hobbyist-accessible DECset kit newer
than "DECSET128E | CO.2" (I still love that
sys$update:VMSINSTAL.HISTORY report.)

The actual task uses MMS /EXTENDED_SYNTAX, so, no, MMK
won't do.

[hb]

On 04/15/2018 06:51 AM, Steven Schweda wrote:
> What am I missing here? (The actual source file is
> "test1.c".)

Looks like ODS-5 ...

... which is more or less confirmed, here. So it can be a case problem.
I don't have access to a 3.9 MMS, but I remember that I experienced
similar problems when MMS was upgraded (to 4.0, as far as I remember,
but I have no data on the previous version). I wonder if re-setting the
process parse style or using the target type "C" (and/or quoting the
target) will help.

[Robert A. Brooks]

On 4/15/2018 8:50 AM, hb wrote:
> On 04/15/2018 06:51 AM, Steven Schweda wrote:
>> What am I missing here? (The actual source file is
>> "test1.c".)
>
> Looks like ODS-5 ...

That's not a surprise; the attempt to add ODS-5 support to CMS apparently turned
into a Keystone Cops-like adventure for HPE.

As the current MMS and CMS (and DTM, ENVMGR, PCA) maintainer, I'll put this on
my list. Paul Anderson drew the short straw and gets to deal with LSE and SCA.

The MMS parser is somewhat scary, and I can see how a seemingly-simple change
could have unintended consequences.

Hartmut's already filed an report regarding case sensitivity and target names.

Maybe once I begin cross-compiling for X86_64 I'll have some time to look at
these things.

--
-- Rob

[Arne Vajhøj]

How much enhancement of DECSet is really needed going forward?

To me MMS, CMS, DTM, LSE and SCA are tools with no future.

They work for what they worked for 25 years ago.

Both internally in VSI and at customers they should switch
to modern industry standard tools for these purposes.

(PCA functionality is needed)

That old stuff on ODS-2 that need to be kept working should
continue to work.

But new stuff (and I see ODS-5 as being an indication of new - even
though is has been some years) should migrate.

And mixed case file names will not be a problem for the new tools. In
fact they may require ODS-5 and not even work on ODS-2.

Arne

[Steven Schweda]

> Looks like ODS-5 ...

This clearly is an ODS5 disk, but the MMS problem may be
worse than you might think:

ITS $ rename test1.c TEST1.C

ITS $ dire test1

Directory ITS$DKA1:[UTILITY.SOURCE.GNUPG.mms_bug_39]

TEST1.C;1

Total of 1 file.

ITS $ mms /list = 390u.lis

%MMS-F-GWKNOPRN, There are no known sources for the current
target TEST1.MMSD

The amazing thing to me is that I thought that this was a
pretty commonly used feature, but apparently it wasn't
tested. Unless I'm doing something which looks normal to me
but really is bizarre.

If I had had to guess what to worry about, I'd've picked
things like the $(FILTER-OUT ...), $(FOREACH ...), and
$(PATSUBST ...) predefined functions, not a user-defined
dependency rule.

Note: If anyone were looking for realistic test cases
(although probably not best-practice examples) whose failure
might bother me, then one need look no further than the
Info-ZIP Zip and UnZip programs ([.vms]descrip_mkdeps.mms).

I noticed this problem while working on an overdue GnuPG
update. Apparently, I hadn't been keeping the tools on my
XP1000 up-to-date, so I hadn't noticed this problem there,
but, when I shifted most operations to the rx2660, it got
fresh installations of most things. Except DFG, whose PAK is
in the Hobbyist collection, but whose product kit seems not
to be.)

[hb]

On 04/15/2018 07:48 PM, Steven Schweda wrote:
>> Looks like ODS-5 ...
>
> This clearly is an ODS5 disk, but the MMS problem may be
> worse than you might think:
>
> ITS $ rename test1.c TEST1.C

This works for me with MMS 4.0, which is said to be functionally
equivalent to HP's MMS V3.9-1 (except for the DECWindows interface,
which got a fix). Google finds the release notes of DECset V12.8 ECO3
which contains an MMS V3.9-01.

With MMS 4.0, "test1.c" and /CASE=BLIND/PARSE_STYLE=EXTENDED it also
works for me.

[Craig A. Berry]

On 4/14/18 11:51 PM, Steven Schweda wrote:

> The actual task uses MMS /EXTENDED_SYNTAX, so, no, MMK
> won't do.

FWIW, MMK got /EXTENDED_SYNTAX about five years ago. I don't think I've
ever used it, so no promises, but if it has problems you can fix it
yourself:

<https://github.com/endlesssoftware/mmk>

[Tim Sneddon]

Yes, MMK has /EXTENDED_SYNTAX and plenty of extra goodies. It too has its
own problems that unfortunately I have not had any time to address. Github
issues can be filed, but my ability to work on them is significantly
diminished at the moment.

Regards, Tim.

[John E. Malmberg]

It still may be less work for VSI to deprecate MMS and replace it with
the Open Source MMK product than to fix and then continue to maintain MMS.

All the .MMS files in the updated GNV components require MMK when built
on an ODS-5 filesystem just to get the rules to work, so some kits also
are using the MMK extensions to support VAX variants

I do not know how much work it would be to get the Gerrit server (JAVA +
database) running on VMS, but that would look like the logical product
to replace CMS.

Gerrit is a "wrapper" to git that allows enforcing reviews and commit
restrictions like CMS does.

Regards,
-John

[Steven Schweda]

> FWIW, MMK got /EXTENDED_SYNTAX about five years ago. I

> don't think I've ever used it, so no promises, [...]

I tried it (V5.0) years ago (2013), and it didn't work.

> [...] but if it has problems you can fix it yourself: [...]

Yeah, I need another project. Today's github download
("%MMK-I-IDENT, this is the MMK Make Utility V5.1") doesn't
work, either, but it does get further than the 2013-12
version. UnZip 6.0, for example (when it didn't hang):

ITS $ MMK /EXTEND /DESCRIP = [.VMS]DESCRIP_MKDEPS.MMS /SKIP
%MMK-F-CANTUPD, cannot update target ZIPINF.MMSD - sources unknown

"zipinfo.c" is probably the last item in a $(FOREACH ...)
expansion, which, apparently, got truncated.

I don't get out much, so I don't know who uses
/EXTENDED_SYNTAX other than Info-ZIP (me), but that does
provide a couple of test cases which many people already
have. (Other stuff from here is similar.)

[hb]

On 04/16/2018 08:42 PM, Steven Schweda wrote:
> I don't get out much, so I don't know who uses
> /EXTENDED_SYNTAX other than Info-ZIP (me), but that does
> provide a couple of test cases which many people already
> have. (Other stuff from here is similar.)

Me. My test cases for 'subst' and 'patsubst' pass with MMS and fail with
MMK. Other test cases for patsubst fail with MMS and MMK, but in a
different way. All these test cases pass with GNU Make 4.1 (on Linux).
It doesn't seem possible to simply replace one MM% with the other.