Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown On Thu, 23 Apr 2009 14:34:22 -0500, Chase, John wrote: snip To this day I have the impression that many COBOL shops actually *fear* Assembler and/or anybody who professes even the slightest proficiency with it. IMO, most shops today fear any and all programmers who could be considered above average, regardless of the language that they use. Why? Because their code will be harder to understand than the simple code written by less talented. That means that the code is more difficult, and thus expensive, to maintain. Today is the day of the mediocre-ocaracy instead of the meritocracy. Good enough is better than excellent. Because excellent costs more. And any pay back is long term, not short. Eat, drink, and be merry for tomorrow we change jobs and leave our junkie problems behind! Hmmm I attribute today's mediocrity to the enterprise wannabe, consumer-grade operating system. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown [ snip ] . . .. Take a case in point. A programmer has two VSAM KSDS files. He is reading one file sequentially and wants to see in the second file has as associated record in it (both files are keyed identically). How to do that? I will grant that in the past, this was a no brainer. However, this normal (perhaps sub-normal?) programmer did it the easy way. He read the first file sequentially. Then, for each record read, he did a keyed read of the second file. The second file contained about 5% of the number of records in the first file. So 95% of the time, the keyed read got a record not found and, as a plus, ended up with its buffers flushed and positioning lost. Of course the correct way to do this is to read each file sequentially in parallel (they are in the same order due to using the same key values), doing a match merge type operation. But that mindset seems, at least around here, to have disappeared. I did the match merge code to show how to do it (with a dramatic reduction in CPU and elapsed time). The programmer considered __that__ to be too advanced and obscure. IBM already provides a program to do exactly that: ICETOOL. Syncsort provides a similar program. Don't know about CA-Sort. Why bother to reinvent that wheel? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Fri, 24 Apr 2009 07:15:15 -0500, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of John McKown
[ snip ]
. . .. Take a case in point. A programmer has two VSAM KSDS
files. He is reading one file sequentially and wants to see in the
second
file has as associated record in it (both files are keyed
identically). How
to do that? I will grant that in the past, this was a no brainer.
However,
this normal (perhaps sub-normal?) programmer did it the easy way.
He
read the first file sequentially. Then, for each record read, he did a
keyed
read of the second file. The second file contained about 5% of the
number of
records in the first file. So 95% of the time, the keyed read got a
record
not found and, as a plus, ended up with its buffers flushed and
positioning
lost.
Of course the correct way to do this is to read each file sequentially
in
parallel (they are in the same order due to using the same key
values),
doing a match merge type operation. But that mindset seems, at least
around here, to have disappeared. I did the match merge code to show
how
to do it (with a dramatic reduction in CPU and elapsed time). The
programmer
considered __that__ to be too advanced and obscure.
IBM already provides a program to do exactly that: ICETOOL.
Syncsort provides a similar program. Don't know about CA-Sort.
Why bother to reinvent that wheel?
-jc-
I simplified too much. The code was more like (pseudo-COBOL):
read master-file
perform until eof-on-master-file
move master-key to second-key
read second-file key second-key
if record-not-found-second then
do default processing
else
do processing based on data in second-file
end-if
read mater-file
end-perform
it is still better (personal opinion) to read both files sequential,
matching the key values and doing the required processing.
--
John
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
John McKown wrote:
On Fri, 24 Apr 2009 07:15:15 -0500, Chase, John jch...@ussco.com wrote:
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of John McKown
[ snip ]
. . .. Take a case in point. A programmer has two VSAM KSDS
files. He is reading one file sequentially and wants to see in the
second
file has as associated record in it (both files are keyed
identically). How
to do that? I will grant that in the past, this was a no brainer.
However,
this normal (perhaps sub-normal?) programmer did it the easy way.
He
read the first file sequentially. Then, for each record read, he did a
keyed
read of the second file. The second file contained about 5% of the
number of
records in the first file. So 95% of the time, the keyed read got a
record
not found and, as a plus, ended up with its buffers flushed and
positioning
lost.
Of course the correct way to do this is to read each file sequentially
in
parallel (they are in the same order due to using the same key
values),
doing a match merge type operation. But that mindset seems, at least
around here, to have disappeared. I did the match merge code to show
how
to do it (with a dramatic reduction in CPU and elapsed time). The
programmer
considered __that__ to be too advanced and obscure.
IBM already provides a program to do exactly that: ICETOOL.
Syncsort provides a similar program. Don't know about CA-Sort.
Why bother to reinvent that wheel?
-jc-
I simplified too much. The code was more like (pseudo-COBOL):
read master-file
perform until eof-on-master-file
move master-key to second-key
read second-file key second-key
if record-not-found-second then
do default processing
else
do processing based on data in second-file
end-if
read mater-file
end-perform
it is still better (personal opinion) to read both files sequential,
matching the key values and doing the required processing.
--
Interesting. In our intro to COBOL course, we actually use
match merge as a way to approach complex logic structures.
Not everything has to be online, keyed access.
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
== Check out the Trainer's Friend Store to purchase z/OS ==
== application developer toolkits. Sample code in four==
== programming languages, JCL to Assemble or compile, ==
== bind and test. ==
== http://www.trainersfriend.com/TTFStore/index.html==
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 23 Apr 2009 15:53:04 -0500, John McKown wrote: On Thu, 23 Apr 2009 20:32:30 +, Ted MacNEIL wrote: IMO, most shops today fear any and all programmers who could be considered above average, regardless of the language that they use. Why? Because their code will be harder to understand than the simple code written by less talented. I TOTALLY disagree with that statement! I've found that the most talented write the cleanest, most elegant, and easiest to maintain code. They are smart/skilled enough to not use the obscure constructs. I agree and disagree with you. But, perhaps, it is due to what I have seen written around here. Take a case in point. A programmer has two VSAM KSDS files. He is reading one file sequentially and wants to see in the second file has as associated record in it (both files are keyed identically). How to do that? I will grant that in the past, this was a no brainer. However, this normal (perhaps sub-normal?) programmer did it the easy way. He read the first file sequentially. Then, for each record read, he did a keyed read of the second file. The second file contained about 5% of the number of records in the first file. So 95% of the time, the keyed read got a record not found and, as a plus, ended up with its buffers flushed and positioning lost. I agree with Ted on this one. Better programmers write better code. IMO, the example you cite here is not written by a superior programmer. It is written by a programmer who has difficulty understanding the basics. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On 24 Apr 2009 05:16:31 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of John McKown [ snip ] . . .. Take a case in point. A programmer has two VSAM KSDS files. He is reading one file sequentially and wants to see in the second file has as associated record in it (both files are keyed identically). How to do that? I will grant that in the past, this was a no brainer. However, this normal (perhaps sub-normal?) programmer did it the easy way. He read the first file sequentially. Then, for each record read, he did a keyed read of the second file. The second file contained about 5% of the number of records in the first file. So 95% of the time, the keyed read got a record not found and, as a plus, ended up with its buffers flushed and positioning lost. Of course the correct way to do this is to read each file sequentially in parallel (they are in the same order due to using the same key values), doing a match merge type operation. But that mindset seems, at least around here, to have disappeared. I did the match merge code to show how to do it (with a dramatic reduction in CPU and elapsed time). The programmer considered __that__ to be too advanced and obscure. IBM already provides a program to do exactly that: ICETOOL. Syncsort provides a similar program. Don't know about CA-Sort. Why bother to reinvent that wheel? I would have to know more about the nature of the data and whether BLSR was used for the file with the keyed read. How many records would have been read using the sequential read? Would all records on the second file match records on the first file? While I tend to agree with reading the second file sequentially, that might not have been the best solution. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Kirk Wolf Sent: Wednesday, April 22, 2009 8:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: METAL C: CodeGen defeciency? Snipped Interesting that they didn't use XC, isn't it? If you spend any time looking at XLC generated code you will see lots of interesting stuff. Of particular interest is some of the loop unwinding optimizations. After a while you start to wonder if you should ever write in assembler again, since only IBM knows what instruction heuristics slide through the pipelines the best. It seems to me to be counterproductive of IBM to hide (or simply fail to publish) knowledge or advice on effective assembler programming to take advantage of (or at least not to fall afoul of) the pipeline nature of today's z processors. Obviously a thorough reading of the z/Arch PoOP will give an experienced assembler programmer a few don't do this, it flushes the pipeline cautions, like the following that I recently ran across while researching something else entirely: In the notes under the Branch on Condition instruction in Chapter 7: 4. Execution of BCR 15,0 (that is, an instruction with a value of 07F0 hex) may result in significant performance degradation. To ensure optimum performance, the program should avoid use of BCR 15,0 except in cases when the serialization or checkpoint-synchronization function is actually required. But let's face it -- how many of us have the time to be thorough about reading the PoOP? So, does anyone who regularly reads the IBM Systems Journal or Redbooks/Redpapers or other IBM pubs know of anything that IBM may have published that consolidates and exposes such knowledge? I, for one, would be very happy to reduce my ignorance with a little such light reading. Peter 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 23 Apr 2009 09:58:18 -0400 Farley, Peter x23353 peter.far...@broadridge.com wrote: : -Original Message- : From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On : Behalf Of Kirk Wolf : Sent: Wednesday, April 22, 2009 8:44 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: METAL C: CodeGen defeciency? :Snipped : Interesting that they didn't use XC, isn't it? If you spend any time : looking at XLC generated code you will see lots of interesting stuff. : Of particular interest is some of the loop unwinding optimizations. : After a while you start to wonder if you should ever write in : assembler again, since only IBM knows what instruction heuristics : slide through the pipelines the best. :It seems to me to be counterproductive of IBM to hide (or simply fail :to publish) knowledge or advice on effective assembler programming to :take advantage of (or at least not to fall afoul of) the pipeline nature :of today's z processors. :Obviously a thorough reading of the z/Arch PoOP will give an experienced :assembler programmer a few don't do this, it flushes the pipeline :cautions, like the following that I recently ran across while :researching something else entirely: :In the notes under the Branch on Condition instruction in Chapter 7: :4. Execution of BCR 15,0 (that is, an instruction :with a value of 07F0 hex) may result in significant :performance degradation. To ensure optimum :performance, the program should avoid use of :BCR 15,0 except in cases when the serialization :or checkpoint-synchronization function is actually :required. As there is no reason to code a BCR 15,0 this provides little value. CNOP / NOPR generate BCR 0,0. :But let's face it -- how many of us have the time to be thorough about :reading the PoOP? :So, does anyone who regularly reads the IBM Systems Journal or :Redbooks/Redpapers or other IBM pubs know of anything that IBM may have :published that consolidates and exposes such knowledge? I, for one, :would be very happy to reduce my ignorance with a little such light :reading. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Thursday, April 23, 2009 10:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?] On Thu, 23 Apr 2009 09:58:18 -0400 Farley, Peter x23353 peter.far...@broadridge.com wrote: Snipped :In the notes under the Branch on Condition instruction in Chapter 7: :4. Execution of BCR 15,0 (that is, an instruction :with a value of 07F0 hex) may result in significant :performance degradation. To ensure optimum :performance, the program should avoid use of :BCR 15,0 except in cases when the serialization :or checkpoint-synchronization function is actually :required. As there is no reason to code a BCR 15,0 this provides little value. CNOP/NOPR generate BCR 0,0. Agreed, but this was just an example of pipeline-related information provided in the z/Arch PoOP. Not useful per se, I agree, but I'm sure there are many more such notes that I haven't read about that might indeed be useful to know. Hence my request for a collected source of such information. Peter 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 2009-04-23 at 10:44 -0400, Binyamin Dissen wrote: As there is no reason to code a BCR 15,0 Is that really true? We don't have the M91/195 (and their imprecise interrupts) to kick around anymore, but is there any other legitimate use for serializing the pipeline? Why would IBM carry this side-effect forward for BCR [nonzero],0? -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
I'm not really an assembler programmer, but I've known this one since my earliest days. I'm sure it was in the 370 Pop I used in my one and only assembler programming class in 1979. Good class, I have a job today because I took that class, did an internship the next semester and here I am today :) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Farley, Peter x23353 Sent: Thursday, April 23, 2009 6:58 AM To: IBM-MAIN@bama.ua.edu Subject: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?] Obviously a thorough reading of the z/Arch PoOP will give an experienced assembler programmer a few don't do this, it flushes the pipeline cautions, like the following that I recently ran across while researching something else entirely: In the notes under the Branch on Condition instruction in Chapter 7: 4. Execution of BCR 15,0 (that is, an instruction with a value of 07F0 hex) may result in significant performance degradation. To ensure optimum performance, the program should avoid use of BCR 15,0 except in cases when the serialization or checkpoint-synchronization function is actually required. But let's face it -- how many of us have the time to be thorough about reading the PoOP? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
Gibney, Dave wrote: I'm not really an assembler programmer, but I've known this one since my earliest days. I'm sure it was in the 370 Pop I used in my one and only assembler programming class in 1979. Good class, I have a job today because I took that class, did an internship the next semester and here I am today :) Which is a good reason for every company to sponsor an Assembler class for every one of their z/OS programmers, right? We're ready. :) Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
David Andrews wrote: On Thu, 2009-04-23 at 10:44 -0400, Binyamin Dissen wrote: As there is no reason to code a BCR 15,0 Is that really true? We don't have the M91/195 (and their imprecise interrupts) to kick around anymore, but is there any other legitimate use for serializing the pipeline? Why would IBM carry this side-effect forward for BCR [nonzero],0? It's not [nonzero],0, it's 15,0. SRCHFOR 'BCR 15,0' in SYS1.SHASSRC for some examples. (I know this because I once had a machine that didn't serialize on that instruction and it took me a bit short of forever to determine why HASPNUC 0C4'd on rare occasion.) Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
I have snipped all the content from this IBM-MAIN thread *and* have sent this note to both IBM-MAIN and the Assembler list. The question has been asked as to whether there is consolidated information anywhere on IBM performance advice related to HLASM coding for best pipeline performance. The answer seems to be that, NO, no such consolidated information exists, but that some individual hints are spread out in the PoP (or at least implied there). This seems like a good time to remind both lists that the ASM project of SHARE is still accepting requirements *AND* that requests for documentation (or improved documentation) is definitely within the scope of such requirements. (No recent requirements have been submitted, but I do keep an eye out for when/if they are.) If you are a SHARE member organization and already registered to participate in the ASM project requirements process, please feel free to submit such a requirement (or any OTHER requirement that you might have for either HLASM or the binder). If you are a SHARE participant but not currently registered for the ASM project requirements process, please consider joining. If you need any additional information on this, please contact me off-list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Gibney, Dave wrote: I'm not really an assembler programmer, but I've known this one since my earliest days. I'm sure it was in the 370 Pop I used in my one and only assembler programming class in 1979. Good class, I have a job today because I took that class, did an internship the next semester and here I am today :) Which is a good reason for every company to sponsor an Assembler class for every one of their z/OS programmers, right? We're ready. :) Long ago and far away, during a group job interview (aka tour de farce), the interviewer stated that programmers could code CICS programs in their language of choice, whether it be C, COBOL or PL/I. I asked, Assembler? He replied, Anybody who even *thinks* about coding in Assembler should be shot! I bid them all Good Day and departed immediately. To this day I have the impression that many COBOL shops actually *fear* Assembler and/or anybody who professes even the slightest proficiency with it. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 23 Apr 2009 14:34:22 -0500, Chase, John jch...@ussco.com wrote: snip To this day I have the impression that many COBOL shops actually *fear* Assembler and/or anybody who professes even the slightest proficiency with it. -jc- IMO, most shops today fear any and all programmers who could be considered above average, regardless of the language that they use. Why? Because their code will be harder to understand than the simple code written by less talented. That means that the code is more difficult, and thus expensive, to maintain. Today is the day of the mediocre-ocaracy instead of the meritocracy. Good enough is better than excellent. Because excellent costs more. And any pay back is long term, not short. Eat, drink, and be merry for tomorrow we change jobs and leave our junkie problems behind! -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 2009-04-23 at 14:57 -0400, Bob Rutledge wrote: It's not [nonzero],0, it's 15,0. Hey, you're absolutely RIGHT. (I wonder if it's always been like this? Am I mis-remembering stuff from 35 years ago? Anyone got a *really* old PrincOps?) SRCHFOR 'BCR 15,0' in SYS1.SHASSRC for some examples. Thanks for that tip. There are hits in HASCHAM, HASPMISC, HASPNUC and HASPXEQ. It isn't obvious to me why they want to serialize in those places; maybe I can find some enlightening APAR text somewhere. And fortunately, the serialization discussion in chapter 5 of the PrincOps is pretty lucid. I'll get it eventually. In the meantime I'll go lay down by my dish. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
IMO, most shops today fear any and all programmers who could be considered above average, regardless of the language that they use. Why? Because their code will be harder to understand than the simple code written by less talented. I TOTALLY disagree with that statement! I've found that the most talented write the cleanest, most elegant, and easiest to maintain code. They are smart/skilled enough to not use the obscure constructs. That means that the code is more difficult, and thus expensive, to maintain. I find the weak programmers are the ones to use strange (and often misunderstood) tricks, or as we used to call it 'spaghetti code'. Writing hard to maintain code is produced by poor programmers, not strong ones. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On 23 Apr 2009 13:35:12 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: I find the weak programmers are the ones to use strange (and often misunderstood) tricks, or as we used to call it 'spaghetti code'. Writing hard to maintain code is produced by poor programmers, not strong ones. I once worked in a shop that used to be RPG-II only. In order to do some necessary things, some smart programmers wrote some hard-to-maintain code using tricks.Once they got a CoBOL compiler, that wasn't needed anymore. With that exception, I strongly agree with you that the best programmers created the easiest to maintain code. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
2009/4/23 David Andrews d...@lists.duda.com: On Thu, 2009-04-23 at 14:57 -0400, Bob Rutledge wrote: It's not [nonzero],0, it's 15,0. Hey, you're absolutely RIGHT. (I wonder if it's always been like this? Am I mis-remembering stuff from 35 years ago? Yup - it's always been like this. I think of it as branch always, nowhere, vs the two other NOP formats of branch never, somewhere, and branch never, nowhere. That last one is what people usually think of as *the* NOP, but it's not the only one. Anyone got a *really* old PrincOps?) http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-0_370_Principles_Of_Operation_Jun70.pdf is as old as you can get for S/370. Too old for your purposes, really, since it's just a little booklet that updates the S/360 POO. But even that is available at http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf . Unfortunately these are not searchable PDFs. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 23 Apr 2009 20:32:30 +, Ted MacNEIL eamacn...@yahoo.ca wrote: IMO, most shops today fear any and all programmers who could be considered above average, regardless of the language that they use. Why? Because their code will be harder to understand than the simple code written by less talented. I TOTALLY disagree with that statement! I've found that the most talented write the cleanest, most elegant, and easiest to maintain code. They are smart/skilled enough to not use the obscure constructs. That means that the code is more difficult, and thus expensive, to maintain. I find the weak programmers are the ones to use strange (and often misunderstood) tricks, or as we used to call it 'spaghetti code'. Writing hard to maintain code is produced by poor programmers, not strong ones. - Too busy driving to stop for gas! I agree and disagree with you. But, perhaps, it is due to what I have seen written around here. Take a case in point. A programmer has two VSAM KSDS files. He is reading one file sequentially and wants to see in the second file has as associated record in it (both files are keyed identically). How to do that? I will grant that in the past, this was a no brainer. However, this normal (perhaps sub-normal?) programmer did it the easy way. He read the first file sequentially. Then, for each record read, he did a keyed read of the second file. The second file contained about 5% of the number of records in the first file. So 95% of the time, the keyed read got a record not found and, as a plus, ended up with its buffers flushed and positioning lost. Of course the correct way to do this is to read each file sequentially in parallel (they are in the same order due to using the same key values), doing a match merge type operation. But that mindset seems, at least around here, to have disappeared. I did the match merge code to show how to do it (with a dramatic reduction in CPU and elapsed time). The programmer considered __that__ to be too advanced and obscure. Perhaps that shows what __I__ now consider to be normal. It may well be sub normal in the rest of the world. -- John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
In order to do some necessary things, some smart programmers wrote some hard-to-maintain code using tricks. Would a weak programmer even know how to do it? Once they got a CoBOL compiler, that wasn't needed anymore. With that exception, I strongly agree with you that the best programmers created the easiest to maintain code. Easy is a relative term. If there is no other way to do it, it is the easiest to maintain. A weak programmer cannot overcome limitations of languages. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 2009-04-23 at 16:38 -0400, Tony Harminc wrote: 2009/4/23 David Andrews d...@lists.duda.com: On Thu, 2009-04-23 at 14:57 -0400, Bob Rutledge wrote: It's not [nonzero],0, it's 15,0. Hey, you're absolutely RIGHT. (I wonder if it's always been like this? Am I mis-remembering stuff from 35 years ago? ... and Tony Harminc reminded me of the bitsavers website: http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf The S360 PrincOps didn't say anything about serialization (of course), but I figured I'd look for something like a M91 Functional Characteristics book. I found the IBM System\360 Operating System Guide to Model 91 Support: http://bitsavers.org/pdf/ibm/360/C28--0_360-91_OSsupport.pdf which does by golly on page 7 refer to BCR M,0where M not= 0 So I didn't mis-remember! (Of course, I'm not all that current either. But that's another kettle of fish.) -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
David Andrews wrote: On Thu, 2009-04-23 at 14:57 -0400, Bob Rutledge wrote: It's not [nonzero],0, it's 15,0. Hey, you're absolutely RIGHT. (I wonder if it's always been like this? Am I mis-remembering stuff from 35 years ago? Anyone got a *really* old PrincOps?) I seem to recall BCR 1,0 in the Fortran G subroutines, and was under the impression that it was used for one of the machines we couldn't afford (75, 91, or 95)? Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Thursday, April 23, 2009 12:34 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?] -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Gibney, Dave wrote: I'm not really an assembler programmer, but I've known this one since my earliest days. I'm sure it was in the 370 Pop I used in my one and only assembler programming class in 1979. Good class, I have a job today because I took that class, did an internship the next semester and here I am today :) Which is a good reason for every company to sponsor an Assembler class for every one of their z/OS programmers, right? We're ready. :) Long ago and far away, during a group job interview (aka tour de farce), the interviewer stated that programmers could code CICS programs in their language of choice, whether it be C, COBOL or PL/I. I asked, Assembler? He replied, Anybody who even *thinks* about coding in Assembler should be shot! I bid them all Good Day and departed immediately. To this day I have the impression that many COBOL shops actually *fear* Assembler and/or anybody who professes even the slightest proficiency with it. -jc- That's what the internship was, took me a couple days to learn Cobol (perhaps my 4th or 5th language) just fresh out of the assembler class. A few years application programming, moved to general support of the production application environment for a few more, to systems programmer, been doing this ever since. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Effective pipeline programming [was:RE: METAL C: CodeGen defeciency?]
On Thu, 23 Apr 2009 20:32:30 +, Ted MacNEIL wrote: I find the weak programmers are the ones to use strange (and often misunderstood) tricks, or as we used to call it 'spaghetti code'. What's a trick? What's an idiom? In a recent discussion in TSO-REXX, Phil Smith, among others, urged that programmers understand the idioms of whatever language. I strongly agree; perhaps I go beyond his notion of idiom. A programmer fluent in other languages, and naive in HLASM might code IC ... STC in a loop and consider BCTR ... EX ... MVC a trick. Or, how about (Rexx): if XY then call foo ( 1 ) else call foo ( 0 ) /* versus: */ call foo ( xy ) /* ? */ (Superfluous parentheses added for benefit of weak programmers.) I unashamedly do the latter. Anyone who complains should simply read The Rexx Programming Language. Or: IF TRANSACTION_AMOUNT 0.00 THEN MASTER_TOTAL = MASTER_TOTAL + TRANSACTION_AMOUNT (This is a literal transcription of a specification that an imaginary accountant versed in desk calculator processes might have given a programmer: Why bother adding zero?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
