Professional Web Applications Themes

Cobol format conversion - PERL Beginners

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]...

  1. #1

    Default Cobol format conversion

    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]


    Olivier Wirz Guest

  2. #2

    Default Re: Cobol format conversion

    --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.
    ---------------------------------------------------------------
    Daniel Staal Guest

  3. #3

    Default Re: Cobol format conversion

    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



    R. Joseph Newton Guest

  4. #4

    Default Re: Cobol format conversion

    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

    John McKown Guest

  5. #5

    Default Re: Cobol format conversion

    --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.
    ---------------------------------------------------------------
    Daniel Staal Guest

  6. #6

    Default Re: Cobol format conversion

    John McKown <joarmcswbell.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 p 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./signingbonus[/url]
    Jeff Westman Guest

  7. #7

    Default Re: Cobol format conversion

    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

    R. Joseph Newton Guest

  8. #8

    Default Cobol format conversion

    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
    Unregistered Guest

Similar Threads

  1. 3D annotations and File format Conversion
    By DeveloperGuy@adobeforums.com in forum Adobe Acrobat SDK
    Replies: 10
    Last Post: March 13th, 03:34 PM
  2. mp3 -> streaming format conversion on the fly
    By carrrramba in forum Macromedia Flash Flashcom
    Replies: 1
    Last Post: October 6th, 05:33 PM
  3. Video Format Conversion
    By Bart A in forum Macromedia Flash Flashcom
    Replies: 0
    Last Post: May 11th, 03:02 PM
  4. time format conversion
    By point in forum PHP Development
    Replies: 19
    Last Post: December 11th, 05:35 AM
  5. VAX floating point format conversion
    By Dale Pennington in forum AIX
    Replies: 0
    Last Post: July 3rd, 06:07 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139