Internal MMS Error

[Peter Bengtsson]

Hi, started to build an old product using MMS and got the error:

%MMS-F-INTERNERR, Internal MMS Error. Please Report Error #2.

It worked 3 years ago and "nothing is changed" in the environment that we know of. Tried to debug by changing the MMS-file and adding qualifiers to MMS (/log/list/noaction/check_status/force/ignore etc) but cannot get any idea about what is wrong. Does anybody know what internal error number 2 means?

Thanks!

Peter Bengtsson
Etteplan for ABB

[Mark Katz]

I don't know what the message means literally, but it was commonly encountered (at least in older versoins of MMS when there was a syntax error in the description file. Not sure why it would crop up suddenly in a system that hasn't changed (that you know of) but anything is possible.

Since MMS digests the entire description file and builds its internal tree as a very early step, no actions execute if this step is not successful.

My best advice on this one is to use the divide and conquer approach. Using temporary copis of the original description file, cut out a large section of the file and see if you get past that message (the /NOACTION qualifier may be useful here to keep from doing a partial build). If the error stops, put back the cut section and remove the rest and do another division.

The only thing you need to do is make sure as you cut out pieces of the description file is that you don't cut dependencies in the middle. Also watch out for .IF ... .ENDIF conditionals. You don't want to introduce syntax errors as you chop away.

Hopefully, you will find the offending piece eventually.

Mark

[Peter Bengtsson]

Thank you for your answer! Unfortunately this is exactly what I've already done...

The original MMS-file (tried more than one) is from the early 90:ies and worked 2006 when I last built it. I've cut out most of it and it now only contain one object to build but I still get the error.

The machine has been physically moved but according to the ones that did the move, nothing as been changed in the SW environment (like installing new version etc). But obviously something must have happened in the environment. Maybe a logical name, symbol etc... But which (there are a lot...)?

Hoped that #2 could give me a hint...

Peter

[Hoff]

Something deep inside MMS broke.

There's an old release note for MMS around the "Use of library module specifications as targets in double colon rules is disallowed. A library module specification is one in which a source or target of a dependency rule is a module in a VMS library..." The results of that (mis)usage were formerly this internal error, but that was switched to a different error at MMS V2.2.

Confirm sufficient process quotas and other such for correct operations, see if the /VERIFY or /LOG gets you any details on the specific failure, and the confirm that the current ECO kits for whatever OpenVMS VAX or OpenVMS Alpha or OpenVMS I64 box is in use here, and for whatever version of DECset MMS here, and then lob this problem report and MMS file over to HP for a look.

I'd probably first try this on a newer or more current version of DECset MMS prior to ringing up HP support. (That's likely what HP is going to request here in any case, if you're not already there.)

[Camiel Vanderhoeven]

It might be a simple case of bit-rot... You could try re-installing decset.

[Peter Bengtsson]

Thank you for your answer.

Yes, it might have something to do with library. The files I have problems with are creating libraries (OLB-files I think, I am not at work now so I cannot check). It seems like MMS-files that only compile files are working.

/verify and /log gives nothing.

I will check quotas for the account, disk space and such things. I will also check which MMS-version we are using.

Regards Peter

[Bob Blunt]

Peter, according to some really old information "error #2" is a catch-all. It could be anything from an accvio to something missing from a library. There was a problem around the V2.7-ish timeframe and the V2.7-2 release fixed it. This was around 1993.

What versions of DECset/MMS do you have on your unchanged system after all?

Based on some other old information and your comment that you've tried using /list/log already, it might be due to a corrupt library or some other part of the MMS installation that hasn't survived.

bob

[Peter Bengtsson]

Hi, still haven't solved the problem.

Checked process quotas, ok. Cannot find any logical name that is wrong (not saying that everything is ok). MMS version is 2.6. Have not reinstalled it yet. Found the log-file from 2003 (attached). Also attached the log file from now when it fails. Attached one of the mms-files that fails (at least 2 fails) and also a more detailed log when running the attached mms-file. Greatful for any more ideas!

[Steven Schweda]

> [...] MMS version is 2.6 [...]

Ooh. That's pretty old and tired. Around
here:

alp $ write sys$output f$getsyi( "version")
V7.3-2
alp $ mms /id
%MMS-I-IDENT, MMS V3.5 © 2003 Hewlett-Packard Development Company, L.P.

And that's not the latest. (The full-kit
ECO on the FTP server includes V3.8-2.)

Did you ever try MMK?

[Peter Bengtsson]

Yes, it is very old and if possible - we want to stay "old". It is an old project that we have support on and we want the development environment the same for the rest of the support time. It has been working without any problems since early 90's until now...

Regards / Peter

[Larry Bohan]

Two scenarios I've found where MMS might fail
(seemingly sliently), is lack of pagefile quota
(pgflquo), and channel counts (film).

iirc, b/c most of what MMS will execute via
a subprocess, you migth also look at the
PQL_M*, and PQL_D* quotas, in particular those
that are pooled.

You might also try $SET WATCH/CLASS=ALL FILE
(/class=none to turn it back up), in case
there's some sort of loop, or recursion going
on ...

