Thanks. I remember SCS! I've written a couple of 3270 emulators. SCS was
used for 3270 printers, right?
Does not look quite right. As I recall, cccccc = 0 is illegal, right? Here
is the beginning of some compressed data:
80 7f 00 01 00 02 00 03 00 04 00 05 ... so cccccc is 0.
Circumstantial evidence indicates that the uncompressed data might be 00 01
00 02 ... so perhaps 807f says "7f bytes of uncompressed data follow."
Yes, I could dump the compressed data, build test cases, etc. but I have not
done that. It's inside a program so "dump the uncompressed data" is a
program change. I was hoping that someone had already done that and knew and
was willing to share.
I found the problem so the urgency is off. I know that in some cases I have
only part of a compressed record. This is a known and acceptable condition.
It appears the 16 ("not compressed by CSRCESRV") is actually "your
compressed input data ends at an illogical point." I have a possible
work-around.
Thanks again.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Tony Harminc
Sent: Monday, June 10, 2013 5:42 PM
To: [email protected]
Subject: Re: Anyone familiar with how z/OS CSRCESRV works?
On 10 June 2013 19:58, Charles Mills <[email protected]> wrote:
> Is anyone familiar with the "internals" of CSRCESRV run-length
compression?
> I am familiar with RLE schemes in general -- typically a run of n
> identical characters is replaced with something like
> <escape><n><character>. Does anyone know the specifics of z/OS's scheme?
What is the escape character?
> How is <n> specified? Is it <escape><n><character> or
> <escape><character><n>. How do they handle occurrences of <escape> in
> the original data? (A typical scheme is <escape>1<escape>.)
I don't know, but without looking I'd guess it's SNA Character String
(SCS) format, or perhaps part of it. The first byte would be a String
Control Byte (SCB), with the leftmost two bits indicating what follows, and
the rightmost six containing the length of the run of data. Of course there
might well be higher level header info.
00 cccccc No compressed characters follow
10 cccccc Repeat blanks
11 cccccc Repeat the following non-blank character
01 cccccc Compacted characters follow
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
