Internal MMS Error

[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