Subject: | |
From: | |
Reply To: | |
Date: | Fri, 14 Nov 2003 04:48:47 -0600 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
Hello,
I just figured out the answer to this one but I'll leave it as an
excercise for the bored to figure out what I did wrong! (as I spent so
long typing it) Answer at the end. Not exactly sure why it happened
though.
I'm trying to get to grips with the way MPE has a temporary domain,
permanent domain and new domain. So I'm changing some of my test
programs but I'm getting an "INTERNAL TRAP" error on an FCLOSE intrinsic
call.
The program deletes the output file first ( I think this is how you
delete files on MPE!). That code works. If I create the test file
outside the program then the program will FOPEN and FCLOSE the file to
delete it.
But the FCLOSE that I'm testing (which should create a permanent file)
is causing an INTERNAL TRAP - I don't know what that is. Presumably
it's like a core dump or General protection fault. But I'm only passing
a file number and some constants so I can't see how I've got them wrong.
Please help.
This is the output -
:run peterx
TESTF does not exsist - not deleting.
Calling FCLOSE
**** INTERNAL TRAP
Data PAGE Fault
[VSM] Undecoded status.info = -300
ABORT: PETERX.DEV.DEV
NM USER c5.000a97e4 free+$48
NM PROG 197.00006140 _start+$310
Program terminated in an error state. (CIERR 976)
:pwd
/DEV/DEV
:
Here is the complete COBOL test program -
IDENTIFICATION DIVISION.
PROGRAM-ID. RELIO.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES.
CONDITION-CODE IS CC.
INPUT-OUTPUT SECTION.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 TESTF-LEN PIC S9(4) COMP VALUE -20.
01 TESTF-FNUM PIC S9(4) COMP VALUE 0.
01 ferr PIC S9(4) COMP VALUE 0.
01 TESTF-NAME PIC X(28) .
01 FILE-DESIG PIC X(28) .
01 recdata PIC X(20).
01 readdata PIC X(20).
01 info-reclen PIC S9(4) comp value 0.
01 ctrlcode PIC S9(4) COMP VALUE 0.
PROCEDURE DIVISION.
LEVEL-1 SECTION.
blah.
MOVE "TESTF.DEV.DEV" to TESTF-NAME.
CALL INTRINSIC "FOPEN" USING TESTF-NAME \1\ \5\
TESTF-LEN \\ \\ \\ \\ \\ \1000\ \32\ \1\ GIVING
TESTF-FNUM.
IF CC NOT = 0
DISPLAY "TESTF does not exsist - not deleting."
ELSE
display "deleting test file."
CALL INTRINSIC "FCLOSE" using testf-fnum \4\ \0\
.
CALL INTRINSIC "FOPEN" USING TESTF-NAME \0\ \5\
TESTF-LEN \\ \\ \\ \\ \\ \1000\ \32\ \1\ GIVING
TESTF-FNUM.
IF CC NOT = 0
DISPLAY "FOPEN failed."
call intrinsic "FCHECK" using \0\ ferr
display "system error ", ferr
stop run.
display "Calling FCLOSE".
call "FCLOSE" using testf-fnum \1\ \0\.
IF CC NOT = 0
DISPLAY "FCLOSE failed.".
DISPLAY "finished.".
This is what I did wrong -
I noticed the trap info looks a bit like a stack trace and I could see
"free" on it which I know (as a C programer) is part of the C library
and often causes core dumps/GP's when releasing unallocated memory.
Then I realised it must be somehow calling the fclose() function from
the C library. Then I realised I'd missed "intrinsic" from the call
statement!!! I've been developing with ACU COBOL where you don't have
to do that - that's my excuse and I'm sticking with it. It works now.
Not sure how it found the C library though.
Cheers
Peter
--
http://www.beluga.freeserve.co.uk
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
|
|