Really, I'd like to know how dbget knows the length. Does it use pointer 
arithmetic or $null  character search. Does status 50 depend on the call 
"Intrinsic" clause? That would make sense, because the compiler could 
then send the length of the buffer to DBGET, which would be a more 
reliable method. Just curious.

What I've always done is: After a DBGET call with a @ list: Where 
FFFLDS-BUFFER is my dataset buffer and RECORD-LENGTH is the second 16 
bit integer in the image status parm.

     COMPUTE IREAD-LEN = FUNCTION LENGTH (FFFLDS-BUFFER).
     COMPUTE IREAD-LEN = ( IREAD-LEN / 2 )
     IF ( NOT END-OF-CHAIN ) AND
        (IREAD-LEN NOT = RECORD-LENGTH)

If the above is true, depending on the app, I can report/log this event 
and abort or continue.

Mike.
 

Denys Beauchemin wrote:
> If your buffer is too small for the returning data, IMAGE will return a
> status 50 on the DBGET.
>
> Denys
>
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
> Of Roy Brown
> Sent: Tuesday, July 13, 2010 2: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 *