|
Nowadays we may often assume processing by key. However, some EDI feeds don't have that luxury. That's about the only snake in the grass around here. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com Al Barsa <barsa@xxxxxxxxxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 02/10/2005 06:39 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? 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.