Including Code - A Best Practice?

[Big_Tecs]

A friendly discussion arose recently among some U2/MV Developers about whether to include code.

If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.

In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides: unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker




  ________________________________
This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way. Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Kevin King]

An include is fine for declarations, but not for executable code due to the
fact that individual lines in the include cannot be debugged (on Unidata).
 Declarations like EQUates and common blocks are best uses for includes.
 The need to break apart big routines due to some arbitrary limit (i.e.
32K) is no longer a valid argument and without the ability to debug
included code, any gains quickly become lost.

On Tue, Feb 7, 2012 at 4:04 PM, Baker Hughes <baker.hughes@...>wrote:

> A friendly discussion arose recently among some U2/MV Developers about
> whether to include code.
>
> If any of you have opinions about the positive aspects or negative aspects
> of this practice, please respond.  Should it be adopted as a best practice,
> or rejected as special situation use only?
>
> Many shops probably include long sections of variable assignments, or
> perhaps globally opened files.  This is pretty much accepted everywhere as
> a good practice.
>
> In question here is the insertion of actual code - business logic or
> screen I/O programs or code snippets.
>
> Maybe you know of methods to overcome some of the obvious downsides:
> unintended reassignment of local variables, difficulty in debugging, others.
>
> What are the positive upsides?  Performance gains?
>
> What is the longest snippet you think should be included, if allowed?
>
> What advantage has included code over a CALL or a Function?  Reuse.  What
> else?
>
> Can the downsides be mitigated satisfactorily to justify the gains?
>
> Thanks so much.
>
> -Baker
>
>
>
>
>  ________________________________
> This communication, its contents and any file attachments transmitted with
> it are intended solely for the addressee(s) and may contain confidential
> proprietary information.
> Access by any other party without the express written permission of the
> sender is STRICTLY PROHIBITED.
> If you have received this communication in error you may not copy,
> distribute or use the contents, attachments or information in any way.
> Please destroy it and contact the sender.
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Wols Lists]

On 07/02/12 23:46, Kevin King wrote:
> An include is fine for declarations, but not for executable code due to the
> fact that individual lines in the include cannot be debugged (on Unidata).
>  Declarations like EQUates and common blocks are best uses for includes.
>  The need to break apart big routines due to some arbitrary limit (i.e.
> 32K) is no longer a valid argument and without the ability to debug
> included code, any gains quickly become lost.

Plus, what happens if you ever want to update that code?

If it's INCLUDEd in twenty different files, you need to recompile the
lot - that is if you even know what files include it! (And don't say you
can search, you're quite likely to miss something).

If it's a subroutine, you know one recompile and you've caught all
instances.

Cheers,
Wol
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Kevin King]

I agree with Wols; a subroutine takes more memory and is slower to launch
but is so much easier to work with in any sized system.  It's funny, our
subroutines are oddly similar to how Microsoft implemented DLL wrecknology
for Windows, but we've never had the kind of hell that Windows programmers
experience.  Funny how that works... :)

On Tue, Feb 7, 2012 at 5:01 PM, Wols Lists <antlists@...> wrote:

> On 07/02/12 23:46, Kevin King wrote:
> > An include is fine for declarations, but not for executable code due to
> the
> > fact that individual lines in the include cannot be debugged (on
> Unidata).
> >  Declarations like EQUates and common blocks are best uses for includes.
> >  The need to break apart big routines due to some arbitrary limit (i.e.
> > 32K) is no longer a valid argument and without the ability to debug
> > included code, any gains quickly become lost.
>
> Plus, what happens if you ever want to update that code?
>
> If it's INCLUDEd in twenty different files, you need to recompile the
> lot - that is if you even know what files include it! (And don't say you
> can search, you're quite likely to miss something).
>
> If it's a subroutine, you know one recompile and you've caught all
> instances.
>
> Cheers,
> Wol
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
>

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Ross Ferris]

There are plenty of reasons to include code, and issues like variable assignment should be able to be addressed with minimal care as to scope of the variables --> if you use "I" in a for/next loop and include or execute some code in the loop that also uses "I", U will get what you deserve.

As per other recent discussions, I'd run the includes through a pre-processor so that the object you ultimately produce DOES NOT have includes, but rather has real code, and real line number references, that can be used against the pre-processed source code

