[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access

Jan Moeyersons

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access

Esteemed Listers,

I have 23 identical tables in databases (libraries) on two different iSeries. I need to get a few columns from a few rows from these tables in a program running in CICS on mainframe. 

I have set up two remote locations in the communication DB on z/OS and have defined 23 aliases on z/OS to avoid having to specify three-part names in my SQL query. So far, so good; I can access the 23 tables and query them as I need. Now comes the optimising.

In my use case, every time the program needs to query the remote table, it knows a code that allows to identify the one remote database that contains the data of interest and the result set is only a few rows all coming from the one table. Obviously, from one run to the next, this code and, hence the database from where the data must be fetched, can change.

I am thinking the lazy programmer would like to write just one SELECT with a WHERE clause of the form:

WHERE REMOTE_ORIGIN = 'code-that-identifies-the-DB' AND <all-the-other-criteria>

and I thought that would be possible by creating a view of the form:

CREATE VIEW MYVIEW (REMOTE_ORIGIN, C1, C2, C3) AS

SELECT CAST(1 AS SMALLINT), C1, C2,C3) FROM ALIAS_ONE

UNION ALL

SELECT CAST(2 AS SMALLINT), C1, C2,C3) FROM ALIAS_TWO

UNION ALL

SELECT CAST(3 AS SMALLINT), C1, C2,C3) FROM ALIAS_THREE

UNION ALL

etc. until 23... ;

Now, if I do that, there is a performance problem. Indeed, when a 

SELECT C2, C3 FROM MYVIEW

WHERE REMOTE_ORIGIN = 2 AND C1 = 75 ;

is run, all 23 remote tables will be interrogated to see if there are rows that have C1 = 75 while only those coming from ALIAS_ONE will ever make it to the final result set.

Is there any way of creating a view or any other construct that would avoid accessing the other tables?

Thanks and very best regards,

Jantje.

 

 

Philip Sevetson

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)
Jan,

For a truly lazy programmer, you might want to create an index on each table, containing the code. Presto: DB2-i interrogates the index on each of 23 tables, and a dozen milliseconds later 22 of them are done processing.

If this is not feasible, you could achieve the “don’t query 22 of the 23 tables” result by writing a stored procedure in your local subsystem which accepts the code (and any other criteria), and uses logic to determine which table to query.

--Phil S.

From: Jan Moeyersons [mailto:[login to unmask email]
Sent: Tuesday, July 10, 2018 10:22 AM
To: [login to unmask email]
Subject: [DB2-L] - [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access


Esteemed Listers,

I have 23 identical tables in databases (libraries) on two different iSeries. I need to get a few columns from a few rows from these tables in a program running in CICS on mainframe.

I have set up two remote locations in the communication DB on z/OS and have defined 23 aliases on z/OS to avoid having to specify three-part names in my SQL query. So far, so good; I can access the 23 tables and query them as I need. Now comes the optimising.

In my use case, every time the program needs to query the remote table, it knows a code that allows to identify the one remote database that contains the data of interest and the result set is only a few rows all coming from the one table. Obviously, from one run to the next, this code and, hence the database from where the data must be fetched, can change.

I am thinking the lazy programmer would like to write just one SELECT with a WHERE clause of the form:

WHERE REMOTE_ORIGIN = 'code-that-identifies-the-DB' AND

and I thought that would be possible by creating a view of the form:

CREATE VIEW MYVIEW (REMOTE_ORIGIN, C1, C2, C3) AS

SELECT CAST(1 AS SMALLINT), C1, C2,C3) FROM ALIAS_ONE

UNION ALL

SELECT CAST(2 AS SMALLINT), C1, C2,C3) FROM ALIAS_TWO

UNION ALL

SELECT CAST(3 AS SMALLINT), C1, C2,C3) FROM ALIAS_THREE

UNION ALL

etc. until 23... ;

Now, if I do that, there is a performance problem. Indeed, when a

SELECT C2, C3 FROM MYVIEW

