long-term system failures

Robert_L_Harris · November 20, 2000, 10:37pm

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

Shortly after starting, the output of “sin” and “sin fr” look like this:

sin
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 12976 0
0 1 sys/Proc32 30f READY — 122k 167k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r READY — 77k 905k
0 5 /bin/Fsys.eide 22r RECV 0 61k 110k
0 8 idle 0r READY — 0 0
0 16 //1/bin/Dev32 24f RECV 0 32k 90k
0 20 //1/bin/Dev32.ser 20r RECV 0 16k 32k
0 21 //1/bin/Dev32.par 9o RECV 0 8192 12k
0 23 //1/bin/emu387 10o RECV 0 16k 12k
0 25 //1/bin/emu87_32 10o RECV 0 12k 8192
0 27 //1/bin/Fsys.floppy 10o RECV 0 20k 40k
0 30 //1/bin/Dosfsys 10o RECV 0 49k 73k
0 32 //1/bin/tinit 10o RECV 0 8192 20k
0 33 //1/bin/tinit 10o WAIT -1 8192 28k
0 34 //1/bin/cron 10o RECV 0 24k 20k
0 37 //1//bin/led_server 10o RECV 0 12k 16k
0 38 //1//bin/reset_modem 10o REPLY 0 12k 12k
0 40 //1/*/bin/tracelogger 10o READY — 12k 16k
1 2174 //1/bin/ksh 10o WAIT -1 94k 45k
1 2209 //1/bin/sin 10o REPLY 1 45k 40k
$ sin fr
24576
8192
180224
57344
1093k
32768
$

[This was actually run several days after starting – see the PIDs for
ksh and sin; but entries for the first 18 processes are as at the
start. An example from tracedata is available if useful].

led_server is a process that turns LEDs connected to the parallel port
on and off. It receives messages from other processes invoked by cron
which tell it which LED should be illuminated or extinguished.

reset_modem is a process that typically runs once per day. If the modem
is not in use, it powers the modem off then 10 seconds later powers
the modem back on. To determine if the modem is in use, the standard
QSSL-supplied utility “modem” was modified so it would register its name
(“narda_modem”) using qnx_name_attach(). reset_modem does a
qnx_name_locate() and if “narda_modem” cannot be located, concludes that
the modem is in use and postpones the reset until the next time it runs.
It does a sleep() between checks. This “feature” was incorporated
because they were experiencing situations where the modem would not
respond to the ring signal from the telephone company and had to
dispatch a technican to cycle the power to the modem.

tracelogger is set to write events as they occur ("-p 0") to
“tracedata”. The sensitivity has been set to 7 by tracectrl.

Everything runs smoothly for weeks, even months. The PIDs increase in a
predictable manner [Exception: approximately every twenty hours, the
PIDS will increase in bounds of 18 over a period of 12 minutes or so. I
have no idea what activity is taking place. Obviously, not something
launched by cron].

When the PIDs reach the maximum value (32767), they start to be reused.
On three or four different installations, problems developed at this
point. Here is a typical entry from tracedata at this point showing the
last sixty-two minutes of operation:

Nov 11 03:10:01 6 00001020 Spawn pid 32732 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:10:02 6 00001020 Spawn pid 32733 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:12:01 6 00001020 Spawn pid 32735 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:12:02 6 00001020 Spawn pid 32736 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:14:01 6 00001020 Spawn pid 32738 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:14:02 6 00001020 Spawn pid 32739 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:20:02 6 00001020 Spawn pid 32741 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:20:02 6 00001020 Spawn pid 32742 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:22:02 6 00001020 Spawn pid 32744 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:22:02 6 00001020 Spawn pid 32745 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:24:02 6 00001020 Spawn pid 32235 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:24:02 6 00001020 Spawn pid 32236 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:35:02 6 00001020 Spawn pid 32750 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:35:02 6 00001020 Spawn pid 32751 ruid 0 euid 0 file
(//1/usr/narda/bin/scan_rx)
Nov 11 03:38:02 6 00001020 Spawn pid 32241 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:38:02 6 00001020 Spawn pid 32754 ruid 0 euid 0 file
(//1/usr/narda/bin/scan_rx)
Nov 11 04:10:02 6 00001020 Spawn pid 32756 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 04:10:02 6 00001020 Spawn pid 3 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 04:12:01 6 00001020 Spawn pid 7 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 04:12:01 6 00001020 Spawn pid 14 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)

When the client called the system on November 14th, these were the last
entries in tracedata. The last instance of sweep_pwr_amps appears to have
run successfully to its conclusion (the data it acquired was properly
logged in the data file for that day).

The last three lines are identical to the previous three failures.

When the client ran “sin”, he observed that //1/bin/emu387,
//1/bin/emu87_32, and //1/*/bin/tracelogger were no longer running.
Unfortunately, he did not run “traceinfo” at that time to see if
anything was being retained by Proc32.

He says cron was still in the list of processes produced by “sin”.

It is now my job to find and fix the problem. For starters, I plan to
call in once per day, run (with logging to my system) sin, sin fr, sin
mem, sin ar, sin vc, and sin pr. I will also download tracedata.%m%d and
the data file for the prior day.

Unfortunately, the unit does not have a video card and does not have
/dev/con1; therefore I cannot run ditto or run cron in the verbose mode.

Any suggestions as to the nature of the problem or getting it identified
will be appreciated! For starters: what will “kill” emu387 and
tracelogger? There are no instances of kill() in any of the application
processes, so it is not an errant PID being used in kill(). Is there
something else I should monitor besides the six variants of sin?

\

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com have deliberately planned your course…”
(Thoreau: Wild Fruits)

Paul_Russell · November 21, 2000, 1:41am

Check out using Dev.ditto to create virtual consoles when Dev.ansi is not an option due to no video
card.
Maybe you can put your primary con on a Dev.ditto console…

-Paul

Robert L. Harris <bob@microprograms.com> wrote in message news:8vc8m5$aki$1@inn.qnx.com…

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

Shortly after starting, the output of “sin” and “sin fr” look like this:

sin
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 12976 0
0 1 sys/Proc32 30f READY — 122k 167k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r READY — 77k 905k
0 5 /bin/Fsys.eide 22r RECV 0 61k 110k
0 8 idle 0r READY — 0 0
0 16 file://1/bin/Dev32 24f RECV 0 32k 90k
0 20 file://1/bin/Dev32.ser 20r RECV 0 16k 32k
0 21 file://1/bin/Dev32.par 9o RECV 0 8192 12k
0 23 file://1/bin/emu387 10o RECV 0 16k 12k
0 25 file://1/bin/emu87_32 10o RECV 0 12k 8192
0 27 file://1/bin/Fsys.floppy 10o RECV 0 20k 40k
0 30 file://1/bin/Dosfsys 10o RECV 0 49k 73k
0 32 file://1/bin/tinit 10o RECV 0 8192 20k
0 33 file://1/bin/tinit 10o WAIT -1 8192 28k
0 34 file://1/bin/cron 10o RECV 0 24k 20k
0 37 file://1//bin/led_server 10o RECV 0 12k 16k
0 38 file://1//bin/reset_modem 10o REPLY 0 12k 12k
0 40 file://1/*/bin/tracelogger 10o READY — 12k 16k
1 2174 file://1/bin/ksh 10o WAIT -1 94k 45k
1 2209 file://1/bin/sin 10o REPLY 1 45k 40k
$ sin fr
24576
8192
180224
57344
1093k
32768
$

[This was actually run several days after starting – see the PIDs for
ksh and sin; but entries for the first 18 processes are as at the
start. An example from tracedata is available if useful].

led_server is a process that turns LEDs connected to the parallel port
on and off. It receives messages from other processes invoked by cron
which tell it which LED should be illuminated or extinguished.

reset_modem is a process that typically runs once per day. If the modem
is not in use, it powers the modem off then 10 seconds later powers
the modem back on. To determine if the modem is in use, the standard
QSSL-supplied utility “modem” was modified so it would register its name
(“narda_modem”) using qnx_name_attach(). reset_modem does a
qnx_name_locate() and if “narda_modem” cannot be located, concludes that
the modem is in use and postpones the reset until the next time it runs.
It does a sleep() between checks. This “feature” was incorporated
because they were experiencing situations where the modem would not
respond to the ring signal from the telephone company and had to
dispatch a technican to cycle the power to the modem.

tracelogger is set to write events as they occur ("-p 0") to
“tracedata”. The sensitivity has been set to 7 by tracectrl.

Everything runs smoothly for weeks, even months. The PIDs increase in a
predictable manner [Exception: approximately every twenty hours, the
PIDS will increase in bounds of 18 over a period of 12 minutes or so. I
have no idea what activity is taking place. Obviously, not something
launched by cron].

When the PIDs reach the maximum value (32767), they start to be reused.
On three or four different installations, problems developed at this
point. Here is a typical entry from tracedata at this point showing the
last sixty-two minutes of operation:

Nov 11 03:10:01 6 00001020 Spawn pid 32732 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:10:02 6 00001020 Spawn pid 32733 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:12:01 6 00001020 Spawn pid 32735 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:12:02 6 00001020 Spawn pid 32736 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:14:01 6 00001020 Spawn pid 32738 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:14:02 6 00001020 Spawn pid 32739 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 03:20:02 6 00001020 Spawn pid 32741 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:20:02 6 00001020 Spawn pid 32742 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:22:02 6 00001020 Spawn pid 32744 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:22:02 6 00001020 Spawn pid 32745 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:24:02 6 00001020 Spawn pid 32235 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:24:02 6 00001020 Spawn pid 32236 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_cdma)
Nov 11 03:35:02 6 00001020 Spawn pid 32750 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:35:02 6 00001020 Spawn pid 32751 ruid 0 euid 0 file
(//1/usr/narda/bin/scan_rx)
Nov 11 03:38:02 6 00001020 Spawn pid 32241 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 03:38:02 6 00001020 Spawn pid 32754 ruid 0 euid 0 file
(//1/usr/narda/bin/scan_rx)
Nov 11 04:10:02 6 00001020 Spawn pid 32756 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 04:10:02 6 00001020 Spawn pid 3 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)
Nov 11 04:12:01 6 00001020 Spawn pid 7 ruid 0 euid 0 file (//1/bin/ksh)
Nov 11 04:12:01 6 00001020 Spawn pid 14 ruid 0 euid 0 file
(//1/usr/narda/bin/sweep_pwr_amps)

When the client called the system on November 14th, these were the last
entries in tracedata. The last instance of sweep_pwr_amps appears to have
run successfully to its conclusion (the data it acquired was properly
logged in the data file for that day).

The last three lines are identical to the previous three failures.

When the client ran “sin”, he observed that file://1/bin/emu387,
file://1/bin/emu87_32, and file://1/*/bin/tracelogger were no longer running.
Unfortunately, he did not run “traceinfo” at that time to see if
anything was being retained by Proc32.

He says cron was still in the list of processes produced by “sin”.

It is now my job to find and fix the problem. For starters, I plan to
call in once per day, run (with logging to my system) sin, sin fr, sin
mem, sin ar, sin vc, and sin pr. I will also download tracedata.%m%d and
the data file for the prior day.

Unfortunately, the unit does not have a video card and does not have
/dev/con1; therefore I cannot run ditto or run cron in the verbose mode.

Any suggestions as to the nature of the problem or getting it identified
will be appreciated! For starters: what will “kill” emu387 and
tracelogger? There are no instances of kill() in any of the application
processes, so it is not an errant PID being used in kill(). Is there
something else I should monitor besides the six variants of sin?

\

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com > have deliberately planned your course…”
(Thoreau: Wild Fruits)

Robert_L_Harris · November 28, 2000, 6:53pm

The client has had another UEF. Again, it occurred shortly after Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com (Thoreau: Wild Fruits)

John_Parsons · November 28, 2000, 9:03pm

Robert,

The PID number should have a limited size, I do not know what the real number
for QNX is so I’m not sure you have really hit it, normally it would go to
65536. Remember though that the PID number should be released when the process
is released. This would allow the PID number to be reused. Looking at you
tracelog you will see where it looks like this has happend. It may be that you
have a process that is not exiting cleanly and the PID is not being released.
Your tracelog may not be telling the hole story. What is ‘sweep_pwr_cdma’ doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Robert_L_Harris · November 28, 2000, 9:23pm

The maximum for a PID number is 32767, so, yes, we have hit the ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case) ran
sucessfully to its normal exit. The last thing it does is to write the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be released
(boy, that is a hard sentence to phrase clearly). How can we determine if a
PID is not being released?

I have written versions of the programs peppered with trace() calls, but I
cannot get the client to install them on one of their customer’s computers.
It does take weeks for the problem to show up. It runs sucessfully for
12,000+ invocations of the programs.

“John Parsons” <parsonsj@esi.com> wrote in message
news:3A241D87.1AC8853@esi.com…

Robert,

The PID number should have a limited size, I do not know what the real
number
for QNX is so I’m not sure you have really hit it, normally it would go to
65536. Remember though that the PID number should be released when the
process
is released. This would allow the PID number to be reused. Looking at you
tracelog you will see where it looks like this has happend. It may be
that you
have a process that is not exiting cleanly and the PID is not being
released.
Your tracelog may not be telling the hole story. What is ‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no
video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs
spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board
that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

John_Parsons · November 29, 2000, 1:56pm

Hi Robert,

Well it looks like you might be correct about the 32767 (strange number to end
on).

I have been looking for past information about any similar problems. Go look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot like your
problem. After reading this posting I believe they may be correct. I to do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers site. Is
there a way you could run it local to you in some way. Create false I/O to make
the different applications run. If it is a resource problem it may show up by
making the complete application run. All you would need to do is fake the
application out so it would continue to run tell it dies. If you have a small
memory leak that takes time to show up you may find it this way. Also look to
make sure that you are controlling memory correctly. Allocate and release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should have
closed down, and it has not for some reason. That way the PID would be held and
a new PID would be created. Sense you are only seeing a small part of what is
going on you may not be aware of this. By running you application and logging
each process PID you will get to a point where the problem will start to show
up. I do not know if you will be able to do such a thing in your system.
You’ll also have to be able to run it some where. I’ll have to think if there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case) ran
sucessfully to its normal exit. The last thing it does is to write the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be released
(boy, that is a hard sentence to phrase clearly). How can we determine if a
PID is not being released?

I have written versions of the programs peppered with trace() calls, but I
cannot get the client to install them on one of their customer’s computers.
It does take weeks for the problem to show up. It runs sucessfully for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the real
number
for QNX is so I’m not sure you have really hit it, normally it would go to
65536. Remember though that the PID number should be released when the
process
is released. This would allow the PID number to be reused. Looking at you
tracelog you will see where it looks like this has happend. It may be
that you
have a process that is not exiting cleanly and the PID is not being
released.
Your tracelog may not be telling the hole story. What is ‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25, using a
hard disk for OS, program, and data storage. There is no console (no
video
card
monitor or keyboard). A user accesses from the outside via a modem on
/dev/ser1.
The majority of the activity is generated by cron. The programs
spawned
by cron were written for this application. They communicate with our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary board
that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Robert_L_Harris · November 29, 2000, 9:29pm

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee. The
interesting fact at this point is that all five or six failures have had the
same pattern – the PIDs start to be reused (same low numbers), emul_387 and
tracelogger die.

Last night, I was pouring over the tracedata log from the latest failure and
I noticed that the PIDs increase in a predictable manner until they reach
somewhere around 3600 to 3800; then they will have an erratic pattern for a
short time. In one case – shortly before the failure – the six PIDs
associated with three processes run from cron were 32714, 32715, 32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that to hex,
the value is 0x7cdc. If one uses the value one might expect from the pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one bit.
These anomolies appear several times in the tracedata. Is this significant?

As I write, I have cron running “date >>test_data” every minute on (1) a
reliable desktop and (2) the SBC used by the client. In approximately 11
days, I will know if this works satisfactorily. If so, I will replace "date

test_data" with one of the client’s processes. By then, I will have the
necessary cables to connect the SBC to another – and have the second behave

like the data acquistion board (accept a command and respond with a proper
response).

(The tracedata log contains all the events from the boot until tracelogger
died.)

“John Parsons” <parsonsj@esi.com> wrote in message
news:3A250B03.99121A0E@esi.com…

Hi Robert,

Well it looks like you might be correct about the 32767 (strange number to
end
on).

I have been looking for past information about any similar problems. Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot like
your
problem. After reading this posting I believe they may be correct. I to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers
site. Is
there a way you could run it local to you in some way. Create false I/O
to make
the different applications run. If it is a resource problem it may show
up by
making the complete application run. All you would need to do is fake the
application out so it would continue to run tell it dies. If you have a
small
memory leak that takes time to show up you may find it this way. Also
look to
make sure that you are controlling memory correctly. Allocate and release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should
have
closed down, and it has not for some reason. That way the PID would be
held and
a new PID would be created. Sense you are only seeing a small part of what
is
going on you may not be aware of this. By running you application and
logging
each process PID you will get to a point where the problem will start to
show
up. I do not know if you will be able to do such a thing in your system.
You’ll also have to be able to run it some where. I’ll have to think if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case) ran
sucessfully to its normal exit. The last thing it does is to write the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be released
(boy, that is a hard sentence to phrase clearly). How can we determine
if a
PID is not being released?

I have written versions of the programs peppered with trace() calls, but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs sucessfully for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the real
number
for QNX is so I’m not sure you have really hit it, normally it would
go to
65536. Remember though that the PID number should be released when
the
process
is released. This would allow the PID number to be reused. Looking at
you
tracelog you will see where it looks like this has happend. It may be
that you
have a process that is not exiting cleanly and the PID is not being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in
the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25,
using a
hard disk for OS, program, and data storage. There is no console
(no
video
card
monitor or keyboard). A user accesses from the outside via a modem
on
/dev/ser1.
The majority of the activity is generated by cron. The programs
spawned
by cron were written for this application. They communicate with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary
board
that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

Mario_Charest1 · November 30, 2000, 2:12am

“Robert L. Harris” <bob@microprograms.com> wrote in message
news:903saj$90f$1@inn.qnx.com…

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee. The
interesting fact at this point is that all five or six failures have had
the
same pattern – the PIDs start to be reused (same low numbers), emul_387
and
tracelogger die.

Hum, all problems from the same source. Could they be doing
something specific they are doing that’s causing this.

Last night, I was pouring over the tracedata log from the latest failure
and
I noticed that the PIDs increase in a predictable manner until they reach
somewhere around 3600 to 3800; then they will have an erratic pattern for
a
short time. In one case – shortly before the failure – the six PIDs
associated with three processes run from cron were 32714, 32715, 32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that to
hex,
the value is 0x7cdc. If one uses the value one might expect from the
pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one bit.
These anomolies appear several times in the tracedata. Is this
significant?

I’m not sure I’m following you. Could you post the data.