You can get the same level of re-use from included code as you can from calling external subroutines with appropriate code builds, and the speed gains can be significant from, inline code, though sometimes this can be counter-intuitive if a highly used routine spans frame boundaries & frame faults (though few people will bother looking at code for this level of optimization within the runtime environment

Ross Ferris
Stamina Software
Visage > Better by Design!

-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Wednesday, 8 February 2012 10:05 AM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about whether to include code.

If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.

In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides: unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker




  ________________________________
This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way. Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Tony Gravagno-3]

> From: Kevin King
> It's funny, our subroutines are oddly similar to how
> Microsoft implemented DLL wrecknology for Windows, but
> we've never had the kind of hell that Windows
> programmers experience.  Funny how that works... :)

I completely disagree. Have you never been working on code in a
live shop, make a change, and have someone in the other room
scream?  Errr, neither have I, but Hypothetically...

DLL Hell is where you change a subroutine on which many others
are based, and where calling programs are unprepared for a change
in behaviour or structure of the called program.  Since we
operate in a global environment, where all users in an account
share the same calling and called programs, we're subject to the
exact same issues.  Try changing a common block without
recompiling all the programs that Include it, or adding an
argument to a subroutine without changing the programs that call
it.  Welcome to the MV version of DLL Hell.

..NET addresses DLL hell by allowing calling programs to call a
specific version of the subroutine, so updates with a different
version don't cause the callers to blow up.  We could do this in
MV too but I don't know anyone who does.  The way we do it is to
set flags in the code that route differently based on port number
or user name or something similar.  When the code is fully
debugged we remove the flag and all users execute the same code,
hopefully without error.

That wrecknology has been fixed.  Programs that continue to break
aren't making use of the wrecknology, errr, the current features.
MV has yet to catch up.

T



_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David A. Green]

I don't think using an INCLUDE is bad, but it must be done in the right way.

Pros:

* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.

Cons:

* You must, MUST, address the variable names. I always prefix mine with
CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
unique for your system.
* You must recompile all instances if you want the change to be updated
everywhere.
* More difficult to edit program logic, unless you have a nice editor that
brings in INCLUDES/INSERTS for you automatically.

David A. Green
[phone]
DAG Consulting

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about
whether to include code.

If any of you have opinions about the positive aspects or negative aspects
of this practice, please respond.  Should it be adopted as a best practice,
or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or
perhaps globally opened files.  This is pretty much accepted everywhere as a
good practice.

In question here is the insertion of actual code - business logic or screen
I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What
else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker




  ________________________________
This communication, its contents and any file attachments transmitted with
it are intended solely for the addressee(s) and may contain confidential
proprietary information.
Access by any other party without the express written permission of the
sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy,
distribute or use the contents, attachments or information in any way.
Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Big_Tecs]

David,

Could you elaborate a little more on your two positive arguments?  Thanks for your insights, and all those shared from others so far.

Thank you.
-Baker

-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of David A. Green
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?

I don't think using an INCLUDE is bad, but it must be done in the right way.

Pros:

* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.

Cons:

* You must, MUST, address the variable names. I always prefix mine with CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be unique for your system.
* You must recompile all instances if you want the change to be updated everywhere.
* More difficult to edit program logic, unless you have a nice editor that brings in INCLUDES/INSERTS for you automatically.

David A. Green
[phone]
DAG Consulting

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about whether to include code.

If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.

In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker

This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way.  Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Tom Whitmore]

I would agree that code in includes provides a faster program than making an external subroutine.  I had performed tests when milliseconds counted,  but now systems are so fast the advantage is not noticeable.

Putting code in includes:
        Makes debugging harder
        Installing updates requires compiling the world to make sure you get all the programs that use that include.
        Maintenance costs are higher

>From my perspective, just say "NO" to code in includes.  The cost is too high with no real benefit.

Tom
RATEX Business Solutions

-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Wednesday, February 08, 2012 10:15 AM
To: 'dgreen@...'; 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?

David,

Could you elaborate a little more on your two positive arguments?  Thanks for your insights, and all those shared from others so far.

Thank you.
-Baker

-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of David A. Green
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?

I don't think using an INCLUDE is bad, but it must be done in the right way.

Pros:

* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.

Cons:

* You must, MUST, address the variable names. I always prefix mine with CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be unique for your system.
* You must recompile all instances if you want the change to be updated everywhere.
* More difficult to edit program logic, unless you have a nice editor that brings in INCLUDES/INSERTS for you automatically.

David A. Green
[phone]
DAG Consulting

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about whether to include code.

If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.

In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker

This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way.  Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[David A. Green]

