C$XML Disable initial comment in generated XML

Sorry to revive an old question, but I'd like to know if it's now possible with extend 9 or 10 to disable the initial comment in XML generated by C$XML (original filename and "generated by ACUCOBOL-GT", etc). This has been asked in the past, but there was never much of an answer. 

Since C$XML does pretty much what I want, I'd rather not get into other solutions like XML Extensions. I've already tried deleting the comment with CXML-DELETE-COMMENT, but it doesn't seem to be handled like a normal comment in the XML. I can't even access it with CXML-GET-COMMENT, like I can with comments I've added myself.

Is there some trick or configuration setting for getting rid of this comment?






  • No, there isn't a configuration variable or work around when using C$XML to get rid of the "generated by" line in the XML file.
  • Verified Answer

    Run an XSL transform as a post-generation step.  This could be done by executing a command line XSL processor as appropriate for your operating system.

    The XSL you need is an identity transform with a template added to match comment nodes and eliminate them.  The following would be a good starting point for such a transform:

    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:xsl="www.w3.org/.../Transform" version="1.0">
    <xsl:template match = "@*|node()|processing-instruction()">
    <xsl:apply-templates select="@*|node()|processing-instruction()"/>
    <xsl:template match="comment()"/>

    The first <xsl:template> is the classic identity transform.  The second <xsl:template> matches all comment nodes and eliminates them by the fact that the template does not create any output.

    I can supply some more information if you want to supply the OS identity.

  • Thanks, this sounds like something we could try. We're using Windows. Is there a command line XSL processor that you can recommend?

  • Thanks, this sounds like something we could try. We're using Windows. Is there a command line XSL processor that you can recommend?

  • Thanks, this sounds like something we could try. We're using Windows. Is there a command line XSL processor that you can recommend?

  • Verified Answer


    I created a Jscript script which can be found in the last two entries on this thread (no login needed):


    I am sure it could be improved by a better JScript programmer, but again it is a starting point.

  • Verified Answer

    Tom - Rather than rely on an external script (Powershell, Jscript), wouldn't it make more sense to invoke the XSLT directly from the ACUCOBOL program using XML TRANSFORM FILE? Claire mentions "extend 9 or 10" and I believe XML Extensions is available in either of those versions (I don't recall now in exactly which version it was introduced, but I know for sure it's in 10 since that's what I'm using).

    Claire - unless Tom sees an issue using it, I don't think there'd be any conflict using a combination of C$XML and XML Extensions in this way - you'd still create the file with your current usage of C$XML, then post-process it with XML TRANSFORM FILE.
  • Verified Answer

    Since Claire expressed a preference for other than XML Extensions, I devised a solution that did not use XML Extensions. I am not sure what the licensing scheme is for XML Extensions on AcuCOBOL, or what operational issues it may present for Clair. Of course, I would prefer to use XML Extensions, and yes XML TRANSFORM FILE would have the identical effect of applying an XSLT transformation and would have the further benefit of being OS agnostic.

    [Chuck, hope you are doing well.]

  • I don't mind using XML Extensions for post-processing. C$XML just seemed like a good choice for generating the file, because it won't always have quite the same structure, so I wanted the flexibility. We have extend 10, although we're still using 9 in production. I can check and see what's available in extend 9 and experiment with these suggestions later this week.

    Thanks for the ideas!

  • Verified Answer

    "it won't always have quite the same structure, so I wanted the flexibility"

    Please understand, Claire, that I am not suggesting a rewrite of something you probably already have working.  However,...

    I have a lot of experience in the world of XML.  I strongly believe that a (mostly) functional programming approach to building XML documents (XSLT) is highly preferred to a procedural approach (C$XML).  I have used other procedural languages (VB, C, to some extent C#) to build and consume XML documents, and I find that there is so much 'busy-ness' in all the logic to build/consume a document, that clarity is sacrificed.  And if clarity is sacrificed, future maintenance costs will be much higher.

    I also have an intuition that using XSLT to process documents provides a clear separation between data and its representation, much like the old argument about having a user interface layer, business rules layer, data store layer, etc.  Having this type of separation allows the selection of tools that best fit each layer.

    Now, to go directly to the point of your statement - that the use of C$XML is going to provide more flexibility than an XSLT approach.  I cannot imagine a situation where this is true.  XSLT has a complete set of control flow statements, so all the decisions that can be made in the COBOL program can be made with the control flow statements in XSLT.  While XSLT does not have an assignment statement, this is almost never a constraint.

    And, just to show who's boss, the COBOL program can decide to use different XSLT in different situations, though I find this is rarely needed.  The one time I have done this on a consistent basis is where the consuming application can demand either XML or JSON (typically as a web service response).  Oh, wait... what happens if you are suddenly required to produce JSON instead of XML?  Will C$XML output JSON - without rewriting more than two or three lines of the COBOL program?

    So, Clair, there is no right way or wrong way.  C$XML is working for you, and I hope that it continues to serve you well in the future.  But, in a future project where you have a chance to change the development approach, please give XSLT (and therefore XML Extensions) serious consideration. 

    Best of luck!