Gods Of COBOL

[MichaelBlane]

Funny, that's who I work for. Which DIVISION and SECTION is this piece of code in?

[Chris Losinger]

am i allowed to say ? :) it's a NCOA thing, for the USPS.

image processing toolkits | batch image processing

[MichaelBlane]

I work for a contractor. The DIVISION and SECTION that the code is in would be helpful, as the code would have a different function depending on where it is located. If in the SCHEMA SECTION, this is most likely a set of Key lookup tables. If in the LINKAGE SECTION, this could be a subroutine pass from another programming language. If this is in the WORKING-STORAGE SECTION, it's possible that the original programmer was trying to write a piece of code in Assembler and have it called as a binary routine. If this is the case, there will be a LOADING paragraph in the PROCEDURE DIVISION.

[Chris Losinger]

ah... that section/division (still learning the COBOL lingo). it's in the data division, working-storage section. it's a temp in-memory table. the full def'n is actually:

   01 MEMORY-AREA-ONE                           PIC X(2816).

   01  REDEFINES MEMORY-AREA-ONE.
       05 MEM-ONE-CHUNK OCCURS 11  TIMES
          INDEXED BY MEM-ONE-X                  PIC X(256).

   01  REDEFINES MEMORY-AREA-ONE.
      05 K01-1 OCCURS 37 TIMES
               INDEXED BY K01-1-X               PIC 9(04) COMP-5.
      05 K02-1 OCCURS 1369 TIMES
               INDEXED BY K02-1-X               PIC 9(04) COMP-5.

it looks like that MEM_ONE_CHUNK thing only used to initialize the entire buffer.

       MOVE LOW-VALUES TO MEM-ONE-CHUNK(1)
       PERFORM VARYING MEM-ONE-X FROM 2 BY 1
        UNTIL(MEM-ONE-X > 11)
        MOVE MEM-ONE-CHUNK(1) TO MEM-ONE-CHUNK(MEM-ONE-X)
       END-PERFORM

that's the only place that particular redefine is used. seems like an odd way to do things.

image processing toolkits | batch image processing

[MichaelBlane]

What is the definition line in the WORKING-STORAGE SECTION for "LOW-VALUES"? It's probably an "01" or "77" line. If it's a "77" line, it will not have anything underneath it that subdivides it like the "01" lines do. Because of the ">" in the PERFORM statement, you are using a "newer" version of COBOL (the older - COBOL 68, 74 standards forced the relationals to be written out "IS GREATER THAN"). Not that that's helpful at this point, but you may be able to find the "newer" COBOL manual(s). Are there any COMMENTS in the IDENTIFICATION DIVISION that tell you what this program is supposed to do? I also wonder, does this program have a LINKAGE SECTION in it? If so, this code could be called from another program.

[MichaelBlane]

Chris, check your "image processing toolkit" support email address. I've sent you an email for offline help.

[CJ_1]

Fujitsu Cobol.NET has been very very good to me! Was my bridge from the mainframe world to the .NET world. Converted a legacy MicroFocus COBOL financial system to a .NET system. While Fujitsu may be a pig, it enabled us to re-use complicated COBOL business logic and increase our delivery time. Can't say I miss coding in COBOL but, .... in another 15 years who knows what the market will be paying folks with COBOL knowledge :cool:

[LockH]

