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.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.