WHERE REMOTE_ORIGIN = 2 AND C1 = 75 ;

is run, all 23 remote tables will be interrogated to see if there are rows that have C1 = 75 while only those coming from ALIAS_ONE will ever make it to the final result set.

Is there any way of creating a view or any other construct that would avoid accessing the other tables?

Thanks and very best regards,

Jantje.





-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Jan Moeyersons

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Philip Sevetson)

Dear Phil,

The index option is not really on, because the code that distinguishes between the 23 possible origins is not in the tables; it is constructed by the view itself. Anyway, it still requires 23 exchanges between mainframe and iSeries. I would like to avoid that.

The stored procedure has crossed my mind, but I am not clear on how I am going to push down the WHERE clauses the program will need. Indeed, the selection criteria may not be fixed at the time of writing of the stored procedure. Would there be a way of receiving them as arguments to the stored proc and (dynamically?) pushing them down to the SELECT that will be shipped over to the iSeries?

Thanks,

Jantje


In Reply to Philip Sevetson:

Jan,

For a truly lazy programmer, you might want to create an index on each table, containing the code. Presto: DB2-i interrogates the index on each of 23 tables, and a dozen milliseconds later 22 of them are done processing.

If this is not feasible, you could achieve the “don’t query 22 of the 23 tables” result by writing a stored procedure in your local subsystem which accepts the code (and any other criteria), and uses logic to determine which table to query.

--Phil S.

Philip Sevetson

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)
Jan,

Do you use REXX or Python or some general scripting language with a database link, in iSeries world? REXX is acceptable in z/OS SPs and can construct SQL on the fly, which sounds like what you need.

Based on the determinant code values not being in the data, I _think_ you’re at a case where you need either an interpreted language in the SP, or at the absolute least, the ability to PREPARE a SQL statement in the SP.

--Phil

From: Jan Moeyersons [mailto:[login to unmask email]
Sent: Tuesday, July 10, 2018 11:17 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access


Dear Phil,

The index option is not really on, because the code that distinguishes between the 23 possible origins is not in the tables; it is constructed by the view itself. Anyway, it still requires 23 exchanges between mainframe and iSeries. I would like to avoid that.

The stored procedure has crossed my mind, but I am not clear on how I am going to push down the WHERE clauses the program will need. Indeed, the selection criteria may not be fixed at the time of writing of the stored procedure. Would there be a way of receiving them as arguments to the stored proc and (dynamically?) pushing them down to the SELECT that will be shipped over to the iSeries?

Thanks,

Jantje

In Reply to Philip Sevetson:
Jan,

For a truly lazy programmer, you might want to create an index on each table, containing the code. Presto: DB2-i interrogates the index on each of 23 tables, and a dozen milliseconds later 22 of them are done processing.

If this is not feasible, you could achieve the “don’t query 22 of the 23 tables” result by writing a stored procedure in your local subsystem which accepts the code (and any other criteria), and uses logic to determine which table to query.

--Phil S.

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Jan Moeyersons

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Philip Sevetson)

Dear Phil,

At this stage, I am using SPUFI on mainframe, just to test feasibility. Ultimately, it will be a COBOL program running in CICS that will actually do the querying.

I was hoping to keep the complexity out of the program, but from the looks of it, I think indeed, you're right and we will need to go with a PREPARE.

Thanks for the suggestions and very best regards,

Jantje.

 


In Reply to Philip Sevetson:

Jan,

Do you use REXX or Python or some general scripting language with a database link, in iSeries world? REXX is acceptable in z/OS SPs and can construct SQL on the fly, which sounds like what you need.

Based on the determinant code values not being in the data, I _think_ you’re at a case where you need either an interpreted language in the SP, or at the absolute least, the ability to PREPARE a SQL statement in the SP.

--Phil

Philip Sevetson

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)
Jan,

My pleasure. Also - put the list of codes and servers in a table. You know that if you hard code it, the minute it’s committed to production, someone’s going to add another server!!!

--Phil the Pessimistic

