Re: XML Parser in HLASM?

[Paul Raulerson]

Is anyone aware of an XML parser written in HLASM? Ideally, I would like to find a DOM like parser, but a SAX parser is better than having to write one from scratch. :)

Oh, this will most likely run under zLInux, so if someone has already built HLASM interfaces to eXpat or libXML2 or something similar, that would work very well for us as well.

Thanks,
-Paul

[Chuck Arney]

I looked into writing a DOM parser for a product I used to have but it
looked like way too much work since they are already available in other
languages. I never found one already existing in HLASM but that does not
mean none exist.

Chuck Arney
Arney Computer Systems

[Bernd Oppolzer]

I have a XML parser (SAX and DOM) which is written in C
and is very fast. It runs on z/OS, but on other platforms, too
(Linux, Windows, OS/2). On z/OS, I built an interface to make
calls from PL/1 possible, and the routines for the SAX events
can also be PL/1 routines. The same is of course possible for
ASSEMBLER; the PL/1 interface (or the C interface) should in
my opinion be usable by HLASM without any investment.

I recently observed that the storage management which is built
into this parser outperforms standard malloc/free of LE (it is
optimized especially to deal with many allocations of small areas
of storage).

If you're interested, please contact me offline to discuss further details.

Kind regards

Bernd

[Martin Packer]

Anything wrong with System XML? Perfectly feasible to use from HLASM.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

From: Bernd Oppolzer <bernd.o...@t-online.de>
To: ASSEMBL...@listserv.uga.edu,
Date: 07/25/2013 10:23 AM
Subject: Re: XML Parser in HLASM?

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Fred van der Windt]

> Anything wrong with System XML? Perfectly feasible to use from HLASM.
> Cheers, Martin

Yes, and extremely efficient if you implement a String ID exit. But it's called *z/OS* XML System Services so it might not available under zUnix?

Fred!
-----------------------------------------------------------------
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-----------------------------------------------------------------

[Martin Packer]

Ah, I missed the Unix / Linux connection.

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

From: Fred van der Windt <Fred.van....@mail.ing.nl>
To: ASSEMBL...@listserv.uga.edu,
Date: 07/25/2013 11:04 AM
Subject: Re: XML Parser in HLASM?
Sent by: IBM Mainframe Assembler List
<ASSEMBL...@listserv.uga.edu>

[Bernd Oppolzer]

No, there's nothing wrong with the other XML solutions,
except the fact that we needed our solution in 2001, already,
and that it runs on all the other platforms, too.

It turned out to be 3 times faster than XerCes, BTW,
when there were some efforts at our site to get rid of it,
in favor of XerCes, so this was not done (and XerCes is
in C++, and we didn't want C++ at out site - or more precisely:
we are a "C, PL/1 and ASSEMBLER only" shop).

Kind regards

Bernd

[Robin Vowels]

> From: IBM Mainframe Assembler List [mailto:ASSEMBL...@LISTSERV.UGA.EDU]
> On Behalf Of Paul Raulerson
> Sent: Wednesday, July 24, 2013 7:31 PM
>

> Is anyone aware of an XML parser written in HLASM? Ideally, I would like to
> find a DOM like parser, but a SAX parser is better than having to write one
> from scratch. :)
>
> Oh, this will most likely run under zLInux, so if someone has already built
> HLASM interfaces to eXpat or libXML2 or something similar, that would work
> very well for us as well.

IBM's PL/I has a high-speed XML parser built in.

[Alex Kodat]

The Rocket Software XmlDoc
(http://wiki.sirius-software.com/index.php/XmlDoc_API#The_XmlDoc_class)
and XmlParser (http://m204wiki.rocketsoftware.com/index.php/XmlParser_API)
APIs available for the Model 204 database are completely written in
Assembler though users access them via the SOUL O-O language. The XmlDoc
classes are full O-O XML APIs with a parser and serializer and the
XmlParser classes are a SAX stream-based XML parser (like SAX but better
because it uses method variables rather than inheritance). All of these
APIs provide full-on unicode support for the users with automatic
conversion to/from EBCDIC as possible.

Unfortunately from the OP's perspective, these APIs are proprietary and
tightly coupled into the Model 204/SOUL environment. So this is mainly
just bragging and as a point of information for people wondering what sort
of work is being done in Assembler these days. While the fact that Model
204 is written almost completely in assembler forced our hand, I'm not
convinced that the implementation of these classes would have been
significantly easier than in a higher level language.

The main down-side of having implemented in assembler is that, in the
early days we did get the odd storage overlay bug that was quite difficult
to diagnose. Of course you can get these in C and C++ also. Type-safe
languages such as C# and Java manage to avoid these issues though my
experience is that this comes at the very real cost of loss of control or
at least more difficult control of storage usage.

Sorry, that this doesn't help the OP but, again, I thought some Assembler
jockeys might be interested.

--
Alex Kodat
Senior Product Architect
Rocket Software
t: +1 781 684 2294 • m: +1 315 527 4764
e: ako...@rocketsoftware.com • w: www.rocketsoftware.com

[Paul Raulerson]

Thanks guys - you have all given me a great deal to sort and think about! Appreciate all the tips, and I will contact offline those of you who invited me to. When we come up with just the right solution, I'll also feedback and let you guys know what we did.

Thanks again - Paul

> t: +1 781 684 2294 � m: +1 315 527 4764
> e: ako...@rocketsoftware.com � w: www.rocketsoftware.com