Re: Writing XML from RPGLE

On 8/22/2014 11:02 AM, John Yeung wrote:

Scott eventually managed to port *and nicely package* p7zip (Unix
version of 7-Zip) for PASE. So you could switch to that. I've found
jar on the slow side, and its compression isn't the best. You can do
better on both counts with p7zip. (Of course be sure to stick to the
.zip format, not 7-Zip's own .7z format.)

In my tests, I've had problems with this. Has this worked for you? p7zip seems to use a newer version of the .ZIP specification than Microsoft does, and OFfice chokes on files created with p7zip.

Unless this was fixed on Office 2013? I haven't tried it with that version of Office, yet.

But, I've been using infoZip instead of 7-Zip for this reason. (JAR works too, but JAR is a bit slower.)

That's why I mentioned his pure RPG work. Last he wrote about it, it
was in the neighborhood of 60 times faster than his POI-based
approach. The only issue is I don't know how fleshed-out it is (so I
don't know what kind of formatting support it has, for example). He
hasn't released it yet, to my knowledge.

Yes, that's correct. My biggest problem with this right now is the .ZIP support, because I don't really want to require everyone who uses it to have PASE & InfoZip (Or Qshell & Jar) installed. The Zip APIs that IBM provided in 7.1 also won't work because they don't have a feature that allows paths relative to the current directory when generating the zip file.

I was working on getting MiniZip to work, have been having some CCSID problems with that. But if I can solve these, it would work well.

Biggest problem is that I don't have the time, especially since I have to spend so many hours each day working with my medical problems (about 5 hours) in addition to my full-time job. This doesn't leave as much time for open source work as I previously had.

Including reading? I guess I was never really clear on how much you
had to read existing data. Reading existing Excel files can be a much
greater challenge than writing an Excel file from scratch (because you
can control how many features you want to include when writing; but
typically cannot control how many features were used if you're doing
the reading).

That depends on why you're reading it. IF you just want to get the data out of the Excel sheet and put it into a PF or something like that, then it's easier than you might think. Excel puts stuff like formatting into separate XML files. So the one you have to parse to get just the spreadsheet data is not too complex. The only real complex problem is dealing with the shared string table...