|
V5R3 allows a RGZPFM while the file is in use. However, journalling is required. Session 1: CREATE TABLE ROB/EVAN (MYCHAR CHAR (15 ) NOT NULL WITH DEFAULT, PRIMARY KEY (MYCHAR)) STRJRNPF FILE(ROB/EVAN) JRN(ROB/ROB) upddta rob/evan inserted 4 records dsppfm rob/evan *...+. zulu alpha yankee bravo upddta rob/evan deleted zulu rolled down to yankee and have it up Session 2: RGZPFM FILE(ROB/EVAN) KEYFILE(*FILE) ALWCANCEL(*YES) LOCK(*SHRUPD) CPD3198-Reorganize operation was unable to truncate file EVAN in library ROB, member EVAN. Recovery . . . : Exclusive use of the member is necessary to truncate the deleted records at the end of the member. Specify LOCK(*EXCL) and repeat the reorganize operation again. CPC2983-Data in member EVAN reorganized. dsppfm rob/evan *...+. alpha bravo yankee DSPFD still shows the one deleted record. Oh well, at least they're sorted. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com Evan Harris <spanner@xxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 02/10/2005 02:10 AM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc Subject RE: How to tell if an object is in use? Hiya The pesky lock issues are now transferred to the period when the RGZPFM has to be run - potentially a much longer period of time and more of a pain to deal with. If you use a soft delete as suggested, then alter the file to REUSDLT (presuming you can) and thereby eliminate the RGZPFM and another potential lock conflict. With respect to the original problem, if the user has just left the screen on, why is the object locked ? Perhaps altering the maintenance program so the record/object is only locked when an update is actually occurring rather than locking the file when the procedure is entered might be a better way to go Apologies if this is not what is happening, it's just what it sounds like :) Regards Evan Harris >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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.