You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@daffodil.apache.org by Peter Kostouros <Pe...@awta.com.au> on 2021/05/13 02:27:42 UTC

CLI and JAVA API parsing not exiting

Hi

I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.

I have modified the NACHA schemas to demonstrate this behaviour.


The basic changes made were:

1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).

The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).

The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.


The test is run from the command line as

sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt

with the files under a child directory from where the daffodil program resides.

I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.


I have attached the relevant files used in testing.


Please let me know what I am missing.


Peter



This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.

Re: CLI and JAVA API parsing not exiting

Posted by Steve Lawrence <sl...@apache.org>.
Glad to hear 3.1.0 worked.

Thanks for letting us know about the FreeBSD issue. I've opened a ticket
to track the FreeBSD build issue:

https://issues.apache.org/jira/browse/DAFFODIL-2516



On 5/14/21 6:01 AM, Peter Kostouros wrote:
> Hi
> 
> Thanks. I ran the tests against the new version (3.1.0) and they worked as expected.
> 
> As an aside, I could not build the system from the latest source published on github on a FreeBSD system as:
> 
> 1. It looked like the runtime2 C code was looking for the Mini-XML dependencies under /usr whereas the package on FreeBSD is stored under /usr/local, and;
> 2. Some C files under runtime2 were including <endian.h> whereas the file was under /usr/local/sys.
> 
> I made some changes to the relevant make file and some C files and was able to build the system.
> 
> 
> Peter
> 
> ________________________________________
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, May 13, 2021 9:57 PM
> To: users@daffodil.apache.org
> Subject: Re: CLI and JAVA API parsing not exiting
> 
> We actually recently fixed a bug that sounds like it might be related to
> the issue you're seeing. I've tested your schema/files with the latest
> development branch, and both the valid files parse successfully and the
> invalid file fails with an assertion error. So I think fixing that bug
> may have fixed the issue you're seeing.
> 
> We are actually going through a release vote on the
> dev@daffodil.apache.org mailing list for the 3.1.0 version of Daffodil
> right now, with a the release candidate available here:
> 
>   https://daffodil.apache.org/releases/3.1.0/
> 
> That release does contain the fix for the known hang issue. I'm not too
> familiar with NACHA, but if you could try downloading the release
> candidate and see if it solves the problem that would be really helpful.
> 
> - Steve
> 
> 
> On 5/12/21 10:27 PM, Peter Kostouros wrote:
>> Hi
>>
>> I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.
>>
>> I have modified the NACHA schemas to demonstrate this behaviour.
>>
>>
>> The basic changes made were:
>>
>> 1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
>> 2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
>> 3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
>> 4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).
>>
>> The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).
>>
>> The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.
>>
>>
>> The test is run from the command line as
>>
>> sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt
>>
>> with the files under a child directory from where the daffodil program resides.
>>
>> I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.
>>
>>
>> I have attached the relevant files used in testing.
>>
>>
>> Please let me know what I am missing.
>>
>>
>> Peter
>>
>>
>>
>> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
>>
> 
> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
> 


Re: CLI and JAVA API parsing not exiting

Posted by Steve Lawrence <sl...@apache.org>.
Thanks for the correction. I've updated the ticket.

- Steve

On 5/14/21 7:09 PM, Peter Kostouros wrote:
> Hi
> 
> A correction on Point 2. The included file endian.h can be found under /usr/include/sys on a FBSD system.
> 
> 
> Peter
> 
> ________________________________________
> From: Peter Kostouros
> Sent: Friday, May 14, 2021 8:01 PM
> To: users@daffodil.apache.org
> Subject: Re: CLI and JAVA API parsing not exiting
> 
> Hi
> 
> Thanks. I ran the tests against the new version (3.1.0) and they worked as expected.
> 
> As an aside, I could not build the system from the latest source published on github on a FreeBSD system as:
> 
> 1. It looked like the runtime2 C code was looking for the Mini-XML dependencies under /usr whereas the package on FreeBSD is stored under /usr/local, and;
> 2. Some C files under runtime2 were including <endian.h> whereas the file was under /usr/local/sys.
> 
> I made some changes to the relevant make file and some C files and was able to build the system.
> 
> 
> Peter
> 
> ________________________________________
> From: Steve Lawrence <sl...@apache.org>
> Sent: Thursday, May 13, 2021 9:57 PM
> To: users@daffodil.apache.org
> Subject: Re: CLI and JAVA API parsing not exiting
> 
> We actually recently fixed a bug that sounds like it might be related to
> the issue you're seeing. I've tested your schema/files with the latest
> development branch, and both the valid files parse successfully and the
> invalid file fails with an assertion error. So I think fixing that bug
> may have fixed the issue you're seeing.
> 
> We are actually going through a release vote on the
> dev@daffodil.apache.org mailing list for the 3.1.0 version of Daffodil
> right now, with a the release candidate available here:
> 
>   https://daffodil.apache.org/releases/3.1.0/
> 
> That release does contain the fix for the known hang issue. I'm not too
> familiar with NACHA, but if you could try downloading the release
> candidate and see if it solves the problem that would be really helpful.
> 
> - Steve
> 
> 
> On 5/12/21 10:27 PM, Peter Kostouros wrote:
>> Hi
>>
>> I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.
>>
>> I have modified the NACHA schemas to demonstrate this behaviour.
>>
>>
>> The basic changes made were:
>>
>> 1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
>> 2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
>> 3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
>> 4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).
>>
>> The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).
>>
>> The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.
>>
>>
>> The test is run from the command line as
>>
>> sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt
>>
>> with the files under a child directory from where the daffodil program resides.
>>
>> I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.
>>
>>
>> I have attached the relevant files used in testing.
>>
>>
>> Please let me know what I am missing.
>>
>>
>> Peter
>>
>>
>>
>> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
>>
> 
> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
> 


