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://prino.neocities.org/indez.html
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
