|
Dougs' replay was the closest thing to correct so far.
01 MEMORY-AREA-ONE PIC X(2816).
This just defines a 2816 byte vaariable and the PIC X means it's alphanumeric
01 REDEFINES MEMORY-AREA-ONE
This says your going to redefine that chunk of data into a different structure/layout
05 K01-1 OCCURS 37 TIMES
INDEXED BY K01-1-X PIC 9(04) COMP-5.
These 2 lines make an array of 37 four digit numbers (0000-9999) and gives you a subscript named K01-1-X to reference entries 1-37
remember COBOL subscripts start at 1 not zero.
This K01-1 array actually exists in the first 74 bytes of MEMORY-AREA-ONE
The COMP-5 or any COMP in COBOL basicall says to save space by representing the numbers in memory (like they should) in a binary format. COBOL will basically use a string for numbers is you don't use COMP (1 byte for each digit)
05 K02-1 OCCURS 1369 TIMES
INDEXED BY K02-1-X PIC 9(04) COMP-5.
This is basically the same except it uses bytes 75-2812 of MEMORY-AREA-ONE to define and array of 1369 four digit numbers and gives you subscript K02-1-X to reference it.
I'd say the original author didn't quite understand COBOL either as you dont need to define extra space in the MEMORY-AREA-ONE for the subscripts. if it was 01 MEMORY-AREA-ONE PIC X(2812) it would have worked the same.
|
|
|
|
|
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 
|
|
|
|
|
Hi Chris,
you are aware there are a couple of .NET COBOL compilers around?
you might be lucky and have a look at the IL your source generates; and reflector might be willing to show you equivalent C# or VB.NET code. And maybe you don't need to translate it after all, just run it...
|
|
|
|
|
Luc Pattyn wrote: you are aware there are a couple of .NET COBOL compilers around?
Their authors should be flamed, immediately. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
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 
|
|
|
|
|
No cookie for you: COBOL is the only computer language invented by the Etrurians.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Isn't that part of the start up code for Cylons...oh wait, that's "Lords of Kobol" 
Steve
_________________
I C(++) therefore I am
modified on Friday, April 9, 2010 5:55 PM
|
|
|
|
|
01 SORRY-CHRIS PIC YOUR-NAME(LANCELOT).
01 I-DON'T-KNOW.
05 IDK OCCURS 100 TIMES
INDEXED BY I-REALLY-DON'T-KNOW PIC A-COLOUR(BLUE).
05 IDK-2 OCCURS 1520 TIMES
INDEXED BY WHAT-IS-THE-CAPITAL-OF-ASSYRIA I-DON'T-KNOW-THAT(NONE).
Output is apparently "Arrrrrrrrrrrrrggggggggggghhhhhhhhhhhhhhhhhh!"
|
|
|
|
|
Hahaha. Excellent dude. Best Holy Grail reference I've seen yet.
|
|
|
|
|
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.
maybe becomes 
union {
{
PIC MEMORY-AREA-ONE X[2816];
struct {
PIC K01-1-X;
PIC K01-1[37];
PIC K02-1-X;
PIC K02-1[1369];
} COMP-5
};
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
Chris Losinger wrote: 01 MEMORY-AREA-ONE PIC X(2816).
Allocate a block of memory 2816 bytes in size and fill with 'X'.
Name the block of memory 'MEMORY-AREA-ONE'.
Chris Losinger wrote:
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.
Reallocate the array for a different purpose.
K01-1 is an array that contains 37 elements.
The index to the array is K01-1-X.
Each element is a 4-byte numeric. 'PIC 9(04)'
Each element is stored as a 2's complement big-endian number in machine-dependant format. 'COMP-5'
When I say big-endian I mean that when the number is displayed it will be displayed as 4 digits from left to right with most significant to least significant order. Whether it's big-endian in memory depends on the implementation.
K02-1 is a 1369 element array with similar properties.
K01-1-X and K02-1-X are the variables used to index the arrays. Each one belongs to it's respective array and can't be used for the other one.
p-code example:
for K01-1-X in {1 .. 37}
do something with K01-1[K01-1-X]
-Sean
----
Fire Nuts
modified on Friday, April 9, 2010 6:58 PM
|
|
|
|
|
how can they be 4 byte integers ? that's twice the size of the MEMORY-AREA-ONE's 2816 bytes.
(37 + 1369) * 4 = 5624
i'm thinking the 4 is the number of places allowed for the value. 9(4) is a 4 digit integer (0-9999) ? you can fit that in a two byte integer, which would fit in the 2816 bytes.
make sense ?
|
|
|
|
|
yeah I updated my post after I realized I put the wrong info in it.
4 byte 'numeric'. the numeric is stored in memory as a 2's complement number, big-endian and machine-dependent format.
So
37 * 2 + 2 for the first array, and
1369 * 2 + 2 for the second array.
==> 76 + 2740 = 2816 bytes.
-Sean
----
Fire Nuts
|
|
|
|
|
PIC simply sets the output type. PIC X is alphanumeric, and PIC 9 is numeric, so PIC X(2816) is 2816 alphanumeric characters (in this case used to reserve contiguous space -- a common trick in COBOL, where you're not supposed to worry about things like memory allocation), and PIC 9(4) is four numeric digits.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
It throws an exception!!
Either a
System_TerrorException
or a System_LiquidNitro one.
|
|
|
|
|
Or a Dumber_Than_Baboon_Exception.
|
|
|
|
|
My bad. I totally forgat about it. Forgime me pls!!!
URGENT!!!
|
|
|
|
|
I knew cobol in another long ago and far away life.
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.
If I remember right, that corresponds to :
struct numeric_arrays
{
short k01_1_x;
short k01_1[37];
short k02_1_x;
short k02_1[1369];
};
union mem_area
{
char memory_area_one[2816];
numeric_arrays k01_and_k02;
};
As others have said, the PIC 9(04) is 4 numeric digits and the comp-5
packs it to 2 bytes. I believe the indices map to mem preceding the array
parts in mem, but I'm not 100% sure.
|
|
|
|
|
01 MEMORY-AREA-ONE PIC X(2816)
Declares a variable of 2816 chars, same as C char[2816].
The REDEFINE statement means that the next structure will occupy the same physical memory as MEMORY-AREA-ONE - much like a C UNION.
Each 'PIC 9(04) COMP' is a 4 byte numeric optimised for computation, this is the same as a C UINT. If 'COMP' had been ommitted then the each of these variables would be able to store anything from 0 to 9999 and these would be stored as ASCII numeric digits which isnt efficient for computation but is how COBOL was designed to be used by 'non programmers' who didnt need to understand computer internals.
This structure is typically used for low level data manipulation like encryption or compression because its the only way you could have a sequence of numbers and be able to address bytes at any offset within a structure - the char[2816] is effectively used as a char*.
OCCURS is just an array count.
Hope that answers your questions.
|
|
|
|
|
Not a COBOL programmer, but here goes nothing:
Comp-5 is a "native" binary format. Equivalent of "comp" type.
pic 9(4) comp-5 is a two-byte unsigned binary 0 - 65535.
Roughly in 'C, you are looking at:
union
{
unsigned char buffer[2816] ;
struct
{
unsigned short k01[37] ;
unsigned short k02[1369];
} a ;
} mem_area_one ;
The layout of the two-bytes is platform specific ("native"), so if the COBOL is running on a PC platform, the two-bytes are stored in memory reversed (value of 12 decimal is stored as 0x0c00 in byte order).
|
|
|
|
|
As previously pointed out, MEMORY-AREA-ONE is a string of 2816 characters [PIC X(...) is the method by which character data is reserved/declared, and space assigned for it].
The REDEFINES... is a common COBOL method for permitting memory/data to be accessed in multiple ways. The C/C++ equivalent would be a "struct" definition with a "union" component -- you can access the memory using either elements of the struct, or elements of the union.
Most "COMP-xx" data definitions are implementor-defined, so you will need the specific COBOL documentation for the machine upon which this code was implemented. IBM was a big user of COMP-xx declarations, and had several flavours of them, so you could have true floating-point, or packed-decimal data in a COBOL program by using their COMP-xx datatypes. Without the specific documentation, it is impossible to say exactly how the redefined data mask would lay out over the original character space. These kinds of implementor-defined situations always made conversions from one mainframe machine architecture to another somewhat interesting.
The INDEXED BY clauses instruct the compiler to reserve specific indexes for iterating through the array created by the OCCURS clause. The assignment of an index usually translated (at the machine hardware level) into the use of a reserved index register. This was done for performance, rather than using a memory-based byte/word for storage of the array index value. As such, you don't need to be too worried about the INDEXED BY clause, as it's more a compiler instruction than anything else.
Hope this helps.
Norm Powroz
Former member, CODASYL COBOL Committee (the people who designed the language)
Former Member, ISO COBOL Experts Group
Former Member, CSA COBOL Working Group
...and I'm not retired yet 
|
|
|
|
|
COBOL pre-allocates memory for everything in the code at runtime. All variables used are created in the WORKING STORAGE section. Nothing is dynamically created or destroyed in a garbage collection sweep.
PIC X is a byte of memory, so PIC X(2816) is a block of memory taking 2816 bytes. By default, "PIC" will use the translation base of the machine, e.g. EBCDIC on a mainframe or ASCII on most anything else.
"COMP" data types are a way to pack numeric values into a smaller number of bytes, much like INT and FLOAT. PIC 9 is a numeric data type. PIC 9(4) uses 4 bytes of memory to contain the number. PIC 9(4) COMP-5 in particular is a 32-bit signed float.
"OCCURS" is used to create an array. "INDEXED BY" also creates the index to the array at the same time.
"REDEFINES" means "uses the same memory space as".
Putting it all together:
01 MEMORY-AREA-ONE is simply a block of memory using 2816 bytes. Inside that block of memory, there are two float arrays, one called K01-1 with 37 elements, and the other called K02-1 with 1369 element. To reference a given element in an array, you first assign a value to the index, then you can get what you need from the array. e.g. "MOVE 1 TO KO1-1-X." followed by "ADD K01-1 (KO1-1-X) TO TOTAL."
I don't know why you use a REDEFINES for a bunch of floats, unless you needed to dump all of them to an output file for some reason, then it's only 1 line of code, rather than writing the loop logic.
(I'm a 2nd-gen coder. The old man taught me this stuff when I was 14. His lab classes when he was in school were "paper-tape in, oscilloscope out" and they programmed in binary. He used to quote "Assembler was a godsend." I'm attending the VS 2010 launch in 15 minutes.)
Good luck.
|
|
|
|
|
This does not appear like a valid definition.
Since "9(04) COMP-5" represents a 2-byte integer number and (37 + 1369) * 2 = 2812 and not 2816, you are certainly missing some further variable definitions or the COBOL program itself does not compile (or, if it does, it is not a very well made program).
"INDEXED BY" just means that the tables defined by names K01-1 and K02-1 can be searched for values using built-in SEARCH function(s).
|
|
|
|
|
MEMORY-AREA-ONE is defining an alph-numeric space of 2816 bytes aligned to a work boundary
The redefines is overlaying the mapping ( similar to a C union ) with two arrays of compresses numeric ( check your compiler doc regarding how these are represented internally ). The punch line is that 9(04) COMP-5 takes two bytes.
My math may be off, but it looks like the original space has four extra bytes
|
|
|
|
|
asherw0202 wrote: My math may be off, but it looks like the original space has four extra byte
that's what it looked like to me, too. and that's really the primary reason i asked the question - why define an overlay/alias that doesn't fit the original memory ? is that intentional but sloppy, or is there some tricky COBOL thing that explains it?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
