Hi
We crashed our Dev box today, twice, with a program containing a COBOL
error. I don't think that's supposed to happen to HP3000's.. :-)
Here's the offending fragment of code. It's a macro call for a DBGET.
We use 1000's of these, and they usually work just fine.
Base, Set, Key, Key Value, DB-Buffer.....
01850 XX030820 018600
01851 XX030820 018700 %DBGET(01#,"CODES"#,"CONCAT-KEY"#,CONCAT-KEY OF CDS#).
Did I say DB-Buffer? Oops. He missed it off on this one. But the macro
does what macros do, and writes the COBOL code without that field....
01851 XX000323 010300*--- Do a DBFIND/DBGET on detail dataset "CODES"
01852 XX951108 010400 MOVE 01 TO DB-BNR
01853 YEAR2000 010500 MOVE "CODES" TO DB-SETNAME
01854 YEAR2000 010600 MOVE "CONCAT-KEY" TO DB-KEYNAME
01855 XX951108 010700 MOVE 10 TO DB-FUN
01856 XX000121 010800 MOVE 0 TO DB-LCK
01857 XX951108 010900 DB-ULK
01858 XX000229 011000 MOVE CONCAT-KEY OF CDS TO DB-ITEM
01859 XX030820 011100 CALL "DBACCESS" USING SR-PARAMS .
There should be a DB-BUFFER after that SR-PARAMS, and before the
full-stop. But it's legal code, and so it compiles.....
01860 XX030820 018800
01861 XX030820 018900 IF DB-OK <> 0
01862 XX030820 019000 %ERROR("Missing program parameter " DB-ITEM#)
01862 XX941004 011900
01863 XX030819 012000 DISPLAY "TESTFX04: ERROR - "
01864 XX941004 012100 "Missing program parameter " DB-ITEM
01865 XX030820 012200
The DBACCESS it CALLs is our common Image handler. Again, it gets used
1000's of times, and works just fine, if you call it correctly.
So we're on our way to a bog-standard Image intrinsic DBGET from the
above, in an ANSISUB subroutine with the following control options:
* $VERSION "<v>DBACCESSMAINT 00000001010303262005 " YEAR2000
+1 $COMMENT $SET X1=ON XX000814
+2 $INCLUDE DEFMACRO.INCLUDES
+3 $CONTROL OPTFEATURES=CALLALIGNED LINKALIGNED,OPTIMIZE
+4 $CONTROL ANSISUB,BOUNDS
and which is called as follows:
+6 ******************************************** XX000120
+7 PROCEDURE DIVISION USING SR-PARAMS DB-BUFFER. SP011008
+8 ******************************************** XX000120
Note that it takes two parameters. As the COBOL manual says of the CALL
and the CALLed program:
Number of parameters must be the same.
and indeed, if we Link as follows:
DEV/PROGTEST(MGR)/PUB>link from=TESTfx04.object,dbaccess.object;to=roytest.nmprg
HP Link Editor/iX (HP30315A.06.23) Copyright Hewlett-Packard Co 1986
LinkEd> link from=TESTfx04.object,dbaccess.object;to=roytest.nmprg
INCOMPATIBLE NUMBER OF ARGUMENTS: dbaccess (TESTFX04.OBJECT, DBACCESS.OBJECT) (
LINKERR 1042)
FOUND 1 TYPE CHECKING ERROR(S) (LINKERR 1010)
LINK FAILED (LINKERR 1116)
it fails as you might expect.
However, we don't do it like that; we link TESTfx04 on its own, and
then:
RUN TESTfx04.nmprg;xl="XL.NMPRG"
where the XL contains DBACCESS.
Now, I'm not quite sure when and where MPE should notice it's been
shortchanged on the CALL - at load time, when parsing the RUN?
Or not until the bad CALL is encountered during the program run?
(If it is - and it always is encountered, in that program at least).
Either way, I can't seem to find a runtime error message that would
correspond with the INCOMPATIBLE NUMBER OF ARGUMENTS from the LINK
above. So I wonder how it's going to tell me.
In practice, it told us (twice) about the problem by halting the 928.
Not good..... One time, my colleague ran the bad program without
crashing the box, but I didn't find out exactly what happened that time.
Finally, FWIW, we've no COBRUNTIME in force, and the OS version is:.
RELEASE: C.75.00 MPE/iX HP31900 C.45.05 USER VERSION: C.75.00
The fix for the immediate problem is easy - put the DB-BUFFER in , and
all is just fine and dandy.
But we more or less take it as a given that nothing we do as
programmers, no matter how stupid, should crash the box - unless we're
tinkering with PRIV mode, which we don't. (And I don't count standard
Image calls as PRIV mode for these purposes, as they are all safely
wrapped up for us).
Any known problems in this area? Anything else we should investigate
before putting in that inevitable support call to HP?
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
