>Do you know of any software/utility apart from Selcopy that can convert an
>EBCDIC file with packed fields to ASCII on a unix machine? DD can do the
>character set conversion but cannot unpack the fields. I need a utility
>that does both.
specific utility to do EBCDIC->ASCII conversion of selected fields and
Packed decimal->numeric. You'ld have to tell the utility where each
decimal field begins and how long it is.
You could do this with Perl. Use the unpack function to extract each
decimal field into an array of byte values using 'C' (unsigned char
value) then write a little loop to convert the list to a representation
of your choosing.
while(<STDIN>) {# Read in and convert STDIN
print &e2a($fields[0]),&p2a($fields[1]),$fields[2],"\n";
}
sub e2a {shift}# EBCDIC->ASCII left as an exercise
sub p2a {
local $_= shift;
my $r='';
$_= chop $r;
((/^[cf]/)?'+':'-').$r;
}
Note that the above hasn't been tested, also, it's been a long time
since I've played with 370 assembly and I can't remember if there are
other positive sign patterns than X'C' and X'F'. Adjust the final
regular expression as appropriate. Given input of X'01234D', the
function p2a should return the string '-01234'. You will also probably
want to add a diagnostic if the regular expression to decompose your
input records fails.
If the input file records are fixed length (not new line terminated),
you'll have to replace the while(<STDIN>) with calls to sysread,
however, that only complicates things a little.
You could without too much effort turn the above into a general utility
to decompose input based on command line arguments which describe the
layout of the input records.
extract CL3 PL5 C <input.file >output.file
expression to parse the input record and build an array of the
appropriate conversion routine to call for each field.
If I had to write the e2a function, I'd probably use dd to get a
translation of X'00'-X'FF' then use the result as the second argument of
the Perl tr function. I'd run the dd in a pipe during the script
initialization so that e2a would be reasonably efficient.
--