[Hoff]

Early 1990s? What OpenVMS version?

What VAX or Alpha box?

What's changed in the system configuration since the last successful build? Any product upgrades?

[Peter Bengtsson]

Hi again. Started to look at this again...

The VMS version is 5.5-2 on a VAX 4000-200 machine.

With some more testing by stripping and changed one of the failing MMS-files, I have found out one exact case where the error occurs:

I have a C-file that shall be compiled to an object file and then put into an object library. If MMS determines that the object file needs to be rebuilt (object file is missing or older than the C-file), everything seems to work, the C-file is compiled and the object file is replaced in the library. If the object file instead is up to date, I get the internal error directly after the time of the C-file and object file is fetched (and compared I guess but the log says nothing about it).

Any more ideas (except upgrading to newer versions which is no solution in this case)?

Thanks, Peter

[Steven Schweda]

On my VAX 4000 model 200:

GIMP $ write sys$output f$getsyi( "version")
V5.5-2
GIMP $ mms /iden
%MMS-I-IDENT, DEC/MMS V2.7-03 COPYRIGHT © 1983, 1993 DIGITAL EQUIPMENT CORPORATION

and the MMS release notes say things like:

DEC/MMS
Version V2.7-03
6 October 1993

So, it's not as if MMS V2.7-03 is
particularly new.

> Did you ever try MMK?

Still wondering.

[Peter Bengtsson]

Hi, no we have not tried MMK. The reason why we will not change anything in the environment is that the product we create within the development environment is very critical. If we change anything, we will probably have to go through all Acceptance Tests we went through in the early 90's together with the end customer. That will cost a lot... So therefore, we do not want to upgrade to newer versions, not change tools or anything like that as long as there is any hope left of being able to "repair" the current environment.

[Peter Bengtsson]

After more tests; it seems to do with comparing the times of the files. If I add the qualifier /from_sources I can run the MMS-files without problems but then all is built without checking date and time of the involved files.

More info; not all files cause problems. Files that has only one "action", e.g. compilation seems to work. But if there are 2 "actions", e.g. compilation and then put the object fil into a library, then it fails. And it then fails when the object file is up-to-date (need not be rebuilt).

Thankful for any more ideas!

Peter

[Peter Bengtsson]

Hi again

In the attached zip-file, there are two very small mms-files, one that fails with the internal error and one that is successful. The failing file is extracted from the original file that fails and contains the rules for compiling a C-file to an object file and then replacing the object file into an object library file (abb.olb). In the successful mms-file, the object file is instead linked into an exe-file and that always works. Attached are also two log-files (failing and successful) when running the two mms-files. The mms files are run 3 times each:
1) The C-file is modified and thus compiled and put into library/linked. This is always successful.
2) The C-file is not modified which results in the internal error in the failing example and "up-to-date" in the successful example.
3) The C-file is not modified but the qualifier /from_source is added which will cause unconditional compilation and then put into library/linked. This is also always successful.

Any ideas? Is the only answer to re-install mms?

Thanks / Peter

[Hoff]

HP is unlikely to fix an old version of this tool on an OS version that's sixteen years old and on a hardware platform that's two architectures back, and you're unlikely upgrade your configuration here, and certainly nobody wants to re-qualify a large and critical application.

That's a tough spot to be in here, yes.

Time to remove MMS. Entirely. Create a brute-force DCL build procedure for whatever this is, based on what MMS does for you, for instance. Or move to MMK, or whatever. Or force the existing MMS file to always do a full build; a "clean" pass or whatever it might be, and then a full build.

Sure. Try a VAXset re-install. Chances are, it won't help.

If you can't move on, then punt this up to your boss(es) to decide.

(Even tweaking the code of these sorts of large and complex applications around the edges is tantamount to triggering a re-qualification, in any case. This stuff is always a debatable call, too. Is replacing the MMS big enough to trigger a re-qualification? Or is just rebuilding the app? I had one where I could patch the images to make changes, but could not rebuild them. But I digress.)

Yes, you're going to zero-points this answer. Now think of why you're going to do that, and then of who ultimately owns this whole decision. Your bosses, right? Ask your manager for guidance. You've been deadlocked since June, after all.

[Steven Schweda]

> Yes, you're going to zero-points this
> answer. [...]

I'm still wondering why using MMK would
require going "through all Acceptance Tests",
but replacing the current MMS scheme with
some worked-around MMS scheme would be
harmless.

Knowing nothing, I'd expect that one could
observe the build, see who does what when,
say, "Well, that looks the same to me", and
go about his business. Unpleasant, perhaps,
but not inadequate. MMS does not, after all,
create the product, It manages the
compilers, linkers, and other tools which do
all the real work, and that real work is all
observable.

Of course, the same argument would apply as
well to a newer version of MMS.

[Peter Bengtsson]

Thank you for your answers. I'll take your input and go to my bosses. They have to decide how to continue with this strange problem. The easiest way is probably to rebuild everything unconditionally but I'll have a look at MMK also.

Regards Peter