COBOL tool

On Wed, 3 Sep 2008 03:18:25 +1200, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>
>"Howard Brazee" <howard@brazee.net> wrote in message
>news:r0hqb4p50ddcfunusikfll1plm5gl7t6ad@4ax.com.. .
>> On Sat, 30 Aug 2008 12:07:59 +1200, "Pete Dashwood"
>> <dashwood@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.
>>>
>>>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.
>>
>> I wrote one once - in CoBOL (I believe it used 3 passes). But there
>> are differences between machines that would make this a non-universal
>> tool.
>
>It is interesting to me that both you and Robert talked about multiple
>passes.
>
>My version uses a single pass and handles group fields, OCCURS and
>REDEFINES to 32 levels, along with binary, packed, big and little endian
>formats, synchronized (it calculates and inserts slack bytes as filler where
>needed) and sign separate clauses. It doesn't handle floating point or
>object references or index data names (all of which have no picture...)

I considered doing it in one pass, as the original version did. I didn't for three
reasons:

... The program needs to keep the structure in memory so it can look backward for
REDEFINES. The backward search is a second pass. Might as well call it what it is.
... People might say it's too complicated.
... Group names would be out of order, as you said.

Adding slack bytes and sign separate would be easy.

I also considered keeping the structure in a linked list, didn't because Cobol makes it
difficult to compare two list entries. It makes you code the structure twice in the
linkage section.

"Howard Brazee" <howard@brazee.net> wrote in message
news:nihqb4h7ji4sfg1fdqvhiihqtdc11pimfr@4ax.com...
> On Sun, 31 Aug 2008 12:44:36 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>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.)
>
> Non CoBOL programmers might be the primary audience.

Possibly.

If it is of use to anyone then it is not pointless to do it.

It will, amongst other things, demonstrate how to get COBOL running with C#,
how to bring COBOL to the .NET environment, and how using the best tools for
particular jobs can provide an overall better experience. It is also time
that there was some co-operative development between people here, so I hope
it will establish a precedent that will get others thinking about what this
community could be capable of.

There is no reason why this public code couldn't be a model for other COBOL
functionality to be brought into .NET.

That's before it even begins to achieve it's specified purpose.

I think it was Richard who complained about people with little
imagination... :-)

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

"Howard Brazee" <howard@brazee.net> wrote in message
news:19hqb4po25h370nldesb7q141ocdvog228@4ax.com...
> On Sat, 30 Aug 2008 17:20:08 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>>I don't want to re-process compiler output (which I cannot guarantee has
>>even been produced yet... the tool will be used during development. You
>>could be developing a record layout that has never been compiled...)
>>
>>I thought the requirement was clear; maybe it wasn't...
>
> You don't have a compiler available at this early development stage?
> I've used shells of programs just to get compile listings of copy
> members, I just don't create a load module. What is it that you are
> wanting that the compiler listing doesn't provide?

I want to use a mouse interactively. (Like they do in the 21st century.) How
does referring to a compiler listing help me do that? Even if I do it on
line I have to locate it, make sure it is the correct and current version,
then look at it with Notepad or somesuch... and that breaks my train of
thought when I am concentrating on the record layout. (Always assuming that
it has even been compiled yet...)

I have a mouse at my fngertips and I am editing the record layout or writing
it. I can select what is on screen and get what I need immediately with no
hassles.

Once I have the offsets and lengths I can not only use this information to
write other code, I can generate structures for other languages at the same
time as I develop or edit the COBOL layout.

I think, when you see the tool Robert and I will produce, you will have a
better idea of what I'm on about.

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

