We have a new requirement where the strings with 'AF' from 10 to 12 should be included in the first part of the sort - i.e. 10,2,CH,A
but not in the 2nd part of the sort - i.e. 13,1,CH,A
Can you let me know if this is possible in a single sort step?
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Build a seperate key at the end (fixed-length records) or beginning (variable-length records). For your range, blat the second part of the generated key to a standard value (space, for instance). Change your SORT card to use the generated key. Drop off the generated sort afterwards.
This would be some INREC stuff, to generate the key, and an OUTREC BUILD to drop it off.
I have put 06 and 09 at the first key position you mentioned and the second sort key is the field after the two-char field you want to identify. The AB-AF records are in different order to the BB-BF records (which are the same, except for the B).
Enrico, thank you - the main problem is i cannot post company data or requirement explicitly on this website so that is why the data is masked and my requirement is not clear.
The requirement - put simply is as below.
Say in a file we have 2 Fields - Fld 1 and Fld 2
the sort field sorts by Fld 1 and then by Fld 2
Code:
Sort fields (fld 1, Fld 2)
However i want a particular string (say Fld 1 = 3 ) not to be sorted based on Fld 2 and still appear in the output file. the rest of the strings need to be sorted on both Fld 1 and Fld 2. Only Fld 1 = 3 should be sorted on Fld 1 and not on Fld3
I hope i am clear.
Code:
File looks like this
A1
1C
2E
3B
EX
D5
B6
Here by Fld 1 i mean the first byte. Field 2 is the 2nd byte.
Fld 1 Fld 2
A 1
1 C
2 E
3 B
E X
D 5
B 6
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Bill Woodger wrote:
[...]
Code:
ORIGINAL-RECORD,1,21,CH !!! CODE THESE
GENERATED-KEY,*,3,CH !!! THREE
OVERLAY-START,= !!! TOGETHER
Although the coding of OVERLAY-START like that, to get a constant value (22 in this case) "works", I don't think I should rely on it. Better like this:
Code:
OVERLAY-START,=,1,CH !!! TOGETHER
In the documentation it is explicit that when used for a column the processing of the SYMNAME will only use the starting position value from the definition. I think my previous attempt was a little "fudge" as, when I tried to re-arrange it (OVERLAY first then GENERATED) I got an error. Now it should be possible to re-arrange.
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
On the banner at the top of the page it says 'EXPERT FORUM' so it should not be beyond these people to skim the manual to find out about SYMNAMES. In depth reading would be required to get into all the nooks and crannies and, possibly, a manual in their native language - if they do not have such things.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Hi Dave,
Thanks for the comments. I don't agree about the efficacy of my solutions, by the way :-)
To me, SYMNAMES are to make things easier: to understand; to maintain.
You can take a Cobol (or whatever) record-layout, generate DFSORT symbols from it, and use the identical names/definitions in DFSORT without having to do any counting, referring to datamaps on listings, using browse with COLS or whatever technique.
When you have written the sort code, you can far-better understand it, spot "obvious" errors, avoid stupid typos/miscountings, "move" a field which is referenced in several places by only changing the definition in one place, etc.
If anyone is happier doing all the counting and stuff, that's fine by me. DFSORT lists the sort cards once the symbols have been resolved, so someone can take that as the solution if they like.
I think the symnames are easier. Anyone been called at 2am by OPS? "OK, do you think you are up to changing some sort cards?" you say, or you are thinking "what the heck is at position 48 for a length of five and is packed?" when you haven't looked at a particular part of the system for a couple of years.
I wish symnames had been around 32 years ago. Would have been much easier, and I don't think it would have made understanding position, length and type any more difficult.
Yes, it takes longer to code initially by hand. Doesn't take as long with generated symbols. Once you have the symbols, I find it is quicker to write the sort cards, certainly easier to understand and maintain.
OK, "understand" can be a personal thing. "I can see what it says, but what does it do?" maybe, but that cuts both ways, symnames or "classic".
Symnames make me think about the data content, not about the position of the data.
The main problem with my sort "solutions" is whether they are fit for purpose, not about the symnames. I leave a lot of useless clutter for Frank and Kolusu to wade through unnecessarily. Sorry about that guys.
If people don't know about DFSORT symbols, they won't use them for sure. If they do know, they might, and they may well benefit from it.
If they want the classic, just look at the output and paste it over the input sort cards :-)
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Quote:
On the banner at the top of the page it says 'EXPERT FORUM'
Unfortunately, we are an expert forum in name only (even though we do have an entire separate forum for "Students and Beginners".. . .
Only rarely do true experts post questions here. Which is unfortunate as we have several people who can/do provide help/information for these "heavier" questions.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
I'm with you Bill, I love DFSORT symbols. I have never understood why it is so difficult to convince people to use them. In our shop there are over 8,000 jobs in production that use DFSORT; less than 30 of them use SYMNAMEs.
Symbols have been around since 1998. How old does a feature need to be before it can no longer be considered "new"?
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
In most of the solutions, Frank and Kolusu could provide a SYNAMES solutions, but they choose not to.
My guess as to why is that the solution needs to be catered to the user it is provided for.
While I agree that SYMNAMES is a better way to go (well, I did "invent" it), I generally choose NOT to show solutions with SYMNAMES because it requires the reader to understand one more level of "abstraction" which some have trouble with. I figure that the more capable/interested people in this group will use SYMNAMES themselves without me showing them how. Of course, if anyone has specific questions about how to use SYMNAMES, I would be glad to respond.
thanks for the solution to posted but as i mentioned before i cannot use Sym names - because this sort card would be placed in a job that has around 10 million records accessing it daily. so we needed a more simple method.
Frank, is there another possible solution to this - thank you for your time on this.
Nic,
Quote:
On the banner at the top of the page it says 'EXPERT FORUM' so it should not be beyond these people to skim the manual to find out about SYMNAMES. In depth reading would be required to get into all the nooks and crannies and, possibly, a manual in their native language - if they do not have such things.
Definitely our skills are nothing compared to the vast expertise and knowledge that many in this group have but we do have a basic knowledge of English and that is why we are Cobol programmers and a lot of companies trust us to handle their processes. Most of the cases due to dearth of time we may not be able to dig into these manuals.
I did not mean any offence to anyone here but a little respect would not harm anyone - thank you.
Thank you all again for your time and solutions.
thanks for the solution to posted but as i mentioned before i cannot use Sym names - because this sort card would be placed in a job that has around 10 million records accessing it daily. so we needed a more simple method.
utter horse manure ...
symnames is just a way of making things more readable
I am not a dfsort expert, but I strongly believe that
they do not have any performance implications .
a properly defined SYMBOL library is like a COBOL COPYBOOK LIBRARY
OK... if You want to be picky the jcl might become a bit more complicated
if You believe that TWO DD statements have that bad influence
it will sort the records in the proper sequence on both fields
only for the AF records it will leave them alone, but in the proper place relative to the others
********************************* TOP OF DATA **********************************
AB7
AB9
AF9
AF5
AF2
AF5
XB7
XB9
YA8
ZQ8
******************************** BOTTOM OF DATA ********************************
just a proof of concept, modify the fields positions according to Your needs
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
Quote:
You just started a religion war
I hope i didnt, its just what i think. Bill Woodger is a Cobol zealot, so i understand he loves to use SYMNAMES to define Cobol like names. Well
whoever wants to use it, thats ok with me.
