parsing cobol structures

hi,
We are developing a vb.net app that talks to a backend cobol app
through mq messages. To understand each other the vb.net app reforms
its data to one string that exactly maps to a cobol structure known to
the cobol backend. On vb.net side we have classes that can automate
mapping the cobol structure to a .net 'compatible' format, ie classes
with properties that are either strings or decimals, integers, ... So
far no problem.

Problem is that for each cobol structs we use, we have to define a
new .net equivalent class. We could automate this if there were an
easy way to derive the following for each field in a cobol structure:
- datatype
- length in bytes
- offset in the structure in bytes
- occurance if any
All this can be generated based on the cobol definition of the
structure, but it rapidly begins to look like a cobol compiler to
me. :-)

We don't want to use xml (yet) for the messages between the two sides
because this would mean composing and decomposing an each side for
each message, this seems more of an overhead than a solution.

Is there anyone out there that encountered the same problem, any hint
on how you solved it?
Is there (open source) software out there that gives the required info
based on the cobol definition of the structure?

thanks for your feedback,
Andy Heynderickx

From mentioning MQ, I am guessing (and it is only a guess) that your COBOL m
ay
be on an IBM mainframe.  If so, there is an easy way to get the information 
you
want.  I don't know, however, if it would allow you to get what you want WHE
N
you want it and where.

check out the example of "MAP" output at:

http://publibz.boulder.ibm.com/cgi-...gy3pg32/2.6.4.3

I think it would be (relatively) trivial to take that type of output and cre
ate
what you are interested in.

--
Bill Klein
wmklein <at> ix.netcom.com
"andyhe" <andyhenospam@skynet.be> wrote in message
news:1176390826.943476.120310@n76g2000hsh.googlegroups.com...
> hi,
> We are developing a vb.net app that talks to a backend cobol app
> through mq messages. To understand each other the vb.net app reforms
> its data to one string that exactly maps to a cobol structure known to
> the cobol backend. On vb.net side we have classes that can automate
> mapping the cobol structure to a .net 'compatible' format, ie classes
> with properties that are either strings or decimals, integers, ... So
> far no problem.
>
> Problem is that for each cobol structs we use, we have to define a
> new .net equivalent class. We could automate this if there were an
> easy way to derive the following for each field in a cobol structure:
> - datatype
> - length in bytes
> - offset in the structure in bytes
> - occurance if any
> All this can be generated based on the cobol definition of the
> structure, but it rapidly begins to look like a cobol compiler to
> me. :-)
>
> We don't want to use xml (yet) for the messages between the two sides
> because this would mean composing and decomposing an each side for
> each message, this seems more of an overhead than a solution.
>
> Is there anyone out there that encountered the same problem, any hint
> on how you solved it?
> Is there (open source) software out there that gives the required info
> based on the cobol definition of the structure?
>
> thanks for your feedback,
> Andy Heynderickx
>

"andyhe" <andyhenospam@skynet.be> wrote in message
news:1176390826.943476.120310@n76g2000hsh.googlegroups.com...
> hi,
> We are developing a vb.net app that talks to a backend cobol app
> through mq messages. To understand each other the vb.net app reforms
> its data to one string that exactly maps to a cobol structure known to
> the cobol backend. On vb.net side we have classes that can automate
> mapping the cobol structure to a .net 'compatible' format, ie classes
> with properties that are either strings or decimals, integers, ... So
> far no problem.
>
> Problem is that for each cobol structs we use, we have to define a
> new .net equivalent class. We could automate this if there were an
> easy way to derive the following for each field in a cobol structure:
> - datatype
> - length in bytes
> - offset in the structure in bytes
> - occurance if any
> All this can be generated based on the cobol definition of the
> structure, but it rapidly begins to look like a cobol compiler to
> me. :-)
>
> We don't want to use xml (yet) for the messages between the two sides
> because this would mean composing and decomposing an each side for
> each message, this seems more of an overhead than a solution.
>
> Is there anyone out there that encountered the same problem, any hint
> on how you solved it?