Re: CLI and JAVA API parsing not exiting

Posted by Peter Kostouros <Pe...@awta.com.au>.
Hi

A correction on Point 2. The included file endian.h can be found under /usr/include/sys on a FBSD system.


Peter

________________________________________
From: Peter Kostouros
Sent: Friday, May 14, 2021 8:01 PM
To: users@daffodil.apache.org
Subject: Re: CLI and JAVA API parsing not exiting

Hi

Thanks. I ran the tests against the new version (3.1.0) and they worked as expected.

As an aside, I could not build the system from the latest source published on github on a FreeBSD system as:

1. It looked like the runtime2 C code was looking for the Mini-XML dependencies under /usr whereas the package on FreeBSD is stored under /usr/local, and;
2. Some C files under runtime2 were including <endian.h> whereas the file was under /usr/local/sys.

I made some changes to the relevant make file and some C files and was able to build the system.


Peter

________________________________________
From: Steve Lawrence <sl...@apache.org>
Sent: Thursday, May 13, 2021 9:57 PM
To: users@daffodil.apache.org
Subject: Re: CLI and JAVA API parsing not exiting

We actually recently fixed a bug that sounds like it might be related to
the issue you're seeing. I've tested your schema/files with the latest
development branch, and both the valid files parse successfully and the
invalid file fails with an assertion error. So I think fixing that bug
may have fixed the issue you're seeing.

We are actually going through a release vote on the
dev@daffodil.apache.org mailing list for the 3.1.0 version of Daffodil
right now, with a the release candidate available here:

  https://daffodil.apache.org/releases/3.1.0/

That release does contain the fix for the known hang issue. I'm not too
familiar with NACHA, but if you could try downloading the release
candidate and see if it solves the problem that would be really helpful.

- Steve


On 5/12/21 10:27 PM, Peter Kostouros wrote:
> Hi
>
> I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.
>
> I have modified the NACHA schemas to demonstrate this behaviour.
>
>
> The basic changes made were:
>
> 1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
> 2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
> 3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
> 4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).
>
> The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).
>
> The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.
>
>
> The test is run from the command line as
>
> sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt
>
> with the files under a child directory from where the daffodil program resides.
>
> I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.
>
>
> I have attached the relevant files used in testing.
>
>
> Please let me know what I am missing.
>
>
> Peter
>
>
>
> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
>

This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.

Re: CLI and JAVA API parsing not exiting

Posted by Peter Kostouros <Pe...@awta.com.au>.
Hi

Thanks. I ran the tests against the new version (3.1.0) and they worked as expected.

As an aside, I could not build the system from the latest source published on github on a FreeBSD system as:

1. It looked like the runtime2 C code was looking for the Mini-XML dependencies under /usr whereas the package on FreeBSD is stored under /usr/local, and;
2. Some C files under runtime2 were including <endian.h> whereas the file was under /usr/local/sys.

I made some changes to the relevant make file and some C files and was able to build the system.


Peter

________________________________________
From: Steve Lawrence <sl...@apache.org>
Sent: Thursday, May 13, 2021 9:57 PM
To: users@daffodil.apache.org
Subject: Re: CLI and JAVA API parsing not exiting

