RE: weird problems w/ Q7FSJOB job (TCPIP File Server on V3R7)

The rebuild(?) job is still going strong as I write this.  We do have access to our folders, and normal operations have not been impacted since we dismounted and remounted the folders from the VAX box yesterday morning.

Leif, thanks, but it doesn't really help *me* >to know that the object is a "commit block" <.  So, please, fill me in.  Why/How does a commit block object get damaged?  Anything that can help prevent this in the future?

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

-----Original Message-----
From:   Andy Nolen-Parkhouse [SMTP:aparkhouse@mediaone.net]
Sent:   Wednesday, July 25, 2001 7:06 AM
To:     MIDRANGE-L@midrange.com
Subject:        RE: weird problems w/ Q7FSJOB job (TCPIP File Server on V3R7)

From the description you give Dan, it looks as though the internal cross
reference which maintains the directory structure of your Document
Library Objects became unusable due to a damaged object.  The message
indicated that no recovery is necessary because the system would rebuild
the required object.  That is what it is doing in your second message.
I hope that it is done by now, but it is very possible that you did not
have access to your folders during the rebuild.

Andy





> -----Original Message-----
> From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]
> On Behalf Of Bale, Dan
> Sent: Tuesday, July 24, 2001 6:04 PM
> To: MIDRANGE-L@midrange.com
> Subject: weird problems w/ Q7FSJOB job (TCPIP File Server on V3R7)
>
> A real brain stumper here, any help would be appreciated.
>
> We've got a model 510 running V3R7, been running fine since it was
> installed eons ago.  This morning, in the wee hours, we get an error
in
> QSYSOPR:
>
> Message ID . . :  CPF8190       Severity . . :  20
> Message type . :  Information
> Date sent  . . :  07/24/01      Time sent  . :  04:09:24
>
> Message . . . . :   Object CBLK257381QDLS001   b»=ÔØ type X'0FC1'
>   damaged.
> Cause . . . . . :   Object CBLK257381QDLS001   b»=ÔØ found damaged
> and
>   may no longer be usable.  The owner of the object is QDBSHR.  No
owner
>   indicates that the object is a temporary object.  The VLOG dump
> identifier
>   is 01000CC5.
> Recovery  . . . :   No recovery action is required.  The system will
> take any
>   necessary action to recover the object.
>
> This was followed by CPF8198: Damaged object found.
>
> Unfortunately, some action *was* required, as we lost our connection
to
> two other interfaces that drive some of our automation equipment.  We
> tried ending TCP and restarting with no success.  As soon as we
> restarted TCP, we noticed that local port 2049 for associated user
> profile Q7FSOWN was experiencing a high volume of traffic (WRKTCPSTS,
> then option 3"Work with TCP/IP connection status"), even though there
> were no "transactions" going on with the other interfaces.  (In the
end,
> we dismounted and then re-mounted on the VAX box, and that solved that
> problem.)
>
> Job Q7FSJOB in subsystem Q7FSSBS starts right after TCP is restarted.
> The job log for this job shows that it does a "call QTCPFSS/Q7FSSTRSD"
> right from the get go, and ever since it started several hours ago,
its
> been running a slew of RTVDLONAM commands, such as this one:
>
> 4400 - RTVDLONAM DLO('*SYSOBJNAM') FLR('*NONE') DOCID('*NONE')
> LADNTSP(*NONE) SYSOBJNAM(OJQL095368) OBJCLS('*DOC') RTNDLO(&RTNDLO)
> RTNFLR(&RTNFLR) RTNDOCID(&RTNDOCID) RTNLADNTSP(&RTNLADN)
> RTNOBJNAM(&RTNOBJNAM) RTNOBJCLS(&RTNOBJCLS)
>      - RETURN        /* RETURN due to end of CL program */
>
> There are no other entries that I've been able to see (job logging was
> not turned on originally, so I don't know if there's anything else
> missing that would have been logged otherwise).  It would appear that
> the RTVDLONAM is part of a sanity check procedure that is looking at
all
> of the DLO objects and checking the DLO attributes.
>
> Any ideas on what's happened here?
>
> Dan Bale
> IT - AS/400
> Handleman Company
> 248-362-4400  Ext. 4952
> D.Bale@Handleman.com
>   Quiquid latine dictum sit altum viditur.
>   (Whatever is said in Latin seems profound.)