Qdbrrcdl api

[MelissaG]

We've been trying to use QDBRRCDL to find out what / who has record locks at the beginning of a nightly batch program. The situation is that people on the overnight shift walk away for "lunch" and leave a particular screen open that ends up locking FILEA. Well, at 2:45 AM a batch job kicks off that allocates and clears FILEA so it can be updated by data from another system.

We were hoping QDBRRCDL would allow us to warn the user and then end their jobs rather than our current process, which is waiting for the computer operator to notice the message, end the job and do a retry on the batch job --- sometimes this isn't happening for hours! Our batch job only runs a few seconds if no one is in FILEA.

My co worker is doing this:

DCL &RL_RCVVAR *CHAR 3216
DCL &RL_LEN *INT VALUE( 3216 )
DCL &RL_FORMAT *CHAR 8 VALUE( 'RRCD0100' )
DCL &RL_RRN *INT VALUE( 0 )
DCL &RESET_IND *CHAR 10 VALUE( '*NO' )
DCL &ERRCODE *CHAR 116 VALUE( X'00000074' )
DCL &ERRLEN *DEC ( 3 0 ) VALUE( 0 )
DCL &RL_AVL *INT VALUE( 0 )
DCL &RL_RTN *INT VALUE( 0 )

        /*some other code here*/
CALL QDBRRCDL ( +
                                &RL_RCVVAR +
                                        &RL_LEN +
                                &RL_FORMAT +
                                  'FILEA *LIBL ' +
                                         '*FIRST ' +
                                      &RL_RRN +
                                  &ERRCODE +
                                  )​

CHGVAR &RL_AVL %BIN( &RL_RCVVAR 1 4 )
CHGVAR &RL_RTN %BIN( &RL_RCVVAR 5 4 )

IF ( &RL_AVL *EQ 0 ) DO
GOTO CMDLBL(ENDLOOP)
ENDDO​ 

and expects &RL_AVL to be > 0 when the record is locked. We aren't finding that to be the case. He has been struggling with this for a couple of days. Neither of us can see the issue when we are looking at the IBM documentation. Are we incorrect that this API will do what we need it to? Are we using the wrong format? Should we just give it up and go get jobs at Starbucks? (MMMM...coffee..... ) Any push in the right direction will be GREATLY appreciated.

[Brian Rusch]

An alternative way to approach this problem would be to use the OBJECT_LOCK_INFO view to look at object locks for FILEA instead of record locks. In your CL:

RUNSQL     SQL('create table QTEMP/LOCKS as (select +
                        distinct cast(job_name as char(28)) as +
                        jobname from object_lock_info where +
                        object_name = ''FILEA'') with data') +
                        COMMIT(*NONE)​

That will create a file in QTEMP with the qualified job names of any jobs holding a lock on FILEA which you then can read in your CL using RCVF.

[Scott Klement]

Shouldn't you be using RRCD0200? Or am I confused?

[Scott Klement]

Thinking about this some more... you said "Well, at 2:45 AM a batch job kicks off that allocates and clears FILEA so it can be updated by data from another system." Are you SURE the programs that are left running when someone "leaves for lunch" are holding a record lock? They don't need to be in order to create the problem you cite.

The ALCOBJ command does not check for record locks. It checks for object locks, and optionally member locks. The CLRPFM command also checks for member locks... record locks aren't needed to cause it to fail.

Maybe that's the problem, here? You're looking for record locks when you should be looking for member locks?

[Peder Udesen]

Assuming the file is opened for input for the session causing the trouble, then what causes the problem is
an object lock. If the file is opened for update, then you could potentially have a record lock.

In the first case you could replace the CLRPFM FILEA with an SQL statement DELETE FROM FILEA
If there isn't an object lock the SQL statement will perform a CLRPFM otherwise it willl delete the records one by one.

In the second case where the file is opened for update, you could change the code the night shift is using so it would time out and terminate
after perhaps ? hour when not used.
Alternatively send a break message telling everybody that QINTER will be closed in 5 minutes. Then end and restart QINTER.

[MelissaG]

Thank you all for your advice! My co-worker believes he has found how to best do this using the SQL option in a way that will allow us to know exactly who and what program is causing the issue. I like that because then we can address the underlying issue. I also apologize- I tend to use all the locks interchangeably and I know that I shouldn't! I will try to do better about that. Have a wonderful day and thank you again.