-Paul
"Ubiquitous" <web...@polaris.net> wrote in message news:b03m3q$3st$1...@news.utelfla.com...
Doesn't the newest mainframe COBOL have an XML Parse statement built in?
Why bother to call Java when you can it directly in COBOL?
For Windows and Unix, Micro Focus are implementing this in the soon to be
released Net Express version 4.0 and Server Express 4.0 will follow later in
the year.
Micro Focus are also extending file I/O syntax in these products so as to be
able to deal with XML.
"Ubiquitous" <web...@polaris.net> wrote in message
news:b03m3q$3st$1...@news.utelfla.com...
: Well Ubiquitous - if your mainframe is up to date, you probably just want
: to call a decent Java XML parser from the COBOL code.
: Other than that, it is a much more difficult proposition to parse XML than a
: fixed format flat file.
The trouble is, I don't think there is one installed, not do I expect
one in the future (we are eventually going to migrate off it).
I might just have to load it to an ORACLE table and then send a transaction
file to the mainframe...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg10/1.13
--
Bill Klein
wmklein <at> ix.netcom.com
"Ubiquitous" <web...@polaris.net> wrote in message
news:b03m3q$3st$1...@news.utelfla.com...
: If you write down in more detail what you want to do I might be able
: to help. Do you only want to rewrite XML to COBOL? Or do you also
: need things like SOAP etc.?
I have no more details as of yet, other than we might be receiving
accounting transactions from a client in XML format and we want to
load them into an IMS database. I'm sorry I cannot be more specific
right now.
> I might just have to load it to an ORACLE table and then send a transaction
> file to the mainframe...
You're going to take a flat file, put it on a database, and generate a flat
file from it?
Uh, why?
---
Doug
Acucorp will soon be releasing a new product call AcuXML with the new Extend
6 product set, which facilitates accessing XML files directly, please
contact your locate Acucorp office for more details on this, as they will be
happy to assist.
You can find their website at http://www.acucorp.com/
Thanks
Shaun Gough
Acucorp Inc.
Senior Customer Solutions Analyst.
"Ubiquitous" <web...@polaris.net> wrote in message
news:b03m3q$3st$1...@news.utelfla.com...
I can't speak to the details of implementation, but I can make
a decent suggestion. When writing an XML document generator,
consider part of its documentation to be a document schema.
They are fairly simple to do, and can preserve the type
information that's ostensibly discarded in Rik's example.
Here's an example of a schema that describes the aforementioned
document:
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- Elements -->
<xsd:element name="report-query">
<xsd:complexType>
<xsd:sequence minOccurs="1" maxOccurs="1">
<xsd:element name="report-ID" type="xsd:string"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="report-style" type="reportStyle"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="query-data">
<xsd:complexType>
<xsd:sequence minOccurs="1" maxOccurs="1">
<xsd:element name="department-ID"
type="xsd:string"/>
<xsd:element name="the-date"
type="reportMonthlyDate"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="show-return" type="xsd:integer"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- General Data types -->
<xsd:complexType name="reportMonthlyDate">
<xsd:sequence minOccurs="1" maxOccurs="1">
<xsd:element name="year" type="reportYear"
minOccurs="1" maxOccurs="1"/>
<xsd:element name="month" type="reportMonth"
minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="reportMonth">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="12"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="reportYear">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1999"/>
<xsd:maxInclusive value="9999"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="reportStyle">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="01"/>
<xsd:enumeration value="02"/>
<xsd:enumeration value="03"/>
<xsd:enumeration value="08"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
________________________
You can reference a schema in the document. (In this simple
example, both documents are in the same folder...)
<?xml version="1.0"?>
<report-query
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="report.xsd.xml">
<report-ID>1289</report-ID>
<report-style>08</report-style>
<query-data>
<deparment-ID>02</department-ID>
<the-date>
<year>1999</year>
<month>11</month>
</the-date>
</query-data>
<show-return>1</show-return>
</report-query>
<!--
01 report-query.
03 report-ID PIC 9(9).
03 report-style PIC 9(2).
03 query-data.
05 department-ID PIC 9(2.
05 the-date.
07 year PIC 9(4).
07 month PIC 9(2).
03 show-return PIC 9.
-->
__________________
Even if you do not describe the schema, you can validate the
document with a variety of xml-validators. This command line
utility had this to say about the example xml:
6 23 The 'deparment-ID' start tag on line '6'
doesn't match the end tag of 'department-ID'
11 5 The 'deparment-ID' start tag on line '6'
doesn't match the end tag of 'query-data'
13 3 The 'deparment-ID' start tag on line '6'
doesn't match the end tag of 'report-query'
This is an unexpected token. Expected
'EndElement'. Line 13, position 15.
http://www.naspa.com/02articlesbymonth.htm
Generation X Meets Tyrannosaurus Rex: Working with XML on the Mainframe
By Larry Kahm
This article describes a new feature in each of two venerable mainframe
products: the XMLGEN utility in Compuware Corporation’s File-AID/MVS
Release 8.8.1 and the XML PARSE statement in IBM’s Enterprise COBOL for
z/OS and OS/390 Version 3 Release 1. The former helps generate XML
documents; the latter makes it relatively easy to obtain data from these
documents.
Ubiquitous <web...@polaris.net> wrote in article
<b03m3q$3st$1...@news.utelfla.com>...
I was going to mention that one myself...
Larry Kahm
:> I might just have to load it to an ORACLE table and then send a transaction
:> file to the mainframe...
: You're going to take a flat file, put it on a database, and generate a flat
: file from it?
: Uh, why?
If the original flat file is in XML format and I don't have a parser
on the mainframe, I'm going to have to find some way to process it, yes?
: Acucorp will soon be releasing a new product call AcuXML with the new Extend
: 6 product set, which facilitates accessing XML files directly, please
: contact your locate Acucorp office for more details on this, as they will be
: happy to assist.
: You can find their website at http://www.acucorp.com/
Thank you all for all your help, but it looks like they can send us
plain flat data files after all.
> If the original flat file is in XML format and I don't have a parser
> on the mainframe, I'm going to have to find some way to process it, yes?
Oh, and the Oracle table load will recognise the XML?
---
Doug
> I have no more details as of yet, other than we might be receiving
> accounting transactions from a client in XML format and we want to
> load them into an IMS database. I'm sorry I cannot be more specific
> right now.
There is a simple XML Parser written in Cobol at Miami-Dade Community
College that works as a state machine (without any go to). This reads
an XML message into memory and is called repeatedly until the end,
each return replies with the nesting level, tagname, data type and
value. It doesn't validate though, expecting the XML to be correctly
structured.
I can a EMail a copy to you, plus a test program that I wrote, if you
want.
Writing XML is relatively easy, preferably using a templating
mechanism, I find that my templating code for HTML and/or forms can
also be used easily for XML.