information in output listing

[Felicity Vaughan]

We have 2 instances of Endevor that are very different.  On one of them, when I run a compile job, a copy of the full processor appears in the output before the symbolic substitutions, however, on the other site, the output goes straight to the symbolic substitutions without showing the full processor in the output.  Can anyone remind me if there's an option that controls this and where is it?

Thanks.

------------------------------
Felicity
------------------------------

[Dana Crawford]

[Felicity Vaughan]

Thanks I'll look at this - I couldn't even find the fields in the table in the documentation anymore - ah for the days when it was easy to find what you needed in the manuals.  Appreciate the swift response.

------------------------------
Felicity
------------------------------

[Felicity Vaughan]

Unfortunately, this field is commented out on both instances.  However, I'll keep looking - doesn't make any sense that it's commented out.  thanks.

------------------------------
Felicity
------------------------------

[Eoin OCleirigh]

Hmm - I posed a longer reply but it seems not to have been published yet.  So quickly the two important DDs to try are EN$TROPT to find out what value is being set for NO_PROC_PRINT option, and if set, what defaults/options table it's coming from.  The other hint is to try adding EN$PPRT to toggle on processor listings in the job that's not showing them.  Hopefully this message (and the longer one) will eventually appear.
Eoin

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Eoin OCleirigh]

Hi Felicity, I think Dana gave the correct (most likely) spot - ENCOPTBL option NO_PROC_PRINT.  If it's commented out (normal) is should not be active, but you mentioned it's having different behaviour's on different instances, maybe you have an exit that's loading a different version of the Optional Feature table.  To find out, I's use the options trace (add //EN$TROPT DD SYSOU=*) if batch or use TSO command - 'tso alloc f(en$tropt) sysout(x)' and then search the output for the NO_PROC_PRINT value - if it shows up on the right side of the listing, it's not active.

There is a "secret" DD that you can add to your job or TSO session to temporarily override it too so if all else fails try
adding //EN#PPRT DD DUMMY, and see what you get.

IMHO the Processor print should never be suppressed, the only person who'll likely be hurt is the Endevor admin, and Developers are more like to self-solve silly issues like mis-matched naming conventions etc. if they can SEE what's expected.

Good Luck,
Eoin

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Bridgetburgh]

Hi Felicity,

I think Dana pointed you to the most likely culprit - the ENCOPTBL option NO_PROC_PRINT. If it's commented out (which is the default), it shouldn't be active. However, since you're seeing different behavior across environments, it's possible that an exit is loading a different version of the Optional Features table.

To confirm, I'd recommend using the options trace. For batch jobs, add:

arduino


CopyEdit


//EN$TROPT DD SYSOUT=*

Or in TSO, run this command:

scss


CopyEdit


tso alloc f(en$tropt) sysout(x)

Then, search the output for NO_PROC_PRINT. If it appears on the right side of the listing, it's not active. MyLabCorp

There's also a lesser-known trick - a "secret" DD you can add to your job or TSO session to temporarily override it:

arduino


CopyEdit


//EN#PPRT DD DUMMY

Give that a try if everything else fails.

Personally, I don't think the processor print should ever be suppressed. It's rarely the developers who suffer - it's usually the Endevor admins who end up chasing ghosts. And developers are much more likely to self-solve things like naming mismatches if they can clearly see what the processor is expecting.