Yes, I have had exactly this problem. I had a COBOL structure that needed to
be created, passed, and analysed upon return, in the DotNET environment.

Here's the cobol structure:

01  ws-interfaceBlock.
12 ws-return   pic x(5).
88 ws-OK            value '00000'.   *> will contain SQLSTATE if
*> there is a
DB error
12 ws-message  pic x(256). *> will contain SQLMSG if
*> there is a DB error
12 ws-buffer   pic x(2048). *> holds free format address data
*> this will be formatted on
return
12 ws-breakdown.
15 ws-streetNo             pic x(20).
15 ws-POBoxNo              pic x(15).
15 ws-RDNo                 pic x(8).
15 ws-street               pic x(150).
15 ws-locality             pic x(150).
15 ws-city                 pic x(50).
15 ws-lobby                pic x(150).
15 ws-postCode             pic x(4).
15 ws-addressType          pic x(1).
15 ws-streetSDX            pic x(4).
15 ws-localitySDX          pic x(4).
15 ws-lobbySDX             pic x(4).
15 ws-prologue             pic x(100).
12 ws-interface               pic x.
88 free-format-input        value '1'.
88 fixed-field-input        value '2'.
88 XML-input                value '3'.
12 ws-streetMatchFlag         pic x(1).
88 street-fuzzy                  value '0'.
88 street-exact                  value '1'.
12 ws-localityMatchFlag       pic x(1).
88 locality-fuzzy                  value '0'.
88 locality-exact                  value '1'.
12 ws-repeatLocalityFlag      pic x(1).
88 no-Locality                  value '1'.
88 repeatLocality               value '0'. *> used if Locality =
City
12 ws-ignoreInvalidPostcodeFlag    pic x(1).
88 ignoreInvalidPostCode        value '1'.
88 reportInvalidPostCode        value '0'. *>stops if Post Code
is invalid
12 ws-foreignFlag             pic x(1).
88 foreign-address            value '1'. *>stops if foreign
address detected
88 NOT-foreign-address        value '0'.


Heres the C# source of the Class that deals with it:

http://homepages.ihug.co.nz/~dashwo...BlockBuilder.cs

(I'm not entirely happy with this as it was an early attempt and I think I
could do better now. XML is definitely the way to go.)

The interface block string in the example above is later wrapped by SOAP and
used with a Web Service. This is all automatic with VS 2005, generate the
WSDL and the XML is done for you...

The point is that every element in the COBOL structure needs to be publicly
addressable, and if you are SETting it, you must insert it correctly at the
right position in the string which is represented by the COBOL 01 level. It
is also handy to have a method which initializes the whole string for you.

The COBOL requirement for fixed length strings has caused me considerable
grief in the DotNET environment, but I've pretty much developed simple ways
to deal with this. One of the worst was when updating a Relational table
with a Table Adapter and OLE Command, if any of the strings to be updated
are longer than the DB Schema column definition provides for, the UPDATE
command fails. This doesn't happen in COBOL because all fields are fixed
length and they are truncated to the maximum length by MOVE (So they CAN'T
be longer than the column definition). I have overcome this by accessing the
Schema definition for every DB I intend to update, and ensuring that no
strings in the program are greater than the permissible length before
replacing them in the in-memory result set. This works fine and it has a
spin off in that, under certain circumstances, I can actually reorganise the
data so it ISN'T truncated (as it would be in COBOL) but is spread across
other columns.

> Is there (open source) software out there that gives the required info
> based on the cobol definition of the structure?

Not that I know of, but it is fairly easy to design a general "COBOL
Structure Builder" using the principles demonstrated above. Provided you
know the length (and, possibly, type) of each element (and parsing the COBOL
picture gives you this) it isn't too hard to construct Properties and
Methods that can deal with the Record level and each of the constituent
elements. (REDEFINES and OCCURS would be problematic, but not
insurmountable. I have parsed and dealt with these in other tools I've
developed.)

Hope the above is of some use; it represents a great deal of thought,
experiment, and effort.


