Re: [U2] File name of the RECORDS which are listed in LIST.READU output

2005-08-06 Thread Louis Windsor
I do the same but every time you login.

Louis
'
- Original Message - 
From: [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Saturday, August 06, 2005 12:43 AM
Subject: Re: [U2] File name of the RECORDS which are listed in LIST.READU 
output


: In a message dated 8/4/2005 1:56:49 AM Pacific Daylight Time,
: [EMAIL PROTECTED] writes:
:
:
:  2. Write a simple program to build your own register of inode numbers. 
You
:  can do this with a loop based on the following
:
: I take Martin's idea one step further.
: I have a phantom, that every night rebuilds the inode-to-filename xref 
table.
: Then when people run the LIST-READU command, I have it display the 
filename
: instead of the inode.
:   While there *are* occasions when the filename is not in the list, 
because
: it's been created that *day*, they are usually rather rare.
: Will Johnson
: Fast Forward Technologies
: ---
: u2-users mailing list
: u2-users@listserver.u2ug.org
: To unsubscribe please visit http://listserver.u2ug.org/
:
: 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] File name of the RECORDS which are listed in LIST.READU output

2005-08-06 Thread Timothy Snyder
Louis Windsor [EMAIL PROTECTED] wrote on 08/06/2005 04:12:35 AM:

 I do the same but every time you login.

The context of this is a bit blurred due to over-quoting, so I just want 
to make sure I understood correctly.  Does the same mean going through 
all file references in an account and creating an entry in an i-node table 
for each?  And does you mean every user?

If so, you may want to reconsider this strategy.  If you have five people 
logging on simultaneously, each of them is buzzing through the VOC, 
opening each file referenced therein, resolving the device and i-node, 
then constructing and writing a record in a reference table.  Now, let's 
say you have dozens or hundreds of users logging on simultaneously - say, 
at the start of business in the morning.  The overhead of all of the I/O 
(including many expensive OPEN operations) and contention for the lock 
table will be overwhelming.  Not to mention the delay the user encounters 
before being able to start working.

Maybe you could check a time stamp somewhere and bypass the procedure if 
the table has been rebuilt in the last, let's say, 10 minutes.  That will 
still give you fairly current information, assuming somebody has logged in 
recently.  However, if you don't have people logging in constantly 
throughout the day, the table could get rather stale at times.  I'd be 
more inclined to have something that is scheduled on a regular basis.  Or, 
since you apparently have a wrapper around LIST.READU, maybe have that 
wrapper check a time stamp to see how old the i-node look-up table is.  If 
it's not very fresh, ask whether to rebuild it right before doing the 
native LIST.READU command.

If, on the other hand, I misunderstood what you're doing, then please 
ignore the two previous paragraphs.  ;-)


Tim Snyder
Consulting I/T Specialist , U2 Professional Services
North American Lab Services
DB2 Information Management, IBM Software Group
717-545-6403
[EMAIL PROTECTED]
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] File name of the RECORDS which are listed in LIST.READU output

2005-08-06 Thread Louis Windsor
WARNING - LONG STORY

I'm sorry Tim - I told a lie!

The first User to login for the day causes the inode table to be refreshed.

The logic is built in (through subroutines) called by ALL programs that 
update
files.  Should a lock occur the subroutine rerefreshes before notifying 
the User.

The Users are told, with a bottom line message, which record is locked, in 
which file,
by whom, running which program.  Like :-

Trying To Access PRODUCT MASTER FILE  Locked By Fred User In 
Program

No actual file names rather file descriptions are displayed.  Security 
measure!

The subroutine then beeps every second and loops on the lock.  The User 
knows who
to contact and whose butt to kick!  I thought of including a phone number 
but Big
Sister said No!

Only the IT dept can query the full lock status with a function that reports 
on all locks
set including the deadly embraces (UniVerse calls them Waiters) in progress, 
which
Users are involved, which files, which records and how long each User has 
been idle so
we (IT) know who has gone for a cup of coffee or gone home!  We are in five 
States,
and three (?) time zones.

Complications occur when untrained (or impatient) Users kill their telnet 
sessions
and go home leaving the lock in place then IT must use UNLOCK User etc 
etc.

Pardon my lie, I did all this about 15 years ago!  With a few tweaks as
Unixes ( Unixi :) ) changed from time to time with hardware (and software) 
updates etc.

I warned you it was a long story!

Louis

- Original Message - 
From: Timothy Snyder [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Sunday, August 07, 2005 12:19 AM
Subject: Re: [U2] File name of the RECORDS which are listed in LIST.READU 
output


: Louis Windsor [EMAIL PROTECTED] wrote on 08/06/2005 04:12:35 AM:
:
:  I do the same but every time you login.
:
: The context of this is a bit blurred due to over-quoting, so I just want
: to make sure I understood correctly.  Does the same mean going through
: all file references in an account and creating an entry in an i-node table
: for each?  And does you mean every user?
:
: If so, you may want to reconsider this strategy.  If you have five people
: logging on simultaneously, each of them is buzzing through the VOC,

snip 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/