|
Ken, Fantastic. That's so simple. It sure beats using the complicated WRKOBJLCK command. :) I don't save many posts, but I will with yours. I may even get it framed. Greg >From: "Graap, Ken" <keg@nwnatural.com> >Reply-To: midrange-l@midrange.com >To: "'midrange-l@midrange.com'" <midrange-l@midrange.com> >CC: "'steven.donnellan@simonjersey.com'" ><steven.donnellan@simonjersey.com> >Subject: RE: IFS >Date: Fri, 19 Oct 2001 08:04:28 -0800 > >Steven .... > >Boy oh boy .... are you going to like this!!! <smile> ...Kenneth > > >IFS Lock - How to see who has one... > >First, determine if the file is checked out, especially if the person >reporting the problem has stated that the file remains locked across IPLs. >Simply use the DSPLNK command for the object and take option 8. If you do >not see any checkout fields, the file is not checked out. If you see >checkout information but the user profile name is unreadable or simply >blank, you might want to talk with IBM Support Line, since we have seen >some intermittent directory glitches with this symptom. To free the file, >use the CHKIN command. > >If the file is not checked out, the process becomes a bit more involved. >Start by using our dumper to find the system pointer to the object. For >example, if you are examining /mydir/mysubdir/myfile, use the following >command: > >CALL QP0FPTOS '/mydir/mysubdir/myfile' > >That is, "QP-zero-FPT-oh-S". Make sure you press F10 to include detailed >messages. The command produces a message like the following: > >DSPJOBLOG to find system object at address. > >Specified path refers to a system object at address > 000000000000000014B5FCF424001E00 > >The critical portion of the address on a RISC system is underlined above. >Its twelve characters starting under the second "e" in "refers" and ending >under the second "s" in "system". Copy those twelve characters. > >Now, you need to call the dumper with a different parameter: > >CALL QP0FPTOS *DUMPALL > >This will produce a spool file containing information about vnodes and open >instances. Search the spool file for the system pointer string you saved >previously, but you need to add a space between the 10th and 11th >characters: > >Find . . . . . . 14B5FCF424 00 > >When you perform the search (F16), you should end up positioned to a line >like this: > >h_tnode 0000000100 0072C0 h_c 14B5FCF424 001E00 h_next >F2D5CE48B6 020E10 h_prev *NULL > >You are now looking at part of the vnode information for the file. The >vnode address should be about seven lines backward from this line, right >above a line starting with "v_lock", and look something like: > >F1799388DD 008000 > >Copy this information. About three lines below the address is the >"v_usecount" field. Take note of the number there. > >Now, scroll forward until you see the line containing only "Lock flags". >The three lines following that show locking information for the object. >Take note of the information there. > >To determine whether the file is actually open, we need to search the spool >file for the vnode address until we find a match on a line containing >"f_object". If no such match is found, the file was not open at the time >of the dump. If a match is found, search backward in the spool file for a >line starting with "Process". This line will contain the job name which >has the file open. For instance, the following line: > >Process QPADEV0007RJTRAFF 022600 PPCO address EECFB2AFE6 000200 > >indicates that job 022600/RJTRAFF/QPADEV0007 has the file open. Of course, >that may not be the only job, and the file may be open multiple times in >the same job. Repeated searches for the vnode address will yield all of >the open instances for a file. > >Now that you have all the information, here is what you do with it: > > > > 1 If you find that the file is open, simply ending the opening jobs > should free the file. > > > > 2 If the lockattrs value in the Lock flags area is "1", then > SAV/RST is involved. If there is no current SAV/RST activity, > then it is either the case that a SAV or RST operation was > interrupted while the lock was held and the lock was not > released, or there is directory damage which confused SAV/RST > into locking and unlocking the wrong objects. An IPL is > necessary, and if the problem reoccurs, a RCLSTG is probably > needed. > > > > 3 If the object is still locked right after an IPL and the object > is not checked out, then some autostart/prestart job is grabbing > the lock. The system owners will have to disable that if they > can. > > > > 4 If you find some odd circumstance, such as the usecount being > negative, or lock flags set while the usecount is zero, and so > on, you need to get one of the file system experts involved. > Some extra-fine analysis is necessary in these cases. > > > > 5 If the usecount seems consistent with the lock flags information, > but there is no open instance, the system owners will have to > find out what application is associated with a certain file and > end all jobs related to that application. Try ending all > servers. > > > > 6 If all else fails, get a file system expert involved. The lock > bits can be patched, but that is a risky move and should only be > employed when the system owners refuse to IPL. > > >(Technical source - IBM supportLIne) .... > >Well, did you like this procedure? > >Kenneth > >**************************************** >Kenneth E. Graap >IBM Certified Specialist >AS/400e Professional System Administrator >NW Natural (Gas Services) >keg@nwnatural.com >Phone: 503-226-4211 x5537 >FAX: 603-849-0591 >**************************************** > > >-----Original Message----- >From: steven.donnellan@simonjersey.com >[mailto:steven.donnellan@simonjersey.com] >Sent: Friday, October 19, 2001 6:04 AM >To: midrange-l@midrange.com >Subject: IFS > > >This is a multipart message in MIME format. >-- >[ Picked text/plain from multipart/alternative ] >Is there an IFS equivilent of WRKOBJLCK? > >Steven Donnellan >AS/400 Systems Manager >IBM Certified Specialist - AS/400 Professional Operator >Simon Jersey Ltd > >http://www.simonjersey.com >-- > > > >_______________________________________________ >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list >To post a message email: MIDRANGE-L@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com >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@midrange.com >To subscribe, unsubscribe, or change list options, >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l >or email: MIDRANGE-L-request@midrange.com >Before posting, please take a moment to review the archives >at http://archive.midrange.com/midrange-l. > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.