Walter:

The programmer could just define a DB-Buffer field large enough for the 
largest record length possible (thinking about current and future lengths).

Olav.


Walter J. Murray wrote:

>Greetings,
>
>Roy gives some excellent advice here.  Database buffer overruns are a
>very common cause of such problems.  And it's an argument for not using
>the "@" list construct on a DBGET call.
>
>Even if nobody has changed the structure of the database, it's possible
>for a program with a too-short database buffer to run for years without
>a problem, until just the wrong combination of data and events turns a
>benign bug into a show-stopper.
>
>It can happen with VPLUS calls too, and with other intrinsic calls.
>
>Walter  
>
>Walter J. Murray
>
>-----Original Message-----
>From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
>Behalf Of Roy Brown
>Sent: Tuesday, July 13, 2010 12:14 PM
>To: [log in to unmask]
>Subject: [HP3000-L] Internal Trap (for the unwary)
>
>In message <000f01cb22b5$45d4f3c0$d17edb40$@com>, Mark Ranft 
><[log in to unmask]> writing at 13:00:25 in his/her local time opines:-
>  
>
>>I wonder which is more of a concern:
>>-  An unexplained Data PAGE Fault or
>>    
>>
>
>Unexplained doesn't mean inexplicable.
>
>Conjecture a dataset at the very end of your data division.
>
>Somebody added extra fields to it.
>
>Nobody told your COBOL program; though they might have told the copy 
>library.
>
>You run your program. Image tries to give you the record. It is not 
>aware you think it smaller than it is. But MPE is, and the attempt to 
>encroach outside the designated area produces the smart rebuke you saw.
>
>You recompile. You pick up the new, expanded, dataset definition from 
>the copy library. Enough data space is duly reserved..
>
>All thereafter is sweetness and light.
>
>  
>
>>-  wondering if the source code that you had been running matches the
>>    
>>
>object.
>
>If you embark upon a migration project, where your emulated code is 
>required to match the original MPE code, *demand* that the source you 
>are given to migrate is compiled on MPE to produce the reference system.
>
>By all means allow the client to provide a copy of their production 
>system for further comparison; if the source they provide you is not the
>
>source of the code they are running, this is the only way you (and they)
>
>will find this out.
>
>But the A-B-C comparison is essential to isolate the results of 
>incorrect emulation from those of incorrect source/data/what-have-you 
>provision.
>
>  
>
>>If simply re-compiling the code did indeed solve the issue, either the 
>>compiler had changed to fix a bug that you only ran into recently, or 
>>the compiler/link options had changed, or the source code and object 
>>didn't match.
>>    
>>
>
>Or (as above) there were copy libraries involved that had changed, 
>and/or COBOL's inability to achieve as a matter of course what 'make' 
>achieves for C.....
>
>  
>
>>Mark Ranft
>>Pro 3K
>>
>>-----Original Message-----
>>From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On 
>>Behalf Of Dave Vorgang
>>Sent: Tuesday, July 13, 2010 12:19 PM
>>To: [log in to unmask]
>>Subject: [HP3000-L] Internal Trap
>>
>>I recompiled my program and the error went away.
>>
>>Thank you,
>>
>>Dave
>>    
>>
>
>  
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *