Re: [U2] UniData PROC tip: DB command

[Susan Lynch]

Sorry, Clif, I was thinking UD, not UV - I am working in an almost entirely 
UD environment at this point.  I do have a UV proc manual - not as complete 
as the older Proc manuals but UV proc did, the last time I was on a UV 
system, behave as the other Proc flavors I had seen in the past.  UD, not so 
much...


Susan
- Original Message - 
From: "Clifton Oliver" <[EMAIL PROTECTED]>

To: 
Sent: 08/02/2008 5:55 PM
Subject: Re: [U2] UniData PROC tip: DB command



UniVerse has a Proc manual, except they call it "ProVerb" these days.
It is available for free from the IBM web site in the 10.2 (and
before) documentation set.

Not vouching for the quality, completeness, or accuracy, however.

Regards,

Clif

--
W. Clifton Oliver, CCP
CLIFTON OLIVER & ASSOCIATES
Tel: +1 619 460 5678Web: www.oliver.com




On Aug 2, 2008, at 10:46 AM, Susan Lynch wrote:


Now, not only are there no Proc manuals (

---
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] UniData PROC tip: DB command

[Clifton Oliver]

UniVerse has a Proc manual, except they call it "ProVerb" these days.  
It is available for free from the IBM web site in the 10.2 (and   
before) documentation set.

Not vouching for the quality, completeness, or accuracy, however.

Regards,

Clif

-- 
W. Clifton Oliver, CCP
CLIFTON OLIVER & ASSOCIATES
Tel: +1 619 460 5678Web: www.oliver.com




On Aug 2, 2008, at 10:46 AM, Susan Lynch wrote:

> Now, not only are there no Proc manuals (
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] UniData PROC tip: DB command

[MAJ Programming]

In my decades of MV programming, the manuals have gotten more scarce. I
recall the original Microdata manuals being pretty good but not perfect
enough. Thus JES was borne with their 'Pocket Guides' and other training
periphery.

I have total dislike for the UV/UD manuals as they break up the commands by
their stolen names for the obvious. UniBasic, UniQuery and ECL etc clearly
have their roots as Data/Basic, English and TCL.

Plus many commands are somewhat ambiguous and until recently, you struggle
to determine which specific book to pick up to review its index to find the
topic.

MVBase is similar. At least the D3 manual had one single index so that
SYSTEM (as a file name) is right next to SYSTEM() as a basic function and
you can go from there.

Nowadays, it should be easier and kept up to date far more easily with
on-line docs.

In the big picture, programmer's documentation can't be that much of a
profit center so the principals may not want to invest too heavily there.

A lot of this stagnation helps me believe that there is no future
development on the database side, just rather keeping the flame and putting
out fires (bugs).

One could argue that since there is no real advancing of Proc (or other
areas in the MV database) that the last real documentation (circa 1992?) may
be all that we need. If you lived through it, as I and many have, then it's
burned in our brains. If one is a new person to Pick, then there's the rub
to rely on oldies like me or forums or other folklore.

In a 'chicken and egg' situation, we should rely on each other and the
forums for more real-world experience with the subtle nuances of these
systems. I would bet that the vars like IBM and Raining Data (I know, TL)
appreciate the relief of not having to spend $ on supporting the past.

My free cents,
Mark Johnson
- Original Message -
From: "Susan Lynch" <[EMAIL PROTECTED]>
To: 
Sent: Saturday, August 02, 2008 1:46 PM
Subject: Re: [U2] UniData PROC tip: DB command


