Unidata 7.1 on RHEL, Pick mode. I have a subroutine that displays parts with
declining sales. I am using a HEADI\NG command for multiple pages. Everything
is fine, except if the user chooses to stop a multi-page listing early by
typing Q to Enter New line to continue... prompt. In that
Is this unibasic doing an execute and the 'report' done using a List command
?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kebbon Irwin
Sent: 24 October 2011 16:13
To: u2-users@listserver.u2ug.org
Subject:
The subroutine does an execute 'Select ', then it processes each record
using a LOOP/READNEXT structure, seleectively printing lines that meet my
criteria - so no LIST is executed. It would definitely seem that HEADING is
the culprit. Any UDT.OPTIONS that migth be influencing the
I have gotten around this lack of control in BASIC by EXECUTEing a program that
does the display. If the user gets to the end of the listing or they quit out
control comes back to the main program in any case. Not very elegant but I
don't think there is a way to trap when a user Quits out.
Does anyone have solid experience with this product yet? I am particularly
interested in the license costs for a Unidata environment and some sense of
what development efforts are required and the quality of the results,
especially when compared with Cognos or MITS or the others in the
Kebbon:
I've converted our application from D3 to UniData. There were a number
of issues with the Heading statement and, if I remember correctly,
wouldn't allow me to do what you're trying. Fortunately, we already had
a scrolling program to pass output into so this didn't cause problems.
UV 10.2.10 on Windows is behaving differently from what I recall.
Are my expectations out of line?
Suppose Session A holds a readu lock; and Session B attempts a WRITE to
same record withOUT!!! 1st explicitly getting the readu lock.
Session B waits for Session A to release the lock before
I don't know about UV but in UD, LIST.QUEUE shows waiters.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson
Sent: Monday, October 24, 2011 5:12 PM
To: U2 Users List
Subject: [U2] [UV] LIST.READU
The cost is a fraction of Cognos and DataVu provides more development
functionality. You also don't have the cost of adding an SQL Server database
and work to copy from UniData to the SQL Server that you would normally do with
a Cognos environment. There is a development license and web
I would think that because you are not trying to obtain the lock in a
WRITE statement, it would not be classified as a waiter. True, it's
waiting because of the lock but by not trying to obtain the lock, it's
only waiting for the blockage to clear. If it were to be classified as
a waiter then I
Yeah right, if you can get it to connect.
On 24/10/2011 22:20, David Jordan wrote:
The cost is a fraction of Cognos and DataVu provides more development
functionality. You also don't have the cost of adding an SQL Server database
and work to copy from UniData to the SQL Server that you would
Now why would anybody want to use a WRITE without a READU?
I can possibly understand that somebody would want to do it with a
WRITEV (i.e writing a flag on a record) but WRITE?
And WRITE totally ignoring locking would be outright stupid.
On 24/10/2011 22:28, Woodward, Bob wrote:
I would think
The EVERY option on the LIST.READU shows the READ WAITERS.
I remember from when I was digging into the universe performance counters that
I enquired about this. The feedback I got was that there is nothing in UV that
shows the WRITE WATIERS your test is creating.
-Original Message-
Oh I agree! I was just thinking round-robin that if we're going to talk
about adding a LOCKED clause to the WRITE statement, matching the
structure of READU, then we ought to have a WRITEU, too. Didn't say I
liked the idea
-Original Message-
From:
That little company called CSC does/did not use readu's - they put login id in
field 1 and used that for a 'locking' situation.
From: Woodward, Bob bob_woodw...@k2sports.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Monday, October 24, 2011 7:06 PM
For the record, UV Basic's WRITE command does allow a LOCKED clause.
Which, of course, only applies in the ugly case where the lock was not
already held.
That doesn't imply that the legacy pre-UniVerse code actually has WRITE
LOCKED clauses.
On 10/24/2011 4:28 PM, Woodward, Bob wrote:
I
Mecki,
Point taken, but I didn't say anything about WANTing to do it that way.
This is existing software I'm trying to what's important to fix first.
Because there is a sort of implicit behind-the-scenes wait-for-then-lock
that happens on any WRITE to a record that is not explicitly (i.e.,
Maybe UD is where I am remembering this from.
On 10/24/2011 4:19 PM, Dave Davis wrote:
I don't know about UV but in UD, LIST.QUEUE shows waiters.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles Stevenson
Come to think of it, I think customizing CSC's MHC s/w was the 1st time
I ever fought this fight.
Before that, I had always programmed under a standard that demanded a
READU before a WRITE. And every READU needed a LOCKED clause.
cds
On 10/24/2011 6:57 PM, Paul Wilson wrote:
That little
20 points to anyone who is old enough to remember *why* we couldn't rely on the
Locked clause.
-Original Message-
From: Charles Stevenson stevenson.c...@gmail.com
To: Paul Wilson sfr192...@yahoo.com; U2 Users List
u2-users@listserver.u2ug.org
Sent: Mon, Oct 24, 2011 5:28 pm
Why the 'deadly embrace' issue
From: Wjhonson wjhon...@aol.com
To: u2-users@listserver.u2ug.org; sfr192...@yahoo.com
Sent: Monday, October 24, 2011 8:42 PM
Subject: Re: [U2] [UV] LIST.READU EVERY's waiters when there are writes w/o
explicit readu.
20 points
21 matches
Mail list logo
