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: 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 an
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: 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: > > 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 > > > >
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: 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: > > 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 us
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: 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: > > > >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: [EMAI
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: 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: > > 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
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: 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 > > execute
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: 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 r
[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: 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(), SYST
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: 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: > 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. > > > > >
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: 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 READN
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: 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 ti
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: 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
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
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
> ... 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/
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: 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
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
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
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/
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: 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: : 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
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: 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
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
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: 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
in universe there is an sselect basic command -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Larry Hiscock Sent: Saturday, October 01, 2005 12:21 PM To: u2-users@listserver.u2ug.org 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
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] 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 NEW, OLD, 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/