When you INCLUDE code during compile time it becomes as one, thus all your
subroutines are now internal subroutines.  And internal subroutines execute
about 1000 times (just guessing here it's been a while since I have done
timing) faster than calling a subroutine.

For debugging, we just had some emails that talked about this very thing.  I
know you need something like -Z2 -D.

David A. Green
[phone]
DAG Consulting


-----Original Message-----
From: Baker Hughes [mailto:baker.hughes@...]
Sent: Wednesday, February 08, 2012 8:15 AM
To: 'dgreen@...'; 'U2 Users List'
Subject: RE: [U2] Including Code - A Best Practice?

David,

Could you elaborate a little more on your two positive arguments?  Thanks
for your insights, and all those shared from others so far.

Thank you.
-Baker

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of David A. Green
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?

I don't think using an INCLUDE is bad, but it must be done in the right way.

Pros:

* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.

Cons:

* You must, MUST, address the variable names. I always prefix mine with
CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
unique for your system.
* You must recompile all instances if you want the change to be updated
everywhere.
* More difficult to edit program logic, unless you have a nice editor that
brings in INCLUDES/INSERTS for you automatically.

David A. Green
[phone]
DAG Consulting

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about
whether to include code.

If any of you have opinions about the positive aspects or negative aspects
of this practice, please respond.  Should it be adopted as a best practice,
or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or
perhaps globally opened files.  This is pretty much accepted everywhere as a
good practice.

In question here is the insertion of actual code - business logic or screen
I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What
else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker

This communication, its contents and any file attachments transmitted with
it are intended solely for the addressee(s) and may contain confidential
proprietary information.
Access by any other party without the express written permission of the
sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy,
distribute or use the contents, attachments or information in any way.
Please destroy it and contact the sender.

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Rutherford, Marc]

Baker,

In production at my current site I have used Include only once, but for reasons very different from what has already been discussed.  I have a Shipment print program customized into a true monster.  It had not been rolled forward during previous vendor (Dataflo) upgrades because of the difficulty.

I bit the bullet.  Internally smaller custom sections with limited variable requirements I pushed into subroutines. These were low-usage code sections so I was not concerned with performance.  The bulk of the customizations were in huge blocks of heavily exercised code.  I did not what to put those into subroutines for performance reasons, and because the variable usage was huge and tangled. I collected those large blocks and moved them to the bottom of the program as internal gosubs.

My final step was to use the vendor's COMPARE tool to confirm I did break baseline functionality.  This forced a major refractor of internal custom structure and major cleanup of comment tags and project references. Now when the COMPARE tools runs I can rapidly confirm correct modification of the vendor's code. This sets up the program to be upgrade-able in the future.

I finally pushed the massive custom block I placed at the end of the program into an Include. Now when I run the COMPARE tool it reaches the end of the program where there is now one custom Include and Done!  My reason is that simple.

I have had to debug only a couple of times.  I simply comment out the Include and Load the entire Include code into place, compiled, and debug. Cumbersome yes, fortunately not a daily procedure. ;-)

Marc Rutherford
Principal Programmer Analyst
Advanced Bionics LLC
661) 362 1754


-----Original Message-----
From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 3:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about whether to include code.

If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.

In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides: unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker




  ________________________________
This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way. Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Robert Porter-3]

1000?  I find that hard to swallow on modern systems.  To see that kind of difference I suspect it would have to be really memory starved so as to not cache it after the 1st use for commonly used routine. And if we're talking about a routine that's once in a while, then the benefit doesn't add up to much anyway.  I'd love to see some simple benchmarks. I've been surprised before, so it could happen. :)
 
We use include for: named commons, a couple common equates (TRUE, FALSE, ASCII char names such as ESC, etc), and file dictionaries. To build those we use a program that ensures that a prefix is unique to that file, so that variable names cannot get crossed.
 
Robert
 
 
Robert F. Porter, MCSE, CCNA, ZCE, OCP-Java
Lead Sr. Programmer / Analyst
Laboratory Information Services
Ochsner Health System
 
 
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


>>> "David A. Green" <dgreen@...> 2/8/2012 9:38 AM >>>
When you INCLUDE code during compile time it becomes as one, thus all your
subroutines are now internal subroutines.  And internal subroutines execute
about 1000 times (just guessing here it's been a while since I have done
timing) faster than calling a subroutine.

For debugging, we just had some emails that talked about this very thing.  I
know you need something like -Z2 -D.

David A. Green
[phone]
DAG Consulting


