The TS has asked a question of Frank and now there are six posts after that question which Frank would have to wade through, plus all the stuff from yesterday.
If the six posts can be split off to here, or a new topic in FAQ then we can continue on our way saving Frank the wading.
Bill Woodger wrote:
Just because you can do it in Cobol, does not mean it should be done in Cobol.
The above might give a clue as to whether this link exists.
I will baldly state that Cobol is the most common mainframe language. This is the reason for my references to Cobol in non-Cobol places, to attempt the widest understanding.
DFSORT allows 50 characters for symbols. Easytrieve 40 for datanames. Cobol 30. If you want a name that works in multiple places, it would be the Cobol name with Cobol syntax limitations. I don't know what PL/I offers for datanames, but I suspect for a PL/I site it would be PL/I syntax that would be relevant. I don't know about limits for others, like SAS or Natural, but the point would be that what would be relevant for names which can be used in all places would be the language with the greatest limitation on name definition.
Both will operate in the same way. Yes, you don't "know" that the field is binary, or where it starts, or how long it is, with the symbol, but without the symbol you don't know what the field is. Except, if there is a problem, you have the output from the sort, where it tells you all of those things, because the symbols are translated to the traditional notation for the sort.
The thing is, the lack of "knowing" by looking at the name is the same in any language. And we usually "know" because we are using the data at the time.
With the first example, you know how the field is defined. You don't know that it is correct. With generated symbols, you don't have to check the field is correctly defined because some program has done the definition for you. You don't have to check, but you can, from the output messages.
There is at least one place, the key(s) for a Join, where the length/type have to be the same and it could be argued that it is "much easier" if you can see them in the statement. Again they'd still have to be correct (coded by hand) and again you'd see the definitions in the output.
The DFSOORT Application Programming Guide shows how you can use the "next position" (*) to make the generation of the symbols independent of the RDW, avoiding the problem of "forgetting" whether or not four should be added to all the start positions.
In Easytrieve Plus (my zealotry is unbound) you code a SORT with datanames. To see how a field is defined, you have to look at the definition. Sometimes that is in the program, but it is often better in a MACRO, and it is better if that MACRO is generated and is the same name as the lowest-common-format-dataname that is used across the system. Same with the SEQUENCE on the REPORT. I suspect it is similar in SAS or Natural or whatever. Even in a Cobol sort (which I have never used, and would not use except under sufferance) the same thing.
In my opinion (not words a zealot would use) meaningful datanames are better than non-meaningful ones, or no-names-at-all, better that the same name is used everywhere (where names are allowed and assuming syntactic co-incidence, in the last you might have to end up with "similar" in some instances, I suppose, if there is a clash of "seperators" or something).
I like code that is easy to understand and easy to maintain. Doesn't matter to me what language it is in. DFSORT symbols give that to the control cards for DFSORT/ICETOOL/ICEGENER operations within the wider context of systems as a whole.
If I am again involved in defining standards, they would include the use of Sort symbols.
I understand Dave's point in the DFSORT topic, which Frank confirms as being an issure of "another level of abstraction" rather than a better/worse way to implement. So, other than where it is a technique to get reference data into a sort (by generating the symbols in an earlier step) I should leave them out of "solutions".
[/code]
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
I had not heard of using '*' in a symbol definition to indicate 'next position'. Thanks for the tip, which prompted me to re-read the fine manual (rRTFM?)
My favourite way to create symbols is to use the IBM supplied sample Rexx program to generate them from Cobol copybooks. I have a modified version of the program that allows you to easily adjust the starting position of the fields in order to account for the RDW. (If I had known about the use of '*' I might not have bothered making the modification). Over time, I have built up a small library of locally useful SYMNAMES members.
I have been evangelizing on the use of SYMNAMES for years, without much success. The following is an excerpt from an article that I wrote for our local Wiki. It has generated zero comments or other feedback.
===============================================
What would you rather look at:
SORT FIELDS=(18,2,PD,A,20,3,PD,A,23,4,PD,A)
or
SORT FIELDS=(BANK_NUM,A,BRANCH_NUM,A,ACCT_NUM,A)
DFSORT allows you to define symbolic names that correspond with field positions. This makes sort control cards pretty much self documenting so that you do not have to be on intimate terms with the file layout in order to figure out what is going on.
This feature has been around since 1998, but is not well known and has not been used much here at <redacted>. By my count only 27 out of 8,000 SORT related production jobs use symbols. (This is progress: in 2003 the count was zero).