"Howard Brazee" <howard@brazee.net> wrote in message
news:0nnqb49ubb6fmet6lu7dn61ojq00utd2bd@4ax.com...
> O
>>> I wrote one once - in CoBOL (I believe it used 3 passes). But there
>>> are differences between machines that would make this a non-universal
>>> tool.
>>
>>It is interesting to me that both you and Robert talked about multiple
>>passes.
>>
>>My version uses a single pass and handles group fields, OCCURS and
>>REDEFINES to 32 levels, along with binary, packed, big and little endian
>>formats, synchronized (it calculates and inserts slack bytes as filler
>>where
>>needed) and sign separate clauses. It doesn't handle floating point or
>>object references or index data names (all of which have no picture...)
>>
>>I manage this by detecting reserved words and so knowing what are
>>datanames
>>and what are not, and PUSHing and POPping information at each level.
>
> My main interest in multiple passes was to avoid more tables than I
> needed. It was written on mainframe CoBOL about a decade ago. I
> was told to not look at every possible compiler USAGE clause, only the
> USAGE clauses our shop used (no floating point). But it did look at
> explicit and implicit synchronization. I'm not sure, but I don't
> think it handled sign separate clauses (these days that would be
> mandatory).
>
>>It emits metadata for every dataname in the record layout, but the group
>>levels are emitted after their constituent fields. (It would be a simple
>>matter to sort them if they needed to be in the same sequence as the
>>original record layout. For my purposes they don't have to be.)
>
> What do you use the metadata for?

It is used to generate load programs (in COBOL) for a relational database
generated from the COBOL FD source, and will be used for the MOST
(Maintenance Object Server Template) general purpose Data Access Layer which
I am currently developing.

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

"Robert" <no@e.mail> wrote in message
news:htsqb45v5ta0mj2i4q8g1cfmj9sogtobop@4ax.com...
> On Wed, 3 Sep 2008 03:18:25 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>>
>>
>>"Howard Brazee" <howard@brazee.net> wrote in message
>>news:r0hqb4p50ddcfunusikfll1plm5gl7t6ad@4ax.com. ..
>>> On Sat, 30 Aug 2008 12:07:59 +1200, "Pete Dashwood"
>>> <dashwood@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.
>>>>
>>>>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.
>>>
>>> I wrote one once - in CoBOL (I believe it used 3 passes). But there
>>> are differences between machines that would make this a non-universal
>>> tool.
>>
>>It is interesting to me that both you and Robert talked about multiple
>>passes.
>>
>>My version uses a single pass and handles group fields, OCCURS and
>>REDEFINES to 32 levels, along with binary, packed, big and little endian
>>formats, synchronized (it calculates and inserts slack bytes as filler
>>where
>>needed) and sign separate clauses. It doesn't handle floating point or
>>object references or index data names (all of which have no picture...)
>
> I considered doing it in one pass, as the original version did. I didn't
> for three
> reasons:
>
> .. The program needs to keep the structure in memory so it can look
> backward for
> REDEFINES. The backward search is a second pass. Might as well call it
> what it is.
> .. People might say it's too complicated.
> .. Group names would be out of order, as you said.
>
> Adding slack bytes and sign separate would be easy.
>
> I also considered keeping the structure in a linked list, didn't because
> Cobol makes it
> difficult to compare two list entries. It makes you code the structure
> twice in the
> linkage section.
>

I think your code is fine... :-)

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

Thane is still on the PL22.4 (previously J4) mailing list. See:
http://www.cobolstandard.info/j4/files/08-0182.doc

--
Bill Klein
wmklein <at> ix.netcom.com
"ElPistolero" <Merlin43PhD@Netscape.net> wrote in message
news:FdydnZBpONzPeCfVnZ2dnUVZ_uednZ2d@trueband.net ...
> 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=

On Wed, 3 Sep 2008 11:35:09 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>I want to use a mouse interactively. (Like they do in the 21st century.) How
>does referring to a compiler listing help me do that? Even if I do it on
>line I have to locate it, make sure it is the correct and current version,
>then look at it with Notepad or somesuch... and that breaks my train of
>thought when I am concentrating on the record layout. (Always assuming that
>it has even been compiled yet...)

Sometimes a mouse is useful - cutting and pasting. That said, I'm
accessing this forum using a newsgroup reader instead of a web
service. Using Google groups is much more work than typing.

We have record layouts of our IDMS records that are available on the
web. The main advantage is that I can enter the name of the record
and get all of its information quickly - even from home. But when I
have it, it's cutting and pasting - just the same as if I pulled it up
from a listing.

It is not obvious to me why locating the current version would be
easier using one tool over another. Maybe you don't have a place
where you can pull up the latest compile listing (we use Endevor which
has it for us).

On Aug 31, 2:39*pm, ElPistolero <Merlin43...@Netscape.net> wrote:
> 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.Wolfenot withstanding, has anyone heard from
> Thane Hubbell recently?
>
> --
> Fui et vidi experiri.
> =DSM=

Thane and I are alive and well......we just aren't very frequent
visitors. Thane still does contracting work for Flexus and we still
offer an array of compiler independent COBOL development tools. We
now have about 14 tools, including some migration and conversion tools
for COBOL.