-----Original Message-----
From: Baker Hughes [mailto:baker.hughes@...]
Sent: Wednesday, February 08, 2012 8:15 AM
To: 'dgreen@...'; 'U2 Users List'
Subject: RE: [U2] Including Code - A Best Practice?

David,

Could you elaborate a little more on your two positive arguments?  Thanks
for your insights, and all those shared from others so far.

Thank you.
-Baker

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of David A. Green
Sent: Wednesday, February 08, 2012 8:21 AM
To: 'U2 Users List'
Subject: Re: [U2] Including Code - A Best Practice?

I don't think using an INCLUDE is bad, but it must be done in the right way.

Pros:

* It is the fastest way to use reusable code.
* It can be debugged just fine if you use the correct compile arguments.

Cons:

* You must, MUST, address the variable names. I always prefix mine with
CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
unique for your system.
* You must recompile all instances if you want the change to be updated
everywhere.
* More difficult to edit program logic, unless you have a nice editor that
brings in INCLUDES/INSERTS for you automatically.

David A. Green
[phone]
DAG Consulting

-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: Tuesday, February 07, 2012 4:05 PM
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about
whether to include code.

If any of you have opinions about the positive aspects or negative aspects
of this practice, please respond.  Should it be adopted as a best practice,
or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or
perhaps globally opened files.  This is pretty much accepted everywhere as a
good practice.

In question here is the insertion of actual code - business logic or screen
I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What
else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker

This communication, its contents and any file attachments transmitted with
it are intended solely for the addressee(s) and may contain confidential
proprietary information.
Access by any other party without the express written permission of the
sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy,
distribute or use the contents, attachments or information in any way.
Please destroy it and contact the sender.

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[WJhonson]

What compile arguments?
I just checked the help pages for both BASIC and RAID and don't see anything about including the INCLUDE code so the debugger can use it.



-----Original Message-----
From: David A. Green <dgreen@...>
To: 'U2 Users List' <u2-users@...>
Sent: Wed, Feb 8, 2012 6:21 am
Subject: Re: [U2] Including Code - A Best Practice?


I don't think using an INCLUDE is bad, but it must be done in the right way.
Pros:
* It is the fastest way to use reusable code.
 It can be debugged just fine if you use the correct compile arguments.
Cons:
* You must, MUST, address the variable names. I always prefix mine with
ODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
nique for your system.
 You must recompile all instances if you want the change to be updated
verywhere.
 More difficult to edit program logic, unless you have a nice editor that
rings in INCLUDES/INSERTS for you automatically.
David A. Green
480) 813-1725
AG Consulting
-----Original Message-----
rom: u2-users-bounces@...
mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
ent: Tuesday, February 07, 2012 4:05 PM
o: U2 Users List (u2-users@...)
ubject: [U2] Including Code - A Best Practice?
A friendly discussion arose recently among some U2/MV Developers about
hether to include code.
If any of you have opinions about the positive aspects or negative aspects
f this practice, please respond.  Should it be adopted as a best practice,
r rejected as special situation use only?
Many shops probably include long sections of variable assignments, or
erhaps globally opened files.  This is pretty much accepted everywhere as a
ood practice.
In question here is the insertion of actual code - business logic or screen
/O programs or code snippets.
Maybe you know of methods to overcome some of the obvious downsides:
nintended reassignment of local variables, difficulty in debugging, others.
What are the positive upsides?  Performance gains?
What is the longest snippet you think should be included, if allowed?
What advantage has included code over a CALL or a Function?  Reuse.  What
lse?
Can the downsides be mitigated satisfactorily to justify the gains?
Thanks so much.
-Baker


 ________________________________
his communication, its contents and any file attachments transmitted with
t are intended solely for the addressee(s) and may contain confidential
roprietary information.
ccess by any other party without the express written permission of the
ender is STRICTLY PROHIBITED.
f you have received this communication in error you may not copy,
istribute or use the contents, attachments or information in any way.
lease destroy it and contact the sender.
______________________________________________
2-Users mailing list
2-Users@...
ttp://listserver.u2ug.org/mailman/listinfo/u2-users
_______________________________________________
2-Users mailing list
2-Users@...
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Brian Leach]

Required for UniData not UniVerse.

Brian

Sent from my iPad

On 8 Feb 2012, at 17:27, Wjhonson <wjhonson@...> wrote:

