RE: [U2] Fw: More U2 programming hints
I wasn't asking anything. I was making a statement regarding the previous post. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Sunday, October 09, 2005 10:32 PM To: u2-users@listserver.u2ug.org Subject: 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
RE: [U2] Fw: More U2 programming hints
I have usually used a BASIC SELECT within a routine that is grabbing a very large file during something akin to a overnight/day-end routine where end-users are not likely to be on the system, or the file is simply utilized to retain daily processing keys to overnight updating (i.e. a temp file to retain invoice keys), or off a list that was created within another process, especially when the same keys are for multi files (i.e history, active files). This is especially useful when if you were to attempt to select a large file that may cause you to wait until next shrove tuesday to be able to process ityech...index it, or something! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Marcos Sent: Sunday, October 09, 2005 8: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
[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
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] 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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE, (next meaning as stored on disk). UV keeps track of where it is in the file, unbeknownst to you. Sorta like it keeps track of where it is for REMOVE or attribute-level EXTRACTs. Exceptions to internal being faster than executed: 1.SSELECT FILEVAR (i.e., 2 S's, SortSelect). You gotta read the whole file First to sort the keys. (and it's an alpha-type sort, even for numeric keys.) 2. $OPTIONS FESLECT Makes SELECT FILEVAR populate @SELECTED and to do so means traversing the file. 3. Louis Windsor. Poor bloke, they're out to get him. Chuck Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please
Re: [U2] Fw: More U2 programming hints
I'll add another observation. One file on a client's system (D3, proper mod) contains over 7 million records. It's 1.25 GB. The client wanted to know what the oldest record was. I don't dare SORT BY DATE so I wrote a small basic program to BASIC SELECT and keep the lowest number date field. Out of pure habit I used BASIC SELECT as I know that at TCL a COUNT of this file takes around 20 minutes. So I can imagine a EXECUTE SELECT would have to wait at least 20 minutes before evaluating the first record. I don't know everything about select buffers, but something tells me that the 20 minutes (from COUNT) would be much longer as it has to prepare the active list of 7 million elements. As before, I can't imagine the EXECUTE SELECT making up for the lost time going through the file from beginning to end *and* preparing an isolated entity (active list) to READNEXT from. Please no flames on my exposed word called 'habit'. We all have habits, both good and bad and only when proven that my habits are bad can I consider changing them. Actual proof, not guesses and/or first-training. Thanks Mark Johnson - 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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE, (next meaning as stored on disk). UV keeps track of where it is in the file, unbeknownst to you. Sorta like it keeps track of where it is for REMOVE or attribute-level EXTRACTs. Exceptions to internal being faster than executed: 1.SSELECT FILEVAR (i.e
RE: [U2] Fw: More U2 programming hints
You could always build an index by date. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, October 06, 2005 7:36 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I'll add another observation. One file on a client's system (D3, proper mod) contains over 7 million records. It's 1.25 GB. The client wanted to know what the oldest record was. I don't dare SORT BY DATE so I wrote a small basic program to BASIC SELECT and keep the lowest number date field. Out of pure habit I used BASIC SELECT as I know that at TCL a COUNT of this file takes around 20 minutes. So I can imagine a EXECUTE SELECT would have to wait at least 20 minutes before evaluating the first record. I don't know everything about select buffers, but something tells me that the 20 minutes (from COUNT) would be much longer as it has to prepare the active list of 7 million elements. As before, I can't imagine the EXECUTE SELECT making up for the lost time going through the file from beginning to end *and* preparing an isolated entity (active list) to READNEXT from. Please no flames on my exposed word called 'habit'. We all have habits, both good and bad and only when proven that my habits are bad can I consider changing them. Actual proof, not guesses and/or first-training. Thanks Mark Johnson - 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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE
Re: [U2] Fw: More U2 programming hints
It was a one-shot request. Building the index would take more time than the current process. If the request for dating the data were there, that approach would be used. Thanks - Original Message - From: Baakkonen, Rodney [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, October 06, 2005 9:05 AM Subject: RE: [U2] Fw: More U2 programming hints You could always build an index by date. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Thursday, October 06, 2005 7:36 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Fw: More U2 programming hints I'll add another observation. One file on a client's system (D3, proper mod) contains over 7 million records. It's 1.25 GB. The client wanted to know what the oldest record was. I don't dare SORT BY DATE so I wrote a small basic program to BASIC SELECT and keep the lowest number date field. Out of pure habit I used BASIC SELECT as I know that at TCL a COUNT of this file takes around 20 minutes. So I can imagine a EXECUTE SELECT would have to wait at least 20 minutes before evaluating the first record. I don't know everything about select buffers, but something tells me that the 20 minutes (from COUNT) would be much longer as it has to prepare the active list of 7 million elements. As before, I can't imagine the EXECUTE SELECT making up for the lost time going through the file from beginning to end *and* preparing an isolated entity (active list) to READNEXT from. Please no flames on my exposed word called 'habit'. We all have habits, both good and bad and only when proven that my habits are bad can I consider changing them. Actual proof, not guesses and/or first-training. Thanks Mark Johnson - 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] 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
RE: [U2] Fw: More U2 programming hints
Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: Tuesday, October 04, 2005 2:45 PM To: u2-users@listserver.u2ug.org 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. Yes, well that *was* back in '88. :) Actually, I've no idea what UV does; there are many things which were implemented differently from Pr1me INFORMATION, or not at all. But IIRC, the issue above was addressed by pre-fetching the next group while processing the current one, so that processing and I/O overlap. With the right tuning, it would be significantly faster than processing after an external SELECT. -Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Fw: More U2 programming hints
Well, only testing would reveal that. Anything else is just speculation that it's better now. My last testing of GOTO's revealed they are still slower than GOSUB's and this was last year. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith W. Roberts Sent: Wednesday, October 05, 2005 09:42 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Fw: More U2 programming hints Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. Elwood Sent: Tuesday, October 04, 2005 2:45 PM To: u2-users@listserver.u2ug.org 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. Yes, well that *was* back in '88. :) Actually, I've no idea what UV does; there are many things which were implemented differently from Pr1me INFORMATION, or not at all. But IIRC, the issue above was addressed by pre-fetching the next group while processing the current one, so that processing and I/O overlap. With the right tuning, it would be significantly faster than processing after an external SELECT. -Keith --- 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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE, (next meaning as stored on disk). UV keeps track of where it is in the file, unbeknownst to you. Sorta like it keeps track of where it is for REMOVE or attribute-level EXTRACTs. Exceptions to internal being faster than executed: 1.SSELECT FILEVAR (i.e., 2 S's, SortSelect). You gotta read the whole file First to sort the keys. (and it's an alpha-type sort, even for numeric keys.) 2. $OPTIONS FESLECT Makes SELECT FILEVAR populate @SELECTED and to do so means traversing the file. 3. Louis Windsor. Poor bloke, they're out to get him. Chuck Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE, (next meaning as stored on disk). UV keeps track of where it is in the file, unbeknownst to you. Sorta like it keeps track of where it is for REMOVE or attribute-level EXTRACTs. Exceptions to internal being faster than executed: 1.SSELECT FILEVAR (i.e., 2 S's, SortSelect). You gotta read the whole file First to sort the keys. (and it's an alpha-type sort, even for numeric keys.) 2. $OPTIONS FESLECT Makes SELECT FILEVAR populate @SELECTED and to do so means traversing the file. 3. Louis Windsor. Poor bloke, they're out to get him. Chuck Stevenson --- 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] Fw: More U2 programming hints
But... using an external select then reading in the records means grabbing the records from disk or cache twice. Like most things, it's a judgement call. Are you going to select the entire file and evaluate each record in basic? No brainer; use an internal select. Sre you sorting? then maybe the external select makes sense. Selecting a subset for processing? hmm... the next question I'd ask is, can I use an index?. Yes? External select. No? Internal. If it's a big enough file relative to my box size, and I need to sort a subset, I might even build a temp file populate it. SSELECT'ing 800Mb versus doing an internal select then sorting the 2Mb I actually need? I might go for choice # 2. Unlike the 4-letter word which we shall not mention here, this is a situational call. I did, however, agree with the notion that it's ok to allow programmers to use the 4-letter word when the power is out, but only then. 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: Allen E. Elwood [EMAIL PROTECTED] Reply-To: u2-users@listserver.u2ug.org To: u2-users@listserver.u2ug.org Subject: RE: [U2] Fw: More U2 programming hints Date: Tue, 4 Oct 2005 14:45:04 -0700 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] 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 things up behind the scenes so that subsequent READNEXTs each get the next id from the file opened to F.FILE, (next meaning as stored on disk). UV keeps track of where it is in the file, unbeknownst to you. Sorta like it keeps track of where it is for REMOVE or attribute-level EXTRACTs. Exceptions to internal being
RE: [U2] Fw: More U2 programming hints
... the next question I'd ask is, can I use an index?. Yes? External select. No? Internal. or use the basic SELECTINDEX statement. Stuart ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (+61 3 9269 7555) immediately, who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer related viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Fw: More U2 programming hints
At the risk of being verbose, this topic is near and dear to me based on the sheer volume of programs and styles I've observed in my many years of MV. While many may offer positive suggestions, I'm sure I'm not alone in offering up code snippets that should be avoided. Remember, nothing is completely useless. It can always serve as a bad example. 1. use spaces after commas in file I/O statements and subroutine parameter lists. especially when so many variables have periods and/or underscores. The white space helps a lot. 2. don't use L#10 as the space after the 10 is easily lost and not mentally counted when formatting output. 3. I don't care for IF CONDITION ELSE statement. 99% of IF's are THEN-oriented and sometimes these get overlooked. Use IF NOT(CONDITION) THEN 4. I don't care for consecutive OPEN FILE THEN's with the ELSEs at the end of the program. 5. I don't care for having the NEXT I's or REPEATs hundreds of lines from their starting partners. 3. Use spaces with semi-colons to separate multiple statements on one line. 3. Use common sense when using internal SELECT and CLEARFILE statements. A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. B: If opened, don't use EXECUTE CLEARFILE (DATA FILE, use CLEARFILE 4. If you have the luxury of starting a new system or module, put all 3 components of handling the data files in one INCLUDE: A: OPEN FILE to CONSISTENT.FILE.HANDLE else stop B: DIM CUST(100) for this file C: EQUATE CUST.NAME TO CUST(1) EQUATE CUST.ADDR TO CUST(2) 5. If you like using variables as attribute number references, put them in an equate to be consistent as well. 5. Have an INCLUDE that contains all of the necessary housekeeping stuff. 6. Comments are very nice. 7. Revision control using date suffixes instead of dotNEW, dotOLD, TEMP, HOLD, BKUP, BU etc. 8. Don't use reserved words as variable names, ie COUNT, DATE, PRINT, INDEX, FIELD etc. While these and others are all good suggestions, certainly someone's good suggestion is someone else's caveat and vice versa. If we were to publish a composite of those items that are 100% agreed upon, it would be a very short document. Many of us have seen atrocious code in our travels. This guides us to our personal 'standards' of today. Yet those persons writing this atrocious code may not know there's a better way. I run into some of these guys who defend their poor habits with That's the way I've always done it mentality. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Fw: More U2 programming hints
Mark Johnson wrote: A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. Only one problem: the internal select doesn't sort. It returns records by their physical location in the file (ie by group). So, until an intrinsic SSELECT verb is introduced to basic, PERFORM SSELECT ... will continue to be used. Larry Hiscock Western Computer Services --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Fw: More U2 programming hints
My A-Z meant from the beginning of the file to the end, not sorted, merely to go through the entire file, a-z. - Original Message - From: Larry Hiscock [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Saturday, October 01, 2005 12:20 PM Subject: RE: [U2] Fw: More U2 programming hints Mark Johnson wrote: A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. Only one problem: the internal select doesn't sort. It returns records by their physical location in the file (ie by group). So, until an intrinsic SSELECT verb is introduced to basic, PERFORM SSELECT ... will continue to be used. Larry Hiscock Western Computer Services --- 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] Fw: More U2 programming hints
yeahbut: basic's SSELECT does an alpha sort, even if keys are numeric. i.e.: 1,10,100,11,2 instead of 1,2,10,11,100. And the important gains for basic SELECT filevar over EXECUTE SELECT filename... are lost, (namely traversing the file only once), since the file needs to be entirely traversed to do the initial sort. cds From: gerry-u2ug in universe there is an sselect basic command -Original Message- From: Larry Hiscock Mark Johnson wrote: A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. Only one problem: the internal select doesn't sort. It returns records by their physical location in the file (ie by group). So, until an intrinsic SSELECT verb is introduced to basic, PERFORM SSELECT ... will continue to be used. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Fw: More U2 programming hints
Here's what i meant initially and apologize for stating it ambiguously. Ineffecient: OPEN FILE TO F.FILE ELSE STOP EXECUTE SELECT FILE LOOP READNEXT... More effecient OPEN FILE TO F.FILE ELSE STOP SELECT F.FILE LOOP READNEXT... I try not to get code-y in examples but this should clear it up. Likewise Extraneous OPEN FILE TO F.FILE ELSE STOP EXECUTE CLEAR-FILE (DATA FILE more effecient: OPEN FILE TO F.FILE ELSE STOP CLEARFILE F.FILE Mark Johnson - Original Message - From: Stevenson, Charles [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Saturday, October 01, 2005 3:33 PM Subject: RE: [U2] Fw: More U2 programming hints yeahbut: basic's SSELECT does an alpha sort, even if keys are numeric. i.e.: 1,10,100,11,2 instead of 1,2,10,11,100. And the important gains for basic SELECT filevar over EXECUTE SELECT filename... are lost, (namely traversing the file only once), since the file needs to be entirely traversed to do the initial sort. cds From: gerry-u2ug in universe there is an sselect basic command -Original Message- From: Larry Hiscock Mark Johnson wrote: A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. Only one problem: the internal select doesn't sort. It returns records by their physical location in the file (ie by group). So, until an intrinsic SSELECT verb is introduced to basic, PERFORM SSELECT ... will continue to be used. --- 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] Fw: More U2 programming hints
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. We were told (by VMark) that the BASIC SELECT now selected each group but it could be optioned to work the old way. 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. My 2c worth. Louis - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 02, 2005 3:50 AM Subject: Re: [U2] Fw: More U2 programming hints : Here's what i meant initially and apologize for stating it ambiguously. : : Ineffecient: : OPEN FILE TO F.FILE ELSE STOP : EXECUTE SELECT FILE : LOOP READNEXT... : : More effecient : OPEN FILE TO F.FILE ELSE STOP : SELECT F.FILE : LOOP READNEXT... : : I try not to get code-y in examples but this should clear it up. : : Likewise : Extraneous : OPEN FILE TO F.FILE ELSE STOP : EXECUTE CLEAR-FILE (DATA FILE : : more effecient: : OPEN FILE TO F.FILE ELSE STOP : CLEARFILE F.FILE : : Mark Johnson : - Original Message - : From: Stevenson, Charles [EMAIL PROTECTED] : To: u2-users@listserver.u2ug.org : Sent: Saturday, October 01, 2005 3:33 PM : Subject: RE: [U2] Fw: More U2 programming hints : : : yeahbut: basic's SSELECT does an alpha sort, even if keys are numeric. : i.e.: 1,10,100,11,2 instead of 1,2,10,11,100. : : And the important gains for basic SELECT filevar over EXECUTE SELECT : filename... are lost, (namely traversing the file only once), since the : file needs to be entirely traversed to do the initial sort. : : cds : : From: gerry-u2ug : in universe there is an sselect basic command : : -Original Message- : From: Larry Hiscock : : Mark Johnson wrote: : :A: If opened and an A-Z select is desired, don't EXECUTE :SELECT FILE :then READNEXT, use SELECT. : : Only one problem: the internal select doesn't sort. It : returns records by their physical location in the file (ie by : group). So, until an intrinsic SSELECT verb is introduced to : basic, PERFORM SSELECT ... will continue to be used. : --- : 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] Fw: More U2 programming hints
true , but that wasn't the question - until an intrinsic SSELECT verb is introduced to basic -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Stevenson, Charles Sent: Saturday, October 01, 2005 03:33 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Fw: More U2 programming hints yeahbut: basic's SSELECT does an alpha sort, even if keys are numeric. i.e.: 1,10,100,11,2 instead of 1,2,10,11,100. And the important gains for basic SELECT filevar over EXECUTE SELECT filename... are lost, (namely traversing the file only once), since the file needs to be entirely traversed to do the initial sort. cds From: gerry-u2ug in universe there is an sselect basic command -Original Message- From: Larry Hiscock Mark Johnson wrote: A: If opened and an A-Z select is desired, don't EXECUTE SELECT FILE then READNEXT, use SELECT. Only one problem: the internal select doesn't sort. It returns records by their physical location in the file (ie by group). So, until an intrinsic SSELECT verb is introduced to basic, PERFORM SSELECT ... will continue to be used. --- 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/
