If Adobe PDF wasn't such a crappy format, it would be easy to program it to filter those grafs so you could select just the grande instructions (or whatever), the number of columns, etc. In the meanwhile, great example! This is indeed the kind of thing that makes it hard to use.
On Sat, Nov 15, 2014 at 3:00 AM, David Stokes <sto...@interchip.de> wrote: > Tom Marchant wrote: Please don't tell me or anyone else what I think. > > Well, you pretty well trashed every suggestion Tony Thigpen made (as well > as Fred.van.der.Windt's comments), adding " Clearly, there is no consensus > here that _any_ of the proposed changes are a good idea." so it certainly > sounded like it. > > Is "Yuck" in your view not hyperbole? Should we dismiss your opinions > because of this? > > > I certainly feel that a paragraph such as > > For COMPARE LOGICAL (CLR, CL, CLY), COMPARE LOGICAL IMMEDIATE (CLFI), and > COMPARE > LOGICAL RELATIVE LONG (CLRL), the operands > are treated as 32 bits. For COMPARE LOGICAL > (CLGR, CLG) and COMPARE LOGICAL RELATIVE > LONG (CLGRL), the operands are treated as 64 bits. > For COMPARE LOGICAL (CLGFR, CLGF), COMPARE LOGICAL IMMEDIATE (CLGFI), and > COMPARE LOGICAL RELATIVE LONG (CLGFRL), the > first operand is treated as 64 bits, and the second > operand is treated as 32 bits with 32 zeros appended > on the left. For COMPARE LOGICAL IMMEDIATE > (CLHHSI), the operands are treated as 16 bits. For > COMPARE LOGICAL IMMEDIATE (CLFHSI) and > COMPARE LOGICAL RELATIVE LONG (CLHRL), > the first operand is treated as 32 bits and the second > operands is treated as 16 bits with 16 zeros > appended on the left. For COMPARE LOGICAL > IMMEDIATE (CLGHSI) and COMPARE LOGICAL > RELATIVE LONG (CLGHRL), the first operand is > treated as 64 bits, and the second operand is treated > as 16 bits with 48 zeros appended on the left. For > COMPARE LOGICAL IMMEDIATE (CLI, CLIY), the > operands are treated as 8 bits. > > could be expressed somewhat better. > > > > > -----Ursprüngliche Nachricht----- > Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > Im Auftrag von Tom Marchant > Gesendet: Freitag, 14. November 2014 21:31 > An: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Betreff: Re: Redesigning the Principles of Operation Manual > > On Fri, 14 Nov 2014 19:34:52 +0100, Fred.van.der.Windt wrote: > > >Could't agreement more: the two columns are a nightmare. > > Nightmare? I understand that many don't like it. Maybe most don't like it. > I don't know, maybe Mark and I are the only ones who like it for this > manual. > When I see hyperbole such as this, my tendency is to dismiss the opinions > that are expressed. > > >I'm puzzled by the strong reactions this thread evokes. > > Does that include your own strong reaction, where you refer to the two > column > format as a "nightmare"? > > >To me it is so obvious that the current format does not work as a PDF (or > similar format). > > "It is obvious." Does that mean that anyone who disagrees is an idiot? > When you express your opinion and your preference as fact, you undermine > your credibility. I understand that you don't like it. Perhaps you dislike > it so > much that it doesn't work for you. It does work for me. In fact, it works > rather nicely for me. > > >The various suggestions and ideas just show that need some kind of > dynamic, > >configurable format with several ways to locate and display the > information > >(an app is an excellent idea). > > The suggestions show a desire, which is different from a need. > > >It amazes me that there are actually people that think the current format > >is just fine and doesn't need any improvement... > > I never said that. Please don't tell me or anyone else what I think. > > -- > Tom Marchant > -- zMan -- "I've got a mainframe and I'm not afraid to use it"
