Convert text to Hex

[zvika]

How can I want to convert this text:

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

To:

01 SYSOT VALUE X'001800010001C1' PIC X(07).
(This is the eqvivalent hex values.)

 

[Stephane CHAZELAS]

2004-12-9, 05:06(-08), zvika:

How can I want to convert this text:

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

To:

01 SYSOT VALUE X'001800010001C1' PIC X(07).
(This is the eqvivalent hex values.)

[...]

s/VALUE '(.*?)'/"VALUE '" . unpack("H*", $1) . "'"/e;

 

[Craig Dunn]

How can I want to convert this text:

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

To:

01 SYSOT VALUE X'001800010001C1' PIC X(07).
(This is the eqvivalent hex values.)

The binary part of your string can be decoded easily with:

$hex = unpack "H*, $bin;

 

[James Willmore]

How can I want to convert this text:

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

To:

01 SYSOT VALUE X'001800010001C1' PIC X(07).
(This is the eqvivalent hex values.)

I can get you part way there. This will take into account that you are
trying to convert from one COBOL representation into another (because most
of the responses you have gotten are dealing with the whole value versus
the 7 values you want - as depicted by the PICTURE). Sadly, I don't get
the values you described from within the script. Maybe someone can point
out what's wrong.

HTH

Jim

#!/usr/bin/perl

use strict;
use warnings;

my $string = <<EOL;
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).
EOL

#remove single quotes
$string =~ s/\'//g;

#break $string into it's white space deliminated parts
my @parts = split /\s+/, $string;

#the PIC values; '^char' with '\cchar '
$parts[3] =~ s/\^(.{1})/\\c$1 /g;

#spilt the PIC value into component parts
my @pic_value = split /\s+/, $parts[3];

#reconstruct the PIC value with appropriate substitution
my $new_pic_value = "VALUE X'";
foreach my $current(@pic_value) {
print "($current)\n";
#I'm not sure how to convert something like ^@ into hex :-(
$new_pic_value .= sprintf "%X", ord($current);
}
$new_pic_value .= "'";

#replace old PIC value with new PIC value
$parts[3] = $new_pic_value;

print "new pic value: ",join("", $new_pic_value),"\n";
print join(" ", @parts),"\n";

 

[James Willmore]

On Thu, 09 Dec 2004 11:11:18 -0500, James Willmore wrote:

print "new pic value: ",join("", $new_pic_value),"\n";

This line should be ...
print "new pic value: $new_pic_value\n";

Opps!

 

[Stephane CHAZELAS]

2004-12-09, 11:11(-05), James Willmore:
[...]

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

[...]
#I'm not sure how to convert something like ^@ into hex :-(

[...]

^@, ^A, ... ^_, ^? is one usual representation of characters
\0..\037,\0177.

^<n> being actually ord(<n>) & ~64. ^X would then be the
character \030.

Hence the:

s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e

I was suggesting.

 

[James Willmore]

2004-12-09, 11:11(-05), James Willmore:
[...]

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

[...]
#I'm not sure how to convert something like ^@ into hex :-(

[...]

^@, ^A, ... ^_, ^? is one usual representation of characters
\0..\037,\0177.

^<n> being actually ord(<n>) & ~64. ^X would then be the
character \030.

Hence the:

s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e

I was suggesting.

And ... when the following is run ...

#!/usr/bin/perl

use strict;
use warnings;

my $string = <<EOL;
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).
EOL

$string =~ s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e;
print "$string\n";

.... produces ...

[jim@localhost clpm]$ perl hex.pl
01 SYSOT VALUE X'5e405e585e405e415e405e4141' PIC X(07).

[jim@localhost clpm]$

.... which isn't what the OP wanted

To complicate things, he appears to be using EBCDIC, not ASCII values as
the final result. '41' is 'A' in ASCII, but in EBCDIC it's represented by
'C1'. And, in your solution, you don't appear to take into account that
'^' is a control character (much like the infamous '^M' you get when
getting a DOS file and placing it in binary format on a Unix box).

Close ... but no cigar

Jim

 

[Stephane CHAZELAS]

2004-12-09, 12:16(-05), James Willmore:
[...]

01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).

[...]
^<n> being actually ord(<n>) & ~64. ^X would then be the
character \030.

Hence the:

s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e

I was suggesting.

And ... when the following is run ... [...]
my $string = <<EOL;
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07).
EOL

$string =~ s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e;
print "$string\n";

... produces ...

