Uniobjects and Record Locking

[Bill Haskett]

I'm using DesignBais and have run into an unusual problem.  When I
display some data on a web form the dbms is contacted through UO and the
returned data is displayed.  When I click on the [Save] button the same
UO connection is used to contact the dbms and run whatever program is
required to update the record.

In the called update program, the record is read and locked.  If it's
already locked the program terminates and a message is returned
informing the user the record is locked (try again).  If it's not locked
the record is updated and, of course, the program terminates in the same
manner.

Problem: if I edit the record via UniData's AE editor (LIST.READU shows
a record lock) and try to update the record via the DesignBais form, the
LOCKED clause is taken.  This is good.  However, after I release the
record via the AE editor (LIST.READU now shows nothing locked), then
click on the [Save] button, the LOCKED clause is still taken, even
though no record is locked!  If I kill the UO connection, DesignBais
will make another UO connection and all works fine.

So, it appears a UO connection won't release a lock under whatever
circumstances I've happened to stumble upon.  Any ideas what causes this
and how to "work-around" the problem?

Thanks,

Bill Haskett
Advantos Systems, Inc.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Doug Averch-2]

Bill:

Your problem might have to do with DesignBais not connecting with the same
connection as the first read.  I don't know if there is a way to restrict
DesignBais to use the same connection.

Regards,
Doug
www.u2logic.com
"The other Web Developer company"

On Sat, Jan 7, 2012 at 4:16 PM, Bill Haskett <wphaskett@...> wrote:

> I'm using DesignBais and have run into an unusual problem.  When I display
> some data on a web form the dbms is contacted through UO and the returned
> data is displayed.  When I click on the [Save] button the same UO
> connection is used to contact the dbms and run whatever program is required
> to update the record.
>
> In the called update program, the record is read and locked.  If it's
> already locked the program terminates and a message is returned informing
> the user the record is locked (try again).  If it's not locked the record
> is updated and, of course, the program terminates in the same manner.
>
> Problem: if I edit the record via UniData's AE editor (LIST.READU shows a
> record lock) and try to update the record via the DesignBais form, the
> LOCKED clause is taken.  This is good.  However, after I release the record
> via the AE editor (LIST.READU now shows nothing locked), then click on the
> [Save] button, the LOCKED clause is still taken, even though no record is
> locked!  If I kill the UO connection, DesignBais will make another UO
> connection and all works fine.
>
> So, it appears a UO connection won't release a lock under whatever
> circumstances I've happened to stumble upon.  Any ideas what causes this
> and how to "work-around" the problem?
>
> Thanks,
>
> Bill Haskett
> Advantos Systems, Inc.
> ______________________________**_________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
>

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Bill Haskett]

Doug:

I'm not sure I understand.  I know DB "does" use the same connection for
both reads.  It's only when I "change" the connection that it works
properly.

Thanks,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* daverch@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/7/2012 6:18 PM
*Subject:* Re: [U2] Uniobjects and Record Locking

> Bill:
>
> Your problem might have to do with DesignBais not connecting with the same
> connection as the first read.  I don't know if there is a way to restrict
> DesignBais to use the same connection.
>
> Regards,
> Doug
> www.u2logic.com
> "The other Web Developer company"
>
> On Sat, Jan 7, 2012 at 4:16 PM, Bill Haskett<wphaskett@...>  wrote:
>
>> I'm using DesignBais and have run into an unusual problem.  When I display
>> some data on a web form the dbms is contacted through UO and the returned
>> data is displayed.  When I click on the [Save] button the same UO
>> connection is used to contact the dbms and run whatever program is required
>> to update the record.
>>
>> In the called update program, the record is read and locked.  If it's
>> already locked the program terminates and a message is returned informing
>> the user the record is locked (try again).  If it's not locked the record
>> is updated and, of course, the program terminates in the same manner.
>>
>> Problem: if I edit the record via UniData's AE editor (LIST.READU shows a
>> record lock) and try to update the record via the DesignBais form, the
>> LOCKED clause is taken.  This is good.  However, after I release the record
>> via the AE editor (LIST.READU now shows nothing locked), then click on the
>> [Save] button, the LOCKED clause is still taken, even though no record is
>> locked!  If I kill the UO connection, DesignBais will make another UO
>> connection and all works fine.
>>
>> So, it appears a UO connection won't release a lock under whatever
>> circumstances I've happened to stumble upon.  Any ideas what causes this
>> and how to "work-around" the problem?
>>
>> Thanks,
>>
>> Bill Haskett
>> Advantos Systems, Inc.
>> ______________________________**_________________
>> U2-Users mailing list
>> U2-Users@...
>> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users>
>>
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David Jordan]

