We phased out "@" in the early 80s, but just in case, our coplibs always put 
the data set name right after the buffer for that data set, so if I 
overwrite it, I can only do it ONCE.  Next time the pgm does anything with 
that data-set, like try to read the next record -- kablooey.    One of 
several tricks I do to try to replace every subtle error I can think of with 
something so spectacular it can't possibly get past testing.

----- Original Message ----- 
From: "Olav Kappert" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, July 16, 2010 09:42
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 *