>
> What compile arguments?
> I just checked the help pages for both BASIC and RAID and don't see anything about including the INCLUDE code so the debugger can use it.
>
>
>
> -----Original Message-----
> From: David A. Green <dgreen@...>
> To: 'U2 Users List' <u2-users@...>
> Sent: Wed, Feb 8, 2012 6:21 am
> Subject: Re: [U2] Including Code - A Best Practice?
>
>
> I don't think using an INCLUDE is bad, but it must be done in the right way.
> Pros:
> * It is the fastest way to use reusable code.
> It can be debugged just fine if you use the correct compile arguments.
> Cons:
> * You must, MUST, address the variable names. I always prefix mine with
> ODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
> nique for your system.
> You must recompile all instances if you want the change to be updated
> verywhere.
> More difficult to edit program logic, unless you have a nice editor that
> rings in INCLUDES/INSERTS for you automatically.
> David A. Green
> 480) 813-1725
> AG Consulting
> -----Original Message-----
> rom: u2-users-bounces@...
> mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
> ent: Tuesday, February 07, 2012 4:05 PM
> o: U2 Users List (u2-users@...)
> ubject: [U2] Including Code - A Best Practice?
> A friendly discussion arose recently among some U2/MV Developers about
> hether to include code.
> If any of you have opinions about the positive aspects or negative aspects
> f this practice, please respond.  Should it be adopted as a best practice,
> r rejected as special situation use only?
> Many shops probably include long sections of variable assignments, or
> erhaps globally opened files.  This is pretty much accepted everywhere as a
> ood practice.
> In question here is the insertion of actual code - business logic or screen
> /O programs or code snippets.
> Maybe you know of methods to overcome some of the obvious downsides:
> nintended reassignment of local variables, difficulty in debugging, others.
> What are the positive upsides?  Performance gains?
> What is the longest snippet you think should be included, if allowed?
> What advantage has included code over a CALL or a Function?  Reuse.  What
> lse?
> Can the downsides be mitigated satisfactorily to justify the gains?
> Thanks so much.
> -Baker
>
>
> ________________________________
> his communication, its contents and any file attachments transmitted with
> t are intended solely for the addressee(s) and may contain confidential
> roprietary information.
> ccess by any other party without the express written permission of the
> ender is STRICTLY PROHIBITED.
> f you have received this communication in error you may not copy,
> istribute or use the contents, attachments or information in any way.
> lease destroy it and contact the sender.
> ______________________________________________
> 2-Users mailing list
> 2-Users@...
> ttp://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> 2-Users mailing list
> 2-Users@...
> ttp://listserver.u2ug.org/mailman/listinfo/u2-users
>
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Mecki Foerthmann]

Like with most things I'd say it depends.
I have worked with quite a few systems that use standard includes and
haven't noticed that those were harder to maintain than those that don't.
The reason being that those includes never get changed.
Usually these include equates (TRUE, FALSE, VM, AM etc.), commons,
opening standard system files (error messages, personal work files and
so on), housekeeping and/or wrapping up at the end of the program.
Debugging is also no problem since you have compile options that not
only generate a symbol table but also make the included code visible (in
UniData just use -Z2 -D).
If you use includes like that then at least 2 of your points become invalid.
That said, I don't understand what you mean with "installing updates
requires compiling the world".
If your software vendor uses includes you haven't got a choice and if
the software is developed in-house you define the standards.
And one of those standards should be, 'Don't change the standard includes!'.
So I can't see any disadvantage in using includes per se.
To the contrary.
You just copy the parts with the includes (in our case top and bottom)
of an existing program into an empty item (or create a template) and
start writing your code and you don't have to worry about your system
wide standard variables.


On 08/02/2012 15:35, Tom Whitmore wrote:

