RE: [U2] OPEN vs TRANS

[Stevenson, Charles]

Vectoring (is 'vector' a verb?) is built into TRANS already.  
No need to abandon in favour of OCONVS T-correlative.
You can specify a dynamic array of IDs for the target file to read.

> I have used the Translate code with OCONVS() function when it 
> is stylistically in keeping with the use of vector functions 
> around it and only because there isn't a vector version of 
> TRANS(), but personally I wouldn't use it outside of that situation.
> 
>   custProductIDs = splice(reuse(custId),'*',productIds)

instead of / as well as this:

>   prices = oconvs(custProductIDs,'TCUST.PRODUCT;X;;99')

this works fine (even better I think):

prices = TRANS( 'CUST.PRODUCT', custProductIDs, 99, 'X' )


But a caution:

If CUST.PRODUCT <99> is multivalued &/or sub-valued:
 
 * T-correlative converts all delimiters to spaces when OCONVS returns.
 (consistent with PICK.)

 * TRANS will lower the returned delimiters. 
(almost consistent with PI.)
- if called from Retrieve, the delimiters are lowered enough to
keep the association with the dict equivalent of custProductIDs
which might be multi-SUB-valued or even have TMs or lower.
- if called from Basic, not that smart, just lowered once,
so you might lose the association with custProductIDs.


The above for UV. Mileage for UD may vary.

cds
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OPEN vs TRANS

[Stuart . Boydell]

> I've actually run into a program with 10 READV's, some processing then 10


> WRITEV's for the obvious same record in the same file.

>

> Is the OCONV(translate) function any more or less effecient in BASIC than
in

> English (sic). I use them for simple validation or to retrieve one field

> with no side effects. If I need another field, I use OPEN and READ.



I have used the Translate code with OCONVS() function when it is
stylistically in keeping with the use of vector functions around it and
only because there isn't a vector version of TRANS(), but personally I
wouldn't use it outside of that situation.



  custProductIDs = splice(reuse(custId),'*',productIds)

  prices = oconvs(custProductIDs,'TCUST.PRODUCT','X';;99)



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

[Mark Johnson]

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]
>  ] 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]
>   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 EXECUT

Re: [U2] Fw: More U2 programming hints

[Mark Johnson]

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]
> > ] 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]
> >  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 

Re: [U2] Fw: More U2 programming hints

[Mark Johnson]

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]
>  ] 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]
>   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 

Re: [U2] Fw: More U2 programming hints

[Bruce Nichol]

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]
 ] 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]
  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', TIM

RE: [U2] Fw: More U2 programming hints

[gerry-u2ug]

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]
 ] 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]
  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 E

[U2] Fw: More U2 programming hints

[Jeff Marcos]

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]
 ] 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]
  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.

> 

> Norm

RE: [U2] Senior Pick Programming Position - Centennial, CO

[Allen E. Elwood]

I did the documentation for the Forecasting interface to Demand Solutions I
wrote while at ROI Systems and it was done so well that last I heard they
were still using it as the standard to maintain when teaching others how to
document.

Very professional, every stinking sentence in third person.  Took a long
time to get just right.

But the only reason it got done at all was because there were no requests
for custom code at the time (2001-ish), and people were searching for
something to do just to avoid the boredom of playing solitaire all day.

On the other hand, the documentation for the hazardous materials bill of
lading I wrote was "Use standard procedures to operate."

Nobody is perfect. 'specially me

:-)

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Don Kibbey
Sent: Sunday, October 09, 2005 14:40
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Senior Pick Programming Position - Centennial, CO


It's something that good programmers are going to write "tomorrow"...

On 10/7/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> From: "Debster" <[EMAIL PROTECTED]>
>
> > Something most programmers hate to write
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] OPEN vs TRANS

[Don Kibbey]

Yep, I've recently went on several site visits to other Law Firms
running two different billing packages on SQL Server.  All 6 had
converted from a UniVerse system running on HP-UX.  All 6 mentioned
the letdown of running a large query against their spanking new "uber"
machines only to find they had a significant performance lag when
compared to the "ancient" HP-UX machines running a very well designed
UniVerse application.

