Olav and the group,
I'm not sure how safe it is to put the buffer at the end of
working-storage. I don't know that doing so will always result in the
buffer overflow causing a trap. The compiler might allocate a few bytes
just beyond the end of working-storage for some special use. If
anything is going to get corrupted, I think I'd rather have it be a
variable that I can examine with a symbolic debugger (or with DISPLAY
statements or other means), rather than temp cells used by
compiler-generated code for who knows what.
Walter
Walter J. Murray
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Olav Kappert
Sent: Friday, July 16, 2010 9:42 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] Internal Trap (for the unwary)
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 *
|
