The answer for which I was looking was that the Locked clause was introduced.
It was not original.
-Original Message-
From: Paul Wilson sfr192...@yahoo.com
To: Wjhonson wjhon...@aol.com; u2-users u2-users@listserver.u2ug.org
Sent: Mon, Oct 24, 2011 6:01 pm
Subject: Re: [U2] [UV]
Yes.
Today, deadly embraces can be avoided via LOCKED clauses.
In days of yore, Pick's READU syntax did not allow a LOCKED clause.
BTW, I advocate 2 Programming Standards:
1. If a lock is taken (READU, RECORDLOCKU, FILELOCK, etc.), a
LOCKED clause must be present.
2. A lock must be
Deadly Embraces cannot be avoided by use of a LOCKED clause.
That's not what it means.
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 6:29 am
Subject: Re: [U2] [UV] LIST.READU EVERY's
What if you were writing to an empty file?
Rich
- Original Message -
From: Mecki Foerthmann mec...@gmx.net
To: u2-users@listserver.u2ug.org
Sent: Monday, October 24, 2011 6:30:08 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
Now why would
This is deadly embrace
http://knol.google.com/k/will-johnson/deadly-embrace-on-pick-systems/4hmquk6fx4gu/816#view
The Locked clause does not save us from it. There is no known trivial solution
to the problem, which troubles all multi-table, multi-user database
environments.
Perhaps we
Firstly a file isn't empty any more after the first WRITE.
Secondly we have item and not file locking so if the file is empty or
not is irrelevant.
And last but not least only if you have exclusive use of a work file for
instance you may not have to worry about locks and waiting since you are
Oh yes there is a very easy solution.
If you write a mass update process like in your example you skip the
records with a lock and write them to an error log file.
That way you never end up in a deadly embrace.
After you finished the mass update you can then check for skipped
records and
Your second solution only works if one of the processes is controlled by a
human.
I've encountered deadly embraces between two phantom routines.
Your first solution works, if we have the luxury of skipping locked records.
Some update routines, don't have that luxury as most accountants will let
So you just examine the errors at the end of the process and fix them
automatically.
The accountants will never know ;-)
Where there is a will there is a solution!
On 25/10/2011 19:20, Wjhonson wrote:
Your second solution only works if one of the processes is controlled by a
human.
I've
I know I'll write a phantom to monitor the phantom and write an error log read
by a third phantom!
I'll be at the top of the matrix in six years!
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
Can anyone help explain this behavior or offer a workaround that saves me
from handling it with line counters and printing my own
headings?Cheers,Kebbon
___
Perry's approach is the correct one. If you want to
And... when you prematurely quit from an execution level which *had* been
processing a select list your select list is not thrown away.
Which is annoying.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
You could do it all in one program and run only one phantom, but of
course you can make it a lot more difficult if you want too.
KISS
On 25/10/2011 20:13, Wjhonson wrote:
I know I'll write a phantom to monitor the phantom and write an error log read
by a third phantom!
I'll be at the top of
I'd strongly suggest using the Unibasic SELECT file TO listname
instead of EXECUTE SELECT filename selection criteria
Then you just specify your selection criteria inside your loop.
A few advantages that I've personally experienced, but there are
probably more:
The READNEXT begins immediately
It's always simple when you are programming for yourself.
Once you start programming for contingencies, exceptions, and PDWT (people
doing weird things), it's get complicated quickly.
-Original Message-
From: Mecki Foerthmann mec...@gmx.net
To: u2-users u2-users@listserver.u2ug.org
Dave
The next-to-last one may depend on Unidata vs. Universe. I understand
that Unidata only 'fetches' the key in the READNEXT while I believe
Universe grabs both the key and record, due to the construct of the
database.
I believe that is the case in Unidata. A SELECT returns a list of
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to have to read each record, how else
would it know which records to throw out?
My point is, if one of your selection criteria were in the key, then my
method bypasses the need to read the record if the
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to have to read each record, how else
would it know which records to throw out?
SELECT is definitely faster than EXECUTE SELECT... and I try and use it
first.
Charles Shaffer
Senior Analyst
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
On Tue, Oct 25, 2011 at 5:14 PM, charles_shaf...@ntn-bower.com wrote:
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
Are you saying that when there is an index, the system does not need to
read the record at all? It just gets the SELECT list from the index? Is
this only true in
There are key differences between the two types of selects. The EXECUTE
SELECT... guarantees you access all the records that fit your criteria
at the moment of the execute. The BASIC SELECT processes node by node
of the datafile which allows for the possibility of records being added,
deleted,
True on UV, too.
Compare output of these using EXPLAIN keyword:
LIST FILE WITH indexed_field = soemthing EXPLAIN
LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX
Or forget EXPLAIN, but do it with a large file and notice the speed
differnce.
On 10/25/2011 4:29 PM,
Add a second selection criteria and the benefit of the index is washed
out.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Stevenson
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re:
I think we are bike-shedding this now :)
I seem to recall that if the indexed field is _before_ the non indexed
field, its benefit is not lost. I have not looked close at that in a
long time.
On Tue, Oct 25, 2011 at 5:42 PM, Woodward, Bob
bob_woodw...@k2sports.com wrote:
Add a second selection
Yes yes and no.
If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and do
NOT refer at all to any other fields in the file, then index does NOT read the
record to see if it even actually exists. It just retrieves the list of keys
from the index.
If you specific a
RetrieVe will use an index if it can, regardless of the order of the
selection criteria ( if not select list is already active).
RetrieVe will now do intersections of index reults if 2 indexed
selection criteria are specified.
I'm not sure when or how good it does that.
NO.OPTIMIZE can override
But you are potentially reducing your input set for the 2nd criteria
by a large margin correct?
I've never considered alt key + non-indexed usage to create disk thrash.
When you select on an alternate key index, you are reading the file,
but (in Udt at least) an X_myfile binary file. So you are
That's too bold a rule of thumb for me, Bob.
I will grant you that indexes need to be well thought out.
It also depends on what percent of the entire file you retrieve via the
index.
If it is too large, a filescan via basic select or NO,.INDEX keyword is
quicker.
Bob also made a comment about
On 10/24/2011 4:11 PM, Charles Stevenson wrote:
--- [snip] ---
I have not yet explored what the deadlock daemon does.
Deadlock daemon ignores these WRITEs w/o explicit locking before hand.
I ran these 2 pgms simultaneously so that they both tried to lock or
write the lock that the other held.
When you read the index, you are doing a direct read.
When on your second pass you are reading some other field as part of your
select criteria, you are using the index, which is layed down sequentially, to
access a non-sequential file, causing thrashing.
In other words, in order to determine
I believe that it is incorrect that it will intersect indexes.
I understand that some people think this might be preferable, but I do not
believe this logic has ever been coded in.
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: U2 Users List
I dont' quite follow that.
Are you stating that if there is no explicit READU that both processes will
complete without the deadlock deamon?
But if there is explicit READUs in both processes, that one of them will fail
in 20 minutes?
-Original Message-
From: Charles Stevenson
On 25/10/11 22:22, Steve Romanow wrote:
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
SELECT *is* faster. Because it does far less work!
EXECUTE SELECT needs to read the entire file to create a select list.
SELECT
Consider a sparse file. I have seen where a execute select is faster so I
counter your AlwaysFaster claim. Like the previous poster said, it will
always be fastest to start, but not always first to complete.
On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote:
On 25/10/11
English is my 1st language, but that doesn't mean I'm good at it.
Let me try again.
1. If either (or both) of these have WRITEs without explicit readus
ahead of time:
-- the deadlock daemon seems to recognize the deadlock.
-- If said WRITE command cannot gain a lock within 20 minutes it will
I reread my post and meant no disrespect Wols. I shouldnt post replies
without considering twice.
On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote:
On 25/10/11 22:22, Steve Romanow wrote:
I don't know if I agree that SELECT is faster. If you are using
indexed fields,
Thanks for that longer explanation, but you can't avoid deadlocks with LOCKED
clauses.
Maybe what you meant was something like You can try to think of some strategy
to deal with them when they occur.
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: U2 Users
Properly programmed locked clauses are exactly the means by which one
always avoids deadlocks.
I can think of no example where that would not work, including your
earlier example.
As an example, I have added LOCKED clauses to the 2 pgms I listed below
W12 W21.
If you run the original
While Will's articledoes give a good, clear example of a deadly embrace,
and remediating faulty code is not trivial, the solution is conceptually
trivial and it is exactly the LOCKED clause that saves us.
If you write new code, deadlocks are easy to prevent.
Testing is non-trivial. It
Your example fails.
You are deliberately returning the user back to the beginning of a program deep
in progress, or you are assuming we know in advance what locks might be set.
Both of these are bad devices and assumptions.
Are you really going to throw away your order entry clerk's last five
It is not possible to know in advance all the locks you may wish to set.
That's the problem.
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 5:22 pm
Subject: Re: [U2] [UV] LIST.READU EVERY's
41 matches
Mail list logo