We actually recently fixed a bug that sounds like it might be related to
the issue you're seeing. I've tested your schema/files with the latest
development branch, and both the valid files parse successfully and the
invalid file fails with an assertion error. So I think fixing that bug
may have fixed the issue you're seeing.

We are actually going through a release vote on the
dev@daffodil.apache.org mailing list for the 3.1.0 version of Daffodil
right now, with a the release candidate available here:

  https://daffodil.apache.org/releases/3.1.0/

That release does contain the fix for the known hang issue. I'm not too
familiar with NACHA, but if you could try downloading the release
candidate and see if it solves the problem that would be really helpful.

- Steve


On 5/12/21 10:27 PM, Peter Kostouros wrote:
> Hi
>
> I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.
>
> I have modified the NACHA schemas to demonstrate this behaviour.
>
>
> The basic changes made were:
>
> 1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
> 2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
> 3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
> 4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).
>
> The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).
>
> The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.
>
>
> The test is run from the command line as
>
> sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt
>
> with the files under a child directory from where the daffodil program resides.
>
> I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.
>
>
> I have attached the relevant files used in testing.
>
>
> Please let me know what I am missing.
>
>
> Peter
>
>
>
> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
>

This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.

Re: CLI and JAVA API parsing not exiting

Posted by Steve Lawrence <sl...@apache.org>.
We actually recently fixed a bug that sounds like it might be related to
the issue you're seeing. I've tested your schema/files with the latest
development branch, and both the valid files parse successfully and the
invalid file fails with an assertion error. So I think fixing that bug
may have fixed the issue you're seeing.

We are actually going through a release vote on the
dev@daffodil.apache.org mailing list for the 3.1.0 version of Daffodil
right now, with a the release candidate available here:

  https://daffodil.apache.org/releases/3.1.0/

That release does contain the fix for the known hang issue. I'm not too
familiar with NACHA, but if you could try downloading the release
candidate and see if it solves the problem that would be really helpful.

- Steve


On 5/12/21 10:27 PM, Peter Kostouros wrote:
> Hi
> 
> I am experiencing behaviour from daffodil's CLI and Java API I hope someone can help with. Parsing specific files via a custom dfdl through the CLI or Java API seems to hang the processes, although depending on the data, a correct info set or a zero sized file may be created.
> 
> I have modified the NACHA schemas to demonstrate this behaviour.
> 
> 
> The basic changes made were:
> 
> 1. The CTXEntry was modified with the addition of an optional Tests element that holds an unordered sequence of TestRecord01, TestRecord02, ... elements (nacha_file.xsd);
> 2. TestRecord01, TestRecord02, ... elements were added to nacha_records.xsd;
> 3. BatchHeaderRecord's CompanyName was changed from a reference to an element with type CompanyNameType, and an assertion to check constraints was added (nacha_records.xsd), and;
> 4. Some dfdl attributes in CTXEntry's choice elements were removed or changed to enable a larger file to be processed (nacha_file.xsd).
> 
> The CompanyNameType is an uppercase alphanumeric string that also accepts blank spaces (see nacha_types.xsd).
> 
> The files used are based on ctx_valid_1.txt: file ctx_valid_2.txt and ctx_invalid_2.txt both had additional batched added, and ctx_invalid_2.txt's final Batch BatchHeaderRecord's CompanyName set to an invalid company name, ^^^^^ERROR COY. In test runs, both tests seem to hang, with ctx_valid_2.txt producing an output file, and ctx_invalid_2.txt producing a zero sized output file.
> 
> 
> The test is run from the command line as
> 
> sh ./daffodil -v -t parse --schema nacha_file.xsd -TunqualifiedPathStepPolicy=defaultNamespace -o ctx_invalid_2.xml ctx_invalid_2.txt
> 
> with the files under a child directory from where the daffodil program resides.
> 
> I am using apache-daffodil-3.0.0-SNAPSHOT-incubating on BSD and Windows environments.
> 
> 
> I have attached the relevant files used in testing.
> 
> 
> Please let me know what I am missing.
> 
> 
> Peter
> 
> 
> 
> This e-mail and any attachment is intended for the party to which it is addressed and may contain confidential information or be subject to professional privilege. Its transmission is not intended to place the contents into the public domain. If you have received this e-mail in error, please notify us immediately and delete the email and all copies. AWTA Ltd does not warrant that this e-mail is virus or error free. By opening this e-mail and any attachment the user assumes all responsibility for any loss or damage resulting from such action, whether or not caused by the negligence of AWTA Ltd. The contents of this e-mail and any attachments are subject to copyright and may not be reproduced, adapted or transmitted without the prior written permission of the copyright owner.
>