> > Please don't patronise me with high "coding standards", you banned > me from your > forum when I commented on the fact that you suggested using UNSPEC() > to look at > the internal representation of z/OS HEX FLOAT values in order top > print them in > a PL/I program, and then deleted the postings to hide your own incompetence!
Robert, Ya right ! And you had the audacity to call it a bug in the product even though you are data owner and mere checking of the data would have answered your own question. I should have gone with my first instinct of just ignoring your rambling. That is the only thing you do. > And did you actually read the "...and ***someone*** came up with a > really very > elegant way of performing this task, ..." (Emphasis added...) You should have > seen, as you're also on that forum, that the solution was provided by Jörg > Findeisen! I stopped browsing that forum ever since they forced ads. Kudos to Jorg findeisen for coding a solution. And the degree of elegance depends. So if you are happy with the solution stick with it >>> And that saves? 1 nanosecond? The question is NOT only about saving CPU cycles. The elegance you boast isn't seen when you code such statements. > Which is really important for something that processes 209 lines of > input, and > might at some stage process as many as 300 lines on input, and it's part of a > job that runs for about a minute, so saving a fraction of a second? And when > SORT is invoked by the viewer, the result is usually displayed when > my finger is > still next to the Enter key. As I said earlier I wouldn't have bothered to answer the questions from YOU if you hadn't called an user error a bug in the product. Thanks, Kolusu IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 01/15/2021 10:53:50 AM: > From: Robert Prins <rob...@prino.org> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/15/2021 08:54 AM > Subject: [EXTERNAL] Re: Bug in DFSORT? [WAS: Merging multiple > records using DFSORT] > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > On 2021-01-15 11:50, Sri h Kolusu wrote: > >> So what's so special about 80? 9, 41 and 44 are unique in the entire set > > of >sort control statements, and 80 also doesn't appear, yet replacing 44 > > by 80 >results in incorrect output. > > > >> I've gone over it again and again, but I'm totally clueless, unless this > > is >one of those bugs that nobody's encountered before(*). > >> So, if someone can confirm the problem, or that this is a case of Edgar > >> Allan Poe's "The Purloined Letter", i.e. so obvious that it hides in plain > >> sight, please reply to this post! > > > > Robert, > > > > Let me start off with "It is NOT a BUG" and the obvious is right in front > > of you. As a data owner you SHOULD be in a better position to tell as to > > what is so special about the data at position 80. > > Yes, as I already wrote, it's probably a case of "The Purloined Letter"... > > > To explain what is so special about 80. Open the input dataset in > > browse/edit mode > > > > Issue the command F '+' 44 ALL then make a note of where exactly you are > > finding the specified character. Also Make a note of the number of times > > the character is found. (5 times) > > > > Hint : It is found on the FIRST line of the boxed data skipping the first > > set of data > > > > Now issue the same command but changing the position to 80 > > > > F '+' 80 ALL > > > > Also make a note of how many number of times the character is found (9 > > times) > > > > Hint : It is found on the FIRST/SECOND/THIRD line of the boxed data > > starting with the first set of data. > > > > DFSORT is merely doing what you wanted it to do. So I am not sure comparing > > a 5 time found data with 9 times found data is correct. > > > > Btw the control cards can be optimized and I am not even sure as to why you > > need a numeric conversion for simply sticking a constant value of 0120 ? > > Not sure how it passed your high "coding standards" > > Please don't patronise me with high "coding standards", you banned > me from your > forum when I commented on the fact that you suggested using UNSPEC() > to look at > the internal representation of z/OS HEX FLOAT values in order top > print them in > a PL/I program, and then deleted the postings to hide your own incompetence! > > And did you actually read the "...and ***someone*** came up with a > really very > elegant way of performing this task, ..." (Emphasis added...) You should have > seen, as you're also on that forum, that the solution was provided by Jörg > Findeisen! > > > INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:+120,ZD,LENGTH=4)), > > > > should be as simple as > > > > INREC IFTHEN=(WHEN=INIT,OVERLAY=(364:C'0120')), > > And that saves? 1 nanosecond? > > > Similarly when using the substring format and searching for multiple > > characters, it is advisable to have a comma so that it is easy to > > understand and maintain. > > > > (44,1,SS,EQ,C'+|') should be (44,1,SS,EQ,C'+,|') > > And how much extra time does this add to parsing the string? Sheesh... > > > This is explained in the 2nd bullet here > > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/ > com.ibm.zos.v2r4.icea100/substr.htm > > > > And just for the record, the job can be optimized and can be done easily. > > Which is really important for something that processes 209 lines of > input, and > might at some stage process as many as 300 lines on input, and it's part of a > job that runs for about a minute, so saving a fraction of a second? And when > SORT is invoked by the viewer, the result is usually displayed when > my finger is > still next to the Enter key. > > Robert > -- > Robert AH Prins > robert(a)prino(d)org > The hitchhiking grandfather - https://urldefense.proofpoint.com/v2/ > url? > u=https-3A__prino.neocities.org_indez.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=IAduPlMgORoDwSg- > QJfFI61PqQWHjCo5brtkXopHqZk&m=lXgJyqGOAVsIUiLvml6BxXiiDu7vSsYXEBTdNDdrW2U&s=f5_2gX28BbyphxHVdu3qp1gbqGbMnii83edHxUZAPI4&e= > Some REXX code for use on z/OS - https://urldefense.proofpoint.com/ > v2/url? > u=https-3A__prino.neocities.org_zOS_zOS-2DTools.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=IAduPlMgORoDwSg- > QJfFI61PqQWHjCo5brtkXopHqZk&m=lXgJyqGOAVsIUiLvml6BxXiiDu7vSsYXEBTdNDdrW2U&s=Y7ytliMtrkOzcUUpn829Lj5bbPuQntPmee8G5hAYUzU&e= > > ---------------------------------------------------------------------- > 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
