RE: [U2] user IDs

[Bill Haskett]

Harold:

I suspect you're asking for something other than "LISTU".  True?

Bill 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of Oaks, Harold
>Sent: Sunday, November 18, 2007 11:16 PM
>To: u2-users@listserver.u2ug.org
>Subject: [U2] user IDs
>
>Is there a Universe command to show all those logged in with their user
>ID?  I can run UniAdmin to find this out, of course, but the users
>can't.  What simple unix or Universe command will return this
>information?
>
>Thanks!
>
>Harold D. Oaks
>Sr. Analyst/Programmer
>Office of the Budget and Information Systems
>Clark County, Washington
>ph: (360) 397-6121 x4132
>fax: (360) 397-2342
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] user IDs

[Brian Phillips]

PORT.STATUS 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Oaks, Harold
> Sent: Monday, November 19, 2007 2:16 AM
> To: u2-users@listserver.u2ug.org
> Subject: [U2] user IDs
> 
> Is there a Universe command to show all those logged in with 
> their user ID?  I can run UniAdmin to find this out, of 
> course, but the users can't.  What simple unix or Universe 
> command will return this information?
> 
> Thanks!
> 
> Harold D. Oaks
> Sr. Analyst/Programmer
> Office of the Budget and Information Systems Clark County, Washington
> ph: (360) 397-6121 x4132
> fax: (360) 397-2342
> ---
> 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] user IDs [not-secure]

[Hennessey, Mark F.]

If you want 'regular' users to be able to run PORT.STATUS against all
logged in users, you'll have to set the user id bit on
./uvhome/bin/list_readu.

I also create a VOC I call ULIST...  It does:

SH -c "who -u -H -b | /usr/bin/pg -p '  Page %dPress Spacebar to
continue, Q to Quit' -n -s -e -r"

This allows you to search forward and back. It also inhibits the ability
of a clever/accidental bang out to Unix.


Mark Hennessey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Phillips
Sent: Monday, November 19, 2007 8:12 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] user IDs

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

RE: [U2] OT: Email encryption [not-secure]

[Hennessey, Mark F.]

My employer uses Tumbleweed. Be careful on how you setup the triggers
for securing e-mails. I have sent innocuous e-mails that our policies
flagged as requiring security (including to this list, hence the "not
secure" addition to the subject line!). Yet I can send an e-mail with
the phrase "the root password to the Solaris server is makemydaygeek"
and it would sail through...  Not Tumbleweed's fault, it's the arcane
policies we have setup...


Mark Hennessey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger
Sent: Friday, November 16, 2007 3:16 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] OT: Email encryption

I have a client that uses Tumbleweed to send secure emails. It works at
the email server level (these folks use Exchange), intercepting any
email message with the string ##SECURE in the subject. It then sends an
email to the recipient telling them they have a secure email waiting for
them at the client site; they need to connect to the site (via https by
clicking a link) and  authenticate themselves (or if first time create a
user & password), then they can view the text + attachments of the
original email. Works seamlessly with outlook+exchange and with
automatically generated emails from the UV/Linux system that use SMTP to
connect to the exchange server.
Should also work with other email clients. Not cheap, but pretty cool.

Another option would be pgp/gpg if full paranoia mode is required.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] user IDs

[Michael Martin]

We run Unidata with SBClient.  For the users with security to access the
"/" command they can use "/WHO" 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oaks, Harold
Sent: Monday, November 19, 2007 1:16 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] user IDs

Is there a Universe command to show all those logged in with their user
ID?  I can run UniAdmin to find this out, of course, but the users
can't.  What simple unix or Universe command will return this
information?

Thanks!

Harold D. Oaks
Sr. Analyst/Programmer
Office of the Budget and Information Systems Clark County, Washington
ph: (360) 397-6121 x4132
fax: (360) 397-2342
---
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] OCONV Extraction Question - Best Practises

[Baker Hughes]

It's JUST a preference, presently

I know we all reach for a good balance between brevity and clarity.

I have some preferences too which I think are ideal, which seem less
than ideal to others.

... but rather than mount my own hobby horse I have a suggestion /
question that could put these types of exchanges to rest:

WHAT IF - the U2UG took it as a future project to compile a Best
Practices coding guideline document for our language?

There's always helpful 'How to' stuff exchanged here. ...but style
question sometimes spiral downward.

As someone pointed out recently, we have the blessing and curse of using
a rather free style language.
Not much Structure-Style is not imposed by the construct of the language
itself, like some others.

Is it time to codify some best practices relating to structure,
modularity, reuse, length of internal subs, etc?

I may not like some of the resulting definitions myself but it would
build cohesion and greater respect for the MV space.
Another thing it would do is chart a clearer path for those coming
behind us - we need new blood if the VARs in this space are going to
continue to sell/support embedded MV apps.

I would personally find it fascinating to see some of our venerable
coders get together and see what they produced along this line.  I have
some names in mind but I'll wait for the nominations to officially open.

Happy Thanksgiving.

-Baker

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming
Sent: Saturday, November 17, 2007 12:58 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] OCONV Extraction Question

According to who?

I know there are some pluses and minuses but where is this decided or is
it just a preference.

Thanks
Mark Johnson
- Original Message -
From: "Brutzman, Bill" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 16, 2007 11:30 AM
Subject: RE: [U2] OCONV Extraction Question


> Speaking of mis-used commands and side-stepping some of the given code