It is possible that design base is running a separate locking mechanism that it is caching.   The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login.  This is different to a telnet connection with one user per login.   If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem.  You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe.

What you are doing is pessimistic locking.   With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images.   If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment.

Regards
David Jordan

-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: Sunday, 8 January 2012 10:16 AM
To: U2 Mail List
Cc: DesignBais Support
Subject: [U2] Uniobjects and Record Locking

I'm using DesignBais and have run into an unusual problem.  When I display some data on a web form the dbms is contacted through UO and the returned data is displayed.  When I click on the [Save] button the same UO connection is used to contact the dbms and run whatever program is required to update the record.

In the called update program, the record is read and locked.  If it's already locked the program terminates and a message is returned informing the user the record is locked (try again).  If it's not locked the record is updated and, of course, the program terminates in the same manner.

Problem: if I edit the record via UniData's AE editor (LIST.READU shows a record lock) and try to update the record via the DesignBais form, the LOCKED clause is taken.  This is good.  However, after I release the record via the AE editor (LIST.READU now shows nothing locked), then click on the [Save] button, the LOCKED clause is still taken, even though no record is locked!  If I kill the UO connection, DesignBais will make another UO connection and all works fine.

So, it appears a UO connection won't release a lock under whatever circumstances I've happened to stumble upon.  Any ideas what causes this and how to "work-around" the problem?

Thanks,

Bill Haskett
Advantos Systems, Inc.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[John Jenkins]

If DesignBais is using it's own connection pooling or cacheing mechanism
then it's possible the update request is not being made on the same
UniObjects connection on which the lock was created. The result is exactly
the same as you would expect from two different TELNET sessions - one locks
the other. If you force a release of the lock as root/administrator on the
server and the update proceeds then you have the cause and need to change
either DesignBais or the methodology the application uses. If you release
the lock and the update still can't proceed then DesignBais is probably
using an internal locking mechanism that has some issues.

As we all know, you can only update or release a locked record on the same
session which holds the lock.

Also a pointer - if you are using UniObjects with U2 Connection Pooling,
then the same can apply the moment you have two server processes on the same
connection pool. Each request made to a connection pool could be serviced by
ANY process assigned to that pool - not necessarily the last one you
happened to get assigned to your last request. (After all - that's the whole
point of Connection Pooling - POOLING being the operative word. This is
quite different to UO without Connection Pooling where the client to server
link is one-to-one. With Connection Pooling it is many-to-many.

The locking mechanism DesignBais is using needs to be re-thought if either
of these applies. You should be using optimistic locking for scalability in
any case,

Regards

JayJay


-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: 07 January 2012 23:16
To: U2 Mail List
Cc: DesignBais Support
Subject: [U2] Uniobjects and Record Locking

I'm using DesignBais and have run into an unusual problem.  When I display
some data on a web form the dbms is contacted through UO and the returned
data is displayed.  When I click on the [Save] button the same UO connection
is used to contact the dbms and run whatever program is required to update
the record.

In the called update program, the record is read and locked.  If it's
already locked the program terminates and a message is returned informing
the user the record is locked (try again).  If it's not locked the record is
updated and, of course, the program terminates in the same manner.

Problem: if I edit the record via UniData's AE editor (LIST.READU shows a
record lock) and try to update the record via the DesignBais form, the
LOCKED clause is taken.  This is good.  However, after I release the record
via the AE editor (LIST.READU now shows nothing locked), then click on the
[Save] button, the LOCKED clause is still taken, even though no record is
locked!  If I kill the UO connection, DesignBais will make another UO
connection and all works fine.

So, it appears a UO connection won't release a lock under whatever
circumstances I've happened to stumble upon.  Any ideas what causes this and
how to "work-around" the problem?

Thanks,

Bill Haskett
Advantos Systems, Inc.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users


