Change in DCL continuation-line behavior, 7.3-2 to 8.3 ?

[Richard W Hunt]

Site info: OpenVMS 8.3/Alpha, patched with all patches through end of September 2009.

One of my customers uses a foreign command supplied by a third-party vendor for linking with some menu- and database- linking code.

He has the command defined as

TPLINK == @TPHOME:TPXLINK_DATABASE

If he does:

TPLINK MAINPROG SUB1,INCLDIR:TPLIST/OPT

This works fine under OpenVMS 7.3-2 and 8.3

If he does:

TPLINK MAINPROG -
SUB1,-
INCLDIR:TPLIST/OPT

This works in 7.3-2 and in 8.3.

If he does:

TPLINK MAINPROG -
SUB1,{tab}-
INCLDIR:TPLIST/OPT

This worked in 7.3-2, fails in 8.3, only because of that tab character. The failure is that it somehow misses the last continuation line and blows off the implied LINK command because it doesn't have enough to build the image without the stuff from our shared include-file area.

We have a workaround (remove the tab...) so this isn't a threat to project completion, but I'm wondering if something changed here that I didn't notice.

Oh, the user is fairly astute. He is aware of SET PROC/PARSE=EXTENDED, but that does not seem to have any effect.

Any comments or suggestions?

[Hoff]

You appear to have what looks to be a good reproducer and a functional workaround, so there's not much more folks here in ITRC can contribute.

Ensure the box is on the most current UPDATE and DCL ECO kits (patches), and then report what looks to be a DCL parsing bug to HP.

(One of the first items in the HP support script tends to be the "are you patched to current?" question. Preemptively patch to current tends to speed travel through the support center queue.)

[Richard W Hunt]

Thanks for the comments, Hoff. I can't patch anything else for a few weeks, probably. We just finished the upgrade to 8.3 and it was more painful than it should have been. A lot of our third-party software was balky and the "few weeks" project turned into a "few months" project (fortunately, on a test system for the dreary grind through the problems). Some time during the coming holiday season we will schedule a "patch day" and get to play some "catch up" with patches.

My latest DCL patch is VMS83A_DCL-V0300, which had to have been installed from the UPDATE v10 patch ('cause I didn't do it separately.) It is clearly there even though not in PROD SHOW HIST, so it must have come through UPDATE 10.

I agree that with a workaround, we can go to fight another day. However, I was very curious to see if anyone had heard of this before.

I'm currently working with the customer on my theory that the tab changes the DCL parsing of the Px parameters such that with both the comma and tab, the parameters are

commmand P1=main, P2=sub, p3="", p4=include-stuff/opt

That is, having comma AND tab skips the p3 parameter. The only gripe I've got is that he discovered this because the foreign command was used in a script that was working before the upgrade - so some basic parsing behavior has changed in that upgrade. (Yeah, I know - wouldn't be the first time, won't be the last time.)

[John Gillings]

Richard,

Please try to reduce this bug down to minimal commands and procedures and submit it to HP as a high priority issue.

If it's general, this is potentially VERY scary, as it has the potential for introducing silent bugs in existing, correct procedures. It needs to be fixed ASAP.

[Karl Rohwedder]

In my opinion, the behaviour is correct and is what I would expect: the TAB character splits the 2nd parameter and introduces a 3rd one.

I tried it on different VMS versions (Alpha V7.3 and 8.3 and VAX V5.5-2 and V7.3) and all behave the same.

regards Kalle

[Richard W Hunt]

John, I no longer have the ability to test this on an OpenVMS 7.3-2, because we upgraded the last 7.3-2 box last month. I have no usable test platform.

Actually, to be honest, I'm surprised it worked correctly under 7.3-2 based on my understanding of how command-line parsing is supposed to work for scripts.

As noted by Kalle, the behavior in 8.3 is what I would have expected. Tab breaks the parse as a "major" token delimiter. What surprised me more than anything else is that the comma DIDN'T act as a parameter delimiter for either case. If I had written the parser myself, that comma would have been an "eatable" parameter break.

I have now had some time to examine the actual script. It basically builds a complex, multi-line LINK command via string substitution. The P1 parameter is always handled correctly, "MAINPROG" - but it is the P2 parameter that goes whacky.

In the cases that works as intended, the P2 parameter is "SUB1,INCLDIR:TPLIST/OPT" - but when that tab is there, the comma is part of P2 and the INCLDIR part is now P3. It goes to another (incorrect) part of the LINK command, hence the error.

I had the user switch to wide-screen and then re-form the commands into single-line format but retaining tabs or spaces or other formatting. In other words, I had him rejoin the continued lines literally. It behaves exactly as I expected it to do. The tab or space makes the INCLDIR portion move to P3 (proven by turning on all verification). If he removes all excess tabs and spaces, the P2 parameter includes the comma, SUB1, and the INCLDIR part. If he encloses the SUB1 and INCLDIR parts in " marks, any tabs and spaces inside that string are retained but the parameters stay together as P2.

Basically, I agree with Kalle that this is what you would expect - and would have expected for OpenVMS 7.3-2. I am at a loss to explain why it ever worked with those tabs for OpenVMS 7.3-2 because to me, it is doing what I expected it to do for version 8.3 of VMS.

I have advised my user that he was getting away with something earlier and now he has to follow the parser rules a bit better. He's good-hearted enough to not give me too much of a hard time about that answer, particularly since chapter and verse of the DCL documentation describes this behavior.

At least we can now recognize the problem. And as we all know, "experience" is what allows you to recognize your mistake when you make it again. Guess that makes us very experienced.