> craziness...
>
> It is better practice to atomize the code into discrete elements such
as...
>
>   Var1.F = oconv(Var1, 'MD0')
>   crt Var1.F 'R#11'
>
> rather than to try to kill two birds with one stone by including an 
> oconv statement inside a crt statement such as...
>
>   crt oconv(Var1, 'MD0')
>
> --Bill
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of MAJ 
> Programming
> Sent: Friday, November 16, 2007 12:48 AM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] OCONV Extraction Question
>
>
> This is real smart, making things harder than they should be. Just use
<>.
>
> Mark Johnson
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, November 14, 2007 5:23 PM
> Subject: RE: [U2] OCONV Extraction Question
>
>
> > Didn't work for me either. It may not fit what you need, but SWAP 
> > can
make
> > it work.
> >
> > VAR1 = 'SAM':@VM:'TRUDY'
> > SWAP @VM WITH '*' IN VAR1
> > FMTSTR = 'G*1'
> > CRT OCONV(VAR1,FMTSTR)
> >
> > Brad
> >
> >
> > U.S. BANCORP made the following annotations
> > 
> > - Electronic Privacy Notice. This e-mail, and any attachments, 
> > contains
> information that is, or may be, covered by electronic communications
privacy
> laws, and is also confidential and proprietary in nature. If you are 
> not
the
> intended recipient, please be advised that you are legally prohibited 
> from retaining, using, copying, distributing, or otherwise disclosing 
> this information in any manner. Instead, please reply to the sender 
> that you
have
> received this communication in error, and then immediately delete it.
Thank
> you in advance for your cooperation.
> >
> >
> >
> > 
> > -
> > ---
> > 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/
---
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] OCONV Extraction Question - Best Practises

[Charles Barouch]

Baker,
  I agree, but the path is hard and the way is murky. A few months 
back, I posted a free skeleton maker, which implemented some reasonable 
commenting. When I opened it up to the list for comments, the response 
was greatly varied. Some people even replied privately for fear of 
starting a flame war on the lists.
  If we are going to do as you suggested, I only see one way to make 
that work: Let's get a few people to each write up their own style 
guideline and subject them all to the list's opinions, with each 
originator having a final say on their guideline. We can post them all 
to U2UG.org and let people select the one they like. it won't have the 
value of setting a single style, but it has the value of being possible. 
Anyone frustrated with all choices can petition the author who is 
closest or they can roll their own and subject it to feedback.

  Anyone willing to step up? I'd be willing to play under these terms.
 
  - Chuck


Baker Hughes wrote:

WHAT IF - the U2UG took it as a future project to compile a Best
Practices coding guideline document for our language?

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

RE: [U2] OCONV Extraction Question - Best Practises

[Anthony Youngman]

Just DON'T start a few flame wars over this :-)

I'd actually vehemently disagree with the original suggestion, for several 
reasons. The two biggest are:

It introduces an extra variable. Any poor maintenance guy coming along has to 
worry about whether it's used elsewhere. This sort of behaviour is actually 
frowned on in ANY programming language, I believe.

And my personal reason for disliking it, over and above the previous - it takes 
two lines where one would do. Okay, compressing code for the sake of it can 
hinder comprehension, but I like tight, compact code with white-space 
separating small sections, not individual sections full of white space...

Cheers,
Wol

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes
Sent: 19 November 2007 15:18
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] OCONV Extraction Question - Best Practises

It's JUST a preference, presently

I know we all reach for a good balance between brevity and clarity.

I have some preferences too which I think are ideal, which seem less
than ideal to others.

... but rather than mount my own hobby horse I have a suggestion /
question that could put these types of exchanges to rest:

WHAT IF - the U2UG took it as a future project to compile a Best
Practices coding guideline document for our language?

There's always helpful 'How to' stuff exchanged here. ...but style
question sometimes spiral downward.

As someone pointed out recently, we have the blessing and curse of using
a rather free style language.
Not much Structure-Style is not imposed by the construct of the language
itself, like some others.

Is it time to codify some best practices relating to structure,
modularity, reuse, length of internal subs, etc?

I may not like some of the resulting definitions myself but it would
build cohesion and greater respect for the MV space.
Another thing it would do is chart a clearer path for those coming
behind us - we need new blood if the VARs in this space are going to
continue to sell/support embedded MV apps.

I would personally find it fascinating to see some of our venerable
coders get together and see what they produced along this line.  I have
some names in mind but I'll wait for the nominations to officially open.

Happy Thanksgiving.

-Baker

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming
Sent: Saturday, November 17, 2007 12:58 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] OCONV Extraction Question

According to who?

I know there are some pluses and minuses but where is this decided or is
it just a preference.

Thanks
Mark Johnson
- Original Message -
From: "Brutzman, Bill" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 16, 2007 11:30 AM
Subject: RE: [U2] OCONV Extraction Question


> Speaking of mis-used commands and side-stepping some of the given code

> craziness...
>
> It is better practice to atomize the code into discrete elements such
as...
>
>   Var1.F = oconv(Var1, 'MD0')
>   crt Var1.F 'R#11'
>
> rather than to try to kill two birds with one stone by including an
> oconv statement inside a crt statement such as...
>
>   crt oconv(Var1, 'MD0')
>
> --Bill
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of MAJ
> Programming
> Sent: Friday, November 16, 2007 12:48 AM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] OCONV Extraction Question
>
>
> This is real smart, making things harder than they should be. Just use
<>.
>
> Mark Johnson
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: 
> Sent: Wednesday, November 14, 2007 5:23 PM
> Subject: RE: [U2] OCONV Extraction Question
>
>
> > Didn't work for me either. It may not fit what you need, but SWAP
> > can
make
> > it work.
> >
> > VAR1 = 'SAM':@VM:'TRUDY'
> > SWAP @VM WITH '*' IN VAR1
> > FMTSTR = 'G*1'
> > CRT OCONV(VAR1,FMTSTR)
> >
> > Brad
> >
> >
> > U.S. BANCORP made the following annotations
> > 
> > - Electronic Privacy Notice. This e-mail, and any attachments,
> > contains
> information that is, or may be, covered by electronic communications
privacy
> laws, and is also confidential and proprietary in nature. If you are
> not
the
> intended recipient, please be advised that you are legally prohibited
> from retaining, using, copying, distributing, or otherwise disclosing
> this information in any manner. Instead, please reply to the sender
> that you
have
> received this communication in error, and then immediately delete it.
Thank
> you in advance for your cooperation.
> >
> >
> >
> > 
> > -
> > ---
> > 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://listserv