In the Oracle, SQL server, arena, performance problems are solved with
the check book and more/faster hardware.

On 10/7/05, Dan Fitzgerald <[EMAIL PROTECTED]> wrote:
> Amen. Allow me to add that often the decision to replace an MV database with
> an RDBMS hinges on, "what do you mean I need 5 times as much
> hardware/horsepower to run Oracle?".
>
>
>
> "Our greatest duty in this life is to help others. And please, if you can't
> help them, could you at least not hurt them?" - H.H. the Dalai Lama
> "When buying & selling are controlled by legislation, the first thing to be
> bought & sold are the legislators" - P.J. O'Rourke
> Dan Fitzgerald
>
>
>
>
>
> >From: Timothy Snyder <[EMAIL PROTECTED]>
> >Reply-To: u2-users@listserver.u2ug.org
> >To: u2-users@listserver.u2ug.org
> >Subject: RE: [U2] OPEN vs TRANS
> >Date: Fri, 7 Oct 2005 17:21:28 -0400
> >
> >"Allen E. Elwood" <[EMAIL PROTECTED]> wrote on 10/07/2005 12:53:47 PM:
> >
> > > The way I look at it, when I started programming 30 years ago systems
> >were
> > > millions of times slower, and in another 30 years they'll be so stinking
> > > fast that coding for speed will go the way of the Suchomimus and the
> > > Iguanodon!
> >
> >As long as programmers think that way, their employers will continue to
> >pay people like me big bucks to come in and make the code more efficient.
> >;-)  Sometimes more powerful systems can make bottlenecks more prominent.
> >Today's systems are expected to process more data in a shorter time, and
> >to provide more functionality than in days of yore, so even minor
> >inefficiencies are encountered over and over again.  IMHO, there will
> >always be room for efficient coding techniques.  Some folks claim you have
> >to sacrifice maintainability and readability for the sake of efficiency -
> >I've rarely found that to be true.  As long as you care about and consider
> >both performance and maintainability as you develop code, it all just
> >falls together.
> >
> >Now, as to people who want to code one line instead of two (e.g.: the
> >topic of this thread), I say take a touch typing course so you don't mind
> >a few extra keystrokes.  (I've always been amazed watching seasoned
> >professionals using only one finger on each hand to write programs.)  I
> >would much rather inherit a program that does its own opens and reads
> >instead of doing translates.  Sooner or later somebody will want to get a
> >second field from the record and you'll be faced with doing two translates
> >or changing it to the way it should have been done in the first place.
> >Plus, the OCONV with a translate isn't nearly as obvious to the casual
> >observer of the code.  Of course, you could put in some comments to make
> >it clear, but those keystrokes could have been spent opening the file at
> >the top of the program.
> >
> >
> >Tim Snyder
> >Consulting I/T Specialist , U2 Professional Services
> >North American Lab Services
> >DB2 Information Management, IBM Software Group
> >717-545-6403
> >[EMAIL PROTECTED]
> >---
> >u2-users mailing list
> >u2-users@listserver.u2ug.org
> >To unsubscribe please visit http://listserver.u2ug.org/
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Senior Pick Programming Position - Centennial, CO

[Don Kibbey]

It's something that good programmers are going to write "tomorrow"...

On 10/7/05, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> From: "Debster" <[EMAIL PROTECTED]>
>
> > Something most programmers hate to write
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Unidata TCL - beginner question

[colin.alfke]

See UDT.OPTIONS 43.

The udto.pdf explains what this is doing. The file isn't too large - UniData
just doesn't like displaying valid values in a detail suppress report that you
don't break-on.

hth
Colin Alfke
Calgary Canada



From: Bruce Ordway

>SORT filename BY Part BY Date @ID BREAK.ON Part Date DET.SUP<
BTW, I thought this worked to begin with.
Then, I started noticing it wasn't really.
I keep getting dates in the middle of the range for some parts.
Just so happens I'm working on a huge file, 886817 records.
I wonder if Unidata SORT's break down if a file is too big or sized
incorrectly?

[demime 1.01d removed an attachment of type application/ms-tnef which had a 
name of winmail.dat]
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/