Paul, Happily I kept this post for review - actually just before an intended purge.
I see that the URL for a "Contents" page requires only the text up to, but not including, "/CCONTENTS". The text from and including "/CCONTENTS" may be ditched. That's useful to know - and if I was awake I should have tried it. Thus the "wrap" is less likely. Thanks Chris Mason ----- Original Message ----- From: "Paul Gilmartin" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 06 March, 2006 9:42 PM Subject: Re: Manual References in Posts (was Update a module in LPA ?) > In a recent note, Chris Mason said: > > > Date: Mon, 6 Mar 2006 20:35:59 +0100 > > > > Bruce here is pure goodness in providing just the needed manual reference. > > > My thanks, also, to Bruce and others who do likewise. Even a document > number helps. > > > What isn't quite pure goodness, in my opinion, is that it's a PDF file. It's > > much faster to provide the CONTENTS page of the "book" rather than a PDF. > > For example, for z/OS V1R7.0 MVS System Commands it's > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G160/CCONTENTS?SHELF=EZ2ZO10F&DN=SA22-7627-12&DT=20050714212238 > > > Actually, it's intact as served by bama.ua.edu. So your MUA, any intervening > MTAs (poor Charlie), and LISTSERV are friendly to it. No representations > made for any recipient software. > > > which I expect will need a "watch the wrap" warning. It may be friendlier to > > specify an URL which the list server system will not cut such as - praying > > <g>: > Why do they do that? From RFC 821: > > 4.5.3. SIZES > > There are several objects that have required minimum maximum > sizes. That is, every implementation must be able to receive > objects of at least these sizes, but must not send objects > larger than these sizes. > [ ...] > > text line > > The maximum total length of a text line including the > <CRLF> is 1000 characters (but not counting the leading > dot duplicated for transparency). > > Here, though, IBM shares the blame. The VM/CMS implementation of SMTP > (optionally) used virtual readers and punches as a Mail vehicle, thus > enforcing (in violation of RFC 821) an 82-character limit. > > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2CMZ60 > > We'll see if that worked required a cut or not. > > > Which isn't the same. Perhaps: > > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G160 > > > Having got to the Contents page, a simple Edit-Find for the section title - > > if no lower than 3 levels perhaps - will locate the wanted information. If > > that's not appropriate, the "library" system provides a Search function. > > > Amen. > > > For those who are keen PDF users, I know Acrobat has a pair of binoculars > > but I don't think I'm alone in finding the "library" Search somewhat faster > > and easier to use. > > > Unless the resource costs of bandwidth, contention, and latency > are deemed inconsequential. > > Vive la Bookie! A bas PDF. Please, IBM, don't switch. > > -- gil > -- > StorageTek > INFORMATION made POWERFUL > > > -- > StorageTek > INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
