RE: How to tell if an object is in use?

["Stone, Joel" <StoneJ@xxxxxxxxxxxxxxxx>]

Greg - have you considered handling this using a completely different
method?

After the pgm processes each record in the batch file, mark the record as
deleted (either change a flag value to "D", or actually delete the record).
(I would recommend changing a flag value so you can easily view deleted
records).

Later during the nightly or weekly maintenance runs, when the interactive
system is down, purge the deleted records using a program and/or SQL and
RGZPFM.

Then you will never see those pesky lock issues!!




-----Original Message-----
From: Greg Wenzloff [mailto:GWenzloff@xxxxxxxxxxx]
Sent: Wednesday, February 09, 2005 8:45 AM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: How to tell if an object is in use?


I have a CLP that will process a file in batch then delete it.   Sometimes a
user first performs maintenance on the file but fails to exit the
maintenance program leaving the file locked.    The CLP which runs in batch
then hangs.

I put the following code in the program that is about to submit the batch
job:

/* SOMETIMES USERS ARE IN MAINTENANCE IN ANOTHER SESSION */             
        ALCOBJ OBJ((&FILEE *FILE *EXCL *FIRST)) WAIT(5)                  
        MONMSG MSGID(CPF0000) EXEC(DO)                                   
                <<< send the user a message to get out of the file  >>>>
                ENDDO                                                    
        DLCOBJ     OBJ((&FILEE *FILE *EXCL *FIRST))                      
  
This ALCOBJ/DLCOBJ does not seem very elegant.   Is there a better way to
tell if an object is being used by someone?

Thanks,
Greg                                                                       
-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.