Re: [U2] OCONV Extraction Question - Best Practises

[Susan Lynch]

Actually, that brings up an important point - my preference would  be that 
if you are going to do it once and never re-use that value, then it probably 
makes sense to do it in one line, and not add the additional variable, but 
if you are going to need it again, as the OCONV'd value, it makes sense to 
set a new variable to the OCONV'd value and use the variable, rather than 
re-doing the oconv.  But that requires that a maintenance programmer take 
the time to know the program rather than look at the surrounding 20 lines or 
so (and their performance is probably evaluated on how fast they get the 
changes made rather than on their effect on the quality of the code), which 
is why most of us have so often seen (particularly in programs generated by 
a code-generator or in programs maintained by a variety of people over many 
years) multiple READV's and WRITEV's rather than a single read of the 
record, or multiple OCONV's of the exact same field with the exact same 
masking.  But making the decision based on the need is my personal 
preference - others may prefer a standardized approach for ease of training 
new programmers or may argue that "disk is cheap, memory is cheap" and 
prefer not to focus on efficiency as one of the criteria for evaluating 
code.  All of which makes the determination of "best practices" rather 
difficult, since it depends on the criteria you choose for the evaluation - 
efficiency?  Ease of maintenance?  Conformation to 'site standards'? 
Ability to call a logical  module from multiple locations in the wider 
application?  Auditability of the results?  Various standards of 
presentation of data for the user interface?  Once you get beyond the very 
simple aspects of programming, everything has to be judged in the context of 
the application as a whole, rather than on the brilliance (or lack thereof) 
of small code fragments.


Susan Lynch
- Original Message - 
From: "Anthony Youngman" <[EMAIL PROTECTED]>

To: 
Sent: Monday, November 19, 2007 11:19 AM
Subject: RE: [U2] OCONV Extraction Question - Best Practises



Just DON'T start a few flame wars over this :-)

I'd actually vehemently disagree with the original suggestion, for several 
reasons. The two biggest are:


It introduces an extra variable. Any poor maintenance guy coming along has 
to worry about whether it's used elsewhere. This sort of behaviour is 
actually frowned on in ANY programming language, I believe.


And my personal reason for disliking it, over and above the previous - it 
takes two lines where one would do. Okay, compressing code for the sake of 
it can hinder comprehension, but I like tight, compact code with 
white-space separating small sections, not individual sections full of 
white space...


Cheers,
Wol

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes

Sent: 19 November 2007 15:18
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] OCONV Extraction Question - Best Practises

It's JUST a preference, presently
[SNIP]

[END SNIP]


Speaking of mis-used commands and side-stepping some of the given code



craziness...

It is better practice to atomize the code into discrete elements such

as...


  Var1.F = oconv(Var1, 'MD0')
  crt Var1.F 'R#11'

rather than to try to kill two birds with one stone by including an
oconv statement inside a crt statement such as...

  crt oconv(Var1, 'MD0')

--Bill> 

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

Re: [U2] OCONV Extraction Question - Best Practises

[Kevin King]

I'd play on that field, Chuck.  Not looking for a flame war, but I
know there are a lot of people with some great ideas and there's much
to be gained by keeping the lines of communication open.  Then again,
topics like alpha vs. numeric labels could turn out to be massively
polarizing.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OCONV Extraction Question - Best Practises

[Charles_Shaffer]

My personal preference is to atomize.  This goes back to my C days.  I 
found that while it was possible to cram a lot of code into one line, 
there were portability problems.  The same code could compile differently 
on different platforms depending on how the C compiler handled the complex 
lines.  I don't know if there are similar issues with UniBasic, or not. 

Also, I personally find the atomized code easier to read and more 
explicit.

Charles Shaffer
Senior Analyst
NTN-Bower Corporation




>Just DON'T start a few flame wars over this :-)

>I'd actually vehemently disagree with the original suggestion, for 
several reasons. The two biggest are:

>It introduces an extra variable. Any poor maintenance guy coming along 
has to worry about whether it's used elsewhere. This sort of behaviour is 
>actually frowned on in ANY programming language, I believe.

>And my personal reason for disliking it, over and above the previous - it 
takes two lines where one would do. Okay, compressing code for the sake of 
>it can hinder comprehension, but I like tight, compact code with 
white-space separating small sections, not individual sections full of 
white >space...

>Cheers,
>Wol

> Speaking of mis-used commands and side-stepping some of the given code

> craziness...
>
> It is better practice to atomize the code into discrete elements such
as...
>
>   Var1.F = oconv(Var1, 'MD0')
>   crt Var1.F 'R#11'
>
> rather than to try to kill two birds with one stone by including an
> oconv statement inside a crt statement such as...
>
>   crt oconv(Var1, 'MD0')
>
> --Bill
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] Via Systems

[Suzanne P. Irwin]

Hello,
Does anyone know what the current status of Via Systems is?  Their domain 
appears to be for sale.  As I am contemplating making a commitment to 
MyViewPoint and use ViaDuct rather extensively, the sudden disappearance of 
their website is unsettling.

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

Re: [U2] OCONV Extraction Question - Best Practises

[Kevin King]

In response to Susan's mention of the criteria for evaluating code, I
submit that I personally verify code against three criteria:

1) Is it accurate?  Does it fulfill its designed mission?  Often times
code misses this mark simply because of the shifting sands of
requirements, and what might have been accurate six months ago may no
longer be so.

