In Mainframe FOCUS, not WebFocus, is there a way to trace the steps a FOCEXEC is performing? Is there some kind of log for mainframe FOCUS? I've got a FOCEXEC that I can't tell if it's running for a really long time, or if it's looping or hung. A trace facility would really help.

Thanks to all who reply...looking forward to hearing from you!

This message has been edited. Last edited by: webmeister,

In the document "FOCUS for S/390 - FOCUS for S/390 Relational Data Adapter User’s Manual, Version 7.2", Appendix D describes how to set up SQL traces.

The first paragraph:

quote:

The data adapter communicates with the RDBMS through
SQL statements it generates on your behalf. You can view
these SQL statements with the trace facility. Traces are
helpful for debugging procedures or for data adapter
performance analysis. The trace facility is easy to invoke,
requires no changes to either the data adapter or FOCUS
request, and have no effect on how the data adapter
functions.

If you want to track the non-SQL parts of the program, have you set &ECHO to ALL or ON to see the results in SYSPRINT? In the past I have also allocated a file that I write into after each part of the program.

There's a lot of other tracing available, one only has to read the manuals.

Cheers,

Francis,

Thanks for replying.... the main reason I wrote to the forum was that I did not even know about the ECHO function, plus, I did look up TRACE, which is only for CASE logic. Also, I did look in my manuals and since I didn't know the right words for finding information about tracing a program, that was a bit of a time-cruncher. Yes, you are correct, that one only has to read the manuals....however that only helps when one knows somewhat what to look up.

You also mention that you have an allocated file that you read into after each part of a program; would you be willing to explain or share that bit of information?

Again, thanks for replying. Looking forward to your reply.

To do what Francis is talking about, look up FILEDEF for allocating a file. Then look up -WRITE in the Dialogue Manager chapter. That should get you started.

Look for these commands in the data adapter manual:

SET TRACEUSER=ON

SET TRACEON = component / [level] / destination

where component is one of these options:

SQLDI traces the SQL physical layer (formerly FSTRACE)
SQLAGGR provides optimization information (formerly FSTRACE3)
STMTRACE displays generated SQL statements (formerly FSTRACE4)
SQLCALL traces commands and data exchange between the physical and the logical layers of the data adapter.

where level is optional and is one of these options:

FSTRACE returns the trace output to the destination indicated in the allocation for
DDNAME FSTRACE. You must explicitly allocate this DDNAME.
CLIENT displays the trace output on the screen of an online session. No explicit allocation is necessary.

SET TRACEOFF=ALL
SET TRACEOFF = component [/ [level] [/ [destination] ] ]

How to Allocate FSTRACE in Batch:

You can write trace results to SYSOUT. BLKSIZE information is optional, but should be
compatible with other FSTRACE formats. For example, to allocate DDNAME FSTRACE:
//FSTRACE DD SYSOUT=*,DCB=(LRECL=80,BLKSIZE=80,RECFM=F)
You can also write trace results to an MVS sequential data set. First, allocate the FSTRACE
data set in a prior batch step (as shown) or in ISPF:
//ALLOC EXEC PGM=IEFBR14
//FSTRACE DD DISP=(,CATLG),DSN=userid.FSTRACE,
// UNIT=SYSDA,VOL=SER=USERM1,SPACE=(TRK,(5,5)),
// DCB=(LRECL=80,BLKSIZE=80,RECFM=F)
.
.
.
Then, allocate the trace data set with DISP=MOD in the batch FOCUS JCL:
.
.
.
//FOCBATCH EXEC PGM=FOCUS
//FSTRACE DD DISP=(MOD,KEEP,KEEP),DSN=userid.FSTRACE

------------------------

For my own non SQL tracing, I would allocate a file in the JCL with DISP=MOD and then use -WRITE statements where necessary in the program. I would probably write something that would identify the part of the program and perhaps the time at that moment. SOmething like this:

-*-- Set Trace Step Start Date and Time --------------------
-SET &S_ST_DATE = &DATEYYMD;
-SET &S_ST_TIME = HHMMSS('A8');

