RE: Problem with Daily Link Maintenance in combo with lyrcirc-yt dcirc activity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Wed, 13 Dec 2000 11:17:19 -0000
- From: "Turner, Anne" <A.Turner@xxxxxxxxxx>
- Subject: RE: Problem with Daily Link Maintenance in combo with lyrcirc-yt dcirc activity
Mieko - please could you explain a bit more about these "gates"?
Thanks,
Anne Turner
Sheffield Hallam University (UK)
a.turner@xxxxxxxxxx
-----Original Message-----
From: Mieko Yamaguchi [mailto:iss053@xxxxxxxxxx]
Sent: 12 December 2000 19:40
To: innopac
Subject: Re: Problem with Daily Link Maintenance in combo with
lyrcirc-ytdcirc activity
We had a similar experience at the beginning of August (start of our
academic/fiscal year). Before we changed our server YTDCIRC-LYRCIRC
"Rapid" Updates took more than 24 hours (running on 3 or 4 review files
simultaneously) but with a new server I was hoping it would not take as
long. And while I was doing it why not Daily Link Maintenance as well?
Well, it wasn't just slow - everything stopped! Eventually I had to
kill Daily Link Maintenance and also Rapid Updates for YTDCIRC-LYRCIRC
maintenance (having made notes of how far in each file records had been
updated).
I contacted the Help Desk and found that Rapid Updates and Link
Maintenance were all sending information through the transaction
processing program (control) and that when the transaction file became
full, control caused the programs to "wait" to send any further data.
So the programs were waiting for resources to free up and in the mean
time stopped (or at least appeared to stop).
The solution suggested was to place "gates" on the Rapid Update and Link
Maintenance programs so that data is sent in a more orderly fashion.
These programs try to dump their entire load of transactions to the
transaction file at once, causing a large "traffic jam". The way to
avoid this traffic jam is to set up these "gates" on these programs to
act as "traffic signals". These gates will slow down the programs a
little but we have not noticed this to be a problem so far.
Fortunately we don't have to run Link Maintenance that regularly, so I
will definitely not run it when I next run YTDCIRC-LRYCIRC.
On Tue, 12 Dec 2000, Jim Gingery wrote:
> This is the first year we have had Daily Link Maintenance, and while it
> works OK for the rest of the year, it has been a real problem at the end of
> the year when ytdcirc-lyrcirc activity takes place.
>
> Daily Link Maintenance is notoriously slow (and it's not the server that's
> the problem, it's the software), and we have found it very problematic to
> combine allowing Daily Link to complete itself while at the same time
> needing to move all of the lyrcirc-ytdcirc item information one-by-one
> through big Rapid Updates. Every one of these rapid updates writes into the
> Daily Link Maintenance file, creating a Catch-22. If we choose to do Rapid
> Updates, the Daily Link Maintenance grows too rapidly and becomes unwieldy.
> If we choose do Daily Link Maintenance, we neglect the Rapid Updates that
> we must do..
>
> I can't emphasize enough how much we would like III to be able to allow us
> to, at a designated time, REPLACE all of the lyrcirc data with ytdcirc
> data... not having to go through the laborious routine of creating all of
> these lists and doing all of these rapid updates
>
> This is absolutely necessary, given the problem with Daily Link Maintenance
> and the need to do literally a few million lyrcirc-ytdcirc transactions.
>
> Anyone else frustrated out there ?
Mieko
-----
Mieko Yamaguchi m.yamaguchi@xxxxxxxxxx
Technical Services Manager/System Coordinator +44 (0)1248 382970
Main Library, University of Wales Bangor, UK +44 (0)1248 382979 (Fax)
--
This message was distributed through the Innovative Users Group INNOPAC list.
Private replies: Mieko Yamaguchi <iss053@xxxxxxxxxx>
Public replies: INNOPAC@xxxxxxxxxx
Archives: http://innopacusers.org/list/archives/
--
This message was distributed through the Innovative Users Group INNOPAC list.
Private replies: "Turner, Anne" <A.Turner@xxxxxxxxxx>
Public replies: INNOPAC@xxxxxxxxxx
Archives: http://innopacusers.org/list/archives/