LOW-VALUES is not a literal or a variable, but a "figurative constant". Commonly used to initialise variables, or areas of storage, or for comparisons like IF MY-VARIABLE > SPACES THEN ... LOW-VALUES means binary zeros, the lowest thing possible in the collating sequence. HIGH-VALUES means binary ones, the highest value in the collating sequence. SPACES was the only other figurative constant that I remember. The practice of initialising one chunk of memory with a figurative constant, then using a loop to copy that chunk, was a performance optimisation, minimising the size of the object code and the run time taken. If I remember right, moving a figurative constant like "spaces" or "low-values" to up to 256 bytes took only one machine instruction, but if the target area was longer than 256 then the compiler generated a loop to set one byte at a time. So initialising 256 bytes, then looping to copy the 256 byte chunk, was faster for only a couple of bytes extra memory cost. This program, or at least this part of it, has been written with care by a skilled programmer putting in extra effort to produce a smaller faster runtime, instead of doing it the easiest way. So don't mock. Once upon a time, when dinosaurs roamed the earth, in my first year of programming I was tasked to make a suite of invoicing and sales ledger programs smaller, so that they would fit in whatever was going to be left over from the massive 64K of memory in our mighty 360/30 mainframe, after the new version of the IBM DOS/360 operating system was installed. We only had about 20 spare free with the previous version of DOS. No such thing as multi-programming or virtual memory, and the price of the next hardware upgrade had about five zeros on the end. I spent weeks rewriting little routines different ways and looking at the memory map of the generated code, changing all the literals like " " and " " or "XX" and "XXX" to multiple redefinitions of the same constants, thus saving the vital couple of hundred bytes.

[AECAEC]

Correct The Comp-5 was i believe setup to handle the big-endian, little-endian problem. And COBOL is still better then many of the more advanced languages for many activities. Especially those that do batch processing. Admitably not good for interaction "GUI" processes. COBOL and FORTRAN did not survive this long and still constiture over 50% of operational systems by not being GOOD at what they do. New colorable clothes are not neccesarily better then older ones. Primitive people are always attracted to pretty baubles. Anyone want to exchange the latest and greatest hardware for some pretty beads i have.

[MichaelBlane]

Chris, I think LockH is correct here in the description of producing a smaller faster runtime. That was because of the expense associated with the actual machine run-time allocation. That said, I think what this is doing is ensuring that the memory area used by K01 and K02 does not contain any incorrect or "ghost" information in the memory that could cause untraceable error messages within the program. You'll have to track down the actual use of the K01 and K02 and determine what those were used for. Something else to consider: COBOL was written for batch processing. It was only in the later years that the computer time became inexpensive enough to begin interactive processing. That said, this is most likely a "run this once a month, once a week, once a quarter" type program. That may help you in the detective work for the actual use of the program and/or the actual use of the environment that is being created here.

[alex turner]

01 MEMORY-AREA-ONE PIC X(2816). 01 REDEFINES MEMORY-AREA-ONE. 05 K01-1 OCCURS 37 TIMES INDEXED BY K01-1-X PIC 9(04) COMP-5. 05 K02-1 OCCURS 1369 TIMES INDEXED BY K02-1-X PIC 9(04) COMP-5. The previous was nearly there! COMP-5 is machine dependant. So on a little endian machine (eg x86) it will be backwards compared to a big endian machine link AIX. On big endian machines, COMP/COMP-4 and COMP-5 end up being the same thing (usually). COMP-3 is DCD and COMP-1/COMP-2 are poorly defined but often resolve to floating point. In more modern COBOL one would use float-short and float-long to resolve the issues with COMP-1 and COMP-2. PIC 9(04) means an unsigned _decimal_ integer of four digits INDEXED BY defines a working storage element (variable) which works a lot like a subscript to a C array. However, indexes in COBOL in old (very old) days were more efficient because they come pre-computed and avoid multiplications in computing memory offset (as all cpus have hardware multiplication - this is not an issue any more). You move the index by set up by and set down by like with pointers. If you are a C programmer - then just think of redefines like a union and the pain will go away. Also - why does everyone have to make fun of COBOL? I mean - what gives? Just because one does not understand something does not mean it is wrong. C does not even allow the definition of an unsigned 4 digit decimal. However, because such things are required, we have to use horrid library routines to work with them in C. So, despite its age - COBOL has its uses. It is just another language. Good on you for learning it. Take care - AJ www.nerds-central.com - welcomes all nerds :-)

[Mark Denson]

