I love programming as it gives me the illusion that almost everything is
possible. So yes, we may add code to perform text conversion using
multiple code pages, or generate the output in XMIT format.
The only question I have is: Would this help us pay the bills?
:-)
Thank you,
mario
On 3/14/21 5:13 PM, Mike Schwab wrote:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
