|
I sent this note to midrange-l. If you could write a tool that could determine that no database file is ever used without key, this would be very interesting for promoting the use of REUSEDLT(*YES). A few points: 1. I believe that CL has to work by key. 2. Otherwise the file could be limited to RPG and RPGLE. Overrides are another question. This could be a $25 tool, or a $5 tool with lots of caveats. Al - in Tampa - on the way home. Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com Al Barsa <barsa@barsaconsu lting.com> To Sent by: Midrange Systems Technical midrange-l-bounce Discussion s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 02/10/2005 06:39 Subject AM RE: How to tell if an object is in use? Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> There are two primary issues here: 1.) To guarantee that an object is or isn't in use, you can always allocate it with ALCOBJ. There are a lot of details as to locking levels, and what this will do with the remainder of your application, that I will not get into this here. 2.) The problem with reuse of deleted records is the issue of program logic. If you can GUARANTEE that EVERY program on your system reads the database file by key, no sweat. But if for performance reasons you don't, there is a risk: If the logic of a program that reads a program without a key assumes that relative record "n" was ALWAYS written BEFORE record "n+1", REUSEDLT(*YES) will not work, because you can no longer guarantee this fact! One more minor issue. We normally think that the last record added to the PF will be the last relative record number, but you can no longer guarantee that with REUSEDLT(*YES), and this can screw up your mind while debugging. Bottom line: If you're designing a new application with large master files where RGZPFM will eventually become issue, set a standard that you always process by key, or at least when processing sequentially, never make any arrival sequence assumptions. Develop without REUSEDLT(*YES), because debugging is easier, and then change the file to REUSEDLT(*YES) prior to the testing phase. And then to a final reorg (or clear is possible [not always possible]) of all physical files before going into production. Lastly, there are some trivial overhead issues, that were real issues when REUSEDLT(*YES) came out in V2R1M1, but today those issue are moot because of the faster processors. Al - in Tampa - on the way home Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com Evan Harris <spanner@xxxxxxxx nz> To Sent by: Midrange Systems Technical midrange-l-bounce Discussion s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 02/10/2005 02:10 Subject AM RE: How to tell if an object is in use? Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> 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. -- 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.