- My first attempt was not to generate code at all but to dynamically process the XML generated by CB2XML at run time to access/build the COMMAREA. Some of the XML generated by CB2XML could be very large (120K or more). This performed very poorly and was just plain ugly.
- I generated code for every field in the copybook (both setters and getters). While this performed okay the generated code could be huge, two or three times the size of the copybook.
On everything I tried I had lots of problems with groups, overlays, OCCURS and especially OCCURS DEPENDING ON structures.
Based on a suggestion from Scott, I focused on creating a byte array that just described each field in the copybook, but did not store any of the data. Its data type, signed/unsigned, precision, scale, length, position, OCCURS, OCCURS DEPENDING ON and the fields relationship to its owning group could all be stored in as little as 24 bytes. To store the values, I created a string that was the length of the COMMAREA and I would “set” or “get” the values directly in the string. The code for setting and getting the fields was static and the same for all copybooks; it just used the field description to convert the data into the proper format whenever you set or got a field. It performed very well. . . for a while.
The StringBuffer constructor creates an object with a static piece of storage. Through the use of its methods, I could update as many times as needed without causing additional storage to be allocated. I updated my scripts to use StringBuffer and performance started to fall in line with my expectations. I found other places where I had gotten sloppy with my use of strings (lots of unnecessary concatenations/manipulations); after I cleaned those up CopybookToCode was a regular rocket.
On occasion I still work on CopybookToCode, adding new features or fixing minor issues. I am in the process of changing the way the generated files are returned. Right now you have to click on each generated file you want to download; soon a zip file containing all of the files will automatically download at the conclusion of the generation (of course I told Scott we needed zip support in HB.js for a customer . . . and he bought it).
It occurs to me after writing all of this you may not have a clear picture of how all of this comes together, so one more blog post on CopybookToCode to draw it out for you.