MVSFORUMS.com

[misi01]

Not sure how to express this, so it'll probably be easier to include a screen capture to illustrate what I want to do. What is the edit command to create MSG text in the prefix area (as well as the actual message itself).

Thanx

[misi01]

The following will do it

[kolusu]

misi01,

I am guessing that you are running a JCL checker and want to capture the error messages. Just so you know you can run JCL checker in batch and here is an example of it

http://www.mvsforums.com/helpboards/viewtopic.php?p=1157#1157

Kolusu

[misi01]

What I've done is to write a macro that can be used when editing some COBOL source code. It edits the compiler listing and looks for occurrences of sections and variables that not used in the source code (Micros Focus's Mainframe Express has a similar menu option for this).

Let's assume that they have 5 "errors" in their code, either sections that are never performed or variables that are never referenced. As a s result of the macro, I do the LINE_AFTER calls above for these 5 occurrences.

This now means that the user has 5 msg's in the prefix area. What I'm wondering is if there is a way of finding these via a primary command, something like, say,

[misi01]

Use

[papadi]

Good to hear it! Thanks for posting what you found
_________________
All the best,

di

[semigeezer]

Also. I'd suggest you never use the variable name in concatenation with edit commands like this. Instead, set the variable and use parenthesis notation.
With concatenation, if your variable contains characters that are important to edit macro syntax like ampersands and quotes, your command will fail and those types of problems are hard to diagnose, especially if someone else has to do it.

Instead of

[William Collins]

You are using compiler option OPT(FULL) when producing the listing?

[misi01]

William. No, we're using XREF(FULL)

Semigeezer. Thanks for the idea. Will include it in my "cheat" list so I remember it for next time
_________________
Michael

[William Collins]

Well, if you use OPT(FULL) the compiler will tell you, exactly, with no fear of error and no code for you to write other than to extract what the compiler tells you: code which cannot be executed (not limited to paragraphs/SECTIONs not actually referenced (which does not tell you that the code is not used anyway)) and WORKING-STORAGE/LOCAL-STORAGE which is unreferenced.

However, why it would require other than using a split-screen to work on any information uncovered (I can't see why there should often be such things) I don't know.

[misi01]

At the end of the day, you can use the macro I wrote when editing your source code. This then runs an edit macro under the covers, analyzing the results of the compiler listing to return a list of unused variables/sections. On returning from the "covers", the macro then highlights the places "in error" with ==MSG> in the prefix area.

I agree, they could split the screen and then start visually analyzing the results in the compiler listing, but it's a damn site easier to have everything served up on a plate using ==MSG>
_________________
Michael

[William Collins]

You have written some code to identify storage which is not referenced.

You have written some code to identify paragraphs/SECTIONs which are not referenced.

The first is not too bad (assuming you have the data-map).

The second is very difficult (if I have understood what you want) to do reliably.

With OPT(FULL) the compiler does both of these, to a 100%-accurate degree. It lists the line-numbers for you, points them out in the listing. All you'd need to do is extract those (not needing XREF(FULL)) and then take that information into your macro.

At that point I just wonder how many times it is useful to have a macro to highlight the lines, when all you need to do is look at the listing, then look at the source and fix it.

Why do you get unused storage and unused (non-accessible) code so often that you need a macro to make it easier to look at?

[misi01]

I'll play around with the OPT(FULL) to see how the results differ compared to the other variation. A potential problem there is that (and I'd have to check this) OPT(FULL) is not the default parm for compilations here at work, XREF(FULL) is.

[papadi]

I've only supported more than 100 data centers over the years and never yet has "dead code" been much of an issue. . .

How has this become a "biggie" in your organization? I suspect making sure the code always runs correctly and performs acceptably is a bigger issue than dead code . . .
_________________
All the best,

di

[misi01]

It isn't a big deal here, it's just rather quiet at the moment
_________________
Michael