[hercules-390] CRC32 CKSM instruction

[João Reginato [e-mail] [hercules-390]]

Hi



I’m using Hercules 3.12 on Linux and trying to use the CKSM asm instruction
to get the CRC32 result.



As per IBM DB2 APAR

http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633



After this apar,

SELECT HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))

FROM SYSIBM.SYSDUMMYU;

The result returned should be: xB4B86309



My pgm below:

SR R1,R1

LA R14,KEY

LA R15,L'KEY

CKSM R1,R14

BNZ *-4

S0C1 DC H'0'

KEY DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'



After running it shows R1 = x’CCDA0605’ as the result and not xB4B86309 as
expected.

I wonder if it could be any Hercules issue.

Any tips welcome

TIA

João

[[e-mail] [hercules-390]]

The data representation of table SYSDUMMYU is Unicode so in the example cited
HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))


would compute CRC32 on the Unicode prepresentation. Your Assembler program with compute CRC32 on the EBCDIC representation and will give a different result.



IIRC, the Unicode representation of English alphabetic characters is the same as the ASCII representation. If you replace C'ABCDEFGHIJKLMNOPQRZTUVWXYZ' with X'...' where ... is the hex representation of each letter I would think you would get the same result as the DB2 APAR.


Jim
---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi

I’m using Hercules 3.12 on Linux and trying to use the CKSM asm instruction to get the CRC32 result.

As per IBM DB2 APAR
http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633 http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633

After this apar,
SELECT HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))
FROM SYSIBM.SYSDUMMYU;
The result returned should be: xB4B86309

My pgm below:
SR R1,R1
LA R14,KEY
LA R15,L'KEY
CKSM R1,R14
BNZ *-4
S0C1 DC H'0'
KEY DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'

After running it shows R1 = x’CCDA0605’ as the result and not xB4B86309 as expected.
I wonder if it could be any Hercules issue.
Any tips welcome
TIA
João








---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi

I’m using Hercules 3.12 on Linux and trying to use the CKSM asm instruction to get the CRC32 result.

As per IBM DB2 APAR
http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633 http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633

After this apar,
SELECT HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))
FROM SYSIBM.SYSDUMMYU;
The result returned should be: xB4B86309

My pgm below:
SR R1,R1
LA R14,KEY
LA R15,L'KEY
CKSM R1,R14
BNZ *-4
S0C1 DC H'0'
KEY DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'

After running it shows R1 = x’CCDA0605’ as the result and not xB4B86309 as expected.
I wonder if it could be any Hercules issue.
Any tips welcome
TIA
João

[[e-mail] [hercules-390]]

Or, you could do your select from SYSDUMMYE (I think that is the name of the DUMMY table defined as EBCDIC - it may be SYSDUMMY).


Jim

[João Reginato [e-mail] [hercules-390]]

Yep, I’ve noted it yet (ascii x ebcdic).

Now In ascii



L R1,=X'FFFFFFFF'

LA R4,KEY

LA R5,L'KEY

CKSM R1,R4

BNZ *-4

DC 2H'0'

DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'

KEY DC X'4142434445464748494A4B4C4D4E4F5051525A5455565758595A'



The result is x’1D23D6D6’. The same as the “before” APAR said.

Note that I’m not using DB2 neither have the sysdummy tables.

I’m just trying to use CRC-32 in batch ASM but cannot achieve the same DB2 result.

Maybe DB2 uses another implementation instead of the CKSM instruction??

Should it be the same result?





De: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Enviada em: quinta-feira, 4 de outubro de 2018 19:38
Para: hercules-***@yahoogroups.com
Assunto: [hercules-390] Re: CRC32 CKSM instruction





The data representation of table SYSDUMMYU is Unicode so in the example cited

HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))



would compute CRC32 on the Unicode prepresentation. Your Assembler program with compute CRC32 on the EBCDIC representation and will give a different result.



IIRC, the Unicode representation of English alphabetic characters is the same as the ASCII representation. If you replace C'ABCDEFGHIJKLMNOPQRZTUVWXYZ' with X'...' where ... is the hex representation of each letter I would think you would get the same result as the DB2 APAR.



Jim

---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

Hi



I’m using Hercules 3.12 on Linux and trying to use the CKSM asm instruction to get the CRC32 result.



As per IBM DB2 APAR

http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633



After this apar,

SELECT HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))

FROM SYSIBM.SYSDUMMYU;

The result returned should be: xB4B86309



My pgm below:

SR R1,R1

LA R14,KEY

LA R15,L'KEY

CKSM R1,R14

BNZ *-4

