Problem with Printing

Yahoo Archive
1
Interesting, we were told that this was a problem by our Epicor Implementation Specialist and told to use the date in the group ID to prevent it. There were a few other work-around too. Maybe they should put a list together for front-line support?

--- In vantage@yahoogroups.com, "Pulsifer, Sharon" <sharon.pulsifer@...> wrote:
>
> We had the same issue with AP Checks. It turned out that using a new Group ID every time fixed our problem. Our Accounting clerk was using the same Group ID every time. Other less active AP users also used the same group. It seems that the issue only occurs with using the same group over a long period of time.
>
> It makes absolutely no sense, but fixed our problem. Epicor was no help at all in finding this solution.
>
>
> [Non-text portions of this message have been removed]
>
2
Okay, I have been combing the group for messages that might assist me in
troubleshooting a problem, but to no avail. I have an open ticket with
Epicor to try and troubleshoot, but we are hitting a brick wall. So,
here is my dilemma.
Firstly, we are 8.03.410 (this problem existed before the 410 patch).
Accounting goes to process payments via the Finance module. A batch is
created, manual check numbers are assigned and then the process payments
(print) is depressed. Now comes the fun part - waiting. Waiting = 10+
minutes to process. I have timed the exact sequence: 5 min to render
the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
machine and 20sec to print to a printer/file/etc.
It is only this function that is impacted. Sales Orders, SOA/Quotes/PO,
etc all print within 15sec of submitting. I have changed print servers
(SAMBA/CUPS or Windows Server), local printers, PDF creator and no
change. On the server itself, the proapsv process is at 100% and stays
pegged for the 10 minutes.
I have changed the parameters for the mfgsys.pf file to increase the -Mm
from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with no
change (restarted the appservers of course).
We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find a
smoking gun. Does anyone out there have any thoughts, suggestions, holy
water, etc to assist me in this? My troubleshooting is pretty much
spent.
I should also mention that this problem is not OS-specific - it happens
on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
Windows XP Pro.


[Non-text portions of this message have been removed]
3
Additional information -

While we are 100BT, my machine is on 1GB and it still is lethargic. Also, we did rebuild the indexes on OpenEdge, but gained nothing from it.

