Re: Interesting? Mobile App (iOS Android) for IBM Redbooks
I (really) liked the move to epub - dunno about this. Maybe I should go back to dragging my tablet around rather than just the phone. Or maybe not. And why, oh why, is the video in Flash for gawds sake ?. Why do IBM need to be dragged kicking and screaming into (what some would hope to be) an open world. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Two questions about OSA
OSA Express5S 1000Base-T, EC12 machine. 1. I tried to use OSA/SF functionality from HMC, but noticed the following error: I cannot choose LPAR (MIFID), the list contains only 00 and 07 entries, which is not true. The same with UA the panel shows 00-05, while there are more devices defined. For another OSE chpid attempt to enter OSA/SF panel ends with error message. Has anyone used OSA/SF on HMC? Any observations? 2. OSA-ICC and IP_FILTER. I just RTFM, but still have doubts. I would like to define OSC server with IP 10.48.22.1/24 and allow all the machines within address range 10.48.22.2-254 to connect to given session. (note, OSC itself can be ignored) My idea: SESSION1 CSS= 00 IID= 01 DEVICE= 2201 GROUP= LU01 CONSOLE_TYPE= 1 RESPONSE= ON READ_TIMEOUT= 60 CLIENT_IP= 10.48.22.2 IP_FILTER= 255.255.255.0 /SESSION1 Will it work? -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Model Change -- Required activities
Every time I've reduced the machine's CPUs (either CBU or OOCoD), I've always varied CPUs offline from z/OS such that no running system has more CPUs online than what I'm reducing to. I'm not sure that it's an absolute requirement, but it seems like an easy precaution to take. Never have had a problem with adjusting things that way. Of course IBM making the change themselves may be somewhat different, but I wouldn't expect any problems. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
LOGICAL DUMP OF ARCIVE DATA SETS
Hello, One of our DR activities is backing up selected data set using DFSMSdss (a logical dump). Some of them were archived before by CA-DISK and cataloged to ARCIVE volser. How can we make DFSMSdss restore these datasets prior to real dump action, at the same step ? We know that we can first restore them and then to run the DUMP, but would like to avoid it. Avner לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEASYMxx in DR
Hello All, Just looking for a general idea of sharing IEASYMxx in DR site. How many of you intend to keep a different IEASYMxx member in production site and another for DR(Disaster recovery) site or else keeping One IEASYMxx across production and DR would be a good choice ? Just looking for some idea. Any pointers ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF AIM Stage 3 Issue
On Mon, 17 Feb 2014 07:54:35 +0530, venkat kulkarni venkatkulkarn...@gmail.com wrote: Initially my RACF DB was at AIM stage 1 but as the steps to converting BPX.UNIQUE.USER, I converted AIM stage 1 to AIM stage 3. As I have mentioned earlier as well, that along with z/OS 2.1, we have down level system(z/OS 1.13) as well sharing same RACF DB . Now after this BPX.UNIQUE.USER setup, when we tried starting Jobs, as I mentioned above getting same error about OMVS segment not defined. But as IBM manual, as now we have both BPX.UNIQUE.USER and BPX.DEFAULT.USER setup in RACF, so z/OS 1.13 should use BPX.DEFAULT.USER. But its not happening. If you setup BPX.UNIQUE.USER then both z/OS 2.1 and z/OS 1.13 will use it as the support for BPX.UNIQUE.USER is not new with z/OS 2.1. So, if you have BPX.UNIQUE.USER setup incorrectly then that would cause problems for both z/OS 2.1 and z/OS 1.13. I agree with Lizette that you should be discussing this in only one place, and that the RACF-L mailing list is the better place. Also, you're having enough problems that it may be time to get the IBM Support Center involved directly. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LOGICAL DUMP OF ARCIVE DATA SETS
ABARs can read HSM migrated datasets and write them to backup tapes. Maybe it can do the same for these datasets? On Mon, Feb 17, 2014 at 5:23 AM, אבנר מיכאלי avne...@malam.com wrote: Hello, One of our DR activities is backing up selected data set using DFSMSdss (a logical dump). Some of them were archived before by CA-DISK and cataloged to ARCIVE volser. How can we make DFSMSdss restore these datasets prior to real dump action, at the same step ? We know that we can first restore them and then to run the DUMP, but would like to avoid it. Avner לשימת לבך, בהתאם לנהלי חברת מלם מערכות בעמ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : החברה) וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam and/or its subsidiaries (hereinafter : Malam) regulations and signatory rights, no offer, agreement, concession or representation is binding on the Malam, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the Malam seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance question - adding
FWIW, If the branch technique is faster, and depending on how high a percentage most of the time (as in most of the time CURRENT will be zero) is, then the branch technique given as the alternative to no-branch is likely not optimal. Even with branch prediction technology, it is still better to have the expected path not take a branch. So, for example (when LT is available), LTRx,CURRENT JNZ Need_To_Add Return_From_Need_To_Add DS 0H ... Need_To_Add DS 0H A Rx,SUM STRx,SUM J Return_From_Need_To_Add Then you get to factor in how much readability is worth to you. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYMxx in DR
Our parmlib members (including IEASYMxx) are the same for home and DR. This reduces the level of surprise when we test/declare. The first DR IPL is done with an Operator prompt. This first IPL the sysplex specific settings are updated, before we re-IPL the full environment. Part of the reason we do it this way is because the DR supplier can't guarantee the hardware we'll run on (model/serial#), so the CFRM policy will need to be updated at the time of the test/declare. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Monday, February 17, 2014 6:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IEASYMxx in DR Hello All, Just looking for a general idea of sharing IEASYMxx in DR site. How many of you intend to keep a different IEASYMxx member in production site and another for DR(Disaster recovery) site or else keeping One IEASYMxx across production and DR would be a good choice ? Just looking for some idea. Any pointers ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IS the DCB represented by TCBJLB valid for FIND
Hi, Would anyone know if the DCB represented by TCBJLB valid for the FIND macro ? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEASYMxx in DR
The use of indirect references allows for modifying the symbolics dynamically 'artificially' i.e. SYMDEF(SYSF0='SYSR1(1:4).SYSFZOS.0') Penina Koenigsberg P 972-2-5602354 972-58-6540737 9 penin...@education.gov.il -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of mf db Sent: Monday, February 17, 2014 1:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IEASYMxx in DR Hello All, Just looking for a general idea of sharing IEASYMxx in DR site. How many of you intend to keep a different IEASYMxx member in production site and another for DR(Disaster recovery) site or else keeping One IEASYMxx across production and DR would be a good choice ? Just looking for some idea. Any pointers ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN div style=text-align: center;a href=http://edu.gov.il/lm;img src=http://meyda.education.gov.il/images/homepage_header_raze.png;/a/div -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Branch (was: Performance question - adding)
On Mon, 17 Feb 2014 07:49:18 -0500, Peter Relson wrote: If the branch technique is faster, and depending on how high a percentage most of the time (as in most of the time CURRENT will be zero) is, then the branch technique given as the alternative to no-branch is likely not optimal. Even with branch prediction technology, it is still better to have the expected path not take a branch. So, for example (when LT is available), (It's possible that CURRENT has just been calculated and CC is already set.) LTRx,CURRENT JNZ Need_To_Add Return_From_Need_To_Add DS 0H ... Need_To_Add DS 0H A Rx,SUM STRx,SUM J Return_From_Need_To_Add Is there a maxim here? When the programmer expects that a branch will usually be taken, is it better to avoid: BCC,USUALLY and code instad: BC15-C,*+8 B USUALLY ??? Then you get to factor in how much readability is worth to you. Macros are your friend. But does providing readability at the programming interface level make such a macro unpleasantly verbose internally? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. I don't know if this code avoid the cache thrashing mention by Ed. I don't know if the CPU needs to lock the cache line if the STOC is a NOP due to the CC being zero (from the LT) most of the time (per the OP). I used R0 and R1 only because I tend to use them, along with R14 and R15, as junk temporary registers. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 17/02/2014 10:25 PM, Paul Gilmartin wrote:
Then you get to factor in how much readability is worth to you.
Macros are your friend. But does providing readability at the
programming interface level make such a macro unpleasantly
verbose internally?
Unless your desperately need highly optimized code readability is very
important when writing assembler code. I suppose that's definitely the
case for most vendors.
The alternative is to use an optimizing compiler which go out of their
way to remove branches. The following code snippet is a simple routine
to convert a flag byte into a string of binary 1s and 0s. The optimizer
unrolled the loop and used those fancy new load on condition
instructions to remove all branches.
I compiled two versions, one with loop unrolling and one without using
the #pragma nounroll directive. The unrolled version was x3 faster! Now
that's impressive.
* static char buffer[CHAR_BIT + 1];
* int i;
* int numBits = CHAR_BIT;
*
* for ( i = 0; numBits--; i++ )
LR r3,r1
* {
* buffer[i] = ( c 0x80 ) ? '1' : '0';
LA r0,240
NILF r1,F'128'
LA r8,241
LA r9,241
NILF r3,F'255'
LA r10,241
LTR r1,r1
SLLK r1,r3,1
LOCREr8,r0
LR r3,r1
NILF r1,F'128'
LA r11,241
NILF r3,F'255'
STC r8,buffer[]0(,r5,9)
LA r2,241
LTR r1,r1
SLL r3,1
LR r1,r3
LOCREr9,r0
NILF r3,F'128'
STC r9,buffer[]0(,r5,10)
NILF r1,F'255'
LTR r3,r3
SLL r1,1
LOCREr10,r0
STC r10,buffer[]0(,r5,11)
* c = 1;
LR r3,r1
NILF r1,F'128'
NILF r3,F'255'
LTR r1,r1
SLLK r1,r3,1
LR r3,r1
LOCREr11,r0
NILF r3,F'255'
STC r11,buffer[]0(,r5,12)
LA r8,241
SLLK r9,r3,1
NILF r1,F'128'
LR r10,r9
LA r11,241
LTR r1,r1
LOCREr8,r0
NILF r10,F'255'
NILF r9,F'128'
STC r8,buffer[]0(,r5,13)
LTR r9,r9
SLLK r8,r10,1
LOCREr11,r0
LR r9,r8
NILF r8,F'128'
LA r1,241
NILF r9,F'255'
STC r11,buffer[]0(,r5,14)
* }
*
* buffer[i] = '\0';
*
* return buffer;
LA r3,buffer(,r5,9)
LTR r8,r8
SLLK r8,r9,1
LOCREr1,r0
NILF r8,F'128'
STC r1,buffer[]0(,r5,15)
LTR r8,r8
LOCREr2,r0
STC r2,buffer[]0(,r5,16)
MVI buffer[]0(r5,17),0
* }
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance question - adding
On 17/02/2014 3:32 AM, Ed Jaffe wrote: On 2/16/2014 1:10 AM, Binyamin Dissen wrote: Say I have two words, CURRENT DS F SUM DS F I want to add CURRENT to SUM, but most of the time CURRENT will be zero. CURRENT and SUM are not adjacent (different data lines) If only a single unit of work and both fields are in the same 256-byte cache line, I predict it will be faster just to add them - no branch. However, if multiple units of work simultaneously executing on different CPs will be doing this operation, then I would consider the branch technique to avoid cache thrash. It's interesting you should mention that because I was looking at a concurrent queue implementation for x86 just the other day and all the node data structures were padded to fit into a cache line. That seemed like an enormous waste of space but I suppose it's a space for time trade-off. If a consumer was popping while a producer was pushing and the queue was small that would thrash the cache. Phew, concurrent programming is tricky! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IS the DCB represented by TCBJLB valid for FIND
On 2/17/2014 8:23 AM, MichealButz wrote: Would anyone know if the DCB represented by TCBJLB valid for the FIND macro Would anybody know whether it's faster to run a test job than ask on a list, especially if the question has already be answered in this thread? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IS the DCB represented by TCBJLB valid for FIND
Yes. And also it depends. Bill Fairchild Nolensville, TN - Original Message - From: Gerhard Postpischil gerha...@charter.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, February 17, 2014 9:50:48 AM Subject: Re: IS the DCB represented by TCBJLB valid for FIND On 2/17/2014 8:23 AM, MichealButz wrote: Would anyone know if the DCB represented by TCBJLB valid for the FIND macro Would anybody know whether it's faster to run a test job than ask on a list, especially if the question has already be answered in this thread? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IS the DCB represented by TCBJLB valid for FIND
I think the DCB has to be owned by the TCB ? Sent from my iPhone On Feb 17, 2014, at 10:57 AM, DASDBILL2 dasdbi...@comcast.net wrote: Yes. And also it depends. Bill Fairchild Nolensville, TN - Original Message - From: Gerhard Postpischil gerha...@charter.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, February 17, 2014 9:50:48 AM Subject: Re: IS the DCB represented by TCBJLB valid for FIND On 2/17/2014 8:23 AM, MichealButz wrote: Would anyone know if the DCB represented by TCBJLB valid for the FIND macro Would anybody know whether it's faster to run a test job than ask on a list, especially if the question has already be answered in this thread? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Nice! I got to thinking it would be nice to have a store different instruction (or make store behave this way automatically under the covers) which would invalidate the cache only if what it were storing were different from what was in memory already. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 6:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Branch (was: Performance question - adding) Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. I don't know if this code avoid the cache thrashing mention by Ed. I don't know if the CPU needs to lock the cache line if the STOC is a NOP due to the CC being zero (from the LT) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, 17 Feb 2014 08:02:40 -0800, Charles Mills wrote: I got to thinking it would be nice to have a store different instruction (or make store behave this way automatically under the covers) which would invalidate the cache only if what it were storing were different from what was in memory already. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 6:37 AM Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Doesn't one also want to avoid fetching the line into cache if it's not already there? I once examined the circuit diagram of some 3rd-party add-on DRAM for a PDP-12 we had. The hardware compared the data to be stored with that already in memory and bypassed the write-back if identical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Another possibility which occurs to me, on newer hardware, is to try out the BPRP instruction. This also addresses Gil's thought about not fetching the cache line containing SUM unless it is necessary. Remember this assumes that CURRENT is almost always a zero, per the OP. * * SET UP BRANCH PREDICTION ON JZ * INSTRUCTION TO NOADD LABEL BPRP 8,JZ,NOADD PREDICT BRANCH IS TAKEN LT R0,CURRENT JZ JZ NOADD ADD R0,SUM ST R0,SUM NOADD DS 0H On Mon, Feb 17, 2014 at 10:02 AM, Charles Mills charl...@mcn.org wrote: Nice! I got to thinking it would be nice to have a store different instruction (or make store behave this way automatically under the covers) which would invalidate the cache only if what it were storing were different from what was in memory already. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 6:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Branch (was: Performance question - adding) Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. I don't know if this code avoid the cache thrashing mention by Ed. I don't know if the CPU needs to lock the cache line if the STOC is a NOP due to the CC being zero (from the LT) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. - -teD - Original Message From: John McKown Sent: Monday, February 17, 2014 12:02 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Branch (was: Performance question - adding) Another possibility which occurs to me, on newer hardware, is to try out the BPRP instruction. This also addresses Gil's thought about not fetching the cache line containing SUM unless it is necessary. Remember this assumes that CURRENT is almost always a zero, per the OP. * * SET UP BRANCH PREDICTION ON JZ * INSTRUCTION TO NOADD LABEL BPRP 8,JZ,NOADD PREDICT BRANCH IS TAKEN LT R0,CURRENT JZ JZ NOADD ADD R0,SUM ST R0,SUM NOADD DS 0H On Mon, Feb 17, 2014 at 10:02 AM, Charles Mills charl...@mcn.org wrote: Nice! I got to thinking it would be nice to have a store different instruction (or make store behave this way automatically under the covers) which would invalidate the cache only if what it were storing were different from what was in memory already. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 6:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Branch (was: Performance question - adding) Combining the thoughts engendered from about three replies, I wonder if avoiding a branch as follows (on a processor which supports the instructions) would perform better than branching. LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. I don't know if this code avoid the cache thrashing mention by Ed. I don't know if the CPU needs to lock the cache line if the STOC is a NOP due to the CC being zero (from the LT) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Good question. This is why I asked that loop question earlier today. But I'm following this fun thread about the cache, fetch/modify by different CPs and execution prediction. Just curious of course. Optimisation of a few is not worth the effort these days. After my question, someone posted me off-line that if the machine only execute ONE instruction PER second, then only, then this optimisation work is worth the trouble. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, Feb 17, 2014 at 12:03 PM, Paul Gilmartin paulgboul...@aim.comwrote: On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- gil I guess that I ASSuMEd that the code was in a heavily used loop. If you remove 1 instruction from a loop which is executed a million times, assuming the instruction is expensive, then it may well be worth the effort. Or maybe even replacing it with two simpler instructions (such as my thought on using IPM and SPM with an STOC instead of a JZ and ST). -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, Feb 17, 2014 at 12:06 PM, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Good question. This is why I asked that loop question earlier today. But I'm following this fun thread about the cache, fetch/modify by different CPs and execution prediction. Just curious of course. Optimisation of a few is not worth the effort these days. After my question, someone posted me off-line that if the machine only execute ONE instruction PER second, then only, then this optimisation work is worth the trouble. Groete / Greetings Elardus Engelbrecht Of course, IBM is trying to make this discussion moot by getting people off of using assembler at all, and implementing a code generation back end which will produce better than the average HLASM programmer code for C/C++, Java, and COBOL (COBOL code generation, pre-V5.1 at least, really stinks IMO). I don't know if IBM worries as much about FORTRAN and PL/I these days. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Need help on SORT solution
The following DFSORT JCL will give you the desired results. The trick here is to join the file to itself which results in a cartesian join. example. You have 8 records as sample in here, a cartesian join on the key would result in (8 X 8 = 64 records). Out of the 64 records you don't want the records which are a match to themselves, so you need to eliminate them and you are left with 56 records. ie every record is matched with 7 other records. Once you have the cartesian join, use the operator RESIZE to combine all the 7 records per key into a single record. Once you created a long record we then have the option of picking the values as needed. //STEP0100 EXEC PGM=ICETOOL //TOOLMSG DD SYSOUT=* //DFSMSG DD SYSOUT=* //INA DD * PARA_1VAR_1 A PARA_1VAR_1 TEST1 PARA_1VAR_2 B PARA_1VAR_2 TEST2 PARA_1VAR_3 C PARA_1VAR_3 TEST3 PARA_1VAR_4 D PARA_1VAR_4 TEST4 //INB DD * PARA_1VAR_1 A PARA_1VAR_1 TEST1 PARA_1VAR_2 B PARA_1VAR_2 TEST2 PARA_1VAR_3 C PARA_1VAR_3 TEST3 PARA_1VAR_4 D PARA_1VAR_4 TEST4 //T1 DD DSN=T1,DISP=(,PASS),SPACE=(CYL,(25,25),RLSE) //OUT DD SYSOUT=* //TOOLIN DD * COPY JKFROM TO(T1) USING(CTL1) RESIZE FROM(T1) TO(OUT) TOLEN(1120) USING(CTL2) //* //CTL1CNTL DD * JOINKEYS F1=INA,FIELDS=(1,10,A),SORTED,NOSEQCK JOINKEYS F2=INB,FIELDS=(1,10,A),SORTED,NOSEQCK REFORMAT FIELDS=(F1:1,80,F2:1,80) OMIT COND=(1,80,CH,EQ,81,80,CH) INREC IFOUTLEN=160, IFTHEN=(WHEN=GROUP,KEYBEGIN=(1,80),PUSH=(161:SEQ=3)), IFTHEN=(WHEN=(161,3,ZD,GT,1),OVERLAY=(01:80X)) //* //CTL2CNTL DD * OUTFIL FNAMES=OUT, BUILD=(0001,80,261,60,581,60,901,60,60X,/, 0001,80,101,60,421,60,741,60,1061,60) //* Kolusu DFSORT Development IBM Corporation IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 02/14/2014 10:29:35 PM: From: adarsh khanna adarshkha...@yahoo.com To: IBM-MAIN@listserv.ua.edu, Date: 02/14/2014 10:31 PM Subject: Need help on SORT solution Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Hi, We have a requirement to generate all possible combinations of below input and need help to achieve it using SORT. Para_1Var_1A Para_1Var_1Test Para_1Var_2B Para_1Var_2Test Para_1Var_3C Para_1Var_3Test Para_1Var_4D Para_1Var_4Test Expected output is all combinations of each Var* Var* should be of 10 bytes (if text is less than 10 bytes, padd it with spaces) A, B, C, Text... should be of 60 bytes (if text is less than 60 bytes, padd it with spaces) Output: Para_1Var_1...(Total 10 bytes)..A (Total 60 bytes)...Var_2B...Var_3...C Para_1Var_1...(Total 10 bytes)..Test (Total 60 bytes)...Var_2B...Var_3...C Para_1Var_1...(Total 10 bytes)..Test (Total 60 bytes)...Var_2Test...Var_3...C .. Thanks Adarsh -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Or if you are writing a compiler (or similar code generator, such as a sort compare generator, or a SQL implementation). One instruction saved X a million compiles = a million instructions saved. Some of us here do things of that type. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, February 17, 2014 10:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Branch (was: Performance question - adding) On Mon, Feb 17, 2014 at 12:03 PM, Paul Gilmartin paulgboul...@aim.comwrote: On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- gil I guess that I ASSuMEd that the code was in a heavily used loop. If you remove 1 instruction from a loop which is executed a million times, assuming the instruction is expensive, then it may well be worth the effort. Or maybe even replacing it with two simpler instructions (such as my thought on using IPM and SPM with an STOC instead of a JZ and ST). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On a 600 MIPS single engine (z/990 class) 1,000,000 instructions is 0.17% of a CP. These days? - -teD - Original Message From: John McKown Sent: Monday, February 17, 2014 13:15 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Branch (was: Performance question - adding) On Mon, Feb 17, 2014 at 12:03 PM, Paul Gilmartin paulgboul...@aim.comwrote: On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- gil I guess that I ASSuMEd that the code was in a heavily used loop. If you remove 1 instruction from a loop which is executed a million times, assuming the instruction is expensive, then it may well be worth the effort. Or maybe even replacing it with two simpler instructions (such as my thought on using IPM and SPM with an STOC instead of a JZ and ST). -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
What does the statement | 1,000,000 instructions is 0.17% of a CP mean? What are the dimensions of % John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, 17 Feb 2014 14:04:56 -0500, John Gilmore wrote: What does the statement | 1,000,000 instructions is 0.17% of a CP mean? What are the dimensions of % I don't know, but it would appear to be a gross oversimplification. Ted should know as well as anyone here that MIPS is meaningless, and that a snippet of code taken out of context doesn't tell much. We don't know why the OP was concerned, but that doesn't mean that his concern isn't valid. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IS the DCB represented by TCBJLB valid for FIND
Yep, you asked this before, I guess you forgot …. Sent from Windows Mail From: MichealButz Sent: Monday, February 17, 2014 5:23 AM To: IBM Mainframe Discussion List Hi, Would anyone know if the DCB represented by TCBJLB valid for the FIND macro ? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IS the DCB represented by TCBJLB valid for FIND
I'm sorry to all I got it Thanks Sent from my iPhone On Feb 17, 2014, at 6:06 PM, Scott Ford scott_j_f...@yahoo.com wrote: Yep, you asked this before, I guess you forgot …. Sent from Windows Mail From: MichealButz Sent: Monday, February 17, 2014 5:23 AM To: IBM Mainframe Discussion List Hi, Would anyone know if the DCB represented by TCBJLB valid for the FIND macro ? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
I develop vendor code. Customers always ask about CPU time. If I answered oh we don't worry about that anymore do you think they would buy? Do you think I would have a job? Charles Composed on a mobile: please excuse my brevity Ted MacNEIL eamacn...@yahoo.ca wrote: On a 600 MIPS single engine (z/990 class) 1,000,000 instructions is 0.17% of a CP. These days? - -teD - Original Message From: John McKown Sent: Monday, February 17, 2014 13:15 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Branch (was: Performance question - adding) On Mon, Feb 17, 2014 at 12:03 PM, Paul Gilmartin paulgboul...@aim.comwrote: On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. Hmmm... No single instruction is worth optimizing. No single instruction among a million is worth optimizing. It's not worth optimising a million instructions because that would imply optimizing each, which is not worth it. E.E. asked whether the code is in a loop. -- gil I guess that I ASSuMEd that the code was in a heavily used loop. If you remove 1 instruction from a loop which is executed a million times, assuming the instruction is expensive, then it may well be worth the effort. Or maybe even replacing it with two simpler instructions (such as my thought on using IPM and SPM with an STOC instead of a JZ and ST). -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
How to issue TSO prompts in batch
-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF AIM Stage 3 Issue
On Mon, 17 Feb 2014 17:19:32 +0530, venkat kulkarni venkatkulkarn...@gmail.com wrote: Hello, Thanks for reply. But as per IBM link, it says it we have down level system well sharing RACF then older system will use BPX.DEFAULT.USER if, they are not supported by BPX.UNIQUE.USER. That's undoubtedly true, but BPX.UNIQUE.USER has existed since z/OS 1.11, and so your z/OS 1.13 system does support it, and will use it. IBM has been telling customers for several years that they should be using it, rather than BPX.DEFAULT.USER. All that is new in z/OS 2.1 in this are is that BPX.DEFAULT.USER is no longer supported, rather than merely being not recommended. I also mentioned steps I followed for this BPX.UNIQUE.USER setup. But not able to what I missed out. You did not tell us everything, though. For example, you omitted what you did to setup BPX.NEXT.USER. We need to see everything. (Actually, we on IBM-MAIN don't need it, but the folks on RACF-L and the IBM Support Center will need it.) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to issue TSO prompts in batch
On Mon, 17 Feb 2014 14:11:32 -0600, Greg Kreth wrote: How to issue TSO prompts in batch Why bother? Whom would you expect to reply to such a prompt? If I have a program that insists on issuing a prompt, such as RECEIVE, I can (sometimes) stage a reply with a Rexx queue instruction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
Benchmarks, features, tuning knobs, performance bonds all factor in to the mix. The ones that scare me are the 'theoretically we can run some gazillion transactions on a mainframe'! In a message dated 2/17/2014 2:18:47 P.M. Central Standard Time, charl...@mcn.org writes: I develop vendor code. Customers always ask about CPU time. If I answered oh we don't worry about that anymore do you think they would buy? Do you think I would have a job? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On Mon, Feb 17, 2014 at 11:36 AM, Ted MacNEIL eamacn...@yahoo.ca wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. - -teD - OK, this then causes me to wonder why IBM has bothered to create instructions such as Load On Condition and Store On Condition. The manual in the STOC says: quote STORE ON CONDITION provides a function similar to that of a separate BRANCH ON CONDITION instruction followed by a STORE instruction, except that STORE ON CONDITION does not provide an index register. For example, the following two instruction sequences are equivalent. STOCG 15,256(7),8 BC 7,SKIP STG 15,256(7) SKIP DS 0H On models that implement predictive branching, the combination of the BRANCH ON CONDITION and STORE instructions may perform somewhat better than the STORE ON CONDITION instruction when the CPU is able to successfully predict the branch condition. However, on models where the CPU is not able to successfully predict the branch condition, such as when the condition is more random, the STORE ON CONDITION instruction may provide significant performance improvement. /quote The above makes me wonder if my example of using the BPRP (does anyone else read that as burper?) instruction, since I _know_ at that point that the branch _will be_ taken should be used instead of the STOC. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to issue TSO prompts in batch
On 2/17/2014 3:11 PM, Greg Kreth wrote: PUTLINE and GETLINE (and PUTGET) will work in both online and offline environments, but your input file (SYSTSIN?) must have all expected replies. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to issue TSO prompts in batch
Matthew: Not much point since I moved to California last year. Thanks for the thought, and good luck with the weather back east. It's sunny here but with the drought, we may dry up and blow away. Moral is there is no perfect place. Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, February 17, 2014 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to issue TSO prompts in batch On Mon, 17 Feb 2014 14:11:32 -0600, Greg Kreth wrote: How to issue TSO prompts in batch Why bother? Whom would you expect to reply to such a prompt? If I have a program that insists on issuing a prompt, such as RECEIVE, I can (sometimes) stage a reply with a Rexx queue instruction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Optimization, CPU time, and related issues
Starting a new thread . It seems to me that as the hardware has gotten faster and faster, it is tempting to think that optimization and CPU time no longer matter. I think three things have conspired to make that thought not true: 1. Of course as hardware has gotten faster and faster, transaction volumes have gotten greater. The one instruction that used to get executed 100,000 times a day now gets executed a million times a day. 2. Much of the increase in speed has been due to increased numbers of processors per box. That gives the customer more MIPS but it is no help to processes that are either inherently single-thread, or have been implemented in a way that makes them single thread, and must be completed within some finite window. 3. Most significantly, as machines have gotten faster, customers have also gotten much more cost conscious, and are very aware that every instruction brings them closer to the day that they have to upgrade the box, which will bring an inevitable major increase in the cost of IBM and non-IBM software. It would be an interesting exercise to try to figure out an estimated dollar cost for a million instructions executed per day, using an assumed typical installation and an assumed typical mix of IBM and non-IBM software -- on the assumption that those million instructions represent x% of the need to upgrade to a faster box, and the increase in costs, hardware and software, due to that upgrade. Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to issue TSO prompts in batch
Sorry for the mis-post. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike La Martina Sent: Monday, February 17, 2014 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to issue TSO prompts in batch Matthew: Not much point since I moved to California last year. Thanks for the thought, and good luck with the weather back east. It's sunny here but with the drought, we may dry up and blow away. Moral is there is no perfect place. Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, February 17, 2014 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to issue TSO prompts in batch On Mon, 17 Feb 2014 14:11:32 -0600, Greg Kreth wrote: How to issue TSO prompts in batch Why bother? Whom would you expect to reply to such a prompt? If I have a program that insists on issuing a prompt, such as RECEIVE, I can (sometimes) stage a reply with a Rexx queue instruction. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
My objection to sentiments like . . . as the hardware has gotten faster and faster, it is tempting to think that optimization and CPU time no longer matter. is of a different sort. They erode the notion that craftsmanship is important. It is easy to make fun of attempts to shave a µsec from the CP time of an I/O-bound transaction, but it remains important to try to get things right during development. The prayerbook's 'sure and certain hope of resurrection to eternal life' is not so widespread as it once was, but we can be very sure that entropy and maintenance will make things worse. In general, blunders aside, things are better out of the box than they will ever be again. Thus, while there is certainly a perspective from which these discussions are silly, they may be helpful if some guidance for writing new code comes out of them. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
Agreed. Pride of craftsmanship (like anything else, if not taken to an unproductive extreme) is worthwhile. Also, and I almost posted this on the other thread, these problems are just plain interesting and intellectually challenging. Many hours and many pages have been devoted to the Knight's Tour problem (http://en.wikipedia.org/wiki/Knight's_tour). Like a discussion of the fastest way to add two numbers one of which is most likely zero, it has nothing to do with the real-life problem -- it its case, the real problem being winning a chess match. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Monday, February 17, 2014 2:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Optimization, CPU time, and related issues My objection to sentiments like . . . as the hardware has gotten faster and faster, it is tempting to think that optimization and CPU time no longer matter. is of a different sort. They erode the notion that craftsmanship is important. It is easy to make fun of attempts to shave a µsec from the CP time of an I/O-bound transaction, but it remains important to try to get things right during development. The prayerbook's 'sure and certain hope of resurrection to eternal life' is not so widespread as it once was, but we can be very sure that entropy and maintenance will make things worse. In general, blunders aside, things are better out of the box than they will ever be again. Thus, while there is certainly a perspective from which these discussions are silly, they may be helpful if some guidance for writing new code comes out of them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Feb 17, 2014, at 3:42 PM, Charles Mills wrote:
Starting a new thread .
--
SNIP--
2. Much of the increase in speed has been due to increased numbers of
processors per box. That gives the customer more MIPS but it is
no help to
processes that are either inherently single-thread, or have been
implemented
in a way that makes them single thread, and must be completed
within some
finite window.
3. Most significantly, as machines have gotten faster, customers
have also
gotten much more cost conscious, and are very aware that every
instruction
brings them closer to the day that they have to upgrade the box,
which will
bring an inevitable major increase in the cost of IBM and non-IBM
software.
---
SNIP
Charles,
I am sort of in agreement but, about 30 years ago I worked at a
company that (at least one division) really went whole hog on the
idea of multithreading.
Their online system ran transaction on multiple (30+)TCB's . Their
production batch ran many many TCB's and they really used the system
in an efficient way.
As an example one of their production jobs each ran 6-10 (sometimes
only one) active TCB('s). It of course was all done in assembler.
Even coding as efficient as they did they pinned the needle at 100
percent on a multiprocessor (both sides) if there had been available
another processor they would have pinned that as well and perhaps
more (this is well guessed conjecture).
The problem was (at that time the speed of a 168-3 (MP)was the
fastest IBM computer that was available (at least to the public).
There were two major issues they always wanted more CPU and the code
was pretty much unintelligible to most programmers.
There was just no way that they could keep up with the CPU demand, it
was insatiable.
I do not remember if they were on a monthly cycle or their own (its
been a long time).
The point I am trying to make is that throwing cpu cycles at it does
not always solve the problem. Optimization did little for them as
they were CPU intensive.
They were always looking for ways to optimize their code the small
nibs that they gained were sucked up by other processes.
I think if IBM could have delivered one of their modern day systems
it would be sucked dry as well.
Lesson for me is that a well written process can only be be fed just
so much resources.
I would love to see what would have happened on a current processor
say a 64 way .
Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 17 February 2014 09:37, John McKown john.archie.mck...@gmail.com wrote: LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. Not that it affects your proposal, but I think your SPM and IPM are reversed there... It's perhaps interesting that IPM appeared only in 370/XA; on 24-bit systems BALR was expected to do. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 2014-02-17, at 10:36, Ted MacNEIL wrote: I have to ask: Why they big concern over a few instructions? Optimisation of a few is not worth the effort these days. LOL. If Binyamin's question wasn't worth asking, then IBM would never have recently introduced the STOC instruction that John McKown so kindly reminded us about. (Wish we could use instructions like that in other than our JIT-compiled Java code...) If most simple instructions run in roughly one cycle (with the wind at their back i.e., no interlocks or other delays), an L1 memory access is zero cycles, and an uncached memory access is roughly 1000 cycles, then it makes perfect sense for professional programmers to want to understand how they might avoid having even a small code fragment run three orders of magnitude slower. Add enough of them up and it can make a big difference. If professionals never ask questions, they'll never know the answers when they need them. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to issue TSO prompts in batch
Thanks for the replies, everyone! I think the easiest way to do this is simply to add a RENAME command into TSO command string, i.e.: I started simply enough: //TSORCV EXEC PGM=IKJEFT01,DYNAMNBR=300 //SYSTSIN DD * RENAME 'DPGDK.TRANSFER.LOAD' 'DPGDK.TRANSFER.LOAD.TEMP' RECEIVE RESTORE This seems to do what I want. I'll need to know in advance that the PDS exists, but then, I would have had to know that, anyway. All's well that ends well! Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On 2/17/2014 1:42 PM, Charles Mills wrote: It would be an interesting exercise to try to figure out an estimated dollar cost for a million instructions executed per day, using an assumed typical installation and an assumed typical mix of IBM and non-IBM software Sub-capacity pricing for IBM MLC software products is based on peak, monthly, rolling four-hour average utilization of the LPARs in which the software products ran at any time that month. The measurement granularity is just one MSU (approximately 4-6 MIPS depending on CPU type/model). If a program generally runs off-shift (e.g., nightly batch window) then increasing or decreasing by one MSU probably will have no effect on billing. But, if the program generally runs during peak shift (e.g., 2-4pm), then increasing or decreasing by one MSU could have a _tremendous_ impact on monthly software charges; the price for every software product in those LPARs goes up! Things are even worse for IBM IPLA-style products. Exceeding entitled capacity by even just one MSU translates into an immediate order for additional capacity. Besides paying for the upgrade on all of the IPLA licensed products, the annual SS contracts go up as well... Bottom line: every developer should try to write code that runs as fast as possible. A single MSU increase at just the wrong time could translate into huge $$. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MF (z) waxing/waning in Columbia SC
I am curious about the mainframes (z/9 z/10 z/196) local waxing/waning here in Columbia SC. BlueCross and BlueShield of SC is one of the larger z/196 non federal government shops in the US (somewhere in top 10%). Then there is CSC at Blythewood, AFAIK. And there is the IT-oLogy consortium (Google it), but its focus seems much broader than MF or SC. The SC state Budget and Control shop still has a z/10 or above, again AFAIK, as I suppose does SCANA but I was told that the University of SC was moving away from MF toward other technologies. This in itself is a real disappointment, since if all the above are still going strong there should be future local opportunities. Anyone here in Columbia SC or nearby on a z box, moving toward or away? Another OLD (70) geezer hanging on till they pry. David Speake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Edit Mauling of previous post
I'm going to start keying these things in ISREDIT and then CUT/PASTE. Yeach! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
Hello, when we discussed the one bit copy topic recently, I had a solution in mind that was kind of inspired by the new store on condition instruction, but there was no such solution, because a instruction like OI on condition or NI on condition would have been necessary, and there are no such instructions. Now my question: I could imagine some use cases for a new instruction, that supresses the execution of the next instruction, depending on certain values of the condition code. For example SKIP NEXT INSTRUCTION IF NOT ZERO, or IF ZERO. This would be much more general than store on condition, because you could skip every instruction (not only ST), depending on the condition code. Of course, this needs some extensions to the machine logic, because it must be possible that only the PSW will be incremented but the instruction is not executed, depending on this SKIP condition. But: it saves some branches in some cases. My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... Kind regards Bernd Am 18.02.2014 00:36, schrieb Ed Jaffe: Bottom line: every developer should try to write code that runs as fast as possible. A single MSU increase at just the wrong time could translate into huge $$. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MF (z) waxing/waning in Columbia SC
Hello David, tuco bonno here. you probably remember me. sc bcb has two z10-s , 14 lpars. work load stable neither moving off of nor toward more m/f usage. moving very s-l-o-w-l-y into VM and linuxen app-s under VM /s/ tuco bonno ; graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho chi Minh Trail - tiến lên !! From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of David Speake [david.spe...@bcbssc.com] Sent: Monday, February 17, 2014 19:14 To: IBM-MAIN@LISTSERV.UA.EDU Subject: MF (z) waxing/waning in Columbia SC I am curious about the mainframes (z/9 z/10 z/196) local waxing/waning here in Columbia SC. BlueCross and BlueShield of SC is one of the larger z/196 non federal government shops in the US (somewhere in top 10%). Then there is CSC at Blythewood, AFAIK. And there is the IT-oLogy consortium (Google it), but its focus seems much broader than MF or SC. The SC state Budget and Control shop still has a z/10 or above, again AFAIK, as I suppose does SCANA but I was told that the University of SC was moving away from MF toward other technologies. This in itself is a real disappointment, since if all the above are still going strong there should be future local opportunities. Anyone here in Columbia SC or nearby on a z box, moving toward or away? Another OLD (70) geezer hanging on till they pry. David Speake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On 2/17/2014 7:34 PM, Bernd Oppolzer wrote: My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... The IBM 704/709/709x machines had several SKIP instruction types (Compare[one or two skips], Compare Logical[1 or 2 skips], Test Sense Switch); using the latter I could create a print string (0/1 for 6 switches) with fourteen instructions. However, all instructions were the same length, which avoided problems. On zOS machines you'd need to specify the skip amount to make them usable in general, or use macros? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
Isn't it called Jump, or more properly, Branch Relative on Condition? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, February 17, 2014 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Optimization, CPU time, and related issues Hello, when we discussed the one bit copy topic recently, I had a solution in mind that was kind of inspired by the new store on condition instruction, but there was no such solution, because a instruction like OI on condition or NI on condition would have been necessary, and there are no such instructions. Now my question: I could imagine some use cases for a new instruction, that supresses the execution of the next instruction, depending on certain values of the condition code. For example SKIP NEXT INSTRUCTION IF NOT ZERO, or IF ZERO. This would be much more general than store on condition, because you could skip every instruction (not only ST), depending on the condition code. Of course, this needs some extensions to the machine logic, because it must be possible that only the PSW will be incremented but the instruction is not executed, depending on this SKIP condition. But: it saves some branches in some cases. My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... Kind regards Bernd Am 18.02.2014 00:36, schrieb Ed Jaffe: Bottom line: every developer should try to write code that runs as fast as possible. A single MSU increase at just the wrong time could translate into huge $$. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU Model Change -- Required activities
An additional note : You may also need to renew the license keys for all CPU dependent ISV products such as syncsort/ SAS /ASG softwares etc Regards, Baby On Mon, Feb 17, 2014 at 4:42 PM, Scott Chapman sachap...@aep.com wrote: Every time I've reduced the machine's CPUs (either CBU or OOCoD), I've always varied CPUs offline from z/OS such that no running system has more CPUs online than what I'm reducing to. I'm not sure that it's an absolute requirement, but it seems like an easy precaution to take. Never have had a problem with adjusting things that way. Of course IBM making the change themselves may be somewhat different, but I wouldn't expect any problems. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Mon, 17 Feb 2014 20:05:12 -0500, Gerhard Postpischil wrote: On 2/17/2014 7:34 PM, Bernd Oppolzer wrote: My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... The IBM 704/709/709x machines had several SKIP instruction types (Compare[one or two skips], Compare Logical[1 or 2 skips], Test Sense Switch); using the latter I could create a print string (0/1 for 6 switches) with fourteen instructions. However, all instructions were the same length, which avoided problems. On zOS machines you'd need to specify the skip amount to make them usable in general, or use macros? The Data General Nova had no condition code register; rather every RR instruction had a condition mask selecting the condition on which the next instruction would be skipped or not. Also, a bit which suppressed loading the target register: Don't load; just test. One might code a fairly long sequence of interleaved RR instructions beginning with a conditional skip and followed by any number of unconditional skips until the paths finally merged at the bottom. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On Mon, Feb 17, 2014 at 6:34 PM, Bernd Oppolzer bernd.oppol...@t-online.dewrote: Hello, when we discussed the one bit copy topic recently, I had a solution in mind that was kind of inspired by the new store on condition instruction, but there was no such solution, because a instruction like OI on condition or NI on condition would have been necessary, and there are no such instructions. Now my question: I could imagine some use cases for a new instruction, that supresses the execution of the next instruction, depending on certain values of the condition code. For example SKIP NEXT INSTRUCTION IF NOT ZERO, or IF ZERO. This would be much more general than store on condition, because you could skip every instruction (not only ST), depending on the condition code. Of course, this needs some extensions to the machine logic, because it must be possible that only the PSW will be incremented but the instruction is not executed, depending on this SKIP condition. But: it saves some branches in some cases. My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... Kind regards Bernd I was thinking of something similar, but from the other side. An execute on condition type instruction. It would be like the EX and EXRL instructions, except that: where they have the R1 field, which designates the register used to modify the EXecuted instruction, the EXConditional would have an M1 field like the mask in the Branch instructions which says whether the instruction pointed to by the second operand is executed (unmodified) or not. I don't know how the machines actually work inside (hardwired and millicoded instructions), but it seems to me that an EXC might use some of the same hardware functionality. Your skip could be implemented if IBM did an EXCI (not the CICS EXCI) which would be an EXecute Conditional Immediate. I'm just a bit concerned about the possibility of the EXecuted immediate instruction getting a program interrupt, such as a page fault. I don't know how tricky the instruction decoding would need to be. With an EXCI, the next instruction could be 2, 4, or 6 bytes and so the IC would need to be incremented by the proper amount. With the EXC (or EXCRL), the instruction length is always 4 or 6 bytes, so updating the PSW address for the next instruction is a fixed amount. I also had the same thought about how well this would fit in and also whether it was worth it in terms of hardware cost to develop and test. I never did really come up with any good example to show how this would be really useful. I saw a wonderful ARM code sequence in their assembler to compute the GCD of a number. It was 5 assembler instructions. Unfortunately, it used another ARM difference in that the ARM subtract instruction can set the CC or not as desired by the programmer. And this code depends on the subtract _not_ disturbing the CC set by the initial compare. GCD CMP R0,R1 SUBGT R0,R0,R1 IF GT FROM CMP THEN R0-=R1 SUBLT R1,R1,R0 IF LT FROM CMP THEN R1-=R0 BNE GCD IF NOT EQUAL FROM CMP THEN LOOP ; R0 CONTAINS GCD The SUBGT and SUBLT don't disturb the condition code from the CMP. The z doesn't have a way do go general arithmetic which doesn't set the condition code. Yes, it could be done with the IPM and a couple of SPMs, I guess GCD CR R0,R1 IPM R14 EXC SUB01,GT SPM R14 EXC SUB10,LT SPM R14 JNE GCD --- SUB01 SR R0,R1 SUB10 SR R1,R0 But that doesn't really look that nice to me. I was looking for a golly, wiz! that is fantastic! but couldn't think of any. -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
Finally caving in to overwhelming temptation. In my first IT job as an assembler application trainee, my assignment was to (re)write a data base accounting program. The program read every record in the application data base and reported the number of each type of record. Pretty simple. There were hundreds of record 'buckets', and my program counted and formatted totals for all of them into the millions. As a newbie, I wanted to streamline the process as much as possible. I consulted manuals in the department library (no internet then) to assess relative instruction efficiency. My manager encouraged me (thank you Frank) to spend the extra time. I decided on this technique when I needed to tally a particular record type: L Rn,COUNTERFetch the counter LA Rn,1(,Rn)Increment the count ST Rn,COUNTER Update the counter Along with some fairly 'imaginative' structural techniques, this program ran like a bat out of aitch ee double hockey sticks. I was later told after I had joined the sysprog staff that my program had been used to benchmark hardware and software upgrades. Wow. After I had move on, I was nagged by an obvious limitation: while the data base at the time contained at most 12M records of any type, my technique would fail utterly in the 24 bit world if any bucket hit the 16M ceiling. Don't know what ever happened, but Experian ultimately inherited the issue. No one has tracked me down. Point is that I was a bargain potato in a world where hardware was the gorilla in the data center. Nowadays I make a boatload of dough, while the hardware gets cheaper by the generation. Efficiency should never be dissed, but there are also other fish to fry in the 21st Century. Lesson: maintain perspective.; . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU, Date: 02/17/2014 08:19 PM Subject:Re: Optimization, CPU time, and related issues Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Isn't it called Jump, or more properly, Branch Relative on Condition? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, February 17, 2014 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Optimization, CPU time, and related issues Hello, when we discussed the one bit copy topic recently, I had a solution in mind that was kind of inspired by the new store on condition instruction, but there was no such solution, because a instruction like OI on condition or NI on condition would have been necessary, and there are no such instructions. Now my question: I could imagine some use cases for a new instruction, that supresses the execution of the next instruction, depending on certain values of the condition code. For example SKIP NEXT INSTRUCTION IF NOT ZERO, or IF ZERO. This would be much more general than store on condition, because you could skip every instruction (not only ST), depending on the condition code. Of course, this needs some extensions to the machine logic, because it must be possible that only the PSW will be incremented but the instruction is not executed, depending on this SKIP condition. But: it saves some branches in some cases. My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... Kind regards Bernd Am 18.02.2014 00:36, schrieb Ed Jaffe: Bottom line: every developer should try to write code that runs as fast as possible. A single MSU increase at just the wrong time could translate into huge $$. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
Skip Robinson wrote: Finally caving in to overwhelming temptation. All of us have this ONE temptation because of branch prediction, cache, optimization, etc: My proposed code would really be this, but I can at most just dream... ;-D PPB 1000 (Predict and Prevent Bugs in next 1000 lines) SUCO 1000(Search [for] Unoptimized Code and Optimize during Run-Time) WTO1 WTO 'All bugs zapped and code optimized successfully. Proceeding ...' PROG CSECT AMODE 31 RMODE 24 USING *,PROG ... etc ... ;-D ;-D ;-D BTW: I know that for some languages there are compiler options for code optimization. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On 2/18/2014 12:11 AM, Skip Robinson wrote: L Rn,COUNTERFetch the counter LA Rn,1(,Rn)Increment the count ST Rn,COUNTER Update the counter I realize hindsight is wonderful, but I can't keep wondering why you didn't use something like: LA Rn,1 AL Rn,COUNTER ST Rn,COUNTER which would have given you a 32-bit maximum total? And even using a plain A would have given you 31 bits. But then I look at my early code and cringe g Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
