I am writing a small rexx code to find the list of unused variables in the prog. For this,
1. I have put the data division lines in a array and procedure division lines in another array.
2. extract the variable names from the data division array.
3. check for occurance of each variable in the procedure division array.
Here, I have a problem with the group variable names...Some times the group variable name are not used in the program instead they use the idividual element names....In these cases the group variable name pops up in the unused var list.......and some times if the group name is used and individual names are not used then the individual item names pop up as unused vars.....
Can any1 suggest a better idea to deal with this issue.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
use a syntax only compile with a xref.
the xref will tell you which data elements are not referenced.
In Rexx, there is no such thing as an array.
Rexx uses a convention called stems.
Also, you do not write small rexx codes REXX is a SCRIPT language. - you write scripts.
Use proper terminology, and you will find answers.
also, this is not a chat room. any1 is not standard english, do not use such abreviations in this forum, please.
the problem is that you need to keep track of what elements are in a group.
and since a group can contain a group, which also can contain a group
which would contain elements,
keeping track of the group to group to group to element relationship would be difficult.
i would load elements into a stem. then if found in the procedure division,
replace the element reference with spaces. then you would know
what elements were not referenced.
then you could go backwards with that knowledge and make decisions about groups.
You will also face the challenge that some data division items or even procedure division usage might be brought in by copy members or macro expansion, so unless you find a way to expand this, these references will not be covered.
I have actually written an edit macro in REXX that utilises commands in a Cobol-aware editor environment Smartedit, supplied by a 3rd party software vendor. It will highlight every unused definition in a module even if they where included from a copy or a macro expansion.
Joined: 07 Feb 2009 Posts: 1306 Location: Vilnius, Lithuania
Can anyone tell me why it's so bad if there are actually any unused variables in a program?
There does not seem to be any point in removing them, and as far as PL/I is concerned, just specify *process rules(nounref) and the compiler will actually flag them.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
From the COBOL Programming Guide manual:
Quote:
The FULL suboption requests that, in addition to the optimizations performed with OPT(STD), the compiler discard unreferenced data items from the DATA DIVISION and suppress generation of code to initialize these data items to the values in their VALUE clauses. When OPT(FULL) is in effect, all unreferenced level-77 items and elementary level-01 items are discarded. In addition, level-01 group items are discarded if none of their subordinate items are referenced. The deleted items are shown in the listing. If the MAP option is in effect, a BL number of XXXXX in the data map information indicates that the data item was discarded.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
Robert Sample wrote:
From the COBOL Programming Guide manual:
Quote:
The FULL suboption requests that, in addition to the optimizations performed with OPT(STD), the compiler discard unreferenced data items from the DATA DIVISION and suppress generation of code to initialize these data items to the values in their VALUE clauses. When OPT(FULL) is in effect, all unreferenced level-77 items and elementary level-01 items are discarded. In addition, level-01 group items are discarded if none of their subordinate items are referenced. The deleted items are shown in the listing. If the MAP option is in effect, a BL number of XXXXX in the data map information indicates that the data item was discarded.
That greatly simplifies the problem. You'd just have to compile the program with MAP,OPT(FULL) and write a Rexx program to read the listing and pull out the names. If it were me, I would have the Rexx program generate a simple edit macro to delete the unreferenced items from the source code. You'd want to be careful about testing that, of course.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Robert Sample wrote:
From the COBOL Programming Guide manual:
Quote:
The FULL suboption requests that, in addition to the optimizations performed with OPT(STD), the compiler discard unreferenced data items from the DATA DIVISION and suppress generation of code to initialize these data items to the values in their VALUE clauses. When OPT(FULL) is in effect, all unreferenced level-77 items and elementary level-01 items are discarded. In addition, level-01 group items are discarded if none of their subordinate items are referenced. The deleted items are shown in the listing. If the MAP option is in effect, a BL number of XXXXX in the data map information indicates that the data item was discarded.
In PROCEDURE DIVISION,
MOVE SPACE TO REDEFINES-SUBORDINATE-ITEM but no other references.
It would seem from the manual that with OPT(FULL) that GROUP-DATA-WITH-SUBORDINATE and SUBORDINATE-ITEM should be deleted by the compiler. Causing a compile error? If it did cause an error, that would turn off the optimising (according to the manual). Would you then see the XXXXX in the DMAP?
I suppose it depends if I'm reading it correctly (but can't see how not), or if it is a documentation error, or where the non-referenced data removal takes place (would the REDEFINEd group somehow occupy the space, or would it be looking at what is now (after removal of the group by the optimiser) storage belonging to someone else?).
I guess someone could try it if they felt inclined... and had access to a mainframe. I do feel inclined, but...
And, yes, I know such a construct is unlikely to deliberately exist.
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
Quote:
It would seem from the manual that with OPT(FULL) that GROUP-DATA-WITH-SUBORDINATE and SUBORDINATE-ITEM should be deleted by the compiler.
Why? GROUP-DATA-WITH-SUBORDINATE is referenced by the following REDEFINES. The extract from the manual does not mention anything about being not referenced in the PROCEDURE division only.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Thanks very much for your time Robert, I appreciate it.
Nic Clouston wrote:
Why? GROUP-DATA-WITH-SUBORDINATE is referenced by the following REDEFINES. The extract from the manual does not mention anything about being not referenced in the PROCEDURE division only.
Quote:
all unreferenced level-77 items and elementary level-01 items are discarded (my emphasis added)
Nope, doesn't refer to my example. Mine is not elementary.
Quote:
level-01 group items are discarded if none of their subordinate items are referenced(my emphasis added)
Seems to refer to my example. A REDEFINES is not "subordinate" to an 01-level. I checked in the manual before posting. I also checked the full text for the OPTIMIZE. Nothing there either.
If I had thought the text only referred to PROCEDURE references, I would have used an example like this, wouldn't I?
I tried to use fairly explicit data-names and thought that, along with the manual text quoted, it would be clear to people in this forum what I was getting at.
At least we see that the documentation error causes confusion.
I did make a mistake. I thought that the situation would not arise deliberately (knowiningly or otherwise). However, what if there is a COPYBOOK with an 01 defined in it. Then someone REDEFINES the 01 in the copybook, makes their own names but does not refer to anything in the copybook itself? Having said that, I'm not sure they'd worry about it not being documented in OPT(FULL).
Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
As to why one would care:
An analogous situation is the compiler's warning messages about dead code.
In investigating a dead code warning a few years back, I discovered a stray period at the end of a line of indented code following an ELSE. It seemed that since the several following lines were also indented, the last of which had a period, that the earlier period was wrong.
It of course ended the ELSE code, and the following (indented lines) were therefore always executed.
One of these set a variable to a constant value. This in turn caused the following IF to be always false, and the compiler could see that, therefore causing this IF's THEN code to be dead code.
So - warnings of this nature, and analogously unref'd variables, can point out problems in clean code.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Very good point Phrz... er, I'll call you Phil, if you don't mind
I've seen the same sort of thing. The instances I saw were "editor errors" as people were tossing blocks of code around with the editor. From a block of unconditional code, copy it to a condition, change the indentation, but, leave a period behind.
With the advent of Cobol II I very happily only coded the mandatory period. On a line of its own.
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
Bill Woodger wrote:
.....
With the advent of Cobol II I very happily only coded the mandatory period. On a line of its own.
I second that! Using END-IF and minimizing period usage makes for much more maintainable code. In my opinion END-IF was the most important innovation made to Cobol in the 30 years I've been in this business.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Hi Nic. Sorry if I seemed a bit short earlier, but there was no time. Looking at your profile, I see that there can easily be things that are "obvious" but aren't really so, I'm guessing you are enormously more familiar with PL/1 than with Cobol.
Here is the quote again from the manual.
Quote:
The FULL suboption requests that, in addition to the optimizations performed with OPT(STD), the compiler discard unreferenced data items from the DATA DIVISION and suppress generation of code to initialize these data items to the values in their VALUE clauses. When OPT(FULL) is in effect, all unreferenced level-77 items and elementary level-01 items are discarded. In addition, level-01 group items are discarded if none of their subordinate items are referenced. The deleted items are shown in the listing. If the MAP option is in effect, a BL number of XXXXX in the data
map information indicates that the data item was discarded.
Firstly "all unreferenced level-77 items and elementary level-01 items are discarded"
An "elementary level-01 item" is like this
Code:
01 ELEMENTARY-LEVEL-01-ITEM PIC X(50).
The is the whole of the 01-level. There is nothing else. It is "elementary" as opposed to "group".
Code:
01 GROUP-LEVEL-01.
05 FILLER PIC X.
Here is a "group". A group consists of subordinate items, which may be groups of a higher level-number or elementary items of a higher level-number.
"In addition, level-01 group items are discarded if none of their subordinate items are referenced."
It is a level-01 group item, and none of its subordinate items are referenced. The only subordinate item is SUBORDINATE-ITEM. The REDEFINES is referencing the 01-level. Items in a redefines are not subordinate to items in the level being redefined (see, for instance, MOVE CORRESPONDING). According to the documentation, it should be deleted by OPT(FULL). However, the compiler treats it logically and does not delete it, ergo the documentation is wrong.
We even have a second situation. Remove the "MOVE..." to REDEFINES-SUBORDINATE-ITEM from Robert's program, so that now none of the storage area is referred to in the PROCEDURE. It is, however, still referred to in the DATA division (the REDEFINES). Does the compiler remove the storage or not, with OPT(FULL)? I say that you can't tell by reading the manual. My "best guess" is that it would be. But, ideally, I'm not reading manuals just so that I can "guess" afterwards.
Joined: 10 May 2007 Posts: 2455 Location: Hampshire, UK
Hi Bill,
No prob. I was debating with myself as to whether I should just drop out of the debate or review the whole caboodle before (not) taking further part. I do not know who won tht debate!
Yes I am P/1 but record structures are familiar as are redefines and I do have COBOL but I do not 'dream' it as I do PL/1 - sad or not??!!
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Hi Nic,
I guess most of the confusion is that my example is, logically, using the storage area allocated by the 01-level group item which has no referenced subordinate items.
The rest of the confusion is the specificity of the terms "elementary", "group" and "subordinate".
The compiler behaves logically, but the documentation denies that that behaviour is possible, because it provides only a limited description of how data can be defined in the DATA DIVISION. The documentation is wrong. According to the documentation my group level-01 should be deleted, even though it is redefined.
You are right that the debate has to be won. Otherwise, what is the point of debating?
So, fortunately for you, there is not so much to check on. This is the statement I rely on "In addition, level-01 group items are discarded if none of their subordinate items are referenced."
You need "level-01 group items" and "subordinate items". If you are worried you can't find enough on "subordinate items" check out CORRESPONDING (as in MOVE CORRESPONDING, ADD CORRESPONDING etc).
If you can convince me that either of these two things I have interpreted incorrectly, then I will conceed defeat. Otherwise, you add to your store of Cobol knowledge, and you concede defeat (this can be achieved implicitly).
"level-01 group item" - In the DATA DIVISION, an 01 which has no picture clause on its definition, but which contains items (elementary or group) at higher level numbers. This definition of mine would cause some confusion because if the 01 does not have a PICTURE and has no subordinate items then it causes a compile error. So, really, it is a "valid" 01 which has no picture clause on its definition.
"subordinate items" - In the DATA DIVISON, the things which make up a group item, they can be either elementary or a group item with a level number higher than the group item they are subordinate to.
For what it's worth, which may not be much, as far as I am concerned the data element "REDEFINES-SUBORDINATE-ITEM" is, indeed, subordinate to the group "GROUP-DATA-WITH-SUBORDINATE" by virtue of the fact that it is subordinate to a group element that redefines that group.
Mathematically, given the following formulae as being true
A=B,
C=A, and
C=D
One could state with absolute certainty that
B=A (symmetric postulate of equality - if A=B then B=A),
A=C (symmetric postulate of equality - if C=A then A=C),
D=C (symmetric postulate of equality - if C=D then D=C),
A=D (transitive postulate of equality - if A=C and C=D then A=D),
B=C (transitive postulate of equality - if B=A and A=C then B=C), and
B=D (transitive postulate of equality - if B=A and A=C and C=D then B=D)
Similarly, given the fact that each of the problem group elements contain one and only one subordinate data element it follows that
GROUP-DATA-WITH-SUBORDINATE = REDEFINES-SUBORDINATE-ITEM (A=D), etc.
Thus, any reference to REDEFINES-SUBORDINATE-ITEM (D) is implicitly a reference to GROUP-DATA-WITH-SUBORDINATE (A).
If you increase the number of subordinate data elements in either the main or redefined groups, there remains an overlap of elements that would still lead to some level of mathematical equality between a subordinate element of one of the groups to the other group - hence any element subordinate to one group is also subordinate to the redefines/redefined group.
Because it is only usable if you have the Smartedit editor installed.
I have not heard of anyone here in the forum that uses Smartedit, let alone a forum that features a topic list that includes (mainframe) Cobol editor software.
I don't want to drop source/script code in some random thread unless specifically usable or asked for in the topic.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
I agree that, logically, the redefines has a necessary relationship to the item it is redefining.
This is the way the programmer/team doing the optimisation code have approached it (OK, that's a lot to say from one test, but at least so far it seems reasonable to say).
For a similar reason, I would expect both 01-levels to be removed by the OPT(FULL) if there are no references, in the Procedure Division, to any of the items in either 01-level.
However, I do have a problem with the item in the redefines then being regarded as "subordinate".
From the Programmer's Guide
Quote:
Using data items and group items
Related data items can be parts of a hierarchical data structure. A data item that does not have subordinate data items is called an elementary item. A data item that is composed of one or more subordinate data items is called a group item.
A record can be either an elementary item or a group item. A group item can be either an alphanumeric group item or a national group item.
So a group item consists of subordinates. A subordinate item may itself be a group, or it may be elemental. A subordinate item is part of a group item. Everything that makes up a group item is subordinate to that group item. Everything that makes up an 01-level group item is a subordinate item of the 01-level group.
This is how every reference (let's leave the OPT(FULL) for the moment) in the Programmer's Guide and Language Reference use the term "subordinate item".
If you think about it, the usage has to be consistent, otherwise, if the same phrase were to mean different things in different parts of the manuals, understanding the manuals would be less clear. OK, I can get stronger than that. The manuals would be rubbish, and unusable (assuming the same process applied to several phrases - if they don't always mean the same thing, then they mean nothing).
Now, what I am saying is that the programmer/team are different from the writer/team who updated the manual. Who knows what the writer/team were working from, but, assuming that "subordinate item" means the same as it does throughout the Cobol manuals, then the description of OPT(FULL) is incorrect. We have an example where what the documentation says should be removed is not removed (and is correctly not removed as far as logic is concerned) and another example which we can't tell from the documentation whether or not it would be removed (although, logically, it should).
I'm afraid we can't just get away with "I feel subordinate should mean this". But even if we did just allow it to mean something different in that paragraph in the manual, we still wouldn't know whether the second example (where nothing is referenced in the Procedure Division, but the redefines is still there in the Data Division) would be removed, or not.
It is a documentation error. Anyone agree? Why are we carrying this out in the CLIST & rexx forum?
Enterprise COBOL for z/OS V4.2 Programming Guide: 2.4.40 wrote:
Discard unreferenced data items from the DATA DIVISION, and suppress generation of code to initialize these data items to their VALUE clauses. (The optimizer takes this action only when you use the FULL suboption.)
