RE: IFS -- MIDRANGE-L

Thanks Ken, we just had a problem yesterday where I needed this information.

-----Original Message-----
From: Graap, Ken [mailto:keg@nwnatural.com]
Sent: Friday, October 19, 2001 11:04 AM
To: 'midrange-l@midrange.com'
Cc: 'steven.donnellan@simonjersey.com'
Subject: RE: IFS


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.