Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

C Program Logic 3

Status
Not open for further replies.

FireStarter1

Programmer
Jun 6, 2003
40
US
Hi
I am very much new C programming. We are in the process of making an application on the mainframe in cobol. Can someone please tell me what the following piece of C program do.

typedef unsigned char Byte; /* Byte as unsigned char */
typedef unsigned short Word; /* Word as unsigned short */

Word wBuildCrc (Byte *pbBuf, unsigned wLen, Word wCrc)
{
Byte bCh;
Word j;
char i;


bCh=(Byte)(wCrc & 0x00FF);
wCrc=(wCrc>>8) + (unsigned short)bCh*0x100; /* " */


for (j = 0; j < wLen; j ++)
{
bCh = pbBuf[j];
wCrc=wCrc ^ ((unsigned short) bCh <<8);
for (i=0; i<8; i++)
{
if (wCrc & 0x8000)
wCrc = (wCrc << 1) ^ 0x1021;
else
wCrc = wCrc << 1;
}
}

bCh=(Byte)(wCrc & 0x00FF);
wCrc=(wCrc>>8) + (unsigned short)bCh*0x100; /* &quot; */

return(wCrc);
}


Word cdecl uiBuildCrc (Byte *pbBuf, unsigned wLen, Word wCrc)
{
return(wBuildCrc (pbBuf,wLen,wCrc));
}
 
It computes a cyclic redundancy check.

The problem with CRCs is that they are based on one bit more than what is normal eg a 16 bit CRC normally uses 17 bits so there is a lot of shifting about and finding out what the top bit is.

If you come from a Cobol background, try something higher level like reading from files, moving data about and simple computations. Only try stuff like CRCs when you are more familiar with the language. CRCs isn't a good place to start.
 
Thanks a lot for giving me the info. If you understand the code can you tell me what this code is doing I want to do the same in cobol. I really don't understand the logic.
 
Hi,
Can anyone in plain english tell me what the above C code is doing. I know it is trying to do a Cyclic redundancy check, but I don't know much above that. I need to implement the same logic in the C code above in cobol. Somebody please help me out here.
Thanks.
 
Wonder if it is possible / smart to code this in Cobol ?

Can you do bit-stuff like
&quot;bitwise exclusive or&quot; and test if a single bit is set ?

Haven't you got a C-compiler on the mainframe ?

/JOlesen
 
Hi,
There is a C compiler on Mainframe but the company really don't want to implement this portion individually. The CRC is only part of a program that convert a file into binary and send it to workstation. If you can tell me what this piece of code is doing then I can try it in cobol.
 
Thank you dlkfjdlkfjdlfkd that helps a bit. But my question is still open.
 
A lot of programmers would be able to explain what the code does, but isn't there a saying going something like this : A single line of code says more than a thousand words .... ;-)

It takes a lot of words to explain these few lines.

Why don't you start to take the code apart yourself ? You can get a lot of help on this site if you present your problem in small pieces.

/JOlesen
 
HEHEHE,
Well I know very little about C so it is kinda wierd for me to do it.
 
Apologies for the bad Cobol 66 - mine is very rusty. The last time I did Cobol was 1976 - even Cobol 68 was advanced. The Cobol equivalents are in the comments. You will need exclusive or and modulus. If you don't have modulus,
Code:
C  x = y % d
Cobol compute x = y - ((y / d) * d)

I am using this in place of the AND (&) function.
C  x = y & 0xFF
Cobol compute x = y - ((y / 256) * 256)



// No idea how you pass parameters into cobol routines
Word wBuildCrc (Byte *pbBuf, unsigned wLen, Word wCrc)
{
  Byte bCh;     // 77 bch pic 999   the range is 0-255
  Word j;       // 77 j   pic 999   the range is whatever length wlen goes to
  char i;       // 77 i   pic 9     just a counter.  int would be more efficient

   // NOTE Switch the two bytes round so hex DEC0 becomes hex C0DE
   // NOTE If there is a modulus function in Cobol it is probably something like
   // compute wcrc = mod(wcrc, 256) * 256 + (wcrc / 256)
   bCh=(Byte)(wCrc & 0x00FF);
   wCrc=(wCrc>>8) + (unsigned short)bCh*0x100;  

    // perform block1 varying j from 0 by 1 until j greater than equal to wlen
   for (j = 0; j < wLen; j ++)
   {
       // BLOCK1
       // move pbbuf(j) to bch
       bCh = pbBuf[j];
       // NOTE Don't know if you have exclusive or in Cobol
       // NOTE ^ is binary exclusive or
       // NOTE << is shift left
       // compute wcrc = wcrc xor (bch * 256)
       wCrc=wCrc ^ ((unsigned short) bCh <<8);
       // perform block2 varying i from 0 by 1 until i greater than equal to 8
       for (i=0; i<8; i++)
       {
           // block2
           // NOTE & is a binary AND
           // if wcrc less than zero
           if (wCrc & 0x8000)
               // compute wcrc = (wcrc * 2) xor 4129
               wCrc = (wCrc << 1) ^ 0x1021;
           // else
           else
               // multiply wcrc by 2
               wCrc = wCrc << 1;
       }
   }

    // NOTE Same as above.  Must be some Big Endian Little Endian code
    bCh=(Byte)(wCrc & 0x00FF);                  
    wCrc=(wCrc>>8) + (unsigned short)bCh*0x100;  /* &quot;                       */
  
  return(wCrc);
  }
 
WOW xwb
That was more than I asked for. I am going to do a CRC calculation with this logic exploded out the C code given above. I really really appreciate the effort you took to translate the C code to COBOL. I will post the COBOL program here if it calculates the correct CRC.
 