_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Bill Haskett]

David:

Thanks for the input.  This has nothing to do with DB, as the message
that displays is generated by the update program due to the LOCKED
clause being taken, even though there is no record locked.

We do a quasi-optimistic locking and only lock records during those few
milliseconds where updating occurs. A record is "NEVER" locked until an
update occurs, and since locks release when a program terminates (even a
subroutine returns) we shouldn't be having such problems ( i.e. a record
is never locked then left alone).

This is why I'm thinking it has something to do with Uniobjects.

Thanks again,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* David@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 1:33 AM
*Subject:* Re: [U2] Uniobjects and Record Locking

> It is possible that design base is running a separate locking mechanism that it is caching.   The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login.  This is different to a telnet connection with one user per login.   If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem.  You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe.
>
> What you are doing is pessimistic locking.   With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images.   If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment.
>
> Regards
> David Jordan
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
> Sent: Sunday, 8 January 2012 10:16 AM
> To: U2 Mail List
> Cc: DesignBais Support
> Subject: [U2] Uniobjects and Record Locking
>
> I'm using DesignBais and have run into an unusual problem.  When I display some data on a web form the dbms is contacted through UO and the returned data is displayed.  When I click on the [Save] button the same UO connection is used to contact the dbms and run whatever program is required to update the record.
>
> In the called update program, the record is read and locked.  If it's already locked the program terminates and a message is returned informing the user the record is locked (try again).  If it's not locked the record is updated and, of course, the program terminates in the same manner.
>
> Problem: if I edit the record via UniData's AE editor (LIST.READU shows a record lock) and try to update the record via the DesignBais form, the LOCKED clause is taken.  This is good.  However, after I release the record via the AE editor (LIST.READU now shows nothing locked), then click on the [Save] button, the LOCKED clause is still taken, even though no record is locked!  If I kill the UO connection, DesignBais will make another UO connection and all works fine.
>
> So, it appears a UO connection won't release a lock under whatever circumstances I've happened to stumble upon.  Any ideas what causes this and how to "work-around" the problem?
>
> Thanks,
>
> Bill Haskett
> Advantos Systems, Inc.
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Bill Haskett]

John:

As a note, we've been programming in web paradigms for many years, and
we mostly understand the difference between non-persistent web
connections and persistent telnet connections.

