Origins of COB2XSD tool

[Steve Dalton]

Just came upon this project by way of Fady on the cicsctg mule list.

Can anyone point me in the direction of the origins of the COB2XSD
DLLs/libraries supplied with legstar? I don't think this is from
legstar as there is no source - is this an IBM tool or something?, I
wasn't able to find a lot of reference to it on Google. I'm just a bit
wary of something I don't have the source for or any licence
information.

Apart from this question - all seems to work well - I've successfully
converted my copybooks to XSD... now digging a little further.

Thanks
Steve

--
Refactor
Engage. Succeed. Repeat.
PO Box 5658, GCMC, Q 9726, Australia
tel: +61 (0)7 5668 3424 web: refactor.com.au

[Steve Dalton]

Just answering my own question here. I found what I needed in

docs/SCHEMAGEN-README

Schemagen is the only LegStar module that uses native C programs. The
standard
delivery includes dlls for Windows and shared objects for Linux. The
Linux
shared objects were compiled on Fedora Core 6 with GNU C. If you are
targeting a
different unix distribution, a makefile is available along with the
sources
that you can get from the LegStar web site.

I couldn't find the source code for the C library on the website, but
did eventually find it in Subversion

http://legstar.googlecode.com/svn/tags/Legstar-1.2.6/legstar-schemagen/src/main/resources/

Steve

[Fady Moussallam]

Sorry that you had to do all that research Steve. The README text should
be more precise.

In addition to SVN, the C sources are also part of the
legstar-1.2.6-sources.jar bundle which is available for download at
http://www.legsem.com/legstar/legstar-distribution/index.html.

Fady

[Steve Dalton]

No worries Fady - wasn't hard to find, I was just being lazy not
looking properly. I did have the source bundle - but wrongly assumed
it was all java code in there.

Good work on the project btw - looks pretty awesome (and well
documented) - there's not much around in this area, about time there
was some decent open source for it.

I am currently mostly interested in the copybook -> XML conversion - I
already have the data files out of the mainframe on a drive share and
just need to convert these into some clean XML that I can then perform
some of our own XSLT on. How easy would it be to hook up your binding
modules directly to filesystem rather than going through all the
Mainframe adapter and proxying stuff? I could see how some of this
might be useful for your own automated testing of the binding code
anyway (isolated from all mainframe stuff).

Plan to have a good look at the code today so perhaps my questions
will be answered there.

Steve

[Fady Moussallam]

Hello Steve,

Thanks for the nice comment.

You can use the binding capabilities without the transport/messaging
stuff. Legstar is very modular, perhaps too much actually. Originally
the web site simply listed all modules and you would have to pick and
choose the ones you needed. That was not simple for newcomers so we
bundled the entire thing together for simplicity. You can still download
individual modules though.

Using ant scripts or Eclipse plugins, you can do COBOL > XSD > Binding
classes. The Binding classes include Transformers which are a high level
API. At this stage you have everything necessary to convert mainframe
data to java or XML. There is a section on using transformers here:
http://www.legsem.com/legstar/legstar-coxbgen/release-notes.html.

Let us know how it goes.

Fady

[Steve Dalton]

Thanks Fady
I'll have a play with it today and get back to you
Regards
Steve

On Thu, Sep 10, 2009 at 4:31 PM, Fady Moussallam

[Steve Dalton]

OK - I have the transformers going - I can get the transformers and
convert to java JAXB objects to get to the individual fields or I can
use the XmlTranformer and pump out the raw XML.

My main stumbling block at the moment is redefines. One of my
copybooks has several - and if I try and access one of the rows in the
data files as the redefined type - it's just null. I can access the
row as the raw Variable data - but that's not much use to me. Same
applied to the XML - it has every row just output as the raw data, not
redefined.

My apologies if my terminology is not quite correct here - I'm not
much of a mainframe person and only just getting the hang of this
redefine stuff.

Many Thanks
Steve

[Fady Moussallam]

Hello Steve,

The topic of handling REDEFINES have come up recently on the list and I
thought it was time to write a wiki on the subject. I just posted this
first attempt: http://code.google.com/p/legstar/wiki/HandlingRedefines.
I think it might help you understand the default behavior and what you
can do if you need to customize it.

When you unmarshal COBOL data to Java. You should get a non-null
alternative and the others should be null. If you are getting all nulls
then there might be a bug somewhere. Would you mind posting your COBOL
structure (I suggest changing the COBOL data item names if there are
confidentiality issues).

Thanks

Fady