RE: [U2] Leaving U2 World to the Dark Side (SQL)
Brian, Thanks for book suggestions as this is one of the concepts that I am having issues with. Understanding the database/languages, SQL and Csharp, are just a how-to problem which I've got a pretty decent grasp of. However, RECORD LOCKING and concurrency seems to be the white elephant in room that I have seen less written about and worse even less thought out in the application(s) that I'm having to deal with. Thanks, Don Verhagen -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Brian Leach Sent: Sunday, February 22, 2009 12:39 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Leaving U2 World to the Dark Side (SQL) Hi Don I'm sure you'll excel there - especially with your depth of real-world (ie multivalue) knowledge behind you! But I would highly recommend reading whatever is the latest book on SQL Server and .Net by Roger Jennings before you do (check out Wrox press). Apart from the stuff pointed out here about maintaining three tier architectures and not just using data binding (actually, data binding to classes is fine, just binding to data sets is crap) the real bitch is concurrency control and how to handle it when you need to start looking at merge processing. There's a lot of good advise on that in the Roger Jennings books - and details on some hidden language features to make SQL Server access in .Net a lot more performant... Best of luck. Brian -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Don Verhagen Sent: 19 February 2009 11:04 To: u2-users@listserver.u2ug.org Subject: [U2] Leaving U2 World to the Dark Side (SQL) To those that know me on this group. I have been using the Unidata databases since 1998 when introduced to it by my former CIO. Over the years and throughout my IT career, it has served me well. Decreasing software production and maintenance costs, while at the same time increasing the value of the software I (we) developed to solve complex business solutions. I have accepted an Application Development management position with a company here in the Philadelphia area. However, they are not a U2 shop. I view this opportunity as a chance to build my skills in and around the .NET platform and evaluate the use MSSQL in a true business application that I myself have built on a U2 platform in a previous time. While this doesn't exclusively rule out U2 in the future, for now, I'll be in SQL-land. Just wanted give a heads up to those that know me here. Don Verhagen Application Development Manager People 2.0 www.people20.com --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Deadlock report ?
Take a look at analyze.shm (see the 'Administering Universe manual), IIRC the -r option in particular should give you just the record locks. On Sun, Feb 22, 2009 at 2:00 PM, Jacques G. jacque...@yahoo.com wrote: Hello, I was wondering if there is a deadlock report feature in Universe. We have web services that need to call legacy subroutines and these sometimes make use of READU clauses without the locked statements. Since our pooled webservices have to run between 14 and 92 transactions a minute these READU statements can cause timeouts for transactions waiting in line. The transactions causing the blockage do not necessarely remain blocked for very long. It can be anywhere from 30 seconds to half an hour however between the time the problem occurs and is detected and reported by our clients. It has usually passed before we can do a LIST.READU EVERY to detect which file is the one being blocked. I am only interested in the list of deadlocks that show blocked users at the end of the LIST.READU command (the list of users running a READU and waiting to obtain the lock) and not the huge GROUP locks report which preceeds it and which takes time to produce. There does not appear to be a switch to LIST.READU to only show the deadlock section. I've thought of running periodic LIST.READU EVERY every 2 minutes but with over 800 users online + the numerous webservices transactions, it just takes to long (over 4 minutes) to produce the list. So I've wondered if there isn't a reporting feature I could turn on so that I could see the deadlocks that occured during the day. This way, I could cross-reference the timeout problems with the deadlock list and see which file being accessed is behind the blockage. The info I'd need is: Time, blocked User, File, Key, Id of blocking user --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] HP, Cron, Como, Execute, Capturing . Not
We have a client on UV/HP-UX running a BASIC routine from a Cron job. The BASIC code shells out from EXECUTE and Captures data from the OS. The Capture is failing and it looks like COMO gets the StdOut that should be directed into a variable. I'm not sure yet if Como plays any part or if all Execute/Capturing instructions will fail when executed from Cron. The code works fine from TCL. I'm also checking to see if there are any other options or middleware, and exactly what's being executed in the Cron line. Until I get more info though, I'd like to know if this is a recognized issue. Under what conditions can we expect something like this to fail?: Execute sh -c ... Capturing result Thanks. Tony Gravagno Nebula Research and Development Info@ removeNebula-RnD.com (Various other email addresses are currently down ... it's Monday...) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Deadlock report ?
I'm already familiar with the -r option of analyse.shm but it is the equivalent to: LIST.READU EVERY. I only need this part: Active Read Waiters: Owner Waiter Device Inode Userno Userno 107400397041292 671 547 I an extract this part from the output of analyse.shm but this report takes a lot of time producing all of the grouplock and record lock information. Ideally, i'd need a switch to give me only this part + the key or group where the problem is occuring. - Original Message From: David Scoggins dscogg...@gmail.com To: u2-users@listserver.u2ug.org Sent: Monday, February 23, 2009 9:59:29 AM Subject: Re: [U2] [UV] Deadlock report ? Take a look at analyze.shm (see the 'Administering Universe manual), IIRC the -r option in particular should give you just the record locks. On Sun, Feb 22, 2009 at 2:00 PM, Jacques G. jacque...@yahoo.com wrote: Hello, I was wondering if there is a deadlock report feature in Universe. We have web services that need to call legacy subroutines and these sometimes make use of READU clauses without the locked statements. Since our pooled webservices have to run between 14 and 92 transactions a minute these READU statements can cause timeouts for transactions waiting in line. The transactions causing the blockage do not necessarely remain blocked for very long. It can be anywhere from 30 seconds to half an hour however between the time the problem occurs and is detected and reported by our clients. It has usually passed before we can do a LIST.READU EVERY to detect which file is the one being blocked. I am only interested in the list of deadlocks that show blocked users at the end of the LIST.READU command (the list of users running a READU and waiting to obtain the lock) and not the huge GROUP locks report which preceeds it and which takes time to produce. There does not appear to be a switch to LIST.READU to only show the deadlock section. I've thought of running periodic LIST.READU EVERY every 2 minutes but with over 800 users online + the numerous webservices transactions, it just takes to long (over 4 minutes) to produce the list. So I've wondered if there isn't a reporting feature I could turn on so that I could see the deadlocks that occured during the day. This way, I could cross-reference the timeout problems with the deadlock list and see which file being accessed is behind the blockage. The info I'd need is: Time, blocked User, File, Key, Id of blocking user --- 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] [UV] HP, Cron, Como, Execute, Capturing . Not
We do it all of the time with no problem. UV 10.1.12 on RH Linux AS 3. Jerry Banker -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tony G Sent: Monday, February 23, 2009 9:37 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] HP, Cron, Como, Execute, Capturing . Not We have a client on UV/HP-UX running a BASIC routine from a Cron job. The BASIC code shells out from EXECUTE and Captures data from the OS. The Capture is failing and it looks like COMO gets the StdOut that should be directed into a variable. I'm not sure yet if Como plays any part or if all Execute/Capturing instructions will fail when executed from Cron. The code works fine from TCL. I'm also checking to see if there are any other options or middleware, and exactly what's being executed in the Cron line. Until I get more info though, I'd like to know if this is a recognized issue. Under what conditions can we expect something like this to fail?: Execute sh -c ... Capturing result Thanks. Tony Gravagno Nebula Research and Development Info@ removeNebula-RnD.com (Various other email addresses are currently down ... it's Monday...) --- 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] [UV] Deadlock report ?
Use this verb. LIST.QUEUE [USERNAME user_name | FILENAME filename | user_number][DETAIL] Synonym LIST-QUEUE Description The ECL LIST.QUEUE command lists processes that currently waiting for locks. If a process is waiting for a lock, LIST.QUEUE displays information about the holder of the lock and processes waiting for the lock. Locks are set by each udt process through the general lock manager (GLM) module. UniBasic commands that check for locks, such as READU and READVU, cause processes to wait for locks to be released before proceeding. Nicholas M Gettino | Director of Development | EnRoute Emergency Systems, an Infor company | office: 813-207-6998 | fax: 678-393-5389 nick.gett...@infor.com | www.enroute911.com -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Jacques G. Sent: Monday, February 23, 2009 11:24 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Deadlock report ? I'm already familiar with the -r option of analyse.shm but it is the equivalent to: LIST.READU EVERY. I only need this part: Active Read Waiters: Owner Waiter Device Inode Userno Userno 107400397041292 671 547 I an extract this part from the output of analyse.shm but this report takes a lot of time producing all of the grouplock and record lock information. Ideally, i'd need a switch to give me only this part + the key or group where the problem is occuring. - Original Message From: David Scoggins dscogg...@gmail.com To: u2-users@listserver.u2ug.org Sent: Monday, February 23, 2009 9:59:29 AM Subject: Re: [U2] [UV] Deadlock report ? Take a look at analyze.shm (see the 'Administering Universe manual), IIRC the -r option in particular should give you just the record locks. On Sun, Feb 22, 2009 at 2:00 PM, Jacques G. jacque...@yahoo.com wrote: Hello, I was wondering if there is a deadlock report feature in Universe. We have web services that need to call legacy subroutines and these sometimes make use of READU clauses without the locked statements. Since our pooled webservices have to run between 14 and 92 transactions a minute these READU statements can cause timeouts for transactions waiting in line. The transactions causing the blockage do not necessarely remain blocked for very long. It can be anywhere from 30 seconds to half an hour however between the time the problem occurs and is detected and reported by our clients. It has usually passed before we can do a LIST.READU EVERY to detect which file is the one being blocked. I am only interested in the list of deadlocks that show blocked users at the end of the LIST.READU command (the list of users running a READU and waiting to obtain the lock) and not the huge GROUP locks report which preceeds it and which takes time to produce. There does not appear to be a switch to LIST.READU to only show the deadlock section. I've thought of running periodic LIST.READU EVERY every 2 minutes but with over 800 users online + the numerous webservices transactions, it just takes to long (over 4 minutes) to produce the list. So I've wondered if there isn't a reporting feature I could turn on so that I could see the deadlocks that occured during the day. This way, I could cross-reference the timeout problems with the deadlock list and see which file being accessed is behind the blockage. The info I'd need is: Time, blocked User, File, Key, Id of blocking user --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] HP, Cron, Como, Execute, Capturing . Not
We are running UniData on HP-UX and I capture Unix info regularly. Rather than using a COMO, just do it with the EXECUTE command like so: STMT = !ls -lia (or whatever you need to capture) EXECUTE STMT CAPTURING UNIX.TXT Then loop through UNIX.TXT as needed. If the results can be big, use LOOP/REMOVE rather than FOR/NEXT. John Israel -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of jpb-u2ug Sent: Monday, February 23, 2009 12:28 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] [UV] HP, Cron, Como, Execute, Capturing . Not We do it all of the time with no problem. UV 10.1.12 on RH Linux AS 3. Jerry Banker -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Tony G Sent: Monday, February 23, 2009 9:37 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] HP, Cron, Como, Execute, Capturing . Not We have a client on UV/HP-UX running a BASIC routine from a Cron job. The BASIC code shells out from EXECUTE and Captures data from the OS. The Capture is failing and it looks like COMO gets the StdOut that should be directed into a variable. I'm not sure yet if Como plays any part or if all Execute/Capturing instructions will fail when executed from Cron. The code works fine from TCL. I'm also checking to see if there are any other options or middleware, and exactly what's being executed in the Cron line. Until I get more info though, I'd like to know if this is a recognized issue. Under what conditions can we expect something like this to fail?: Execute sh -c ... Capturing result Thanks. Tony Gravagno Nebula Research and Development Info@ removeNebula-RnD.com (Various other email addresses are currently down ... it's Monday...) --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] Deadlock report ?
On UV I don't seem to have a LIST.QUEUE command; is it possible that this is a UD feature? I wish there were a UV equivalent, like the D3 LIST-LOCKQ command. /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 On Mon, Feb 23, 2009 at 10:11 AM, Nick Gettino nick.gett...@enroute911.comwrote: Use this verb. LIST.QUEUE [USERNAME user_name | FILENAME filename | user_number][DETAIL] Synonym LIST-QUEUE Description The ECL LIST.QUEUE command lists processes that currently waiting for locks. If a process is waiting for a lock, LIST.QUEUE displays information about the holder of the lock and processes waiting for the lock. Locks are set by each udt process through the general lock manager (GLM) module. UniBasic commands that check for locks, such as READU and READVU, cause processes to wait for locks to be released before proceeding. Nicholas M Gettino | Director of Development | EnRoute Emergency Systems, an Infor company | office: 813-207-6998 | fax: 678-393-5389 nick.gett...@infor.com | www.enroute911.com -Original Message- From: owner-u2-us...@listserver.u2ug.org [mailto:owner-u2-us...@listserver.u2ug.org] On Behalf Of Jacques G. Sent: Monday, February 23, 2009 11:24 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UV] Deadlock report ? I'm already familiar with the -r option of analyse.shm but it is the equivalent to: LIST.READU EVERY. I only need this part: Active Read Waiters: Owner Waiter Device Inode Userno Userno 107400397041292 671 547 I an extract this part from the output of analyse.shm but this report takes a lot of time producing all of the grouplock and record lock information. Ideally, i'd need a switch to give me only this part + the key or group where the problem is occuring. - Original Message From: David Scoggins dscogg...@gmail.com To: u2-users@listserver.u2ug.org Sent: Monday, February 23, 2009 9:59:29 AM Subject: Re: [U2] [UV] Deadlock report ? Take a look at analyze.shm (see the 'Administering Universe manual), IIRC the -r option in particular should give you just the record locks. On Sun, Feb 22, 2009 at 2:00 PM, Jacques G. jacque...@yahoo.com wrote: Hello, I was wondering if there is a deadlock report feature in Universe. We have web services that need to call legacy subroutines and these sometimes make use of READU clauses without the locked statements. Since our pooled webservices have to run between 14 and 92 transactions a minute these READU statements can cause timeouts for transactions waiting in line. The transactions causing the blockage do not necessarely remain blocked for very long. It can be anywhere from 30 seconds to half an hour however between the time the problem occurs and is detected and reported by our clients. It has usually passed before we can do a LIST.READU EVERY to detect which file is the one being blocked. I am only interested in the list of deadlocks that show blocked users at the end of the LIST.READU command (the list of users running a READU and waiting to obtain the lock) and not the huge GROUP locks report which preceeds it and which takes time to produce. There does not appear to be a switch to LIST.READU to only show the deadlock section. I've thought of running periodic LIST.READU EVERY every 2 minutes but with over 800 users online + the numerous webservices transactions, it just takes to long (over 4 minutes) to produce the list. So I've wondered if there isn't a reporting feature I could turn on so that I could see the deadlocks that occured during the day. This way, I could cross-reference the timeout problems with the deadlock list and see which file being accessed is behind the blockage. The info I'd need is: Time, blocked User, File, Key, Id of blocking user --- 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/ --- 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] [UV] HP, Cron, Como, Execute, Capturing . Not
Hi Tony,
I do this all the time on UV 10.1.4 on RH AS 3. I have not seen a conflict
with COMO and EXECUTE CAPTURING, except that the COMO records the results of
the execute as well as the CAPTURING variable.
E.g. EXECUTE SH -c 'ls' CAPTURING DIR.LIST
Not only does DIR.LIST contain all the files in the directory, but the COMO
records them as well, making for very verbose COMO files!
Note that I have not tried the combination of cron + COMO + EXECUTE
CAPTURING {+
On Mon, Feb 23, 2009 at 7:37 AM, Tony G 1tlx6h...@sneakemail.com wrote:
We have a client on UV/HP-UX running a BASIC routine from a Cron
job. The BASIC code shells out from EXECUTE and Captures data
from the OS. The Capture is failing and it looks like COMO gets
the StdOut that should be directed into a variable.
I'm not sure yet if Como plays any part or if all
Execute/Capturing instructions will fail when executed from Cron.
The code works fine from TCL. I'm also checking to see if there
are any other options or middleware, and exactly what's being
executed in the Cron line.
Until I get more info though, I'd like to know if this is a
recognized issue. Under what conditions can we expect something
like this to fail?:
Execute sh -c ... Capturing result
Thanks.
Tony Gravagno
Nebula Research and Development
Info@ removeNebula-RnD.com
(Various other email addresses are currently down ... it's
Monday...)
---
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] [UV] HP, Cron, Como, Execute, Capturing . Not
Thanks for responses so far.
Scott - this code is also doing 'ls', and the output gets
captured in COMO as you have seen, but it doesn't continue into
the Capturing var. At least we can confirm COMO is supposed to
see the output (for better or worse) but not at the expense of
BASIC not seeing it.
I'm wondering if this is an OS-specific issue where UV/HP is
capturing in COMO but not in Capturing, or maybe this is only
occurring when run through Cron. They could be doing something
like this too:
echo PHANTOM RUNREPORT | uv
...with the phantom being the platform-specific culprit.
I'll get the details and report back, then maybe someone with the
same platform here can check this before we file a bug report.
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Email now working properly
Don't forget Pickwiki.com!
From: Scott Ballinger
I do this all the time on UV 10.1.4 on RH AS 3. I have
not seen a conflict with COMO and EXECUTE CAPTURING,
except that the COMO records the results of the
execute as well as the CAPTURING variable. E.g.
EXECUTE SH -c 'ls' CAPTURING DIR.LIST
Not only does DIR.LIST contain all the files in the
directory, but the COMO records them as well, making
for very verbose COMO files!
Note that I have not tried the combination of cron +
COMO + EXECUTE CAPTURING {+ PHANTOM?} so perhaps there
is something going on there, but I do use cron +
EXECUTE CAPTURING in many places without problems.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
