Cobol format conversion

[Olivier Wirz]

Hello,

What is the best way to convert a numeric cobol format S9(09)V9(04) in a
more readable way.

For example:

000001000000} will be -1000.0000
000001000000{ will be 1000.0000

It works with substr and =~, but may be there is a module or another better
way.

Thank you.

Olivier

--
+++ GMX - die erste Adresse für Mail, Message, More +++
Neu: Preissenkung für MMS und FreeMMS! [url]http://www.gmx.net[/url]

[Daniel Staal]

--As off Saturday, January 10, 2004 3:40 PM +0100, Olivier Wirz is
alleged to have said:

> Hello,
>
> What is the best way to convert a numeric cobol format S9(09)V9(04)
> in a more readable way.
>
> For example:
>
> 000001000000} will be -1000.0000
> 000001000000{ will be 1000.0000
>
> It works with substr and =~, but may be there is a module or
> another better way.

--As for the rest, it is mine.

Well, it seems the module Convert::IBM390 may be able to do this, but
substr would probably be enough.

Actually, Convert::IBM390 seems to be a little too specific for this:
it would expect the file to be mainframe packed. A more general
COBOL reading module might be nice; it would help people stuck
maintaining that beast work in a language that is actually fun to
work in.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

[R. Joseph Newton]

Olivier Wirz wrote:

> Hello,
>
> What is the best way to convert a numeric cobol format S9(09)V9(04) in a
> more readable way.

How would we know? This is a Perl list. To some people here, the string above
may be meaningful. To most, it is line noise.
Try:

I am working with formats in COBOL. COBOL expreses numerical values in a
format where [fill in some blanks here if you want quality help] I would like
my output to have a more natural form where [fill in some more blanks here]

>
>
> For example:
>
> 000001000000} will be -1000.0000
> 000001000000{ will be 1000.0000

Gazing way deep in my crystal ball, I'm going to intuit that those left and
right braces are a COBOL signed value indicators. The problem is that you
haven't said this.

>
>
> It works with substr and =~, but may be there is a module or another better
> way.

Search CPAN using COBOL as a keyword, maybe. It will do little good to move
code out of COBOL, though, if you carry COBOL thinking with you. Presuming
that you know what the significance of place value operators, etc. are for
COBOL, you could:

Read the COBOL output as strings, interpreting each string to its numerical
value by the sysntactic rules you are familiar with.
Output the numbers in Perl, since Perl's default output format is generally the
natural expression of any numerical value.

Practice thinking in full concepts, expressed in full words. You will get more
long-term mileage out of this step than any code solution could possibly
provide.

Joseph

[John McKown]

FWIW - the best thing, IMO, is to change the generating program's PIC
clause to:

PIC S9(09)V.9(04) SIGN IS LEADING SEPARATE.

This will take up two more characters in the output line. It will insert
an actual decimal point and prefix the number with a + or a - sign. Much
easier to process in a non-COBOL language.

Sorry if this COBOL-talk offends any Perl-ites <grin>.

On Sat, 10 Jan 2004, Olivier Wirz wrote:

> Hello,
>
> What is the best way to convert a numeric cobol format S9(09)V9(04) in a
> more readable way.
>
> For example:
>
> 000001000000} will be -1000.0000
> 000001000000{ will be 1000.0000
>
> It works with substr and =~, but may be there is a module or another better
> way.
>
> Thank you.
>
> Olivier
>
>

--
--
Maranatha!
John McKown

[Daniel Staal]

--As off Saturday, January 10, 2004 11:53 AM -0800, R. Joseph Newton
is alleged to have said:

> Olivier Wirz wrote:
>

>> Hello,
>>
>> What is the best way to convert a numeric cobol format
>> S9(09)V9(04) in a more readable way.

>
> How would we know? This is a Perl list. To some people here, the
> string above may be meaningful. To most, it is line noise.
> Try:

That's a signed number, with 9 digits before the decimal point and 4
after.

>> For example:
>>
>> 000001000000} will be -1000.0000
>> 000001000000{ will be 1000.0000

>
> Gazing way deep in my crystal ball, I'm going to intuit that those
> left and right braces are a COBOL signed value indicators. The
> problem is that you haven't said this.

Close: their the filesystem signed value indicators unpacked numeric
records for COBOL files. Or at least this format of COBOL files.

>> It works with substr and =~, but may be there is a module or
>> another better way.

>
> Search CPAN using COBOL as a keyword, maybe. It will do little
> good to move code out of COBOL, though, if you carry COBOL thinking
> with you. Presuming that you know what the significance of place
> value operators, etc. are for COBOL, you could:
>
> Read the COBOL output as strings, interpreting each string to its
> numerical value by the sysntactic rules you are familiar with.
> Output the numbers in Perl, since Perl's default output format is
> generally the natural expression of any numerical value.

Which is exactly what he is trying to do. In fact, it sounds like he
already has a way to do it. He's just asking if there is a *better*
way.

> Practice thinking in full concepts, expressed in full words. You
> will get more long-term mileage out of this step than any code
> solution could possibly provide.
>
> Joseph

He did. He's asking for semi-high level advice here: what is the
*best* way to do a particular conversion. Anyone who can answer the
question probably has done the conversion themselves, and would
understand the few things he left unexplained. Anyone who couldn't
understand what he left unexplained would have no answer; they've
never done it. He explained enough to be clear, but not enough to be
redundant. (Though I would like to know what system he is getting
the file from, it could be pertinent.)

A search of CPAN for COBOL doesn't turn up anything particularly
promising, but that is occasionally the case. Modules are sometimes
hard to find, and may not be under the obvious-at-the-time keywords.

This is a common question class on this list. I see it often: some
question that the details of make little or no sense to me, but does
to people who know what the poster is talking about. The general
population of the list may or may not be able to answer, but the
poster is looking for those few who *can* answer. They provide
enough for someone who knows the problem space can answer, but don't
bother to define everything because it would bore people, and not get
any better answers.

There are a few of us here who will admit to knowing COBOL. We can
answer the question as asked. For those who don't, Oliver can
probably do as good a job of coding a conversion routine as they can.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------

[Jeff Westman]

John McKown <joarmc@swbell.net> wrote:

> FWIW - the best thing, IMO, is to change the generating program's
> PIC
> clause to:
>
> PIC S9(09)V.9(04) SIGN IS LEADING SEPARATE.
>
> This will take up two more characters in the output line. It will
> insert
> an actual decimal point and prefix the number with a + or a -
> sign. Much
> easier to process in a non-COBOL language.
>
> Sorry if this COBOL-talk offends any Perl-ites <grin>.

Doesn't offend me ... we use COBOL, PERL and Java in our shop.

> On Sat, 10 Jan 2004, Olivier Wirz wrote:
>

> > Hello,
> >
> > What is the best way to convert a numeric cobol format

> S9(09)V9(04) in a more readable way.

> >
> > For example:
> >
> > 000001000000} will be -1000.0000
> > 000001000000{ will be 1000.0000

The problem with the above is that you do not know where the
decimal point is. I'm assuming this is in an ASCII file (hence the
curley braces). Also there is no implication if these are COMP
fields or not. Even so, the code you write will not be completely
portable: A COMP-5 [binary] value with a negative sign will have a
lower case 'p' instead of '}' if using Microfocus COBOL.

