I have got another doubt here!!
1. From the link provided by you
Code:
INCLUDE COND=(106,5,SS,EQ,C'BIOL ,HIST ,BUSIN,PSYCH')
2.
Code:
OMIT COND=(1,1,SS,EQ,C'H,T')
As you mentioned, the second codition is searching for 3 strings they are
1. 'H'
2. ','
3. ' T'
Which means that ',' is not used as seperator, its just another string.
So, in that case the first codition should search for the following strings right?
1. 'BIOL '
2. ',HIST'
3. ' ,BU'
4. 'SIN,P'
5. 'SYCH' but this not right. How is this handled?
In what case ',' is used as seperator and in what case it is used as another string?
If length of the string is one, will comma be used as another string?
I'd be careful trying to catch Frank in an error.
Were he a COBOL programmer, I'd maybe try.
But he is an assembler type.........don't mess with them.
The kind of quality control that the SORT Team has to go thru
(a gazillion users)
makes them somewhat precise.
My advice, always double check......which you did not do.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
The comma is part of the string. Here's what the DFSORT APG says:
Quote:
Note that the comma is used within the constant to separate the valid values; any character that will not appear in the field value can be used as a separator in the constant.
The best way to illustrate this is with a better example. Say we have:
1,3,SS,EQ,C'ABC,DEF'
SS first searches for 'ABC', then 'BC,', then 'C,D', then 'DEF'.
If the record can contain 'BC,' or 'C,D', then that matters. But in most cases, only ABC or DEF would appear in the record, so the combinations with the comma don't matter. Usually, inserting comma separators is enough to prevent getting a hit on any unwanted values. Another separator could be used instead, e.g. C'ABC$DEF' if that will work where the comma wouldn't.
Quote:
If length of the string is one, will comma be used as another string?
Yes. If the comma is a problem in that case, you could just use 1,1,SS,EQ,C'HT'.
SS doesn't really use the separator as a separator. It's just another character, but that's usually not a problem. However, it helps to know how it actually works (as documented in the book) in case the use of the separator ever does matter.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Dick,
Quote:
I'd be careful trying to catch Frank in an error.
Quote:
you were correct.
Sorry to nitpick, but can you clarify what you were correct about.
AFAIK, I didn't make any error in my description of SS. vvmanyam was correct in his question about how it worked, but I never said that it worked any other way and neither did the DFSORT APG.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Yes, I did miss ,DE (good thing I put code in to do these things instead of doing it myself by hand).
Quote:
Why carry out more tests than is required. ?
Yes, although SS can be easier to code (especially for a lot of values), it can cost a bit more CPU time. Of course, your mileage may vary - I have found cases where SS actually performs better than OR.
