Thanks for the info Walter, I was just curious, (in reference to Deny's 
comment), how DBGET knows to return a condition-code of 50.

What I commonly do, and believe to be a "Best Practice" is compare the 
sizeof(buffer) or function length(buffer) to the length returned by 
DBGET, if you're using the @ data item list.

ma.

Olav Kappert wrote:
> And that is why some calls will work and other will fail.  It all 
> depends if their is available stack after the pointer.  If not, a 
> stack overflow message (or something) will ensue.
>
> I will generally put my buffer as the last area in my working-storage 
> section so that if their is insufficient space available the call will 
> fail and a message will be displayed.  Placing it anywhere else will 
> result in incorrect data in variables meant for other uses by the 
> program, resulting in corruption of data.
>
> Olav.
>
>
> Walter J. Murray wrote:
>
>> 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 *
>>
>>  
>>
>
> * 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 *