This is what is in the IMAGE reference manual for DBGET error 50:

"Buffer is too small (will only be returned if buffer is
too small and the data transfer would write over
stack markers in the user's stack)."

In appendix A it says:  

"Calling program's buffer (identified by buffer parameter)
is too small to accommodate the amount of information
that DBGET or DBINFO wishes to return without extending
into the parameters area. This message is returned only if
the buffer is the last item in the user's stack, and will
overflow the stack boundaries."

You mean we can't trust the IMAGE reference manual?  Gasp, shudder.

Denys

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf
Of Michael
Sent: Wednesday, July 14, 2010 9:12 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Internal Trap (for the unwary)

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 *

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