> I would agree that code in includes provides a faster program than making an external subroutine.  I had performed tests when milliseconds counted,  but now systems are so fast the advantage is not noticeable.
>
> Putting code in includes:
> Makes debugging harder
> Installing updates requires compiling the world to make sure you get all the programs that use that include.
> Maintenance costs are higher
>
> > From my perspective, just say "NO" to code in includes.  The cost is too high with no real benefit.
>
> Tom
> RATEX Business Solutions
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
> Sent: Wednesday, February 08, 2012 10:15 AM
> To: 'dgreen@...'; 'U2 Users List'
> Subject: Re: [U2] Including Code - A Best Practice?
>
> David,
>
> Could you elaborate a little more on your two positive arguments?  Thanks for your insights, and all those shared from others so far.
>
> Thank you.
> -Baker
>
> -----Original Message-----
> From: u2-users-bounces@... [mailto:u2-users-bounces@...] On Behalf Of David A. Green
> Sent: Wednesday, February 08, 2012 8:21 AM
> To: 'U2 Users List'
> Subject: Re: [U2] Including Code - A Best Practice?
>
> I don't think using an INCLUDE is bad, but it must be done in the right way.
>
> Pros:
>
> * It is the fastest way to use reusable code.
> * It can be debugged just fine if you use the correct compile arguments.
>
> Cons:
>
> * You must, MUST, address the variable names. I always prefix mine with CODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be unique for your system.
> * You must recompile all instances if you want the change to be updated everywhere.
> * More difficult to edit program logic, unless you have a nice editor that brings in INCLUDES/INSERTS for you automatically.
>
> David A. Green
> [phone]
> DAG Consulting
>
> -----Original Message-----
> From: u2-users-bounces@...
> [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
> Sent: Tuesday, February 07, 2012 4:05 PM
> To: U2 Users List (u2-users@...)
> Subject: [U2] Including Code - A Best Practice?
>
> A friendly discussion arose recently among some U2/MV Developers about whether to include code.
>
> If any of you have opinions about the positive aspects or negative aspects of this practice, please respond.  Should it be adopted as a best practice, or rejected as special situation use only?
>
> Many shops probably include long sections of variable assignments, or perhaps globally opened files.  This is pretty much accepted everywhere as a good practice.
>
> In question here is the insertion of actual code - business logic or screen I/O programs or code snippets.
>
> Maybe you know of methods to overcome some of the obvious downsides:
> unintended reassignment of local variables, difficulty in debugging, others.
>
> What are the positive upsides?  Performance gains?
>
> What is the longest snippet you think should be included, if allowed?
>
> What advantage has included code over a CALL or a Function?  Reuse.  What else?
>
> Can the downsides be mitigated satisfactorily to justify the gains?
>
> Thanks so much.
>
> -Baker
>
> This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
> Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
> If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way.  Please destroy it and contact the sender.
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users
> _______________________________________________
> U2-Users mailing list
> U2-Users@...
> http://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[WJhonson]

I believe he means, as can often happen, that your file structure changes.
You start with an invoice file of say 30 fields, and write 80 programs to reference that include.
But down the road someone says oh hey we need to handle cases where we need to add a "extension with no penalty" date, or a "multiple methods of payment" or a "APS rejected date" or whatever to that structure.

Now you edit your include and add one or three more fields at the bottom say, but no program yet knows you've done that, until you recompile that program.  You could select all the programs that include that equate table and recompile them all.  You don't have to of course, but you could, most people would probably strengthen that and say you SHOULD.










-----Original Message-----
From: Mecki Foerthmann <meckif@...>
To: u2-users <u2-users@...>
Sent: Wed, Feb 8, 2012 10:36 am
Subject: Re: [U2] Including Code - A Best Practice?


Like with most things I'd say it depends.
 have worked with quite a few systems that use standard includes and
aven't noticed that those were harder to maintain than those that don't.
he reason being that those includes never get changed.
sually these include equates (TRUE, FALSE, VM, AM etc.), commons,
pening standard system files (error messages, personal work files and
o on), housekeeping and/or wrapping up at the end of the program.
ebugging is also no problem since you have compile options that not
nly generate a symbol table but also make the included code visible (in
niData just use -Z2 -D).
f you use includes like that then at least 2 of your points become invalid.
hat said, I don't understand what you mean with "installing updates
equires compiling the world".
f your software vendor uses includes you haven't got a choice and if
he software is developed in-house you define the standards.
nd one of those standards should be, 'Don't change the standard includes!'.
o I can't see any disadvantage in using includes per se.
o the contrary.
ou just copy the parts with the includes (in our case top and bottom)
f an existing program into an empty item (or create a template) and
tart writing your code and you don't have to worry about your system
ide standard variables.

n 08/02/2012 15:35, Tom Whitmore wrote:
 I would agree that code in includes provides a faster program than making an
xternal subroutine.  I had performed tests when milliseconds counted,  but now
ystems are so fast the advantage is not noticeable.

 Putting code in includes:
  Makes debugging harder
  Installing updates requires compiling the world to make sure you get all the
rograms that use that include.
  Maintenance costs are higher

 > From my perspective, just say "NO" to code in includes.  The cost is too
igh with no real benefit.

 Tom
 RATEX Business Solutions

 -----Original Message-----
 From: u2-users-bounces@... [mailto:u2-users-bounces@...]
n Behalf Of Baker Hughes
 Sent: Wednesday, February 08, 2012 10:15 AM
 To: 'dgreen@...'; 'U2 Users List'
 Subject: Re: [U2] Including Code - A Best Practice?

 David,

 Could you elaborate a little more on your two positive arguments?  Thanks for
our insights, and all those shared from others so far.

 Thank you.
 -Baker

 -----Original Message-----
 From: u2-users-bounces@... [mailto:u2-users-bounces@...]
n Behalf Of David A. Green
 Sent: Wednesday, February 08, 2012 8:21 AM
 To: 'U2 Users List'
 Subject: Re: [U2] Including Code - A Best Practice?

 I don't think using an INCLUDE is bad, but it must be done in the right way.

 Pros:

 * It is the fastest way to use reusable code.
 * It can be debugged just fine if you use the correct compile arguments.

 Cons:

 * You must, MUST, address the variable names. I always prefix mine with
ODE$NAME where CODE is the prefix I've chosen for my INCLUDE and should be
nique for your system.
 * You must recompile all instances if you want the change to be updated
verywhere.
 * More difficult to edit program logic, unless you have a nice editor that
rings in INCLUDES/INSERTS for you automatically.

 David A. Green
 [phone]
 DAG Consulting

 -----Original Message-----
 From: u2-users-bounces@...
 [mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
 Sent: Tuesday, February 07, 2012 4:05 PM
 To: U2 Users List (u2-users@...)
 Subject: [U2] Including Code - A Best Practice?

 A friendly discussion arose recently among some U2/MV Developers about whether
o include code.

 If any of you have opinions about the positive aspects or negative aspects of
his practice, please respond.  Should it be adopted as a best practice, or
ejected as special situation use only?

 Many shops probably include long sections of variable assignments, or perhaps
lobally opened files.  This is pretty much accepted everywhere as a good
ractice.

 In question here is the insertion of actual code - business logic or screen
/O programs or code snippets.

 Maybe you know of methods to overcome some of the obvious downsides:
 unintended reassignment of local variables, difficulty in debugging, others.

 What are the positive upsides?  Performance gains?

 What is the longest snippet you think should be included, if allowed?

 What advantage has included code over a CALL or a Function?  Reuse.  What
lse?

 Can the downsides be mitigated satisfactorily to justify the gains?

 Thanks so much.

 -Baker

 This communication, its contents and any file attachments transmitted with it
re intended solely for the addressee(s) and may contain confidential
roprietary information.
 Access by any other party without the express written permission of the sender
s STRICTLY PROHIBITED.
 If you have received this communication in error you may not copy, distribute
r use the contents, attachments or information in any way.  Please destroy it
nd contact the sender.
 _______________________________________________
 U2-Users mailing list
 U2-Users@...
 http://listserver.u2ug.org/mailman/listinfo/u2-users
 _______________________________________________
 U2-Users mailing list
 U2-Users@...
 http://listserver.u2ug.org/mailman/listinfo/u2-users
______________________________________________
2-Users mailing list
2-Users@...
ttp://listserver.u2ug.org/mailman/listinfo/u2-users

_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Susan Joslyn]

Piping in with contrary notions all the way across the board!  See my
remarks at -->[SJ] in four places, if you like.


On 07/02/12 23:46, Kevin King wrote:
> An include is fine for declarations, but not for executable code due to
the > fact that individual lines in the include cannot be debugged (on
Unidata). >  Declarations like EQUates and common blocks are best uses for
includes.  The need to break apart big routines due to some arbitrary limit
(i.e.> 32K) is no longer a valid argument and without the ability to debug
included code, any gains quickly become lost.

-->[SJ] I disagree with Kevin (not unusual, our technical approaches to
developing have always been different!)... for one thing I totally hate file
equate declarations. I'm probably in the unpopular crowd on that one, but
that's how I feel.  Then I believe that debugging, while requiring an extra
step, is not that hard and the gains are worth the extra effort.  I'll
elaborate below...


Plus, what happens if you ever want to update that code? If it's INCLUDEd in
twenty different files, you need to recompile the lot - that is if you even
know what files include it! (And don't say you can search, you're quite
likely to miss something).

--->[SJ]  Disagreeing with Wol, too. This is exactly why I *do* use an
include.  If you are running the same chunk of code all over the place, I
think it is much easier to recompile the 25 programs when you change it,
than it is to change it in 25 places!  And I can use a search ... or I keep
a matrix of what calls and includes what. Since an include would have a
unique name, and certainly the string INCLUDE FILENAME INCLUDENAME is very
unique, an ESEARCH should be quite reliable.

If it's a subroutine, you know one recompile and you've caught all
instances.

---> [SJ] Subroutines do have advantages but an include can make a lot of
assumptions about where it is... a subroutine either has an immense number
of arguments, a fragmented COMMON, or you start over with building up some
basic info.  Includes are a convenient way to isolate a repeated chunk of
code and very easily reuse it without duplicated effort.   When it needs to
be fixed or updated, it is in one place.

-->[SJ] I acknowledge that debugging is harder.  So what I do is I have a
standard way that I remark out the include and indicate the end of the
included section, then I just merge the whole business in until I'm finished
debugging.  The 'Basic Developer Toolkit' editor (BDT, from rocket software)
actually does this automatically.  Even doing it manually and acknowledging
the inconvenience it is still less maintenance and far less ambiguity to
reuse chunks of code this way.



_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Brian Leach]

