Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in



Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> FAQ & Off Topics
View previous topic :: :: View next topic  
Author Message
Bill Woodger

DFSORT Moderator

Joined: 09 Mar 2011
Posts: 7162

PostPosted: Thu Jan 05, 2012 4:47 pm    Post subject: SYMNAMES
Reply with quote

We are making a mess of topic.

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".

EDIT: Small "clarity" amendment.
Back to top
View user's profile Send private message


Active Member

Joined: 06 Jul 2010
Posts: 640
Location: Whitby, ON, Canada

PostPosted: Thu Jan 05, 2012 6:48 pm    Post subject:
Reply with quote

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)



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).

A symbol definition looks like this:


Too much work, you say? Well, IBM provides a free tool that converts Cobol copybooks to DFSORT symbols. See this link for more details
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> FAQ & Off Topics All times are GMT + 6 Hours
Page 1 of 1


Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Yesterday's Date using SYMNAMES and F... SathishCS DFSORT/ICETOOL 2 Mon Jun 29, 2015 6:59 pm
No new posts SYMNAMES in SORT card tvinodkumar7 DFSORT/ICETOOL 2 Fri Feb 13, 2015 10:35 am
No new posts Building SYMNAMES file, two or more r... zh_lad DFSORT/ICETOOL 1 Tue May 13, 2014 9:08 pm
No new posts Sticky: Symbols/SYMNAMES Bill Woodger DFSORT/ICETOOL 3 Fri May 24, 2013 8:07 pm
No new posts Generating SYMNAMES using COBDFSYM gylbharat CLIST & REXX 5 Tue Jun 05, 2012 3:31 pm

Back to Top
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us