HP3000-L Archives

October 2000, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Cadier <[log in to unmask]>
Reply To:
Bill Cadier <[log in to unmask]>
Date:
Wed, 4 Oct 2000 12:03:58 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (79 lines)
Hi John,

Since nobody had responded to you on this (that I know of) and I just had the
opportunity to look at this code I thought I'd try to answer your questions:

1. (system) is used to indicate a job or session that is in some state
other than fully logged on. Since the job/session is in a transitional state
we do not attempt to display the job/session number.

2. ...dead(x) usually means just that and the 'x' (or '5' in your example) is the
escapecode. LISTFILE  uses a TRY/RECOVER block inside the loop
that looks at each process accessing a file. This ensures that any trap
will be intercepted and prevent, for example your CI from being logged
off. It is also used in this case to indicate what operation was being
performed that could not complete. Following is a _reasonably_ accurate
list of what codes 1..5 mean. As you can see the bottom line is that the
process has terminated as we were scanning the list of file accessors.

dead(1): Mapping PID (process ID) to PIN failed - likely cause, PIN is dead.
dead(2): JSINFO returned non-zero status, likely cause job/session gone or
        PIN is dead.
dead(3): Same as 1, different code location.
dead(4): Same as 3 (or 1), different code location.
dead(5): AIFPROCGET returned non-zero status, likely cause, PIN is dead.

Although this has never occured to my knowledge, I should also mention that if
you were to see ...dead(nnnn) where 'nnnn' were a rather large number this might
indicate that an actual trap occured. If this is ever observered it would be good
to report it to the HP Reponse Center especially if it were repeatable.

So both conditions you have observed are completely normal. Probably not so
likely on a largely idle system but certainly more likely on a very busy one.

I hope this helps!

Best Regards,

Bill Cadier
HP/CSY
reply to: [log in to unmask]

-----Original Message-----
From: John Pollard <[log in to unmask]>
To: [log in to unmask] <[log in to unmask]>
Date: Monday, October 02, 2000 9:59 AM
Subject: [HP3000-L] LISTFILE ,locks


>I just discovered a couple of results of the LISTFILE ,locks (and probably
>LISTFILE ,access) which I could not find explanations for in the online
>documentation. Can anybody help?
>
>1.)
>FILE: L01217D.CUSTOMER.CLAIMS
>8 Accessors(O:8,P:8,L:0,W:1,R:0),Share
>system  BOB,CUSTOMER.CLAIMS            P:1,L:0,W:1,R:0      LDEV: 217
> #P430   (LCS001.PGM.CLAIMS)
>  ACCESS: A-shr             REC#: 0                    FNUM: 100
>   LOCKS: none
>
>I could not find any info on the use of the word "system" in the
>documentation. A quick check indicated that it seemed to be present
>whenever the file in question was a circular file.  What about other file
>types?  And more important, why can we not get a job/session number for
>this user?
>
>
>2.)
>FILE: ACCEPTKF.CUSTOMER.CLAIMS
>62 Accessors(O:62,P:62,L:0,W:62,R:62),Share
>#S5881  ANNETTE,CUSTOMER.CLAIMS        P:2,L:0,W:2,R:2      LDEV: 211
> #P535
> ...dead(5)
>
>What does "dead" mean - has the process died?  And what does the number in
>the parentheses mean? I also found the term "dead" on the same line as a
>job/session in another instance - but the job/session was still "alive".
>

ATOM RSS1 RSS2