I have been trying to look from an old post on quics that explain
how PID number where allocated, it was far from simple. I looked
everywhere but couldn’t find it. The post must have been made in a
beta conference, these conferences are not archive ;-(

As I write, I have cron running “date >>test_data” every minute on (1) a
reliable desktop and (2) the SBC used by the client. In approximately 11
days, I will know if this works satisfactorily. If so, I will replace
“date
test_data” with one of the client’s processes. By then, I will have the
necessary cables to connect the SBC to another – and have the second
behave
like the data acquistion board (accept a command and respond with a proper
response).

(The tracedata log contains all the events from the boot until tracelogger
died.)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A250B03.99121A0E@esi.com> …
Hi Robert,

Well it looks like you might be correct about the 32767 (strange number
to
end
on).

I have been looking for past information about any similar problems. Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot
like
your
problem. After reading this posting I believe they may be correct. I
to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers
site. Is
there a way you could run it local to you in some way. Create false I/O
to make
the different applications run. If it is a resource problem it may show
up by
making the complete application run. All you would need to do is fake
the
application out so it would continue to run tell it dies. If you have a
small
memory leak that takes time to show up you may find it this way. Also
look to
make sure that you are controlling memory correctly. Allocate and
release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should
have
closed down, and it has not for some reason. That way the PID would be
held and
a new PID would be created. Sense you are only seeing a small part of
what
is
going on you may not be aware of this. By running you application and
logging
each process PID you will get to a point where the problem will start to
show
up. I do not know if you will be able to do such a thing in your
system.
You’ll also have to be able to run it some where. I’ll have to think if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the
ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case) ran
sucessfully to its normal exit. The last thing it does is to write the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be
released
(boy, that is a hard sentence to phrase clearly). How can we determine
if a
PID is not being released?

I have written versions of the programs peppered with trace() calls,
but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs sucessfully for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the
real
number
for QNX is so I’m not sure you have really hit it, normally it would
go to
65536. Remember though that the PID number should be released when
the
process
is released. This would allow the PID number to be reused. Looking
at
you
tracelog you will see where it looks like this has happend. It may
be
that you
have a process that is not exiting cleanly and the PID is not being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in
the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25,
using a
hard disk for OS, program, and data storage. There is no console
(no
video
card
monitor or keyboard). A user accesses from the outside via a
modem
on
/dev/ser1.
The majority of the activity is generated by cron. The programs
spawned
by cron were written for this application. They communicate with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary
board
that
measures various things of interest to an operator of a
microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

John_Parsons · November 30, 2000, 12:57pm

Robert,

Could you post the ’ tracedata log containing all the events from the boot until
tracelogger
died’. I would like to take a look at this. The 32205 (0x7dcd) does look funny
but I would like to see the whole thing.

By the way ’ (32205), the hex value is 0x7dcd not 0x7cdc’ though I should point
this out cause somebody else will. )

“Robert L. Harris” wrote:

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee. The
interesting fact at this point is that all five or six failures have had the
same pattern – the PIDs start to be reused (same low numbers), emul_387 and
tracelogger die.

Last night, I was pouring over the tracedata log from the latest failure and
I noticed that the PIDs increase in a predictable manner until they reach
somewhere around 3600 to 3800; then they will have an erratic pattern for a
short time. In one case – shortly before the failure – the six PIDs
associated with three processes run from cron were 32714, 32715, 32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that to hex,
the value is 0x7cdc. If one uses the value one might expect from the pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one bit.
These anomolies appear several times in the tracedata. Is this significant?

As I write, I have cron running “date >>test_data” every minute on (1) a
reliable desktop and (2) the SBC used by the client. In approximately 11
days, I will know if this works satisfactorily. If so, I will replace “date
test_data” with one of the client’s processes. By then, I will have the
necessary cables to connect the SBC to another – and have the second behave
like the data acquistion board (accept a command and respond with a proper
response).

(The tracedata log contains all the events from the boot until tracelogger
died.)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A250B03.99121A0E@esi.com> …
Hi Robert,

Well it looks like you might be correct about the 32767 (strange number to
end
on).

I have been looking for past information about any similar problems. Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot like
your
problem. After reading this posting I believe they may be correct. I to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers
site. Is
there a way you could run it local to you in some way. Create false I/O
to make
the different applications run. If it is a resource problem it may show
up by
making the complete application run. All you would need to do is fake the
application out so it would continue to run tell it dies. If you have a
small
memory leak that takes time to show up you may find it this way. Also
look to
make sure that you are controlling memory correctly. Allocate and release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should
have
closed down, and it has not for some reason. That way the PID would be
held and
a new PID would be created. Sense you are only seeing a small part of what
is
going on you may not be aware of this. By running you application and
logging
each process PID you will get to a point where the problem will start to
show
up. I do not know if you will be able to do such a thing in your system.
You’ll also have to be able to run it some where. I’ll have to think if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case) ran
sucessfully to its normal exit. The last thing it does is to write the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be released
(boy, that is a hard sentence to phrase clearly). How can we determine
if a
PID is not being released?

I have written versions of the programs peppered with trace() calls, but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs sucessfully for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the real
number
for QNX is so I’m not sure you have really hit it, normally it would
go to
65536. Remember though that the PID number should be released when
the
process
is released. This would allow the PID number to be reused. Looking at
you
tracelog you will see where it looks like this has happend. It may be
that you
have a process that is not exiting cleanly and the PID is not being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events in
the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25,
using a
hard disk for OS, program, and data storage. There is no console
(no
video
card
monitor or keyboard). A user accesses from the outside via a modem
on
/dev/ser1.
The majority of the activity is generated by cron. The programs
spawned
by cron were written for this application. They communicate with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary
board
that
measures various things of interest to an operator of a microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

Robert_L_Harris · November 30, 2000, 2:00pm

Attached, in zip format, is the tracedata as sent to me by the client.

So far, my experiment (running date from cron every minute) is working fine.
No anomolies in the PIDs (and and I am upto 5000+). If I can get
confirmation that Proc32 (or whatever tracks PIDs) alloc()s it memory, I may
have something to work on.

Thanks for catching my transposition. I can’t even copy from my own notes
correctly.
“John Parsons” <parsonsj@esi.com> wrote in message
news:3A264E9D.97EE5046@esi.com…

Robert,

Could you post the ’ tracedata log containing all the events from the boot
until
tracelogger
died’. I would like to take a look at this. The 32205 (0x7dcd) does look
funny
but I would like to see the whole thing.

By the way ’ (32205), the hex value is 0x7dcd not 0x7cdc’ though I should
point
this out cause somebody else will. > > )

“Robert L. Harris” wrote:

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee. The
interesting fact at this point is that all five or six failures have had
the
same pattern – the PIDs start to be reused (same low numbers), emul_387
and
tracelogger die.

Last night, I was pouring over the tracedata log from the latest failure
and
I noticed that the PIDs increase in a predictable manner until they
reach
somewhere around 3600 to 3800; then they will have an erratic pattern
for a
short time. In one case – shortly before the failure – the six PIDs
associated with three processes run from cron were 32714, 32715, 32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that to
hex,
the value is 0x7cdc. If one uses the value one might expect from the
pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one
bit.
These anomolies appear several times in the tracedata. Is this
significant?

As I write, I have cron running “date >>test_data” every minute on (1) a
reliable desktop and (2) the SBC used by the client. In approximately 11
days, I will know if this works satisfactorily. If so, I will replace
“date
test_data” with one of the client’s processes. By then, I will have
the
necessary cables to connect the SBC to another – and have the second
behave
like the data acquistion board (accept a command and respond with a
proper
response).

(The tracedata log contains all the events from the boot until
tracelogger
died.)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A250B03.99121A0E@esi.com> …
Hi Robert,

Well it looks like you might be correct about the 32767 (strange
number to
end
on).

I have been looking for past information about any similar problems.
Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot
like
your
problem. After reading this posting I believe they may be correct. I
to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers
site. Is
there a way you could run it local to you in some way. Create false
I/O
to make
the different applications run. If it is a resource problem it may
show
up by
making the complete application run. All you would need to do is fake
the
application out so it would continue to run tell it dies. If you have
a
small
memory leak that takes time to show up you may find it this way. Also
look to
make sure that you are controlling memory correctly. Allocate and
release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should
have
closed down, and it has not for some reason. That way the PID would
be
held and
a new PID would be created. Sense you are only seeing a small part of
what
is
going on you may not be aware of this. By running you application and
logging
each process PID you will get to a point where the problem will start
to
show
up. I do not know if you will be able to do such a thing in your
system.
You’ll also have to be able to run it some where. I’ll have to think
if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the
ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The
common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case)
ran
sucessfully to its normal exit. The last thing it does is to write
the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the
failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be
released
(boy, that is a hard sentence to phrase clearly). How can we
determine
if a
PID is not being released?

I have written versions of the programs peppered with trace() calls,
but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs sucessfully
for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the
real
number
for QNX is so I’m not sure you have really hit it, normally it
would
go to
65536. Remember though that the PID number should be released
when
the
process
is released. This would allow the PID number to be reused.
Looking at
you
tracelog you will see where it looks like this has happend. It
may be
that you
have a process that is not exiting cleanly and the PID is not
being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events
in
the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25,
using a
hard disk for OS, program, and data storage. There is no
console
(no
video
card
monitor or keyboard). A user accesses from the outside via a
modem
on
/dev/ser1.
The majority of the activity is generated by cron. The
programs
spawned
by cron were written for this application. They communicate
with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary
board
that
measures various things of interest to an operator of a
microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

\

