If you use a @ data item list, it is always wise to have a copylib member 
which matches the data set, so you always get the right amount of space.

On Fri, 16 Jul 2010 12:36:20 -0500, Michael <[log in to unmask]> 
wrote:

>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:HP3000-
[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 *

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