2) Does it perform as well as it could?  This is where the multiple
READV/WRITEV thing falls down, as it may not be the most efficient way
of achieving a given objective.

3) Is it maintainable?  This goes far beyond "readable" to include
elements to strengthen comprehension of the context and intended
objective and how the source code interprets the implementation of
that objective.  This includes standardized code fragments and
structures, predictable and consistent variable naming conventions,
intentional use and avoidance of certain language elements (such as GE
verses >= for comparison) and commenting styles and standards.

Too often, as Susan has pointed out, programmers write code to make
today's problem go away because there are a dozen or more projects
lined up behind it, instead of writing the code thinking of the guy
who will be reading the code several months from now.   I submit that
we should always keep the future maintainer in mind, assuming that
they know nothing of the context, little of the problem, and less time
than needed to achieve their objective.  If we don't set the stage for
that person's success, we shouldn't be surprised when they don't
describe our work in the most complimentary of terms.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Via Systems

[Ray Methvin]

I received the following email from ViaSystems on November 13th...

Dear Via Systems Customer:
 
As part of our business expansion we have moved our domain name from
via.com to viasystemsinc.com.
 
You are now able to reach us on the World Wide Web at
www.viasystemsinc.com, or if you prefer send an email to any of the
following addresses:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
 
Sincerely,
Your Via Systems Team

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Suzanne P.
Irwin
Sent: Monday, November 19, 2007 12:52 PM
To: u2-users@listserver.u2ug.org
Subject: [U2] Via Systems

Hello,
Does anyone know what the current status of Via Systems is?  Their
domain 
appears to be for sale.  As I am contemplating making a commitment to 
MyViewPoint and use ViaDuct rather extensively, the sudden disappearance
of 
their website is unsettling.
Thanks,
---
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] OCONV Extraction Question - Best Practises

[Bill Haskett]

Susan:

See.  This brings up the difference between coding styles and guidelines.

The guidline is:

If you use it once use it once.  If you use it twice either create a variable 
or a
local subroutine.  If it's used in more than one program then either create a 
common
variable or a separate subroutine.  You get the idea.

Now we expose ourselves to style.

Style 1:

OfficeRec(5) = OfficeRec(6) * OfficeRec(7)

Style 2:

EQUATE OfficeSize to OfficeRec(4)
OfficeWidth = OfficeRec(6)
OfficeDepth = OfficeRec(7)
OfficeSize  = OfficeWidth * OfficeDepth

I think this demonstrates the style differences between brevity and clarity.  
Style 1
accomplishes exactly what's needed while style 2 reflects the need for clarity 
of
what's actually being done.  Often I simply add a comment to Style 1 like:

Style 1 (amended):

OfficeRec(5) = OfficeRec(6) * OfficeRec(7)  ; ** the size of the office in 
square
footage

However, as you say, if I'm using any of the variables elsewhere in the code, 
or was
referencing a dynamic instead of a dimensioned array for OfficeRec, I'd much 
prefer
Style 2.

So it seems to me there really is a difference between style and guidelines.  
:-)

Bill 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of Susan Lynch
>Sent: Monday, November 19, 2007 9:25 AM
>To: u2-users@listserver.u2ug.org
>Subject: Re: [U2] OCONV Extraction Question - Best Practises
>
>Actually, that brings up an important point - my preference would  be that 
>if you are going to do it once and never re-use that value, then it probably 
>makes sense to do it in one line, and not add the additional variable, but 
>if you are going to need it again, as the OCONV'd value, it makes sense to 
>set a new variable to the OCONV'd value and use the variable, rather than 
>re-doing the oconv.

[snipped]

>Susan Lynch
>
>- Original Message - 
>From: "Anthony Youngman" <[EMAIL PROTECTED]>
>To: 
>Sent: Monday, November 19, 2007 11:19 AM
>Subject: RE: [U2] OCONV Extraction Question - Best Practises
>
>
>> Just DON'T start a few flame wars over this :-)
>>
>> I'd actually vehemently disagree with the original suggestion, for several 
>> reasons. The two biggest are:
>>
>> It introduces an extra variable. Any poor maintenance guy coming along has 
>> to worry about whether it's used elsewhere. This sort of behaviour is 
>> actually frowned on in ANY programming language, I believe.
>>
>> And my personal reason for disliking it, over and above the previous - it 
>> takes two lines where one would do. Okay, compressing code for the sake of 
>> it can hinder comprehension, but I like tight, compact code with 
>> white-space separating small sections, not individual sections full of 
>> white space...
>>
>> Cheers,
>> Wol
>>
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes
>> Sent: 19 November 2007 15:18
>> To: u2-users@listserver.u2ug.org
>> Subject: RE: [U2] OCONV Extraction Question - Best Practises
>>
>> It's JUST a preference, presently

[snipped]

>>> Speaking of mis-used commands and side-stepping some of the given code
>>>
>>> craziness...
>>>
>>> It is better practice to atomize the code into discrete elements such
>>> as...
>>>
>>>   Var1.F = oconv(Var1, 'MD0')
>>>   crt Var1.F 'R#11'
>>>
>>> rather than to try to kill two birds with one stone by including an
>>> oconv statement inside a crt statement such as...
>>>
>>>   crt oconv(Var1, 'MD0')
>>>
>>> --Bill> 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Via Systems

[Ross Ferris]

NOT HAPPY JAN!! (will make sense to the aussies)

I'm guessing that someone may have forgotten to renew their domain,
which has been swooped upon by an E-squatter. If something more serious
has happened, I can offer you my alternative viewpoint for one of the
products mentioned 

