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