Hi,
It all started from here so let me end it here. For the above question xwb gave me and Tom Morrison a logic. Making that logic as a foundation we developed a program that calculates CRC-CCITT. There is a lot of controversy about CRC-CCITT but we achieved what we wanted. My special thanks to xwb.
Here is the program.
************************************************************
identification division.
program-id. crcshift.
data division.
working-storage section.

01 message-buffer.
02 pic x(16) value X&quot;03703030303030303030303030303030&quot;.
02 pic x(16) value X&quot;30303032303030303030303030303030&quot;.
02 pic x(16) value X&quot;30303030303030303030303030303030&quot;.
02 pic x(16) value X&quot;30303030303030303030303030303030&quot;.
02 pic x(16) value X&quot;3030303030303030413130323230324A&quot;.
02 pic x(16) value X&quot;5257454C49525250454E544F4E594331&quot;.
02 pic x(14) value X&quot;3131310000000000000000000000&quot;.

01 another-msg.
02 pic x(9) value &quot;123456789&quot;.
01 msg-length pic 9(9) binary.
01 i pic 9(9) binary.
01 j pic 9(9) binary.
01 k pic 9(9) binary.
01 hex-display pic x(16) value &quot;0123456789ABCDEF&quot;.

01 crc-accum-big pic 9(9) binary.
01 redefines crc-accum-big.
02 crc-top pic 9(4) binary.
02 crcshift-accum pic 9(4) binary.
02 crcshift-accum-group redefines crcshift-accum.
88 crc-accum-high-bit values x&quot;8000&quot; thru x&quot;ffff&quot;.
03 crcshift-octet pic x occurs 2.

01 xorshift-a.
02 xor-a-octet pic x occurs 2.

01 xorshift-b.
02 xor-b-octet pic x occurs 2.
01 xor-ord-a pic 9(4) binary.
01 redefines xor-ord-a.
02 pic x.
02 xor-octet-a pic x.
01 xor-ord-b pic 9(4) binary.
01 redefines xor-ord-b.
02 pic x.
02 xor-octet-b pic x.

01 temp-c pic x.

01 xor-table.
copy &quot;xortable.cpy&quot;.
01 redefines xor-table.
02 occurs 256. 03 xor-result pic x occurs 256.


procedure division.
a.
move X&quot;FFFF&quot; to crcshift-accum-group.
move crcshift-octet (1) to temp-c.
move crcshift-octet (2) to crcshift-octet (1).
move temp-c to crcshift-octet (2).
move length of message-buffer to msg-length.
perform varying i from 1 by 1 until i > msg-length
move crcshift-accum-group to xorshift-a
move message-buffer (i:1) to xor-b-octet (1)
move X&quot;00&quot; to xor-b-octet (2)
perform xor-2-octets
move xorshift-b to crcshift-accum-group

perform varying j from 1 by 1 until j > 8
move 0 to crc-top
add crc-accum-big to crc-accum-big
if crc-top not = 0
move crcshift-accum-group to xorshift-a
move x&quot;1021&quot; to xorshift-b
perform xor-2-octets
move xorshift-b to crcshift-accum-group
end-if
end-perform
end-perform.
move crcshift-octet (1) to temp-c.
move crcshift-octet (2) to crcshift-octet (1).
move temp-c to crcshift-octet (2).
perform display-crcshift.
stop run.

xor-2-octets.
perform varying k from 1 by 1 until k > 2
move 0 to xor-ord-a, xor-ord-b
move xor-a-octet (k) to xor-octet-a
move xor-b-octet (k) to xor-octet-b
add 1 to xor-ord-a
add 1 to xor-ord-b
move xor-result (xor-ord-a, xor-ord-b)
to xor-b-octet (k)
end-perform.

display-crcshift.
display &quot; CRC-shift = &quot;.
perform varying i from 1 by 1 until i > 2
move 0 to xor-ord-a
move crcshift-octet (i) to xor-octet-a
divide 16 into xor-ord-a giving j remainder k
add 1 to j
add 1 to k
display hex-display (j:1) position 0
hex-display (k:1) position 0
end-perform.
************************************************************
If you are interested in knowing more CRC in cobol please brwose the CRC-IN-COBOL thread at COBOL general discussion forum. Tom Morrison had written a CRC-32 program also. For both these programs to work one need couple of huge copy books which of course is available either from me or Tom. Check the thread and you can figure out Tom's e-mail address. My e-mail address is FIRESTARTER@mainframer.net.
Thanks a lot everyone.
 
Very nice !

Don't you Cobol quys retire quite early due to worn out fingers / hands ;-)

/JOlesen
 
Good Remark,
We COBOL programmers have proven to the world that what we make are here to stay a long time back and now the IT world is just living what we made. The only problem is we don't appreciate hype, so the hype makers show off a lot, their products and programs don't work and many lost millions and now it is our job to fix it using the good old cobol. Well as long as it pays we are happy.
hehehe
 
>>their products and programs don't work
That does happen quite often I am afraid.

C Programming still could be an option - even in a mainframe world ?
Still somewhat concerned about your fingers ;-)

/JOlesen
 
Don't you C-programmers ever retire early suffering from curly-bracket-induced-range-confusion??

(a dyed-in-the-wool begin-and-end Pascalian)
Li
 
I think C and all other curly-bracketed disasters were made by some narrow minded computer nerds who don't want the majority of the world to understand what computer programming is.
Then there are those who want the world to understand everything and help the world of computing to be better and better. THEY ARE CALLED &quot;COBOL PROGRAMMERS&quot;.
HEHEHE, Just kidding.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top