DCL command buffer overflow

[Jess Goodman]

Karl,

I think you will find that:

$ kurz=F$Ex(0,10,Lang)

will work also.

The full text of the error message is, after all, "command buffer overflow - shorten expression or command line", and using abreviations is one way to shorten the command line.

[Hein van den Heuvel]

You're joking right?!

Watch check... noop, not 1-apr yet.

Hein.

[Jess Goodman]

No, I wasn't joking. The reason that Jon's
F$FAO("!10AS",x_Rec)
worked, when
F$EXTRACT(0,10,x_Rec)
didn't is becayse it is one byte shorter.

Using F$EX instead of F$EXTRACT saves 5 bytes. Using shorter symbol names is another way of shortening the command line.

The longest symbol that can be defined directly with F$FAO under VMS 7.3-2 is, I think, 8181 bytes:
$ f = "!8181*a"
$ x=f$fa(f)
Add extra spaces around the = or a second letter to a symbol name and it fails.

Now, if you thought I meant that you should depend on one of these commands working at the very edge of the DCL command buffer limit in operational code, then no - that would be a joke.

[John Gillings]

re: Arron's SOAPBOX comment (obviously meant for me)

I don't have any problem with people running old versions of VMS. As I said, there are legitimate reasons for running V7.3-2, V6.2 or V5.5-2 or even in some cases V4.7. I've spent many years supporting customers on all versions.

However, there are some versions that are just plain silly to run. Probably the worst is V7.0 - when released customers were specifically told not to run it in production, but I've still come across cases of people running it years later "because their application is only supported on V7.0". Nonsense!

V7.2 isn't quite so absurd, but it's not far from it! V7.2 was released in 2001. It's now 7 years old. In that time there have been many improvements and corrections. Apart from the newer major versions of OpenVMS there are also the "dash" releases -1 and -2. OpenVMS went to great pains to make sure these releases were cross compatible with V7.3. The wording of the is unequivocal:

"Enhancement Releases for OpenVMS contain enhancements to existing features and maintenance updates.
The version number increases to show a revision by using a dash (e.g., 7.2-1 for VMS)
Enhancement releases are shipped to service customers who have a valid service update contract, however, License Subscription service is not required.

Application Impact: The release may contain new hardware support, software enhancements and maintenance, but the changes are isolated and have no impact on applications. We are confident that the new release has 100% binary compatibility with the previous release. If an application compatibility problem is discovered, we will assign the problem a high priority and commit to providing a fix.

There is no need for ISVs to test on the new release or produce a new application kit."

In other words, if software is qualified on V7.3 then it is automatically qualified on V7.3-1 and V7.3-2 without the need for further testing. That is the guarantee of OpenVMS engineering.

What never ceases to amaze me is people who complain about a limitation or bug in an old version that's long since been fixed, but who refuse to install a guaranteed, qualified and historically stable fix for the problem they're reporting. What's the point of complaining about it if you're not going to accept the fix?

The other issue here is the FUD factor - people assuming that the risk of upgrading is worse than the risk of not upgrading. In a very stable environment that may be the case, but if you're actually experiencing problems, it clearly is not. You also need to factor in the lack of support from OpenVMS engineering.

No doubt there are people who could chime in with "I upgraded from 7.3 to V7.3-2 and X or Y broke, so it must the fault of the upgrade". Having worked for many years in a support role and seen numerous instances of such reports, the vast majority were NOT due to the upgrade itself, but mostly just the reboot itself. OpenVMS has a double edged sword of reliability. In many cases it's so long since the last reboot that various things have been forgotten or changed without realisation. A good tip is to perform a reboot before upgrading just to shake out any lurking bugs, and distinguish them from real problems associated with the upgrade itself.

When done in a professional, researched and planned manner, the vast majority of V7.3 to V7.3-2 upgrades (or indeed ANY OpenVMS upgrades) are quick, smooth and trouble free.

Run whatever version you like, but if you're not running a supported version, and you come across a problem that's already been fixed, expect to be told it's already been fixed. Yes?

[Hoff]

Derision here would be an inference, and not an intended implication.

Running an old software version or old hardware is not without cost, and older versions and older hardware can and does fail, and latent bugs can and will crop up. Older versions can and do avoid the upgrade costs, and avoiding upgrades is not without costs.

I've seen production sites slammed hard -- hard down, corruption -- because they didn't keep current on their software version and/or their ECOs or their hardware. John has also seen these. The panic is palpable.

And I've seen folks spend days figuring out, hey, the bug in version Vx.y is known and fixed in version Vx.y+n, and, well, we're going to have to pay for a backport or we're going to have to quick-upgrade. The result of spending some number of days (and possibly an associated partial or full outage) on the investigation doesn't change the results here. And worse, the quick-upgrade can occur under a "get it going NOW" deadline, and can open up exposures that a more controlled upgrade might have detected.

Certainly maintain your environment to meet your needs, but recognize that a decision to not to spend money on upgrades or ECOs is inherently equivalent to a decision to spend some lesser or larger amount of money at some later and usually unspecified date.

TANSTAAFL, as Mr Heinlein once wrote. There ain't no such thing as a free lunch. Staying on old versions is cheap for a while, though can quickly become surprisingly expensive, and the repairs are increasingly large and increasingly difficult to predict.

--

Written text can be difficult to interpret as the author had intended. I know John, and I seriously doubt any derision was intended. You'll have to trust me on this, but John knows how to get the cudgel out. If he's truly unhappy with something, you'll know it. I seriously doubt he intended derision.

[Jan van den Ende]

Wim,

>>>
Most of the stuff is going to Sun. It concerns big trades and currency swaps.
<<<

And _THAT_ is considered a lesser risk than going to VMS 7.3-2 (+ ECOs) ?

I would compare that to rolling 6 dice.

They do not dare take the risk that the result will be six 1's. Instead they feel safe to assume there will be not one 1.

I would not want them to play with MY money!

And I can support John G:
I was hired by the Amsterdam Police for 6 months, starting januari 1995. "to phase out VMS while moving to (Tru64) Unix".
I just left there, and now they are migrating the VMS apps... to another VMS configuration. (although: to be replaced "in the near future")

fwiw.

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

As expected, f$fao doesn't work on 7.3. Overflow too.

If it was up to me to decide, we were still on 6.2 1H3. The last upgrade costed over 1000 man days and IMO not worth the money.
And we would be on the 4100, not the GS160.

And I want to see who can convince his management of an upgrade when management makes a planning that within 1 year the platform is finished.

BTW : John, I didn't complain, just asked if there was a workaround.

BTW2 :
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=655880

Wim
(sorry for the low points but the discussion is off topic)