From: Jan Moeyersons [mailto:[login to unmask email]
Sent: Wednesday, July 11, 2018 9:59 AM
To: [login to unmask email]
Subject: [DB2-L] - RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access


Dear Phil,

At this stage, I am using SPUFI on mainframe, just to test feasibility. Ultimately, it will be a COBOL program running in CICS that will actually do the querying.

I was hoping to keep the complexity out of the program, but from the looks of it, I think indeed, you're right and we will need to go with a PREPARE.

Thanks for the suggestions and very best regards,

Jantje.



In Reply to Philip Sevetson:
Jan,

Do you use REXX or Python or some general scripting language with a database link, in iSeries world? REXX is acceptable in z/OS SPs and can construct SQL on the fly, which sounds like what you need.

Based on the determinant code values not being in the data, I _think_ you’re at a case where you need either an interpreted language in the SP, or at the absolute least, the ability to PREPARE a SQL statement in the SP.

--Phil

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

JITINDER CHOUDHARY

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Philip Sevetson)

Can we use Python also in place of REXX? 

Philip Sevetson

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to JITINDER CHOUDHARY)
That’s a read-the-manual question, sorry.

The two questions are, whether Python is compiled for iSeries, and whether its database calls will talk to IBM (without an intermediary product). Rocket Software is handling Python for IBM, and I know they have an implementation for zSeries, but I don’t know about the i-machines.

--Phil

From: JITINDER CHOUDHARY [mailto:[login to unmask email]
Sent: Wednesday, July 11, 2018 1:46 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access


Can we use Python also in place of REXX?

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Michael Hannan

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)

In Reply to Jan Moeyersons:

I am thinking the lazy programmer would like to write just one SELECT with a WHERE clause of the form:

 

The joys of distributed data. LOL

I am thinking if the programmer is that lazy, you had better code the 23 variations yourself. If performance is not critical could be a single Dynamic SQL modified by the program. Must have been critical otherwise your Union would be O.K., right?

So in my opinion, a View on 23 tables is not the way to go. It is possible to put the 23 SQLs in a Stored Proc I am sure, but not sure why. Stored Procs are mainly to reduce extra Comms interactions between Client and server, although can do other fancy things when really needed.

You could make use of a view on a single table to provide a level of independence and Obfuscation, and so you can more than 23 to provide for the future. Then you need a lookup of which SQL View to use in which case.

Maybe you have simplified the real problem. Maybe there is not just one table with a set of the 23 copies?

If queries on the set of 23 tables, were super critical for performance, I would consider propagating copies of the data changes so that can be queried from one place only, by simplest possible Static SQL. Depends if Update performance or Query performance is critical.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Jul 12, 2018 - 03:38 AM (Europe/Berlin)

Jan Moeyersons

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Philip Sevetson)

Been there, done that. Still wearing the scars of it, too...

Jantje.


In Reply to Philip Sevetson:

Jan,

My pleasure. Also - put the list of codes and servers in a table. You know that if you hard code it, the minute it’s committed to production, someone’s going to add another server!!!

--Phil the Pessimistic

Jan Moeyersons

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Michael Hannan)

Dear Michael,

Yes, performance is rather critical, indeed. And tests indeed prove the view approach is a bit detrimental to that.

I have considered a stored proc, but I am afraid that is just shifting the problem, not solving it. The logic of selecting the correct destination is still there in the program, be it the stored program. It may well cause more grieve because then it will be my fault...

I did simplify the problem, but not much, BTW.

We have looked into replication too, but rejected it for cost of licence and effort of installation and tuning (it would be the first replication on those machines and we would explose the budget of the project). It would mean we would be sending hundreds of thousands of updates over to the mainframe, where in the end, we would run only a few thousand queries a day (that is not so many queries, I agree, but when we need to query, we need to be quick). Seems a bit of over the top.

 

Thanks for the suggestions,

Jantje.

 


In Reply to Michael Hannan:

The joys of distributed data. LOL