S0C1 DC H'0'

KEY DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'



After running it shows R1 = x’CCDA0605’ as the result and not xB4B86309 as expected.

I wonder if it could be any Hercules issue.

Any tips welcome

TIA

João









---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

Hi



I’m using Hercules 3.12 on Linux and trying to use the CKSM asm instruction to get the CRC32 result.



As per IBM DB2 APAR

http://www-01.ibm.com/support/docview.wss?uid=swg1PI77633



After this apar,

SELECT HEX(HASH_CRC32('ABCDEFGHIJKLMNOPQRZTUVWXYZ'))

FROM SYSIBM.SYSDUMMYU;

The result returned should be: xB4B86309



My pgm below:

SR R1,R1

LA R14,KEY

LA R15,L'KEY

CKSM R1,R14

BNZ *-4

S0C1 DC H'0'

KEY DC C'ABCDEFGHIJKLMNOPQRZTUVWXYZ'



After running it shows R1 = x’CCDA0605’ as the result and not xB4B86309 as expected.

I wonder if it could be any Hercules issue.

Any tips welcome

TIA

João

[[e-mail] [hercules-390]]

Ah - some developer must have also made the assumption that the CKSM instruction implemented CRC-32 and the APAR changed to using a real CRC-32 algorithm. My brief googling did not turn up any mainframe routine available for use - if you really want to do CRC-32, you have a bit of studying to do. Perhaps you will find a routine you can use or you will be doing some programming.


Jim

[[e-mail] [hercules-390]]

I have written a public domain CRC32 routine
available here:

https://sourceforge.net/projects/pdos/files/pdcrc/

I don't know any reason why it wouldn't
work on the mainframe. I don't understand
the issue.

BFN. Paul.



---In hercules-***@yahoogroups.com, <***@...> wrote :

Ah - some developer must have also made the assumption that the CKSM instruction implemented CRC-32 and the APAR changed to using a real CRC-32 algorithm. My brief googling did not turn up any mainframe routine available for use - if you really want to do CRC-32, you have a bit of studying to do. Perhaps you will find a routine you can use or you will be doing some programming.


Jim

[João Reginato [e-mail] [hercules-390]]

Cbt493 has it and works fine.

I wonder why CKSM shows another result





De: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Enviada em: sexta-feira, 5 de outubro de 2018 21:12
Para: hercules-***@yahoogroups.com
Assunto: Re: RES: [hercules-390] Re: CRC32 CKSM instruction





I have written a public domain CRC32 routine
available here:

https://sourceforge.net/projects/pdos/files/pdcrc/

I don't know any reason why it wouldn't
work on the mainframe. I don't understand
the issue.

BFN. Paul.

---In hercules-***@yahoogroups.com <mailto:hercules-***@yahoogroups.com> , <***@... <mailto:***@...> > wrote :

Ah - some developer must have also made the assumption that the CKSM instruction implemented CRC-32 and the APAR changed to using a real CRC-32 algorithm. My brief googling did not turn up any mainframe routine available for use - if you really want to do CRC-32, you have a bit of studying to do. Perhaps you will find a routine you can use or you will be doing some programming.


Jim

[Martin Truebner [e-mail] [hercules-390]]

After each addition of an element, a

carry out of bit position 32 of the first operand is
added to bit position 63 of the first operand.

If the CBT493 implements it without consideration of the overflow
(carry out) - then this is what causes it.

If the above is the case, then I am pretty sure that the
"book of books" will at some point in the future document (and of
course some boxes will have it implemented) a new instruction or a CKSM
with the option to change the handling of overflow. It does have 8 spare
bits which could be used for that purpose (see TROO,TROT,TRTT,TRTO
family).

Martin TrÃŒbner; everything around "PoOps of z/arch"

[João Reginato [e-mail] [hercules-390]]

Very didactic

Thank you





De: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Enviada em: terça-feira, 9 de outubro de 2018 04:03
Para: hercules-***@yahoogroups.com
Assunto: Re: [hercules-390] Re: CRC32 CKSM instruction

After each addition of an element, a

carry out of bit position 32 of the first operand is
added to bit position 63 of the first operand.

If the CBT493 implements it without consideration of the overflow
(carry out) - then this is what causes it.

If the above is the case, then I am pretty sure that the
"book of books" will at some point in the future document (and of
course some boxes will have it implemented) a new instruction or a CKSM
with the option to change the handling of overflow. It does have 8 spare
bits which could be used for that purpose (see TROO,TROT,TRTT,TRTO
family).

Martin TrÃŒbner; everything around "PoOps of z/arch"