[jim@localhost clpm]$ perl hex.pl
01 SYSOT VALUE X'5e405e585e405e415e405e4141' PIC X(07).

I actually meant that "^@^X^@^A^@^AA" was actually the character
0x00 followed by the character 0x18... Such characters can't be
included in newsgroup messages, neither can't they generally be
seen, hence the need of a representations such as ^@, ^X.

[...]

... which isn't what the OP wanted

To complicate things, he appears to be using EBCDIC, not ASCII values as
the final result. '41' is 'A' in ASCII, but in EBCDIC it's represented by
'C1'. And, in your solution, you don't appear to take into account that
'^' is a control character (much like the infamous '^M' you get when
getting a DOS file and placing it in binary format on a Unix box).

[...]

I took it into account, that's what I explained. ^X (aka Ctrl-X)
is the character 0x18. I assumed the ^X in OP's message was
actually the representation of the 0x18 character.

You're right however about the EBCDIC issue.

However if his system charset is EBCDIC (which the fact that he
said that the result should be the hex representation suggests),
my code would still work (pack("H*", "A") would return "C1").

$ cat -vt input-file
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07)
$ od -tc input-file
0000000 0 1 S Y S O T V A L
0000020 U E ' \0 030 \0 001 \0 001 A '
0000040 P I C X ( 0 7 ) \n
0000057
$ cat perl-script
s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e
~$ perl -p perl-script input-file
01 SYSOT VALUE X'00180001000141' PIC X(07)

 

[Jim]

Stephane CHAZELAS wrote:

I actually meant that "^@^X^@^A^@^AA" was actually the character
0x00 followed by the character 0x18... Such characters can't be
included in newsgroup messages, neither can't they generally be
seen, hence the need of a representations such as ^@, ^X.

But they can if they are part of the actual code - which is what the OP
posted ... not a representation of what he wanted, but the actual code
AFAIK. If the OP says I'm wrong, so be it.

[...]

... which isn't what the OP wanted

To complicate things, he appears to be using EBCDIC, not ASCII values as
the final result. '41' is 'A' in ASCII, but in EBCDIC it's represented by
'C1'. And, in your solution, you don't appear to take into account that
'^' is a control character (much like the infamous '^M' you get when
getting a DOS file and placing it in binary format on a Unix box).

[...]

I took it into account, that's what I explained. ^X (aka Ctrl-X)
is the character 0x18. I assumed the ^X in OP's message was
actually the representation of the 0x18 character.

The OP was very clear about what he wanted to see.

You're right however about the EBCDIC issue.

The OP, however, was not clear about this.

However if his system charset is EBCDIC (which the fact that he
said that the result should be the hex representation suggests),
my code would still work (pack("H*", "A") would return "C1").

$ cat -vt input-file
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07)
$ od -tc input-file
0000000 0 1 S Y S O T V A L
0000020 U E ' \0 030 \0 001 \0 001 A '
0000040 P I C X ( 0 7 ) \n
0000057
$ cat perl-script
s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e
~$ perl -p perl-script input-file
01 SYSOT VALUE X'00180001000141' PIC X(07)

What OS are you running? Because I did the following and got different
results. The OS I'm running is Linux (Fedora Core 2 and Red Hat 8.0 -
not sure about the kernel version on the Fedora box, but it's using
5.8.3 Perl - since I'm at work right now, but the Red Hat box is
running a 2.4.18 kernel and 5.8.0 Perl).

This is what I got duplicating your commands and files ...
[jim@oplinux tmp]$ cat -vt input-file
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07)
[jim@oplinux tmp]$ od -tc input-file
0000000 0 1 S Y S O T V A L
0000020 U E ' ^ @ ^ X ^ @ ^ A ^ @ ^ A
0000040 A ' P I C X
0000060 ( 0 7 ) \n
0000065
[jim@oplinux tmp]$ cat perl-script
s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e
[jim@oplinux tmp]$ perl -p perl-script input-file
01 SYSOT VALUE X'5e405e585e405e415e405e4141' PIC X(07)
[jim@oplinux tmp]$

This is starting to bug me that I got different results and executed
the *same* commands. I realize that the various characters, when
*printed* will vary, but the OP provided *code* that *should* print.
And the commands you execute *should* yield the *same* results ... and
it's not.

So ... what am I doing differently from you that produces different
results? I'm sure the OP might be interested as well ... if he's still
with us and following along and is getting what I'm getting.

Jim

 

[Stephane CHAZELAS]

2004-12-9, 15:12(-08), Jim:

Stephane CHAZELAS wrote:


