RE: [U2] Unidata TCL - beginner question
See UDT.OPTIONS 43. The udto.pdf explains what this is doing. The file isn't too large - UniData just doesn't like displaying valid values in a detail suppress report that you don't break-on. hth Colin Alfke Calgary Canada From: Bruce Ordway SORT filename BY Part BY Date @ID BREAK.ON Part Date DET.SUP BTW, I thought this worked to begin with. Then, I started noticing it wasn't really. I keep getting dates in the middle of the range for some parts. Just so happens I'm working on a huge file, 886817 records. I wonder if Unidata SORT's break down if a file is too big or sized incorrectly? [demime 1.01d removed an attachment of type application/ms-tnef which had a name of winmail.dat] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Senior Pick Programming Position - Centennial, CO
It's something that good programmers are going to write tomorrow... On 10/7/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: Debster [EMAIL PROTECTED] Something most programmers hate to write --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OPEN vs TRANS
Yep, I've recently went on several site visits to other Law Firms running two different billing packages on SQL Server. All 6 had converted from a UniVerse system running on HP-UX. All 6 mentioned the letdown of running a large query against their spanking new uber machines only to find they had a significant performance lag when compared to the ancient HP-UX machines running a very well designed UniVerse application. In the Oracle, SQL server, arena, performance problems are solved with the check book and more/faster hardware. On 10/7/05, Dan Fitzgerald [EMAIL PROTECTED] wrote: Amen. Allow me to add that often the decision to replace an MV database with an RDBMS hinges on, what do you mean I need 5 times as much hardware/horsepower to run Oracle?. Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them? - H.H. the Dalai Lama When buying selling are controlled by legislation, the first thing to be bought sold are the legislators - P.J. O'Rourke Dan Fitzgerald From: Timothy Snyder [EMAIL PROTECTED] Reply-To: u2-users@listserver.u2ug.org To: u2-users@listserver.u2ug.org Subject: RE: [U2] OPEN vs TRANS Date: Fri, 7 Oct 2005 17:21:28 -0400 Allen E. Elwood [EMAIL PROTECTED] wrote on 10/07/2005 12:53:47 PM: The way I look at it, when I started programming 30 years ago systems were millions of times slower, and in another 30 years they'll be so stinking fast that coding for speed will go the way of the Suchomimus and the Iguanodon! As long as programmers think that way, their employers will continue to pay people like me big bucks to come in and make the code more efficient. ;-) Sometimes more powerful systems can make bottlenecks more prominent. Today's systems are expected to process more data in a shorter time, and to provide more functionality than in days of yore, so even minor inefficiencies are encountered over and over again. IMHO, there will always be room for efficient coding techniques. Some folks claim you have to sacrifice maintainability and readability for the sake of efficiency - I've rarely found that to be true. As long as you care about and consider both performance and maintainability as you develop code, it all just falls together. Now, as to people who want to code one line instead of two (e.g.: the topic of this thread), I say take a touch typing course so you don't mind a few extra keystrokes. (I've always been amazed watching seasoned professionals using only one finger on each hand to write programs.) I would much rather inherit a program that does its own opens and reads instead of doing translates. Sooner or later somebody will want to get a second field from the record and you'll be faced with doing two translates or changing it to the way it should have been done in the first place. Plus, the OCONV with a translate isn't nearly as obvious to the casual observer of the code. Of course, you could put in some comments to make it clear, but those keystrokes could have been spent opening the file at the top of the program. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Senior Pick Programming Position - Centennial, CO
I did the documentation for the Forecasting interface to Demand Solutions I wrote while at ROI Systems and it was done so well that last I heard they were still using it as the standard to maintain when teaching others how to document. Very professional, every stinking sentence in third person. Took a long time to get just right. But the only reason it got done at all was because there were no requests for custom code at the time (2001-ish), and people were searching for something to do just to avoid the boredom of playing solitaire all day. On the other hand, the documentation for the hazardous materials bill of lading I wrote was Use standard procedures to operate. Nobody is perfect. 'specially me :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Don Kibbey Sent: Sunday, October 09, 2005 14:40 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Senior Pick Programming Position - Centennial, CO It's something that good programmers are going to write tomorrow... On 10/7/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: Debster [EMAIL PROTECTED] Something most programmers hate to write --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Fw: More U2 programming hints
I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to approximately the same as EXECUTE SELECT..., but not make it slower. Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a $include file common to every program? I wrote a conversion program to change ALL BASIC SELECTs to executed SELECTs in the source and recompiled and that is the way we have done it ever since. I don't know if things are different now but we have grown to prefer EXECUTEd selects as selection criteria can be included. Louis, can you run a simple benchmark and see if this is still true? Or show us an example of your own? INTERNAL: OPEN [really big file] TO F ELSE STOP CRT 'I1', TIMEDATE(), SYSTEM(9) SELECT F CRT 'I2', TIMEDATE(), SYSTEM(9) LOOP WHILE READNEXT ID READ REC FROM F, ID ELSE NULL REPEAT CRT 'I3', TIMEDATE(), SYSTEM(9) EXECUTED: OPEN [really big file] TO F ELSE STOP CRT 'E1', TIMEDATE(), SYSTEM(9) EXECUTE SELECT [really big file] CRT 'E2', TIMEDATE(), SYSTEM(9) LOOP WHILE READNEXT ID READ REC FROM F, ID ELSE NULL REPEAT CRT 'E3', TIMEDATE(), SYSTEM(9) (Run each a couple times, to allow for i/o differences in loading data buffer cache.) There should be virtually no elapsed time between I1:I2 above, but long elapsed time between E1:E2. I expect I2:I3 to approximately equal E2:E3. Let me explain why this is counter-intuitive. Normally, the BASIC SELECT statement itself does not actually do any select on the file. It merely sets
RE: [U2] Fw: More U2 programming hints
That's ridiculous. How is a BASIC select any different from a EXECUTE select in this regard ? When you do an EXECUTE SELECT ... a select list is built. As you process this list, records could be added that will not appear in the list. Conversely, records that have been selected could be deleted and no longer exist when the list is processed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos Sent: Sunday, October 09, 2005 08:26 PM To: u2-users@listserver.u2ug.org Subject: [U2] Fw: More U2 programming hints I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to approximately the same as EXECUTE SELECT..., but not make it slower. Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a $include file common to every program? I wrote a conversion program to change ALL BASIC SELECTs to executed SELECTs in the source and recompiled and that is the way we have done it ever since. I don't know if things are different now but we have grown to prefer EXECUTEd selects as selection criteria can be included. Louis, can you run a simple benchmark and see if this is still true? Or show us an example of your own? INTERNAL: OPEN [really big file] TO F ELSE STOP CRT 'I1', TIMEDATE(), SYSTEM(9) SELECT F CRT 'I2', TIMEDATE(), SYSTEM(9) LOOP WHILE READNEXT ID READ REC FROM F, ID ELSE NULL REPEAT CRT 'I3', TIMEDATE(), SYSTEM(9) EXECUTED: OPEN [really big file] TO F ELSE STOP CRT 'E1', TIMEDATE(), SYSTEM(9) EXECUTE SELECT [really big file]
Re: [U2] Fw: More U2 programming hints
Goo'day, At 10:25 10/10/05 +1000, you wrote: I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. The major thing that one should be aware of using an EXECUTEd SELECT filename versus BASIC SELECT is that SELECT filename goes off and selects a finite number of records from the file BEFORE PROCESSING STARTS and works only with that list during processing, whereas a BASIC SELECT gets a group at a time from the file whilst processing.The latter (BASIC SELECT) can cause problems if, as a result of your processing, you're writing NEW records back to the file, or writing the same record back with a new @ID, and you're writing them into groups the BASIC SELECT has yet to process... They'll get picked up and processed with the rest of the group as if they were there all the time. If that happens to you, then the least important thing you're concerned about is speed.. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to approximately the same as EXECUTE SELECT..., but not make it slower. Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a $include file common to every program? I wrote a conversion program to change ALL BASIC SELECTs to executed SELECTs in the source and recompiled and that is the way we have done it ever since. I don't know if things are different now but we have grown to prefer EXECUTEd selects as selection criteria can be included. Louis, can you run a simple benchmark and see if this is still true? Or show us an example of your own? INTERNAL: OPEN [really big file] TO F ELSE STOP CRT 'I1', TIMEDATE(), SYSTEM(9) SELECT F CRT 'I2', TIMEDATE(), SYSTEM(9)
Re: [U2] Fw: More U2 programming hints
I disagree with BASIC SELECT being the only one susceptible to this situation. I've gotta believe that using an EXECUTE SELECT, the processor could be past groups being currently updated. It affects both. My 1 cent. Mark Johnson - Original Message - From: Jeff Marcos [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 09, 2005 8:25 PM Subject: [U2] Fw: More U2 programming hints I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to approximately the same as EXECUTE SELECT..., but not make it slower. Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a $include file common to every program? I wrote a conversion program to change ALL BASIC SELECTs to executed SELECTs in the source and recompiled and that is the way we have done it ever since. I don't know if things are different now but we have grown to prefer EXECUTEd selects as selection criteria can be included. Louis, can you run a simple benchmark and see if this is still true? Or show us an example of your own? INTERNAL: OPEN [really big file] TO F ELSE STOP CRT 'I1', TIMEDATE(), SYSTEM(9) SELECT F CRT 'I2', TIMEDATE(), SYSTEM(9) LOOP WHILE READNEXT ID READ REC FROM F, ID ELSE NULL REPEAT CRT 'I3', TIMEDATE(), SYSTEM(9) EXECUTED: OPEN [really big file] TO F ELSE STOP CRT 'E1', TIMEDATE(), SYSTEM(9) EXECUTE SELECT [really big file] CRT 'E2', TIMEDATE(), SYSTEM(9) LOOP WHILE READNEXT ID
Re: [U2] Fw: More U2 programming hints
I've run into that scenario before and choose to use EXECUTE SELECT to lock-and-load the active list. It only comes up when writing new records that hash later in the same file (non-predictable). 99% of the time the beginning to end SELECT is to summarize or analyze something. The other 1% should be regarded as well. My 1 cent. - Original Message - From: Bruce Nichol [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 09, 2005 10:04 PM Subject: Re: [U2] Fw: More U2 programming hints Goo'day, At 10:25 10/10/05 +1000, you wrote: I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. The major thing that one should be aware of using an EXECUTEd SELECT filename versus BASIC SELECT is that SELECT filename goes off and selects a finite number of records from the file BEFORE PROCESSING STARTS and works only with that list during processing, whereas a BASIC SELECT gets a group at a time from the file whilst processing.The latter (BASIC SELECT) can cause problems if, as a result of your processing, you're writing NEW records back to the file, or writing the same record back with a new @ID, and you're writing them into groups the BASIC SELECT has yet to process... They'll get picked up and processed with the rest of the group as if they were there all the time. If that happens to you, then the least important thing you're concerned about is speed.. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to
Re: [U2] Fw: More U2 programming hints
Are you asking if there's a difference between a BASIC SELECT and an EXECUTE SELECT? I don't want to answer the wrong question. But I and others have the answer if it's this one. I guess this diverts the question of how to best protect the intregrity of the entire file when processing the entire file for the possiblilites of additions or deletions. Neither BASIC SELECT or EXECUTE SELECT is a clear cut winner. I don't know enough about FILE.LOCK but it sounds likely. My 1 cent. - Original Message - From: gerry-u2ug [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 09, 2005 9:39 PM Subject: RE: [U2] Fw: More U2 programming hints That's ridiculous. How is a BASIC select any different from a EXECUTE select in this regard ? When you do an EXECUTE SELECT ... a select list is built. As you process this list, records could be added that will not appear in the list. Conversely, records that have been selected could be deleted and no longer exist when the list is processed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos Sent: Sunday, October 09, 2005 08:26 PM To: u2-users@listserver.u2ug.org Subject: [U2] Fw: More U2 programming hints I must agree that a BASIC SELECT is quicker but... Don't you run the risk of missing groups (in the read function) in this type of select? If users are updating this file they could insert data into a group which you may already passed. You would only use this type of select when no one is updating this file. Regards, Jeff Marcos -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Johnson Sent: Thursday, 6 October 2005 10:26 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I can't see how a BASIC SELECT can be slower than EXECUTE SELECT. It doesn't have to go through to get 'xxx items selected' before it processes the first one. I also don't believe the mechanical difference once it begins, ie 'find the next group' etc. Wouldn't you think that this at least spares the actual hashing as it is navigating through the file sequentially. I would really like to see a great proof program against BASIC SELECT. I often replace EXECUTE SELECT with a BASIC SELECT over the years *because* it has always ran faster, regardless of platform. I've had many opportunities to be proven wrong. I've tested every replacement and have always reported an improvement. Thanks. MarkJohnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, October 04, 2005 5:45 PM Subject: RE: [U2] Fw: More U2 programming hints This is the way it was explained to me way back in '88. The internal select is slower on the whole file, but immediate in response. It works the same as LIST. If I list a file with 2,000,000 records I get immediate response. If I want to process an entire file, then external select is slower on response, i.e. I have to wait for 2 million records to be selected before processing begins, but is quicker in processing all records. The internal is slower due to the system having to stop what it's doing, find the next group, break out the individual ID's from that group, and then return it to the program - over and over again as it makes it's way through the file. hth! Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Tuesday, October 04, 2005 14:24 To: u2-users@listserver.u2ug.org Cc: Louis Windsor Subject: RE: [U2] Fw: More U2 programming hints This is a bit disconcerting. BASIC SELECT should be faster than EXECUTE SELECT... Maybe the smart people can weigh in on this: From: Louis Windsor A few years ago we used the BASIC SELECT FILE as opposed to the EXECUTE SELECT FILE. We updated UniVerse (don't ask from what version to what version as I don't remember) and overnight ALL our programs ran five or six times longer. Completely contrary to my experience and counter-intuitive, too. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. Hmmm, do I vaguely, hazily remember something about that? Maybe on this list? Maybe in release notes? No uvconfig option jumps out at me. I don't think flavor would matter, or $OPTIONS [-]VAR.SELECT. $OPTIONS FSELECT would slow the BASIC SELECT down to approximately the same as EXECUTE SELECT..., but not make it slower. Louis, do you, perchance, use $OPTIONS FSELECT? Maybe buried in a $include file common to every program? I wrote a conversion program to change ALL BASIC SELECTs to executed
RE: [U2] OPEN vs TRANS
Vectoring (is 'vector' a verb?) is built into TRANS already. No need to abandon in favour of OCONVS T-correlative. You can specify a dynamic array of IDs for the target file to read. I have used the Translate code with OCONVS() function when it is stylistically in keeping with the use of vector functions around it and only because there isn't a vector version of TRANS(), but personally I wouldn't use it outside of that situation. custProductIDs = splice(reuse(custId),'*',productIds) instead of / as well as this: prices = oconvs(custProductIDs,'TCUST.PRODUCT;X;;99') this works fine (even better I think): prices = TRANS( 'CUST.PRODUCT', custProductIDs, 99, 'X' ) But a caution: If CUST.PRODUCT 99 is multivalued /or sub-valued: * T-correlative converts all delimiters to spaces when OCONVS returns. (consistent with PICK.) * TRANS will lower the returned delimiters. (almost consistent with PI.) - if called from Retrieve, the delimiters are lowered enough to keep the association with the dict equivalent of custProductIDs which might be multi-SUB-valued or even have TMs or lower. - if called from Basic, not that smart, just lowered once, so you might lose the association with custProductIDs. The above for UV. Mileage for UD may vary. cds --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