> Mark,
>
> A simple alternative to the "proc-to-Basic" convertor would be manuals -
if
> IBM would publish Proc and Paragraph manuals with the same level of
> completeness that the Basic Reference manual has, there would be far less
> frustration for the inheriting programmers.  I 'grew up' on Microdatas and
> Ultimates and Fujitsus and Sequoias and GA boxes, and never worked with
> anyone who used Paragraphs until my current position.  Now, not only are
> there no Proc manuals (and procs behave somewhat differently than expected
> from my past experience), but the Paragraph documentation does not come
> anywhere near the level of complexity in the Paragraphs that I am
> supporting, and I find myself frequently wondering what patches of
Paragraph
> code is doing.  Why are we dependant on oral tradition (or threads like
> this) rather than manuals for coding tools that are still functional?
>
> Susan Lynch
> F.W. Davison & Company, Inc.
> - Original Message -
> From: "MAJ Programming" <[EMAIL PROTECTED]>
> To: 
> Sent: 08/02/2008 12:57 PM
> Subject: Re: [U2] UniData PROC tip: DB command
>
>
> > Martin: These are some holy grails that would be wonderful if found.
> >
> > One client of mine that was on Results (Microdata) then Universe and is
> > now
> > on D3, still has the original Results PQN procs.
> >
> > Fortunately those procs did not use the extended &, # and ! variable
> > nomenclature but use the % nomenclature very often. Their solution
> > attacked
> > the MV command in this way:
> >
> > Original:
> > MV %1 "Mark"
> > New:
> > HMV %1 "Mark"
> > P
> >
> > whereby they had created a program called MV that would interpret the
> > request. It uses PROCREAD/WRITE. The downside is that this databasic
> > program
> > could not interpet MV &1.4 %10 or MV #1 "SORT MD" as it had no access to
> > those buffers.
> >
> > So one small step for mankind.
> >
> > Regarding "A" correlatives to I Descriptors. One of my clients uses
Media
> > Services Group's Advertising billing system and from the looks of the
> > code,
> > it used to be on R90 then Universe then now on Unidata. All of the
> > dictionary items that used to be "A" correlatives had gone through a
> > conversion utility to create the I descriptors. That utility saved on
line
> > 10 the original 10 line R90 dict item using IIRC value marks. Thus, the
> > original dict item (for me to more easily understand) exists on the
> > ignored
> > line 10.
> >
> > I never got good at the interpreted version of I descriptors (NEQS, EQS
> > and
> > the nested command structure) so I assumed that the conversion was okay.
I
> > write CALL I descriptors if the dict item gets busy.
> >
> > I will offer this though. As a straight programmer for individual
clients
> > (not a VAR, reseller or employee at one location), it may not be worth
it
> > to
> > 'fix what ain't broke' regarding replacing their working procs with all
> > data/basic.
> >
> > But I think it would be a matter of uniformity and forward compliance
f

Re: [U2] UniData PROC tip: DB command

[Susan Lynch]

Mark,

A simple alternative to the "proc-to-Basic" convertor would be manuals - if 
IBM would publish Proc and Paragraph manuals with the same level of 
completeness that the Basic Reference manual has, there would be far less 
frustration for the inheriting programmers.  I 'grew up' on Microdatas and 
Ultimates and Fujitsus and Sequoias and GA boxes, and never worked with 
anyone who used Paragraphs until my current position.  Now, not only are 
there no Proc manuals (and procs behave somewhat differently than expected 
from my past experience), but the Paragraph documentation does not come 
anywhere near the level of complexity in the Paragraphs that I am 
supporting, and I find myself frequently wondering what patches of Paragraph 
code is doing.  Why are we dependant on oral tradition (or threads like 
this) rather than manuals for coding tools that are still functional?


Susan Lynch
F.W. Davison & Company, Inc.
- Original Message - 
From: "MAJ Programming" <[EMAIL PROTECTED]>

To: 
Sent: 08/02/2008 12:57 PM
Subject: Re: [U2] UniData PROC tip: DB command



Martin: These are some holy grails that would be wonderful if found.

One client of mine that was on Results (Microdata) then Universe and is 
now

on D3, still has the original Results PQN procs.

Fortunately those procs did not use the extended &, # and ! variable
nomenclature but use the % nomenclature very often. Their solution 
attacked

the MV command in this way:

Original:
MV %1 "Mark"
New:
HMV %1 "Mark"
P

whereby they had created a program called MV that would interpret the
request. It uses PROCREAD/WRITE. The downside is that this databasic 
program

could not interpet MV &1.4 %10 or MV #1 "SORT MD" as it had no access to
those buffers.

So one small step for mankind.

Regarding "A" correlatives to I Descriptors. One of my clients uses Media
Services Group's Advertising billing system and from the looks of the 
code,

it used to be on R90 then Universe then now on Unidata. All of the
dictionary items that used to be "A" correlatives had gone through a
conversion utility to create the I descriptors. That utility saved on line
10 the original 10 line R90 dict item using IIRC value marks. Thus, the
original dict item (for me to more easily understand) exists on the 
ignored

line 10.

I never got good at the interpreted version of I descriptors (NEQS, EQS 
and

the nested command structure) so I assumed that the conversion was okay. I
write CALL I descriptors if the dict item gets busy.

I will offer this though. As a straight programmer for individual clients
(not a VAR, reseller or employee at one location), it may not be worth it 
to

'fix what ain't broke' regarding replacing their working procs with all
data/basic.

But I think it would be a matter of uniformity and forward compliance for
those VAR, reseller or employee-level members of this forum to engage in 
the

