Re: Anyone familiar with how z/OS CSRCESRV works?
Charles,
hereby a piece of code I used (c++).
input char_compressed, output char_decompressed, input
max_ll_char_decompressed
Hope this helps and sorry for comments in italian language.
Best regards.
Massimo Biancucci
/* -- */
/* Esegue decompressione RLE come da macro CSRCESRV */
/* ci si aspetta di avere una stringa compressa in tal maniera*/
/* in output la stringa su output e la lunghezza del buffer di uscita */
/* se 0 abbiamo incontrato un errore*/
/* -- */
short rle_decode(char *input, char *output, unsigned short ll_i )
{
unsigned short i, j, i_i, i_o, i_copy;
char car;
if (input[0] ^= 0x80)
{
printf(Errore in rle_decode - Il buffer non e' compresso con rle);
return -1;
}
i_i = 1;
i_o = 0;
while (i_i ll_i)
{
i_copy = input[i_i] 0x7F;
if ((input[i_i] 0x80) == 0x80) /* si tratta di una ripetizione */
{
car = input[i_i + 1];
for (i = 0; i i_copy; i++)
{
output[i_o + i] = car;
}
i_o = i_o + i_copy;
i_i = i_i + 2;
}
else /* si tratta di fare una copia dei prossimi bytes */
{
for (i = 0; i i_copy; i++)
{
i_i++;
output[i_o + i] = input[i_i];
}
i_i++;
i_o = i_o + i_copy;
}
}
return i_o;
}
2013/6/11 Charles Mills charl...@mcn.org
Thanks. Yes, the compressed data clearly starts out with 80 followed (in my
case) by a run count 7f of uncompressed characters. After that, I can kind
of see some pattern but I am a long way from totally figuring it out. It
would take some real experiments to do so (as opposed to my just looking at
my existing data) -- or a post here or a private note from someone who has
already done those experiments.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Massimo Biancucci
Sent: Tuesday, June 11, 2013 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone familiar with how z/OS CSRCESRV works?
Hi,
in the past I had to look at such a tricky because CICS write SMF with RLE
if requested and I had to uncompress data on a PC.
The compressed buffer must start with x'80' else it's not compressed with
RLE (so the first character must be x'80' and you have to analyze from the
second one for the real string).
The escape character should be (once again) x'80' and the maximum length
for
the repeat-count is one byte (max=255) .
I'm not sure at 100%, it was a long ago.
Hope this helps.
Best regards.
Massimo
2013/6/11 Charles Mills charl...@mcn.org
Is anyone familiar with the internals of CSRCESRV run-length
compression?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone familiar with how z/OS CSRCESRV works?
Grazie. Nessun problema. Posso leggere un po d'italiano.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Massimo Biancucci
Sent: Monday, June 17, 2013 11:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone familiar with how z/OS CSRCESRV works?
Charles,
hereby a piece of code I used (c++).
input char_compressed, output char_decompressed, input
max_ll_char_decompressed
Hope this helps and sorry for comments in italian language.
Best regards.
Massimo Biancucci
/* -- */
/* Esegue decompressione RLE come da macro CSRCESRV */
/* ci si aspetta di avere una stringa compressa in tal maniera*/
/* in output la stringa su output e la lunghezza del buffer di uscita */
/* se 0 abbiamo incontrato un errore*/
/* -- */
short rle_decode(char *input, char *output, unsigned short ll_i ) {
unsigned short i, j, i_i, i_o, i_copy; char car; if (input[0] ^= 0x80)
{
printf(Errore in rle_decode - Il buffer non e' compresso con rle);
return -1;
}
i_i = 1;
i_o = 0;
while (i_i ll_i)
{
i_copy = input[i_i] 0x7F;
if ((input[i_i] 0x80) == 0x80) /* si tratta di una ripetizione */
{
car = input[i_i + 1];
for (i = 0; i i_copy; i++)
{
output[i_o + i] = car;
}
i_o = i_o + i_copy;
i_i = i_i + 2;
}
else /* si tratta di fare una copia dei prossimi bytes */
{
for (i = 0; i i_copy; i++)
{
i_i++;
output[i_o + i] = input[i_i];
}
i_i++;
i_o = i_o + i_copy;
}
}
return i_o;
}
2013/6/11 Charles Mills charl...@mcn.org
Thanks. Yes, the compressed data clearly starts out with 80 followed
(in my
case) by a run count 7f of uncompressed characters. After that, I can
kind of see some pattern but I am a long way from totally figuring it
out. It would take some real experiments to do so (as opposed to my
just looking at my existing data) -- or a post here or a private note
from someone who has already done those experiments.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Massimo Biancucci
Sent: Tuesday, June 11, 2013 9:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Anyone familiar with how z/OS CSRCESRV works?
Hi,
in the past I had to look at such a tricky because CICS write SMF with
RLE if requested and I had to uncompress data on a PC.
The compressed buffer must start with x'80' else it's not compressed
with RLE (so the first character must be x'80' and you have to analyze
from the second one for the real string).
The escape character should be (once again) x'80' and the maximum
length for the repeat-count is one byte (max=255) .
I'm not sure at 100%, it was a long ago.
Hope this helps.
Best regards.
Massimo
2013/6/11 Charles Mills charl...@mcn.org
Is anyone familiar with the internals of CSRCESRV run-length
compression?
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: anyone familiar with how z/OS CSRCESRV works?
Apologies if this is a duplicate post; I sent this a couple of days ago but never saw it in the digest. Note that this is not an interface, nor a commitment that it will stay this way forever; there is no current activity that would lead one to think a change is forthcoming. This is from the module: Each run is composed of a Substring Control Byte (SCB) followed by 1 to 127 text bytes. For non-repeat runs, the SCB contains a count of the number of text bytes that follow, with a high order bit of '0'B, followed by that number of bytes of text - -- |0 n| byte 1 | byte 2 | byte 3 | | byte n | - -- Where n is the number of non-repeat bytes in the run. For repeat runs, the SCB contains a count of the number of repeated bytes th string represents, with a high order bit of '1'B, followed by a single copy of the repeat byte. --- |1 n| byte 1 | --- Where n is the number of repeat bytes in the run. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: anyone familiar with how z/OS CSRCESRV works?
Peter, thanks much, you are always so helpful. Very similar to SNA SCS. I am going to guess ... with the block being prefixed by a single x'80' indicating 'this data is CSRCESRV compressed.' That's what threw me off in my half-hearted attempts to decode the scheme. This is helpful -- knowing that (for now at least) the longest possible run will be 127 bytes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, June 13, 2013 6:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: anyone familiar with how z/OS CSRCESRV works? Apologies if this is a duplicate post; I sent this a couple of days ago but never saw it in the digest. Note that this is not an interface, nor a commitment that it will stay this way forever; there is no current activity that would lead one to think a change is forthcoming. This is from the module: Each run is composed of a Substring Control Byte (SCB) followed by 1 to 127 text bytes. For non-repeat runs, the SCB contains a count of the number of text bytes that follow, with a high order bit of '0'B, followed by that number of bytes of text - -- |0 n| byte 1 | byte 2 | byte 3 | | byte n | - -- Where n is the number of non-repeat bytes in the run. For repeat runs, the SCB contains a count of the number of repeated bytes th string represents, with a high order bit of '1'B, followed by a single copy of the repeat byte. --- |1 n| byte 1 | --- Where n is the number of repeat bytes in the run. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Anyone familiar with how z/OS CSRCESRV works?
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 escapencharacter. Does anyone know the specifics of z/OS's scheme? What is the escape character? How is n specified? Is it escapencharacter or escapecharactern. How do they handle occurrences of escape in the original data? (A typical scheme is escape1escape.) Thanks. I'm getting a 16 from CSRCESRV SERVICE=EXPAND and I am trying to debug. The data *is* compressed by CSRCESRV but I am obviously fouling something up. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone familiar with how z/OS CSRCESRV works?
On 10 June 2013 19:58, Charles Mills charl...@mcn.org 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 escapencharacter. Does anyone know the specifics of z/OS's scheme? What is the escape character? How is n specified? Is it escapencharacter or escapecharactern. How do they handle occurrences of escape in the original data? (A typical scheme is escape1escape.) 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 cc No compressed characters follow 10 cc Repeat blanks 11 cc Repeat the following non-blank character 01 cc Compacted characters follow The above is from the NJE Formats Protocols book, but it's documented in lots of places, including non-mainframe ones. It should be pretty easy to check my guess against your data - certainly if you have raw and compressed data to compare. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone familiar with how z/OS CSRCESRV works?
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, cc = 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 cc 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:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, June 10, 2013 5:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Anyone familiar with how z/OS CSRCESRV works? On 10 June 2013 19:58, Charles Mills charl...@mcn.org 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 escapencharacter. Does anyone know the specifics of z/OS's scheme? What is the escape character? How is n specified? Is it escapencharacter or escapecharactern. How do they handle occurrences of escape in the original data? (A typical scheme is escape1escape.) 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 cc No compressed characters follow 10 cc Repeat blanks 11 cc Repeat the following non-blank character 01 cc Compacted characters follow -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
