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

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.