project of replacing procs with programs. For the VAR's, it would be a
continued investment in their product. For the employees, it would remove
one of the legacy entities that may become harder to find younger
programmers who can (or want to) understand Procs beyond the bvious
jobstreams.

My 3 cents
Mark Johnson
- Original Message -
From: "Martin Phillips" <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 01, 2008 2:56 PM
Subject: Re: [U2] UniData PROC tip: DB command



Hi,

> The man (person) who writes a PROC interpreter/conversion utility
> that can take a PROC and turn it into either Basic, or a PAragraph, 
> will

> have a product to sell... esp. if it can decipher all the PROC nuances

and

> tricks that have been introduced over the years.

Back in the days when I was working on the development of PI/open, I had 
a

go at this. It is not difficult to produce Basic code that does the same

job

as the Proc but producing good code rather than a simple step by step
interpretation of the Proc is difficult. Also, there are some strange
interactions between Procs and the underlying command environment that 
are

different from how Basic programs work so you can never get a true
replacement.

> Same goes for a tool to convert A correlatives to I-descriptors.

This is relatively easy. If you think there is a market, we might even do
it. We looked at this as part of the migration process for users moving 
to
OpenQM but we chose to implement correlatives instead as it was easy. 
Ours

are compiled (like an I-type) rather than interpretive for best

performance
so actually the task of writing the convertor is probably little more 
than

ripping apart our existing correlative compiler.

> But pity the wretch that is assigned the task of writing the tool to
> convert
> F correlatives.

This is probably easier than A correlatives. Again, if there is a real
market that would pay a sensible price for it, we might do it.


Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
+44-(0)1604-709200
---
u2-users mailing list
u2-

Re: [U2] UniData PROC tip: DB command

[MAJ Programming]

Martin: These are some holy grails that would be wonderful if found.

One client of mine that was on Results (Microdata) then Universe and is now
on D3, still has the original Results PQN procs.

Fortunately those procs did not use the extended &, # and ! variable
nomenclature but use the % nomenclature very often. Their solution attacked
the MV command in this way:

Original:
MV %1 "Mark"
New:
HMV %1 "Mark"
P

whereby they had created a program called MV that would interpret the
request. It uses PROCREAD/WRITE. The downside is that this databasic program
could not interpet MV &1.4 %10 or MV #1 "SORT MD" as it had no access to
those buffers.

So one small step for mankind.

Regarding "A" correlatives to I Descriptors. One of my clients uses Media
Services Group's Advertising billing system and from the looks of the code,
it used to be on R90 then Universe then now on Unidata. All of the
dictionary items that used to be "A" correlatives had gone through a
conversion utility to create the I descriptors. That utility saved on line
10 the original 10 line R90 dict item using IIRC value marks. Thus, the
original dict item (for me to more easily understand) exists on the ignored
line 10.

I never got good at the interpreted version of I descriptors (NEQS, EQS and
the nested command structure) so I assumed that the conversion was okay. I
write CALL I descriptors if the dict item gets busy.

I will offer this though. As a straight programmer for individual clients
(not a VAR, reseller or employee at one location), it may not be worth it to
'fix what ain't broke' regarding replacing their working procs with all
data/basic.

But I think it would be a matter of uniformity and forward compliance for
those VAR, reseller or employee-level members of this forum to engage in the
project of replacing procs with programs. For the VAR's, it would be a
continued investment in their product. For the employees, it would remove
one of the legacy entities that may become harder to find younger
programmers who can (or want to) understand Procs beyond the bvious
jobstreams.

My 3 cents
Mark Johnson
- Original Message -
From: "Martin Phillips" <[EMAIL PROTECTED]>
To: 
Sent: Friday, August 01, 2008 2:56 PM
Subject: Re: [U2] UniData PROC tip: DB command


> Hi,
>
> > The man (person) who writes a PROC interpreter/conversion utility
> > that can take a PROC and turn it into either Basic, or a PAragraph, will
> > have a product to sell... esp. if it can decipher all the PROC nuances
and
> > tricks that have been introduced over the years.
>
> Back in the days when I was working on the development of PI/open, I had a
> go at this. It is not difficult to produce Basic code that does the same
job
> as the Proc but producing good code rather than a simple step by step
> interpretation of the Proc is difficult. Also, there are some strange
> interactions between Procs and the underlying command environment that are
> different from how Basic programs work so you can never get a true
> replacement.
>
> > Same goes for a tool to convert A correlatives to I-descriptors.
>
> This is relatively easy. If you think there is a market, we might even do
> it. We looked at this as part of the migration process for users moving to
> OpenQM but we chose to implement correlatives instead as it was easy. Ours
> are compiled (like an I-type) rather than interpretive for best
performance
> so actually the task of writing the convertor is probably little more than
> ripping apart our existing correlative compiler.
>
> > But pity the wretch that is assigned the task of writing the tool to
> > convert
> > F correlatives.
>
> This is probably easier than A correlatives. Again, if there is a real
> market that would pay a sensible price for it, we might do it.
>
>
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB
> +44-(0)1604-709200
> ---
> 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] Wondering why select is not working