Ross Ferris
Stamina Software
Visage > Better by Design!

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:owner-u2-
>[EMAIL PROTECTED] On Behalf Of Suzanne P. Irwin
>Sent: Tuesday, 20 November 2007 4:52 AM
>To: u2-users@listserver.u2ug.org
>Subject: [U2] Via Systems
>
>Hello,
>Does anyone know what the current status of Via Systems is?  Their
>domain
>appears to be for sale.  As I am contemplating making a commitment to
>MyViewPoint and use ViaDuct rather extensively, the sudden
disappearance
>of
>their website is unsettling.
>Thanks,
>---
>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] OCONV Extraction Question - Good Practice

[Brutzman, Bill]

The problem of printing non-atomic data gets worse when doing reports with
tables, that is, long lines with several variables.  Consider the following
remedy.  The alternative is a nightmare.

--Bill

>>> Speaking of mis-used commands and side-stepping some of the given code
>>> craziness...
>>>
>>> It is better practice to atomize the code into discrete elements such
>>> as...

  Var1.F = oconv(Var1, 'MD0')
  Var2.F = oconv(Var2, 'MD2') 
  Var3.F = oconv(Var3, 'MD4')

  Crt.Str  = Var1.F 'R#6
  Crt.Str := Var2.R 'R#12'
  Crt.Str := Var3.F 'R#14'
  crt Crt.Str  


>>> rather than to try to kill two birds with one stone by including an
>>> oconv statement inside a crt statement such as...
>>>
>>>   crt oconv(Var1, 'MD0')
>>>
>>> --Bill> 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] Baker's Challenge

[Charles Barouch]

My initial entry in the Baker's Challenge for programming standards is 
in U2-Community under this name:


   Programming Standards: The Barouch Spec

   The stated goal is for several people to offer their own 
specifications, for the community to comment on the lot, and for each 
original author to accept or reject comments. The final versions, based 
on whatever the authors deem final will be offered to the U2UG.org 
website for publication and further commentary. In keeping with the 
current discussion on U2-Users, I'm posting this on U2-Community for 
comment.

   All civil feedback will be considered.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] OCONV Extraction Question - Best Practises

[Baker Hughes]

Susan,


 All of which makes the determination of "best practices" rather
difficult, since it depends on the criteria you choose for the
evaluation - efficiency?  Ease of maintenance?  Conformation to 'site
standards'? Ability to call a logical  module from multiple locations in
the wider application?  Auditability of the results?  Various standards
of presentation of data for the user interface?  Once you get beyond the
very simple aspects of programming, everything has to be judged in the
context of the application as a whole, rather than on the brilliance (or
lack thereof) of small code fragments.

Susan Lynch


If there were a set of best practices, no one would expect old code to
conform to it, only new or re-factored code.

Obviously, if you are working with 20 year old code, as many of us are,
you have a huge limitation out of the box (unless you have unlimited
freedom to re-write your app [and multiply QA time exponentially]).  The
purpose of any 'best practices' document{s) would be to set forth ideal
methodologies.  It is up to the art and skill of the individual
programmer to incorporate those methodologies, insofar as s/he can, into
their every project.

However, well formed, well structured, modular code will satisfy all the
evaluation points you mentioned.  The one sticky point could be 'site
standards' - but hopefully those sites that have arcane 'standards'
would consider the weight and authority of a 'industry recognized' [De
Facto] standard 'best practices' document, and change their archaic
ways.

just my .002

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

RE: [U2] OCONV Extraction Question - Best Practises

[Charles_Shaffer]

Great discussion!

One thing that I have learned in my 25 years in IT is that early on, I 
underestimated the importance of maintainability.  I noticed this when I 
got into management.  I had a programmer who seemed to be slow, but when 
you looked at her code, it was BEAUTIFUL.  Anyone could easily modify her 
code because she made the intent SO obvious through structure and 
comments.  The time saved working with her code FAR outweighed the extra 
time she took coding it. 

Charles Shaffer
Senior Analyst
NTN-Bower Corporation
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Via Systems

[Eric Armstrong]

Here's a contact that we picked up at the MV conference in Long Beach.

Michael Hannigan 719-579-6800 x7035
[EMAIL PROTECTED]

Eric Armstrong
Programmer/Analyst
Lobel Financial
714-816-1207


-Original Message-
From: Suzanne P. Irwin [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 9:52 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Via Systems


Hello,
Does anyone know what the current status of Via Systems is?  Their domain 
appears to be for sale.  As I am contemplating making a commitment to 
MyViewPoint and use ViaDuct rather extensively, the sudden disappearance of 
their website is unsettling.
Thanks,
---
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] Via Systems

[Ross Ferris]

I wonder if they passed this on to EDP (owners in the UK), who still
have a link to the wrong domain then  my money is still on the
"ooops, who forgot to re-register their domain" theory !!

Ross Ferris
Stamina Software
Visage > Better by Design!


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:owner-u2-
>[EMAIL PROTECTED] On Behalf Of Ray Methvin
>Sent: Tuesday, 20 November 2007 5:47 AM
>To: u2-users@listserver.u2ug.org
>Subject: RE: [U2] Via Systems
>
>I received the following email from ViaSystems on November 13th...
>
>Dear Via Systems Customer:
>
>As part of our business expansion we have moved our domain name from
>via.com to viasystemsinc.com.
>
>You are now able to reach us on the World Wide Web at
>www.viasystemsinc.com, or if you prefer send an email to any of the
>following addresses:
>[EMAIL PROTECTED]
>[EMAIL PROTECTED]
>[EMAIL PROTECTED]
>
>Sincerely,
>Your Via Systems Team
>
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Suzanne P.
>Irwin
>Sent: Monday, November 19, 2007 12:52 PM
>To: u2-users@listserver.u2ug.org
>Subject: [U2] Via Systems
>
>Hello,
>Does anyone know what the current status of Via Systems is?  Their
>domain
>appears to be for sale.  As I am contemplating making a commitment to
>MyViewPoint and use ViaDuct rather extensively, the sudden
disappearance
>of
>their website is unsettling.
>Thanks,
>---
>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] Via Systems

