HP3000-L Archives

November 2003, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Peter Smithson <[log in to unmask]>
Reply To:
Peter Smithson <[log in to unmask]>
Date:
Fri, 14 Nov 2003 04:48:47 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (121 lines)
 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 *

ATOM RSS1 RSS2