It's connected with the PCC/CONSER PURL Project and the withdrawal/deactivation of a BibPURL. Details from http://libraries.universityofcalifornia.edu/hots/conser/purldocumentation.doc are as follows:

B.	How to update the OCLC record when you withdraw/deactivate a BibPURL

If you withdraw/deactivate a BibPURL that exists on an OCLC record, you will also need to update the OCLC bibliographic record(s). 
Firstly, search for all OCLC records that contain the BibPURL in question.  Use the search index for "access method" (am:) to search for the BibPURLs.  Or try this search method: In Connexion, go through the motions of creating a new record.  Click on Create.  Then check "Use extracted data from URL."  Make sure "Show records that include that URL" is checked.  Type the BibPURL in the URL box.  Click on the "Create" button.  You will get a list of any catalog records that contain that BibPURL in the Search Results box.  Don't click on Continue with record creation.  You can open the record by clicking on the"Display" button.  Otherwise, you can log off.

Leave the BibPURLs and URIs in the 856 field and add an appropriate $z note.   Change the 856 second indicator to blank.**  

URL is no longer valid: 
856 4_ $u http://bibpurl.oclc.org/web/#### $u http:// ... $z No longer valid when searched on: MM/DD/YY

URL is still valid but points to a different resource:
856 4_ $u http://bibpurl.oclc.org/web/#### $u http:// ... $z No longer valid for this resource when searched on: MM/DD/YY

The resource is no longer open access:
856 4_ $u http://bibpurl.oclc.org/web/#### $u http:// … $z No longer freely available when searched on: MM/DD/YY

URL is still valid but no full text is available: 
856 4_ $u http://bibpurl.oclc.org/web/#### $u http:// ... $z No full text available when searched on: MM/DD/YY

Replace the master OCLC record.  Deactivate the BibPURL.  

** OCLC recommends 2nd indicator blank because utilizing any other display constant (0, 1, or 2) would be misleading.  Using the blank 2nd indicator allows the explanatory $z to describe the situation exactly.   Users are always free, at the very least, to edit records locally for their own use or to follow LC practice as outlined in LCRI 9.7B.  Of course, users who are participating in such cooperative programs as CONSER should follow the guidelines of those programs when they are in conflict with more general OCLC advice.

-----Original Message-----
From: Program for Cooperative Cataloging [mailto:[log in to unmask]] On Behalf Of Les Hawkins
Sent: Tuesday, May 22, 2012 5:45 AM
To: [log in to unmask]
Subject: Re: [PCCLIST] Question re invalid URLs in 856

We should rethink CONSER practice if it is causing problems. I think that the basic reason for the difference was to follow OCLC's preferred practice for indexing of the 856.

Les Hawkins
CONSER Coordinator

On Mon, 21 May 2012, Steven C Shadle wrote:

> Greta -- TBH, I have no idea why there are different practices or what 
> the purpose was of leaving the non-working URL in 856|u.  It was in 
> place before we made the recent update to the CCM module.  Anyone have 
> any idea what the reasoning was behind the CONSER decision?  --Steve
> 
> Steve Shadle/Serials Access Librarian         [log in to unmask]
> NASIG President
> University of Washington Libraries              Phone: (206) 685-3983
> Seattle, WA 98195-2900                            Fax: (206) 543-0854
> 
> On Mon, 21 May 2012, Greta de Groat wrote:
> 
> > I have a question about PCC practice for the URLs for internet 
> > resources that are no longer available.
> >
> > LRI 9.7B says the following
> >
> > 2) If searching indicates that the resource is no longer available, 
> > create a note to reflect this fact by changing subfield $u in field 
> > 856 to subfield $z and modifying the subfield to show that the 
> > resource is no longer available, indicating the last date that the resource was searched. ...
> >
> > and gives the example
> > revised record
> > 856 41 $z Electronic address (http://www.example.com) not available 
> > when searched on [date]
> >
> > However CONSER cataloging module module 31 (dated March 2012) says:
> >
> > If the only link appearing on the CONSER record is an invalid link, 
> > it can be left on the record and labeled as invalid in the subfield 
> > $z of the 856 field. Note that the second indicator is blank and 
> > that the non-working URL is maintained in subfield $u of the 856. 
> > This coding differs from LC practice documented in LCRI 9.7B where 
> > the non-working URL is moved to a subfield z so that it does not 
> > appear on LC’s link checking reports repeatedly. The example below 
> > is based on a recommendation from OCLC and is derived from current 
> > system indexing needs and OCLC'€™s electronic address checking software (see OCLC'€™s recommendation at:
> > http://www.oclc.org/support/documentation/worldcat/cataloging/electronicresources/).
> > 856 4# $z Link no longer valid as of Dec. 4, 2000 $u http://www...
> >
> > So, we're confused about which practice to follow, since it seems 
> > that there are two conflicting PCC practices. This is also causing 
> > us problems internally in our opac, since we can't suppress the 
> > display of a hotlink if the URL is in $u. And we don't quite 
> > understand why one would use a public rather than non-public note ($x) for this.
> >
> >
> > Thanks
> > Greta de Groat
> > Stanford University Libraries
> >
>