On 4/6/2012 5:29 PM, Frank Swarbrick wrote:
Enterprise COBOL v4.2.First real world attempt at using XML GENERATE. Works as designed, and relatively user friendly, but not particularly flexible for real world requirements. XML GENERATE will generate no fields as attributes unless with WITH ATTRIBUTES phrase is specified. In that case it will generate attributes (rather than elements) ANYWHERE it can. I just want to make sure, before I go any further, that there is ABSOLUTELY NO WAY, using just XML GENERATE, that some fields that COULD be attributes can not be forced to be elements if the WITH ATTRIBUTES phrase is specified. For example, I cannot generate the following using XML GENERATE alone (no post-processing to modify the generated XML document): <underwritingrequest> <crossSellOfferId>12000</crossSellOfferId> <channelType>WEB-IA</channelType> <offerCategory>Consumer</offerCategory> <preApprovedProds> <product categoryCode="CC" limit="5000"/> <product categoryCode="CR" limit="1000"/> </preApprovedProds> <parties> <party> <dob>01/01/1950</dob> <scoreNo>725298</scoreNo> <income>100000</income> <housingExpense>1200</housingExpense> <housingStatus>Owns</housingStatus> </party> </parties> </underwritingrequest> As you can see, all of the "elementary" data items are XML elements EXCEPT for the "categoryCode" and "limit" fields under "product". Current COBOL group data item: 01 underwritingrequest. 05 crossSellOfferId pic x(10). 05 channelType pic x(10). 05 preApprovedProds. 10 product. 15 categoryCode pic x(2). 15 l1mit pic 9(7). 05 parties. 10 party occurs 1 to 10 times depending on party-count indexed by p_idx. 15 dob pic 99/99/9999. 15 scoreNo pic 9(9). 15 income pic 9(9). 15 housingExpense pic 9(9). 15 housingStatus pic x(10). Please note that I have seen the tech note "XML GENERATE should create attributes under COBOL"; http://www-01.ibm.com/support/docview.wss?uid=swg21218516 All I can say is (to quote Seth Meyers and Amy Poehler): "Really?!?!" Since we own the process that consumes this XML document I hope I can convince them to go either all attributes or all elements, but not this little mish-mash. But I want to make sure I am not missing something SIMPLE that I can do to get what they really want. (I already have to change use field name '1imit' instead of 'limit' and then do INSPECT UWR-DOC REPLACING ALL "l1mit" BY "limit", because LIMIT is a COBOL reserved word. Oy!) ....some short time later.... Ah hah, here's a trick. I don't love it, but I can perhaps live with it. I canspecify OCCURS 1 for any field that I want to be an element rather than an attribute: 01 underwritingrequest. 05 crossSellOfferId pic x(10) occurs 1. 05 channelType pic x(10) occurs 1. 05 preApprovedProds. 10 product. 15 categoryCode pic x(2). 15 l1mit pic 9(7). 05 parties. 10 party occurs 1 to 10 times depending on party-count indexed by p_idx. 15 dob pic 99/99/9999 occurs 1. 15 scoreNo pic 9(9) occurs 1. 15 income pic 9(9) occurs 1. 15 housingExpense pic 9(9) occurs 1. 15 housingStatus pic x(10) occurs 1. Funky, but it works. Of course I now have to use a subscript qualification (oran extra one, in the case of the "party" children. Oh well! If there's a better way I'd still like to know, but at least I got it to work. Thanks! Frank
Frank, That is really cool! How did you come up with that? I'm going to add that technique to my course "Enterprise COBOL: Unicode and XML Support". Thanks. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-355-2752 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