[Ross Morrissey]

Mike left Via a while back.


C7 Reporting is a Via Distributor - Larry Christensen's address is good and
he's glad to help - [EMAIL PROTECTED]


On 11/19/07, Eric Armstrong <[EMAIL PROTECTED]> wrote:
>
> Here's a contact that we picked up at the MV conference in Long Beach.
>
> Michael Hannigan...
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Subject: [U2] Via Systems

[Tom Dodds]

[AD]

As long as we are going to push contacts at this person, Larry Christenson
is a dealer for Via Systems and ViewPoint.  Here is his contact information.
Larry has been in the Multi-Valued industry for a long time and has a great
back ground in Business Intelligence with extensive experience with MITS.

 

Larry Christensen, C-7 Reporting Solutions, LLC, Direct: 909-349-1736,
[EMAIL PROTECTED]

[AD]

 

This is not my AD, but just to be sure I don't get chastised.

 

Tom Dodds

[EMAIL PROTECTED]

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

[U2] Dictionary Help

[Al DeWitt]

UniData 6.1 + System Builder



I have a COMBO box that got change way back when.  Nobody knows way it
was changed as the person who did has long since left the company.  I
want to revert it back to standard.  However I want to know all the
dictionary items that use it.



I'm thinking I need to write a utility that does the following:



1.  Selects all files from the VOC.
2.  Searches the files' dictionary to find any items where the
string 'TXD' if found in attribute 2 of the dictionary item.
3.  If I get a get, display the filename and the item name.



What's the most efficient way to do this?



Thanks.



Albert DeWitt

Sr. Programmer Analyst

Stylmark, Inc.

763.574.8705 (V)

763-574-1052 (F)

[EMAIL PROTECTED] 
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

[U2] Pick programmer needed contract or full time

[Carol Carmen]

We are a mega church located in Tulsa, OK.  We are looking for an
on-site Pick/UniVerse programmer for a full time position or contract
work.  Please send resume to [EMAIL PROTECTED]  Or, mail resume
to:



Church on the Move

Attn:  Carol Carmen

1003 N 129th E Ave

Tulsa, OK  74116
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] Dictionary Help

[Kevin King]

This is exactly what /SEARCH is intended to do in SB+.

On Nov 19, 2007 2:56 PM, Al DeWitt <[EMAIL PROTECTED]> wrote:
> UniData 6.1 + System Builder
>
>
>
> I have a COMBO box that got change way back when.  Nobody knows way it
> was changed as the person who did has long since left the company.  I
> want to revert it back to standard.  However I want to know all the
> dictionary items that use it.
>
>
>
> I'm thinking I need to write a utility that does the following:
>
>
>
> 1.  Selects all files from the VOC.
> 2.  Searches the files' dictionary to find any items where the
> string 'TXD' if found in attribute 2 of the dictionary item.
> 3.  If I get a get, display the filename and the item name.
>
>
>
> What's the most efficient way to do this?
>
>
>
> Thanks.
>
>
>
> Albert DeWitt
>
> Sr. Programmer Analyst
>
> Stylmark, Inc.
>
> 763.574.8705 (V)
>
> 763-574-1052 (F)
>
> [EMAIL PROTECTED] 
> ---
> u2-users mailing list
> u2-users@listserver.u2ug.org
> To unsubscribe please visit http://listserver.u2ug.org/
>



-- 
-Kevin
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] OCONV Extraction Question - Best Practises

[Kevin King]

Charles: GREAT point!

In the overarching scheme of things, we should never forget that while
original implementation has a fixed timeline, maintenance can be
forever.  More importantly, the costs of each are commensurate with
its lifetime.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Baker's Challenge

[Bill Haskett]

Charles:

Where is the community?  I can't find that nor can I figure out how to post to 
the
Wiki.  :-(

Bill 

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf Of 
>Charles Barouch
>Sent: Monday, November 19, 2007 11:51 AM
>To: u2-users@listserver.u2ug.org
>Subject: [U2] Baker's Challenge
>
>My initial entry in the Baker's Challenge for programming standards is 
>in U2-Community under this name:
>
>Programming Standards: The Barouch Spec
>
>The stated goal is for several people to offer their own 
>specifications, for the community to comment on the lot, and for each 
>original author to accept or reject comments. The final 
>versions, based 
>on whatever the authors deem final will be offered to the U2UG.org 
>website for publication and further commentary. In keeping with the 
>current discussion on U2-Users, I'm posting this on U2-Community for 
>comment.
>All civil feedback will be considered.
>---
>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] OCONV Extraction Question - Best Practises

[MAJ Programming]

I would be in favor of chapterizing the various coding concepts into a
greatest hits collection.

As I have transversed perhaps 35 different MV systems during my career, I
have had the chance to view many practices, both good and bad. I add the
good ones to my collection (always willing to learn) and scratch my head at
some of the crazy ones.

I do give the benefit of the doubt in some cases as I can 'age' the programs
and personally recall the available thought processes at the time. But also
having been around since almost the beginning, I can see when some commands
were used when the better ones were certainly available. Thus, those fall
into the 'bad' category.

Example of a bad technique that has no reason for its use:

WHOLE.NAME="MARK JOHNSON"
II=INDEX(WHOLE.NAME," ",1)
FIRST.NAME=WHOLE.NAME[1,II-1]

ain't that called the FIELD command.

Things like that.

My 2 cents
Mark Johnson
- Original Message -
From: "Baker Hughes" <[EMAIL PROTECTED]>
To: 
Sent: Monday, November 19, 2007 10:17 AM
Subject: RE: [U2] OCONV Extraction Question - Best Practises


