DCL command buffer overflow

[John Gillings]

Wim,

That's a load of *&^%#*($

One would have expected that "a bank and lots of money flows thru" would have a much better appreciation risk management than demonstrated by insistence on remaining on an old, unsupported, and unsupportable version of an operating system, with numerous KNOWN problems.

How will they ever upgrade? What will they do if they hit one of the many bugs which have long since been fixed by patches that are tried and tested across the planet? How will anyone even diagnose problems on a system with unique version and patch levels? Don't they have test systems? What if they have a need for a new or fixed feature? (for example, longer command line buffers).

It seems obvious to me that the risk they think they're avoiding is FAR FAR less than the risks they expose themselves to by NOT upgrading.

I could never understand why some users would refuse to upgrade a supported, QA tested minor version, but would happily install and run with a hacked up, untested, unique patch when they hit a problem.

They same bank no doubt blindly downloads and installs all the patches that another software company throws at them...

This is a huge issue in the OpenVMS world. Far too many versions, and far too many people unnecessarily afraid of the upgrade bogeyman. It's up to professionals like YOU to educate those that make the decisions.

OpenVMS should NOT be fragmented into a zillion incremental versions. It makes everyone's life harder and GENERATES risk, rather than mitigating it.

[Jon Pinkley]

John,

Although I agree with you about running old versions, if you were at that site, and given the same restrictions, specifically, "guarantee that this upgrade won't break anything, or pay for all the damages", your only choices are to leave it alone or find another client.

Yes, you can try to educate them, and point out that the risks associated with old versions may be higher that the risk of upgrade. However, if something breaks because of a deficiency of the old system, that can't be blamed on you. Any problems that occur after the upgrade will be blamed on you whether they are in fact related to the upgrade or not.

"core people gone with the wind", this is another problem. What if there is something that breaks as the result of a change? And there is no documentation? Hopefully the those problems would show up before going live, but you often can't do a 100% test on a test system, and with a banking system, I would expect a lot of interaction with outside systems that would be hard to faithfully emulate.

They should definitely have a test system, but doing a good regression test/parallel testing, etc. is not a trivial matter. Although I would be interested in ideas about how those can be done with good coverage and minimal human resources.

I remember when I was in high school (~1973) we went to a NORAD (Air Defense) monitoring site as a school field trip for our Physics class. They were still using vacuum tube computers at that time (possibly due to reduced susceptibility to EMP). So there are some industries/markets that are extremely lethargic in their upgrade schedules. And they may not upgrade until it is a absolute requirement because of non-support of the replacement platform.

Jon

[Wim Van den Wyngaert]

Jon(h),

Sorry but can't give more details but it's worse than you think. Officially we are in the last year of VMS ...

Wim

[Jan van den Ende]

Wim,

>>>
Officially we are in the last year of VMS ...
<<<

And THAT at a bank that does not even dare to upgrade???

Are you at liberty to tell us what will be the replacement platform those "... lots of money flows thru" ?
Try to (let them!) explain how that "minor upgrade" will be less risky than the "giant move" of VMS v7.3 to v7.3-2, or, even better, v8.3 !!
And in the course of that, let them explain how they intend to be more trustworthy on the new platform, because somehow I doubt that the replacement would be NSK...

Then again, probably all caused by the lack of (visual) support for VMS by the current owners... Beuh.

just rambling....

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Jan

Most of the stuff is going to Sun. It concerns big trades and currency swaps. They will just do them in other systems (package based, need a lot more Sun hardware than VMS hardware).

But the last 20% will be tricky ...


Wim

[John Gillings]

Wim,

> Officially we are in the last year of VMS ...

Don't worry, I know plenty of people who've been in "the last year of VMS..." perpetually since 1990! ;-)

[Aaron Sakovich]

SOAPBOX:

It never ceases to amaze me at the haughty, condescending attitudes exhibited by some when a person comes here for help, and receives derision for being on an old version of VMS.

Folks, if the user is running some obsolete version of the OS or an app, tell him why his problem exists, suggest he upgrade because that problem was fixed in a later rev, but don't flame him! Some people are overwhelmed as it is, don't need scorn poured on them, and we will never garner converts to VMS if we ridicule people who come here for help!

Geezzzz.... (off my soapbox now...)

[Jon Pinkley]

Wim,

No guarantees this will work, but it does on 7.3-2 with a 8172 length string.

$ read x x_rec
$ y=f$fao("!10AS",x_rec) ! same effect as f$extr(0,10,x_rec) but may work places f$extract fails.

Can you see if that works on your version?

Jon

P.S. here's what I did on 7.3-2 (patched)

$ abc=f$fao("!8173*a")
%DCL-W-BUFOVF, command buffer overflow - shorten expression or command line
$ abc = f$fao("!8172*a") ! 8172 "a" characters 8173 gets buffer overflow
$ write/symbol sys$output abc
%RMS-F-SYS, QIO system service request failed
-SYSTEM-F-EXQUOTA, process quota exceeded
$ new=""
$ new=f$fao("!10AS",abc)
$ sho sym new
NEW = "aaaaaaaaaa"
$
$ write/symbol sys$output abc

[Karl Rohwedder]

Joe,

nice idea with F$Fao, helps on VAX:

$ lang=F$Fao("!1000*A")
$ kurz=F$Extract(0,10,Lang)
%DCL-W-BUFOVF, command buffer overflow - shorten expression or command line
$ kurz=F$Fao("!10AS",lang)
$ sh sym kurz
KURZ = "AAAAAAAAAA"

regards Kalle

[Jess Goodman]

In VMS 7.3 the DOCUMENTED size limit for a DCL symbol was 1024 bytes. With 7.3-2 and Extended DCL this was increased to 8192 bytes.

However a problem wither DCL or EDCL is that when using symbols that are close to these documented limits with most DCL commands you will get the dreaded:
%DCL-W-BUFOVF, command buffer overflow

For instance under VMS 7.3-2:
$ x_rec=f$fao("!8192*a")
%DCL-W-BUFOVF, command buffer overflow
$ x=f$fa("!8175*a") !longest that works
$ write sys$output f$len(x)
%DCL-W-BUFOVF, command buffer overflow
$ say := write sys$output
$ say "''f$len(x)'"
8175

So minor changes in the DCL commands you use can prevent or cause BUFOVF when you are *CLOSE* to the limit. Jon's choice of F$FAO instead of F$EXTRACT is another example of this.

READ and WRITE/SYMBOL work up to and even over the documented limit, but there's no way under VMS 7.3 to do anything else with a symbol size of more than 1024 bytes.

Another limitation under V7.3-2 is LIB$SET_SYMBOL and LIB$GET_SYMBOL only work for symbols up to 4096 bytes.