HP3000-L Archives

September 1998, Week 1

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:
"James Clark, Jr." <[log in to unmask]>
Reply To:
Date:
Fri, 4 Sep 1998 14:34:07 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
I would load the program on the 960 and if you have Glance check to see what
files are opened. I believe Glance will tell you the XL's also. One option is
that CALLX was added to the system XL and you do not want to over-write the new
one on the 969 with the old one from 960. Another consideration is CALLX is an
internal call of COBOL and the versions of COBOL are not the same. Next option
is to try to locate the CALLX procedure and make sure it is in the same place
that the code thinks it should be on the 969.

James

> -----Original Message-----
> In moving our code from the 960 to 969, I've run into a bit of a
> quandry.  Everything is duplicated down to the wire a best as I can
> tell, but I have several Cobol application which calls a couple of
> local XL routines that are now aborting in one of the XL routines.
>
> I've copied the program files and XL files from the 960 several times
> to insure I had the real code.  The only difference is PP5 on the 969
> and PP4 on the 960 (a powerpatch breaks Cobol code?).  Anyway, the abort:
>
> > **** INTERNAL TRAP
> > Instruction Memory Protection Trap
> > [VSM] Undecoded status.info = -60
> > ABORT: CARS.PUB.DB
> >        PC=a.fff7f000 $RECOVER_END
> >           CALLX stub: 534.000096d0 semester+$234
> > NM* 0) SP=41846a30 RP=534.00009448 ?semester+$8
> >          export stub: 5e8.00038ac0 cars0000+$1810
> > NM  1) SP=41846970 RP=5e8.00017ad0 carslinkage+$d14
> > NM  2) SP=418466f0 RP=5e8.00035dcc _start+$14c
> > NM  3) SP=418463f0 RP=5e8.00000000
> >      (end of NM stack)
> >
> > R0 =00000000 40100ec0 000096d3 82d7e000 R4 =ffffffff 41846734
> 00110168 4163fb08
> > R8 =0000f048 30303030 20202020 00000000 R12=00000000 00000000
> 00000000 00000000
> > R16=00000000 00000000 00000000 00000084 R20=fff7f000 00000534
> ffffffe8 4164d5a1
> > R24=00000000 418469e0 000007ce 41643000 R28=000007cf 00000084
> 41846a30 00000000
> >
> > IPSW=0004000f=jthlnxbCvmrQPDI  PRIV=3   SAR=0008 PCQF=a.fff7f003 a.fff7f007
> >
> > SR0=0000000a 00000000 00000000 00000000 SR4=00000534 00000504
> 0000000b 0000000a
> > TR0=41846cd5 418518ac 008354c8 d69a4000 TR4=014b8c60 41847358
> 0021e374 0000000f
> > PID1=032a=0195(W) PID2=05f6=02fb(W)     PID3=0000=0000(W) PID4=0000=0000(W)
> >
> > RCTR=00000000 ISR=00000504 IOR=41846a14 IIR=6bd53fc9 IVA=0013b000
> ITMR=608d700e
> > EIEM=ffffffff EIRR=00000000 CCR=00c0
>
> What is the odd "CALLX" entry at the beginning of the trace?
>
> Any help greatly appreciated, thanks in advance
>
> Jeff Kell <[log in to unmask]>
>

ATOM RSS1 RSS2