Terry Along with AFAIK - "as far as I know" - perhaps it's time to invent JOTTOMHWHBTDAR - "just off the top of my head without having bothered to do any research".
Having read only your first sentence, I called up http://www.redbooks.ibm.com/ and started checking. When I got to the 4th "hit", I found SG24-6351-03 which happens to be "Threadsafe Considerations for CICS", not that it matters. > Redbooks once published are not updated. So that's a "holed below the waterline"! > There are no dash numbers ... I could excuse "no dash numbers" if there are only ever "-00" "dash numbers" since the "dash numbers" are an integral part of the IBM "form number" scheme. I also thought I had to do my research because the most recent redbook I have been using which I knew had a non-zero "dash number" is "Inside APPN and HPR - The Essential Guide to New SNA", SG24-3669-03. But it is rather old, 1997 - not that that fact detracts in any way whatsoever from its content. Then I remembered that I often refer to the "OSA-Express Implementation Guide" which has attained the heady heights of "-05", SG24-5948-05, and is only 18 months old. Given that its "companion" regular manual, "Open Systems Adapter-Express Customer's Guide and Reference", has a new edition this year, SA22-7935-11, August 2010, with a couple of potentially handy performance enhancemements that look like they might benefit from an expanded explanation and even a "sandbox workout", I expect we might see yet another increment to the "dash number" any time soon. Time to launch the lifeboats I think! > ... or TNLs. Long ago when redbooks didn't have backs - I think we're talking mid-'80s or even earlier here and we're talking the original name WTSC rather than ITSO - and were three-ring binder fodder in the same way as regular manuals, TNLs, the curse of the conscientious technical support wallah, made sense. With glued backs, TNLs do not make sense and the options are 1. get it right first time, the frequent failure of which is down to supposed typically development reviewers not actually being given the mission or time to support this peripheral activity - and we all know who's to blame there ... 2. just hold fire until it's time for the next update - normally I would have thought with the same "form number" - which will happen if the topic has a future > A new Redbooks on the same or similar subject has a completely new number. My metaphor is breaking down since I can only think of one involving digging and you don't dig water! > These are only done when a major change to the subject requires it and the lab that develops the product wants a new Redbook. I guess whether a new "form number" or a new "dash number" is used is down to a flipped coin on the thumbnail of the "suit" in charge of the topic in the ITSO centre - or should that be center. > Error should be trapped at the draft stage before publication. See above. Actually, I see that "draft" redbooks appear on the redbook site and I even tried to get one, the CCL one - now SG24-7223-01 - mainly with the objective of purging the "howlers" in the first edition - but I was too late apparently. Probably, there ought to be a system whereby parties likely to be relevant to a review, other than development, could be alerted to a new "draft" - often for a new "dash number" in all likelihood - having appeared. > If not then they will remain for the life of the Redbook. Without TNLs, inevitable - and it happened when WTSC/ITSO discovered glue. > I have been involved in several Redbooks. Probably, the particular ITSO center responsible for the topic in which you would appear to be an acclaimed specialist had an ecologically unsound policy regarding "form numbers"! > I always say the product manual is the definitive source of information on the subject. This is the *legal* "party line", if not regrettably always reliably true. Going back to my original point, "Google is your friend". I recently discovered an interesting and highly relevant fact about a product function which had existed since the mid-'90s but was documented as "new" only this September in z/OS V1R12. What it actually revealed was that IBM had been using an API function which was "safe" only when the two participating components were "in step" and what was new was removing this requirement, not the function itself. The "fact" was revealed - "by accident" - in the notes to another enhancement in the presentations that seem to go along with new z/OS releases.[1] Given my interests, I am obviously talking about the two sides of Communications Server. Moral: the "definitive" source of information is what the product actually does. This was the "source" I used for my classes but thankfully in those days I had sufficient "sandboxes" to verify what I taught. Today, all I can do is weigh the evidence put to me by various advocates, among whom the authors of the regular, product, manuals are given a prominent - but not overriding - place. Before signing off, it's worth supporting your general position that regular, product, manuals are written by people whose "day job" it is to "get it right" whereas redbooks are written by people who have other jobs and are drafted in to put some typically "how to" material together that is likely to be beyond the wit or remit of the authors. It irritates me what contributors to this list seem incapable of making this key distinction. Perhaps they have yet to enjoy the priviledge of actually working up and writing a redbook. Chris Mason [1] http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/index.jsp On Sun, 7 Nov 2010 12:50:03 +0000, Terry Draper <w...@btopenworld.com> wrote: >Redbooks once published are not updated. There are no dash numbers or TNLs. >A new Redbooks on the same or similar subject has a completely new number. These are only done when a major change to the subject requires it and the lab that develops the product wants a new Redbook. >Error should be trapped at the draft stage before publication. If not then they will remain for the life of the Redbook. >I have been involved in several Redbooks. I always say the product manual is the definitive source of information on the subject. > >Terry Draper >zSeries Performance Consultant >w...@btopenworld.com >mobile: +66 811431287 > >--- On Sun, 7/11/10, Ed Gould <ps2...@yahoo.com> wrote: > > >From: Ed Gould <ps2...@yahoo.com> >Subject: REDBOOKS Question >To: IBM-MAIN@bama.ua.edu >Date: Sunday, 7 November, 2010, 4:05 > > >I have forgotten the answer to this question long ago and I am not coming up with any answer to my question to myself.I will pose it to the group and see if anyone on here knows the answer.I am trying to remember how IBM handles it if there is an error (or poorly written or whatever error) happens with REDBOOKS. >Are they quietly updated (and if so) is there a new dash number or is there a completely new number assigned or how does IBM handle updates to any REDBOOKS? I know there are errors as long time ago (30+ years) I used to see them with TNL's (we all remember those right?) but I do not remember how IBM handles them currently. Anyone? ---------------------------------------------------------------------- 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
