Whew!  Thanks!  I'm slowly loosing my mind, and after this incident, I
thought it  was happening even faster!!



Ray Shahan






> -----Original Message-----
> From: Michael Berkowitz [SMTP:[log in to unmask]]
> Sent: Wednesday, February 25, 2004 11:13 AM
> To:   Shahan, Ray; [log in to unmask]
> Subject:      RE:      Weird CIERROR
>
> Ray Shahan writes
>
> -----Original Message-----
> From: Shahan, Ray [mailto:[log in to unmask]]
> Sent: Wednesday, February 25, 2004 9:03 AM
> To: [log in to unmask]
> Subject: Weird CIERROR
>
>
> Hi all,
>
>         Can anyone tell me what's going on here?  This file is nothing
> more
> than a flat file that's being created via a COBOL prog.  I did a LISTF,2
> and
> got the same error as a LISTF,9 and I don't recall this ever happening
> to me
> before (on a straight ASCII flat file).
>
>
> LISTF PR020O01.DATAWORK.SFD,9
> Cannot access file "!" due to lock contention. (CIWARN 9169)
> ----------------------------------------------------------------
> From Google
> http://groups.google.com/groups?q=listf+lock+contention&hl=en&lr=&ie=UTF
> -8&oe=UTF-8&selm=94bc4r0u8%40enews4.newsguy.com&rnum=1
>
> > In the middle of a "LISTF GETYR@,2" command she got the
> > following display:
> >   Cannot access file "/ACCT/GROUP/GETYR3FN" due to lock
> >   contention  (CIWARN 9169)
> >
> > I remember someone reporting something similar when dealing
> > with one of the 'newer' 'listf' options, but nothing with the
> > old mode 2.
>
> LISTFILE (and LISTF) were partially re-written to support the
> "access" (,8 and ,9) feature.  One of the goals for LISTF,access
> was to not have the LISTF hang if there was a real problem with
> the file being listed.  The original code did a special open of
> each file before listing it.  This open unconditionally locked a
> few file system semaphores.  A file system bug (or some very unusual
> condition) could cause the open to wait forever and the LISTF would
> hang.
>
> The new code doesn't really open the file, but still needs to obtain
> the same semaphores.  However, it locks one of the semaphores with a
> short time out value (10 millisec), so if that semaphore is busy, LISTF
> won't get the lock that time.  The code loops 400 times trying to get
> the lock with the 10 millisec pause after each lock attempt.
>
> Typically, you won't see CIWARN 9169.  There was a patch or two to
> increase both the pause time and the number of iterations.  The
> numbers I used above are for 6.5 and later.  The new LISTF locking
> method affects all formats except 0 and 6.
>
> Probably an SR should be submitted to the lab, since the goal of the
> locking implementation was (and is) to never see CIWARN 9169 unless
> you have a file hang situation.  I've cc'd Craig Fairchild (File System
> Guru), who helped with this design and, in case, I have over simplified
> the explanation.
>
> Hope this helps,
>  Jeff Vance, CSY
>
> Mike Berkowitz
> Guess? Inc.
>
>
> ========================================================================
> This e-mail message has been scanned for Viruses and Content and cleared
> by School Specialty's email filtering solution.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *