0

I need to generate a xml file from a complicated COBOL structure (mainframe). I cant use the XML GENERATE cobol function because the data tree is too big to fit in the W-S (about 8 nested arrays, each with about 75 occurrences of 30 bytes), so there is no one group item to pass to the xml generate function.

The only option i can think of is generating the xml "manually" by going through the hierarchy on the needed adabas tables level by level and filling the file, the problem for me with this option is that I don't know how to go over the file again each time and "Nest" the next node.

Is there a better way?

The data is coming from ADABAS tables, and i can also work with natural, is there a better solution using natural? from what i know natural doesn't allow nesting more than 3 levels, which is a problem for me.

Thank you!

zohar mizrahi
  • 31
  • 1
  • 5
  • 1
    You'd better illustrate your data better. Other than by name, you are not describing a nested structure. – Bill Woodger Aug 24 '16 at 14:58
  • IBM COBOL 6.1 limits Working-Storage to 2,147,483,646 bytes, a single 01 level can be 999,999,999 bytes. In IBM COBOL 4.2 these limits are both 134,217,727 bytes. Are you sure you have more than 128 megabytes of data? – cschneid Aug 24 '16 at 15:01
  • Hi, yes, we are using the 134,217,727 bytes ver. And i am sure my data is more, i get a compilation error saying its bigger than 134,217,727. (i am building a tree, although that the data that will be stored inside is probably less than 128 mb, the structure must fit the worst case, and it exceeds the limit. . . . . . . . . . . . . . . . . . . Bill, the xml should represent a tree with up to 8 levels each node has its attribute and the tree represents a hierarchical structure of a company. Thanks – zohar mizrahi Aug 24 '16 at 15:24
  • 5
    1. You need to provide the description of your Adabas files and the logic of your apparently hierarchical recursive query, otherwise it's impossible to suggest anything. 2. I would question the design that puts that much data in a single XML document. If and when you solve your XML generation problem, you (or someone else) will immediately face the problem of processing this monster. – Yuri Steinschreiber Aug 24 '16 at 17:41
  • What exact COBOL version do you use? Compiler and runtime limits and the option to use newer statements often differ... You may want to look at `OCCURS UNBOUNDED`. The example in IBM's [Programmer's Guide](http://publibfp.boulder.ibm.com/epubs/pdf/igy6pg10.pdf) - page 92 is exactly about XML progressing. ... in any case it is likely a better Idea to split the file into multiple ones, not because of COBOL but because of the resulting file (which will likely only be possible to access in stream-mode). – Simon Sobisch Aug 24 '16 at 18:28
  • 1
    And how are you going to get the data out of your program? You know the limits on record sizes, don't you? – Bill Woodger Aug 24 '16 at 20:48
  • @SimonSobisch the OP is using a compiler that doesn't implement OCCURS UNBOUNDED. – cschneid Aug 25 '16 at 13:52
  • @BillWoodger The OP can CALL 'FOPEN' (FWRITE, FCLOSE) rather than use COBOL I/O to get around the 32K limit for traditional files and the 1M limit for LINE SEQUENTIAL files. – cschneid Aug 25 '16 at 13:55

4 Answers4

1

I can not give a definite answer; Some comments:

  • Is one big XML structure the only way to go ??? Most Xml utilities will struggle with this sort of monolithic XML.
  • A XML Streaming Solution will work better / be more maintainable than writing the full XML structure in the one Go.
  • Have you looked at a Commercial Utilities e.g. XML Thunder, from memory there are others as well. I can not comment on how good they are how much they cost.

I wrote a Cobol to XML utility in Java. It takes a Cobol Data File + a Cobol Copybook and Converts it to XM. The utility allows you to define a Hierarchy among the different Cobol-Records so instead using nested Arrays you use "nested" Cobol-Records. My Cobol to XML utility may struggle with the size of your copybooks. But this sort of utility is fairly easy to write.

It should be reasonably easy to replicate my Cobol to Xml utility by

  • Generating a Cobol Program to write the Xml (in a streaming fashion) from the Cobol Copybook's
  • Write a general Purpose Cobol File ==> Xml program.

For either solution, I would use a formatted version of the Cobol-Copybook e.g.

  • Field-Map produced by the Cobol Compiler.
  • File-Aid Copybook listing
  • cb2xml if using a scripting language to generate the Cobol program

This answer is not related to your problem but it is does demonstrate what can be generated from a Cobol Copybook. In this case he generated:

  • A text-Cobol-Copybook from a Binary Copybook
  • Code to convert the Binary Indexed file to a Flat text file
  • VBA code to generate the Data-Bases
  • VBA code to load the Cobol-Data file in the the DB
Community
  • 1
  • 1
Bruce Martin
  • 10,358
  • 1
  • 27
  • 38
0

So two thoughts:

  • Have your code "hand generate" the XML if necessary.
  • Break your tree up into subtrees if possible.
Martin Packer
  • 648
  • 4
  • 12
  • i cant break the tree because the structure must be as a whole. so probably "hand generating" is the only option. but what is the right method to do this? a file? if so then how do i add rows in the middle of the file- i dont think its possible.. and if i should build a huge string' how do i implent data in the middle of a string? – zohar mizrahi Aug 25 '16 at 11:03
0

The Redvers COBOL XML Interface uses an iteration point and multiple calls to the generator subroutine for very large and complex copybooks. You'd move an initial set of data to the copybook, CALL, then move the next set of data and CALL again. The XML output is obviously going to be a very large string but you can unload this too in managable chunks.

Shady Dave
  • 1
  • 1
0

I have just done something like this for a customer. Obviously I am not able to post their code here, but maybe an outline of what we did...

Firstly, we created a JSON-like structure: a Natural X-Array Group containing 3 fields:

nson         (1:*)  /* X-Array
level-number (I1)
tag-name     (A) DYNAMIC
tag-value    (A) DYNAMIC

(we used -ve level-number to signify - 0:n - XML-Attributes for the preceding +ve level)

To fill the X-Array we used a Global-Data-Area from a Natural Subprogram & Natural External Subroutines (using call-by-value & optional parameters) together with a few Natural Functions for typical data-transformations (e.g. packed or Date variables to String)

The result was Natural Code that resembled XML, for example:

perform XML-at   2  'node-name'                      /* ABSOLUTE Level
perform XML-this    'tag-name'          'tag-value'  /* Relative Level
perform XML-this    'node-name'                      /* Relative Level
perform XML-next        'tag-name'      'tag-value'  /* Relative Level
perform XML-prev    'tag-name'      P3(<-17.123>)    /* Relative Level & Function for (Pnn.3)

Then we posted this via Natural-RPC to a Java Service, which built XML from it.
(in our case we used the XML Server-side, but you could return it to Natural in a DYNAMIC variable)

Dave The Dane
  • 650
  • 1
  • 7
  • 18