None of our activities does anything except gather data and submit to UO
for almost instantaneous results, whereupon the results is returned to
the web.  These are all momentary connections and no LOCKING occurs
except within the context of a momentary update.  So, the user calls the
web server, a UO connection is either reused or created to connect to
the dbms, a subroutine is run and ends (which, of course, should release
all locks within the subroutine (unless doing something like a WRITEU
which we never do - we're old-school in that regard), the the web call
is closed and data returned by the UO connection is returned to the user
in another web page, and the web connection is closed.

I think what's important to note is a "LIST.READU  ALL" shows the lock
when AE has the record edited and the BASIC LOCKED clause is taken on a
momentary UO connection.  When AE exits the record "LIST.READU  ALL" no
longer shows any record locks but the BASIC LOCKED clause on a
subsequent UO connection is still taken as though the record is locked
only if the UO connection where the lock occured is reused.  If a new UO
connection is used (due to timeouts or manually killing the original UO
connection) the BASIC LOCKED clause is __NOT__ taken.

Thanks,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* u2guru@...
*To:* 'U2 Users List' <u2-users@...>
*Date:* 1/8/2012 8:29 AM
*Subject:* Re: [U2] Uniobjects and Record Locking

> If DesignBais is using it's own connection pooling or cacheing mechanism
> then it's possible the update request is not being made on the same
> UniObjects connection on which the lock was created. The result is exactly
> the same as you would expect from two different TELNET sessions - one locks
> the other. If you force a release of the lock as root/administrator on the
> server and the update proceeds then you have the cause and need to change
> either DesignBais or the methodology the application uses. If you release
> the lock and the update still can't proceed then DesignBais is probably
> using an internal locking mechanism that has some issues.
>
> As we all know, you can only update or release a locked record on the same
> session which holds the lock.
>
> Also a pointer - if you are using UniObjects with U2 Connection Pooling,
> then the same can apply the moment you have two server processes on the same
> connection pool. Each request made to a connection pool could be serviced by
> ANY process assigned to that pool - not necessarily the last one you
> happened to get assigned to your last request. (After all - that's the whole
> point of Connection Pooling - POOLING being the operative word. This is
> quite different to UO without Connection Pooling where the client to server
> link is one-to-one. With Connection Pooling it is many-to-many.
>
> The locking mechanism DesignBais is using needs to be re-thought if either
> of these applies. You should be using optimistic locking for scalability in
> any case,
>
> Regards
>
> JayJay
>
>
> -----Original Message-----
> From: u2-users-bounces@...
> [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
> Sent: 07 January 2012 23:16
> To: U2 Mail List
> Cc: DesignBais Support
> Subject: [U2] Uniobjects and Record Locking
>
> I'm using DesignBais and have run into an unusual problem.  When I display
> some data on a web form the dbms is contacted through UO and the returned
> data is displayed.  When I click on the [Save] button the same UO connection
> is used to contact the dbms and run whatever program is required to update
> the record.
>
> In the called update program, the record is read and locked.  If it's
> already locked the program terminates and a message is returned informing
> the user the record is locked (try again).  If it's not locked the record is
> updated and, of course, the program terminates in the same manner.
>
> Problem: if I edit the record via UniData's AE editor (LIST.READU shows a
> record lock) and try to update the record via the DesignBais form, the
> LOCKED clause is taken.  This is good.  However, after I release the record
> via the AE editor (LIST.READU now shows nothing locked), then click on the
> [Save] button, the LOCKED clause is still taken, even though no record is
> locked!  If I kill the UO connection, DesignBais will make another UO
> connection and all works fine.
>
> So, it appears a UO connection won't release a lock under whatever
> circumstances I've happened to stumble upon.  Any ideas what causes this and
> how to "work-around" the problem?
>
> Thanks,
>
> Bill Haskett
> Advantos Systems, Inc.
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>
>
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David Jordan]

Hi Bill
Where is the update program.  If it is a UniData subroutine, then UniObjects is not in the process.  As far as I know UniObjects has no locking process of its own, it uses Unidatas lock table.   I have not experienced this problem, this issue like this sounds like a program bug.

I would step through the logic carefully, as you may be locking the record twice in 2 different processes as part of the update.  Is DB doing an update through its application at the same time you are doing an update.   Check the subroutines call logic.  Check the security access, does the user have write access.

I suspect a process is aborting somewhere that leaves a record locked which is only cleared when the UniObject session is cleared.  Have you done a "list.readu all" after a record locked message has occurred, as you might identify the lock has occurred then.

PS did you do LIST.READU or LIST.READU ALL

Regards

David Jordan




-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: Monday, 9 January 2012 6:34 AM
To: U2 Users List
Subject: Re: [U2] Uniobjects and Record Locking

David:

Thanks for the input.  This has nothing to do with DB, as the message that displays is generated by the update program due to the LOCKED clause being taken, even though there is no record locked.

We do a quasi-optimistic locking and only lock records during those few milliseconds where updating occurs. A record is "NEVER" locked until an update occurs, and since locks release when a program terminates (even a subroutine returns) we shouldn't be having such problems ( i.e. a record is never locked then left alone).

This is why I'm thinking it has something to do with Uniobjects.

Thanks again,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* David@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 1:33 AM
*Subject:* Re: [U2] Uniobjects and Record Locking

> It is possible that design base is running a separate locking mechanism that it is caching.   The Uniobjects connection involves pooling where multiple user accesses use one UniVerse Login.  This is different to a telnet connection with one user per login.   If DesignBase cannot identify the process that updates as being the same as the one that locks the record then you could have a problem.  You cannot identify who locked the record in a pooling environment as 10 people would have the same user ID, hence it has to be managed by designbase rather than universe.
>
> What you are doing is pessimistic locking.   With a web based environment and pooling, you should be thinking optimistic locking where you only do locking at the time of update and compare before and after images.   If a user locks a record over an internet connection and then loses a connection, then that record can remain locked until an administrator releases it manually, this is why pessimistic locking is avoided in this environment.
>
> Regards
> David Jordan
>
> -----Original Message-----
> From: u2-users-bounces@...
> [mailto:u2-users-bounces@...] On Behalf Of Bill
> Haskett
> Sent: Sunday, 8 January 2012 10:16 AM
> To: U2 Mail List
> Cc: DesignBais Support
> Subject: [U2] Uniobjects and Record Locking
>
> I'm using DesignBais and have run into an unusual problem.  When I display some data on a web form the dbms is contacted through UO and the returned data is displayed.  When I click on the [Save] button the same UO connection is used to contact the dbms and run whatever program is required to update the record.
>
> In the called update program, the record is read and locked.  If it's already locked the program terminates and a message is returned informing the user the record is locked (try again).  If it's not locked the record is updated and, of course, the program terminates in the same manner.
>
> Problem: if I edit the record via UniData's AE editor (LIST.READU shows a record lock) and try to update the record via the DesignBais form, the LOCKED clause is taken.  This is good.  However, after I release the record via the AE editor (LIST.READU now shows nothing locked), then click on the [Save] button, the LOCKED clause is still taken, even though no record is locked!  If I kill the UO connection, DesignBais will make another UO connection and all works fine.
>
> So, it appears a UO connection won't release a lock under whatever circumstances I've happened to stumble upon.  Any ideas what causes this and how to "work-around" the problem?
>
> Thanks,
>
> Bill Haskett
> Advantos Systems, Inc.
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David Jordan]

Hi Bill

You cannot assume the exit of a subroutine clears locks.   The way DB works, I suspect that DB has a worker program that calls routines.  If that worker program does not stop then locks may not be cleared.   When you restart UO you are only then clearing a persistent lock.  Also check that the locked message is from the routine you think it is.  I don't know your code, I am just passing issues I have seen in the past.  Do you have triggers doing an update.

It sounds like a lock from a previous step has not cleared.   Put a RELEASE statement in the routine before it exits and see if that helps.

Regards
David Jordan


_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Wally Terhune-2]

