COBOL tool

On Sat, 30 Aug 2008 11:09:53 -0500, "HeyBub" <heybub@NOSPAMgmail.com>
wrote:

>Pete Dashwood wrote:
>> I need a tool that can analyse the source of a COBOL record layout and
>> calculate the offset and length (true length occupied in bytes, not
>> the virtual length implied in the picture... for example, "pic
>> s9(7)v99 comp-3" has a virtual length of 9 digits but occupies 5
>> actual bytes), for each field defined in the definition, including
>> group fields and REDEFINEd and OCCURring fields.
>>
>> If anyone has code that does this and is prepared to share it, mail
>> it to me. I'll wrap it for windows with a GUI front end and put it on
>> a server for freeware download so that everyone can use it. The idea
>> is that you could select with the mouse all or part of a COBOL record
>> layout viewed in your Editor of choice, and have a popup window that
>> would give you the offset and length of each selected field and the
>> total length overall. (It may be a requirement that selection starts
>> from the 01 level, or not, depends on how your code works...)
>>
>> So the code should be able to accept or read COBOL Data Division
>> source as input, and output a simple text list with an entry for each
>> dataname showing the offset and length of it. (The offset represents
>> the total bytes preceding the field, so the total length of a record
>> definition is easily obtained, and saves all that very tedious
>> counting or searching for the compiler output.)
>>
>> I already have some COBOL code that parses COBOL source and analyses
>> pictures. I can amend it to do this as well, but it is tricky and
>> would not be publicly available.
>>
>> Please express interest here if you think you want to have a go at
>> this.
>> If no-one is up for it, I'll write it myself in C#, when I get time.
>> :-)
>
>Is COBFD what you want?
>
>See COBFD.ZIP on the Flexus download page:
>http://www.flexus.com/download.html
>
I looked at this COBFD 3/5 years ago. Seemed very good but would only
handle 15 digit numbers (older Cobol spec I think). Talked to the
author about fixing it, said he was busy putting bread on the table -
fair enough. So I wrote MYCOBFD, thought it would be a snap - it's
not finished, not working, not easy, not fun anymore, so would really
have appreciated COBFD.

Anyway I stuffed dozens of copybooks through COBFD. CAVEAT: for my
needs at the time I accepted the output, did not minutely check. So
today, I would be interested to know how it fares with the big
numbers, 'n' levels of OCCURS, ad infinitum REDEFINES, POINTER
PROCEDURE's, other goodies.

But not that difficult to prove its accuracy - a REXX to compare
COBFD's output against a compile output would tell the story - author
likely did that anyway.

If I remember rightly it needed an 01 level for starters (else would
create one) which suggests it might not work for copybooks with more
than one 01 (I must have worked around this). Can't really remember.

Think it was Michael Matthias - spare me if I'm wrong.

AS for anything else out there years ago - when I looked COBFD was
basically it.
** Posted from http://www.teranews.com **

On Sun, 31 Aug 2008 00:12:36 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>"Robert" <no@e.mail> wrote in message
>news:umnhb490a0jpnau4rjd4qu1l4g8pl250c7@4ax.com.. .

>>
>>>On Aug 30, 12:07 pm, "Pete Dashwood"
>>><dashw...@removethis.enternet.co.nz> wrote:
>>>> I need a tool that can analyse the source of a COBOL record layout and
>>>> calculate the offset and length (true length occupied in bytes, not the
>>>> virtual length implied in the picture... for example, "pic s9(7)v99
>>>> comp-3"
>>>> has a virtual length of 9 digits but occupies 5 actual bytes), for each
>>>> field defined in the definition, including group fields and REDEFINEd
>>>> and
>>>> OCCURring fields.
>>
>> A few years ago I posted a program -- cob2csv -- which did that so it
>> could convert any
>> 'Cobol file' to a csv. Here is a stripped down version showing only the
>> parsing.

>If you can amend it to support REDEFINES and group levels, say up to 6
>levels should be fine...(my own code uses a pushed and popped stack of
>levels with total lengths and offsets),

That will require two additional passes through the structure -- one to look backward for
redefines and one to look forward from group names. I will work on it. I'll have to use
Fujitsu because I forgot to bring the server access device (DigiPass) home this weekend.

>I will wrap it as a a COM server (so
>it can run anywhere) and put a .NET GUI around it. We need to have an
>offset and length for every dataname in the copybook, including fillers...
>The end result would be a COBOL component (with attribution to you) running
>in a C# framework, with all source and executable publicly available. I'll
>organise the "translation" and passing of text selected by the mouse, to
>your code so it appears as if it were a copybook, and the output can be a
>.txt file or display on screen, selectable by the user.