I am thinking if the programmer is that lazy, you had better code the 23 variations yourself. If performance is not critical could be a single Dynamic SQL modified by the program. Must have been critical otherwise your Union would be O.K., right?

So in my opinion, a View on 23 tables is not the way to go. It is possible to put the 23 SQLs in a Stored Proc I am sure, but not sure why. Stored Procs are mainly to reduce extra Comms interactions between Client and server, although can do other fancy things when really needed.

You could make use of a view on a single table to provide a level of independence and Obfuscation, and so you can more than 23 to provide for the future. Then you need a lookup of which SQL View to use in which case.

Maybe you have simplified the real problem. Maybe there is not just one table with a set of the 23 copies?

If queries on the set of 23 tables, were super critical for performance, I would consider propagating copies of the data changes so that can be queried from one place only, by simplest possible Static SQL. Depends if Update performance or Query performance is critical.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

J&#248;rn Thyssen

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to JITINDER CHOUDHARY)

Check the 5733-OPS option for IBM i

In Reply to JITINDER CHOUDHARY:

Can we use Python also in place of REXX? 



 

Best regards,

Jørn Thyssen

Rocket Software
77 Fourth Avenue • Waltham, MA • 02451 • USA
E: [login to unmask email] • W: www.rocketsoftware.com 

2018 IBM Champion.

Views are personal. 

Michael Hannan

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)

In Reply to Jan Moeyersons:

Yes, performance is rather critical, indeed.

I did simplify the problem, but not much, BTW.

We have looked into replication too, but rejected it for cost of licence and effort of installation and tuning (it would be the first replication on those machines and we would explose the budget of the project). It would mean we would be sending hundreds of thousands of updates over to the mainframe, where in the end, we would run only a few thousand queries a day (that is not so many queries, I agree, but when we need to query, we need to be quick). Seems a bit of over the top.

You don't have to buy a replication product. You can use triggers to detect updates, and then decide what to do to send the updates to other subsystems. A bit manual, meaning you have to write some application code, but can be workable especially if updates are very infrequent compared to the queries.  I am assuming you don't have a large number of tables, each with 23 copies.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Edited By:
Michael Hannan[Organization Members] @ Jul 14, 2018 - 09:12 AM (Europe/Berlin)

Jan Moeyersons

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Michael Hannan)

Dear Michael,

Yes, I know, unfortunately, we do have a rather high number of updates and a comparatively low number of queries. The overhead of the trigger and "replication" update would turn out too costly in CPU cycles (which cost €€€…)

Cheers,

Jantje.


In Reply to Michael Hannan:

You don't have to buy a replication product. You can use triggers to detect updates, and then decide what to do to send the updates to other subsystems. A bit manual, meaning you have to write some application code, but can be workable especially if updates are very infrequent compared to the queries.  I am assuming you don't have a large number of tables, each with 23 copies.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Michael Hannan

RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Jan Moeyersons)

In Reply to Jan Moeyersons:

Dear Michael,

Yes, I know, unfortunately, we do have a rather high number of updates and a comparatively low number of queries. The overhead of the trigger and "replication" update would turn out too costly in CPU cycles (which cost €€€…)

Cheers,

Jantje.

 

If you have high updates, and low queries, then there does not seem at first glance to be a big problem. You then don't have to have the best performing query in the world. You could use any reasonable alternative that works. 23 separate SQLs or a Dynamic SQL. You get some zIIP offload for Client Server.

Fix what really matters.

Michael Hannan,
DB2 Application Performance Specialist
CPT Global Ltd

Jim Tonchick

[DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access
(in response to Philip Sevetson)
The IBMi does support Phyhon. Here are a couple of links from a simple Google search.

Talk to your local IBMi Sysadmin to see if your target systems have what is needed.

<div>http://ibmsystemsmag.com/ibmi/developer/general/python-intro/

http://ibmsystemsmag.com/ibmi/developer/general/different-world-python/


https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/Python


-----Original Message-----
From: Sevetson, Phil <[login to unmask email]>
To: '[login to unmask email]' <[login to unmask email]>
Sent: Wed, Jul 11, 2018 12:50 PM
Subject: [DB2-L] - RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access



<div id="AOLMsgPart_2_f152a3c4-0ec8-49e6-b7f6-9b5459e8e1fb">
<style scoped="">#AOLMsgPart_2_f152a3c4-0ec8-49e6-b7f6-9b5459e8e1fb td{color: black;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;}.aolReplacedBody p.aolmail_MsoNormal,.aolReplacedBody li.aolmail_MsoNormal,.aolReplacedBody div.aolmail_MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";}.aolReplacedBody a:link,.aolReplacedBody span.aolmail_MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}.aolReplacedBody a:visited,.aolReplacedBody span.aolmail_MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;}.aolReplacedBody p {mso-style-priority:99; mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman","serif";}.aolReplacedBody span.aolmail_EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;}.aolReplacedBody .aolmail_MsoChpDefault {mso-style-type:export-only; font-family:"Calibri","sans-serif";}@page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}.aolReplacedBody div.aolmail_WordSection1 {page:WordSection1;}</style><div lang="EN-US" class="aolReplacedBody">
<div class="aolmail_WordSection1">
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">That’s a read-the-manual question, sorry.
</span></p>
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The two questions are, whether Python is compiled for iSeries, and whether its database calls will talk to IBM (without an intermediary product). Rocket Software
is handling Python for IBM, and I know they have an implementation for zSeries, but I don’t know about the i-machines.</span></p>
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--Phil</span></p>
<p class="aolmail_MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span></p>
<p class="aolmail_MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> JITINDER CHOUDHARY [<a href="mailto:[login to unmask email]?">mailto:[login to unmask email]</a>]


<b>Sent:</b> Wednesday, July 11, 2018 1:46 PM

<b>To:</b> DB2-<a href="mailto:[login to unmask email]">[login to unmask email]</a>

<b>Subject:</b> [DB2-L] - RE: [DB2 11 z/OS and iSeries V7R2] remote access, a view and how to optimise access</span></p>
<p class="aolmail_MsoNormal"> </p>
<p>Can we use Python also in place of REXX? </p>
<p class="aolmail_MsoNormal"> </p>
<div class="aolmail_MsoNormal" align="center" style="text-align:center">
<div align="left">-----End Original Message-----
</div>
</div>
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate,
copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

<hr size="1" style="color:#ccc"><div id="aolmail_socfooter" style="font-size:80%"><span style="font-weight:bold">Site Links: </span>
<a target="_blank" rel="noopener noreferrer" href="https://www.idug.org/p/fo/st/?post=186428&anc=p186428#p186428">View post online</a>
<a target="_blank" rel="noopener noreferrer" href="https://www.idug.org/p/fo/si/?topic=19">View mailing list online</a>
<a target="_blank" rel="noopener noreferrer" href="mailto:[login to unmask email]">Start new thread via email</a>
<a target="_blank" rel="noopener noreferrer" href="mailto:[login to unmask email]?Subject=Unsubscribe">Unsubscribe from this mailing list</a>
<a target="_blank" rel="noopener noreferrer" href="https://www.idug.org/p/us/to/">Manage your subscription</a>


This email has been sent to: <a href="mailto:[login to unmask email]">[login to unmask email]</a>
<p>
** ** ** IDUG Db2 Tech Conference in Sydney, Australia 2018 ** ** **

---> Sydney, Australia 11 - 13 September, 2018 <---

<a target="_blank" rel="noopener noreferrer" href="http://www.idug.org/au">http://www.idug.org/au</a>

</p>
<p>
Use of this email content is governed by the terms of service at:
<a target="_blank" rel="noopener noreferrer" href="http://www.idug.org/p/cm/ld/fid=2">http://www.idug.org/p/cm/ld/fid=2</a></p>

</div><hr size="1" style="color:#ccc">

</div>
</div>
</div></div>