Inside COBOL #69 (Tips and News)
Well I spent some time starting to read “An Introduction to Object Cobol by E. Reed Doke, Bill C. Hardgrave” this last month, and so far I can highly recommend it. It’s more of a text book and not as thick as you would think. I’ll write up more of a review after I finish reading it.
I just some interesting news in regards to COBOL on IA64. HP has confirmed that COBOL, C, C++ and Java will ship in Native Mode for the IA64 platform when it first comes out. There is some question as to which C++ compiler will be used, but it will probably be the GNU one.
This is extremely good news for us COBOL enthusiasts (not so good for the FORTRAN and Pascal people though). While HP has committed to COBOL, they haven’t committed to which COBOL. I’m assuming at this point that HP will continue to develop and maintain the COBOL compiler for the HP, since there doesn’t seem to be a viable alternative. My concern is if they are going to try to keep COBOL up to date or not.
In case you didn’t know, the HP implementation of COBOL is missing a fair amount of features from the ANSI specification, such as the SCREEN section and REPORT section. I’m not even sure how the REPORT section works, but the SCREEN section could have been implemented to wrap VPLUS and saved us from coding the VPLUS intrinsics and made our code more portable.
The big question is if HP will try to go for the COBOL 2000 standard and include the Object Oriented features that are described in it. If you’ve read the last couple of months, you know what a big shift this will be, and probably require enormous effort and commitment from HP.
There has been a survey running around on the SIGCOBOL-L about what features and things you would like to see in the next release of COBOL. Since HP is in the planning stages at this point, it’s important to let them know how you feel about what you would like to see in the next release. If anyone at HP is reading this, count my vote for OO COBOL.
There was some recent discussion on the 3000-l about how to have COBOL create a file with something other than the default number of records. Doug Werth of Beechglen put up a nice succinct example, that also shows the use of dynamic name assignment in the SELECT..ASSIGN
001100 IDENTIFICATION DIVISION. 001200 PROGRAM-ID. COBTEST. 001300 ENVIRONMENT DIVISION. 001400 CONFIGURATION SECTION. 001500 SPECIAL-NAMES. 001600 CONDITION-CODE IS C-C. 001700 INPUT-OUTPUT SECTION. 001800 001900 FILE-CONTROL. 002000 SELECT FILE1 ASSIGN TO "TEST,,,,55000" USING DYNAMIC-NAME. 002100 I-O-CONTROL. 002200 DATA DIVISION. 002300 FILE SECTION. 002400 FD FILE1. 002500 01 FILE1-RECORD PIC X(80). 002600 002700 WORKING-STORAGE SECTION. 002800 01 PROGRAM-NAME PIC X(26) VALUE SPACES. 002900 002902 01 DYNAMIC-NAME PIC X(16) VALUE "FILENAME". 003000 PROCEDURE DIVISION. 003100 0000-CONTROL-PROCESS. 003300 MOVE "MYFILE" TO DYNAMIC-NAME. 003400 OPEN OUTPUT FILE1. 003500 CLOSE FILE1. 003600 STOP RUN. :run cobtest :listftemp,2 FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE---- SIZE TYP EOF LIMIT R/B SECTORS #X MX MYFILE 80B FA 0 55000 3 0 0 * (TEMP)
I ended up in an interesting trivia conversation with some programmers recently on whether you could use a VALUE clause on a table. I don’t know when this changed, but when I wanted to initialize all the members of a table I would usually declare a buffer, and then redefine it as a table, then I could move spaces to the buffer or set VALUE SPACES on it at declaration time.
Well guess what? You can put a VALUE clause on the table declaration itself, as in:
01 MY-TABLE. 03 MT1 PIC X(10) OCCURS 5 VALUE ZEROES. Now if I do a display of the data as in: DISPLAY '[' MT1(1) ']'. DISPLAY '[' MT1(2) ']'. DISPLAY '[' MT1(3) ']'. DISPLAY '[' MT1(4) ']'. DISPLAY '[' MT1(5) ']'. I will get the following display     
I can then do MOVE SPACES TO MY-TABLE and all of the occurrences of MT1 will now have spaces in them.
Well that’s it for this month – keep those tips coming.