begin 666 Trace.zip
M4$L#!!0````(#IC?"G@#T:DR'H"1#0)! =')A8V5D871A55@,*5/
M^#F@ZB,Z`````R<"514=?O’AV’?AF&1=8!A9MB&;8:1/5,S<\L–#4RZ:B
MB,JB0):.Y8II2AO[OL>F&E6+J@MF)E:OKF48EEJ:6GUOF[EG^'W/&^#YSYX
M?^?/8>3-S?S_WQW.^]W#MVTPT8’6 CD\D<!\I:?\E;OB:U?-FV?.G8OY+I
M)#$!D?_SM13V-4AALAZ_K?2[$QL&TK^!J=9Y I#?7:]2U_9F=@VX&&’?8;
M6[;-?[Z@Y9_(JWMF%^<E"":#^0_52IDL2O;/K[@X8UQ927%<40N3’9=34,1^
M-VK"Q+S":’“S= 31,B,%DX<4U"D%1;8?&X!Y<$70N-+QNJ$KXR(Q(D@>=FE
M^5IAE_-)8(PB3&EIA4Y8J$;$)(4M#"A0O<H9#J,&43LDO&:X7O’4!E” "
MY6:7*@T+#-?,PU7+9/>L93EFFTKU>R[3!">3[L&BD2I\U0:ZG376TV( T5
MMLF!HA++.8;J;2$1.?[LPF15’^CYP[/,,-5]%,"+/DO.MC4"F,SW?M^U\ M.HB/E^M’L,(ETI9)Z’+R#/B2,:X7YP!B#=1)#"$JV@E)<\3RUGV\TB'2G MD#<5I8"\0"$W$A#I02'>66 ]20,W93.E%(5;AB/2FD%B7J8#TH9!%,8B\ M2"%:CW) ^E+(S7A$^HDC)N&[Y$I ^L,?BY\H.3FC2K,+Q^<7*X7#FNJ6B$?+ M:=+T^/%CK= AM!84ZB%?.VZ’)"!%+RW@)(.K56=3PB@Z2N]=6$BVW6&N[F
M/) I!E-[:8Q"9(C4O>0DA@ZTW,L[P090#7V\M"A,R##I.[%E)C>9B]]=!F@
MR"#GKL@$))-"$@R(9%’(D"0!D.$4LM_&Y"7J.]X3C(B(Z1^QR_'E[7YCH?Y
MO0&D=1"]J4B,HI:R$W58D $J0L9’?9VFX6L#-@&BFQJ(;E6VP’)H192&X1(
MKM2%’ S>VV8A,QCTYDBCUJ(4T@,(/D4\J5=+"“CJ;7J;5<”,D;J6N_86@_Z
M9ZTFH5^ _R"F&"M5\9?SC#:!/5"4!1(5539O=U&$6=:!XIQ4A5[9(Z#+17A
M\N&#F6\5(7.V7:HY7’+2)H^E"DQ2>N$:K]9@RX8F]M/ZX+],*G<,M"=D3 M1,NM1[C0Y#X3D(DB2&[QQ*+2[!RM8%+,!FP2U9$%"8A,IE8<8B\?QI!B8L47 MW2T)D15K!;6]-2"E8BMNN?D37G!)'O;/,,,%?6HR1,KH;U(CE-MW!6P*L;P3 M'I:$Z$#_3$"DG-Z7TB!$#AQF>7_*MLWWI^:[Q 1A3\>!H*EX0D/?GZH?N$[* MN)<B_Y_TR>T_7*>TNWW;=5J[V]==J]ILSU"TW:Y4S&]WNU2QJ-WM"8JWVMV6 MN=6UNUT1M+J];<-['LZ9EO?O$P(5F>)#MKA__R7:$A*]?W_9RPV05T00=O\^ M+!*9Z2),Z_W[*9D2D)DB"+M_SW!"IDJ$@?OWE^S=9I%G:WGXOTF4TA\W3^ M@,RAD&UN8#,I9!%ON& S.0!UX1@,P71TR"@TLD( MD$J^HA^+C,ME%8%[+
M14!IZ&SJD6EYQK%M\QE7T7K&C93WA%U42S[C#&O=J]HTZC?5’$)BT:B)T9:0
M:-JO>8"LHAL5&DD,HNI1@V2S0.DAFQ4J1,R;]-NF8]‘Z"WJ*,8$+ 8D44
M<D^Y!)!EU($NLJ!I%;J@1X8OQP.])36_V\Y^8V!YIMFP]T=>N!K@W:#+M8 M+O5 :X68Y'H(_4ODP+8<LV3!Q:T!D+?;]99,S<^?-&K2U.)1V1,FM3SBKI?K MLUAN%:4^[(;(:B[U3;MUD%M+J>V]$%G'I5[AXO02RVV@U+T"$=DH49V;-R%; M*UQ15D%N,Z5>&H3(%B[UX0X/(+>-4I=I$=G.I3[GGS.2Y7:*JXW"W"A$=K6O MSLTN&E5:KA46!K\OL, [E/,KR+U3W<6MSC?TQT9PP)[J!&<,2+R+E<G/M&G
MC&6Y]RCU]TF([.-2E\760^Y]2KU8U@#(2[U0I/?.);[D%)OLO4'Y".N3IQ) M6@*Y0Y3ZEF,-((>YU#Y63N-9KI%2GU0@<I1+'6-77,ARQ\751N%[3T0^;E^- M3?9P:2IB@4\II^"/R&=/=YJ;[*(\4\8")Z@11 8B\CE7)P9Y]9["<E]0ZDDA MB)SB4IO\&B%WFE)?#T/D#)>Z5Y"^G.6^HM1_1R'R-5<G]-JUD/LWI;YL0.0; M+K53A%\%RUV@U(<2$+G(I=X?,[.2Y;X55QN%HC1$OFM?C4TNC#\_C06N4,YY M-A<:7ZZT]SDOQ.;9[’ ]]0(9CA<!>0’KDYT3\N<S7(4NI/7+(^8E+76US M!G(W*'47#T1N<JE3G%+GLMPOE/JV#R*WN#KAY]8N5\I]1<J1’[C4@N>^GDL
M=Y=2=PA!Y’<NM9M?S7R6^U-<;12.A2’RG;5V&1]X,UJ%KA’.<NC$+G_=>Y
MR4,U=Y:PP$-J!,5QB#SBZD1">$$-R_U-J=,[(O82]TANAER5E:$NBD%$;D5
MC_I-0Z^W6,Z&4N^4]P;$5J:=6)#XA’(V5/J@PZ-@#APJ6>EI2QE.2=O<HU
M%1!G+O5CFW7+6,Y57&T4WO5 1-&^FC59:1CKMG&YY6-X0."6Y>/>!:/X;FQ
MEI#H8[A_X%9 WVHQ_",CLAXBC"MC^&Y;MLZ2""L,?P(']DO$48> R?[;<= M(!\1J/49>WG8'D!\Q1&-4._S+B!^5N*?<XX.M21$CE&X<"E@+R !(LC_/CB. M<]@'F(I:L6<B(H'4BM<$W 8D2 0Q_SWQ7-L'0*BI5IWR1B3DZ:TJ+M<(9YV< M5K" AIC3;SZ6A,A>HX6M&F= =.WOM5(KR!P]@0T5FZEY6%=4Q8"$4?.\[5D" M2#B%R!U*8F@D&UVP")I)#C\8CH4016@=(%(5<=CX$2+0XHE0[QID1:SB]
MM8+.ZC!$8BAKE:81D%@,7D=!22.0NZD(F*@D->3CP%BI!!?[7% XBEDG>O’
M@)@HI#$1D8X44A+Q"2 )%++4\U- $L41DS ]N F0I"=J3WX$EQM;07["&YL
MZ]]>S;_!8IDL0N>^>J;$6=7QY 4:JUG-?: I%+(=K<0-(H)$JFN09"ID9
MCD@G:BA?>P8"\JS4H9QWU=99#F6T20NSM1"SD7K.E"(=ZAH8!TI1!_ZPA MGJ,NJ*\Y=@.D&W%IN^QE28A>VFXY/P](]Z=>VC*"TH%]@;JT=9=G]#N! 8
M?HA?76?YT2[;-G^T:_X1GB!DVZ!1<]V5]3FH]UO%?(U±2’NM=Y/1B1%[EN
M_GYWKX1</TJM#$:D/Y?ZK/==R VDU/-UB1SJ:M46>M8;C"ECH]!9 C7S5].
MR&G(#:/4OG&(9’“IMX7V6L]R691ZE F1X5SJCCZ#2PW@KJY)(U#)2RBUK MR[4ZSG$S"PB4\X"M$R#94FY8M()=1_==+)!+C4!MYP%('E<GO%,70&XTI3:Z M5 ,RADM]5"[?S7(%E+I<B<@X+G6QP[AW6*Z04H=[(S*!JQ-5BJN0FTBIDU6( M3.)2+W?/JF>Y8DK=+QB1$BZUMW=C\N54:W+TR$R15J3F_S]][) .>6<‘H%(
MA;0F+U*’?,@”+U,CZ!:+R#2N3GRM6P&Y5RGU72,BT[G4JDCWCUAN)J5.242D
MBDM](K;B(,O-IM1]996 S.‘JQ’;3’<C-H]3’;>",I]+O3"YX!#+55/JC4[C
M%G(I5XM/W.8Y5ZG6C=8B<@B:4T.L=,?98'%E'.B%R)+I#5YCU-\$PN\28W@ M2Q]$WN+J1+1R&^264>KF0$1JN=0E7IH3++>"4D=H$*GC4B_PJ_Z<Y=ZFU,^& M([*2JQ-6P?*3++>:4N^+1F0-E_JJM@)RZRAUK1&1]5SJ>Q'-7[#<1JIU.Q,1 MV22MR9XQ*:=98 OES$Y#9*NT)F\R=OV&!;93(SAL_1P@.[@Z$93T/N1V4>HU M#@<V<VE?BB+/]R]92Z7H%(Y?ZBDW=!99[EU(O\T!D+U<G,IT\+K+</DJM M\$5D/Y=ZC:(:<@<H]1 5(A]PJ?M[W;W$<A]1K;/1(')06I/'^?:^S *'*>?^ M,$2.2&OR(U7ZCRQPE.R$'I%C7)WX-N0SR'U,J6OB$/F$2STWHNM/+/<9I4Y+ M1*2)[V$R:NMUEON<?)A,0>0D5R<:#"$W6.X4I3XIUP#R)9>Z)F$%Y,Y0ZIWV M=8"<Y5)O2;7ZF>6^IEIWU$4.R#EI3<ZRR;K%M]03C</1,Y+:)LQYP_6. B
M-8UWHA<XNJ$R?4"Y+ZCU-?]$;G,I=[ND?XGRS53ZD^#$;GI8[T.? ?EON!
M4G^G0^0:5R<<5?'9;F?/7!2$2N\SU,AFR%W$UO3H6D9^YU+(P]LL=XMJ
MW5X3(K>E-7F/ON A"Q&.:U2$+DCK<ENQLGR^ZV!WZD1ZV+?F#JQ-#$VY MSDY.J+^QNPF(O9Q'/28MVYKEW"CU#9<<0#RYU+UMFFQ8SI=2/W9'1"51S3JQ MQ.$Y6Y;34NH>WHCHN-2370] +HI2AP4@$LVEGN>AL6>Y6'&U47A&C4A<^VIL M\EF?2D<6,%+.!:&(Q#_=V?H?\ZBJE"S0D1I!@!Z1!*Y.7 ZY#[DD2OTH%I%D M+G58V&1WEDNEU-U,B*1QJ3?HSWNP7"=*G9F,R+-<G9@5-]"3Y;I0ZE56Z8!T MY5(_ZO@9Y+I1:F_[)D">YU)7I!@[L-P+5.NB7>(!Z2&MR37R:A\6Z$4Y>RH1 MZ2VMR5,=KOJQP(OBS@0AW ^1OA)&4%H^JKA0*SQP3E6Q4'_*ZZY"9( $;S'S M[E+6!+%0.G7(<H,0&<35X=<[. 6SW!#R]- B,I1+O2J@"G(9E'IP)"*97.K9 MP3?4+#><4J?&(/(25X?S=-DA+#>24OO%(S**2WTI\CSDLBEU31(B.5SJK-BN M6I;+H\Z24MES@.1+._,VF5:$LL 8RGG$M@Z0L=+.O-/):Z-98!PU@D%.ZP9
MS]6)5ZS\8UANJ6N4R!2Q*4>85<#N4F4VL,+D<E<ZA+G![$L5T*I(_T0*>7J MQ"!E<1S+3:'4#D&(3.52UWG=A%P%I>ZO0:222]WLGVYDN6E4ZVHC$'E%6I/S M@K:96& ZY6R(1F2&M";_5U.?R@)5U AV&A"9Q=6),_K(-):;0ZE_34)D+I>Z M?\Q:R,VGU(6IB"S@4I\T.G9BN864^B=K)T!>X^I$]Z29D%M$J07'*D#>X%)7 MRQY ;@FE[JQ I(9+O<8VIS/+O46U;J@G(DNE-?F6TX&N+%!+.=?Y(K)<6I/[ M*1I[LD =-8)Q8C\BZL3,9ZIO5AN):7NK49D%9?:U;<!<FLH=6,H(FNYU-I
M_SXLMYY2G]<CLH&K$S::)9#;1G?CT-D,Y=Z6KCCBRRWE5OZ(C(-B[U@ZC) M?5EN!]6ZW2F([)36Y!>,G_5G@=V4[YU$R#O2&MREX330UF@@1I!EOT90/9P
M=6)@6J]A++>74H]W[0W(>USJ?.M&R.VGU#.5B+S/I?9TU&>RW >4^E-O1#[D
MN^-T70>Y@Y1:&8#((;Z3Q,L_B^6.D"=)""-7.H!/E7#6>X8U3J[4$2.2VOR
M2M6%$2SP">5,UR/RJ;0FUZJ;\UB@B1I!WUA$3G!U0AF6F<]R)REUM F1+[C4
MO^I/0^Y+2KTQ&9’37&I;0\H8ECM+J>=9I0+R%5<G7DVHA]PY2KW<O@&0?W.I
MHU,BQ[+<>?(#26<](!>XU%OD-04L=XEJW0@E(M]*:)]FYOC6> RY>SAB<@5
M:4V>ZW*WF 6N4B-8[X?(]UR=J/485)RURCUN&(,BEWMGAN2N4^H<+2(W
MN-1’_7N7L=S/E+H`I%?N#K127T$<K<I]=T81’[E4L_6I4QAN3N4.B4>D;M<
MZGC]VJDL]P?5NAG)B/PIK<D_QMZO8('4LX55@`N2>MR5?BK6:RP -J! ]L
MY( \Y.I$1G(%Y/ZBU!<<*P’YF^":747<C)K0AVB0,3FD>]QRYK%LM94^JQ
M7HC82%2S3AQS.0,Y.TK=[(>(/9?Z@EOOV2SG2G?"$3$B4O]FU?#’)9S$5<;
MA8T:1%S;5V.3._D[S6<!-\IY-QP1Y=.=YB:?“O)X@P4\J!’,CD;$DZL3S;H% MD.M J?\R(N±I?XXS&HQR_E2ZJLF1/RXU*XQ!4M8+H!2-Z8BHN+JQ"UC,^2” M*+6]S55 @KG4^4F9-2P70JFG.V8!HN%2]Y0UOLER.JIU2Q6(A$IK\D,;_V4L
M$$XY>WDB$B&MR6%.FI4LH=&T,T’D2BN3MBYU4$NAE)K58C$<JG[>GJL8CD#
MI1ZG1L3(I7[D6[F:Y4R4NCX,D8Y<G;@4>!=RB91Z210B25QJG:9@#<NE4.KS
M<8BD<JE3PT^O9;EGJ-;]VA&13M*:?#LJ<@,+=:<::F(=)'297A<V.EL _
MKWHWI^X&P9.O?)EC*KW<<4[%I#HJ]XK[>L!Z69-O>KMHD:FNPC3^JIWGR1$
M>H@@[%7ODPX-P/028>!5[[<]P#46P1J?6’NJ]0/.E#(7.B/P3D10HY%?01 M('TIQ-?]("#]*&1B,B+]*:2'\1 @RBD0’48D($4\I’#$4#2*<0Q$9%!XHA2
M/4;5V()8J&-XMF1C1 93%EM(",D0<T0B.M5&A@RU%G^K\IK!DA Y(Z%
MH?I 0#+:/R,JM<+AQ$1@,T5TK6O:Z-\7D"R191>6:(2PJ$H@AA.KKDBT)$17
M?3/N94!&/‘751MD<8$=2JXZ650,RBEC3=&=+0F1-.F&WRT) LD60DL+L"JVP
MR^4U8’+$&//%X[K]ZX#D4L@%IV6 Y%'U^2,1D7P*.1=9"\AH<<0DJ)4[!GS MQ%S:CMGB->3\^#];(N;7D/?_;?Z?$Y=:V6UBBK%2%2GN0S99*H*]"D!1(%6Q MP>$-"X56F.FS'!3CQ*Z3YJ%>]-X(R'AQ1"-H(S8!4DC49(K)DA"MB2IJ,R!% M8G4LGEBD-'@Z[FMA_GGQF&V;7SPV_T!)$/1^^\ QL=WZM_X.7SR>YA6_G86* MJ9_FQT(1*>&ZO1&\MT&NC%*_HD5D"I=ZB[]F!\N5DZL.1Z2"2SU,O6 GR[U, MJ1V,B$SCNKU)"OT_RLXS*LJS6Z PP%"D#+VWH0QU@&%@8(P%3+!BC4:-&B"Q M)IJ [=-$@QA+L$5$HQB-W=A0L6.+)J+8$HU8L 10L:/8-3%^UYQS[O+F<LSS M_'2MO3?CRYDS[_M8,"T&;RR7OJTCY$NI]-CP4>B-X])ZR%Y4NGHF.KUX’W%
MW4#9FL0F2!V4U8=GUP"PB2N.</:B,ADL<>+H4DI.T#(YR[!(^M419(S<1V
MTU+TIG’I"GM"IDNEYRIUI>!]PZ7370B995.LRW:"=XL+OVG)R&%4C,Q3>6T
M"[PY[.<‘R’?2J4K7/+1F>E]6$%$FEQWO=WPW>=]S4)8<1LD!LDD_XM_X1
MA.^YIK^6D$5BDWPXJ–!$)9PE^!:+"%+I69B=5@Y>LNY],$$0E9(I?.C4PZ!
M]P.7;M:8D%52Z46Z5>7@K>‘2:O/5B*R5FHE<0^!A(JY=)&U&I’U4ND#)D7H
M;>32H^T)9%G[=0’ 5O,S=UWS@3LD5LDC6->AX’81O7O.!!R’:Q20YTRH MH92[!*=]"-DI-1,#G"O1V\VE?0,)V2.5'N79^31X/W+IV:&$[)-*/_8M/0/> M3UQZ;20A/TO-1%-UW%GPRKCTPQA"#DJEMVE6H5?.I4_I"3DLE=9'.5:"=Y2; MNIO)A!P3F^1Q<0,O@/ +U]2;#T+D5[$CG_+XW*K7CWRJ++ZJ:OAF^[4CGW#W MUZ$&CWQ^MYB R&_LD<\$'V(JN".?YW&$G&&/?$I,)R)SEC_RZ60DZ!QWPA 2 MO!212N9I?H_#23.,X]$YWU>)QKX%D5EI’F6(7+Q7Y_F@)^0?92PT_S01G?
MNE8A\COW[+O"MAJ1@X):DQ(-8>T=^M:#4@-=P77&PBYS%R?I;=7B,:N#Z:
MC+0D0JXRCXQ_^>‘T6’=$:OE7O$ESQZ(7.->L6GR042N,Z]XA]6AUX@&7G%0
MQE3S<D1N-OQ=4F5L"HVI@4?TF7^^^JDYP0&Q-:#<XG^3Z@R=2R)BMYF7-’
M=:+!“SK7V8!(W9LNZ&JK@8C=Y2ZHVDC(/?8D+WH0(O7L(/E_C,A]#GFI^@21
M!QS2RFPP(@\YI#“6$#-S!AD9- 01)8=<_D4$4L.7?X#!%[#K&VRD;$@4/
MM(0X<\A"30XB;APR(F H(AX<HG$:AH@/AV2;#T?$OV$D/N-$B%JA>!!U1.;
M,:^]"X(R#&9C,1’4%=1Q8:8%-:?C@$OWYU./3JHR<AXRU5(2:"S?_O<+_A
M<&B(2<YED+^(?WOY_YU)TBW]C]?\JR.PF>C%<>K&*D%BI]!’+K"O@Z;AT
MKBLA\5+I:MO#5%+X-(S?0E)%$S#C= ^Q]1:)X] A_0IETLGNI>@UYM)W
M@PEY2RK=P4=]’;RF#:?C,EY&$=+LS6FZ?1L6D’X#A!2N&1Q’2.J-U]B.P,
M/H#"VUSS,QTA[X@U^T8VN0E"2Z[9UDA([&F1]06%-IPS05)A+05:SZ(C[X%
M0CK7;&:I1:2]6’.!<3D*’;GF=;L5B’02:XXV][L-0A>N><B)D’?%FM-L^I!
MZ,:-FI/0MZ3V@463L_1Z&E=H3TE,JO=DUYSYXO;CT"34AO:72’WI7/@#O
MR[M$4Y(AM0N:!'0Z2%X6>QRU!+RH51Z2G Y>GVY=',=(?WDEF-$W&/P!G!3 M=]= R$"Q#=9;V_L)"!]S395I'T0^$9ODRM@*%(9PS4>*TXA\*M;LDIC^%(1L MKJFT;H](CECSN6D9"L.X9BL5(</%FHVLFCX#8237#',EY#]BS<ZV6U$8S347 M>1'RN5ASGDK['(0Q7#/7GY"Q8LUW/ M>@I#+C7YF*"'CI'9!B)^-R?._O?%< MNC*2D*_DEF/0./0FLLLQEI!)4FGOL!NFX'W-+L<$0O*E=L$?49D*\*9RZ0U& M0J9)I8?ISJ$W@TM/-Z]$Y!NI='UBBCEX!=S4V5JG(C)+;(.M,1EB<)LKOG,
MGI Y8I,<9E:+PERN>4E%R#RQ9K)U’R4([GF)’="OA-K=K ]C<)"KFGA1<CW
M8LT8Q:6(“SFFIM"5DBUOS$NPR%95RS2P0AR\6:>SV;6(&PDFNV”“7D!['F
MB<#%=B"LYD9_4@PA:Z1V@6>HISUXZ[AT0CPAQ5+IIQ$ST=O I8N3”-DHE5X9
M^\P!O$U<>K_B.2*;I79!G3Y;!=Y6+FUMF8/(-JET?^,-]'9PZ1N-;B)2I5N
M;=;9";Q=[%.DBI#=8AMLH=589Q#V<LU%T)^%)ODS8T>H["?:RJ"/E)K’G;
M8X@+" >XIE%#2)E8<Y%G+0J’N&:=AI!RL>;G@;U=03C"-<MC"#DJUHP(J4#A
M.-=LJ2/D%[%F=GBZ&P@GN.9>R$GQ9I;=!N]03C%C;[!O 21"JE=\&=BN ]X M9[CT6*L(1,Y*I5-,EJ!7R:6?V!%R7BK=W<+&#[R+7-K.F9!+4KO :sunglasses:.'7A67 MON-.2+54NI7J.7J7N?0+7T*N2*7+7+("P*OEINYS-2'7Q#;8#8_I@2#<X)H& M#2$WQ2:YO[=2#<)MKND33L@=L>:HP#$HW.6:!V,(N2?65(<]0N$^>UZ72,@# ML>9RS> @$!YQS7 ](8_%FFOCKZ+PE&L^4=8B\DRLN3^Q=S (?W!-.YL^B/PI MUC2:[0\'X2]N]+NI"'DI=P]F98PS]2"2?B2HC"0B:=:5N"GCF7=O,BQ$(J
M[>#D%06>)9<^X$^(E6 :=L%=MP+T;+CTLF!"&DFE$[UMHL&SX]*WPPBQETJG
M!V1KP5,UG([+,-,2XOCF-&VP)2$+8D!PYIKOQ1/B\N-5Y,\2>,:“X(;UQR<
M2(B[6/-EU#04/+GF%B,A7F±%+U%’ @^7’.:I1(17['F/<,8%/RY9H[U6$0” MQ)K]%(]14’/-=$="@L2:ZY1#=""$<,T_7 @)%6O6.YPT@!#&C?Y7T+“I7:!
MPJU-$GB17’I[$”%14NDV7OO1TW+IEQI"8J32&?X11O#BN+1K-"$ZJ5U@$[H8
M/3V7WAM/2()4>G89V/P#%RZ22(A27++43ON+?",W-1U,LE#I+'8!KNO6]<$
MA"9<T\ZB&)&F8I,\7!?2%(3F7/.)62@B6±Z\8%+3@FO/M%B+RMEASMIE;
M,Q#2N.9E1T):BC6;VDQ’H377#/$DI(U8,\A6V1R$=ESSK"<AZ6±.2YC4>C
M-:^H">DHUG3TJ7D’A,[<Z)>%$])%:A?4!_1(Z\KNQRUA'232I$.8%>=RX] M,9Z0'E+I:Q')K<![GTLO2"*DE]0N.!BS$;T^7+K:M 21#Z32*_7AK<'+Y-+[ ME!&(9$FE=R?/; />1]S4G6E4@$A?L0TVTFQ/6Q#Z<\TH1T(&B$WR>U:)[4 8 MQ#67N1'RL5@ST:X8A<%<T]>'D$_%FE7.H>D@9'/-%P&$Y(@U-1X+41C&-2^$ M$#)<K+G(U[4]"".Y9K=(0OXCULQ53T-A--><JR/D<[%F5&1]%Q#&L.^J)$+& M2NV"9;$#WP4OETN'*@8A,DXJ?4M?C=YX+CU868/(5U+I(F/K;N!-Y-*;;=L@ M,DEJ%_QNMA^]K[ETH2,A^5+I4"OC>^!-Y=+G70F9)I6NL%O2';P9W-3E>Q/R MC=@&>^IXO <(!5PS+8"066*3O-(UK2<(L[GFHR!"YH@UZSSWH#"7:S;2$#)/ MK#G8)^%]$.9SS?HP0KX3:[8,7H?"0G8KQA'RO5C3-R:D%PB+N>812@B2\2:
M’\4O0&$9UW17+D1DN5CSBR33+!!6<J,_QT:!R ]2NZ"G8C1ZJ[GT" ="UDBE
M%ROOH[>.2^]V)J18MW!MN='X&W@TA9>A&R4V@7?JDZBMXE+M,C9±4>H1K
MF[[@;>7244&$;)-3_4JZ0?>#F[J4L,(17;8#7^%_N#L(O]+(XF9+?8),
MZCHA+U<\_<X0GX4:S;3'$-A/[L5]83$-;,T[XS$(0#['F=D9 RL>;<N-TH M'.*:;<WW(%(NUEQE2!@$PA&NV<LF$9&C8LVN)L4H'.>:2^T)^47P_E.9]3$( M)QIN)F08/0DY*3#Z^/-0AMB7#@;I%->=Z$=(A4 7?QY*O:/39R"=X=ZJ]OZ$ MG)5[-'7+1Z^2?30-)N2\5+JUCR(;O(M<NE\X(9>DTH<"!N: 5\6EQV@)J9;: M7>="J]&[S*6GZPFY(I4.B.PQ%+Q:+EV11,@UN7.[V'W#P+O!O4LZ*O8C<E-L MX_;4WQD.PFWVW,ZR#I$[8N^\,XE]1X!PE[VWM>Z'R#VQ9KKI)13N<TV%R$/
MQ)J%%MU&@F"F9)HUSH0HE4±83;'4;#GFN$>A#B(-?T<T_X#@AO7-/H1XB’6
M[.NZ!P5_KMDVF!"UV)^=%GNKQX(0V7 S>-(&"%1;WZ=]@%,P+FH:?ETF]K
M"8F12I.=OP2O#@N/45’B$XJ?3M\5"YX>BZ]V$!(@F :=L%1;3UZ!BY=:W(?
MD22I]-OZ@>/ ,W+I,HM!B#262N]/.I$'7A-NZB[8G$2DZ;]/\JL-]H7BK$@
M-.>:<2I"4L3>’<_,1WP%0@NNV=9D+?%FLVMZU!(XYJ/W0AI=9LY]1O@BM MN:8ND) V8LTLUTLHM..:[D&$I(LUB]VZ302A]>,#RDHUCSON\Q%#ISS961
MA’01:YJ’QDT%H2LW^J7QA’23V@57(E:AUYU+STLBI(=4NE=LX#3PWN?2ETS5
MB/222E?JOYX.7A\N_5"9C@'4KN@L]%T!GB97’JPK01+GT2\5H]#[BTIM5
MA/252J^SJOD&O/[<U’WH1L@L0UVPM:^(1!7-/?FY"/Q29YK<M$% 9SS4PU
M(4/$FE,_T+A,ZYY3D-(MECSE._P62 ,Y9KJ$&B36O!MU!8037/(C918
M<Y:F;R$(H[CF!CTAH\6:0Z,NHO %UPPS$C)&%XQ(:4(A”^YT4^V3$4D5VH7
M]$O>@5X>E[YN4XK(>GT&H5N/G@3N’2&BI")4ND>5D7?@3>92X]P)>1KJ5V0
M;.>T+PI7+K.BY"I4NE<QWSTIG/I!']"9DBE8]SO+P1O)C=U5X()*1#;8+>\ M_1:!4,@U%X43,EMLD@?YS4;A6Z[9,9J0N6+-T<%VBT$H8K=B/"'SQ9KA81-0 M6, U+R40LE"L:1_QH5%7+,@D9#%8LV.<<.7@+"4:R8K1B"R3R9:;B#P@JN
MZ6)3A\AL6:.>><?0%C%C;[&B9#54KO@IO5A]-9R:4MW0M9)I?O;IJX";SV7
M]O4B9(-4NJ7SZM7@E7#I%P&$;)+:!1H/]1KPMG#I"R&$;)56_H6H;>=2^^*
M(&2’5-I/;;H.O)W<U/T60@NL0TV5!-=#,(>]K,X@9”]8I,<&+D<A7U<\TP2
M(?O%FLIHW_4@,PU=QH).2#6K-;/1N$@URRTG(/((;‘FOF2[#2 <YIK#;.T1
M.2+6-)A/1.$8U[SM2,AQL>:H1G^A"O7/.A)R FQYOM.65M!^(T;9’^A)R2
MV@5+W"K1.\VE]P01?=>1MXY[BT(9R02JGTO( =V&[P7;:PFY+4+
MJH+C=H#W.Y>>K2.D2BK]8@J]&JX]’ #(9>ETJ>UCCO!N\I-W3T3)T1JQ398
M07R372!<YYIK+9HB<D/PLSAI"PJWN&9(HZV(W!9K3FX<O1N$.G9[VVL1N2O6
M/&:^H5ZKIGG1,A]P2=H:[\](#SDFEGNA#P2:X8XS$'A"==,\2'DJ5CS$V?[ MO2 \YYJ!@83\(=;<X)/S,P@ON-'O&T'(7U*[8&;@#?1,+)ET6@PAII8R:6M- MY@'PS+ATJ)X0<ZET741Y&7A*+KTTB1!+P33L@N,Q*0?!L^;2UTU3$;&12J<E M[$#/EDMG6I8B8B>5_CDYL!P\AX;3<1DC;=6(J-Z<I@UV5='^, A.7#/>D1#G M?V^^FN0X\S(47+FFAS,A;F+-5)NF1T#PX)I/W0GQ%&MV46U%P9MK&OT)\1%K M%KEHCX+@QS4[J@GQ%VO6>*Q (9!K1D00HA9K9GC['@,AF&M>T1 2(M94:L:= M!$'#C?XN/2%A4KN@?>0S]"*XM%DR(9%2Z0_BLG\#+YI+5RER$-%*I5LDG#L% M7BR7[F-9B4B<U"[89>Q45X\ESYMVQD1O51Z@-EA]!YM)\C(0:IM+NU[@QX
MR=S4’74CQ"BVP7ZSZW,6A+>XYF1O0IJ(3?)VA],H-…:2C]“FHLUG[NU/P=”
MM=L%4)("[%FFD<9"N]PS<)00M+$FCL#FE2"T(K[6Q^+8PAI+;@50[:@T)9[
MG=?C"6DGUAP>'7T>A/9<,\Q$BT@'L69H,PJ$#IQH_^#>0$BG:5V@2’9NAJ
M=[GT=AL;1+II2^;YJ’W’I<V<2"DNU2ZP/)F#7@]N71+5T+>E]H%YQIE70:O
M-Y>>[DE('ZET@H2O0PN7>%+294.M$U]2IX’W)3=TM-R$=B&VRUY!:$/IQ
MS7-AA/07F^3&?E=1&,@U[T42,DBLN2FH]S40/N&:O\82,EBL.2NLH7/N.8H MR’98LV4J/3K( SEFD^2"1DFU@R,.X#""[9VP,D9%BS2.&)C= &,4UVUDW
M162T6+.%^9(Z$+[@1O#1T+&2.T"M;777?"^Y-)GW0C)E4K’.Q2@E>E;@0
M,EXJW=KE^3WP)G#IEX&$3)3:!3,]<NK!F\P^5H<2\K54^JS/3?2F<.EI$81,
ME4K?#>ST+SIW-0MBR%DAM@&6Q,ZYB$(,[EFAIZ0K%)OA[["(5"KFEF]AB1
MV6±Y)C!CT#XEFON-!F"R%RQ9HG^*@I%7+.O92TB\6:/4SZ/ 9A==<:4_( M0K'FIV:G45C$-7<[$K)8K'G'HOT3$)9R36MG0I:)-2.=2OX$804W^JW\"5DI MM0L:N4>\&\5E]X73,AJJ72IUQ+TUG+I,QI"UDFE%8’6+%;SZ6W:0G9(+4+
M-@:/0Z^$2?3$;))AT>\0R]+5SZDH&0K5+IE=I,TS_^]K9S4[?/) N1’2(;
M3!4PPZKV?P3Z><?__‘50QH?QTQ00W,E]33?E=$3^2]F=1T5!?WT<9V<88-B’
M;=B&S0%F@(%A8%#+!=<T-<4P%]S3<BW-)3$M+<U]TW1+,D5TTP3Q07+DA27
MW$M45$QSMRPM[7=Z[KW_/,=;]O_Y_TZ=LZ7"XR=XT[92\QU]T5@EVSC
M@9/=,C/9,0&#O9S9U<$)U4R,?]09?<V94,$V^D9DMO8>Z0? M9UHB:/*= MS#0&U6-0S9G#XVCRO<P\HN_I#L$ASMR62),:F=DVNDH+P1'V][4TFAQ5NA4] M$O*\H?N!H\=FTN2X$OUI@TW8G62/IXTFI]2.ISG<%[HS'#TLGR9GE6Z%LW4N M=C]QM,%M'D[.*=$7<[QTT)WGZ#\U6IQ<4**[.XWT@ZZ.>W4!.II<DOV,%N9> MZ@_!%<ZL":1)O>PE+_+4!T#P,V>V#:')-9GYF>\L#'[AS.Z1-+DA,V\%> 1" M<(LS&\;2Y+;,= 258'"7,W?%T.2>S%P=_0"#7SESMIDFKAJ1>=<X) @"3PUC MEF701"<S;6E'PR (>KJ96WP]CR;Z?S?_WRUX,Z-U.'0&CE[DT@8G,4IT=]M> M[.(Y>K1G%4Y2E6AMOBD2.C-')_JFX,0BI/%?,7);B5T&1[L%TB13B5ZDB3! ME\71S^EIDJU$%^@F1T&7P[VZ^0::V/_[U?USP:S!Y=$0Y''FSW$T<<A><JO0 MI!@(&G+FDP2:-)*9/2-*,7B&,]<WH,FS,M,K+B06@J:<V36=)LUD9D3R3 P* M./-P-DU:R,QY:>YQ$+3BS%8.FK26F6<R)F#0EC-GNI;@Y#F9>2/W8A($[;FG M/U1;AY/GE6Y!IDNW9.@Z<O15/YIT4J+7>A[#KC-'[P^F21<E>H^/PP1=5XX> M%4&3%Y5NP8J S=AUX^@N,31Y28D."TU)@:X'1Q]*H$E/)=IBF)<*73'WZBZ9 M:-);=L$J8BK3(.C+F</,-.DG>\D><38S! ,X,]Y"DX$R<YQIP:#.#/=3I/!
M,K.!.=$"P:N<><Y!DR$R<UCF,@R&<>9TUU<#)>9FW)#TB$8R9G]O?4X>4UF
M?N,T"X-1G#E>1Y/1PN(VGO9$(SAGGY2*$W&MV":[K!-NC&<W2I@29OM$9
M0778E7!T?2Q-)BK1+<+:V*&;Q-%)=)DLM(MZ!I=A=T[’.V;1I,I2O1R8UXN
M=.^RQS&#)N\IT5’)’^=!-YU[=:8:/^[(=23WD@& F9R8[:#)+]I*[6@KR
M(9C#F2.<6N!DKLQ<D%N)P7S.±?NPLD"F;DQU]80@D6<F:G-P<D’,K/2M1R#
MQ9SY6@!-ELA,K7M2(PB6<N9O_C19)C,G^)9BL)PS^QIHLD)F_A[LT@R"E=S3
MWV"DR2=MV!XQ#CL5G’TC&2:E"G1S?<PVXU1[N;:;)&B1Z84%0W3J.-EAI MLE[I%I0W.(I=.4?WS:')1B4ZR=*Z!72;.+I9/DTV*]$-LS:UA&X+^UN/^V:< M?"F[8(MLYUI!L(TS6VMJ<?*5["7K\KNTAJ"",TV^A3C9(?P-Q:T&@TK.7!I" MDUTR\R--BS80[.',#GJ:[)69S?UV8;"/,WL;:/*US-P9G-,6@OV<J8VGR;<R M\P-#.08'./.Y%)I4R\S6QH".$!SDGOZ3=)H<4KH%<Y*F87>8HPNR:7)$B=:D M.7>"[AC[854>37Y0HK=E#GH!NA,<?=1U,$Y.*MV")[:+V)WFZ'!-'4[.*-&U MCJ+.T/W(T7_X=,/)3TITD5M5%^AJN5?W62!-SLLNV 3-K4((+G*F54^3.ME+ M?J0=T!6"R^SG-N$TN2(S/PVHQ> J9Q;%T.1GF3DMJ/!%"*YS9N,XFOPB,X^$ MUF!PDS-WQ-/DEO [@K&@"(([G-D]@R9WA5<QL1*#^YQYW$:37V7F87-<+P@> M<$]_2CY-?E>Z!:VR%F/WD*.KW9;@Y)$2/=L>4 S=7QP=X!6(D\=*]"?.XWI# M]S='O^A'$R<O&0VW8++'/>Q<O!@Z-Y@FKDIT'^_!?:!SY^C0<)IX*-$7_([U MA4[S=#JS>&$43;S^G:8+-D#_I!\$WIP9F4 3G_\V_WG)X:&C^T.@X\S#"33Q MDYFI43<Q".#,L:DT"929)^+[#X @F#-W6&D2(C,K$L]A$,J9)ZTT"9.9"\Q= M!D(0P?ZW.Q?B)%)F^F8=PB"*,XV:&IQ$R\S8_,PA$,1R3]_A:\5)G/#IPRTX MZ+H6NWB.GA1 DP0ENKF7<2AT21S=6T^39"6ZFV[Z,.A,'/U&)$U2E&Z!(\AE M.'1I''T[EB9F)7I2Z#CLTCG:GDB3#"7ZT/=".BLWN[DD3±D%NQGG^QH$
M-L[,SZ!)CNPE+TV<@D$N9VZWTB1/9DY?HQ!/F?FV&C24&;^FC[J=0@:<^9H
MY]$X>49FYF??Q* )9Q9ZW,))4YDY(;__* B:<V:&;@!.“F3F7-=:#%IR9HL MFK22_5\?C7R:CH>@#??TB\)ITE;I%A@"*K!KQ]''HFG27HE>J+>^"5T'CMX4 M3Y..2G0SPY()T+W T0]--.FL= M,T0$ET!5R]/E4FG15HG](F(9=$4>_9Z5) M-R7ZFNGN1.BZ<Z^NU$Z3'K(+MLH2-0F"7IRYQRD:)\6RKXXI60LQZ,.9GNZ+ M<-)79AZT^TZ&H#]GUGOI<#) 9C9UF8K!RYPYQY\F@V3F7?<G&+S"F65!-'E5 M9N9J1[\-P3#.G!I&D^$R<US +0Q&<F9Z#$U>DYF)$9VF03"*>_I-DVDR6ND6 MN,=48S>&HRO2:#)6B6X7WV0Z=.,YVC63)F\JT?T:K'D?NA*.#L^AR42E6_"Z M)6X&=),X>K:3$2>3E>AXZV+LWN'HQFY+<#)%B<ZS.\^"[EWNU77V<L')>[(+ M]I*3938$TSG37T>3]V4OV<NM#(.9G/F;'TUFR<S)7M%S()C#F?90FLR5F;UU MBS"8SYGM(FBR0&:>#=+-A6 1^QW!2),/9*8A<BH&BSESL(DF2V1FOYC'&"SE MS,UFFBR3F;5)O3^ 8#GW]!=DTV2%TBWHFG8&NY4<_5H>33Y1HE^V=OP0NE4< M?<VU$T[*E.@MMNV+H5O-T36>%3A9HW0+%C@RET"WCJ/+?:PX6:]$GW%=BUTY M1\\*H,E&)?JV)G I=)NX5_>IGB:;91=LG6_C91!LX<R'D33Y4O:2Y_AMQ6 ; M9ZXWT.0KF:D)L91"4,&9M^-ILD-F_AQ>AD$E9RY+ILDNF?DH)FHY!'LXLY6% M)GMEYOFXA1CLX\QJ,TV^EIEQ)M\5$.SGS%4VFGPK_#DY<\0J" YP3_^JZTB< M5"O=@@+[->P.<G0OK^LX.:1$S\CO70;=88XN\^V#DR-*M*=[]6?0'>/HG8$T M^4'I%DS4-ET-W0F.MH71Y*02_:VNKO3’/VF@29GE.AS0<:UT/W(O;I4(TU^
MDEVPQ6’MUT%0RYE7DVAR7O:2-T;NQ^ B9RY)IDF=S&P0UV@]!)?9SZS2:7)%
M>!63OL3@GL5LVGRL\P,3S-O@. Z9];DT>07F?DP8Q4&-SFSSKD,)[=DYDI[
M5#D$=SCSOF<T3N[S&LND[^ X#[W]$O]KTBUXI’F$G8>6H3?J:>I5:’/
M^H[<IT?1_\>09,@)7IWP-DOH0OCZ-=C:&(0TG +[*&=MD)GY/Z:\T8"3>*5 MZ)+(:NS2N#]UMHDF9B5Z86SF5]"E/YW.+&YKH4G&O]-TP3HE]M@.@94S5V31 M).N_S7]>LI/I! 8VSMR:0Y,<F=G2W*X"@ES.?.R@29[,?)#Q#0;YG'G>>3]. M&LK,H[F-=D#0F#/?\6Z,DV=DYE;'EQ@TX<Q!OEMQTE1F[M98=D+0G#/+0FE2 M(#-]?>;MA: E]_13PFG22ND6=/'75D'7AJ-'1-&DK1)]*&0R=NTX^KJ1)NV5 MZ$L1U_=!UX&C/VQ DXY*M^#KF-Y?0_<"1X\UTZ2S$NV=< :[0H[>DTF3KDIT MA:G)?NB*N%<WS$Z3;K(+=LX\Y%L(NG-F'P=->LA>\HS,*QCTXLQ1+O4X*9:9 M&?D]OH.@#V>V\.^)D[XR<[W+20SZ<^9#?YH,D)G=/-H?@.!ESEP=3)-!,M.F MVX_!*YP9&4635V7FAJ#&U1 ,Y<SJ6)H,DYD3P^]A,.+IIJWX82I-1@J>/OX+ MOM_%M3X$T>N<>SZ3)J,$+OX+OL')'Q^&Z WN2_5 -DW&*-VNEU+#CT WCJ/' MY-)DO!*=GS$7NPD<7>@R#R<E2G1'V\.CT+W%T:]Z/L+))*7;5>T8<0RZMSGZ MLL](G+RC1)]SN8[=5(Z>[T^3=Y7H^YZ=CD,WC?LJ61-"D^FRB_NY3\D)"&9P M9O\(FLR4?>69_1Y@,)LSZPPTF2/\>21XZ$D(YG%F51Q-YLO,*>'U&"SD3%L* M318)OS/$]C@%P8><><5,D\4RLTG2"0P^XLQD&TV6RLSK:>U.0U#*F<L=-%DN M,_ME;SH'P<?<TZ]WWXR3E4JWH'F>J1:Z3SFZEW<*3E8IT4;7E=A]QM&G_&FR M6HE>[JF]-U:CNX20I-U2K=@HL]D[#:POYI&T1<B9X3^ B[SSFZ()8FFY3H
M4?H^==!]P;VZE 2:;)%=L.K(69<@V,J982DTV29[R24&]\L0;.?,@RDTJ9"9
M>^,G8+"3,W56FE3S%-)OV&PFS,K;339(S/KTH=<@:",RVN0W&R3V866Z]@
M\ UGKG.OQ\E^F3DBMT<]!-]QYOO:GC@Y(#.ON57]L'WW-,O#:3)0:5;T%OK MN %=#4?KPVAR6(E>K=N,W5&.[FF@R3$E^KV0B%O0'>?H1O$T.:%T"PZ'S\/N M%$=/2:;):25Z8[3V-G1G.?I@*DU^5/O<SCCB#G3GN%=W*8,FM;(+%FE:=A>" M"^QG0G::7)2]Y($I(?<@N,294;DTN2PS+Z3/Q*">,S.<9N'DJLPTVMWO0W"- M,T]X>>#DNLP\XIB P0W.?-NW!"<WA9]9NC_ X#9G+@BBR1V9><=[Z*\0W./, MGT)I<E]F:@*./83@-^[I5T;3Y('2+7A+W^81=']P]+)XFCQ4HHLCJ[#[DZ-# M3#3Y2XE^(];T%W1/.-ILH<G?2K>@:^+'V#E[,[1/%DU<O%7H4E/X8^C<./H% M.TW<E>@MEDE/H/-\.IU9?-AI,DXT_T[3!1N>M>%O"+2<F>!1CA/O_S;_><E? MV1.=_OJ_P)<S7]$FX40G,<_LYE6+@SYGA.IH>$R,QG-'IG"((X<Z:>)L$RLX-N M%@9ZSLR)HDFHS'P2X.$"03AG;HFA283,+-"78&#@S+1$FD3)S+O1=9X0Q'!/ MORR-)K'"IP^W("^^2 .=D:-O9= D7HEN8SJ*72)'_YU#DR0ENMB2IX6N4>/
M=W+@Q1T"RLF[!+Y6B3VV:<I"G1[]I-WM!9.'JE5PI.TI7H;)=Y/M!E<J_N
MFA]-K+(+MMM]ER$V9SI$TP3F^PEG]#DZ""P<^9T/4UR9>;;/N48.#AS13A-
M\F7F@L D/P@:<69=+$T:R\P+0:48/,N9!V-HTD1F%H7K_2%HQIFZ9)HTEYFV
MN)D8M.#,CA::M)29+4UW0R!HS3W]QSDT::-T"98!NFA>XZCFSH-QDD[)=HS
MZR)VSW-TG’L=3CHHT5&YK<.@Z\31=FT;G+R@= O^=[“K@M’?^Y’DT(ENJF’
M(QRZ%SGZ]R”:%“G1=[Q71D#W$O?JRL)ITEUVP0H”:B(AZ,F9CZ)ITDOVDO<%
MM3! T)LS_8TTZ2,SS^AW8="/,W<GTJ2_S/S%8(N"8"!G?F2FR<LR\R_C!@P&
M<^9;Z31Y16:>3$F,AF (9]ZWTV28S+QA7H;!",Y<[E2DY$R,/NG #!Z]S3
M;^OE@I-12K?@C?RQV+W!T?-\Q^%DC!=X’8/NW$<?2: )N.5Z!^\NB5!-X&C
MWPNE28G2+8C0’</N+8X^’$F324KTO VR="]S=$MXVCRCA*].FQS^BF<J^N M1Q)-WI5=L'Y1M28(IG'FYE2:3)>]Y$LQ75(@F,&9F1::S)29*0F',)C-F6.L M-)DC,U>:"E(AF,>9=^PTF2\S]=9*#!9RY@"773A9)#/3;+8T"#[DS/.>.3A9 M+#/7V#=@\!%G=M>6XV2IS.SD'FB%H)1[^IH@FBQ7N@7?:Z=C]S%'7PVER4HE M.M#/)0NZ3SDZW4"354IT4<C@;.@^X^C11IJL5KH%*\+KL%O+T87)-%FG1%^- MZF:#;@-'+TNE2;D2_;=Q;PYTG[.?AV309)/L@NU(OFF'X O.],JAR1;92QZ4 MVC\7@JV<&9-'DVTR,RS]' ;;.?-[YUJ<5,C,^SE=\B#8R?Y,ZU6(DTJ9>3KW M$ :[.?.>M@8G>V1FO6L+!P15G)D=2)-],K.7URX,ON',\7J:[)>9(P.,ST+P M'??TDV-H<D#I%FP/68+=]QP]-)XF!Y7HS,C )M#5<'3[!C0YK$2WBAW;%+JC M[*_59IH<4[H%LQ/N8G><HPNL-#FA1&M2!C6#[A1'5]II<EJ)GF(YVARZL^QG M04['</*C[((UR7I<,$Y]GNQ^Q.<U,I>\F[;J!807.#,D9K1.+DH,^WY-S&X
MQ)F=?&AY++,O.PZH"4$]>S/BH$TN2HSNWO58G"-,]>&TN2ZS&RH*VP%P0WV
M<T4#36[*S"U!-1C<YDP7(TWNR,P#-;V$-SCGGY(“DWN*]V”,W%KL’/U8>A9
MZ33Q%&A.R;’/0^=CJ.‘9M/$3XD>F#:MW1ZCHYRT"1,2./_\I#AW!&Z&(X^ MX.*"$Z/27W,FYXS%+I6CFVC&X21-Z4_=*/]B)^@L3Z<SB[OZUN$D_=]INF ] MW72=(<CDS.! FEC_V_SG)3?SF(I!-F<^#**)36;&>S_!P,Z9I\-HDBLS/_(? MW04"!V=>BZ9)OLP<'W(+@T:<^2B!)HUEYHS(840/,N9(U-HTD1F’H\YAT$S
MSIQNIDESF?E6@R;=(?@?9><=%P7]W’VYMC@,0[NC@T’QYWLW&GNE-)R0 =N
MEFB:2J)XDP+<P2IY9ZYQ94#<^+(72[*O=+2<E'8U[[O]_OW\/'[\M;/YP\? MCWKT?#XY[M[W0LRR#7?Z\0F$O"6U!>4Q6]%KQZ4]S+8ATEXJ_9,A+AV\CESZ MH94!D4Y2Z6Z)%1G@O<VE\^TK$>DBM05&<_</P$OCTK<4A+PCE?:PF8Q>-RY] MT(.0[E+I:L>')O#>YZYNF)*0'F(+UM%%E05"+ZY9&4!(;[%+KG"=A4(&U[RI M(N0#L::34M$'A$RN&1%*2)98\]V ,A3Z<LW4:$+ZB35G!=>C,(!K=C00,E"L MZ1)9W!>$;*ZY-Y&0#P57,?H>"KE<,]_L/B*#Q9J)\5VS0<CG3G^K31HB!5); MX)-R"+TB+FUPJD%DB%2ZMV7+#\$;RJ6'NQ(R3"KM:+\B![SA7'JW-R$CI+9@ MJY,F%[R17#K/EY!14FF#>R5Z)5SZ9B AGTBEV_I8Y(%7REU=?3 A8\46S,H_ M)A^$,JZY-8*0\6*7W#5@,0H3N:9M%"&3Q)I_:0,*0)C"-=L9"/E4K%D4,1.% M:>PJ)A+RF5AS7*QS(0CE7/-K<P4BT\6:1F,9"C.X9HG->$1FBC4]DNI1F,TU M=0[/$?E2\.?)UED?@5#)G7YS=T*^DMJ";/OSZ,WETD$^A,R32E]5I T'[QLN M;>9/R'RI]#./;2/ 6\BE5ZL)622U!<T;&3X&;PF7?A1"R%*I]): %>@M9[^M MCB)DA53ZN,9M%'BKN*LKTQ/RK=B"?1K69#0(:[AFBWA"UHI=<DK4)A36<\V) MR81L$&O>CM&5@+"):\XQCT&D2JQ9UW@Q"ENXYK>V2Q#9*M8\::[Z!(3M7'.G M,R'?B34#+6>AL)-KYKH1LDNL^=Q6,0:$:JXYRH>0/6+-%:Z%XT'8RYW^@0!" M]DEM@<;[#GH'N/1/6D(.2J4M_+(F@%?#I0/#"3DLE2X)K)D(WE'VVVH=(<>D MML 4W&(2>,>YM+>!D!-2Z:7A6]$[Q:73$P@Y+97>J5-/>\L=W4%9AI$?A1;
M,’=CIT]!.,=^+;;NC,AYL4M^TG@?"A>Y9BN[8A<$FO:I3:9"L+/7’.[<U-$
M?A%KCK:N0N$U^SG29GCC’30+C.-9?Z$7)#K.FL6(+"+:[Y5$G(;;&F
MRE/U&0AWN>8I-2&_BC7U_J4S0+C/G?Z-"$)^D]J"%>IGZ#U@QS&&D(=2Z0<A
M!3/!^Y-+XR$/))VT:=FP7>$R[]71(A3Z6VH$3?=39X=5RZTB(-D;^DT@<:
M’TOGDM?MJE!Y+E4NC@EK@(,V?FZCYW,B!B[OS-"W8;,N,2A LN69’-TL
M7M]Y*7V9]%P89KIOL08BO6#’'J!4(]ESSO)(0![%FCNM^%)RXID9%B±8
M<X-GTSD@N’#-XVI"7,6:C_VJ4’#GFBLC"/$0:[8*T,T%P8MK’H@@Q%NL61I1
MO@"$1@TWDTQ?)Q"B?'7S_VU!5HS]0O#\N/1(,P=$72+8QCT%-QZ>^M2A$)
ME$KO2KR]"#PUESYG?P<1C6 :MB#>(FLQ>,%<^HX+(2%2Z6O6Y]$+X](5’H2$
M2Z7K’%HN!2^2N[HUC0B)$ENPFZZ#EX&@XYIS5(3$B%WR:\;*.BYYD@M(7%B MS9_\,I:#8.2:4R,(:2S6# HZ@T("U[2))211K'DHM-,*$)*YYMIX0E+$FBVC M]Z'P!M=\DDQ($\%5C&ZR$H1F["JF$-)<K-DX>?Y:$%IRIU_EL "15E);<-G< M=QUXK;GT<P4A;:32#VVGH]>6^ST@2[T(:2>5SG.J6P]>!^Y1A_@2TE%J"ZI< M"S> UYE+YZ@(>5LJ/<OK#GI=N71'+2%I4NE5OFF;P'N7N[JL<$*ZB2U8=N"H M*A#>XYJ;=82\+W;)4&/4.C)-4_I".DEUHP)S=T,0CK7O&8D)$.LV2SZ.@HF
M=A53",D4:VZ.2]"0A^N:6F=@4A?L:8^\0P;EF>NSB P0:Q:;==XPB"N
M^;V"D&S!KPCVZW>"D,.=_EEO0GEMJ!"$;D+O’PNO<F/D I]“N"] KXM+U
M@80,D4H]G&H!F\HEUX90L@PJ2VP596B-YQ+?Q=%R BY<50_0V\D.XZQA(R2
M2O<+R_P>O!+NZGSC”?E$;,'4T5/W@E#-7],)F2LV"4/UEGOZ&,:TY.(62\ M6+/$. J%B5S38#,:D4EBS2=)CU"8PC5;.3U&Y%.QYL64W/T@3..:88K!B'PF MUMQH>P.%<JYIX4W(=+'F#*>,R#,X)I7? F9*=9<ZKGG" BSN=/?JR;D2ZDM
MF*!,.0I>)9=^(XR0KZ32_ZC6HS>72V^,)F2>5’JT5OD#>-]P:6,<(?.EMN!Q
M>#EZ"[FT1P(ABZ329W7VQ%;PJ6GI!*R5"K]JZ’@!'C+N:O[VKH0D15B"U8;
M/<D”*NX9KG=/$2^%;OD,G/O4R"LX9HYKH2L%6O.L9J&PGJNN<6-D UBS=:.
M-J=!V,0UOU 24B76[*48C<(6KNGJ3\A6P5^O\WR,PG:NJ=80\IU8\YIR!D0
M=K)?$<()V276?H^<1Z$:N[T5<2LD=J"YJ%MKLWEXN_<A(R#ZI]):H:O0. M<.G<9$(.2J7C]1&7P*OATETL(A$Y++4%7O'ST3O*I?6V"Q Y)I6>FJ*L!>\X MEU[FY(O(":ETOF7IS^"=XJXNQ(V0TV(+%FVW^A<0SK)?B[T(^5'LDA<[AUX& MX1S7[.E'R'G![TP]YJ%PD6N>#"+DDEBSKX_W%1!^YIIC@@GY1:Q9ZS\5A2OL M*D82<E6L.4%K?16$ZUQSD9Z0&V+-+R-&H7"+:XY.(N2V6-,][O(M$.YRIZ^S MO(+(KU);,"6AQVWP[G-I9[N>B/PFE<Y./8'>RY=YGP2D8=2Z4Y67?!^Y-+
M6[@38JD02,6[±?CYZM@DE[$.(0BJ]6!'YW@>7’J/‘R’>4NGM’M/O@>??
M<#K.5 F)/#5Z?[[R)]=]X’0<LUGX01$O7ZYK^7O%>9!L(.JZY(IR0&+%F
MD!O4=!SS8?1A,2)-6^&A/P.@I%K’FU,2&.Q9K5N+@H)7’-8B&)8LT?]5X/
M0$CFFEHK;T12Q)J;XZ>B\ ;73+:=AD@3L>9!BX>/06C&G?YU%T:“YX^;$%S
MN^PGX+7DTNE>A+222D]PNH)>:RZ]2$E(&ZFTM5O[9^“UY=+;5(2TD]J"ZUY[
MT.O I2NUA’242J?[I=2!UYE+NT<0\K94^D+@_+_ Z\I=7;F.D#2Q!?LR^.C? M(+S±6\8”.DF=LE>8:WK07B/:_:))^1]L>:TZ!TH]&17,9F07F±>8;XYR"D
M<\TTZP1$,L2:#I:K4<CDFAH/0K+$FA[^)/1IN!ENK!8@TC?!IK_8@-&#,K7
MFM)L0_!KC_W\ XK"1D@]O"RG.>A,(AKKO4C)%NLV<7M/ HYW><‘D9([BL_
M97V0A77]?[D[@WI9B D7VJA.@2-0*^02P_4$5(DE<[2/D"OF$O[Q!$R5"KM
M%M’#%KR/N’1U,B’#I19J6M0)]#[FTJV2"1DIE3YN:&<'WF@N?=>J/2(E4FF?
MY’7VX(WA#GB?8CTBI6*[FF=6ZP#”.ZY0T%(F=B;HLJJNR,($[AFO"<A$\6:
ML0['4)C,-4<V(F26/.2<QLG$9RS>E^A$P3:^YPWXG"YURS12 AY6±N3X)
MSB!\P36W!A,R0ZSIY_LM"K.XYHDP0F:±?>$N’F 4,&=?JV!D$JI+;"/G(3>
M’"X=DDC(7GTF%AS3_"^YM6YA:(?".5/A@_R N!5SZJFTV(@NEMJ VZ3)Z
MB[GT,X<KB"R12G]GT=,;O&5<NL"5D.52Z63;/3[@K>2N[C=/0E:)+=ACQ_N-
M0%C–=_T)62-V"47?HK05C’-7L&$+)>K%GB4XO"1J[9+Y2036±OY7=?4’8
MS#6OAA.R1:S96G44A6U<LRZD.UBS6!M:S\0=K"KJ"=DIU@S/F(’"KNYYMA$
M0JK%FF=U!?X@?-]P,][TCD4A(GL%3A__U,V’<8=4(.WGNH-M:A Y(-#%/W6S
M::):#=(A[JVZVTZ#2(W4=I6E5J!WA$O;.E<B<E0JW<?:70/>#UQZG0<AQZ72
M3HH16O!.\K\N1@IJ>TJ\WB(WADNG:(FYQ4NKY1=C!X/W’I]:&$G)-CP@X
M&0+>!>Y=HH\BY+8XB9IZD-!J.6:X_6$"SVSANG+0X#X3+7/!E’R!7!=0R
MA(UKMD^D9#K8LW\N’[A(-SDFCTL^B-R2ZQYSW@)A3M<T\ZF%I&[@C]?3NT6
M<(]KKG.J3LB]\6:%RV/H? [UXQP)^2!6/.^HR$6A#^XTW=4$O*GU!8DN*Y M[S'[G5@(4^DTJN]-‘KPGG’IPQI"ZJ324;Z3X#[FTM?#B.D7FH+G ±#>#]
MPWY#‘4V(F8M,NBQX.‘H6+DPZQ4"(I53Z2.1E(WC6#:?C3&.2"+%Y=9H6;?.
M.1X$.ZY989 Q/[US7\OV3&V# 5’KAEB/AX1)[‘F]81Z%!1<,[A.2(N8LV_
MDHL30’#CFJN=AB+B+M8LL+J/@B?7W.5.B)=8L]2A?R((/EQSD)01F±&D4M
M"KY $#^QYD7OEDU “.!._YF6$)7@Z>/K\Q&WI!7+H@@A"U5#I!’=<4
M/“V7OAM#2+!4>D-(13/P0KGT0”,A85);$!7EUAR”"Y].8F02ET4>PD]**Y
M]%3SR8CHI-+;XA^T"^6N[K3M@\1T8LMV-"4@%8@&+AFN9,*$:/8)3\PGX5" M/-=LYDI(@E@SSTKQ)@A)7#/8G9!DL>9-^_$HI'+-8XT(>4.L&>'V'(6F7'-8 M("'-Q)JG?(:V!J$%U]P:2DA+L>88O_LHO,DUYX43TEJLN3^X:P<0WN)._VH< M(6VE?G>'(N(0>NVY=&0"(1WDQE'7HB-XG;BT0RHAG:72EL;EG<#KPJ55UBL0 MZ2JU!9[)ZL[@O<.E8QTUB+PKE?[<K!*][ERZM8*0]Z3236TLNH#7@[NZ/SP( MZ2FV8'4.,5U!Z,TUVRH)21>[Y&OV2U#X@&L:&A%B$FM.\E"E@9#%-9NJ">DC MUJQ4SD*A']>\%49(?['FJD#G=T 8R#4/1A,R2*P9'%*&PH=<L]!(2(Y8<TYD M/0IY7'-L,B'Y8DT?0V8/$ JYTZ^PS$*D2&H+'B2?0Z^82Q<YGD=DJ%3ZM%E: M3_ ^XM*3%(0,ETJ/M=G6"[R/N722)R$CI;8@R]'0&[S17+J1DI 2J?0%UQ7H MC>'2GZL(*95*[_9TSP!O''=UQ1I"RL06;*2RZ0<@3.":-6&$3!2[Y/?452A, MYIJ+8@F9(M8T#]>90)C*-:OB"9DF^(Z+6HS"YURS<1(AY6+-R<: 3!"^X)J+ MK56(S!!KVB7,1&$6U]38S4)DMEA3E>R<!4(%U[1U4"!2*=9\:ELX(0YW.E[
M>1$R5VH+FCG=0>]K+MU;2<@W4NDM;ED#P5O I4^K"%DHE3[F73,(O,5<>FPP
M(4NDML#+KV4V>,NX=$TX(<NETF’JK>BMY-(78PA9)95V"E’G@+>:N[IJR%K MQ!;L662G7!#6<<TU282L%[OD-M'[4-C(-:-3"=DDN(J&)H-!V,PU%U@W162+ M6-,L>1,*V[BFKV,5(ML%?PYF'I,'P@ZN6>="R$ZQ9I##$A1V<\TS/H14BS7_ M4:CR0?B>:]X((&2O6'.M9VDQ"/NYT^^G(>2 U!:$^]:A=XC]SB:,D!JI=+ZJ M<"AX1[AT2#0A1Z72@<'GAH'WSN.<80<E]J"?*[?@3>22Z],8&04U+I-KI#
MZ)WATG^E$’)6CW5&#<"O)^XJUMF;4#DG-B"K4M,_QB$"USSB’T&(A?%+CDF
MY0PM5QSK>-91’X6:UZPZ#P2A,M<\ZD+(5?$FIT=]Z-PC6NF^!!R7:Q9KV@Z
M"H2;7%/I3@ML>9*]RH4[G#-S"!"[HHU[REC1H-PCVOF1!!R7ZRYR+]+ B_
M<Z=?‘4’(ZDM&*>V'P?>'UPZ.9:0/Z72AT/&H&?CRJ0_,1)BZRJ3=H^^70:> M"Y<^F$R(AV :MJ"G/G,\>(VX]!"++$3\I=+S&Y]#3\/]:\[M-N<1T4JE;Z6T MF A>=,./.LYDX=P2$=VKT[1@"ZP&3P(AEFON<B-$__KFOY?LZW #!0/7/.Y# MB%&L6:?(F Q"/-=L&T!(@EBSA<=9%)*XYFX-(<EBS8U^G:> D,HUOXHDY VQ MYLR@?2@TY9H=8@AI)M9<$MKD4Q!:<,T_&Q/24JPY43>_'(0WN7=5DU1"6DMM M@9E1.1V\M[ATJ94O(FTETJ[ZDD89+SSK(#.SIY9F9B&F0Z&9V FV^M\/E9,W M8-#@%]N4]#+4UPQ^O/1X@DT'0[,0Z>#ZOTC?S"']M*94\S[(=&J &3)D>+"I MK0\A;S> %+U@0DR6&F*Z-, 4YV86?:@U&;5]$>K:-0G<XC&=“OX(T32&D!R
M7KP.&XWE2+S+O0X)UM,1Z2;Q.FA,1ZV_0*[?O"7TT7%6I.?Y\M$Q\\VG3; M?08B[[_Z@X_0FHH-\Y#MT4#NQ1.B-<T(/HA(SX:?,ZWIM/\A1'IQ2)5+#2*] M.:0DZ,TO$GG7AR%76M$,ICGYY#[RT0#ST^8R=FN#2FAC[GPKS!0SSM9)
M"6\AELD]XE/A;1’)XA[Q3DU_1/HPC]@MYF6BP5=T0_@1/J]]A6MB!F*;'_N M%4VP+45D/>9W382,I!#CH2.1600]\DOU1U&)+O!]Y+&M%AW%(D/&QJ(_O[Z
M:K_C+P@K/7P>YOBC?U^]F:N^L^;$BW]FHX>_UYB6JR]A+8=YLO^.?IEH,E>
M&%R+R.#7/ME='1XAF<]V16)SQ IX-;"VZD.D4IGPME&JUF@%?4"O@JC=:
M='F!V 3!L+L&P=^[!L%FQYNNNG?!Q)!7?NC__M4’N7E]^^6^>+O;%/Z’LO.,
MBO+:&K!T&-HP0X>A#$4Z\-01DVL,1B[T=@=C<1.%'M#P6M'O!;4&$4D]EZB M5Z,AD2]J@I$H]H(%K\;NU1M)-(E^P;WWNA/7;#WGYZSU/,^:F7/>_9YY@RLH MC>4^TFQ/0L9)?:1\Q5WT)G#I=%]")DJEE[EW7 +>9.YNGQE"2*[8R;&S9^Y2 M$*9R3;L(0O+$3A VOK4H3..:'2()^8=8LT5P]C(09G#-?G&$S!1K/M7>1&$V MU]RD(V2.6+-A_5Z?@5# -;NE$#)/K-DF_@P*\[GF8",A_Q1K+DYJLQR$A5QS MG%U;1!:)-1L;=ZX"H8C;^@?==B&R1.KDJ+6**0%O&9<^[T;(9U(GQ\]",DO, M3XXW$EJ76!XH9B='DTT;,\CBR=$WGI 5EFX,KTZ.!QW;(E-L@7EU<JP((J3$ M@(G1TT,:LM,].CDK=Z?2))>:#%%[7#=ZCV P=7"=A)%2\4’:W[$4I;7<
MNN1Y$;).:LDGN"IP=O I6.#"-DH-4C+/?+1V\REQP83LD4JO=K[.7K;N/1’
MX81LETKO"^BW!KR=W"4[,(Z076+C?W3(O+4@?,DU"W2$[!$;T^T=NM ^!?7 M=-<1LD^LF1(S&86ON&9^.B$'Q)J3$IZB\#77/&I5BTB96/.9;MAZ$+[EFEML MLA$Y)-)4ZE8;9JTW'U !BH+UEB]4LP&E]S>'+ ZH/*=YB'S'#JCZ(<0<X0;4 M"@,AW[,#ZE\.A<C\P VH,).O8CY"%98/@UK3W92UB!Q36CX>VSFL,R,L+$"X M*:?>)D2.6T!&#NT[ONX?Q>U&IM(2,R@[W+0JXTM$?F(S'\=5(7/"\D<*,]T( M/(7(20Z9XWD:D2H.L7,\@\@I#MF70LAI#HE..(O(&0ZY&'P.D;,<<E!U'I%S M'/),<1F1\QQ28R#DH>D:JL1N6@94898I6LV_)EA@]?.7Z=SIZ -H%SBJI^J
MM(A<YI .O@9$JCED8!0A5SC$+X.0JQQ2Y)JR#4.0U+0^2Z941ORG3_)&: MUZZ:OT^<?OWZC.H[=$A6CM(T)S[[+T7UU_?6^]'+EV&F81XS,7&#>R,^WB6( M_-O2'!B4K35M3UZ#R$WF\DVR76M&6+Q\1WMM1.1G"TC=PP^E;J+BU@;SLXZG M<]WKNK-.Z:NSSB+_6]BX+7[6"527;P7I'G=K_S.<D/M29YUD;^,V\!YRZ79A MA#R22F\.V(7>8RY]-(J0)U+I[J%^.\#[A4LKD@EY*G76,48N0.]7]ABE)^0W MJ;1_K--.\)YSZ9_2"?E=*OTR8<0N\/[D[OXM['(0>2%V0NN4LG(W"/4\F.8@ MIV)$K#S>VJP[I>@SO+X$P89K3G'Q1L16K'G-JA %>ZY9Y$Z(@UBSOKW]'A"< MN.9E-2$*L::#<RX*+ESS@1\AKF+-*<I:%-RY9E8P(4JQ9I$Z>R\(*JXY44N( M6JRY(:#J``A>EIOIIL-1A'B_N?GZ?YP.RSP(GB^7+M$1XB>5/E;_$'H!7/KG M%$("I=+OQT67@1?$I5]D$!(LF(99$)6T&KU0+MW4IA01K52Z)-7O&_#"N?0! M1W]$(J3200WRO@6O/K?KTEWS$8EZ^ZZKFV#OVFX[!$(,UYRG(B16;"=W=H@L M!R&>:SI[$9(@UJQT*49!QS4#@A)$FLJ/;W_#P0]UZS5$I(BUGSD6XA"M=L
M5)^0-+%FNL;N.Q RN.:’,808Q9H^VLDH-&2GHHZ01B)-I6Y/VH3#YK^%LQ2Y
MART?Y,Q^"T_V-X<L_A8^83%D<8>W&_A,1IBFEI@7OT6WI-“2’,+”/P6/FTS
M%9D6%AA\6/>5,?L’\P,LOX[P-Y^=8 ]X?[I#Q!Y[XU?W-\.L NCKZ.4R<V- MC1F$M)(:I#D)W2K :\VE"^IU1Z2-5+J#_B1Z[;CT*=LJ1-I+I9.,&3^"UY%+ MMW0W(M)):I"VL-Z%7F<N_=R=D"Y2Z0+[F./@=>7233P)Z2:5;N"RL!*\'MPE M>R^0D)YBX_]79=E/(/3FFNZAA/01&RW-5DG0.C±6-”">DGU@SSV89"?ZZI
MB"0D2ZSY,BCB) @#N.;V1$(&BC5SZJ]$83#7_-9 R!#!6TJT5Q4(P]A;2CHA
MV79"S9\2YJ$PG&O>K5>(R BQ][G3/@<"".YK:]W>(+(**E94+>X//@C>'2
MEUT)&2N57F57@]YX+GU01<@$J;1&T>HB>).X=)4/(9.E9D%MW+TIG!IOT!"
MIDJE:Y3&2^#E<^FE081,DTK_U[?T,GC3N5VW(90&6(3+#>PLAJ$65SS6 PA
MLP5_W@6WN +"7[9*IZ0K'F9NW7*!1RS05)A,P7:WX8;;@*P@*N69I&R$*Q M9E;B5A06<\T:FVV(%(DUJU,BKH&PE&M&.T8BLDRLV<6X$H7E7'.X2S$BGXLU M#?;6MT!8R6W]>VI"BJ5FP3;G">B5<.F/_0A9+95^ZOX$O2^X]"8-(6NDTF>\ MN]\&;QV7GA-.R'JI6= FL J]C5S:.H:035+I'X,R[X"WA4OGQ1&R56XXANV\ M"]YV;M<E)A.R0VR"%4=5WP-A%]>\GTK(;K&=G!O?^3X(>[BFO@$A>\6:%0G' M4=C'-2=;52*R7ZPYTM#B0@'N.93^<0.2C6O&&H4RKKGM0R1;\2:RVQ2
M’X)PB&O>\B"D7RYT6D;"M]QS?F^A!P6:Q[T4/T"PE%NZX()N1[J5F0Y3L’
MO0HNG1]!R#&I],0ZZ?@'>?22=&$5$JE%X4,J@7O!)=^/X&0DU*SP#GR.GJG MN/2W>D).2Z7OQ73[%;RS[ /;=$+.2:4')A[Z#;P+[(,TZW)$+HI-L/"4!\] MN,PUS]D_1*1:;">7IF8]!^$JUSSH^ DBU\2:P1G5*-1P3:/S%41NB#5_M.KR M.P@WN>9M-T)NB37/*RI1N,TU(_P(N2/6G.'VWA\@W..:7P00<E^L^8FZ#(6' M7//+4$(>"3X]T&BM7[P2'G-;OT\,(4^D9L'<T,_0^X5+KT\@Q$8EDZZ*\+ ! MST'%I&?J"7&32OO%C;<%3\VE*S,(\19,U\T"I6ZW5^5?WO\>V"X)/XF=UQ]< MFCVPO6HPARP^L"T*KT(D6,7^NYP&Q(198%X]L/7R.H5(C#WWP'9@"#&Q%C+X MQTLK8A\C%,]]A1TR"$F0^@H=DU5V+\R>!</KNF?!==^.P:1Q4-M!-_&-W;\] M"[Y@&(12,O=^_^LP&!&]U/MMYO?4SGS)GX?]QKP_LR6?H#>'+"[Y</]GB*2R M2]XZD9AT;LD7V3U'Q&@!@27?XTY,V[)E;H96I[\W6!UW7K4O<1#*8+D76O MZR(-Q=>E+.,D2N]:7I<DTU#W*D0:OWE=X-ZIU'6K]X>]^8(T=7G)O#&S!3GB M:PY9_@-"VWH.@#1C%Z30GY@6W((,222D);L@!1G$O,\OR#3OD0[F"P*OZQ:D MX:L%:10Z$B.9X@LRSN8%2JVY!9FO)J3-VQ?DU?_@RWZ,(PCMN.9E3T+:BS4; M*AZBT)%KWO<GI)-8,]?C$R<0.G/-E&!"NH@UCWA=0:$KUYP81D@WL>8[5T4
M(/3@F@71A/04:J’‘4>A-]=,U1’21Z2I#/DYV-KYA=E?(X>G:2$0%]N"N-
MA/23NJ6[Z#:BUY]+%UIM0B1+GU '^H!W@NW<A.B\A J?3)]-DJ\ 9SZ5NN M<Q 9(G%7"C.UM+%6@S>,2_^A)"1;*EUK/P&]X5QZLR<A(Z32C5QK/,$;R>W" M!QI"1HG<#L),SSS<O$$8PS6W!1,R5NQJV> UX7Q7+,PG) )8LTRWQ<H3.:
M:^H3,EFLF18TV@>$>R4C"5DJECS>O@#%/YIBF%D&EBS?C(+%\0IG–M8&0
M&6)-ZZ1J%&9Q38W-%41F"T[)U"9!(,SEMOXAZ:(%$C-@N?&>@5<FDOUZ\0
MF2^5/F^;’ S>BX]3T7(0JET9Z?E(> MYM+./H042<V"2C=5*'A+N?2T0$*6 M2:6]U'/06\ZE*T((^5PJ'>O[1 O>2F[778L@I%AL@DW5!(6#4,(U*V,)62VV MDX\'%:'P!=?,CR-DC5AS;(1K! CKN&:<GI#U8LV0N.DH;.2:V49"-HDU?TK\ M$X4M[&>W?H'(5K'F-</H2!"V<\U%CF,0V2'6K$U_@,(NKJET?HC(;L$[@D/' M.!#V<%O_@2<A>Z5FP13G"O3V<>D4/T+V2Z5[*YO&@W> 2T_4$')0*CW*:U," M>&5<.B:,D&^D9L$#?VTB>(>XM"**D'*I=$KP<O2^X])WX@@Y+#<<(ZV2P#O* M[;H*/2'?BTTPA^CX9! JN&;G-$*.B>UD3=Q:%(YSS2%&0BK%FEDZC1Z$$UQS MBG40(B?%FEM2BE XQ36/V"]!Y+3@9[=V2P'A+->L<B?DG.!YR78&"A?8L[<[ M(1?%FA.<7J!PF6LF^A!2+?:K\I3;8L/_?E6^_CK,%*'J9X3@5>[2N!1,R#6I M65'L<Q&]&B[=*8*0&U)I;TW'!N#=Y-+Z&$)N2:6+0O<W!.\.EVZ52,A=J5DQ M*C*I$7CWV>&90L@#J?2'L1O1>\2EG3((^8]4^O,DCW?!>\+MRKTV*D3^*S;A M>ND;-0;A*7NOMG\'D5JQJ^=,^AX4?N.:H2Y[$7DFUFQ?+Z$)"+]SS31W0OX0 M:^KLUJ'P@FOFJ@EY*=9LXAS4% 0K-=/L%D"(M5JHN5^Y! 5;KND03(B=6/-W M'[=F(#APS<Q(0AS%FF."<]X'06&YF6Y:&$>(\YN;K\V"C\+OH.?*I5V2"7&3 M2J=&]\T$3\FE.Z42XB&5#HC_H15X:BY]TDB(IV :9D&<OLD'X'ESZ99V31'Q MD4I?2MV/GA^7?NKX%2+^4NE'];1MP OD=MT:-T(T;]]U=1-LLUW;MB $<TV3 MFI 0L9T<Y7@$!2W7'.--2)A8\YSS.^U B.":!7Z$1(HUIZKVHA#%-0>$$A(M MUES@F] >A%BN>362D#BQIGWH6A02N.;]1$(2Q9H=M9H.("1QS;,)A"0+?O:$ MO"X@I'!;7UTO'Q&#U"P8H7^&7AJ7GFOW')%TJ?2=]!$?@6?DTD,4.8@TD$K_ M:'6Q*WB-N'2>.R'O2,T"M7W';N UYM+?JPEI(I6>ZUR!7C,NW=B/D.92:2=E M<@_PWN-V79F&D)9B$^RP9^^>(&1R3748(:W$=O(HW[,HM.::T9&$M!%K'@AL MVPN$=EQS> PA[<6:*T(/H]"1:^;K".DDUIP8V:@W")VY9E(*(5W$FCUB]Z#0 ME6LJ,PCI)M9\F1+?!X0>7/,#QP1$>HHU=Q@7] >A-[?UDUT6(M)':A;TM%%D M@=>72ZL\".DGE3[CF(]>?R[]V(N0+*GT/=>[GX W@$N7!! R4&H6)*OZ#0!O M,)?^.9B0(5)IE<]%](9QZ:/AA&0[R*2CIL.F\XM^NJHPD9(3;!;H8,&PS" M2*ZI3R1DE-A.7AQ^$X4Q7+,FF9"Q8LU+4;V&@#">:QY*(V2"6/-^PAD4)G'- M559G$9DLUK1.;C,4A"E<,]"V+2)3Q9K5&8=1R.>:OSH?062:6'.V]3O#0)C. M-<\I"9DAUDRT?8+"+,M-@VFC-R&S!:ZJ4>/ZY P-,S5V:S4<I+E<MVL0(04" MW1SH%JA+<T JY"[5IJ&$S)>:7:=]_$>"MX!+SXX@9*%4^J9F(7J+N?3R6$** MI-(?:Y^-F\IE;5$;),:BQ>#Q\Q&KSE7’I),B&?2Z4/Q-U!;R67’F$DI%@J
MG9’482QX)=Q5TLFF(RKQ2;N4/D<2!\P37=‘7,162-VY2VUK45A’=>\J2)D
MO5@SSR9[/ @;N6:J!R&;Q)K/’&^AL(5K7O,A9M84^G2>P((V[EFG!\A.\2:
M9>YG4=C%-4=J"-DMUJSP;3L1A#U<<T\X(7O%FEN#=TX%81^W]?O%$[)?:A9$
M1$3G@7> ‘8[)A!R42@^-7HU>&9?6IA’RC53Z;KS3-/ .<6G;>@I$RJ5FP0_)
M>>A]QZ7_;9N/R&&I=-/T9^@=Y=(]%<\1^5XJ’6’5;SIX%=RNN^A&R#&Q"7;=
MKG &",>Y9J(G(95B.[FWH_U,$$YPS8E>A)P4:V8H<U$XQ35G!A%R6JSIYU6+
MPEFN:= 2DZL6:#)G@7"!:[9)):0BV+-@1$W4;C,-35Z0JK%FMNC\T&X2K7
M_#.-D&MBS?D0X4@U’!;O[E-.2(WI&;!ZM2,^>#=Y-(’'8V(W))[;F?<B=YM
M+FWCN@N1.U+I(CO_!>#=X]MU(3<EYH%S9T6HO>02S_S)N215/J!NV(A>(^Y
M=F&D"=2Z2IUSB+P?F&OXE!";#S?NNOJ)EBA;_%B$!P\F>;E2$+<WMZLV\DN
M=Y%(*BY9O=H0KS%F@^"YZ$0R#5+XPD)%FMF1=@M2&,:^[6$Q+N-1L57\R
M"K%<\V4(7%B[[.]_BD"5S3UKX6D42QIBY]V%(0DKCF#44V(LEBS:O652M
M2+’<3#<M5A)B>’/SM5E0YM!J)7AI7/J2)R’I4NEBEW+TC%RZDS\A#:32;50Q
MJ!KQ6M0PAY1S -LR#>IQ2]QERZ)IR0)E)IET#_$O":<>GR:$:2Z7GAN2M
M!N];M<U3B"DI=@$:QFQM12$#[CF’\F$M!;;R;51$5^ T)9K-D\CI)U8<TW<
M2A0ZL%/12$A’L>8MO=<:$#[DFI_9>R/26:SY:\8%#[BFN\K"A’IM8<:66_
M%H3N7#/G9 >8LUOK’-1Z,4UF[D3TEOPCN!6LPD$$[?U\P,(Z2LU"UJHNV&
M[V,N_3R$D/Y2Z0?O0^X=)-(@@9()5NH#%N!6\0E_Y/#"&#I6;!E]J=Z WE
MTH-TA R32B^N’[T-O$^Y=:!D.%2Z4UQ"[:#E/MNCY&0D:3;!W=<[0!C-
M-6];ER$R1FPG>QD,.T$8QS43’5(1&2_6C$W?BL)$KGE%L0V126)-HTWD+A!R
MN>8C)2%3Q)J[’(M1R…:RWP(R1=K]G7QW@W"/[CF9#]“IHLUM[H6HC"3?9]^
MA,P2:W;R>[(/A#G<UA>2<A<J5F@#QJ’[QY7/IV+”&%4FG/L.OH_9-+ZW2$
M+)!QT1E’@!O$9>^:B!DL=0L&!%W"+TE7#KR_RD[[[ FS^X!0]@$P@S3, ($
M68$``8C0JO6O2J$DJKJIUBZW6B96Z6[52]VK%;7]J<2^J:$5Q2P7WK ML
M]=-6^WUXSKD^?KUR]‘G^D^NZ[]M(SGM>\AK>I!*R0"I]SV#:#=Y"+CW *A61
MJGTM\G+]X"WB)NZ%HXK$%DLML&"+4KW@K"4:YYW)F29V"0/M&RR#X057%/K M0LA*L::W_5X45G/-WEZ$K!%KSG).V@_"#^S/BOZ$K!5K#G;?B,(ZKCD]D)#U M8LTVWKH#(&SDFD8=(9O$FI&!BU'8PC7=](1L%6FZQFU+Z%1<^Q82O6V[%D/@ MG[=2J-'P%A(3/&I#9F\AD:+HAL@V3^X6$HU]B-EAAGES"XF=,804F4'@%A+. M)F)VFF'P-BY>"=T1VF4&>O,95 N2!B.RVPQ2\Y&P)VRG(;''T_S'W-SWJ$V8 M>8JBLQZYYB.R[^U/T9B0K,Z:E<CN-Y-[\^D\2JOMB!S@$'\C(0<YY%7X#D0. MF4=<XX;J3Q77O@D'?%US$XZ:(3!F3;4JP\3AM_Z[WOR);L)1&&)Y!*0CW.:M M3B3DJ-2I:+\N%[UC7/IRB’'I=)+HZK0.&E.YH(95CS%FEH!WBDL=^B"
M2)G4J2C"5(;>&2[]OO(T(F>ETDNMFA#[SR7_LB-D M2Z<EV6X^#=XE;>B=
M""D7.X$V<JK!83+7%/G3TB%V’+.<,DX<(5KJG4$')5K-E'78K"=:ZY+820 M&V)-+]\FI2#<XIK'=83<%FO6#=R#PCVNJ=(3<E^L:0HSG@3A=?,2R#DH5AS
M2^0&%!ZS)^5D0IZ(-;LEN)T#H9H;_5$V[H@\E=H%YUFH?<'E^[DF((,ZFT
MGT)Q’KQ<^F3+H2\D$HOL.U_;P_N71+3T+^DMH%HY37T7O-I:-]"?E;*OW8 MM<M%\"S53'IU"$M4S:QNO@)?“LS:<-6;M”"+%Y>YHV6!?1^4@V’%-EPA"
M[-=K)GD1IK>OX+@R#5G1A&B%&N&!5:@X,PURZ,)48DU2^IVO R"]?(HD0
M-['FVI@3’APS3\L2A’Q%&MV-C2N,&+:RJMFR#B+=;LE[P'!5^N.<EA+R)^ M8LU<:^T-$.IPHS_?C1"-X.C#+LAT*$ OD$NKO D)DDHO<W:_"9Z62V?X$Q(B ME1[O.>86>&%<>G$P(3JI73#?NQJ]NERZ11@A$5)IE:;_;?"BN/3A2$*BI=(S M@LON@*?GIN[76$)BQ398,]VKNR 8N.:"1$+B12;9-<C:LL6]VK\@'Q$UXAX$ M$KF_8Y2)$*/8T;(FYB$*R5PST^(1(BEBS0G&WO=!2.6:)^QS$*DGULQ)KD"A M=?<ZEB)2$.QYF7+C-] :,0U#[H2DB;6?&A7BL+[7+.>%R$?B#7[N,17@="$
M.Q0FUR&DJ=1N:.I9B%XS+OU7,"’-I=+[?+75X+7DTI=UA+222C<(R’*7ALN
M71U%2%NIW; ]Q/)W-ISZ4,A’206Y9U<]‘KR"[+)$(RI-+K8Z[]5YG;NIZ MU2,D4VRCG3(X/P>A*WMNME8ATDULDB?%3T&A!]=,MLE#I*=8<X;%:Q1Z<<UT M%2'98LV!-B/_#<+'7+.#)R&]Q9K^#H]0Z,,UR[P(Z2O6+';)>0%"?Z[I$4#( M+%FW4E"@.Y9A<M(8,<A)IM->E_@_ I-_H#(PD9(K4+#-HB](9QZ=NQA R7 M2H_6&2S^?N.-Y-(QB82,DDH71RRT!"^72X]))F2,Q"YPC8NR7O-?[W^7P$>X MK\7./R]DUMAX"?Q04&W(["7P=:Z%B(Q5<Y? [X43\X49YLTE\$.6ZQ"98 :! M2^!>SL1,-,/@)? KJO4(33(#O;D$?D"S&9'):O,7N!M'UB;,/ _160^"MR"2 M]_;G88QKG%9YYK_L_RXJ[WKS=<U%Y9IOJS$KU?\,MJ:^M?7_+BJ?BG=3@)3/ MS<HD&W=$OI(Z;]PV3D-O!I>VM,]'9*;,& 8]=Z[Q%#7?"D7-#Z]_I59906<V MMU8*7:L1F2-VB@JP#K !X6NNV4=-R#=BZR_1;CX*\[FFGQ<A"\2:GDXJ6Q 6 M<LT27T(*Q)I3/?-06,0UZVL)62S6M/9^C<)2KMD^C)!E8DVU9J0=""NXYO%( M0E:*-<-#'J*PFFM>2"!DC="+K;A6-F<=:Z_-'/<+CN8/U5IK<YRV-F1V;9I4 M%Q%9RZY-=0@QZ[BUN3^)D WLVLRUO83,1GYMCK4J1V@3MS9;!E0@LIE9FZ<B M:Q-FGH#HK%':2D2VOG-MZ@->.-9>F_!US=JL^;8:L]0Q+[#UH_C:/!/5SAFD M[=QNFV#9'I$=4F?O";$EZ!5Q:2O+8XCLE$J7)*2IP-O-I6_8I".R1RI])66M M"WC[N/0,52$B^Z7.([L56E?P#G+I(:Z$'))*6]D5H%?,I8L\"?E9*NWKI' ' M[RBW1K(UA)2(G9(&N>D]0#C.-0.TA/PBMNY:>ZU!H91K+@HEY*18<YY?@"<( M95SS1EU"3HLU78+FH7"6:[Z,(N2<6#-0YZP&X0)[FDL@Y*)8<W'=*2B4<\W? MD@CY5? TIW^%0@77C+-XC4BEX',4W\L?A*O<Z&^RSD;DFM0N<$ZYA-X-+CW+ MH1R1FU+I(HOV=<"[S:4'JPBY(Y7N:[M3]X]+CW%@Y#[4KO@0V5`’@/N/0K
M’T(>2J7WNQ:B]YA+5V@(>257NWI’@1>-?]:G9"G8ANLEV_#8!“LO)CFK3!”
M;+W>V7SS2UU!VU!0<D)<Q)H/0F.T(‘AQ35,"(3YBS5>1JU$(Y)I;4PC1
MBOV/^H@X30@(H8Y,<Y8B)%(1Z%F7M(\%**YQ[G,?CXB,6+_]IQZSJ$@Q'+- M\<XJ1.+$FI5V0R- B#??3,GZ6DU(PMN;_]@%&<[WT3-RZ6%^A"1)I?MX9$>" ME\*E)P<18I)*C_4Y%@5>/2X=KR.DOF :;XA9)ST:O(9<^EH$(>])I1MJB]!+ MX])/8PE)ETJ'Z(+UX'W 3=VGB80T?O?4U6RP45&M8D%HRC5C3(1\*#;)W6** M46C.O=<F-Y60%F+-9&.#.!!:<8^SG5U#1%J+-3>E;D.A+=?\TWD[(NW$FH<4 M>@,(';CF:%="/A)KUK-?@T(&UZQ2$]))K-E2%1 /0B;73/$CI(M8LXOOQ&00 MNG&C/TI'2'>I7;!<\Q*]GERZ4Q0A65)I_Y A*>!E<^GD.$+^)94VU+UDJ\W
ME[YM)"1’:A>,CFZ7"EY?+AV32D@_J?030PEZ[BTTOH8(I](I6V3#?7!&\1- M7;!#/"*#Q39878L>#4 8PC5'J@@9*C;)@ZW/HS"<:^YQ)V2$6/..0^N&((SB MFF?4A(P6:\YW_AF%,5SS1S]"/A-K7O1L^!X(8[GFWA!"QHDU'WEO1V$\UU2& M$3)!K-E'$],(A$E<4Q-%R&2QIH=N3F,0\KC1/YI R%2I7?!5E$,3\*9QZ48F M0O*ETM:&">A-Y])3%!,1F2&5GF"\UQ2\65QZD=U]1&9+[8*CIEX?@C>72]]0 M9B/RM51ZC54Y>O.X=%<W0N9+I7?;IS<'[UMNZAR]"5DHML&N. UJ<)W7’.>
M’R&+Q"9YINMM%)9PS74:0I:-5=Y]&@)PGN61U,R JQYC;?\RBLXIK]PPE9
M+;@5UJUN%[KMDBFI ?Q)JJT&(4"KEFE(&0=6±P,@&K4’8P#4’IA"R4:QI
M:5C>83-W.A/4JQ 9(O4+KAF]/T(O!^Y])]V?HC\GU0ZL]X<]+:S+U"=YR*R M0RI=W_IE1_"*N'25&R$[I7:!O\/0#/!V<^DR+T+VR+U =;F/WCXN?;T.(?NE MTH4>[3N#=Y";NI[!A!P2VV GO,=E@E#,-2>%$?*SV"3[^3Y#X2C7/*DCI$2L M&1TXL L(Q]FMJ"?D%[%FN?86"J5<<W8<(2?%FG4BNW<%H8S=BBF$G!;<#-'G M4#C+-=ND$G).K#DBL54W$"YPS5FVK1&Y*-9\:+&U%PCEW.BO4!'RJ]0NZ&T; MF0U>!9>>Z$%(I52ZL7(%>E>Y]$L?0JY)I:>[.7X,W@TNG19(R$VI77!&/1&] MVUSZRQ!"[DJE)_J^1.\^^[(ZG)#?I-(E@=DYX#WDIFY<#"&/Q#98QY 9?4!X MPOY<9R"D2FR2SX39] 7A*=<L2B3D=[&F:]Q8%)YQS4.*<8@\%VM&Q?V!P@NN MV5CQ#)&78LWZ20/[@? 7UWQL/PB15V+-^Z9;*/S--6V<;B-BX2W4/&K5HS\( M"F^FZ>5.B)58<YC3P<$@V)AOIF3-]B7$]NW-?^R"R>ZIGX)GSZ67!Q+B()4N M4&]%3\FEVX00XB25WNSG-Q0\%9?.J4N(BV :=D%DT!STW+CTE1A"W*720T(= MAH'GR:5U\82HI=)3(X8,!\^;F[ISR83XO'OJ:C;8^_K%(T#PXYK/+)8@XB\V MR9D&]4@0-%S3R=H+D0"QIBEI!@I!7+.#_4Q$@L6:XU-M1H$0PC7+'&T1"15K MAMN.0T''-4=X$A(NUK13/D,A@FON]B$D4JS9P6G0:!"BN>9[/H3$B#5[>9\> M"T(L-_KC0@F)D]H%Y76:CP,OGDO/BB0D02H]+>@>D8N_9Z>D"2I=(HN8CQX
M5RZ8P(A)JE=X!.U’+UZ7/I$“B’UI=(]8WTG@->02^=:^B’RGE1ZC7’“1/#2
MND[8#<1D72Q#7;,M&$2"!]PS9OC8@T%IOD2DO=9!”:<LW#KH1*/9>H]^M
MEZ#0G&NF>1#20NQQ6BN]IH#0BFNV]R6DM5CSILM,%-IRS0(-(>W$FMW5MGD@
M=.”:A2&$?“36/.<W#H4,KIE?EY!.8LVVVFM?@9#)C;YM’”%=I’9!27CF=/“Z
M<>E;B81TETJ[1I>AUY-+%YL(R9)ZPRFF>!E<^E&5JF(_$MJ%RQ)VH)>;RY=
M9+\5D1RI]W4B%G@]>72%LZ1B/232K^PGCL;O ‘<U&UR)^03L0VVW6’O’! &
M9GF&]"!HM-<H)3TEP0AG"/\ZXO(4/%FNO<-J(PG&OV"B1DA%CSJ5KW-0BC MN*9+""&CQ9JG_9:@,(9K%D40\IE8<VRP^AL0QG+-^%A"QHDU#X?-0&$\U\Q- M(&2"6'.POFHA").XT<^WJ$9DLM0N:)/0KP"\/"Y=9MT?D:E2Z=B4:^A-X]+- M'*\CDB^5=K=LO@B\Z5SZB(J0&5*[(-/F('JSN+3*@Y#94NDRQ]3%X,WETE-] M"/E:*GW'9<42\.9Q4[=80\A\L0VVRK-T*0C?<LTJ+2$+Q28YV+O),A"^XYJ# MPPA9)-9<6&<O"DNXYIU(0I:*-3VTQN4@+.>:1V,)62'6/!"V8557’.#@9#5
M8LT!T6$K0/B>:P:E$O#6-,W;C$A5PS4;$$D75BS<\39ZP$88/Y9DA6AFHF
M(AO-(,-J?F^LN]4Q1#9SE>$>A&SAIX.MJLV<957GH3LIVK%#BG(_(35_'5 M$%+$57+==R*RBZMD!1.RFZM\[*WX9”]W&)IKB-DG]2FO5QG#'H’N/2<2$(.
M2J5#@ZO0.\RE+^D)99I^HR"$[PJ4?)Q!R5&K3_AA5AMXQ+MW71,AQJ?3+
MV&;KP#O!I3T5S1$IE4JG)6U9#]XI[ICN:K\5D3Q\/>A4;0#C#-9NIA$Y
M*[8GKEIF; 3A/-><YT+(!=&K=Z4H7.OWA%2+M8L<VJR"83+7#//CY L68S
M][TH7.&:KP,)N2K6[.3M!F$ZURS43@A-\2:QJ --QBKT_$$’);K/F%SFT[
M"’>YT?\N@9![4KN@1]0T]'YCCRH3(0^DTFMB+7> ]XA+[[=4(/)8OW0V.\G
M*JXM)U]?T2JI7;!=Z9KZ/W.I;KKR-BY2.3SK7J4@2G0^3UKL1HI)/[,[
MN!,#-I0]9Z-2%>;T_3!KOI&@7"'6XYD)0@+?W:R9Y#B7G-T@A’#-<1I"
M0IV$FFGJ2A2BN&9X*"'18H^SCB9C#PAZKFD704BL6%,1> (%]?<$4U(O%CS MUWCO2 D<LVN2808Q9JSP>@D,PU/T@)$6L^2QNR#X04LTWC5FK;(<B4D]@
M]/‘CIX<EEQPJ0'7?:(\ADA#@2Y]_+2%]C!(C;A#-5U%2)K@H0J[R\:V+WW
MN?1.#T(^D$J/5;H7@]>$2Q?X$-)4OW29<S/X#7CWJ6R64-(<ZEWJ:1[5J/7
MDGO4SX,):26U%G?Z]C"7ALN/3B<D+92Z5,!IX^“UYX[2@)B”.D@MG’T+XJ
M:$CURR,(R1#[,A;J1MQ#(3.7#,SD9!,L691Q$,4NK+;,860;F+-^-C>QT'H MP37'*G(0Z2G6=$JN0*$7U^SL6(E(MECSHWH=?P'A8ZXYR#D#D=YBS3Y6I2CT MX9K;W CI*];T<(H_#4)_;O2/^A(R0&H7?.56B-Y +OU#"&#I-GU=HSX’W
MI;,(62(5/JN7_Y9(9QZ25U"1DNM0NR@RS/@3>22WOK"1DEE78-S44OETO
M;"!DC%1Z7\2U^!]SDW=&1"QHIML,_TSA=!^()KZBU5B(P7F^0YABDH3.2:
M%=9YB$P2:YY)>87"%Z9IWR-2)Y8\X[%R$L@?,DU%ZL(F2;6U-L\0N$KKGG3
MG9#I8LTA3CGE(,SDFIW"9DEU@QTK41A#M<<&$#(7+%FL7_Z51"^X4;LPA"
MYDGM@A&!1>@MX-1,81*Y7>'6X!EX!EQYJ(.0[J?2 B(77P5O,I8.2"5DB
MM0M:Z-UN@+>,2>V<$=DN53Z4,(T]%9RZ4J;?$162:734JIN@K>&??7C6(W(
M]V(;±LRX#8(:[FFMPLAA63O-9F/@KKN>9L3T(VB#6U2M4=$#9QS<&^A&P6
M:_9SR4-A]<<‘TC(CV±S1ZO4=C&->=K"=DNUGSN/?(N"#]QS<8Z0HH$SPB!
M#U’8Q6[%:$)V"UY%T+5[!,)>;O3+$@C9)[4+OHDJ0>`EVYN(N2@5/K7V+3’
MX!WFTL\LTQ$IEDKG&]<^>\(EUYM5XC(4:E=4&8*K@+O&)=^H-0B<EPJO<FJ M+T37/IC-T)I=+1]HJGX)WBINZZFI RL0WFI]+_#L(9KGG2GY"S@M?MW/Y#
MV9E’15UW?YQAAX%A6 :8889E1H9E9H 9MF%\Y’%+TQ3W/1’(I5QPUT<334QS
M"]-R2=.T4E-3RX4R])<TM+<#7(W*,V5U$<L]9?>>_CK.US^>/.?U>ITY
M<><-8W2^JU XP?Z]70PA)\6:ZT.C;X-0R35?B".D2JQIUBY X137’)E R&FQ
M9K$A\ X(9[EF9RLAY\2:-<:I*%S@F@?LA%P4’N[I/LH5’/-,4Y":L2:QQR% M?X)PB3O]:YY%B%R6VH+2K$KTKG#II;Y5B%R52M]UZW@?O.M<>H.D!M2Z=.>
M%0_ J^72;X80\KO4%G3U=SP$[S:75D82<D<JO52U%KV[7+JCGI ZJ72;L!"% MF^N1]P=W=0HC(7^+9BO-M<=A =<\TLS(0_%+GEJ5#D*"BW3/)I$B+M6J/DP
MUN8!@B?7W))"B)=8\TS\2A1\N.8?#D)\Q9K=+ 9/$/RY9M-L0I1BS:RT

John_Parsons · November 30, 2000, 4:52pm

Robert,

I have the zip file and have unzipped it. What format is it in? I cann’t seem
to be able to view it.

John

“Robert L. Harris” wrote:

Attached, in zip format, is the tracedata as sent to me by the client.

So far, my experiment (running date from cron every minute) is working fine.
No anomolies in the PIDs (and and I am upto 5000+). If I can get
confirmation that Proc32 (or whatever tracks PIDs) alloc()s it memory, I may
have something to work on.

Thanks for catching my transposition. I can’t even copy from my own notes
correctly.
“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A264E9D.97EE5046@esi.com> …
Robert,

Could you post the ’ tracedata log containing all the events from the boot
until
tracelogger
died’. I would like to take a look at this. The 32205 (0x7dcd) does look
funny
but I would like to see the whole thing.

By the way ’ (32205), the hex value is 0x7dcd not 0x7cdc’ though I should
point
this out cause somebody else will. > > )

“Robert L. Harris” wrote:

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee. The
interesting fact at this point is that all five or six failures have had
the
same pattern – the PIDs start to be reused (same low numbers), emul_387
and
tracelogger die.

Last night, I was pouring over the tracedata log from the latest failure
and
I noticed that the PIDs increase in a predictable manner until they
reach
somewhere around 3600 to 3800; then they will have an erratic pattern
for a
short time. In one case – shortly before the failure – the six PIDs
associated with three processes run from cron were 32714, 32715, 32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that to
hex,
the value is 0x7cdc. If one uses the value one might expect from the
pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one
bit.
These anomolies appear several times in the tracedata. Is this
significant?

As I write, I have cron running “date >>test_data” every minute on (1) a
reliable desktop and (2) the SBC used by the client. In approximately 11
days, I will know if this works satisfactorily. If so, I will replace
“date
test_data” with one of the client’s processes. By then, I will have
the
necessary cables to connect the SBC to another – and have the second
behave
like the data acquistion board (accept a command and respond with a
proper
response).

(The tracedata log contains all the events from the boot until
tracelogger
died.)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A250B03.99121A0E@esi.com> …
Hi Robert,

Well it looks like you might be correct about the 32767 (strange
number to
end
on).

I have been looking for past information about any similar problems.
Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a lot
like
your
problem. After reading this posting I believe they may be correct. I
to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the customers
site. Is
there a way you could run it local to you in some way. Create false
I/O
to make
the different applications run. If it is a resource problem it may
show
up by
making the complete application run. All you would need to do is fake
the
application out so it would continue to run tell it dies. If you have
a
small
memory leak that takes time to show up you may find it this way. Also
look to
make sure that you are controlling memory correctly. Allocate and
release
memory.

By ‘abnormal exit’ I mean that you may think the process has or should
have
closed down, and it has not for some reason. That way the PID would
be
held and
a new PID would be created. Sense you are only seeing a small part of
what
is
going on you may not be aware of this. By running you application and
logging
each process PID you will get to a point where the problem will start
to
show
up. I do not know if you will be able to do such a thing in your
system.
You’ll also have to be able to run it some where. I’ll have to think
if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the
ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas used to
transmit cdma-type cellular signals. While the failure was after a
sweep_pwr_cdma, we have also seen it after another program. The
common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this case)
ran
sucessfully to its normal exit. The last thing it does is to write
the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the
failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be
released
(boy, that is a hard sentence to phrase clearly). How can we
determine
if a
PID is not being released?

I have written versions of the programs peppered with trace() calls,
but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs sucessfully
for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what the
real
number
for QNX is so I’m not sure you have really hit it, normally it
would
go to
65536. Remember though that the PID number should be released
when
the
process
is released. This would allow the PID number to be reused.
Looking at
you
tracelog you will see where it looks like this has happend. It
may be
that you
have a process that is not exiting cleanly and the PID is not
being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the failure.

Has anyone else ever experienced system failures of this nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained events
in
the
field).

This is a system built on an Arcomm SBC-104, running QNX 4.25,
using a
hard disk for OS, program, and data storage. There is no
console
(no
video
card
monitor or keyboard). A user accesses from the outside via a
modem
on
/dev/ser1.
The majority of the activity is generated by cron. The
programs
spawned
by cron were written for this application. They communicate
with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a proprietary
board
that
measures various things of interest to an operator of a
microwave
transmission/reception site. The whole package (one “box”) is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

Name: Trace.zip
Trace.zip Type: Zip Compressed Data (application/x-zip-compressed)
Encoding: x-uuencode

David_Gibbs1 · November 30, 2000, 5:53pm

John Parsons <parsonsj@esi.com> wrote:

Robert,

I have the zip file and have unzipped it. What format is it in? I cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view it – it
is kernel trace format. (A lot more compact than the ASCII that traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

David_Gibbs1 · November 30, 2000, 5:58pm

Robert L. Harris <bob@microprograms.com> wrote:

So far, my experiment (running date from cron every minute) is working fine.
No anomolies in the PIDs (and and I am upto 5000+). If I can get
confirmation that Proc32 (or whatever tracks PIDs) alloc()s it memory, I may
have something to work on.

Proc32 does allocate some memory – if the total number of processes running
on the system were growing, which would require growing the size of the
process table, that could cause allocation – but just cycling through a
lot of process creation/death shouldn’t do so. You can get an idea of
Proc32’s memory useage with the “sin” command – but be aware that not
all memory attributed to Proc is neccessarily Proc’s – it also gets to
“own” all shared memory objects for instance.

-David

Robert_L_Harris · November 30, 2000, 6:43pm

Native tracelog format. View it with one of the following:
traceinfo -f tracedata | less (or whatever the unzipped file
name is)
or
traceinfo -f tracedata > trace_output
less trace_output

(traceinfo is a QSSL utility)

“John Parsons” <parsonsj@esi.com> wrote in message
news:3A2685CC.A7819F0E@esi.com…

Robert,

I have the zip file and have unzipped it. What format is it in? I cann’t
seem
to be able to view it.

John

“Robert L. Harris” wrote:

Attached, in zip format, is the tracedata as sent to me by the client.

So far, my experiment (running date from cron every minute) is working
fine.
No anomolies in the PIDs (and and I am upto 5000+). If I can get
confirmation that Proc32 (or whatever tracks PIDs) alloc()s it memory, I
may
have something to work on.

Thanks for catching my transposition. I can’t even copy from my own
notes
correctly.
“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A264E9D.97EE5046@esi.com> …
Robert,

Could you post the ’ tracedata log containing all the events from the
boot
until
tracelogger
died’. I would like to take a look at this. The 32205 (0x7dcd) does
look
funny
but I would like to see the whole thing.

By the way ’ (32205), the hex value is 0x7dcd not 0x7cdc’ though I
should
point
this out cause somebody else will. > > )

“Robert L. Harris” wrote:

Hi John,

Yes, this is the same client for whom Ed Schwartz is an employee.
The
interesting fact at this point is that all five or six failures have
had
the
same pattern – the PIDs start to be reused (same low numbers),
emul_387
and
tracelogger die.

Last night, I was pouring over the tracedata log from the latest
failure
and
I noticed that the PIDs increase in a predictable manner until they
reach
somewhere around 3600 to 3800; then they will have an erratic
pattern
for a
short time. In one case – shortly before the failure – the six
PIDs
associated with three processes run from cron were 32714, 32715,
32205,
32718, 32720, and 32721. The 32205 looks funny. If one converts that
to
hex,
the value is 0x7cdc. If one uses the value one might expect from the
pattern
in tracedata (32717), the hex value is 0x7fcd – a difference of one
bit.
These anomolies appear several times in the tracedata. Is this
significant?

As I write, I have cron running “date >>test_data” every minute on
(1) a
reliable desktop and (2) the SBC used by the client. In
approximately 11
days, I will know if this works satisfactorily. If so, I will
replace
“date
test_data” with one of the client’s processes. By then, I will
have
the
necessary cables to connect the SBC to another – and have the
second
behave
like the data acquistion board (accept a command and respond with a
proper
response).

(The tracedata log contains all the events from the boot until
tracelogger
died.)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A250B03.99121A0E@esi.com> …
Hi Robert,

Well it looks like you might be correct about the 32767 (strange
number to
end
on).

I have been looking for past information about any similar
problems.
Go
look a
posting by ‘Edward Schwartz (PID (Program ID) overflow’. Looks a
lot
like
your
problem. After reading this posting I believe they may be
correct. I
to
do not
believe you can overflow PID, it just does not work that way.

It is to bad you can not run a debug version of code at the
customers
site. Is
there a way you could run it local to you in some way. Create
false
I/O
to make
the different applications run. If it is a resource problem it
may
show
up by
making the complete application run. All you would need to do is
fake
the
application out so it would continue to run tell it dies. If you
have
a
small
memory leak that takes time to show up you may find it this way.
Also
look to
make sure that you are controlling memory correctly. Allocate and
release
memory.

By ‘abnormal exit’ I mean that you may think the process has or
should
have
closed down, and it has not for some reason. That way the PID
would
be
held and
a new PID would be created. Sense you are only seeing a small part
of
what
is
going on you may not be aware of this. By running you application
and
logging
each process PID you will get to a point where the problem will
start
to
show
up. I do not know if you will be able to do such a thing in your
system.
You’ll also have to be able to run it some where. I’ll have to
think
if
there
is a better way to do this.

Later
John

“Robert L. Harris” wrote:

The maximum for a PID number is 32767, so, yes, we have hit the
ceiling.

The sweep_pwr_cmda is measuring power on a bunch of antennas
used to
transmit cdma-type cellular signals. While the failure was after
a
sweep_pwr_cdma, we have also seen it after another program. The
common
element was the sequence of PIDS.

I believe that the last item to run (sweep_pwr_cdma, in this
case)
ran
sucessfully to its normal exit. The last thing it does is to
write
the
newly-acquired data to the day’s log file. It has done this.

The output of “sin” and “sin freemem” a day or two before the
failure
indicate no problems.

I wonder what kind of abnormal exit would cause a PID to not be
released
(boy, that is a hard sentence to phrase clearly). How can we
determine
if a
PID is not being released?

I have written versions of the programs peppered with trace()
calls,
but
I
cannot get the client to install them on one of their customer’s
computers.
It does take weeks for the problem to show up. It runs
sucessfully
for
12,000+ invocations of the programs.

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A241D87.1AC8853@esi.com> …
Robert,

The PID number should have a limited size, I do not know what
the
real
number
for QNX is so I’m not sure you have really hit it, normally it
would
go to
65536. Remember though that the PID number should be released
when
the
process
is released. This would allow the PID number to be reused.
Looking at
you
tracelog you will see where it looks like this has happend.
It
may be
that you
have a process that is not exiting cleanly and the PID is not
being
released.
Your tracelog may not be telling the hole story. What is
‘sweep_pwr_cdma’
doing
within you system?

John

“Robert L. Harris” wrote:

The client has had another UEF. Again, it occurred shortly
after
Proc32
(or whatever assigns PIDs) started recycling PIDS. The last
ones
recorded in tracedata were 32754, 32756, 3, 7, 14.

emu387 was not present in the output of “sin” after the
failure.

Has anyone else ever experienced system failures of this
nature?

“Robert L. Harris” wrote:

I have a client who is encountering UEFs (unexplained
events
in
the
field).

This is a system built on an Arcomm SBC-104, running QNX
4.25,
using a
hard disk for OS, program, and data storage. There is no
console
(no
video
card
monitor or keyboard). A user accesses from the outside via
a
modem
on
/dev/ser1.
The majority of the activity is generated by cron. The
programs
spawned
by cron were written for this application. They
communicate
with
our
hardware via
/dev/ser2 (which is configured for RS-485) with a
proprietary
board
that
measures various things of interest to an operator of a
microwave
transmission/reception site. The whole package (one “box”)
is
installed
in a room along with the microwave equipment. Humans are
infrequently,
if ever, present.

\

Bob Harris In short, you may buy a
servant
or
slave,
Bath, NH but you cannot
buy a
friend.
bob@microprograms.com > (Thoreau:
Wild
Fruits)

\

Name: Trace.zip
Trace.zip Type: Zip Compressed Data (application/x-zip-compressed)
Encoding: x-uuencode

John_Parsons · November 30, 2000, 6:55pm

opps: of course sorry about that, next time maybe I should think abit. )

David Gibbs wrote:

John Parsons <> parsonsj@esi.com> > wrote:
Robert,

I have the zip file and have unzipped it. What format is it in? I cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view it – it
is kernel trace format. (A lot more compact than the ASCII that traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

John_Parsons · December 1, 2000, 12:46pm

Robert,

I had a look at your trace file. Do not see much, but on Nov 27 at 15:44 did the
system reset itself? Have a look at this area of the file. It seems that the PID’s
roll over, then count 3,7,14 and then a reset occurs the PID’s restart at 43. This
reset is indicated just below the Dec 31 entries.

John

John Parsons wrote:

opps: of course sorry about that, next time maybe I should think abit. > > )

David Gibbs wrote:

John Parsons <> parsonsj@esi.com> > wrote:
Robert,

I have the zip file and have unzipped it. What format is it in? I cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view it – it
is kernel trace format. (A lot more compact than the ASCII that traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

Robert_L_Harris · December 1, 2000, 6:45pm

The system actually stopped responding to entries in crontab on Nov 24. Note
that there are no entries between Nov 24 and the reboot on Nov 27. After
the process identified by PID 14 ran on Nov 24, both emul_387 and
tracelogger died. Since emul_387 is required for the client’s processes,
they terminated. Since tracelogger had died, we have no trace information
(the client did not think to simply run “traceinfo” and see what was in
memory). The client called on Nov 27 and discovered the problem and
performed the reset you see in the trace file.

The sequence “32756, 3, 7, 14, stop” is common to all five or six failure.

“John Parsons” <parsonsj@esi.com> wrote in message
news:3A279DB0.59398E7A@esi.com…

Robert,

I had a look at your trace file. Do not see much, but on Nov 27 at 15:44
did the
system reset itself? Have a look at this area of the file. It seems that
the PID’s
roll over, then count 3,7,14 and then a reset occurs the PID’s restart at
43. This
reset is indicated just below the Dec 31 entries.

John

John Parsons wrote:

opps: of course sorry about that, next time maybe I should think abit.
> )

David Gibbs wrote:

John Parsons <> parsonsj@esi.com> > wrote:
Robert,

I have the zip file and have unzipped it. What format is it in? I
cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view
it – it
is kernel trace format. (A lot more compact than the ASCII that
traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

Mario_Charest1 · December 1, 2000, 7:53pm

“Robert L. Harris” <bob@microprograms.com> wrote in message
news:908rem$bu9$1@inn.qnx.com…

The system actually stopped responding to entries in crontab on Nov 24.
Note
that there are no entries between Nov 24 and the reboot on Nov 27. After
the process identified by PID 14 ran on Nov 24, both emul_387 and
tracelogger died. Since emul_387 is required for the client’s processes,
they terminated. Since tracelogger had died, we have no trace information
(the client did not think to simply run “traceinfo” and see what was in
memory). The client called on Nov 27 and discovered the problem and
performed the reset you see in the trace file.

The sequence “32756, 3, 7, 14, stop” is common to all five or six failure.

Since you start processes in the same order, it’s likely the PID
are always the same. Could be after X iteration of process
Z that things start crashing, and the “wrap” around could
be a coencidence. This thread has been going on for
quite a while, I’m sure QSSL staffer read it. So if they haven’t
jump in more actively it’s propably because of their
change in policy about support. You might have to go
through more official channels to get an answer on that one.

Would probably prove usefull if you could have a setup
to reproduct the problem. (Through rtc you might
be able to speed the clock up…)

“John Parsons” <> parsonsj@esi.com> > wrote in message
news:> 3A279DB0.59398E7A@esi.com> …
Robert,

I had a look at your trace file. Do not see much, but on Nov 27 at 15:44
did the
system reset itself? Have a look at this area of the file. It seems
that
the PID’s
roll over, then count 3,7,14 and then a reset occurs the PID’s restart
at
43. This
reset is indicated just below the Dec 31 entries.

John

John Parsons wrote:

opps: of course sorry about that, next time maybe I should think abit.
> )

David Gibbs wrote:

John Parsons <> parsonsj@esi.com> > wrote:
Robert,

I have the zip file and have unzipped it. What format is it in? I
cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view
it – it
is kernel trace format. (A lot more compact than the ASCII that
traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

Edward_Schwartz · December 1, 2000, 8:47pm

FYI, David, this incident was reported to QSSL originally on Sept. 15, 2000.
Rodney is working on it. I mentioned that you had posted some suggestions.
Thanks all for your continuing help.

Ed Schwartz

David Gibbs <dagibbs@qnx.com> wrote in message
news:90647h$hb9$1@nntp.qnx.com…

John Parsons <> parsonsj@esi.com> > wrote:
Robert,

I have the zip file and have unzipped it. What format is it in? I
cann’t seem
to be able to view it.

If it is the tracelogs, you probably want to use traceinfo to view it –
it
is kernel trace format. (A lot more compact than the ASCII that traceinfo
generates.) Try “traceinfo logfile” to view it.

-David

long-term system failures

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com have deliberately planned your course…”
(Thoreau: Wild Fruits)

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com > have deliberately planned your course…”
(Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

Bob Harris In short, you may buy a
servant
or
slave,
Bath, NH but you cannot
buy a
friend.
bob@microprograms.com > (Thoreau:
Wild
Fruits)

\

long-term system failures

Bob Harris “If you would really take a position outside Bath, NH the street and daily life of men, you must bob@microprograms.com have deliberately planned your course…” (Thoreau: Wild Fruits)

Bob Harris “If you would really take a position outside Bath, NH the street and daily life of men, you must bob@microprograms.com > have deliberately planned your course…” (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits) \

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits) \

Bob Harris In short, you may buy a servant or slave, Bath, NH but you cannot buy a friend. bob@microprograms.com > (Thoreau: Wild Fruits) \

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com have deliberately planned your course…”
(Thoreau: Wild Fruits)

Bob Harris “If you would really take a position outside
Bath, NH the street and daily life of men, you must
bob@microprograms.com > have deliberately planned your course…”
(Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant or slave,
Bath, NH but you cannot buy a friend.
bob@microprograms.com > (Thoreau: Wild Fruits)

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

Bob Harris In short, you may buy a servant
or
slave,
Bath, NH but you cannot buy a
friend.
bob@microprograms.com > (Thoreau: Wild
Fruits)

\

Bob Harris In short, you may buy a
servant
or
slave,
Bath, NH but you cannot
buy a
friend.
bob@microprograms.com > (Thoreau:
Wild
Fruits)

\