I don't know if there's any interest in this, but I have found a very
short program where the old compiled version causes a problem with
VLIST. Here are the details
The old compiler version was 9.3.1.2, the new one 10.2.0.0
001: $OPTIONS -F L ;*WR631
002: *
003: *** TITLE: Time conversion routine.
004: *
005: * Written by Wilfred D'Mello, 02-August-1993
006: *
007: PRINT
008: PRINT "Time conversion routine. Press RETURN to
return to TCL"
009: PRINT "You may enter time in 24 hour format eg:
18:30:26 "
010: PRINT " OR "
011: PRINT "In 12 hour format with AM/PM appended eg:
6:30:26PM"
012: PRINT
013: LOOP
014: PRINT "Enter Time to convert ":
015: INPUT ITIME
016: UNTIL ITIME = '' DO
017: ITIME = OCONV(ITIME,"MTS")
018: ITIME = ICONV(ITIME,"MTS")
019: PRINT @(40):"ICONV()=":ITIME:
020: PRINT @(60):"OCONV()=":OCONV(ITIME,"MTS")
021: PRINT
022: REPEAT
023: END
When I used VLIST, the line numbering gets out of kilter at the LOOP -
all the source prints, then the if fell over like this
00023: END
00258 0001C : 12E print "Enter Time to convert "
00259 00022 : 0B9 input 0 16 => ITIME
00260 0002A : 10C nop
00260 0002C : 06E eq ITIME "" => $R0
00260 00034 : 2E0 testtw $R0 00084:
00261 0003C : 112 oconv ITIME "MTS" => ITIME
00262 00044 : 0AC iconv ITIME "MTS" => ITIME
00263 0004C : 04A cursor 40 -1 => $R0
00263 00054 : 12E print $R0 "ICONV()=" ITIME
00264 0005E : 04A cursor 60 -1 => $R0
00264 00066 : 112 oconv ITIME "MTS" => $R1
00264 0006E : 130 printcrlf $R0 "OCONV()=" $R1
00265 00078 : 126 pcrlf
00266 0007A : 10C nop
00266 0007C : 0C2 jump 00000:
00267 00084 : 01C calculate Abnormal termination of
UniVerse.
Fault type is 11. Layer type is Unknown.
Program "/usr/ibm/uv/bin/vlist" core dumped. [SIGSEGV]
segmentation violation
Interestingly, I don't get the core dump if the source is missing - but
the last two lines don't make any sense to me.
00266 0007C : 0C2 jump 00000:
00267 00084 : 01C calculate [365] => [49]
The VLIST output from a newly compiled program ends like this
00022: REPEAT
00022 0007A : 10C nop
00022 0007C : 0C2 jump 0001C:
00023: END
00023 00084 : 190 stop
So it looks like there's some problem with the way it works out the jump
address. I compared the object code and the only changes are in the
header and a couple of extra char(0)s at the end of the program. If the
logic is unchanged, why does the addressing go wrong?
OLD NEW
3 147 162 <--- EG old version has char(147) as third
character, new is char(162)
4 18 0 Aha! DTX 147 = 93 18 = 12 -> 9.3.1.2 DTX 162
= A2 0 = 0 -> 10.2.0.0
8 0 16
29 0 255
30 0 9
31 0 8
32 0 216
51 0 42
52 0 72
73 0 70
74 0 85
75 0 18
76 0 15
657 255 0 <--- New one is two characters longer
658 255 0
I'm off until Monday morning, so I won't be able to give any further
details before then. It's definitely a puzzle, and possibly a bug.
Regards, Keith
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
