Actually so would I. But that would be a different manual, with a different purpose.
Joey -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Ward Able, Grant Sent: Thursday, November 13, 2014 4:52 AM To: [email protected] Subject: Re: Redesigning the Principles of Operation Manual I could not disagree more, Joey! PRECISE yes, but it does not need to be concise. I have always believed that it is too terse and could do with and upgrade. Mervyn's suggestions are a good starting argument and I, for one, would really enjoy a much more modern POPS manual, which has more verbose descriptions and examples. Regards – Grant. Telephone Internal: 201496 (London) Telephone External: +44 (0)207 650 1496 -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Capps, Joey Sent: 12 November 2014 22:15 To: [email protected] Subject: Re: Redesigning the Principles of Operation Manual Personally I don't think it's design was to save paper. I think it was to 'be concise'. And that is what I think it needs to be. As for reorganizing it into different chapters, that might be useful. But we cannot afford to have it lose its concise nature. Joey -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Melvyn Maltz Sent: Wednesday, November 12, 2014 4:04 PM To: [email protected] Subject: Redesigning the Principles of Operation Manual One can see why the Principles of Operation manual (PoP) was designed in its present format...to save paper. There is now no need to design this manual in a form that was suitable 30 years ago. Now that I've restarted teaching Assembler I realise that the PoP neither serves the professional learning new instructions or techniques nor the student learning for the first time. The suggestions below have been compiled by myself and contacts and are not in any priority order. I offer these in order to stimulate discussion. I know IBM monitor this forum as I see names that I know. IBM can join in as well. 1) Instruction descriptions Every instruction must be individually described. No more bunching. 2) Two Manuals ---PoP1 describes formats and techniques ---PoP2 describes instructions and examples Hyperlinks to similar instructions and examples. 3) Classification The current classification is inadequate, ie. CVD isn't a decimal instruction...there are many others. If you have to classify, then here is a suggestion... 1) Boolean...AND/OR/XOR 2) Branch....BRANCH and PROGRAM 3) Compare...COMPARE and TEST a) Binary b) Floating point c) Decimal 4) Conversion...CONVERT/TRANSLATE/UNPACK/EDIT/PACK a) Character/Binary/Decimal b) Floating point 5) Cryptography...COMPRESSION/CIPHER/PERFORM 6) I/O...CHANNEL 7) Maths a) Binary b) Floating point c) Decimal 8) Move...PAGE/MOVE/LOAD/STORE/INSERT 9) Trace..TRACE 10) Transaction..TRANSACTION 11) Trap...TRAP 12) Others 4) An iPoP app that can display an individual instruction with multiple cross-references for local use. 5) A Web app to do the same, but has the advantage of being international and collective. "People who looked up LG also looked up LLGF" Let the discourse begin. DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