I'll prettify the code. The picture parser could have been written better.

"Robert" <no@e.mail> wrote in message
news:a3vib4t5j6ppa20sg69eg8hrb81g0d164r@4ax.com...
> On Sun, 31 Aug 2008 00:12:36 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>>"Robert" <no@e.mail> wrote in message
>>news:umnhb490a0jpnau4rjd4qu1l4g8pl250c7@4ax.com. ..
>
>>>
>>>>On Aug 30, 12:07 pm, "Pete Dashwood"
>>>><dashw...@removethis.enternet.co.nz> wrote:
>>>>> I need a tool that can analyse the source of a COBOL record layout and
>>>>> calculate the offset and length (true length occupied in bytes, not
>>>>> the
>>>>> virtual length implied in the picture... for example, "pic s9(7)v99
>>>>> comp-3"
>>>>> has a virtual length of 9 digits but occupies 5 actual bytes), for
>>>>> each
>>>>> field defined in the definition, including group fields and REDEFINEd
>>>>> and
>>>>> OCCURring fields.
>>>
>>> A few years ago I posted a program -- cob2csv -- which did that so it
>>> could convert any
>>> 'Cobol file' to a csv. Here is a stripped down version showing only the
>>> parsing.
>
>>If you can amend it to support REDEFINES and group levels, say up to 6
>>levels should be fine...(my own code uses a pushed and popped stack of
>>levels with total lengths and offsets),
>
> That will require two additional passes through the structure -- one to
> look backward for
> redefines and one to look forward from group names. I will work on it.
> I'll have to use
> Fujitsu because I forgot to bring the server access device (DigiPass) home
> this weekend.
>
>>I will wrap it as a a COM server (so
>>it can run anywhere) and put a .NET GUI around it. We need to have an
>>offset and length for every dataname in the copybook, including fillers...
>>The end result would be a COBOL component (with attribution to you)
>>running
>>in a C# framework, with all source and executable publicly available. I'll
>>organise the "translation" and passing of text selected by the mouse, to
>>your code so it appears as if it were a copybook, and the output can be a
>>.txt file or display on screen, selectable by the user.
>
> I'll prettify the code. The picture parser could have been written better.
>

Excellent! Send it to me when you're happy with it or post it here if you
don't want to use private mail.

Pete.
--
"I used to write COBOL...now I can do anything."
>

--
"I used to write COBOL...now I can do anything."
"HeyBub" <heybub@NOSPAMgmail.com> wrote in message
news:MJKdnWHjZaBO7STVnZ2dnUVZ_uGdnZ2d@earthlink.co m...
> Pete Dashwood wrote:
>> I need a tool that can analyse the source of a COBOL record layout and
>> calculate the offset and length (true length occupied in bytes, not
>> the virtual length implied in the picture... for example, "pic
>> s9(7)v99 comp-3" has a virtual length of 9 digits but occupies 5
>> actual bytes), for each field defined in the definition, including
>> group fields and REDEFINEd and OCCURring fields.
>>
>> If anyone has code that does this and is prepared to share it, mail
>> it to me. I'll wrap it for windows with a GUI front end and put it on
>> a server for freeware download so that everyone can use it. The idea
>> is that you could select with the mouse all or part of a COBOL record
>> layout viewed in your Editor of choice, and have a popup window that
>> would give you the offset and length of each selected field and the
>> total length overall. (It may be a requirement that selection starts
>> from the 01 level, or not, depends on how your code works...)
>>
>> So the code should be able to accept or read COBOL Data Division
>> source as input, and output a simple text list with an entry for each
>> dataname showing the offset and length of it. (The offset represents
>> the total bytes preceding the field, so the total length of a record
>> definition is easily obtained, and saves all that very tedious
>> counting or searching for the compiler output.)
>>
>> I already have some COBOL code that parses COBOL source and analyses
>> pictures. I can amend it to do this as well, but it is tricky and
>> would not be publicly available.
>>
>> Please express interest here if you think you want to have a go at
>> this.
>> If no-one is up for it, I'll write it myself in C#, when I get time.
>> :-)
>
> Is COBFD what you want?
>
> See COBFD.ZIP on the Flexus download page:
> http://www.flexus.com/download.html

It looks pretty close from the description on the Web Site. Thanks HeyBub.