[Trevor Fulton]

I think its because the 8a with a LIKE is interpreted as a pattern
match, try the following

SELECT B10.COMMONAPP WITH AVAILABILITY = "[8a]"

Trevor.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anthony W.
Youngman
Sent: 01 August 2008 22:57
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Wondering why select is not working

In message <[EMAIL PROTECTED]>, Jon Wells 
<[EMAIL PROTECTED]> writes
>Hi all,
>
>We have a file (Unidata 7.1) called B10.COMMONAPP where a MV'd
attribute
>called AVAILABILITY contains values representing a day and time.
>
>AE DICT B10.COMMONAPP AVAILABILITY
>Top of "AVAILABILITY" in "DICT B10.COMMONAPP", 6 lines, 24 characters.
>*--: P
>001: D
>002: 63
>003:
>004: AVAILABILITY
>005: 10L
>006: M
>Bottom.
>
>Example record -->
>
>063:
>sun8a}mon8a}tue8a}wed8a}thu8a}fri8a}sat8a}sun830a}mon830a}tue830a}wed83
0a}th
>u830a}fri830a}sat830a}sun9a}mon9a}tue9a}wed9a}thu9a}fri9a}sat9a}sun930a
}mon9
>30a}tue930a}wed930a}thu930a}fri930a}sat930a}sun10a}mon10a}tue10a}wed10a
}thu1
>0a}fri10a}sat10a}sun1030a}mon1030a}tue1030a}wed1030a}thu1030a}fri1030a}
sat10
>30a}sun11a}sat11a}sun1130a}sat1130a}sun12p}sat12p}sun1230p}sat1230p}sun
1p}sa
>t1p}sun130p}sat130p}sun2p}sat2p}sun230p}sat230p}sun3p}sat3p}sun330p}sat
330p}
>sun4p}sat4p}sun430p}sat430p}sun5p}sat5p}sun530p}sat530p}sun6p}sat6p}sun
630p}
>mon630p}tue630p}wed630p}thu630p}fri630p}sat630p}sun7p}mon7p}tue7p}wed7p
}thu7
>p}fri7p}sat7p}sun730p}mon730p}tue730p}wed730p}thu730p}fri730p}sat730p}s
un8p}
>mon8p}tue8p}wed8p}thu8p}fri8p}sat8p}sun830p}mon830p}tue830p}wed830p}thu
830p}
>fri830p}sat830p
>Bottom.
>
>Can anyone tell us why ->
>SELECT B10.COMMONAPP WITH AVAILABILITY LIKE "...8a..."
>
>Produces->
>
>No data retrieved from current (S)SELECT statement.
>
>Thanks,
>
The SELECT isn't doing what you think ...

What you need is
SELECT B10.COMMONAPP WITH AVAILABILITY LIKE "...'8a'..."
Note the single quotes around the '8a'

What you've actually asked for is any AVAILABITY that contains an 
8-alpha string. I got bitten by that *many* years ago ... I've always 
remembered it ...

Cheers,
Wp;
-- 
Anthony W. Youngman <[EMAIL PROTECTED]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The
man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source
Pick
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Epicor Software (UK) is a limited company registered in England & Wales.  
Registration Number: 2338274.   Registered Office:  Osborne Clarke OWA, One 
London Wall, London EC2Y 5EB 
This e-mail is for the use of the intended recipient(s) only. If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it. If you are not the intended recipient, you must not use, disclose or 
distribute this e-mail without the author's prior permission. We have taken 
precautions to minimize the risk of transmitting software viruses, but we 
advise you to carry out your own virus checks on any attachment to this 
message. We cannot accept liability for any loss or damage caused by software 
viruses. Any views and/or opinions expressed in this e-mail are of the author 
only and do not represent the views of Epicor Software (UK) Limited or any 
other company within its group.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] uniobjects help needed!

[Horacio Pellegrino]

Do you have that problem in what exact instruction? 

Please copy & paste.

Horacio



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of doug chanco
Sent: Saturday, August 02, 2008 7:35 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] uniobjects help needed!

Hey,

