Callable CMS problem

[Mark Katz]

First, let me say that I have been writing and maintaining programs which use callable CMS for more that 20 years. So, I don't think the answer to this one wil be obvious (but you never know).

I have written dozens of output callback routines to be called by CMS in the midst of its processing. Most of those are used with wildcards to gather and process information on collections of generations or classes. Up until now, all those routines have returned CMS$_NORMAL which allows CMS to continue processing the wildcards until it runs out of generations, classes or whatever. Then it exits. I use various methods to return the found information to the main program including queues (e.g. INSQTI), callable SORT, etc.

Now, for the first time, I have a use for an output routine (for CMS_SHOW_GENERATION) which will look at each returned generation to see if it meets certain criteria and, if so, will stop the wildcard iteration and return an error. According to the CMS docs, if I return from the output routine with an error status (even), then the CMS operation will terminate and return CMS$_USERERR to the main program. This does not occur. CMS continues to iterate through the wildcard generations (keeps hitting the breakpoint in my output routine) and eventually CMS returns to my main program with CMS$_NORMAL. Note - I have been doing my debugging on a VAX which gives me the luxury of stepping by instruction and examining registers (and even understanding what is happening). I am confident that the output routine is actually returning the error status to CMS.

Just for kicks, I changed the routine to return CMS$_STOPPED rather than the real error status. This should have at least stopped CMS from continuing to iterate but it didn't work either - the iterations continued until the wildcard was exhausted.

This is CMS v4.2 on OpenVMS VAX 6.2. I also have CMS v4.2 on OpenVMS AXP 7.2-2 and CMS v 3.9 on OpenVMS AXP 7.2-2 to test on but I don't expect different results.

I also have workarounds as I have many means of passing info back from the output routine that I can use in place of the return status (and the extra wildcard operations won't hurt much) but I would like to see if anyone has any insight on this issue.

Thanks, Mark

[Hoff]

Smells like a CMS bug. If you've software support in place build yourself a dinky little reproducer that connects up and calls SHOW GEN and (tries to bail), and ring up HP.

The reproducer serves several purposes, not the least of which are reasonable proof that this is a CMS bug and verifying that the eventual eventual fix works.

There have been some CMS ECO kits around, too. Off the top, I don't remember if 4.2 has one, but it would not surprise me.

All that given (and though it does not appear to be the case here), be extremely careful around CMS return status codes; they've changed in an incompatible fashion once or twice circa 3.5 to 4.2, and sent some of my CMS code into the woods. I've seen skewed definitions, and have had to rebuild code that called into the CMS APIs accordingly.

[John Gillings · Accepted solution]

Mark,

If you're debugging on a VAX, and can follow a VAX instruction stream, you could set a break point at the return address in the CMS routine that's calling you. Step by instruction to see what it's doing with your return status (and check that it's getting the right value).

Even if you don't want to step through it, just examine the instruction stream. There should be a bunch of tests and branches on R0. Use SHOW CALLS to give you the address to start at.

If it is a CMS bug, (and I agree with Hoff, that's what it sounds like), you may then be able to point CMS engineering at the exact problem.

[Mark Katz]

I certainly will be filing this with HP once I get access. My System Manager added me as a shared access for our Support Agreement but ITRC is still not letting me into the page for submitting problems. I did create a minimal reproducer which shows the problem quite well, so I'm all set on that front.

As John suggested, I followed the instruction stream on the VAX for a bit. I'm certain that the error status is passed back from my routine correctly and appears in RO *after* the return. Then it is copied into R11. After about 20 instructions (including several CALLS calls into stuff in CMSSHR (which I didn't step into), it eventually copies another CALLS return status (CMS$_NORMAL as it happens) into R11, overwriting my error status. I don't know if it got saved or acted upon during those CALLS calls or this is where it got "ignored", but I don't think I want to spend too much more time on it.

I also checked that it has the same behavior with CMS v4.2 on OVMS AXP 7.2-2. I don't have access to a system with a later version of CMS on it but the release notes for v 4.4 and v4.5 don't mention a fix or a known problem.

Will followup when I get a response back on this (assuming I can get my access problem resolved). I have to say I'm not overly impressed with the general level of user-friendliness of the ITRC mechanism (not the people who are great).

[Mark Katz]

After 5 months of productive dialog, DECset Engineering has found and fixed the problem. Will be fixed via a patch and become CMS V4.5-4.

[Mark Katz]

Problem solved by CMS update.