Thanks for the valuable information. I plan to use the MODE C cmd in selected (10 or 20) z/os, or ZOS, or Z/OS R 1.12. IBM Mainframe(z196) batch jobs. These FTP's currently have an Elapse Time of 20 minutes to 3 hours using BLOCK Mode. With MODE C they use 6 minutes to 90 minutes. I never intended to modify any FTP of a TERSED file. I meant to state that MODE C can be faster and less of a resource hog that a terse, ftp, and then unterse. Bottom line, our batch will complete sooner and help insure we meet our SLA's. I also plan to put in place the new DSWAITTIME nn parameter.
I really enjoy the veritable plethora of in depth information provided by the many factotums and doyens on this SITE. David L. Mingee Principal Systems Administrator Indianapolis Production Control Data Center Operations / Operations Technical Support Work Ext 782-6460 Work Direct Dial 317 581-6460 Home 317 598-0919 / Cell 317 341-0885 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: Thursday, August 11, 2011 10:37 PM To: IBM-MAIN@bama.ua.edu Subject: Re: FTP Question Paul I recently saw - again I have to confess - a program where a character intended to be portrayed as habitually and incessantly argumentative was described in terms of it being very likely that if left alone he would immediately find a reason to argue with himself. If I see it again - it's not that bad a piece - I'll be able to tell myself that's what Paul Gilmartin must be like. In the light of observations such as this, it's useful to examine whether there is an attempt at pure mischief or it is genuine. So let us see what the original post was all about, shall we? After all the whole purpose of the list - as I thought - actually any of these lists as long as it's not VSE-L - is to provide a satisfactory and satisfying answer to the question as asked (- at least initially. There are some to whom creating tangential discussion becomes not so much incidental as an obsession - but we'll try to pass over them - well, we'll try.) > I am asking for opinions on the ramifications or value of using the MODE C > (compress) command within generic ZOS batch FTP. In my opinion pretty clear, wouldn't you agree? IBM wasn't actually specified but, hey, it is *IBM*-Main after all. So we've established it's IBM and it's z/OS (well ZOS, but I'm sure I'll be allowed the adjustment) and it's FTP, the FTP server supplied by the IP component of Communications Server. > ... the publication you cite would hardly be taken as authoritative. So quoting the manual which referred to the precise topic about which the question was posed is inappropriate. I'd like to know what <an extremely large number of expletives deleted> is appropriate. Well, I can't ask you obviously, so I'll have to direct my "what's your opinion?" to everybody else. Indeed IBM does use the word "compress" and "compact" in specific senses and because the context - as already established - was in the context of IBM products, I used this accepted - a barbed assertion! - terminology. I expect that the fact that the terminology was established for use with SNA products in the latish 1970s is the reason for the simulated irritation. "Compression" is just about as I described it while "compaction" is a further step which, come to think of it, is actually not all that much more processing-intensive. In fact, I could promote the idea that "compaction" is a relatively light-weight option for the novel since it is quite good for approximately halving the volume of data - on top of any benefit from compression. Thanks at least for prompting me to present "compaction" more accurately - and to recall where it is documented: Network Job Entry Formats and Protocols http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HAS2A620/11.4.2.3 Of course, I was delighted to note the "riling" potential in the second sentence in this other "parochial" reference: <quote> Note: Compaction is only done on SNA transmissions. </quote> Of course, it helps I used to teach this stuff once - and, moreover, I recall well the teacher who introduced it all to me, a charming Italian gentleman. - > FSVO (in a broader context than IBM's FTP) "compress" ... "Moby Dick" (a > novel; arguably text-rich). The statistics: > Compressed: 584,758 bytes > Uncompressed: 1,231,344 bytes On the basis of this argument, arguably "blank-rich". Was the original double-spaced for those who have difficulty reading single-spaced text? I'd say that was what the statistics supported, wouldn't you? Actually, being serious for a moment, I could guess - given this is all about what is meant by the word "compression" etc. - that the text had been subjected to both IBM's "compression" and "compaction". Maybe that's what your "broader context" is, and, taking the opportunity, the context for "compression" - and "compaction" - within IBM extends way beyond the FTP products. - > BTW, is "mode C" in an RFC nowadays? Well, you did ask! (")If you have a hat, prepare to eat it now!(") I cheated and used Wikipedia but it was just as good - and it reads believably - as using the RFC. http://en.wikipedia.org/wiki/File_Transfer_Protocol Under section "Protocol overview" we find the following at the beginning and the end: <quote> The protocol is specified in RFC 959, which is summarized below. ... Data transfer can be done in any of three modes: - Stream mode: Data is sent as a continuous stream, relieving FTP from doing any processing. Rather, all processing is left up to TCP. No End-of-file indicator is needed, unless the data is divided into records. - Block mode: FTP breaks the data into several blocks (block header, byte count, and data field) and then passes it on to TCP. - Compressed mode: Data is compressed using a single algorithm (usually run-length encoding). </quote> I must say that there is a smidgen of wriggle in that "usually". "Usually" is not a good word to find when the matter in hand is a communication protocol really quite sensitive to the precise interpretation of each byte of data as it comes in.[1] Anyhow "run-length encoding" is what I described in my initial response and is just another way of describing what IBM calls "compression" - which, incidentally, does rather seem by reference to the FTP RFC to have thrown off any cloak of parochialism, don't you think? FSVO "nowadays"! RFC 959 burst upon the unsuspecting world in 1985. I guess that might explain the failing eyesight suspected earlier! - [1] That "usually" bothered me a bit so I did check RFC 959, specifically section "Transmission Modes - Compressed Mode". That "usually" is rubbish - I should "fix" the Wikipedia article. The FTP "compression" is identical to IBM "compression" - with one slight proviso. If "it is understood" that the "compression" could be augmented by "compaction", it is required *not* to allow uncompressed data to be present in strings of up to 127 bytes, but only up to 63 bytes. FTP "compression" is *not* augmented by "compaction" whereas SNA "compression" could be. Chris Mason On Thu, 11 Aug 2011 18:03:39 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote: >On Wed, 10 Aug 2011 08:25:53 -0500, Chris Mason wrote: >> >> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b990/5 >> .44 >> >>Because compression is such a light-weight process - here a comparison with >>the heavy-weight processes compaction or encryption is valid! - it has a very >>small overhead. It causes a major reduction on the volume of data to be >>"moved" when the data consists of reports with a lot of "white space" - let's >>just say blank characters - and maybe lots of fancy lines of asterisks or >>maybe just hyphens to assist with the presentation of arithmetical >>calculations - that sort of thing. >> >Of course, these are parochial definitions of "compress" and "compact". >Elsewhere in the data processing community (there is such an >"elsewhere"), the publication you cite would hardly be taken as authoritative. > >>You would be "stark, raving" to consider compressing anything other than >>text. Text-rich text, a novel for example, would also be getting close to >>pointless. As for "tersed" data - perish the thought! >> >FSVO (in a broader context than IBM's FTP) "compress" I just >downloaded the Gutenberg Project's "Moby Dick" (a novel; arguably text-rich). >The statistics: > > Compressed: 584,758 bytes >Uncompressed: 1,231,344 bytes > >I'll fully agree (without trying the experiment) about "tersed" data. > >BTW, is "mode C" in an RFC nowadays? It's easy enough to find FTP >clients that don't support it. > >-- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