The first bit of code defines a storage area of 2816 bytes. The second code redefines that area into two tables of 37 items (starting at 1 not 0) which are declared as compressed numeric (4 bytes each). As to some of the comments regarding COBOL programmers, just remember the odds of your bank running millions of lines of COBOL code are extremely high. As to whether or not the programmers are sophisticated or not, just remember that many of us had to code programs that HAD to run in 64kb or less. Programs that had (have) the same requirements of many programs today. The one piece missing at the time was a graphical user interface. COBOL was and still is a character based language, despite efforts to convert it to something else. COBOL does not react to events. It starts at the top and runs until it encounters a STOP RUN command. With all that said, it does not change the fact that COBOL was and still is a very sophisticated language that after 60+ years is still running and still performing the tasks it was designed to perform. To all of you that think COBOL (or any other language for that matter) does not match up to (fill in the blank) language, I say this: You bore everyone, except (possibly) the other nerds who happen to agree with you, but then again everyone is bored by them as well.

[Member 3240213]

What the code means depends upon the flexibility or otherwise of the compiler used, and the specifics of the machine it was supposed to run on. In general terms the '01' prefix defines a word/byte aligned ares of memory. The use of 'redefines' means what it says - the two definitions map to the same area of memory. Generally a forgiving compiler won't be worried anout what other people have said, that one definition appears 'longer' than the other I'm intrigued by the 'PIC 9(04) COMP-5' definitions though - as far as I remember 'COMP-5' refers to binary data, not necessarily byte or word-aligned. So ignoring all that..... The user has declared a chunk of memory, nominally 2816 CHARACTERS long (the use of 'PIC X(..)' indicates a character field). The memory starts at a word/byte boundary (depends on the target hardware implementation). I would assume a word boundary myself... The memory area has been (alternatively) defined as two smaller 'tables' - or ARRAYS if you will. The first contains 37 items (each named K01-1), the second 1368 items (each named K02-1). These items will normally be referred to in the code using an index variable or literal (i.e K01-1(1) to K01-1(37), K02-1(1) to K02-1(1369) or K01-1(index variable name). COBOL compilers could generate run-time checks on the index values used to ensure that only valid ranges were used, and COBOL uses '1' as the lowest index value, rather than zero. Specifying the names K01-1-X and K02-1-X implies that later in the code the user will be using these items as the 'normal' way of addressing each (array) element. COBOL would let you mix and match whether you used literals, index variables, or integer data items to index the data. Use of the 'INDEXED BY...' allows the use in the code of statements such as:

SET index-name-variable TO n.
SET index-name-variable UP (or DOWN) BY n.

Otherwise you would normally define an integer data item and use that as an index value i.e.

01 ITEM-PTR PIC 9(4) COMP SYNC RIGHT.

and later

MOVE n TO ITEM-PTR.
ADD n to K02-1 (ITEM-PTR).
...etc.

You could also write things such as:

PERFORM suroutine-name VARYING K02-1-X FROM 1 BY 1 UNTIL K02-1-X EQUALS 1369.

The only downside of COBOL was that the arrays were of fixed size (up to 3 dimensions), and you had to know at the time of compiling the code what the maximum index values were for each dimension. In practise this wasn't hard as you had to design the table (array) to suit your requ

[eslsys]

ok I haven't read thru all your answers and someone else may have given you a fuller or better answer - my memory of this stuff is hazy at best (I've moved it to memory area 99). So Memory-Area-One is reserved as an alphanumeric PIC X of 2816 characters (hazy recall, rather than bytes, bits or whatever) Memory Area One is redefined as consisting of two numeric arrays, the firsts variable name is K01-1 and the array index for each array item is K01-1-1 to K01-1-37, I cant remember if this is zero based or not - sorry. The second array variable K02-1 which has 1369 (1370?) array elements, as before array element index is K02-1-1 to K02-1-1369. The array is a numeric array, 9 digits in total of which there are 4 decimal places (or was it 5 decimal places) Hope that helps and sorry its just tooooooooo long ago - fortunately :)

[Mark Puddephat]

Excuse me, I'm only 49!!! Bloody cheek!!! In C-speak, it's a union of a string and two arrays. (I learned C before I learned COBOL.) We all like to knock COBOL (not invented this year!), but we shouldn't. It does a more than adequate job for most business-related data crunching, and is way easier to learn and use than .NET or Java, even if it does lack a few nice features, like OO, terseness, data hiding...