> It's JUST a preference, presently
>
> I know we all reach for a good balance between brevity and clarity.
>
> I have some preferences too which I think are ideal, which seem less
> than ideal to others.
>
> ... but rather than mount my own hobby horse I have a suggestion /
> question that could put these types of exchanges to rest:
>
> WHAT IF - the U2UG took it as a future project to compile a Best
> Practices coding guideline document for our language?
>
> There's always helpful 'How to' stuff exchanged here. ...but style
> question sometimes spiral downward.
>
> As someone pointed out recently, we have the blessing and curse of using
> a rather free style language.
> Not much Structure-Style is not imposed by the construct of the language
> itself, like some others.
>
> Is it time to codify some best practices relating to structure,
> modularity, reuse, length of internal subs, etc?
>
> I may not like some of the resulting definitions myself but it would
> build cohesion and greater respect for the MV space.
> Another thing it would do is chart a clearer path for those coming
> behind us - we need new blood if the VARs in this space are going to
> continue to sell/support embedded MV apps.
>
> I would personally find it fascinating to see some of our venerable
> coders get together and see what they produced along this line.  I have
> some names in mind but I'll wait for the nominations to officially open.
>
> Happy Thanksgiving.
>
> -Baker
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming
> Sent: Saturday, November 17, 2007 12:58 AM
> To: u2-users@listserver.u2ug.org
> Subject: Re: [U2] OCONV Extraction Question
>
> According to who?
>
> I know there are some pluses and minuses but where is this decided or is
> it just a preference.
>
> Thanks
> Mark Johnson
> - Original Message -
> From: "Brutzman, Bill" <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, November 16, 2007 11:30 AM
> Subject: RE: [U2] OCONV Extraction Question
>
>
> > Speaking of mis-used commands and side-stepping some of the given code
>
> > craziness...
> >
> > It is better practice to atomize the code into discrete elements such
> as...
> >
> >   Var1.F = oconv(Var1, 'MD0')
> >   crt Var1.F 'R#11'
> >
> > rather than to try to kill two birds with one stone by including an
> > oconv statement inside a crt statement such as...
> >
> >   crt oconv(Var1, 'MD0')
> >
> > --Bill
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of MAJ
> > Programming
> > Sent: Friday, November 16, 2007 12:48 AM
> > To: u2-users@listserver.u2ug.org
> > Subject: Re: [U2] OCONV Extraction Question
> >
> >
> > This is real smart, making things harder than they should be. Just use
> <>.
> >
> > Mark Johnson
> > - Original Message -
> > From: <[EMAIL PROTECTED]>
> > To: 
> > Sent: Wednesday, November 14, 2007 5:23 PM
> > Subject: RE: [U2] OCONV Extraction Question
> >
> >
> > > Didn't work for me either. It may not fit what you need, but SWAP
> > > can
> make
> > > it work.
> > >
> > > VAR1 = 'SAM':@VM:'TRUDY'
> > > SWAP @VM WITH '*' IN VAR1
> > > FMTSTR = 'G*1'
> > > CRT OCONV(VAR1,FMTSTR)
> > >
> > > Brad
> > >
> > >
> > > U.S. BANCORP made the following annotations
> > > 
> > > - Electronic Privacy Notice. This e-mail, and any attachments,
> > > contains
> > information that is, or may be, covered by electronic communications
> privacy
> > laws, and is also confidential and proprietary in nature. If you are
> > not
> the
> > intended recipient, please be advised that you are legally prohibited
> > from retaining, using, copying, distributing, or otherwise disclosing
> > this information in any manner. Instead, please reply to the sender
> > that you
> have
> > received this communication in error, and th

RE: [U2] Baker's Challenge

[Ken Hall]

Bill -
To subscribe to the list  [EMAIL PROTECTED]
 please visit http://listserver.u2ug.org/

Then just send your emails to [EMAIL PROTECTED]


Ken


At 07:07 PM 11/19/2007, you wrote:

Charles:

Where is the community?  I can't find that nor can I figure out how 
to post to the

Wiki.  :-(

Bill

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

Re: [U2] OCONV Extraction Question - Good Practice

[MAJ Programming]

Here begins the voting for differences.

I actually do not care for the inclusion of the extra Var1.F variables as,
mentioned earlier, is that variable used elsewhere? Plus, it implies that it
maybe part of a calculation instead of an upcoming, disposable CRT
statement.

Will I rot as I use this CRT statement?

CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":"
":OCONV(VAR3,"MD4")"R#14".

If so, I wonder how much company I'll have.

My 1 cent.

Oddly enough, to make things more interesting, I would have coded it this
way:

CRT VAR1"R0#6":" ":VAR2/100"R2#10":" ":VAR3/1"R4#14"

Less typing. For output, the only time I use OCONV is a "MTx" time
conversion or if the value isn't justified and I want the all the decimals.
I use DATE()"D2/" beaucoups of times.


- Original Message -
From: "Brutzman, Bill" <[EMAIL PROTECTED]>
To: 
Sent: Monday, November 19, 2007 2:41 PM
Subject: RE: [U2] OCONV Extraction Question - Good Practice


> The problem of printing non-atomic data gets worse when doing reports with
> tables, that is, long lines with several variables.  Consider the
following
> remedy.  The alternative is a nightmare.
>
> --Bill
>
> >>> Speaking of mis-used commands and side-stepping some of the given code
> >>> craziness...
> >>>
> >>> It is better practice to atomize the code into discrete elements such
> >>> as...
>
>   Var1.F = oconv(Var1, 'MD0')
>   Var2.F = oconv(Var2, 'MD2')
>   Var3.F = oconv(Var3, 'MD4')
>
>   Crt.Str  = Var1.F 'R#6
>   Crt.Str := Var2.R 'R#12'
>   Crt.Str := Var3.F 'R#14'
>   crt Crt.Str
>
>
> >>> rather than to try to kill two birds with one stone by including an
> >>> oconv statement inside a crt statement such as...
> >>>
> >>>   crt oconv(Var1, 'MD0')
> >>>
> >>> --Bill>
> ---
> 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] OCONV Extraction Question - Best Practises

