Display QCDRCMDD XML Output Using XSLT Stylesheet

by Steven Gray

[The code for this article is available for download.]

Ted Holt recently explained how to retrieve source code for a CL command using the QCDRCMDD (retrieve command definition) API, with the results written to an XML stream file. While the output file was viewable in a browser, there still was a lot of work to be done to extract meaningful information. To make the XML file more readable, I created an XSLT stylesheet that formats the browser display into something meaningful and can be pasted into a CMD source member, virtually ready to compile.

Here's how to make it work.

Copy the original XML file, genddl.xml, and my XSLT stylesheet, genddl.xslt, to any working directory on your PC. Next, using Notepad, add the following statement in genddl.xml as line 2:

<?xml-stylesheet type="text/xsl" 
   href="c:\...path...\genddl.xslt"?>   

Fill in your path, then save, and exit Notepad. Next, start your browser and open the XML file, by using File and Open or by entering the file address directly in the browser's address line:

C:\...path...\genddl.xml

The browser opens the XML file and, using the XSLT stylesheet, displays the data in a working CMD source format. The following is a sample of the full display:

/*=================================*/
/* Command: GENDDL      */
/*=================================*/
CMD PROMPT('Generate SQL DDL') 

PARM                            PosNbr( 1 ) +
                                  KeyParm( *NO ) +
                                  Type( *CHAR ) +
                                  Min( 1 ) +
                                  Max( 1 ) +
                                  Prompt('Object name') +
                                  Len( 258 ) +
                                  Rstd( *NO ) +
                                 AlwUnprt( *YES ) +
                                 AlwVar( *YES ) +
                                 Expr( *YES ) +
                                 Full( *NO ) +
                                 DspInput( *YES ) +
                                 Choice('Character value') +
                                 Dft( ) + 
                                 Values(    ) +
                                 SpcVal( )

At this point, you can directly insert the code blocks into a source member while in SEU, using cut and paste, or copy the entire display to an empty text file and FTP it to your target source member. From SEU, reformat the code and remove unused keywords by pressing F4.

Here's how I reverse-engineered the XML file into an XSLT stylesheet using an XML editor and a stylesheet designer.

Before I could begin designing an XSLT stylesheet, there were several files I needed to create: a DTD file and an XSD file. A DTD file is an XML "document type definition" file. An XSD file is an XML schema, a newer and richer XML document definition language. In addition, XSLT is a complex language (about which I knew nothing, but why let that stop me?), so I needed to get a GUI designer tool to do the heavy lifting. Some XML editors and stylesheet designers also have functions that generate DTD and XLS files from an XML file, so I was going to need these, too.

I chose two GUI tools from XMLSPY. Xmslspy5 is their XML editor and DTD/schemas builder, and Stylesheet Designer is their XSLT builder. Both were available in free trial-demo versions, which aided in the selection process. I downloaded the demo versions and, following the instructions, installed both with no problems.

First, I brought up the XML file in Xmlspy5. The file opened by default in the enhanced grid view. Xmlspy5 lets you edit and view documents in a number of different display types. I worked with three: the enhanced grid view, the text view with color highlighting and drop-down boxes, and the browser view. I verified it was a well-formed XML document by using F7.

Next, I let Xmlspy5 create the DTD for me by using the Generate DTD/Schema wizard. I took the defaults offered and saved the file. I examined the DTD in the text view. The DTD language is a much simpler language than XML Schema, so I hoped to spot any choices made by the generator that I might want to tweak. I found one obvious change to make that would make sense to AS/400 programmers familiar with CMD syntax. The generator had assigned the keyword KWD as an attribute of PARM, which was OK, but it then gave KWD a list of valid values. This would restrict us to working with the parameter names for this command only. I deleted the values list and replaced it with the CDATA attribute, which gives more flexibility. I saved my changes to the DTD file.

Finally, now that I had made an educated guess on some simple editing of the DTD file, I used the Convert DTD/Schema wizard to generate the XSD. I chose W3C Schema type and saved the result file. No other changes were made here.

Now I was ready to design my XSLT document. I started Stylesheet Designer and opened the XSD file. The designer displayed the file in a frame, which showed the structure of my data design in a tree format. Then, in order to see results with real data as I worked, I assigned a Working XML File from the File Menu. Following the online documentation, I dragged data elements and attributes from the structure tree and dropped them into the design frame. I used tables to position the elements or attributes, and added text to create a shell format resembling CMD source. As I worked, I viewed the results in an HTML preview panel. When the results looked right, I used Save Generated XSLT File to build the final transformation document.

What's Next, Doc?

You can use this XSLT file with any XML output from the API QCDRCMDD, but the viewable results may be missing some PARM keywords, as well as the QUAL, ELEM, PMTCTL, and DEP statements. That's because I created my data definitions from your original XML file, which was built from a command that used only PARM statements. However, IBM has a more complete DTD file specifically for use with the output of QCDRCMDD. This DTD file should allow me to add features to handle all CMD statements and keywords and to create a more complete stylesheet. I'll let you know how this works out.

Ted Holt responds: I gave your solution a try, Steven, and it generated command source. I had two problems with the generated source, neither of them show-stoppers. First, the generated XML included a POSNBR keyword for each parameter, which doesn't exist in the PARM command. These keywords gave me a CPD0043 error ("keyword POSNBR not valid for this command"). Second, a very few of the lines were split into two lines, but I quickly fixed them. Thanks for sharing your knowledge with the rest of us.

Look for more XML-related tips from David Morris soon in Midrange Guru.

Steven Gray is an independent consultant. He has worked with the S/38, the AS/400, and the iSeries for over 16 years. E-mail: steven.gray@rcn.com

Sponsored By ADVANCED SYSTEMS CONCEPTS

Quoted from an experienced programmer new to the iSeries (AS/400): "The best thing about working on the AS/400 is using ASC's SEQUEL product." If you're tired of the limitations imposed by Query/400 or ODBC-based query and reporting tools, you need SEQUEL. Discover how thousands of sites around the world have improved access to iSeries data using SEQUEL's Windows- and Web-interfaces. It's the one tool you can rely on for virtually all your iSeries data access needs. FREE trial available. Read More about SEQUEL