I would just build a small conversion routine to parse and
interpret according to how you expect it. For this to be on CPAN
would be too general I think....

> > It works with substr and =~, but may be there is a module or

> another better

> > way.
> >
> > Thank you.
> >
> > Olivier

HTH,

-JW


__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
[url]http://hotjobs.sweepstakes.yahoo.com/signingbonus[/url]

[R. Joseph Newton]

Daniel Staal wrote:

> That's a signed number, with 9 digits before the decimal point and 4
> after.

Thanks. That is useful background. Unfortunately it does not explain
the what was shown in the OP, since there were only twelve digits in the
sample COBOL strings, not the thirteen that would be indicated by a
likely interpretation of the format specifier in the OP, or by your
explanation of the format specs.

>
> ...
> Close: their the filesystem signed value indicators unpacked numeric
> records for COBOL files. Or at least this format of COBOL files.
>
> ...
> Which is exactly what he is trying to do. In fact, it sounds like he
> already has a way to do it. He's just asking if there is a *better*
> way.
>

> > Practice thinking in full concepts, expressed in full words. You
> > will get more long-term mileage out of this step than any code
> > solution could possibly provide.
> >
> > Joseph

>
> He did. He's asking for semi-high level advice here: what is the
> *best* way to do a particular conversion. Anyone who can answer the
> question probably has done the conversion themselves,