Late to this, but I use includes with code in two situations:

1. As standard library pieces managed through a pre-compiler, usually for
platform-dependent sections. For example, I have standard includes for
getting command line arguments, reading and writing from ini files and so
forth. The precompiler builds versions of the code for each supported
platform (Universe, UniData, D3, QM etc) by pulling in the required blocks.

I also make the same code available as subroutines (that have the same
includes), but as I have a lot of utilities it's easier for me if each of
them if relatively stand-alone and I can send them out without the need for
any supporting code.

2. For self-initializing named common blocks. I use these extensively with
web and GUI development, as it means I don't have to assume any specific
start-up routine or entry point - I can just include the declaration and
know it will be valid whatever piece of code is hit first.

These are usually of the format:

COMMON /SOMECOM/ prefix.PARAMS(SomeSize),prefix.INIT
If prefix.INIT = @False Then
  .. go and initialize it, e.g. set params to empty, open files etc.
  prefix.INIT = @True
End

(remember that named common is initialized to zero i.e. @false not to
empty).

For example, a lot of my older green screen routines have a clipboard
function and cursor handling. So I have a CLIPBOARD named common which needs
to be set to empty to begin with, and a TERM named common that defines the
terminal settings and keys, initially as a set of defaults then by reading
overrides from an INI style record. They will be initialized by whatever
routine uses either of them first, without having to call a start-up routine
on login if they aren't going to be used.