UniData record locks are tied to a file variable. So if a file is opened in named common, a lock could persist after a subroutine exits. Of course, it would show up in LIST.READU...

The behavior Bill describes doesn't make sense to me. Would love to see a small test case demonstrating what he describes.

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: [phone]
Email: WTerhune@...
Web: www.rocketsoftware.com/u2




-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: Sunday, January 08, 2012 12:48 PM
To: U2 Users List
Subject: Re: [U2] Uniobjects and Record Locking

John:

As a note, we've been programming in web paradigms for many years, and we mostly understand the difference between non-persistent web connections and persistent telnet connections.

None of our activities does anything except gather data and submit to UO for almost instantaneous results, whereupon the results is returned to the web.  These are all momentary connections and no LOCKING occurs except within the context of a momentary update.  So, the user calls the web server, a UO connection is either reused or created to connect to the dbms, a subroutine is run and ends (which, of course, should release all locks within the subroutine (unless doing something like a WRITEU which we never do - we're old-school in that regard), the the web call is closed and data returned by the UO connection is returned to the user in another web page, and the web connection is closed.

I think what's important to note is a "LIST.READU  ALL" shows the lock when AE has the record edited and the BASIC LOCKED clause is taken on a momentary UO connection.  When AE exits the record "LIST.READU  ALL" no longer shows any record locks but the BASIC LOCKED clause on a subsequent UO connection is still taken as though the record is locked only if the UO connection where the lock occured is reused.  If a new UO connection is used (due to timeouts or manually killing the original UO
connection) the BASIC LOCKED clause is __NOT__ taken.

Thanks,

Bill
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Bill Haskett]

Wally:

