I like your suggestions.
I'd vote for them if IBM were of a mind to take a poll.

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration
EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275
Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230
[email protected] | www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On 
Behalf Of Tony Thigpen
Sent: Friday, November 14, 2014 9:04 AM
To: [email protected]
Subject: Re: Redesigning the Principles of Operation Manual

After thinking about this for a few days, the biggest 'complaint' I have 
with the POP is the two columns. It makes me have to scroll up and down 
just to read the end of the paragraph that started at the bottom of the 
left side.

The second issue is the way the "if 24bit, if 31 bit, if 64bit" 
statements read.

Suggestions:
1) Make each group of instructions (like ADD) start on a new page.
2) Use two columns for the instruction bit pictorials. Put 24/31 bit on 
the left and 64 bit on the right.
3) Use a full width paragraph for things common to both 24/31 bit and 64 
bit.
4) Use the left column for 24/31 bit specifics and the right column for 
64 bit specifics. These groups are side by side for the same 'subject'. 
If there is no 64 bit specifics, then leave a gap in the right side.
5) If possible, consider placing the simple examples directly after the 
instructions.

Tony Thigpen

Paul Gilmartin wrote on 11/14/2014 08:41 AM:
> On 2014-11-13, at 14:48, John Ehrman wrote:
>
>> As others have noted, the PoP is quite large and dense.  Changing the
>> formatting would be a significant effort.
>>
>> The z Architects are always very busy, and I suspect would have difficulty
>> finding resources needed to adopt any of the suggestions on this list.
>>
> A variant of "We're too busy coding to document."
>
> -- gil
>
>

Reply via email to