ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

File Lock

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • File Lock

    I'm experiencing a lock on a member in a file. The message I receive is,
    "Member (file name) already in use." The lock is apparently created
    by a RPG program .

    I cannot find any way to release the lock. I've tried DLCOBJ for all levels
    (*SHRRD/*EXCL/etc.) for both the physical and the logical file involved.

    Nothing seems to work -- except logging off and logging back on
    again.

  • #2
    Re: File Lock

    If the lock is being set by the RPG program please check how the RPG pgm is returning back the control to the calling program.

    If the program is just doing a RETURN and not setting on LR indicator before returning back the control then the lock would remain. You have to have a SETON LR statement before RETURN statement.
    Regards,
    KR

    Comment


    • #3
      Re: File Lock

      besides LR if you chain to a file when its an update file
      you must release the lock prior to leaving the program or a
      lock will remain.

      you can chain with a no-lock

      chain(n) (key1:key2) somefile

      or you can use the unlock opcode on the file...
      I'm here to chew bubble gum and kick @#%@#%@#%.....and I'm all outta bubble gum !
      Yes I'm talking to you squirrel nuts.

      Comment


      • #4
        Re: File Lock

        Hi,

        yet an other question:
        Are you files registered in a journal and are you working with commitment control?
        A row/record locked under commitement controls can only be released by executing a Commit (for confirmation) or Rollback (for resetting).

        Btw a record locked under commitment control cannot be released with the (N)-extention in RPG!

        Birgitta

        Comment


        • #5
          Re: File Lock

          hi.,


          Thank you guys fior your reply for my query..

          but still i didn't get the solution for that..

          ReachKrishna : Krishna I am Setting ON the LR indicator.

          as400Pro: I used that file in the input mode only not in the update mode..

          B.Hauser : no journel is attached to that file.

          regards .,

          Mukundan.M

          Comment


          • #6
            Re: File Lock

            Hi,

            It wasn't clear intially, but is the message "locked to this job" or simply "Already in use".

            If it is the later then this means that some other job, process or user is using this member. You can find out what is locking the member by using WRKOBJLCK for the file in question.

            If it is the former then either your current program or a called/calling program is holding a lock. A combination of the things mentioned in the other responses should help you resolve this.

            HTH

            Mike
            You don't stop playing games because you get old, You get old because you stop playing games!

            Comment


            • #7
              Re: File Lock

              hi mike.,

              i got the later one. that is 'Already in use'.

              i checked with WRKOBJLCK. the PF is being locked by RPG program. with lock status *SHRRD. and my RPG only Reads the physical does not updates.

              what i am trying to do is..

              in one session i am running a RPG program.
              in another session i am trying to clear the physicial file using CLRPFM command which was used for input in the above RPG program.

              I got the following error message.

              Message ID . . . . . . : CPF3156
              Date sent . . . . . . : 07/09/06 Time sent . . . . . . : 14:36:57

              Message . . . . : File BFD in library MUKUNDAN in use.

              Cause . . . . . : Either the initialize physical file member (INZPFM)
              command or the clear physical file (CLRPFM) command failed because the file
              is being processed in another job or thread within your job.
              Recovery . . . : Allocate the file (ALCOBJ command) and then try either the
              INZPFM or the CLRPFM command again.

              Comment


              • #8
                Re: File Lock

                You cannot clear a File in one job while it is being accessed by another job, regardless of whether that file is open for input or update.

                CLRPFM needs an "Exclusive" lock to work. Therefore you cannot do this.

                You would need to end the job on the first session before the CLRPFM would work.
                You don't stop playing games because you get old, You get old because you stop playing games!

                Comment


                • #9
                  Re: File Lock

                  Thank you Mike..

                  is there is any way to read a file without locking it, in RPG?

                  Comment


                  • #10
                    Re: File Lock

                    The problem here is that you need to distinguish between "File Locking" and "Record Locking"

                    When a program starts that uses a file in RPG a basic Lock is applied to the file in all cases. This basically tells the system that this program is using the file, doesn't matter if it's input or update mode.

                    Declaring the file as input or update, tells the program how to handle "record" level locking. i.e. the record will not be locked in Input mode but will be locked in Update mode.


                    The question I would ask is "Why would you need a program to Clear the file while users or another program is viewing it?"

                    If the Clearing of the file is part of an End of Day process then some sort of check on open jobs and a way of closing them first would be required.

                    HTH

                    Mike
                    You don't stop playing games because you get old, You get old because you stop playing games!

                    Comment


                    • #11
                      Re: File Lock

                      You can clear a file that is in use, provided a record lock is not in place. You need to use SQL

                      DELETE FROM myfile

                      This will delete all records from the file, and does not require exclusive access. The SQL statement can be imbeddded in RPG or run seperately.

                      Comment


                      • #12
                        Re: File Lock

                        Originally posted by arrow483 View Post
                        DELETE FROM myfile
                        Depending on the size of the file this still hogs space, with the SQL delete, the records are flagged as deleted but still exist in the file - assumedly this takes up disk space ?

                        Total records . . . . . . . . . . . . . . : 0
                        Total deleted records . . . . . . . . . . : 124


                        But with the CLRPFM command it gets rid of the deleted records as well.

                        Total records . . . . . . . . . . . . . . : 0
                        Total deleted records . . . . . . . . . . : 0


                        GC
                        Greg Craill: "Life's hard - Get a helmet !!"

                        Comment


                        • #13
                          Re: File Lock

                          Hi

                          There is a parameter on CRTPF/CHGPF that may be usable:
                          REUSEDLT(*YES)
                          LP Zdenko

                          Comment


                          • #14
                            mukundan_mv, there are a couple of things you can do to limit locking files and records in RPGLE. One is to use SQL to access & update the data files. The second is to use the USROPN option on the file. Then manually open the file before use, and manually close it after the use. I prefer the 1st option due to its ease of use. However, when converting a program to SQLRPGLE isn't an option, the USROPN (or UC in RPG II) is the better option. Of course, that's just my 2 cents worth, and this is an old thread, but I thought these notes might be useful to others who might find them in the future.

                            Comment

                            Working...
                            X