I can even re-create this (amazing isn't it?).  :-)   I'm here all day
tomorrow after 10:30am PST.  I can call you, if you'd like.

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* WTerhune@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 1:06 PM
*Subject:* Re: [U2] Uniobjects and Record Locking

> UniData record locks are tied to a file variable. So if a file is opened in named common, a lock could persist after a subroutine exits. Of course, it would show up in LIST.READU...
>
> The behavior Bill describes doesn't make sense to me. Would love to see a small test case demonstrating what he describes.
>
> Wally Terhune
> U2 Support Architect
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> Tel: [phone]
> Email: WTerhune@...
> Web: www.rocketsoftware.com/u2
>
>
>
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
> Sent: Sunday, January 08, 2012 12:48 PM
> To: U2 Users List
> Subject: Re: [U2] Uniobjects and Record Locking
>
> John:
>
> As a note, we've been programming in web paradigms for many years, and we mostly understand the difference between non-persistent web connections and persistent telnet connections.
>
> None of our activities does anything except gather data and submit to UO for almost instantaneous results, whereupon the results is returned to the web.  These are all momentary connections and no LOCKING occurs except within the context of a momentary update.  So, the user calls the web server, a UO connection is either reused or created to connect to the dbms, a subroutine is run and ends (which, of course, should release all locks within the subroutine (unless doing something like a WRITEU which we never do - we're old-school in that regard), the the web call is closed and data returned by the UO connection is returned to the user in another web page, and the web connection is closed.
>
> I think what's important to note is a "LIST.READU  ALL" shows the lock when AE has the record edited and the BASIC LOCKED clause is taken on a momentary UO connection.  When AE exits the record "LIST.READU  ALL" no longer shows any record locks but the BASIC LOCKED clause on a subsequent UO connection is still taken as though the record is locked only if the UO connection where the lock occured is reused.  If a new UO connection is used (due to timeouts or manually killing the original UO
> connection) the BASIC LOCKED clause is __NOT__ taken.
>
> Thanks,
>
> Bill
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Wally Terhune-2]

Just open a support case and email the test case...
thanks

Wally Terhune
U2 Support Architect
Rocket Software
4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
Tel: [phone]
Email: WTerhune@...
Web: www.rocketsoftware.com/u2




-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: Sunday, January 08, 2012 7:46 PM
To: U2 Users List
Subject: Re: [U2] Uniobjects and Record Locking

Wally:

I can even re-create this (amazing isn't it?).  :-)   I'm here all day
tomorrow after 10:30am PST.  I can call you, if you'd like.

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* WTerhune@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 1:06 PM
*Subject:* Re: [U2] Uniobjects and Record Locking

> UniData record locks are tied to a file variable. So if a file is opened in named common, a lock could persist after a subroutine exits. Of course, it would show up in LIST.READU...
>
> The behavior Bill describes doesn't make sense to me. Would love to see a small test case demonstrating what he describes.
>
> Wally Terhune
> U2 Support Architect
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> Tel: [phone]
> Email: WTerhune@...
> Web: www.rocketsoftware.com/u2
>
>
>
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
> Sent: Sunday, January 08, 2012 12:48 PM
> To: U2 Users List
> Subject: Re: [U2] Uniobjects and Record Locking
>
> John:
>
> As a note, we've been programming in web paradigms for many years, and we mostly understand the difference between non-persistent web connections and persistent telnet connections.
>
> None of our activities does anything except gather data and submit to UO for almost instantaneous results, whereupon the results is returned to the web.  These are all momentary connections and no LOCKING occurs except within the context of a momentary update.  So, the user calls the web server, a UO connection is either reused or created to connect to the dbms, a subroutine is run and ends (which, of course, should release all locks within the subroutine (unless doing something like a WRITEU which we never do - we're old-school in that regard), the the web call is closed and data returned by the UO connection is returned to the user in another web page, and the web connection is closed.
>
> I think what's important to note is a "LIST.READU  ALL" shows the lock when AE has the record edited and the BASIC LOCKED clause is taken on a momentary UO connection.  When AE exits the record "LIST.READU  ALL" no longer shows any record locks but the BASIC LOCKED clause on a subsequent UO connection is still taken as though the record is locked only if the UO connection where the lock occured is reused.  If a new UO connection is used (due to timeouts or manually killing the original UO
> connection) the BASIC LOCKED clause is __NOT__ taken.
>
> Thanks,
>
> Bill
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Bill Haskett]

Done!  :-)

Thanks,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* WTerhune@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 7:17 PM
*Subject:* Re: [U2] Uniobjects and Record Locking

> Just open a support case and email the test case...
> thanks
>
> Wally Terhune
> U2 Support Architect
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> Tel: [phone]
> Email: WTerhune@...
> Web: www.rocketsoftware.com/u2
>
>
>
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
> Sent: Sunday, January 08, 2012 7:46 PM
> To: U2 Users List
> Subject: Re: [U2] Uniobjects and Record Locking
>
> Wally:
>
> I can even re-create this (amazing isn't it?).  :-)   I'm here all day
> tomorrow after 10:30am PST.  I can call you, if you'd like.
>
> Bill
>
> ------------------------------------------------------------------------
> ----- Original Message -----
> *From:* WTerhune@...
> *To:* U2 Users List<u2-users@...>
> *Date:* 1/8/2012 1:06 PM
> *Subject:* Re: [U2] Uniobjects and Record Locking
>> UniData record locks are tied to a file variable. So if a file is opened in named common, a lock could persist after a subroutine exits. Of course, it would show up in LIST.READU...
>>
>> The behavior Bill describes doesn't make sense to me. Would love to see a small test case demonstrating what he describes.
>>
>> Wally Terhune
>> U2 Support Architect
>> Rocket Software
>> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
>> Tel: [phone]
>> Email: WTerhune@...
>> Web: www.rocketsoftware.com/u2
>>
>>
>>
>>
>> -----Original Message-----
>> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
>> Sent: Sunday, January 08, 2012 12:48 PM
>> To: U2 Users List
>> Subject: Re: [U2] Uniobjects and Record Locking
>>
>> John:
>>
>> As a note, we've been programming in web paradigms for many years, and we mostly understand the difference between non-persistent web connections and persistent telnet connections.
>>
>> None of our activities does anything except gather data and submit to UO for almost instantaneous results, whereupon the results is returned to the web.  These are all momentary connections and no LOCKING occurs except within the context of a momentary update.  So, the user calls the web server, a UO connection is either reused or created to connect to the dbms, a subroutine is run and ends (which, of course, should release all locks within the subroutine (unless doing something like a WRITEU which we never do - we're old-school in that regard), the the web call is closed and data returned by the UO connection is returned to the user in another web page, and the web connection is closed.
>>
>> I think what's important to note is a "LIST.READU  ALL" shows the lock when AE has the record edited and the BASIC LOCKED clause is taken on a momentary UO connection.  When AE exits the record "LIST.READU  ALL" no longer shows any record locks but the BASIC LOCKED clause on a subsequent UO connection is still taken as though the record is locked only if the UO connection where the lock occured is reused.  If a new UO connection is used (due to timeouts or manually killing the original UO
>> connection) the BASIC LOCKED clause is __NOT__ taken.
>>
>> Thanks,
>>
>> Bill

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David Wolverton]

Post back the cause and fix if you can - I know I'd be interested!

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
Sent: Monday, January 09, 2012 4:11 PM
To: U2 Users List
Subject: Re: [U2] Uniobjects and Record Locking

Done!  :-)

Thanks,

Bill

------------------------------------------------------------------------
----- Original Message -----
*From:* WTerhune@...
*To:* U2 Users List <u2-users@...>
*Date:* 1/8/2012 7:17 PM
*Subject:* Re: [U2] Uniobjects and Record Locking

> Just open a support case and email the test case...
> thanks
>
> Wally Terhune
> U2 Support Architect
> Rocket Software
> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
> Tel: [phone]
> Email: WTerhune@...
> Web: www.rocketsoftware.com/u2
>
>
>
>
> -----Original Message-----
> From: u2-users-bounces@...

[mailto:u2-users-bounces@...] On Behalf Of Bill Haskett

> Sent: Sunday, January 08, 2012 7:46 PM
> To: U2 Users List
> Subject: Re: [U2] Uniobjects and Record Locking
>
> Wally:
>
> I can even re-create this (amazing isn't it?).  :-)   I'm here all day
> tomorrow after 10:30am PST.  I can call you, if you'd like.
>
> Bill
>
> ------------------------------------------------------------------------
> ----- Original Message -----
> *From:* WTerhune@...
> *To:* U2 Users List<u2-users@...>
> *Date:* 1/8/2012 1:06 PM
> *Subject:* Re: [U2] Uniobjects and Record Locking
>> UniData record locks are tied to a file variable. So if a file is opened

in named common, a lock could persist after a subroutine exits. Of course,
it would show up in LIST.READU...
>>
>> The behavior Bill describes doesn't make sense to me. Would love to see a
small test case demonstrating what he describes.

>>
>> Wally Terhune
>> U2 Support Architect
>> Rocket Software
>> 4600 South Ulster Street, Suite 1100 **Denver, CO 80237 **USA
>> Tel: [phone]
>> Email: WTerhune@...
>> Web: www.rocketsoftware.com/u2
>>
>>
>>
>>
>> -----Original Message-----
>> From: u2-users-bounces@...

[mailto:u2-users-bounces@...] On Behalf Of Bill Haskett
>> Sent: Sunday, January 08, 2012 12:48 PM
>> To: U2 Users List
>> Subject: Re: [U2] Uniobjects and Record Locking
>>
>> John:
>>
>> As a note, we've been programming in web paradigms for many years, and we
mostly understand the difference between non-persistent web connections and
persistent telnet connections.
>>
>> None of our activities does anything except gather data and submit to UO
for almost instantaneous results, whereupon the results is returned to the
web.  These are all momentary connections and no LOCKING occurs except
within the context of a momentary update.  So, the user calls the web
server, a UO connection is either reused or created to connect to the dbms,
a subroutine is run and ends (which, of course, should release all locks
within the subroutine (unless doing something like a WRITEU which we never
do - we're old-school in that regard), the the web call is closed and data
returned by the UO connection is returned to the user in another web page,
and the web connection is closed.
>>
>> I think what's important to note is a "LIST.READU  ALL" shows the lock
when AE has the record edited and the BASIC LOCKED clause is taken on a
momentary UO connection.  When AE exits the record "LIST.READU  ALL" no
longer shows any record locks but the BASIC LOCKED clause on a subsequent UO
connection is still taken as though the record is locked only if the UO
connection where the lock occured is reused.  If a new UO connection is used
(due to timeouts or manually killing the original UO
>> connection) the BASIC LOCKED clause is __NOT__ taken.
>>
>> Thanks,
>>
>> Bill
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users


_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[John Varney]

I recently went to work for a company that is running UniVerse over Solaris.
This seems to be working really well.

We are running ManFact and are setting up multi-plant operations. As part of
the upgrade we are changing the live account from MANLIVE to something else.
I'm not doing the upgrade as I kinda walked into the middle of it, and the
person who is doing it seems very well versed in ManFact so no worries
there.

My question is where do we change the default login account? Come next
Monday, people should not be logging into MANLIVE. We looked at the initial
login script on Solaris but that just starts a uv session. Any ideas?




_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Joshua Gallant]

When you execute the uv session the local directory you are in at the time
is the account directory.  I'd think you are changing to that directory in
your login script or setting the path the same for every Solaris account.

Something like this in your ".profile" file could help:

cd /path/to/account/directoryexec `cat /.uvhome`/bin/uv


Note those are back ticks above.

- Josh





On 1/12/12 9:04 AM, "John Varney" <jvarney@...> wrote:

I recently went to work for a company that is running UniVerse over
Solaris.
This seems to be working really well.

We are running ManFact and are setting up multi-plant operations. As part
of
the upgrade we are changing the live account from MANLIVE to something
else.
I'm not doing the upgrade as I kinda walked into the middle of it, and the
person who is doing it seems very well versed in ManFact so no worries
there.

My question is where do we change the default login account? Come next
Monday, people should not be logging into MANLIVE. We looked at the initial
login script on Solaris but that just starts a uv session. Any ideas?




_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Sammartino, Richard]

We ran Unidata on Solaris.  Try checking /etc/passwd.  This is where the login account was stored on our configuration.

Rich
----- Original Message -----
From: "John Varney" <jvarney@...>
To: "U2 Users List" <u2-users@...>
Sent: Thursday, January 12, 2012 9:04:52 AM
Subject: Re: [U2] UniVerse over Solaris Logon Question.

I recently went to work for a company that is running UniVerse over Solaris.
This seems to be working really well.

We are running ManFact and are setting up multi-plant operations. As part of
the upgrade we are changing the live account from MANLIVE to something else.
I'm not doing the upgrade as I kinda walked into the middle of it, and the
person who is doing it seems very well versed in ManFact so no worries
there.

My question is where do we change the default login account? Come next
Monday, people should not be logging into MANLIVE. We looked at the initial
login script on Solaris but that just starts a uv session. Any ideas?




_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users