Pete.

This map output would be a great start, but we're running on an AIX
machine (unix) with Microfocus Cobol, and we need the info on the .net
side. :-(
Since my post I've come across the cobfd tool (see http://www.flexus.com/download.
html),
this does more or less what we need, but runs under DOS. With some
patchwork I think we can make this work.

Thanks for the input. From what I see in your source code you started
on the same trakck we did. I don't know about you but when you have a
lot of different cobol structs to deal with this type of interfacing
becomes tedious and prone to bugs. So what we did is develop a base
class you can inherit from and where you can generically define fields
in the constructor.
Define fields with something like
'addfield("myname",myoffset,mylength)'
(redefines are inherently possible, same offset for different fields)
Access an field using a generic method: fieldvalue("myname")
Access the whole structure using 'myclass.tostring' (shadowed)

With this method the interface becomes very 'doable'.

But we still need the correct offsets en lengths for the fields in the
structure, and if you don't count right, this method is still prone to
bugs, so I wanted to automate this step also, hence my question.
Ideally I would just like to copy-paste the cobol definition into the
constructor of my class and extract field definitions (offset, length)
directly from it, without any 'human' interaction. Seems simple but
becomes difficult very rapidly when dealing with redefines and occurs.

"andyhe" <andyhenospam@skynet.be> wrote in message
news:1176704449.881509.118680@l77g2000hsb.googlegroups.com...
> Thanks for the input. From what I see in your source code you started
> on the same trakck we did. I don't know about you but when you have a
> lot of different cobol structs to deal with this type of interfacing
> becomes tedious and prone to bugs. So what we did is develop a base
> class you can inherit from and where you can generically define fields
> in the constructor.
> Define fields with something like
> 'addfield("myname",myoffset,mylength)'
> (redefines are inherently possible, same offset for different fields)
> Access an field using a generic method: fieldvalue("myname")
> Access the whole structure using 'myclass.tostring' (shadowed)
>
Yes, that's pretty good. I'll look at this again when I have time.

> With this method the interface becomes very 'doable'.
>
> But we still need the correct offsets en lengths for the fields in the
> structure, and if you don't count right, this method is still prone to
> bugs, so I wanted to automate this step also, hence my question.

Yes, I have tools that parse COBOL pictures, it isn't that hard to do.

> Ideally I would just like to copy-paste the cobol definition into the
> constructor of my class and extract field definitions (offset, length)
> directly from it, without any 'human' interaction. Seems simple but
> becomes difficult very rapidly when dealing with redefines and occurs.

OCCURS, is harder. At some point, when my decks are clear, I'll look at
something that does this. I think there could be some demand for it as
people move to C# etc.

Good luck!

Pete.

small update: on microfoucs cobol a map can be generated using a
compiler directive '$set DATAMAP' ,  but it's incomplete. It states
offset and length, but only the length of the fields as such,
disregarding whether it's in an occurs or not.
e.g.  "01 AAA pic x occurs 100" looks the same as "01 AAA pic x"
there doesn't seem to be a way to see that the first version is
actually length 100, not 1

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:58ip6tF2h2mklU1@mid.individual.net...
>
> "andyhe" <andyhenospam@skynet.be> wrote in message
> news:1176704449.881509.118680@l77g2000hsb.googlegroups.com... 
> Yes, that's pretty good. I'll look at this again when I have time.
> 
>
> Yes, I have tools that parse COBOL pictures, it isn't that hard to do.
> 
>
> OCCURS, is harder. At some point, when my decks are clear, I'll look at
> something that does this. I think there could be some demand for it as
> people move to C# etc.
>
> Good luck!
>
> Pete.
>

In Donald Knuth's "The Art of Computer Programming: Fundamental Algorithms",
2nd printing 1975, starting on page 423 is section 2.4 MultiLinked
Structures.  It discusses data structures and algorithms for compiler
translation of COBOL records. However IIRC it doe not get into OCCURS, but
it might provide a starting point.  YMMV.