However, you ask about how to determine if any records are available in the CL before calling the problem program. I’m not sure that there is any good way.

One possibility is to try these two commands after your OPNQRYF:

CPYFRMQRYF FROMOPNID( myqryf ) TOFILE( QTEMP/qryf ) CRTFILE(*YES) NBRRCDS(1)
POSDBF OPNID( myqryf ) POSITION(*START)

The CPYFRMQRY command will try to copy one record into a file in QTEMP. It’ll find a record or it won’t. If it doesn’t find any, there will be messages you can test to skip calling the problem program.

The POSDBF command will position the file pointer back to the *START. When you call the problem program, it should be able to read the first record along with any others that follow.

Does that make sense? You’ll want to run some test CL in a small program in order to see how and when the messages will appear.

Tom

Issue is not with the query, needs no change in that.

but scenario is during weekends the where condition of that query wont have records to be pulled. This cause the next called pgm fail. So need to change the CL, to have a check condition after this openqry if the select being blank, it should skip the call of a program.

I feel this is simple, sad I’m new !!

In order for us to suggest possible reasons records might be “blank”, please show code that opens the query file and reads from it.

Also, please clarify “…which sometimes return blank records”. Does that mean that when a program runs it gets some records that have data and others that don’t? Or does it mean that a program can get records with data when it runs one time, but the records are always blank when it runs another time? Do non-blank records ever show up after blank records (assuming the program doesn’t crash)?

Tom