Re: [U2] READU vs READ and CRT
For a webapp, does an animated gif really detract processing time? The gif should be running client side, And the processing of the app would be running server side. Maybe you could only show the gif while The app is waiting for the server to push some more data? George -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 8:38 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ and CRT It's better for peace of mind to know that the computer thinks it's doing something Rather than wondering Is it DOING something -Original Message- From: Dawn Wolthuis dw...@tincat-group.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 5:30 pm Subject: Re: [U2] READU vs READ and CRT Well, I get it even if it seems foolish at first blush -- it's all about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM, Charlie Noah cwn...@comcast.net wrote: Hi Laura and Dawn, This reminds me of a program I wrote about 20 years ago for a multilevel marketing company. Its job was to audit a seller's downline, which in many cases ran into thousands or tens of thousands of transactions. For some larger sellers it ran for several minutes. The users insisted on seeing what progress it was making, and settled on a whirly-gig. I explained that it would only slow the process down, but they didn't care. They were quite willing to sacrifice speed for a stupid little character twirling around. Go figure... Regards, Charlie Noah ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
You are correct that the animated gif does not harm the processing time on the server. I think it is obnoxious to the user when it is there for too short a time, so I hauled some out and stopped putting them in, figuring we will wait to see where they are really needed once we do volume testing. I have not researched it to see if there are any studies that suggest that an animated gif that flashes quickly provides a bad user experience. My UX testing in this case was not formal -- it was me going oh, yuck, I don't want that gif to be there for so short a time. You are right that this is not of the same ilk regarding performance. Yes, it only shows while the server is doing something -- when a process returns it hides the gif. --dawn On Wed, May 2, 2012 at 8:21 AM, George Gallen ggal...@wyanokegroup.comwrote: For a webapp, does an animated gif really detract processing time? The gif should be running client side, And the processing of the app would be running server side. Maybe you could only show the gif while The app is waiting for the server to push some more data? George -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto: u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 8:38 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ and CRT It's better for peace of mind to know that the computer thinks it's doing something Rather than wondering Is it DOING something -Original Message- From: Dawn Wolthuis dw...@tincat-group.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 5:30 pm Subject: Re: [U2] READU vs READ and CRT Well, I get it even if it seems foolish at first blush -- it's all about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM, Charlie Noah cwn...@comcast.net wrote: Hi Laura and Dawn, This reminds me of a program I wrote about 20 years ago for a multilevel marketing company. Its job was to audit a seller's downline, which in many cases ran into thousands or tens of thousands of transactions. For some larger sellers it ran for several minutes. The users insisted on seeing what progress it was making, and settled on a whirly-gig. I explained that it would only slow the process down, but they didn't care. They were quite willing to sacrifice speed for a stupid little character twirling around. Go figure... Regards, Charlie Noah ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Dawn M. Wolthuis Take and give some delight today ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
I use two different onesFor general applications, I have a perpetual melting ice cube, and for financial transactions I use a stack of money being fanned. Sometimes you focus on the image itself and the wait seems like years, other times, you Can work on something else, and know it's completed when the image disappers. Nothings worse than having the application finish, and you keep waiting because you didn't Realize it updated, especially if the layout of the page doesn't change, just The page data. Maybe you could use a javascript timer to unhide the image after x number of seconds goes by. So if it updates in less than 5 seconds, no image, after 5 seconds you get a working icon. George -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dawn Wolthuis Sent: Wednesday, May 02, 2012 10:08 AM To: U2 Users List Subject: Re: [U2] READU vs READ and CRT You are correct that the animated gif does not harm the processing time on the server. I think it is obnoxious to the user when it is there for too short a time, so I hauled some out and stopped putting them in, figuring we will wait to see where they are really needed once we do volume testing. I have not researched it to see if there are any studies that suggest that an animated gif that flashes quickly provides a bad user experience. My UX testing in this case was not formal -- it was me going oh, yuck, I don't want that gif to be there for so short a time. You are right that this is not of the same ilk regarding performance. Yes, it only shows while the server is doing something -- when a process returns it hides the gif. --dawn ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
How about something like this? This way it doesn't get displayed for the
quick updates.
function doServerUpdate() {
var serverUpdateTimer = setTimeout(showServerUpdateWait(), 5000);
...
hideServerUpdateWait();
clearTimeout(serverUpdateTimer);
}
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dawn Wolthuis
Sent: Wednesday, May 02, 2012 7:08 AM
To: U2 Users List
Subject: Re: [U2] READU vs READ and CRT
You are correct that the animated gif does not harm the processing time on
the server. I think it is obnoxious to the user when it is there for too
short a time, so I hauled some out and stopped putting them in, figuring we
will wait to see where they are really needed once we do volume testing. I
have not researched it to see if there are any studies that suggest that an
animated gif that flashes quickly provides a bad user experience. My UX
testing in this case was not formal -- it was me going oh, yuck, I don't
want that gif to be there for so short a time.
You are right that this is not of the same ilk regarding performance. Yes,
it only shows while the server is doing something -- when a process returns
it hides the gif. --dawn
On Wed, May 2, 2012 at 8:21 AM, George Gallen
ggal...@wyanokegroup.comwrote:
For a webapp, does an animated gif really detract processing time? The
gif should be running client side, And the processing of the app
would be running server side. Maybe you could only show the gif while
The app is waiting for the server to push some more data?
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:
u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, May 01, 2012 8:38 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] READU vs READ and CRT
It's better for peace of mind to know that the computer thinks it's
doing something Rather than wondering Is it DOING something
-Original Message-
From: Dawn Wolthuis dw...@tincat-group.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, May 1, 2012 5:30 pm
Subject: Re: [U2] READU vs READ and CRT
Well, I get it even if it seems foolish at first blush -- it's all
about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM,
Charlie Noah cwn...@comcast.net wrote:
Hi Laura and Dawn,
This reminds me of a program I wrote about 20 years ago for a
multilevel marketing company. Its job was to audit a seller's
downline, which in many cases ran into thousands or tens of thousands
of transactions. For some larger sellers it ran for several minutes.
The users insisted on seeing what progress it was making, and settled
on a whirly-gig. I explained that it would only slow the process
down, but they didn't care. They were quite willing to sacrifice speed
for a stupid little character twirling around.
Go figure...
Regards,
Charlie Noah
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
Dawn M. Wolthuis
Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
Good idea! I was just leaving this out at this point so I didn't clutter up
the code unnecessarily, figuring I would only put these in where I know
they are needed. But in cases where I'm not sure, this seems like a good
approach. Thanks! --dawn
On Wed, May 2, 2012 at 10:13 AM, David A. Green dgr...@dagconsulting.comwrote:
How about something like this? This way it doesn't get displayed for the
quick updates.
function doServerUpdate() {
var serverUpdateTimer = setTimeout(showServerUpdateWait(), 5000);
...
hideServerUpdateWait();
clearTimeout(serverUpdateTimer);
}
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dawn Wolthuis
Sent: Wednesday, May 02, 2012 7:08 AM
To: U2 Users List
Subject: Re: [U2] READU vs READ and CRT
You are correct that the animated gif does not harm the processing time on
the server. I think it is obnoxious to the user when it is there for too
short a time, so I hauled some out and stopped putting them in, figuring we
will wait to see where they are really needed once we do volume testing. I
have not researched it to see if there are any studies that suggest that an
animated gif that flashes quickly provides a bad user experience. My UX
testing in this case was not formal -- it was me going oh, yuck, I don't
want that gif to be there for so short a time.
You are right that this is not of the same ilk regarding performance. Yes,
it only shows while the server is doing something -- when a process returns
it hides the gif. --dawn
On Wed, May 2, 2012 at 8:21 AM, George Gallen
ggal...@wyanokegroup.comwrote:
For a webapp, does an animated gif really detract processing time? The
gif should be running client side, And the processing of the app
would be running server side. Maybe you could only show the gif while
The app is waiting for the server to push some more data?
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:
u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, May 01, 2012 8:38 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] READU vs READ and CRT
It's better for peace of mind to know that the computer thinks it's
doing something Rather than wondering Is it DOING something
-Original Message-
From: Dawn Wolthuis dw...@tincat-group.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, May 1, 2012 5:30 pm
Subject: Re: [U2] READU vs READ and CRT
Well, I get it even if it seems foolish at first blush -- it's all
about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM,
Charlie Noah cwn...@comcast.net wrote:
Hi Laura and Dawn,
This reminds me of a program I wrote about 20 years ago for a
multilevel marketing company. Its job was to audit a seller's
downline, which in many cases ran into thousands or tens of thousands
of transactions. For some larger sellers it ran for several minutes.
The users insisted on seeing what progress it was making, and settled
on a whirly-gig. I explained that it would only slow the process
down, but they didn't care. They were quite willing to sacrifice speed
for a stupid little character twirling around.
Go figure...
Regards,
Charlie Noah
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
Dawn M. Wolthuis
Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
Dawn M. Wolthuis
Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
That's been the default mechanism for years in ASP.NET Ajax (just
another free framework). Your progress panel is set to only go visible
if an ajax request doesn't return in x seconds.
Each request needs to be considered for tuning. The response to a
simple data validation is expected to only take a second or so, but
populating a grid may be expected to take much longer. Then again if
you're not using session pooling and a bunch of users hit your server,
then even the simplest validation could take some number of seconds.
So you don't want to hardcode to turn off the progress animation.
Consider that people get uptight and start re-clicking if they don't
get immediate gratification - that's just the broadband world we live
in even if the expectation isn't realistic. So it's not unreasonable
to show progress entertainment within 1-2 seconds of a request, just
to pre-empt that nervous clicking.
Of course, if you expect that a transaction will take longer than a
few seconds, tell the user (just don't use a modal form!), and for
larger reports consider more asynchronous methods which don't require
the user to sit there with a progress indicator in the first place.
HTH
T
(Someone really should have changed the subject of this thread...)
From: Dawn Wolthuis
Good idea! I was just leaving this out at this point so I didn't
clutter up
the code unnecessarily, figuring I would only put these in where I
know they are needed. But in cases where I'm not sure, this seems
like
a good approach. Thanks! --dawn
On Wed, May 2, 2012 at 10:13 AM, David A. Green wrote:
How about something like this? This way it doesn't get displayed
for
the quick updates.
function doServerUpdate() {
var serverUpdateTimer = setTimeout(showServerUpdateWait(),
5000);
...
hideServerUpdateWait();
clearTimeout(serverUpdateTimer);
}
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
Another very simple and subtle thing you can do is make use of the
default OS pointer icons via javascript:
document.body.style.cursor = 'wait'; // hourglass, spinning circle,
etc.
document.body.style.cursor = 'default'; // arrow
I change the pointer for AJAX calls when the user should wait for
results from before doing something else, and additionally pop up an
animated gif for the calls I know will take more than 3 or 4 seconds.
It's pretty clear to users that they shouldn't attempt to click on
things when the mouse pointer is not an arrow or hand.
-John
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dawn Wolthuis
Sent: Wednesday, May 02, 2012 8:22 AM
To: U2 Users List
Subject: Re: [U2] READU vs READ and CRT
Good idea! I was just leaving this out at this point so I didn't clutter
up the code unnecessarily, figuring I would only put these in where I
know they are needed. But in cases where I'm not sure, this seems like a
good approach. Thanks! --dawn
On Wed, May 2, 2012 at 10:13 AM, David A. Green
dgr...@dagconsulting.comwrote:
How about something like this? This way it doesn't get displayed for
the quick updates.
function doServerUpdate() {
var serverUpdateTimer = setTimeout(showServerUpdateWait(), 5000);
...
hideServerUpdateWait();
clearTimeout(serverUpdateTimer);
}
David A. Green
(480) 813-1725
DAG Consulting
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dawn
Wolthuis
Sent: Wednesday, May 02, 2012 7:08 AM
To: U2 Users List
Subject: Re: [U2] READU vs READ and CRT
You are correct that the animated gif does not harm the processing
time on the server. I think it is obnoxious to the user when it is
there for too short a time, so I hauled some out and stopped putting
them in, figuring we will wait to see where they are really needed
once we do volume testing. I have not researched it to see if there
are any studies that suggest that an animated gif that flashes quickly
provides a bad user experience. My UX testing in this case was not
formal -- it was me going oh, yuck, I don't want that gif to be there
for so short a time.
You are right that this is not of the same ilk regarding performance.
Yes, it only shows while the server is doing something -- when a
process returns it hides the gif. --dawn
On Wed, May 2, 2012 at 8:21 AM, George Gallen
ggal...@wyanokegroup.comwrote:
For a webapp, does an animated gif really detract processing time?
The gif should be running client side, And the processing of the
app would be running server side. Maybe you could only show the gif
while The app is waiting for the server to push some more data?
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:
u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, May 01, 2012 8:38 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] READU vs READ and CRT
It's better for peace of mind to know that the computer thinks it's
doing something Rather than wondering Is it DOING something
-Original Message-
From: Dawn Wolthuis dw...@tincat-group.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, May 1, 2012 5:30 pm
Subject: Re: [U2] READU vs READ and CRT
Well, I get it even if it seems foolish at first blush -- it's all
about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM,
Charlie Noah cwn...@comcast.net wrote:
Hi Laura and Dawn,
This reminds me of a program I wrote about 20 years ago for a
multilevel marketing company. Its job was to audit a seller's
downline, which in many cases ran into thousands or tens of
thousands of transactions. For some larger sellers it ran for
several minutes.
The users insisted on seeing what progress it was making, and
settled on a whirly-gig. I explained that it would only slow the
process down, but they didn't care. They were quite willing to
sacrifice speed
for a stupid little character twirling around.
Go figure...
Regards,
Charlie Noah
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
Dawn M. Wolthuis
Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
Dawn M. Wolthuis
Take and give some delight today
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Have you been able to do any os level tools to see what the utilisation of resources is. E.g. on linux, vmstat, top, iostat will show you if it is a diskio or cpu bottleneck. If it is diskio (i.e. high wait on io times) then you may need to upgrade the disks or add more ram so you have more data in cache. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: 01 May 2012 02:58 To: U2 Users List Subject: Re: [U2] READU vs READ Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 9:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended
Re: [U2] READU vs READ
Hi, The question of READU vs READ when you are doing updates is moot. If you do a READ then a WRITE, UniVerse/UniData will perform the record lock. The only difference is with READ you are gambling that no one else is updating the record before you perform your WRITE. Performance, as others suggested, there are several things to do: Tune your files. If you are using dynamic files, make sure you have the MINIMUM.MODULUS set to reduce the shrink and merging If the records are lumpy redesign them so you have a header file and a detail file, with detail files being individual records for the associated values. Use LIST.INDEX with the STATISTICS option to see if you have huge index value, you may need to refine the index. Check your hardware, you may have a bottleneck due to slow disk, I/O pipe. Minimize the number of times you go through the associated values. Use READU with the LOCKED clause, if the record is locked, add logic to queue it up and try the records again once everything else is processed (WRITEs will hang on a lock if you don't have the LOCKED clause, just like a READU without the LOCKED clause. Good luck! Tom RATEX Business Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Symeon Breen Sent: Tuesday, May 01, 2012 4:44 AM To: 'U2 Users List' Subject: Re: [U2] READU vs READ Have you been able to do any os level tools to see what the utilisation of resources is. E.g. on linux, vmstat, top, iostat will show you if it is a diskio or cpu bottleneck. If it is diskio (i.e. high wait on io times) then you may need to upgrade the disks or add more ram so you have more data in cache. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: 01 May 2012 02:58 To: U2 Users List Subject: Re: [U2] READU vs READ Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 9:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http
Re: [U2] READU vs READ
Dave; A couple more things: - do you have any other processes running at the same time? I found (long ago) that a couple of our big processes ran 5X faster consecutively than they did concurrently. - subroutine calls with file opens. I inherited a process that was running for 3 days and was 65% done. I put all of the file opens in common (well, the file variables) and re-ran in hours. You may want to re-think posting some of the code. There can be some efficiencies found in processing large dynamic arrays. You said it wasn't code you wrote - so try to take the criticism as constructive :) hth Colin -Original Message- From: Tom Whitmore Sent: May 1, 2012 5:50 AM To: U2 Users List Subject: Re: [U2] READU vs READ Hi, The question of READU vs READ when you are doing updates is moot. If you do a READ then a WRITE, UniVerse/UniData will perform the record lock. The only difference is with READ you are gambling that no one else is updating the record before you perform your WRITE. Performance, as others suggested, there are several things to do: Tune your files. If you are using dynamic files, make sure you have the MINIMUM.MODULUS set to reduce the shrink and merging If the records are lumpy redesign them so you have a header file and a detail file, with detail files being individual records for the associated values. Use LIST.INDEX with the STATISTICS option to see if you have huge index value, you may need to refine the index. Check your hardware, you may have a bottleneck due to slow disk, I/O pipe. Minimize the number of times you go through the associated values. Use READU with the LOCKED clause, if the record is locked, add logic to queue it up and try the records again once everything else is processed (WRITEs will hang on a lock if you don't have the LOCKED clause, just like a READU without the LOCKED clause. Good luck! Tom RATEX Business Solutions -Original Message- From: Symeon Breen Have you been able to do any os level tools to see what the utilisation of resources is. E.g. on linux, vmstat, top, iostat will show you if it is a diskio or cpu bottleneck. If it is diskio (i.e. high wait on io times) then you may need to upgrade the disks or add more ram so you have more data in cache. -Original Message- From: Dave Laansma Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Thank you Colin. I wouldn't post these types of 'issues' if I were thin-skinned and didn't appreciate input. There are certainly some efficiencies in the updating of the multi-values. Unfortunately I cannot reorganize the data in the records, only the code that updates said data. I'll consider posting it. Names will have to be changed to protect 'the innocent' copyright. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Colin Alfke Sent: Tuesday, May 01, 2012 10:05 AM To: 'U2 Users List' Subject: Re: [U2] READU vs READ Dave; A couple more things: - do you have any other processes running at the same time? I found (long ago) that a couple of our big processes ran 5X faster consecutively than they did concurrently. - subroutine calls with file opens. I inherited a process that was running for 3 days and was 65% done. I put all of the file opens in common (well, the file variables) and re-ran in hours. You may want to re-think posting some of the code. There can be some efficiencies found in processing large dynamic arrays. You said it wasn't code you wrote - so try to take the criticism as constructive :) hth Colin -Original Message- From: Tom Whitmore Sent: May 1, 2012 5:50 AM To: U2 Users List Subject: Re: [U2] READU vs READ Hi, The question of READU vs READ when you are doing updates is moot. If you do a READ then a WRITE, UniVerse/UniData will perform the record lock. The only difference is with READ you are gambling that no one else is updating the record before you perform your WRITE. Performance, as others suggested, there are several things to do: Tune your files. If you are using dynamic files, make sure you have the MINIMUM.MODULUS set to reduce the shrink and merging If the records are lumpy redesign them so you have a header file and a detail file, with detail files being individual records for the associated values. Use LIST.INDEX with the STATISTICS option to see if you have huge index value, you may need to refine the index. Check your hardware, you may have a bottleneck due to slow disk, I/O pipe. Minimize the number of times you go through the associated values. Use READU with the LOCKED clause, if the record is locked, add logic to queue it up and try the records again once everything else is processed (WRITEs will hang on a lock if you don't have the LOCKED clause, just like a READU without the LOCKED clause. Good luck! Tom RATEX Business Solutions -Original Message- From: Symeon Breen Have you been able to do any os level tools to see what the utilisation of resources is. E.g. on linux, vmstat, top, iostat will show you if it is a diskio or cpu bottleneck. If it is diskio (i.e. high wait on io times) then you may need to upgrade the disks or add more ram so you have more data in cache. -Original Message- From: Dave Laansma Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] READU vs READ
Updating 700,000 records. If you want speed on the reads and writes the best way to accomplish it is to MATREADU the record equate the attributes you are going to update or all of them in case you ever want to add and then MATWRITE. It takes more coding, but it is well worth it. It takes a little longer to start the program ( a few seconds) but the results will amaze you compared to a normal READU. Nicholas M Gettino, Director of Professional Services Support, EnRoute Emergency Systems an Infor Company, Concourse Center 1, 3501 East Frontage Rd, Suite 350, Tampa, FL 33607 -(813) 207-6998 direct, (813) 334-3507 cell, FAX (678) 393-5389 nick.gett...@enroute911.com or nick.gett...@infor.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Maybe. There is the additional overhead of populating the DIM array on the MATREAD and the reverse on the MATWRITE. The more your program accesses the fields, esp. the more fields you have, then I agree, this can be MUCH faster. However, it you have big records and all you are doing is updating field 1, you may be doing a lot of overhead without getting the bang for your buck. Write a simple program that simulates your effort with READS/WRITES and then again with MATREADS/MATWRITES. Depending on what you are actually doing may or may not make a huge difference. If your performance is a real issue, this could be well worth the effort. John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Nick Gettino Sent: Tuesday, May 01, 2012 3:45 PM To: 'u2-users@listserver.u2ug.org' Subject: Re: [U2] READU vs READ Additional the larger the record the better the MATREADU works over the READU. Nicholas M Gettino, Director of Professional Services Support, EnRoute Emergency Systems an Infor Company, Concourse Center 1, 3501 East Frontage Rd, Suite 350, Tampa, FL 33607 -(813) 207-6998 direct, (813) 334-3507 cell, FAX (678) 393-5389 nick.gett...@enroute911.com or nick.gett...@infor.com From: Nick Gettino Sent: Tuesday, May 01, 2012 3:44 PM To: u2-users@listserver.u2ug.org Subject: [U2] READU vs READ Updating 700,000 records. If you want speed on the reads and writes the best way to accomplish it is to MATREADU the record equate the attributes you are going to update or all of them in case you ever want to add and then MATWRITE. It takes more coding, but it is well worth it. It takes a little longer to start the program ( a few seconds) but the results will amaze you compared to a normal READU. Nicholas M Gettino, Director of Professional Services Support, EnRoute Emergency Systems an Infor Company, Concourse Center 1, 3501 East Frontage Rd, Suite 350, Tampa, FL 33607 -(813) 207-6998 direct, (813) 334-3507 cell, FAX (678) 393-5389 nick.gett...@enroute911.commailto:nick.gett...@enroute911.com or nick.gett...@infor.commailto:nick.gett...@infor.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
If the multivalues have many many values, and you are adding to the end, then a speed up may be possible. MATREAD in the data, RAISE those array elements you are changing. Before the MATWRITE, LOWER all array elements you raised. As I understand it, Universe keeps internal track on attributes, so processing these in ascending order is a LOT faster than it used to be. However this is not done for multivalues (space considerations?). Regards, Keith ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good thing do help, but I reduced a process scanning 20 million records from 12 days to 2 days just taking out the CRT to screen informing the user of progress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the code as below sits at n,count += 1 if rem(count,2) then CRT n.count:' / ' : tot.count end On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) troy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Computers keep getting faster, and databases keep getting larger. So as a refinement you could say, display something if a second or more has passed, and don't display anything if it hasn't. We used to use MOD 100, which was fine 20 years ago. Now it spins by so fast you cant read it. -Original Message- From: dennis bartlett dqbartl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 3:16 pm Subject: Re: [U2] READU vs READ I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good hing do help, but I reduced a process scanning 20 million records from 12 ays to 2 days just taking out the CRT to screen informing the user of rogress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the ode as below sits at n,count += 1 f rem(count,2) then CRT n.count:' / ' : tot.count nd On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) roy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
Just an interesting piece of history that folks might find amusing. Back in the day, Ultimate had a development project to speed up the basic compiler. Everyone was really anticipating the performance improvements. However, when the new compiler was timed and tested, it didn't produce the expected speed improvements and the developers couldn't find the cause. At the time, Ultimate displayed one asterisk as each line of code was compiled. After much investigation, one of the developers thought to remove the display of the *, and the compiler flew! It was truly amazing - so much so that we didn't think the program compiled at all. The new compiler was finally released as one * for each 10 lines of code. :) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 6:24 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Computers keep getting faster, and databases keep getting larger. So as a refinement you could say, display something if a second or more has passed, and don't display anything if it hasn't. We used to use MOD 100, which was fine 20 years ago. Now it spins by so fast you cant read it. -Original Message- From: dennis bartlett dqbartl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 3:16 pm Subject: Re: [U2] READU vs READ I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good hing do help, but I reduced a process scanning 20 million records from 12 ays to 2 days just taking out the CRT to screen informing the user of rogress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the ode as below sits at n,count += 1 f rem(count,2) then CRT n.count:' / ' : tot.count nd On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) roy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
Good story, Laura! We are figuring out where we need animated gifs in a web app to indicate something is happening. They seem mostly unnecessary (with test data, which, granted, might be the reason they seem unnecessary at this point), so we are erring on the side of keeping them out, rather than putting them in. --dawn On Tue, May 1, 2012 at 6:17 PM, Laura Hirsh la...@lhirsh.org wrote: Just an interesting piece of history that folks might find amusing. Back in the day, Ultimate had a development project to speed up the basic compiler. Everyone was really anticipating the performance improvements. However, when the new compiler was timed and tested, it didn't produce the expected speed improvements and the developers couldn't find the cause. At the time, Ultimate displayed one asterisk as each line of code was compiled. After much investigation, one of the developers thought to remove the display of the *, and the compiler flew! It was truly amazing - so much so that we didn't think the program compiled at all. The new compiler was finally released as one * for each 10 lines of code. :) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 6:24 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Computers keep getting faster, and databases keep getting larger. So as a refinement you could say, display something if a second or more has passed, and don't display anything if it hasn't. We used to use MOD 100, which was fine 20 years ago. Now it spins by so fast you cant read it. -Original Message- From: dennis bartlett dqbartl...@gmail.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 3:16 pm Subject: Re: [U2] READU vs READ I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good hing do help, but I reduced a process scanning 20 million records from 12 ays to 2 days just taking out the CRT to screen informing the user of rogress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the ode as below sits at n,count += 1 f rem(count,2) then CRT n.count:' / ' : tot.count nd On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) roy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Dawn M. Wolthuis Take and give some delight today ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
Hi Laura and Dawn, This reminds me of a program I wrote about 20 years ago for a multilevel marketing company. Its job was to audit a seller's downline, which in many cases ran into thousands or tens of thousands of transactions. For some larger sellers it ran for several minutes. The users insisted on seeing what progress it was making, and settled on a whirly-gig. I explained that it would only slow the process down, but they didn't care. They were quite willing to sacrifice speed for a stupid little character twirling around. Go figure... Regards, Charlie Noah On 05-01-2012 6:41 PM, Dawn Wolthuis wrote: Good story, Laura! We are figuring out where we need animated gifs in a web app to indicate something is happening. They seem mostly unnecessary (with test data, which, granted, might be the reason they seem unnecessary at this point), so we are erring on the side of keeping them out, rather than putting them in. --dawn On Tue, May 1, 2012 at 6:17 PM, Laura Hirshla...@lhirsh.org wrote: Just an interesting piece of history that folks might find amusing. Back in the day, Ultimate had a development project to speed up the basic compiler. Everyone was really anticipating the performance improvements. However, when the new compiler was timed and tested, it didn't produce the expected speed improvements and the developers couldn't find the cause. At the time, Ultimate displayed one asterisk as each line of code was compiled. After much investigation, one of the developers thought to remove the display of the *, and the compiler flew! It was truly amazing - so much so that we didn't think the program compiled at all. The new compiler was finally released as one * for each 10 lines of code. :) -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 6:24 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Computers keep getting faster, and databases keep getting larger. So as a refinement you could say, display something if a second or more has passed, and don't display anything if it hasn't. We used to use MOD 100, which was fine 20 years ago. Now it spins by so fast you cant read it. -Original Message- From: dennis bartlettdqbartl...@gmail.com To: U2 Users Listu2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 3:16 pm Subject: Re: [U2] READU vs READ I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good hing do help, but I reduced a process scanning 20 million records from 12 ays to 2 days just taking out the CRT to screen informing the user of rogress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the ode as below sits at n,count += 1 f rem(count,2) then CRT n.count:' / ' : tot.count nd On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) roy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ and CRT
It's better for peace of mind to know that the computer thinks it's doing something Rather than wondering Is it DOING something -Original Message- From: Dawn Wolthuis dw...@tincat-group.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 5:30 pm Subject: Re: [U2] READU vs READ and CRT Well, I get it even if it seems foolish at first blush -- it's all about he user experience. --dawn On Tue, May 1, 2012 at 7:24 PM, Charlie Noah cwn...@comcast.net wrote: Hi Laura and Dawn, This reminds me of a program I wrote about 20 years ago for a multilevel marketing company. Its job was to audit a seller's downline, which in many cases ran into thousands or tens of thousands of transactions. For some larger sellers it ran for several minutes. The users insisted on seeing what progress it was making, and settled on a whirly-gig. I explained that it would only slow the process down, but they didn't care. They were quite willing to sacrifice speed for a stupid little character twirling around. Go figure... Regards, Charlie Noah On 05-01-2012 6:41 PM, Dawn Wolthuis wrote: Good story, Laura! We are figuring out where we need animated gifs in a web app to indicate something is happening. They seem mostly unnecessary (with test data, which, granted, might be the reason they seem unnecessary at this point), so we are erring on the side of keeping them out, rather than putting them in. --dawn On Tue, May 1, 2012 at 6:17 PM, Laura Hirshla...@lhirsh.org wrote: Just an interesting piece of history that folks might find amusing. Back in the day, Ultimate had a development project to speed up the basic compiler. Everyone was really anticipating the performance improvements. However, when the new compiler was timed and tested, it didn't produce the expected speed improvements and the developers couldn't find the cause. At the time, Ultimate displayed one asterisk as each line of code was compiled. After much investigation, one of the developers thought to remove the display of the *, and the compiler flew! It was truly amazing - so much so that we didn't think the program compiled at all. The new compiler was finally released as one * for each 10 lines of code. :) -Original Message- From: u2-users-bounces@listserver.**u2ug.orgu2-users-boun...@listserver.u2ug.org [mailto:u2-users-bounces@**listserver.u2ug.orgu2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Tuesday, May 01, 2012 6:24 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Computers keep getting faster, and databases keep getting larger. So as a refinement you could say, display something if a second or more has passed, and don't display anything if it hasn't. We used to use MOD 100, which was fine 20 years ago. Now it spins by so fast you cant read it. -Original Message- From: dennis bartlettdqbartl...@gmail.com To: U2 Users Listu2-users@listserver.u2ug.**orgu2-users@listserver.u2ug.org Sent: Tue, May 1, 2012 3:16 pm Subject: Re: [U2] READU vs READ I think you complicating things ... Troy has it right: Sure files could be resized, and code re-engineered, and all these good hing do help, but I reduced a process scanning 20 million records from 12 ays to 2 days just taking out the CRT to screen informing the user of rogress (or lack of progress.) on such a large number I'd set the interval to around 2, so that the ode as below sits at n,count += 1 f rem(count,2) then CRT n.count:' / ' : tot.count nd On 1 May 2012 11:03, Buss, Troy (Contractor, Logitek Systems) roy.b...@nordsonasymtek.com wrote: Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: __** 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users __**_ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users __**_ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users __**_ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/**mailman/listinfo/u2-usershttp://listserver.u2ug.org/mailman/listinfo/u2-users -- awn M. Wolthuis Take and give some delight today __ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http
[U2] READU vs READ
If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 5:32 pm Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, ill a program run significantly faster if I just WRITE it back without ocking it first? I'm updating about 700,000 records and it's just aking TOO long. I DO understand the risks of other users changing the record's content uring so let's not go down that road. I'm interested in the SPEED ialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Understood about the screen I/O ... def not an issue here. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 8:40 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2-Users U2-Users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 5:32 pm Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, ill a program run significantly faster if I just WRITE it back without ocking it first? I'm updating about 700,000 records and it's just aking TOO long. I DO understand the risks of other users changing the record's content uring so let's not go down that road. I'm interested in the SPEED ialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ 2-Users mailing list 2-us...@listserver.u2ug.org ttp://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
It'd be interesting to do a FILE.UGAGE ON, run the program, look at the stats, then do FILE.USAGE OFF. Another thing to look at is LIST.READU EVERY while the program is running. If there appears to be an issue there, increase the lock table sizing parameters in uvconfig. Troy is correct in asking about the select method; no sense in processing the same data multiple times, so that's the first thing to eliminate. The second is file sizing. If you have to follow dozens of links to read write for each record, that consumes a ton of resources. You'll see that in the FILE.USAGE report, or you could just look at ANALYZE.FILE to see if the file is poorly sized. From: troy.b...@nordsonasymtek.com To: u2-users@listserver.u2ug.org Date: Mon, 30 Apr 2012 20:47:59 -0400 Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Good point... For progress indications, I tend to do the following on the mass updates: N.COUNT += 1 IF REM(COUNT, 1000) ELSE CRT +: -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 5:40 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Remove the line that after each read says xxx record written Terminal I/O is 100 times more expensive than reading and writing _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
That is WAY too long. Are your files sized correctly? READ vs READU should not be a resource pig like you are seeing. A little, sure, but not THAT much. Something else is in the mix. John Israel Sent from my iPhone On Apr 30, 2012, at 9:01 PM, Dave Laansma dlaan...@hubbardsupply.com wrote: Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Dave, I tend to cringe when I hear sizable records and updating MV fields. These are red flags. If you don't have the luxury of reconstructing the database then make sure you are using the right UniBasic tools like REMOVE and not FOR...NEXT. David A. Green (480) 813-1725 DAG Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
On 4/30/2012 9:12 PM, Buss, Troy (Contractor, Logitek Systems) wrote: We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. Same here - two years ago we moved from Solaris with dedicated RAID with hardware controller to virtualized RedHat and no hardware RAID, yet improved disk I/O by factor of 2 or more. Ditto on CPU... -- Jeff Butera Hampshire College jbut...@hampshire.edu 413-559-5556 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
By Sizable, are you talking 10k, 50k, 100k, larger? The Seperation would become a huge factor, then. Mark Baldridge wrote some great stuff about Sep in The Hitchhiker's Guide to the UniVerse series a few years back. You wouldn't happen to be on AIX, would you? If so, as root, you could do a truss -pdf pid to see every system call made by the process, along with a time stamp telling you the time delta between each system call. Date: Mon, 30 Apr 2012 21:01:07 -0400 From: dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 8:48 PM To: U2 Users List Subject: Re: [U2] READU vs READ Depends on how much twisted logic you have... Seriously, I would guess that your bottleneck is disk access. Are you using basic SELECT and READNEXT ? Is your list in sorted order (SSELECT) or not (SELECT). Processing the updates in group order will minimize the I/O. I don't think the READU overhead on today's machines are anything that would slow it down. I just tested 100,000 records with and without locking and I get six seconds both ways. Because it was cached data, my test eliminates disk i/o and measures the lock overhead which seems to be negligible on universe 11.1.1. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 5:33 PM To: U2-Users@listserver.u2ug.org Subject: [U2] READU vs READ If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. Thank you folks! Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com http://www.hubbardsupply.com Delivering Products, Services and Innovative Solutions ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
(Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
It's a dynamic file. FILE-STAT shows no overflow. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 9:12 PM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
I learned terminal I/O problems last millennium. Unfortunately I wrote neither the code nor did I design the files. I just want to speed the silly thing up. It also appears that each record is getting several MVs added, so each record is effectively getting larger with each WRITE ... yea ... :-/ ... it must have seemed like a good idea at the time. (My apologies for whining) Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, April 30, 2012 9:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ (Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
Oh ... you're good ... I ALMOST pasted it ... I know better that to put even FICTITIOUS code on this board ... unless I'm just trying to rile things up about the OS. |-) I do appreciate all of the input. Thank y'all for the info. I'll see what I can do. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Monday, April 30, 2012 9:47 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ why not post the relevant code you are using to do the field updates perhaps we can see some inefficiency in the way you're grabbing and updating fields you said the records were sizeable and that raises my eyebrow (just one) -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 6:38 pm Subject: Re: [U2] READU vs READ No indexes and no triggers. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Gregor Scott Sent: Monday, April 30, 2012 9:22 PM To: U2 Users List Subject: Re: [U2] READU vs READ Add to the mix indexes and triggers. They can both add to the time needed to update just one record. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Tuesday, 1 May 2012 11:12 AM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Message protected by DealerGuard: e-mail anti-virus, anti-spam and content filtering. http://www.pentanasolutions.com Click here to report this message as spam: https://login.mailguard.com.au/report/1EE0zigg55/70gcZxRJUITQXy3UHcVFYT/ 0.002 This email and any attachments to it are confidential. You must not use, disclose or act on the email if you are not the intended recipient. Liability limited by a scheme approved under Professional Standards Legislation. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman
Re: [U2] READU vs READ
Well, that'll affect performance somewhat. If you're splitting on a high percentage of writes, that's a lot of expensive overhead. You also (unless someone changed it in the past couple of years) have to lock the header of the file when you do a split. But at least you're not following overflow chains out into West Jibip. The disks/file systems you're writing to aren't more than 85% full? Attaching new disk pages to the dynamic file as it grows can be a bottleneck in that scenario... Date: Mon, 30 Apr 2012 21:35:47 -0400 From: dlaan...@hubbardsupply.com To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ It's a dynamic file. FILE-STAT shows no overflow. Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Contractor, Logitek Systems) Sent: Monday, April 30, 2012 9:12 PM To: U2 Users List Subject: Re: [U2] READU vs READ Inefficient file sizing and disk I/O are your possible issues with slowness. You might be able to address the first at your desk, the latter may require a purchase order. How old is your hardware? We recently upgraded to a virtual server and just using more current technology hard drives we doubled all of our disk I/O from what we had 5 or 6 years ago. CPU speed increased as well, but that was not as suprising. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma Sent: Monday, April 30, 2012 6:01 PM To: U2 Users List Subject: Re: [U2] READU vs READ Yes, using SELECT and READNEXT. These are sizable records. The logic is very straight forward, just updating several multi-valued fields in each record (month end). 500,000 have been updated and I'm 2:45:00 into the process. _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com This email is intended only for the use of the party to which it is addressed and may contain information that is privileged, confidential, or protected by law. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of the email or its contents is strictly prohibited. If you have received this message in error, please notify us immediately, by replying to the message and deleting it from your computer. WARNING: Internet communications are not assured to be secure or clear of inaccuracies as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this email, or any attachment, that have arisen as a result of e-mail transmission. _ ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] READU vs READ
You can put earrings on a pig, but it only makes the pig unhappy -Original Message- From: Dave Laansma dlaan...@hubbardsupply.com To: U2 Users List u2-users@listserver.u2ug.org Sent: Mon, Apr 30, 2012 8:09 pm Subject: Re: [U2] READU vs READ I learned terminal I/O problems last millennium. Unfortunately I wrote neither the code nor did I design the files. I just want to speed the silly thing up. It also appears that each record is getting several MVs added, so each record is effectively getting larger with each WRITE ... yea ... :-/ ... it must have seemed like a good idea at the time. (My apologies for whining) Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com Delivering Products, Services and Innovative Solutions -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Monday, April 30, 2012 9:22 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] READU vs READ (Saw other responses come in as I was writing this - oh well, this might help someone else...) From: Dave Laansma If I don't HAVE TO lock a record before modifying it writing it back, will a program run significantly faster if I just WRITE it back without locking it first? I'm updating about 700,000 records and it's just taking TOO long. I DO understand the risks of other users changing the record's content during so let's not go down that road. I'm interested in the SPEED dialog. I don't know what you meant by SPEED dialog but if WJ is right and you're displaying an item count as you run through records, then he is also right that that IO will destroy performance. Try this as related experiment: Loop to display the numbers 1 through 1 million. Watch it stream on your terminal emulator. Now run it again, minimize the emulator, then re-normalize it. I believe you will find that while the output was hidden it streamed through most or all of the output. Same thing happens if you're doing a copy or delete and tapping your fingers as you wait for the IDs to stream by - a watched kettle takes longer to boil... :) About READU vs READ... You're doing a READU just because you're doing a WRITE? Nah, if you don't care about contentions don't bother to ReadU. You're reading and updating lock tables and semaphors with READU and that's huge performance hit. Here's another experiment: When you're copying or restoring items, use the appropriate option to overlay items, even if you know the target file is empty. Why? Because Copy needs to do a Read first to see if it needs to warn you about an existing item. If you tell it to overlay it will just do the Write (sure, there's a lower level read there anyway but less code is executed). Combining these... if you use a Copy (Pick flavor, don't recall options otherwise) with both overlay and ID suppress, it avoids a ton of internal DBMS code, so it goes a lot faster than a no-option copy. I haven't benched those scenarios for years. If anyone does the tests, please let us know if this is valid or not, and your DBMS/flavors. T ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