I have solved this problem for myself and amended my own metadata generator
to include the information on offset and length. However, Robert is going to
amend his code and I'll wrap it as a GUI tool that can be used with a mouse.
I think this would be a useful thing to have for many programmers dealing
with COBOL. (Not necessarily just COBOL Programmers.)

Pete.
--
"I used to write COBOL...now I can do anything."
>

"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:sReuk.19438$cW3.1359@nlpi064.nbdc.sbc.com...
> "HeyBub" <heybub@NOSPAMgmail.com> wrote in message
> news:MJKdnWHjZaBO7STVnZ2dnUVZ_uGdnZ2d@earthlink.co m...
>>
>> Is COBFD what you want?
>>
>> See COBFD.ZIP on the Flexus download page:
>> http://www.flexus.com/download.html
>
> I was starting to wonder if anybody remembered that. It's been there since
> about 1994.
>
> Ok, so I never got around to updating it. So what do you want at that
> price?

I'm sorry Michael, I never thought to check the Flexus tools.

Are you prepared to make it Freeware, including the source?

If you are, and can spare the time to review the code, and are satisfied
with it, I'll do the same deal for you as for Robert and put your tool onto
the .NET desktop. (The source needs to be COBOL; if you wrote it in BASIC I
can't wrap it easily...)

I believe this could be a useful tool for people. If we have two of them and
they are both Freeware, no harm is done. It's also about time some of us in
CLC actually collaborated on something... :-)

Cheers,

Pete.
--
"I used to write COBOL...now I can do anything."

Richard wrote:
....
> How hard would it be to write a couple of lines around a record layout
> so that the compiler will process it ?

I have one (and the curious thing is that it was inspired by a
conversation I had with Mr. Dashwood many moons ago, related to DECLGEN).
Unfortunately, it is coded in OO-Rexx on my OS/2v4.3 machine, which is
no longer connected to the Internet.

--
Fui et vidi experiri.
=DSM=
I'm not writing much COBOL these days, but then, I'm not writing much at
all except spy novels these days.

Michael Mattias wrote:
....
>> See COBFD.ZIP on the Flexus download page:
>> http://www.flexus.com/download.html
>
> I was starting to wonder if anybody remembered that.

Which reminds me, Mr. Wolfe not withstanding, has anyone heard from
Thane Hubbell recently?

--
Fui et vidi experiri.
=DSM=

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:6hu8boFntd3lU1@mid.individual.net...
> If you are, and can spare the time to review the code, and are satisfied
> with it, I'll do the same deal for you as for Robert and put your tool
> onto the .NET desktop. (The source needs to be COBOL; if you wrote it in
> BASIC I can't wrap it easily...)

The source is in BASIC for MS-DO; so it assumes you can't have more than
64Kb worth of anything without using disk work files.

The very flower of 1994 technology.

Wilted.

But it works!


MCM

On Sun, 31 Aug 2008 00:12:36 +1200, Pete Dashwood wrote:
> I will wrap it as a a COM server (so
> it can run anywhere)

As a matter of considerable interest, what COBOL implementation would you
be using to create that COM server?

Kind regards,
Bruce

-- Posted on news://freenews.netfront.net - Complaints to news@netfront.net --

"Bruce M. Axtens" <bruce.axtens@gmail.com> wrote in message
news:1iqvyxb4ldd53$.s11vbtiq5ltr.dlg@40tude.net...
> On Sun, 31 Aug 2008 00:12:36 +1200, Pete Dashwood wrote:
>> I will wrap it as a a COM server (so
>> it can run anywhere)
>
> As a matter of considerable interest, what COBOL implementation would you
> be using to create that COM server?

The Object Oriented implementation of Fujitsu NETCobol (Version 6, in this
case). This is NOT the Fujitsu product for .NET; it is standard COBOL,
except that it supports OOP. Fujitsu provide Classes that support COM
interfacing. It is really pretty simple. I have written many COM servers
using it and have wrapped many more COBOL modules to be COM servers with it.

When the project is complete you will be able to compare Robert's standard
COBOL engine with the same code wrapped as OO code. Once it is a COM
component it is no problem to access it from C#, using the InterOp Services
Class of the .NET framework. (It would also be a simple matter to embed it
in a Web page or run it as a Web Service...)

I see no need to spend thousands of dollars on the Fujitsu .NET COBOL
product when C# is free. (And much richer than COBOL in the Windows
environment.)

Pete.
--
"I used to write COBOL...now I can do anything."






>
> Kind regards,
> Bruce
>
> -- Posted on news://freenews.netfront.net - Complaints to
> news@netfront.net --