How about a parameter to specify the code page conversions? Or can the output be an XMIT file so an XMIT viewer be used?
On Sun, Mar 14, 2021 at 9:02 AM Mario Bezzi <[email protected]> wrote: > > Andrew thank you. > > I agree on your point about keeping decompression and text conversion > separate. > > The kind of full text conversion which unterse may perform only applies > to text only files. Also for this limited use case, properly managing > mainframe code pages is impossible as the terse container doesn't carry > such information, and one can only guess. > > Making WWUNTERSE available we just wanted to share with the community > something we found useful in our day by day activity. > > I hope this helps, > mario > > On 3/13/21 11:33 PM, Andrew Rowley wrote: > > On 14/03/2021 2:32 am, Robert Prins wrote: > >> > >> Unlike PCTERSE the program and IBMs offering it doesn't do any > >> EBCDIC-ASCII translation... > >> > >> Why hasn't it been released as open source under the same license, > >> after all it's just decompression code, and given the note in the > >> User's Guide, > >> > >> "The decompress function of TERSE was recently ported to Java by IBM > >> and it is available under the Apache 2.0 license and is available > >> here. However, that program doesn’t support VBS format either." > >> > >> so that those with the knowledge can add features like EBCDIC-ASCII > >> translation, or incorporate the code into something with a GUI? > >> > > > > After a discussion with Mario at SHARE last year and some assistance > > since I have been working on updating the open source Java code to > > support variable length binary records. > > > > I have it working, I have just been very slow to update the > > documentation and contribute it back to the original repository. > > > > You can see my changes here: > > https://github.com/andrew890/tersedecompress > > > > What I would like to do is make it available as a class that can be used > > from other applications, not just a command line application. Some of > > the changes and refactoring have been done with that goal in mind. > > > > A secondary goal is a port to C# so it could run under .NET (Windows and > > other platforms). > > > > But *why* do you want it to translate EBCDIC->ASCII? The current > > implementation does that, but I haven't figured out why. It makes > > testing much more complicated. It seems like it would be much better to > > do the translation outside of an UNTERSE implementation, and have the > > compression code give you back exactly the same data that was compressed. > > > > Andrew Rowley > > Black Hill Software > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