[MAJ Programming]

I'm all for exposing my personal techniques and watching the flames come.
Granted, there will be some holy wars but in the end, many ambiguous
conditions may be solved one way or another.

I have exposed my personal techniques for many years on these forums and
will defend them as I understand the offenders. I am also smart enough to
change a technique if I see a better one.

It doesn't have to be voted unanimously to be my favorite. We all can tell
what techniques will fit comfortably with our existing skills. I, for one,
do not care for the EQU CUST.NAME to CUSTOMER(1) style of coding. I do not
like using attr 99 for calculated dictionary items (sorry, that's another
forum). I have my own preferred way of opening files, file handle names, and
even constructively mixing numeric with alphabetic labels.

While there will be no winners, everyone will be a winner as we all will
become exposed to other techniques that many of us may not have had the
luxury of reviewing many different systems.

I can't wait.
Mark Johnson

PS. Hopefully this doesn't become an artistic expression of grandeur.
Meaning, if the chapter was the best way to multiply 2 numbers together,
A=B*C must win. If someone submits A=e^(ln(B)+ln(C)) then that misses the
point.
- Original Message -
From: "Kevin King" <[EMAIL PROTECTED]>
To: 
Sent: Monday, November 19, 2007 12:07 PM
Subject: Re: [U2] OCONV Extraction Question - Best Practises


> I'd play on that field, Chuck.  Not looking for a flame war, but I
> know there are a lot of people with some great ideas and there's much
> to be gained by keeping the lines of communication open.  Then again,
> topics like alpha vs. numeric labels could turn out to be massively
> polarizing.
> ---
> 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] OCONV Extraction Question - Best Practises

[MAJ Programming]

I am living that mess of the 'future maintainer' right now. I've inherited 2
systems due to the prior programmer leaving town and while that programmer
was very smart and had a good memory for the 10+ years of code he wrote, he
barely commented anything, has ambiguous program and file names and, due to
working 80% with The Programmer's Helper, everything is inconsistently
abbreviated.

So I figure that 10-15% of what I'm typing is not code but comments. I put
comments in programs declaring why I am reviewing it in the first place and
what it's attached to. I have a DICT README record in every data file for
its nominal purpose and other commentary. I wrote a FIND.ALL program to
review every BP file, Proc and MD in these multi-account systems to see if
program FIX.RECORD-3 is used anywhere or a one-shot 'programmer's program. I
have programs that sniff out OPEN attempted files that STOP upon failure to
consider archiving the program out of the mainline BP files.

All of this exposure of bad techiques will help many people develop their
own Best Practices.

MJ
- Original Message -
From: "Kevin King" <[EMAIL PROTECTED]>
To: 
Sent: Monday, November 19, 2007 1:17 PM
Subject: Re: [U2] OCONV Extraction Question - Best Practises


> In response to Susan's mention of the criteria for evaluating code, I
> submit that I personally verify code against three criteria:
>
> 1) Is it accurate?  Does it fulfill its designed mission?  Often times
> code misses this mark simply because of the shifting sands of
> requirements, and what might have been accurate six months ago may no
> longer be so.
>
> 2) Does it perform as well as it could?  This is where the multiple
> READV/WRITEV thing falls down, as it may not be the most efficient way
> of achieving a given objective.
>
> 3) Is it maintainable?  This goes far beyond "readable" to include
> elements to strengthen comprehension of the context and intended
> objective and how the source code interprets the implementation of
> that objective.  This includes standardized code fragments and
> structures, predictable and consistent variable naming conventions,
> intentional use and avoidance of certain language elements (such as GE
> verses >= for comparison) and commenting styles and standards.
>
> Too often, as Susan has pointed out, programmers write code to make
> today's problem go away because there are a dozen or more projects
> lined up behind it, instead of writing the code thinking of the guy
> who will be reading the code several months from now.   I submit that
> we should always keep the future maintainer in mind, assuming that
> they know nothing of the context, little of the problem, and less time
> than needed to achieve their objective.  If we don't set the stage for
> that person's success, we shouldn't be surprised when they don't
> describe our work in the most complimentary of terms.
> ---
> 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] OCONV Extraction Question - Good Practice

[Womack, Adrian]

IMO, the only thing wrong with your example is the use of the trailing
format strings - everyone (and I mean everyone) should be using the FMT
function, making your example:

CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10
"):FMT(OCONV(VAR3,"MD4"),"R#14")

The old method is a disaster waiting to happen.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming
Sent: Tuesday, 20 November 2007 2:12 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] OCONV Extraction Question - Good Practice

Here begins the voting for differences.

I actually do not care for the inclusion of the extra Var1.F variables
as, mentioned earlier, is that variable used elsewhere? Plus, it implies
that it maybe part of a calculation instead of an upcoming, disposable
CRT statement.

Will I rot as I use this CRT statement?

CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":"
":OCONV(VAR3,"MD4")"R#14".



DISCLAIMER:
Disclaimer.  This e-mail is private and confidential. If you are not the 
intended recipient, please advise us by return e-mail immediately, and delete 
the e-mail and any attachments without using or disclosing the contents in any 
way. The views expressed in this e-mail are those of the author, and do not 
represent those of this company unless this is clearly indicated. You should 
scan this e-mail and any attachments for viruses. This company accepts no 
liability for any direct or indirect damage or loss resulting from the use of 
any attachments to this e-mail.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/