Not true. Those are strings. Strings, with a clear explanation of their
formatting rules, are emminently amenable to simple logic without
recourse to any particular esoteric body of knowledge.

> and would
> understand the few things he left unexplained. Anyone who couldn't
> understand what he left unexplained would have no answer; they've
> never done it.

I am sorry to hear about this gap in your capacities. Please, though, do
not project it on others. You are vastly overrating the value of
particular jargons, while failing to understand the capacity of the human
mind to translate basic logical constructs between expression patterns.

> He explained enough to be clear, but not enough to be
> redundant. (Though I would like to know what system he is getting
> the file from, it could be pertinent.)

The OP is fortunate here. Jeff Westman seems to be familiar with the
subject matter, and he provides some advice that sounds pretty useful.

>
>
> A search of CPAN for COBOL doesn't turn up anything particularly
> promising, but that is occasionally the case. Modules are sometimes
> hard to find, and may not be under the obvious-at-the-time keywords.
>
> This is a common question class on this list. I see it often: some
> question that the details of make little or no sense to me, but does
> to people who know what the poster is talking about. The general
> population of the list may or may not be able to answer, but the
> poster is looking for those few who *can* answer. They provide
> enough for someone who knows the problem space can answer, but don't
> bother to define everything because it would bore people, and not get
> any better answers.

Wrong again. For one thing, by the time the OP has taken the effort to
articulate the problem in a manner that does not rely on esoteric
knowledge, the solution, particularly in the case of format conversions,
will probably reveal itself in the process of articulation. If not, it
will provide background to open the question to a broad array of
brilliant minds, many of them unhampered by the compulsions towards turf
protection..

> There are a few of us here who will admit to knowing COBOL. We can
> answer the question as asked. For those who don't, Oliver can
> probably do as good a job of coding a conversion routine as they can.
>
> Daniel T. Staal

So where is your answer? I see a maybe reference to one module that
presumably handles many tasks in this particular conversion interface.
What if this module doesn't answer the need? Should the OP) just shrug
his shoulders then, and walk away with the certainty that if it hasn't
been done, it can't? I would suggest that an exercise in accessible
communication open up many promising avenues for him.

Joseph

[Unregistered]

I have written this routine several times myself. COBOL to Perl data conversion is a tricky business. Lately I have adopted a method of using Sort and FileAid on the mainframe to convert/restructure the data into more Perl-friendly constructs (XML, for instance). It's just easier in the long run and I end up transferring smaller files of just the data I want.

The data layout here is called ZONED DECIMAL. The last character is a combination of the sign and the last digit. Trouble is, it needs to be in EBCDIC to make any real sense. Conversion to ASCII makes the conversion far more difficult.

The last byte is divided into 2 nibbles, the first being the sign and the last being the digit. The sign nibble is a C, D, or F. F means unsigned (assumed positive), C means signed positive, and D means signed negative. So, a '}' in EBCDIC is a x'D0' which means the last digit is 0 and the number is negative. '{' in EBCDIC is x'C0' or a positive 0. Not-so-coincidentally, an unsigned number (remove the 'S' from the PIC clause) would have an 'F0' in the final byte, which is an EBCDIC '0'.

I am fairly certain the Convert::IBM390 could handle this, but it may need to be converted to EBCDIC first.

As for the number of decimals, well, that's implied in the layout, or the COBOL PIC clause. Since the V is an implied decimal position, the data won't reflect the decimal, only the digits. Remember, COBOL came into being at a time where every byte was expensive and had to be saved if possible.

I have routines to convert COBOL copybooks to Perl structures, convert COBOL data to Perl data, and even tie a hash via a copybook to a string scalar. If anyone's interested, contact me at MSwanberg - at - mikeswanberg - dot - com and I'll be happy to share.

Note, my routines aren't perfect, but they cover the 99% most-used COBOL data cases (packed, zoned, group, string, comp/binary). It even does a decent job with OCCURS clauses, even nested ones.

Thanks,
-Mike