Re: Debuggers
Agreed. Fantastic product. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Thursday, May 21, 2015 8:15 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Debuggers Cole Software's XDC product. It does everything I have ever needed. It is like debugging with an assembler listing on your screen. I think it is best of breed. Chris Blaicher Technical Architect Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of mikael.nyst...@seb.se Sent: Thursday, May 21, 2015 1:14 AM To: MVS List Server 2 Subject: Debuggers What debug tool are you using for debugging your assembler programs? We use SmartTest from ASG, but management got a bit nervous when ASG announced their financial problems. We are happy with SmartTest, but it’s always good to know what others are using. Regards, Mikael Nyström Core Systems SEB Group IT Switchboard: +46 8 639 10 00 Postal Address: R-A5 302-A, SE-106 40 Stockholm Office Address: Rissneleden 110 E-mail: mikael.nyst...@seb.se www.seb.sehttp://www.seb.se/ P Please consider the environment before printing this e-mail CONFIDENTIALITY NOTICE This e-mail is confidential and may contain legally privileged information. If you have received it by mistake, please inform us by reply e-mail and then delete it (including any attachments) from your system; you should not copy it or in any other way disclose its content to anyone. E-mail is susceptible to data corruption, interception, unauthorised amendment, tampering and virus. We do not accept liability for any such actions or the consequences thereof.
Re: (My) John Ehrman Assembler Book
Thank you very much for this great work! Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of John Ehrman Sent: Monday, February 09, 2015 12:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: (My) John Ehrman Assembler Book Richard Lawrence posted: The long awaited John Ehrman Assembler book as available at the Marist College web site: http://idcp.marist.edu/enterprisesystemseducation/Assembler%20Language%20Programming%20for%20IBM%20z%20System%20Servers.pdf I appreciate the many kind comments posted on these discussion lists. Please note that some fixes will be in the next update: (1) The fragmentary index after the preface/introduction will be removed. (2) The solutions for sections 25 and 26 will be restored. (3) Various typographic errors will be fixed. (4) Some minor text reorganizations. Rather than adding change bars, I plan to add an Updates section somewhere at the front or back of the text explaining differences from version to version. After those are finished: (n) I'm currently preparing some lecturer materials like presentation slides. (n+1) A major item will be to add hyperlinks for contents and cross-references. (n+2) I apologize, Lizette, but I doubt I'll add another 1200 pages any time soon. John Ehrman (ehr...@us.ibm.com)
Re: Advanced Assembler Language etc.
I think there are probably a lot of us hoping to see this ! Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Thursday, January 22, 2015 8:14 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Advanced Assembler Language etc. John, Did you ever finish the text book? Tony Thigpen John R. Ehrman (408-463-3543 T/543-) wrote on 07/09/2009 02:00 PM: I'm writing an Assembler Language textbook, and hope to finish by the end of this year. John Ehrman (-- Referenced Note Follows ) Date: Thu, 9 Jul 2009 09:14:26 -0400 From: John Carini jcar...@ups.com What book would you recomend for someone who has some limited Assembler coding experience, but still is learning to code the language?
Re: Redesigning the Principles of Operation Manual
Thank you. I really have no need of it ... I was just lamenting the loss of simpler times :-) I'm an old guy obviously. Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Monday, November 17, 2014 9:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual On Fri, 14 Nov 2014 21:30:14 +, Capps, Joey wrote: I miss my original POP ... I think it was like a half inch thick ... maybe 3/4. If you mean the System/360 Principles of Operation, it is still available on bitsavers. I have a printed copy of it that I reference sometimes. You can find it at http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/ -- Tom Marchant
Re: Redesigning the Principles of Operation Manual
Actually all good points. And if IBM wanted to allow this kind of work, I'm quite certain they could come up with ways to make it safe. Even going further and creating a mechanism to 'spy' as you say, really the ability to share address spaces, between users could be done safely if they really wanted to. (For those who will say so, yes, I know, it can all be done, but as suggested, it could be made to work safely without authorization being needed. If IBM was so inclined.) Like most computer things, it's just a matter of programming. Whether it's desirable or not, I don't really know. I'd love it. Whether IBM has anybody clamoring for this though, I don't know. Kinda doubt it though. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Monday, November 17, 2014 9:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual I would presume that a mechanism that permitted an ordinary programmer to create and access his/her own address spaces would automatically limit any access to the initial address space (batch/TSO/Unix) and any address spaces created from it, and prohibit access to address spaces not created by the originating address space. The programmer ought to be able to write and use PC-ss code to perform functions in any of the self-created address spaces, and thus be able to create and test viable client/server programs to perform any envisioned business function. Authorized programs and privileged instructions ought not to be required to build such systems. Accessing address spaces you did not create (i.e., spying in other user's address spaces) is not what I imagined or desired. Any such spying capability (and much more so any mechanism permitting modification of contents) must of course come with authorization requirements for the security and integrity of the whole system. But who does it hurt if I bollix my own self-created address spaces? That should have no more impact on the entire system than bollixing my own task does now. There are other hard questions, like how to limit how many such address spaces can be created by any one user to prevent runaway space creation and virtual page disk space exhaustion, but these are more properly answered by control mechanisms in the operating system, not in the hardware. How to design such a hardware environment is well beyond my capabilities, so I will not try to directly answer that question. I was merely pointing out that I thought that the hardware design which IBM created was not an ideal one from the standpoint of the ordinary (but sophisticated and experienced) application programmer. Not that I expect any of the current design to ever change of course. It is now written in stone. Unix programming fork capabilities, shared memory objects and mutex signaling mechanisms provide some of the functional capabilities I described above, but not the full range of course. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Tom Marchant Sent: Monday, November 17, 2014 10:06 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual On Fri, 14 Nov 2014 18:31:23 -0500, Farley, Peter x23353 wrote: I have often thought it was a mistaken design by IBM that prohibits non-authorized programmers from exploiting multiple address spaces and instruction-level space-switching facilities. How would you propose that such non-authorized programs access only the other address spaces that they were permitted to access? In other words, how would you protect the integrity of all address spaces if unauthorized code were able to access other address spaces? -- Tom Marchant This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Redesigning the Principles of Operation Manual
And obvious observation ... I would personally love to have something like this. But I'm not sure that there are hordes out there demanding these features ... IBM is like most corps. The only thing that will drive IBM to do anything like this (or anything else really) is the perception that there are a large number of customers who want it and that it will either result in them making more than enough money to pay for it or in them not losing current revenue due to not doing it. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Raulerson Sent: Monday, November 17, 2014 11:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual In Unix, we would probably use ptrace(), which is a debug facility. One can easily stop a program(process), modify memory or anything else in the program address space, then restart the program with it being none the wiser. -Paul On Nov 17, 2014, at 11:46 AM, Farley, Peter x23353 peter.far...@broadridge.com wrote: I would presume that a mechanism that permitted an ordinary programmer to create and access his/her own address spaces would automatically limit any access to the initial address space (batch/TSO/Unix) and any address spaces created from it, and prohibit access to address spaces not created by the originating address space. The programmer ought to be able to write and use PC-ss code to perform functions in any of the self-created address spaces, and thus be able to create and test viable client/server programs to perform any envisioned business function. Authorized programs and privileged instructions ought not to be required to build such systems. Accessing address spaces you did not create (i.e., spying in other user's address spaces) is not what I imagined or desired. Any such spying capability (and much more so any mechanism permitting modification of contents) must of course come with authorization requirements for the security and integrity of the whole system. But who does it hurt if I bollix my own self-created address spaces? That should have no more impact on the entire system than bollixing my own task does now. There are other hard questions, like how to limit how many such address spaces can be created by any one user to prevent runaway space creation and virtual page disk space exhaustion, but these are more properly answered by control mechanisms in the operating system, not in the hardware. How to design such a hardware environment is well beyond my capabilities, so I will not try to directly answer that question. I was merely pointing out that I thought that the hardware design which IBM created was not an ideal one from the standpoint of the ordinary (but sophisticated and experienced) application programmer. Not that I expect any of the current design to ever change of course. It is now written in stone. Unix programming fork capabilities, shared memory objects and mutex signaling mechanisms provide some of the functional capabilities I described above, but not the full range of course. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER- l...@listserv.uga.edu] On Behalf Of Tom Marchant Sent: Monday, November 17, 2014 10:06 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual On Fri, 14 Nov 2014 18:31:23 -0500, Farley, Peter x23353 wrote: I have often thought it was a mistaken design by IBM that prohibits non-authorized programmers from exploiting multiple address spaces and instruction-level space-switching facilities. How would you propose that such non-authorized programs access only the other address spaces that they were permitted to access? In other words, how would you protect the integrity of all address spaces if unauthorized code were able to access other address spaces? -- Tom Marchant This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Re: Redesigning the Principles of Operation Manual
Except It's already documented. Maybe We're too busy to re-document to meet each wish of this list. :-) -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, November 14, 2014 7:41 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual 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
Re: Redesigning the Principles of Operation Manual
I think there is clearly room for some kind of new documentation to meet some people's needs. If this many people think so, then that's pretty much proof it's needed. There is also a contingent that thinks the existing format of the POP is fine as is for their purposes. Probably the existing publication should stay as it is but there should be a new document that takes care of all these other needs. Not sure IBM will make that happen, or even that they are necessarily the ones who need to write that new book. But it's clear that there is perceived need for such. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gary Weinhold Sent: Friday, November 14, 2014 12:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual You know we're all just talking about presentation of information, not the information itself. So what we want is a flexible (tailorable?) interface to the information, not a change in the information itself. So with all the advances made in user access to information, we're saying it can never apply to the PoOp information. Gary Weinhold On 2014-11-14 12:32, Tom Marchant wrote: On Fri, 14 Nov 2014 09:03:59 -0500, Tony Thigpen wrote: 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. Some of us like it in two columns, some hate it. I happen to be in the former group. The second issue is the way the if 24bit, if 31 bit, if 64bit statements read. For myself, I have no difficulty with the for L, ... for LH, ... kinds of statements. Suggestions: 1) Make each group of instructions (like ADD) start on a new page. Not necessary, IMO 2) Use two columns for the instruction bit pictorials. Put 24/31 bit on the left and 64 bit on the right. Yuck. 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. I really don't like this. 5) If possible, consider placing the simple examples directly after the instructions. Clutter. Please don't. Clearly, there is no consensus here that any of the proposed changes are a good idea.
Re: Redesigning the Principles of Operation Manual
http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html for a link to intel architecture specification documents -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Friday, November 14, 2014 2:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual On 2014-11-14 11:17, Gary Weinhold wrote: You know we're all just talking about presentation of information, not the information itself. So what we want is a flexible (tailorable?) interface to the information, not a change in the information itself. So with all the advances made in user access to information, we're saying it can never apply to the PoOp information. Exactly. Two columns is just presentation. It's a pity that semantics has been subsumed by presentation. Just as a point of reference, how does Intel do it (or AMD or Cyrix or IBM supercomputers)? Probably their Principles of Operation are less targeted at end users, but someone still must write the compilers. -- gil
Re: Redesigning the Principles of Operation Manual
I miss my original POP ... I think it was like a half inch thick ... maybe 3/4. I know there are many here older than me, but my first assembly code was in 74. It was all pretty straightforward back then. Now I look at the doc ... and then I made the mistake of actually looking at the intel doc I linked ... OMG And I do remember that wording you quote below :-) Never did figure out what they were getting at ... -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Michael Stack Sent: Friday, November 14, 2014 3:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual Correctness is the most important, and most difficult to achieve, characteristic of PoO. An example: in my nine-years-old e-copy of PoO, there is in Appendix A a section on sorting instructions (p. A-52 in my edition). The headers and first sentence read: Sorting Instructions Tree Format Two instructions, COMPARE AND FORM CODEWORD and UPDATE TREE, refer to a tree - a data structure with a specific format. The problem is that execution of CFC has nothing directly to do with trees, and anyone attempting to understand those instructions will be seriously misled. What follows is a pretty-much-accurate description of how trees are used in the sort assist, but comprehensibility is sacrificed. (I should say that Dan knows of my concern, and this may well have been corrected in later editions.) This comment is intended solely to point out how much more difficult it is to write accurate mainframe technical language today than it was fifty years ago. Mike At 12:09 PM 11/14/2014 -0500, you wrote: On 2014-11-13 20:28, Tony Thigpen wrote: Something for an intern I assume this was tongue in cheek! The most important attribute of POps is correctness. No offense meant to interns, but I suspect that correctness would suffer if the POps was turned over to interns. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: Redesigning the Principles of Operation Manual
It's an architectural specification book, not a text book. I would prefer it stay that way. There certainly is room for more, and better designed textbooks on this topic though. If someone wanted to take a POP like approach to writing one, and expand that to include more useful information for students that would be great. But the architectural specification book doesn't need to be modified to do that. Just my opinion :-) Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of MELVYN MALTZ Sent: Wednesday, November 12, 2014 5:59 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual Hi Joey, I think you miss the point. Conciseness is essential. What I am suggesting is that each instruction is concisely defined. Start with ADD in Chapter 7, where 15 instructions are concisely compressed into a meaningless hotchpotch of description. Do you think that a student after reading that section would know what ASI actually did ? Mel. - Original Message - From: Capps, Joey jca...@informatica.com To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Wednesday, November 12, 2014 10:15 PM 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Wednesday, November 12, 2014 4:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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) BranchBRANCH 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.
Re: Redesigning the Principles of Operation Manual
Actually so would I. But that would be a different manual, with a different purpose. Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ward Able, Grant Sent: Thursday, November 13, 2014 4:52 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Capps, Joey Sent: 12 November 2014 22:15 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Wednesday, November 12, 2014 4:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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) BranchBRANCH 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.
Re: Redesigning the Principles of Operation Manual
We could always code the information into a small database with as many dimensions as we wanted and allow the data to be cut by any or all of them. Perhaps an app for your phone, tablet or PC. Would be cool. Not what the POP is about, but it would be cool. Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, November 13, 2014 12:05 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Redesigning the Principles of Operation Manual On 2014-11-12, at 23:27, fred.van.der.wi...@mail.ing.nl wrote: That is an excellent point. The description would get a lot clearer if it just detailed one instruction. That could be a significant improvement. I'm sure IBM can come up with a mechanism to create such an end result without replicating every spec of information in the description of every instruction it applies to. That would make life easier for the authors and prevent errors in new versions. Hypertext? With generous use of See also ... Or, for each basic instruction, hyperlinks in a matrix of: address format (RR, RS, SI, SS, ...) by operand format (C, H, F, G, P, D, ...) Each expanding to a complete and concise description of that form only. But where to put the AMODE considerations for such as LA? A third dimension? -- gil
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:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Melvyn Maltz Sent: Wednesday, November 12, 2014 4:04 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 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) BranchBRANCH 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.
Re: ASSEMBLER-LIST Digest - 14 Sep 2014 to 30 Sep 2014 (#2014-41)
Yes John. Like assembly language, z/OS and mainframes, it's long dead ;-)
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John Walker
Sent: Wednesday, October 01, 2014 8:53 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASSEMBLER-LIST Digest - 14 Sep 2014 to 30 Sep 2014 (#2014-41)
This is pretty much a defunct area, isn't it?
On Tue, 9/30/14, ASSEMBLER-LIST automatic digest system
lists...@listserv.uga.edu wrote:
Subject: ASSEMBLER-LIST Digest - 14 Sep 2014 to 30 Sep 2014 (#2014-41)
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Date: Tuesday, September 30, 2014, 11:00 PM
ASSEMBLER-LIST Digest - 14 Sep 2014 to 30 Sep 2014
(#2014-41)
#yiv4286627597 body {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv4286627597 td {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv4286627597 p {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;color:#00;}
#yiv4286627597 a {
font-family:Arial, Helvetica,
sans-serif;font-size:12px;font-weight:bold;color:#3366CC;text-decoration:none;}
#yiv4286627597 h2 {
font-family:Arial, Helvetica,
sans-serif;font-size:17px;font-weight:bold;color:#CC0033;}
#yiv4286627597 h3 {
font-family:Arial, Helvetica,
sans-serif;font-size:16px;font-weight:bold;color:#3366CC;}
ASSEMBLER-LIST Digest - 14 Sep 2014 to 30 Sep 2014
(#2014-41)
Table of contents:
Test post (3)
Test post
Test post (09/30)
From: Hall, Keven
keh...@informatica.com
Re: Test post (09/30)
From: Lizette Koehler stars...@mindspring.com
Re: Test post (09/30)
From: Tony Harminc t...@harminc.com
Browse the ASSEMBLER-LIST
online archives.
Automatic reply: ASMA038S
I am out of the office until Wednesday - Dan Smith is in charge in my place. Thanks, Joey
Automatic reply: PTF level in SYSPRINT? (was: ASSEMBLER-LIST Digest ...)
I am out of the office until Tuesday - Dan Smith is in charge in my place. Thanks, Joey
Automatic reply: getting length of macro symbol
I am out of the office until Monday - Ron Root is in charge in my place. rr...@informatica.com Thanks, Joey
Automatic reply: Carmine Cannatello's book
I am out of the office until Monday - Dan Smith is in charge in my place. Dan Smith COE Owner for DataReplication | Team Lead, Principal Subject Matter Expert | GCS for PowerExchange and DataReplication Email: dsm...@informatica.commailto:dsm...@informatica.com Office: +1.512.795.6988 Thanks, Joey
Automatic reply: macros to implement opcodes
I am Office Today - Dan Smith is in charge in my place. Dan Smith COE Owner for DataReplication | Team Lead, Principal Subject Matter Expert | GCS for PowerExchange and DataReplication Email: dsm...@informatica.commailto:dsm...@informatica.com Office: +1.512.795.6988 Thanks, Joey
Automatic reply: PL/j (Was: FLOWASM)
I will be out of the Office until next Wednesday - Dan Smith is in charge in my place. Dan Smith COE Owner for DataReplication | Team Lead, Principal Subject Matter Expert | GCS for PowerExchange and DataReplication Email: dsm...@informatica.commailto:dsm...@informatica.com Office: +1.512.795.6988 Thanks, Joey Thanks, Joey
Automatic reply: ASSIST Assembler and HLASM
I am currently out of the office. I will return Monday 12/2 Dan Smith will be acting in my place: Dan Smith COE Owner for DataReplication | Team Lead, Principal Subject Matter Expert | GCS for PowerExchange and DataReplication Email: dsm...@informatica.commailto:dsm...@informatica.com Office: +1.512.795.6988 Thanks, Joey
Automatic reply: missing functionality in TRTE
I am currently out of the office. I will return Monday 10/21 If you need a faster response please call Frank Cunningham or Ron Root. Frank's Phone: +1 512 795 6910 Ron's Phone +1 512 795 6923 (Ron will only be here Thursday, not Friday) Thanks, Joey
Re: Sortlessness?
Not since the old days when you dropped your card deck in a physical card sorter :-) -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Gord Tomlin Sent: Friday, August 30, 2013 3:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Sortlessness? Just a little Friday afternoon curiosity...does anyone have, or know of, any z/OS systems that have *no* sort product (DFSORT, Syncsort, etc.) installed? Before anyone asks, no, I am not planning to develop one! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507
Re: YREGS and RA....RF
I do it because I think in HEX, not Decimal ... Just makes more sense to me when messing with assembler. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mike Kerford-Byrnes Sent: Wednesday, July 31, 2013 1:22 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: YREGS and RARF It may be an urban myth, but I recall it being linked to the fact that the 029 punch needed upper case for numerics and it was quicker to touch type if all alpha was involved (that is assuming that the programmers had such skills in the first place - sadly lacking in yours truly!! Can anyone else confirm (or deny)? MKB
Re: 3 job openings for mainframe Assembler/C programmers, dump readers
Same here. I learned on my own, under the tutelage of an expert in my first job, then spent 9 years at Amdahl taking their excellent courses and getting lots of practice on customer dumps. Ended up as an instructor at Amdahl before things went awry with that company ... I believe that Techknowledge Corporation is the spin-off of the old Amdahl Edcuation group and still teaches updated versions of many of those internals and dump classes. Joey Capps -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tom Marchant Sent: Monday, July 29, 2013 1:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: 3 job openings for mainframe Assembler/C programmers, dump readers On Thu, 25 Jul 2013 23:59:49 -0500, William H. Blair wrote: Don V Nielsen asks: | Where might one one find good instruction on how to read a dump? For the most part, everybody I know that's any good at it got that way all on their own (they may have taken a class from IBM or Amdahl back when they were young and green, however...) When I was getting started as a Cobol programmer in 1970, I was given a paper with a title something like Newspaper approach to dump reading. It was based upon a journalist's basic questions, who, what, when, where, why and how, that are necessary in any investigation. That document helped me get started reading SYSABEND dumps of my simple programs. I have no idea where it came from, but I wonder if it might have come from SHARE. Then, as an Amdahl SE, I attended classes in MVS internals and diagnosis. During my years there, I must have analyzed hundreds of dumps. Most of them were SVC dumps, but also the occasional stand-alone dump. In those pre-XA days, the dumps that I examined were all on paper. Today, I use IPCS. I have mentored some to help them with their dump analysis skills. A few have become quite competent at it. -- Tom Marchant
Re: 3 job openings for mainframe Assembler/C programmers, dump readers
Did assembler on all of them. But not as much on VM. As for DOS and it's variants, back then we were very likely to code in Assembler as we had the source and it was common practice to modify it ... Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of T'Dell Sparks Sent: Monday, July 29, 2013 2:49 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: 3 job openings for mainframe Assembler/C programmers, dump readers You're less likely to code assembler on the those systems, as with VSE has a different style to coding I/O macros ( No mystery here the DOS/VSE macros in a spate section of the Abel book ) and with the VM/370 you could code without remorse using the Assembler facility under Xedit (forgot what I was called , but worked well enough to run a few programs).If you are running Linux I's use C/C++ just as well , or if you have a c/C++ compiler at your disposal on z/OS you're ahead of the game. You can write simple c programs and look at the .s listing and compare the code generated against a hand coded assembler. Ahh such memorable fun ... I need my milk and cookies and a nap now .. I'm old -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Capps, Joey Sent: Monday, July 29, 2013 12:26 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: 3 job openings for mainframe Assembler/C programmers, dump readers Yep. I started on DOS (non VS) moved to VS, then NIXDORF VS Extended, then VSE, then VM, then the MVS series ... Shot dumps on them all, coded on them all. I think I'm getting old ... Joey -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Meyer, Kenneth J Sent: Monday, July 29, 2013 2:22 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: 3 job openings for mainframe Assembler/C programmers, dump readers Contrary to popular opinion, z/OS is not the only operating system on the mainframe. You also have z/VM and (gasp!) z/VSE! z/Linux was already mentioned multiple times, so no need to repeat. :) I learned to read dumps back in College by reading dumps. It was much easier to debug COBOL and Fortran programs by looking at the LISTX than to actually check the logic of those 3 GLs... ;) Took a class given by GOAL about VSE control blocks and other such stuff, and then built on that without a mentor per se. Ken snip..
Automatic reply: 64 bit question
I am currently out of the office. I will return Thursday Ron Root is in charge in my place. rr...@informatica.com 512 795 6923 Thanks, Joey
Automatic reply: Good Performing Code (Was: Millicode Instructions)
I am currently out of the office and unreachable until Thursday. If you have a P1, Production Down issue with PowerExchange or UDR products please make a voice call to Informatica Support and open an SR. Thanks, Joey
Automatic reply: How to print a floating point number
I am currently out of the office and unreachable until Wednesday, January the 2nd, 2013. If you have a P1, Production Down issue with PowerExchange or UDR products please make a voice call to Informatica Support and open an SR. Thanks, Joey
Automatic reply: Passing SYSLIST to sub-macro.
I am currently out of the office and unreachable until Tuesday 4/2. If you have a P1, Production Down issue with PowerExchange or UDR products please make a voice call to Informatica Support and open an SR. Thanks, Joey
Automatic reply: STORAGE OBTAIN with ALET
I am currently out of the office and unreachable until Wednesday, January the 2nd, 2013. If you have a P1, Production Down issue with PowerExchange or UDR products please make a voice call to Informatica Support and open an SR. Thanks, Joey
Automatic reply: Impossible - generic macro prototype
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. Ron Root - PWX Support Team Lead rr...@informatica.com 512-795-6923
Automatic reply: flowcharting
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. Ron Root - PWX Support Team Lead rr...@informatica.com 512-795-6923
Automatic reply: MVS SYS PROG needed.
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. Ron Root - PWX Support Team Lead rr...@informatica.com 512-795-6923
Automatic reply: Some Help with IEAMSCHD
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. Ron Root - PWX Support Team Lead rr...@informatica.com 512-795-6923
Automatic reply: Title: V1R6 Language Ref
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. Ron Root - PWX Support Team Lead rr...@informatica.com 512-795-6923
Automatic reply: Program FLIH backdoor
I am currently out of the office. Ron Root will be handling US PWX issues while I am out. rr...@informatica.com 512-795-6923