We are having a problem with uniobjects that started a couple of days 
ago. We have a VB app that uses uniobjects to access an aix system 
running universe 10.1 and a few days ago we started getting errors where 
uniobjects would just die, its starting to look like it might be a 
network issue but so far nothing we can discover.

Our Cisco guy is not seeing any errors in the cisco switches, I am not 
seeing any errors on the aix system (5.2.6).

While is may or may not be a universe/uniobjects issue, so far we have 
been stumped as to what the problem is. We even called an IBM uniobjects 
engineer for several hours and he could not find a problem as neither 
could our VAR or IBM tech support for aix.

So I thought I would throw this out to youll who vast knowledge may 
hold the key to the answers we seek! The fact that in the past 3 days I 
have works close to 60 hours is a testimony to the amount of effort we 
have been putting in to try and solve this problem.

Basically what we are seeing that is

Run-TIme error '-2147417848 (80010108)':
Method 'Read' of object 'IUniFileEx' Failed

So any suggestions/thoughts/ideas/crystal balls/magic spells/voodoo 
chants are welcomed!

dougc
---
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] uniobjects help needed!

[Mike Dallaire]

Doug,
I don't know if this will help, but we had similar issues caused by the way
uo.net handles locking.  If you read and lock a record using one uo.net
connection (using an exclusive read lock) and try to read it using a
different uo.net connection it will not be able to read it.  IIRC it will
hang, waiting for the lock to be released.  Each uo.net connection uses a
different pid, therefore in essence is seen as a different user.
We had to use a method where we make the connection, read the record and
lock it using a different method, controlling the locking internally, and
then disconnect the uo.net session.  
We have requested an enhancement from IBM on this issue, but I am not sure
where it stands.
HTH,
Mike

Michael Dallaire
Senior Applications Developer
IBM Certified Solutions Expert
Mortgage Builder Software, Inc.
Phone: (248) 304-0600 x 103
Fax: (248) 304-0601
[EMAIL PROTECTED]
www.mortgagebuilder.com
 
Providing Outstanding Support 
It's more than just a company philosophy; it's a whole corporate culture
whose foundation is service.
 
Confidentiality Notice 
This transmission may contain confidential information which is intended for
the exclusive use of the intended recipient. Any disclosure, copying,
distribution or use of the contents by anyone other than the intended
recipient is strictly prohibited. If received in error, please reply to the
sender immediately.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of doug chanco
Sent: Saturday, August 02, 2008 10:35 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] uniobjects help needed!

Hey,

We are having a problem with uniobjects that started a couple of days 
ago. We have a VB app that uses uniobjects to access an aix system 
running universe 10.1 and a few days ago we started getting errors where 
uniobjects would just die, its starting to look like it might be a 
network issue but so far nothing we can discover.

Our Cisco guy is not seeing any errors in the cisco switches, I am not 
seeing any errors on the aix system (5.2.6).

While is may or may not be a universe/uniobjects issue, so far we have 
been stumped as to what the problem is. We even called an IBM uniobjects 
engineer for several hours and he could not find a problem as neither 
could our VAR or IBM tech support for aix.

So I thought I would throw this out to youll who vast knowledge may 
hold the key to the answers we seek! The fact that in the past 3 days I 
have works close to 60 hours is a testimony to the amount of effort we 
have been putting in to try and solve this problem.

Basically what we are seeing that is

Run-TIme error '-2147417848 (80010108)':
Method 'Read' of object 'IUniFileEx' Failed

So any suggestions/thoughts/ideas/crystal balls/magic spells/voodoo 
chants are welcomed!

dougc
---
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] uniobjects help needed!

[doug chanco]

Hey,

We are having a problem with uniobjects that started a couple of days 
ago. We have a VB app that uses uniobjects to access an aix system 
running universe 10.1 and a few days ago we started getting errors where 
uniobjects would just die, its starting to look like it might be a 
network issue but so far nothing we can discover.


Our Cisco guy is not seeing any errors in the cisco switches, I am not 
seeing any errors on the aix system (5.2.6).


While is may or may not be a universe/uniobjects issue, so far we have 
been stumped as to what the problem is. We even called an IBM uniobjects 
engineer for several hours and he could not find a problem as neither 
could our VAR or IBM tech support for aix.


So I thought I would throw this out to youll who vast knowledge may 
hold the key to the answers we seek! The fact that in the past 3 days I 
have works close to 60 hours is a testimony to the amount of effort we 
have been putting in to try and solve this problem.


Basically what we are seeing that is

Run-TIme error '-2147417848 (80010108)':
Method 'Read' of object 'IUniFileEx' Failed

So any suggestions/thoughts/ideas/crystal balls/magic spells/voodoo 
chants are welcomed!


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