-WRITE B2TRACE
-WRITE B2TRACE --- Step 2 - Process Extract files
-WRITE B2TRACE
-WRITE B2TRACE *** Step Start: &S_ST_DATE &S_ST_TIME
-WRITE B2TRACE

YOUR CODE HERE

-*-- Set Trace Step End Date and Time ----------------------
-SET &S_EN_DATE = &DATEYYMD;
-SET &S_EN_TIME = HHMMSS('A8');
-*----------------------------------------------------------

-WRITE B2TRACE
-WRITE B2TRACE *** Step End: &S_EN_DATE &S_EN_TIME
-WRITE B2TRACE

Thanks, Ginny!

I also looked up the ECHO info in my manuals.... some of it was clear, some was not. Does the ECHO facility work when a FOCEXEC does not do any MODIFYs? My FOCEXEC has several CREAT TABLEs, which in turn are then joined, and finally end up producing a report. My FOCEXEC contains no SQL, nor does it do any MODIFY-ing.

If the ECHO facility is not for what I'm trying, are there any other items I can try to use in order to trace my FOCEXEC's logic?

Thanks so much!

Thank you, Francis,
Where my FOCEXEC is a group of CREATE TABLE steps, with JOINs in-between, and ending up by creating a report, I will try using your NON-SQL suggestions.

Thanks for writing back.... I'm looking forward to trying your suggestions!

What are these CREATE FILE steps? Are you reading data from a flat file to create FOCUS DB's?

Perhaps you can fine-tune the JCL to make it more efficient, memory allocation, FOCSORT and other fiels, etc.

My bad!! The CREATE FILE steps are nothing more than using code like the foloowing:

TABLE FILE XYZ
PRINT
FIELDA
FIELDB
FIELDC
ON TALBE HOLD AS ALPHA

TABLE FILE ABC
PRINT
FIELDX
FIELDY
FIELDZ
ON TALBE HOLD AS BETA

JOIN FIELDA IN ALPHA TO FIELDX IN BETA
TABLE FILE ALPHA
PRINT
FIELDA
FIELDB
FIELDC
FIELDY
FIELDZ
ON TALBE HOLD AS CAPPA

...and so on....

What I meant was that I do a bunch of TABLE FILEs and then JOIN the Tables I made, so that in the end I will have one Table with my desired fields that I can then do DEFINEs against and also create reports. In my IT Group, we call this sort of thing doing a CREATE FILE. Apologies for misunderstandings!

Files XYZ and ABC are what exactly? FOCUS databases? DB2 tables?

Why can't you join FIELDA in XYZ to FIELDX in ABC instead of creating the HOLD files?

When I was doing mainframe FOCUS, executing focexecs via JCL, we simply put SET MSG = ON in the JCL right before the EX focexec statement. This would cause the focexec to display in the JES listing, as it was executed, along with the results. We had SDSF for reviewing JES listings and there was no need for any -WRITE statements to a flat file to determine what happened, or ECHO. You could still do ECHO if you wanted the Dialog Manager statements to also display, but if not, you could simply go with the SET MSG=ON in the JCL. I could also include -TYPE statements in the focexec for tracing capabilities. I'm making an assumption that you're actually submiting the JCL in batch mode. If not, then this won't be of any help to you.

Good Luck.

Jessica Bottone

I use -WRITE or -TYPE statements to display the time so I can determine how long a piece of an individual program takes.

OMG!
In the vein of "Old Programmers always die but Old Software still runs production every night":
Will JCL never end? I first learned those statements waaay back in '69. Especially the classic 'DCB=(LRECL=80,BLKSIZE=80,RECFM=F)'!
[Reminds me of my days driving the 024, 026, 402 and 407, then converting their jobs to a 360/30!]

Thanks to all who have replied!!

Francis, I most likely could use JOINs as you suggested, however, this project is something I inherited, and until I feel comfortable with the FEX's code, I want to leave the code alone as much as possible.

Jessica, that is a good thought!! I didn't think at all about the "NESSAGE" line.... however, I gues I was looking for something like what can be used in VB - where you can put a STOP command into code and then step through code from that point on.

cburtt, it looks like at my shop, JCL will not die for at least another 2 to 5 years - "It's working - why do we have to change?"

As I said at the top of this reply, thank you all for replying!