But they can if they are part of the actual code - which is what the OP
posted ... not a representation of what he wanted, but the actual code
AFAIK. If the OP says I'm wrong, so be it.

[...]

Yes, it may, except that he said 0x18 was the "corresponding
hexadecimal code" of ^X, hence my assumption.

The corresponding code of ^X (the two characters ^ and X) would
be 5E58 (ASCII) or 5FE7 (EBCDIC).

When someone talks about ^M is a usenet message, I generally
assume he is speaking of the CR character, not the two
characters ^ and M.

Now, I may be wrong about the actual content of OP's input. We'd
need him to clarify it.

[...]

$ cat -vt input-file
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07)
$ od -tc input-file
0000000 0 1 S Y S O T V A L
0000020 U E ' \0 030 \0 001 \0 001 A '
0000040 P I C X ( 0 7 ) \n
0000057
$ cat perl-script
s/VALUE '(.*?)'/"VALUE X'" . unpack("H*", $1) . "'"/e
~$ perl -p perl-script input-file
01 SYSOT VALUE X'00180001000141' PIC X(07)

[...]
What OS are you running? Because I did the following and got different
results. The OS I'm running is Linux (Fedora Core 2 and Red Hat 8.0 -
not sure about the kernel version on the Fedora box, but it's using
5.8.3 Perl - since I'm at work right now, but the Red Hat box is
running a 2.4.18 kernel and 5.8.0 Perl).

This is what I got duplicating your commands and files ...
[jim@oplinux tmp]$ cat -vt input-file
01 SYSOT VALUE '^@^X^@^A^@^AA' PIC X(07)
[jim@oplinux tmp]$ od -tc input-file
0000000 0 1 S Y S O T V A L
0000020 U E ' ^ @ ^ X ^ @ ^ A ^ @ ^ A
0000040 A ' P I C X
0000060 ( 0 7 ) \n
0000065

You didn't have the same file as mine, as od suggests.

My file, I repeat is what I suspected the OP's one to be:

VALUE '^@...

Where ^@ is the ^@ character whose byte value is 0, not the two
characters ^ and @ as in your file.

cat -vt

represents the invisible characters (such as <NUL> or <TAB> or
<CTRL-X>) in the ^X notation. Of course for visible characters
such as ^ and @, it represents them as-is, that's why we get the
same output for cat -vt.

[...]

This is starting to bug me that I got different results and executed
the *same* commands.

different results because different inputs.

 

[James Willmore]

On Fri, 10 Dec 2004 09:01:13 +0000, Stephane CHAZELAS wrote:

Yes, it may, except that he said 0x18 was the "corresponding
hexadecimal code" of ^X, hence my assumption.

The corresponding code of ^X (the two characters ^ and X) would
be 5E58 (ASCII) or 5FE7 (EBCDIC).

When someone talks about ^M is a usenet message, I generally
assume he is speaking of the CR character, not the two
characters ^ and M.

Now, I may be wrong about the actual content of OP's input. We'd
need him to clarify it.

Agreed.

You didn't have the same file as mine, as od suggests.

My file, I repeat is what I suspected the OP's one to be:

VALUE '^@...

Where ^@ is the ^@ character whose byte value is 0, not the two
characters ^ and @ as in your file.

cat -vt

represents the invisible characters (such as <NUL> or <TAB> or
<CTRL-X>) in the ^X notation. Of course for visible characters
such as ^ and @, it represents them as-is, that's why we get the
same output for cat -vt.

[...]

This is starting to bug me that I got different results and executed
the *same* commands.

different results because different inputs.

I understand now. Thanks for the clarification.

It's rather ironic that, when done at the command line, a single character
can be converted without issue. When done in a loop, the results are
different. This is where, for me, the disconnect started. I did the
following and got the following results:

[jim@localhost jim]$ perl -e 'printf "%x\n", ord("A");'
41
[jim@localhost jim]$ perl -e 'printf "%x\n", ord("\c@");'
0
[jim@localhost jim]$

The "\c" is representative of the control character in Perl. As you can
see, the results are (AFAIK) what is expected (in ASCII, not EBIDIC).
When I tried this same concept in a loop, the results were as I posted
before. Different variations yielded various warnings and syntax errors.
It was rather frustrating.

I hope I didn't come off as being difficult and have shown why I was
saying what I was saying and showed, maybe, where my head was at during
this discussion.

Jim

 

[zvika]

thanks a lot. It works perfect

 

[zvika]

thanks a lot. It works perfect.