"0C4 Storage Exception" vs. "B055 Invalid Length" ...The controversy continues
Article ID: 55581
Updated On:
Products
Issue/Introduction
As most of the computer knowledgeable world is aware, there is an industry wide movement to ensure that simple tasks like moving a field from one place in memory to another are secure so virus makers can not attach any offensive code into an existing process. We read about it daily... "Virus code executes as a result of a buffer overflow". We've seen it in Microsoft products and now recently in Oracle's database code among others. As programmers, we are being encouraged to move from our common string handling functions like using a strcpy to copy data between buffers to use StringCbCopy which protects the size of the destination buffer and ensures that data is not written past the end of the buffer. The world is changing and Easytrieve is changing along with it...
Environment
Easytrieve Plus Report Generator, release 6.4
Resolution
Within Easytrieve, users may have experienced an ABEND within a program that worked five years ago when it was written but suddenly caused a 0C4 storage exception when run under the 6.4 release. In almost all cases, this was a direct result of attempting to use fields that were defined beyond the length specified on the FILE statement. After debugging the first ten to twenty of these issues, Easytrieve published a fix that, upon compilation, produced a "B055 Invalid Length" message if fields were defined outside of the reported file length were detected and thereby notified the programmer of this problem before an ABEND could occur. The result of this fix was that suddenly programs that were being run as a "load and execute" program were no longer running and Support was informed of all the reasons that the problem could not be fixed at that time. So, a fix for the fix was developed?
Now, literally years later, Support is still getting the calls for storage exceptions only to find programs with fields defined beyond the declared file length. Sometimes there are valid programming reasons for why this is done and Easytrieve, as a programming language, does not want to restrict this usage. More often, fields have been added to the record over the years and have been added to the Easytrieve program but the file length on the FILE statement has not been changed to keep up. To avoid the B055 message, the easiest change to make within an existing program is to remove the file length information from the FILE statement and have that length come from the DCB information on the JCL or from within the operating system catalog. For example, a statement coded like "FILE filename FB(140 1400)" now results in Easytrieve comparing the defined fields to ensure that their combined length does not exceed 140 bytes. By simply coding " FILE filename", you will prevent any checking at compile time and therefore eliminate the B055 message.
Of course, by doing this, you remove the protection that Easytrieve offers to prevent storage overlays. From a programming and testing point of view, the easy fix is not necessarily the best fix. However, with the advent of the r11 release of Easytrieve, the B055 message will not be optional and therefore, it's time to address the cause. To quote the novelist Miguel de Cervantes... " Forewarned, forearmed; to be prepared is half the victory".
Feedback
