Greetings,

DBGET does not know the length of the buffer you passed to it.  It
doesn't make any difference whether you use the INTRINSIC phrase in your
CALL statement in COBOL (or the equivalent mechanism in other
languages).  

The code that the compiler generates simply passes the address of the
beginning of the buffer.  DBGET does not receive any information about
how long the buffer is.  It doesn't scan the buffer looking for a null
character--DBGET never cares about the contents of the buffer at the
time of the call.  It trusts that you have provided enough space to
receive the data you asked for in the list you provided.  If you
haven't, DBGET will happily try to write over the following items in
working-storage, or whatever might lie beyond the buffer you provided.

Walter  

Walter J. Murray

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Michael
Sent: Wednesday, July 14, 2010 7: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 *