PR108? IBSYS? The early manuals had tons of examples - some were even correct.
I disagree on authorship; manuals should be written by a team of people who know how it actually works and tech writers who know how to make it clear to a broad audience without being wrong, ambiguous or incomplete. Somebody from Library Science to help with the index wouldn't hurt. The reviewers should include lots of unsophisticated users. I find that with decent software, online reading is easier than dead trees. However, if I ever get into weight lifting I'll order a paper copy of PoOps. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of [email protected] <[email protected]> Sent: Thursday, October 16, 2025 10:41 AM To: [email protected] <[email protected]> Subject: Re: Newer SYSPROGs (was Re: Political topics) External Message: Use Caution >......read the manual!!! I have been reading the manuals since PR108 days (for those who remember that one — before S/360 days) and there have been significant differences through the years. 1. A few rather small manuals (even in early S/360 days) were helpful. Now, they measure by the ton or the millions of pages. It simply is not practical to read them all, or half of them, or a quarter of them, etc..... 2. Perhaps because of my age, but I often find some "real paper" manuals to be much more helpful than thousands of screens full of material that seems to vanish when I might try to find it again. 3. Many of the earlier manuals (especially the earlier RedBooks) often had more practical advice about how to use it. (Whatever the "it" subject happened to be at the moment.) Current manuals seem to focus on the syntax of command lines/parameter lines/macro operands/etc. This is important, of course, but it tends to skip details about various practical examples in a fuller environment. This "fuller" environment could include other products, useful code, interfaces with "real" TSO/batch/networks/debugging/recovery/etc/etc, and how to "get started.". . . 4. IMO, manuals (or at least some of the manuals) should be written by actual users, not by the developers of whatever product is involved or by "information writers" who might have no experience actually using the product. Users and product developers very often see a product in different ways!!! And, IMO, most manuals should be written for actual users of the products. 5. With so many manuals, and so many detailed topics, somewhat obscure titles, and the seemingly continuous rearrangement of how something might be found on the web, "read the FM" might not be very practical advice. As several people have already commented, "which manual?" can be a difficult question. 6. Some of us have too many years of experience. How many years of practical work does it take to create that experience? We must make allowances for anyone trying to get started with sysprog topics. (And, these days, anyone foolish enough to focus on assembly programming probably falls into the general "sysprog" category.) 7. IMO, it might be a good idea to have real customers/users evaluate the quality of product manuals, rather than any evaluation related to the number of pages produced. [I realize this is an odd idea.] 8. Information found on the web might be good and useful ....or it might be bad, or wrong, or crazy, or part of a marketing push, etc, etc. Of course, this characteristic of the web is not unique to "computer stuff." My $.02 worth.....if it is even worth that much. Bill Ogden ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
