Endevor

When running a batch job I added the needed DD for this trace and DSN for capturing results. The processor has a number of IF-THEN-ELSE statements ... but nothing came back. What would prevent this?

Example of three items included... one is the EN$TRITE

     //**************************************************
     //*  INCLUDED JCL                                  
     //**************************************************
  17 //EN$TRITE DD DISP=SHR,DSN=#6580.TRACE.TEST001     
  18 //EN$TRXIT DD DISP=SHR,DSN=#6580.TRACE.TEST002     
  19 //BSTERR DD DISP=SHR,DSN=#6580.TRACE.BSTERR01      

No errors, no info on RITE. Captured info on our EXIT programs. Each file is PS, FB, 133, 1330.

Another person tried another processor with even more IF-THEN-ELSE. Got nothing, but did get a list of info from the BSTERR.

Thoughts? Insights?

Thanks.

Hi Ronald,

Are you running a processor ?
Can you show the whole sysout execution ?

Regards,

Ollivier

Hi yes a processor was executed and it has IF Then Else logic. I will get a copy of the job download etc and reply with it in a while.

Hi Ollivier

First we opened a ticket, #582466. It was opened by Ronald Wojnar. You can reach out to him or to me.

Second I have a text file which is attach it.

Hi we found out that the IF THEN ELSE trace information is buried inside the C1MSGS1.

However, the manual on Exits is very misleading. It states to put the DD line into the jcl.

Where it seems to show that by doing that and having a SYSOUT or DSN the trace would go into that.

Just like other traces do.

However, it doesn't state for this specific trace EN$TRITE is inserts the trace info when a IF statement is encounter. It makes sense, but the manual should state that.

Of course it would be helpful if it also puts out the trace info to that DD.

Hi Ronald,

Yes the traces are wrote into C1MSGS1, iin fact doc shows the allocation as "//EN$TRITE DD DUMMY" which means trace is written into C1MSGS1.

But in the trace facility the sample are mentioning the use of SYSOUT= or DSN=, not Dummy.

I will suggest a doc update to the lab in order to mention that some trace require DD DUMMY when they are written into ddname BSTERR or C1MSGS1.

Regards,

Ollivier

Thanks for informing the lab about the different trace info. NOTE, I was checking the Admin manual V17 at the bottom where it goes over Enabling Trace. I didn't see //EN$TRITE DD DUMMY . What 'doc' are you referring to?

BTW, Thank you for your help.

See here Ron:

https://docops.ca.com/ca-endevor-SCM/18/en/administrating/extended-processors/writing-processors#WritingProcessors-IF-THEN-ELSETraceFacility

Regards,

Ollivier

This version of DOCOPS relates to Endevor V18. We are V17. I realize (or I didn't see it documented) that this specific ITE trace didn't change between V17 and V18. Its just the DOCOPS information was updated/enhanced. Thanks again.

The DOCOPS sample that shows the following is extracted from an output listing of an action with tracing activated: (see attached file) seems more organized than what we got in the job. If you look at the prior text file I sent. The expression list seems more organized in the sample than what is in our job. Is that a release difference or just better placement of ITE statements?

Hi Ron,

You processor has a lot of ITE and steps while the sample is very simple.

In my opinion both are correct is no issue in yours and this is not a matter of Endevor version, simply the coding that make the reading of trace EN$TRITE plus or minus readable.

Personally, to make trace more readable, I use name to identify Ite, ie

//SITE1000 IF .... (Start ITE)

...

//SITE1100 IF ....

...

//OITE1100 ELSE 

...

//EITE1100 ENDIF

...

//OITE1000 ELSE (Otherwise ITE)

...

//SITE1200 IF ....

...

//OITE1200 ELSE

...

//EITE1200 ENDIF 

...

//EITE1000 ENDIF (End ITE) 

//SITE2000 IF ....

...

This is just a sample, hope this help.

Regards,

Ollivier