Brian



-----Original Message-----
From: u2-users-bounces@...
[mailto:u2-users-bounces@...] On Behalf Of Baker Hughes
Sent: 07 February 2012 23:05
To: U2 Users List (u2-users@...)
Subject: [U2] Including Code - A Best Practice?

A friendly discussion arose recently among some U2/MV Developers about
whether to include code.

If any of you have opinions about the positive aspects or negative aspects
of this practice, please respond.  Should it be adopted as a best practice,
or rejected as special situation use only?

Many shops probably include long sections of variable assignments, or
perhaps globally opened files.  This is pretty much accepted everywhere as a
good practice.

In question here is the insertion of actual code - business logic or screen
I/O programs or code snippets.

Maybe you know of methods to overcome some of the obvious downsides:
unintended reassignment of local variables, difficulty in debugging, others.

What are the positive upsides?  Performance gains?

What is the longest snippet you think should be included, if allowed?

What advantage has included code over a CALL or a Function?  Reuse.  What
else?

Can the downsides be mitigated satisfactorily to justify the gains?

Thanks so much.

-Baker




  ________________________________
This communication, its contents and any file attachments transmitted with
it are intended solely for the addressee(s) and may contain confidential
proprietary information.
Access by any other party without the express written permission of the
sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy,
distribute or use the contents, attachments or information in any way.
Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users


_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users

[Big_Tecs]

I want to thank each contributor to this thread for the reasoned and professional responses.

As always, very illuminating and instructive to be a part of this list.

Thank you each.
-Baker




This communication, its contents and any file attachments transmitted with it are intended solely for the addressee(s) and may contain confidential proprietary information.
Access by any other party without the express written permission of the sender is STRICTLY PROHIBITED.
If you have received this communication in error you may not copy, distribute or use the contents, attachments or information in any way.  Please destroy it and contact the sender.
_______________________________________________
U2-Users mailing list
U2-Users@...
http://listserver.u2ug.org/mailman/listinfo/u2-users