How does 'IN' works in db2 sql query?

My requirement is to select data from DB2 table where phone number is equal to 16 set of phone numbers.I have tried to run this query given below on my local test data and my program is successfully working! But , when i try to run this same program on real table(backup table) , my RUN jcl is getting failed with S722 abend.

i feel it is not space abend because we are using file with attributes of 7 cylinders(1 primary,6 secondary). According to my research i found out that sql query with 'IN ,'LIKE' takes too much time to execute so changed Time parameter in Jobcard to NOLIMIT. But noluck !!

Can someone help me with any other way of writing this query ? or help me to rectify this issue....

query like this :

EXEC SQL
DECLARE WS-CURSOR CURSOR WITH HOLD FOR
SELECT CUST_ID,CUST_NAME,SEQ_NUM,PHONE_NUM FROM PHONE_TAB 
  WHERE PHONE_NUM IN ('123456789','789456123','456789123','789456123' etc) AND
        PHONE_TYPE = 'DU' 
END-EXEC.

Thanks in advance !!

Solution

The Sx22 family of abends indicate exceeding some system defined parameter. A S322 typically indicates you've exceeded the amount of CPU time in the TIME parameter on your job card or job step, for example.

A S722 abend indicates you have produced more spool output than is allowed by your shop's JES parameters. You need to determine the source of that spool output to resolve the abend.

You may have a core dump (CEEDUMP), debugging output you've coded (SYSOUT or SYSPRINT or STDOUT or STDERR), or a runaway report DD you've coded. The JESMSGLG DD visible in the spool either at the top of your output in SDSF or by selecting your job with a '?' may report errors prior to the S722.

Perhaps you are experiencing a S322 which leads to the S722. This is entirely possible since the problem occurs with a large quantity of data.

Setting the time parameter to NOLIMIT is an expensive debugging technique as most mainframe shops have a chargeback algorithm in place, typically CPU time = money in someone's budget. Your shop may have a JES exit in place that substitutes some other value for NOLIMIT specifically to prevent its use.

As indicated by user6542823, you could add a JOBPARM LINES=some-large-number to get around the S722, but you'll still have to resolve the underlying problem.

z/OS tries to give you as much information as possible to debug. Make use of what it gives you.

Given...

you've said your program executes fine with local test data
the problem manifests when running against a backup of the production sized data

...then if...

the definition of table PHONE_TAB in your local test data matches that in the backup and the production data
your program binds successfully
you have authorization to read the backup data

...the problem is likely not with your SQL but rather related to the volume of data.

Look at the EXPLAIN output for your package and you'll likely see you're scanning the entire PHONE_TAB table. Perhaps there is an index in place in production that is absent in the backup you're testing against.