--- In vantage@yahoogroups.com, "smithmartinchristopher" <sdiver7@...> wrote:
>
> Okay, I have been combing the group for messages that might assist me in
> troubleshooting a problem, but to no avail. I have an open ticket with
> Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> here is my dilemma.
> Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> Accounting goes to process payments via the Finance module. A batch is
> created, manual check numbers are assigned and then the process payments
> (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> minutes to process. I have timed the exact sequence: 5 min to render
> the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> machine and 20sec to print to a printer/file/etc.
> It is only this function that is impacted. Sales Orders, SOA/Quotes/PO,
> etc all print within 15sec of submitting. I have changed print servers
> (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> change. On the server itself, the proapsv process is at 100% and stays
> pegged for the 10 minutes.
> I have changed the parameters for the mfgsys.pf file to increase the -Mm
> from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with no
> change (restarted the appservers of course).
> We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find a
> smoking gun. Does anyone out there have any thoughts, suggestions, holy
> water, etc to assist me in this? My troubleshooting is pretty much
> spent.
> I should also mention that this problem is not OS-specific - it happens
> on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> Windows XP Pro.
>
>
> [Non-text portions of this message have been removed]
>
4
Any size batch?
I've seen it take long on super large batches

*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*



On Mon, Aug 27, 2012 at 6:00 PM, smithmartinchristopher
<sdiver7@...>wrote:

> **
>
>
> Additional information -
>
> While we are 100BT, my machine is on 1GB and it still is lethargic. Also,
> we did rebuild the indexes on OpenEdge, but gained nothing from it.
>
>
> --- In vantage@yahoogroups.com, "smithmartinchristopher" <sdiver7@...>
> wrote:
> >
> > Okay, I have been combing the group for messages that might assist me in
> > troubleshooting a problem, but to no avail. I have an open ticket with
> > Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> > here is my dilemma.
> > Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> > Accounting goes to process payments via the Finance module. A batch is
> > created, manual check numbers are assigned and then the process payments
> > (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> > minutes to process. I have timed the exact sequence: 5 min to render
> > the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> > machine and 20sec to print to a printer/file/etc.
> > It is only this function that is impacted. Sales Orders, SOA/Quotes/PO,
> > etc all print within 15sec of submitting. I have changed print servers
> > (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> > change. On the server itself, the proapsv process is at 100% and stays
> > pegged for the 10 minutes.
> > I have changed the parameters for the mfgsys.pf file to increase the -Mm
> > from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with no
> > change (restarted the appservers of course).
> > We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find a
> > smoking gun. Does anyone out there have any thoughts, suggestions, holy
> > water, etc to assist me in this? My troubleshooting is pretty much
> > spent.
> > I should also mention that this problem is not OS-specific - it happens
> > on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> > Windows XP Pro.
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


[Non-text portions of this message have been removed]
5
Aha! I knew someone would ask. It could be 1 check, or 50. Same timing.

Now, here is one more thing to noodle - we have multiple companies set up in our ERP. In one company, checks take 10+min, the other, wait for it, 30secs tops.

Go figure.

--- In vantage@yahoogroups.com, Jose Gomez <jose@...> wrote:
>
> Any size batch?
> I've seen it take long on super large batches
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@...
> http://www.josecgomez.com
> <http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
> <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
>
>
> On Mon, Aug 27, 2012 at 6:00 PM, smithmartinchristopher
> <sdiver7@...>wrote:
>
> > **
> >
> >
> > Additional information -
> >
> > While we are 100BT, my machine is on 1GB and it still is lethargic. Also,
> > we did rebuild the indexes on OpenEdge, but gained nothing from it.
> >
> >
> > --- In vantage@yahoogroups.com, "smithmartinchristopher" <sdiver7@>
> > wrote:
> > >
> > > Okay, I have been combing the group for messages that might assist me in
> > > troubleshooting a problem, but to no avail. I have an open ticket with
> > > Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> > > here is my dilemma.
> > > Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> > > Accounting goes to process payments via the Finance module. A batch is
> > > created, manual check numbers are assigned and then the process payments
> > > (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> > > minutes to process. I have timed the exact sequence: 5 min to render
> > > the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> > > machine and 20sec to print to a printer/file/etc.
> > > It is only this function that is impacted. Sales Orders, SOA/Quotes/PO,
> > > etc all print within 15sec of submitting. I have changed print servers
> > > (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> > > change. On the server itself, the proapsv process is at 100% and stays
> > > pegged for the 10 minutes.
> > > I have changed the parameters for the mfgsys.pf file to increase the -Mm
> > > from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with no
> > > change (restarted the appservers of course).
> > > We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find a
> > > smoking gun. Does anyone out there have any thoughts, suggestions, holy
> > > water, etc to assist me in this? My troubleshooting is pretty much
> > > spent.
> > > I should also mention that this problem is not OS-specific - it happens
> > > on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> > > Windows XP Pro.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
6
I've had this exact problem before.



When in AP Invoice Entry.. NEVER, EVER, NEVER use the same GroupID. Make it
unique.



We had 2 AP Clerks and they'd always use their initials as the AP Invoice
Group. It got slower and slower. After much research, Vantage hiccups on
this and Epicor finally instructed us to use unique groups.



So if you're not already doing this, use the Clerks Initials followed by the
date, perhaps: "JTS082812"



Your problem should be solved. That was our issue, at least.





Good luck.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
smithmartinchristopher
Sent: Tuesday, August 28, 2012 10:19 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Problem with Printing





Aha! I knew someone would ask. It could be 1 check, or 50. Same timing.

Now, here is one more thing to noodle - we have multiple companies set up in
our ERP. In one company, checks take 10+min, the other, wait for it, 30secs
tops.

Go figure.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , Jose
Gomez <jose@...> wrote:
>
> Any size batch?
> I've seen it take long on super large batches
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@...
> http://www.josecgomez.com
> <http://www.linkedin.com/in/josecgomez>
<http://www.facebook.com/josegomez>
> <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
>
>
> On Mon, Aug 27, 2012 at 6:00 PM, smithmartinchristopher
> <sdiver7@...>wrote:
>
> > **
> >
> >
> > Additional information -
> >
> > While we are 100BT, my machine is on 1GB and it still is lethargic.
Also,
> > we did rebuild the indexes on OpenEdge, but gained nothing from it.
> >
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"smithmartinchristopher" <sdiver7@>
> > wrote:
> > >
> > > Okay, I have been combing the group for messages that might assist me
in
> > > troubleshooting a problem, but to no avail. I have an open ticket with
> > > Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> > > here is my dilemma.
> > > Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> > > Accounting goes to process payments via the Finance module. A batch is
> > > created, manual check numbers are assigned and then the process
payments
> > > (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> > > minutes to process. I have timed the exact sequence: 5 min to render
> > > the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> > > machine and 20sec to print to a printer/file/etc.
> > > It is only this function that is impacted. Sales Orders,
SOA/Quotes/PO,
> > > etc all print within 15sec of submitting. I have changed print servers
> > > (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> > > change. On the server itself, the proapsv process is at 100% and stays
> > > pegged for the 10 minutes.
> > > I have changed the parameters for the mfgsys.pf file to increase the
-Mm
> > > from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with
no
> > > change (restarted the appservers of course).
> > > We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find
a
> > > smoking gun. Does anyone out there have any thoughts, suggestions,
holy
> > > water, etc to assist me in this? My troubleshooting is pretty much
> > > spent.
> > > I should also mention that this problem is not OS-specific - it
happens
> > > on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> > > Windows XP Pro.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>



No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12

[Non-text portions of this message have been removed]
7
Thats exactly what our AP ppl do. Let me try this and get back to you.

Thanks for the heads up!

--- In vantage@yahoogroups.com, "Vic Drecchio" <vic.drecchio@...> wrote:
>
> I've had this exact problem before.
>
>
>
> When in AP Invoice Entry.. NEVER, EVER, NEVER use the same GroupID. Make it
> unique.
>
>
>
> We had 2 AP Clerks and they'd always use their initials as the AP Invoice
> Group. It got slower and slower. After much research, Vantage hiccups on
> this and Epicor finally instructed us to use unique groups.
>
>
>
> So if you're not already doing this, use the Clerks Initials followed by the
> date, perhaps: "JTS082812"
>
>
>
> Your problem should be solved. That was our issue, at least.
>
>
>
>
>
> Good luck.
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
> smithmartinchristopher
> Sent: Tuesday, August 28, 2012 10:19 AM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Problem with Printing
>
>
>
>
>
> Aha! I knew someone would ask. It could be 1 check, or 50. Same timing.
>
> Now, here is one more thing to noodle - we have multiple companies set up in
> our ERP. In one company, checks take 10+min, the other, wait for it, 30secs
> tops.
>
> Go figure.
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , Jose
> Gomez <jose@> wrote:
> >
> > Any size batch?
> > I've seen it take long on super large batches
> >
> > *Jose C Gomez*
> > *Software Engineer*
> > *
> > *
> > *
> > *T: 904.469.1524 mobile
> > E: jose@
> > http://www.josecgomez.com
> > <http://www.linkedin.com/in/josecgomez>
> <http://www.facebook.com/josegomez>
> > <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> > <http://www.josecgomez.com/professional-resume/>
> > <http://www.josecgomez.com/feed/>
> > <http://www.usdoingstuff.com>
> >
> > *Quis custodiet ipsos custodes?*
> >
> >
> >
> > On Mon, Aug 27, 2012 at 6:00 PM, smithmartinchristopher
> > <sdiver7@>wrote:
> >
> > > **
> > >
> > >
> > > Additional information -
> > >
> > > While we are 100BT, my machine is on 1GB and it still is lethargic.
> Also,
> > > we did rebuild the indexes on OpenEdge, but gained nothing from it.
> > >
> > >
> > > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "smithmartinchristopher" <sdiver7@>
> > > wrote:
> > > >
> > > > Okay, I have been combing the group for messages that might assist me
> in
> > > > troubleshooting a problem, but to no avail. I have an open ticket with
> > > > Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> > > > here is my dilemma.
> > > > Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> > > > Accounting goes to process payments via the Finance module. A batch is
> > > > created, manual check numbers are assigned and then the process
> payments
> > > > (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> > > > minutes to process. I have timed the exact sequence: 5 min to render
> > > > the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> > > > machine and 20sec to print to a printer/file/etc.
> > > > It is only this function that is impacted. Sales Orders,
> SOA/Quotes/PO,
> > > > etc all print within 15sec of submitting. I have changed print servers
> > > > (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> > > > change. On the server itself, the proapsv process is at 100% and stays
> > > > pegged for the 10 minutes.
> > > > I have changed the parameters for the mfgsys.pf file to increase the
> -Mm
> > > > from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with
> no
> > > > change (restarted the appservers of course).
> > > > We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find
> a
> > > > smoking gun. Does anyone out there have any thoughts, suggestions,
> holy
> > > > water, etc to assist me in this? My troubleshooting is pretty much
> > > > spent.
> > > > I should also mention that this problem is not OS-specific - it
> happens
> > > > on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> > > > Windows XP Pro.
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12
>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12
>
> [Non-text portions of this message have been removed]
>
8
We had the same issue with AP Checks. It turned out that using a new Group ID every time fixed our problem. Our Accounting clerk was using the same Group ID every time. Other less active AP users also used the same group. It seems that the issue only occurs with using the same group over a long period of time.

It makes absolutely no sense, but fixed our problem. Epicor was no help at all in finding this solution.


[Non-text portions of this message have been removed]
9
We are using a very simple approach that works well.
Use the persons initials followed by the date.
VD082812
This works like a charm.
Do not go over 8 characters.


Sent from my iPad

On Aug 28, 2012, at 8:14 AM, "smithmartinchristopher" <sdiver7@...> wrote:

> Thats exactly what our AP ppl do. Let me try this and get back to you.
>
> Thanks for the heads up!
>
> --- In vantage@yahoogroups.com, "Vic Drecchio" <vic.drecchio@...> wrote:
> >
> > I've had this exact problem before.
> >
> >
> >
> > When in AP Invoice Entry.. NEVER, EVER, NEVER use the same GroupID. Make it
> > unique.
> >
> >
> >
> > We had 2 AP Clerks and they'd always use their initials as the AP Invoice
> > Group. It got slower and slower. After much research, Vantage hiccups on
> > this and Epicor finally instructed us to use unique groups.
> >
> >
> >
> > So if you're not already doing this, use the Clerks Initials followed by the
> > date, perhaps: "JTS082812"
> >
> >
> >
> > Your problem should be solved. That was our issue, at least.
> >
> >
> >
> >
> >
> > Good luck.
> >
> >
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
> > smithmartinchristopher
> > Sent: Tuesday, August 28, 2012 10:19 AM
> > To: vantage@yahoogroups.com
> > Subject: [Vantage] Re: Problem with Printing
> >
> >
> >
> >
> >
> > Aha! I knew someone would ask. It could be 1 check, or 50. Same timing.
> >
> > Now, here is one more thing to noodle - we have multiple companies set up in
> > our ERP. In one company, checks take 10+min, the other, wait for it, 30secs
> > tops.
> >
> > Go figure.
> >
> > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , Jose
> > Gomez <jose@> wrote:
> > >
> > > Any size batch?
> > > I've seen it take long on super large batches
> > >
> > > *Jose C Gomez*
> > > *Software Engineer*
> > > *
> > > *
> > > *
> > > *T: 904.469.1524 mobile
> > > E: jose@
> > > http://www.josecgomez.com
> > > <http://www.linkedin.com/in/josecgomez>
> > <http://www.facebook.com/josegomez>
> > > <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> > > <http://www.josecgomez.com/professional-resume/>
> > > <http://www.josecgomez.com/feed/>
> > > <http://www.usdoingstuff.com>
> > >
> > > *Quis custodiet ipsos custodes?*
> > >
> > >
> > >
> > > On Mon, Aug 27, 2012 at 6:00 PM, smithmartinchristopher
> > > <sdiver7@>wrote:
> > >
> > > > **
> > > >
> > > >
> > > > Additional information -
> > > >
> > > > While we are 100BT, my machine is on 1GB and it still is lethargic.
> > Also,
> > > > we did rebuild the indexes on OpenEdge, but gained nothing from it.
> > > >
> > > >
> > > > --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> > "smithmartinchristopher" <sdiver7@>
> > > > wrote:
> > > > >
> > > > > Okay, I have been combing the group for messages that might assist me
> > in
> > > > > troubleshooting a problem, but to no avail. I have an open ticket with
> > > > > Epicor to try and troubleshoot, but we are hitting a brick wall. So,
> > > > > here is my dilemma.
> > > > > Firstly, we are 8.03.410 (this problem existed before the 410 patch).
> > > > > Accounting goes to process payments via the Finance module. A batch is
> > > > > created, manual check numbers are assigned and then the process
> > payments
> > > > > (print) is depressed. Now comes the fun part - waiting. Waiting = 10+
> > > > > minutes to process. I have timed the exact sequence: 5 min to render
> > > > > the xml data, 5 minutes to transfer the xml+chkprint.rpt to client
> > > > > machine and 20sec to print to a printer/file/etc.
> > > > > It is only this function that is impacted. Sales Orders,
> > SOA/Quotes/PO,
> > > > > etc all print within 15sec of submitting. I have changed print servers
> > > > > (SAMBA/CUPS or Windows Server), local printers, PDF creator and no
> > > > > change. On the server itself, the proapsv process is at 100% and stays
> > > > > pegged for the 10 minutes.
> > > > > I have changed the parameters for the mfgsys.pf file to increase the
> > -Mm
> > > > > from 1024 to 2096, -s from 215 to 8000 and -Bt from 1024 to 4096 with
> > no
> > > > > change (restarted the appservers of course).
> > > > > We are running on Linux 2.6 and OpenEdge 10.1B and simply cannot find
> > a
> > > > > smoking gun. Does anyone out there have any thoughts, suggestions,
> > holy
> > > > > water, etc to assist me in this? My troubleshooting is pretty much
> > > > > spent.
> > > > > I should also mention that this problem is not OS-specific - it
> > happens
> > > > > on Windows 7 64-Bit, Windows XP clean install (with no AV), existing
> > > > > Windows XP Pro.
> > > > >
> > > > >
> > > > > [Non-text portions of this message have been removed]
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12
> >
> >
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2012.0.2197 / Virus Database: 2437/5230 - Release Date: 08/28/12
> >
> > [Non-text portions of this message have been removed]
> >
>
>


[Non-text portions of this message have been removed]