OK, this is Not Good® code. I didn't write it, but I have to deal with it:
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTIT.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WK01-CLI-COMMANDS PIC X(250) VALUE SPACES.
01 WK-RETURN-STAT PIC S9(09) COMP.
PROCEDURE DIVISION.
0-BEGIN.
MOVE SPACES TO WK01-CLI-COMMANDS.
STRING "DIR/NOHEAD/NOTRAIL"
"/OUT=SYS$SCRATCH:TEMP.OUT/VERS=1 "
"SYS$SCRATCH:"
DELIMITED BY SIZE INTO WK01-CLI-COMMANDS.
CALL "LIB$SPAWN" USING BY DESCRIPTOR
WK01-CLI-COMMANDS GIVING WK-RETURN-STAT.
STOP RUN.
END-PROGRAM.
When run interactively, this code behaves itself. No alignment faults as you'd expect. However, if you write a simple one line command procedure to run the resultant image and submit it to batch, the thing generates alignment faults like crazy. Including an executive fault at RMS+001DC540. (Note I'm seeing this via SDA> FLT START TRACE/INDEX=).
IA64 OpenVMS 8.3-1H1 patched up-to-date. HP COBOL V2.9-1453
There should be no unaligned data in this code. Everything in the working storage section is at level 01. Has anyone seen something like this? While I'd love to tell the programmers just to substitute a lib$find_file
, I'm guessing that this will meet with resistance.
I guess this will end up as a logged call...
Posted at September 16, 2008 5:38 PMComments are closed