Re: BPCS-L Digest, Vol 1, Issue 644 -- BPCS-L




To Steve:

Concerning historization of BPCS files we BPCS V 6.1. GA archived the
following files: ECH, ECL, ECS, ECT, ESN, EIL, IPP, LLH, LLL, LLM, LLX,
PDA.

Rgds

Hans-Georg Loef
Impress Metal Packaging
Central MIS





bpcs-l-request@xxxxxxxxxxxx@midrange.com on 03.06.2003 20:12:51

Please respond to bpcs-l@xxxxxxxxxxxx

Sent by:    bpcs-l-bounces@xxxxxxxxxxxx


To:    bpcs-l@xxxxxxxxxxxx
cc:
Subject:    BPCS-L Digest, Vol 1, Issue 644



Send BPCS-L mailing list submissions to
 bpcs-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.midrange.com/mailman/listinfo/bpcs-l
or, via email, send a message with subject or body 'help' to
 bpcs-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
 bpcs-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of BPCS-L digest..."


Today's Topics:

   1. INV900 Oops (Al Mac)
   2. RE: INV900 Oops (DeeDee Virgei)
   3. Re: Deleting BPCS Customer records (RCM) - mixed mode version
      6.04heavily modified (Al Mac)


----------------------------------------------------------------------

message: 1
date: Tue, 03 Jun 2003 12:15:12 -0500
from: Al Mac <macwheel99@xxxxxxxxxxx>
subject: INV900 Oops

I am looking for suggestions while I struggle looking into some things.
We are BPCS 405 CD

I work nites and this info was as of what I figured out last nite

Last Friday night most of the EOM was done, finishing up Saturday
Morning.  I was long gone from the system.  Monday I was informed that
something went wrong with INV900, know not what exactly.  The hope is that
we can do June transactions almost like normal, then some recovery effort
in the next EOM.  What I expect is that there will be NO May totals in the
system except any reports accounting ran from MTD perspective and from
files not affected by INV900, so the total sales for JUNE will really be
MAY plus JUNE combined, and some files will be out of sync with each other
for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files
REORG until I have a better grasp of what files went thru EOM Ok, and which
will have a double month next EOM..

This means the new sales reports that I developed last month with Y"all
help should be considered as trash for now, and the AMP TYCO report will
not be available for another month.  AMP TYCO is one of our vendors ... we
send them a monthly report on how much raw materials we ordered on behalf
of each of our customers, in which the data is computed using combination
of BOM and Sales History.  Well I consider Sales History to be the same
value as GARBAGE until I figure out what is Ok.

WRKOBJ INV90* gets at a list of related INV900 major steps
8 (eight) enter scroll second screen shows DATE last time that program was
used

The following were last used end of May (last Friday)
INV900PM (prompt screen)
INV900C (Main CL from menu)
INV903 (I think this is involved in the cycle count clean up at the start
of INV900)
INV903O (report associated with cycle count distraction at very beginning
of INV900C)

The following were last used end of April (a month ago)
INV900 (main RPG program)
INV904 (Rel-2 version)
INV901C (I think this runs close to the end of the whole operation)

According to SSARUN03, the files that INV900 messes with are
IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story and
that we do use ACR900, but I have lots of clues to explore

Some of these files are updated during the course of daily transactions,
while some only EOM hits.  I happen to have been messing with RCM Friday
before EOM due to placement of customers on a report sequenced by customer
name.

I know from past experience that YTH file contains copy of ITH transactions
cleared off in the previous EOM.  Our YTH file is empty of records (DSPFD
list members ... the date not help me ... my speculation is that when a
file is cleared, that does not alter the date of last change, it is only
adding or changing records that updates that).  We used to write off last
month records to tape, not do that any more, I not remember when that
policy changed ... that could be why January 2003 is date of last change of
YTH.

I have some software off GO CMDSCDE that I not check every week, but from
it I see that our ITH Inventory History file had
1.330 million records as of a week before EOM
1.347 million records as of late afternoon of EOM (before final shipping
and some other transactions) = 17 thousand added in the 4 day week
1.347 million records (about 500 more) first thing Monday morning
1.350 million records Monday evening (3 thousand added during Monday)
This tells me that the INV900 did not clear off the records older than our
SYS800 system parameters (should be 365 days ... I still need to check to
make sure no one mucked with that) so I know INV900 did not get to whatever
step where that happens
It also tells me we have not lost anything valuable records wise

There are some files updated by EOM that I not sure if they supposed to get
updated each day ... some of them supposed to have MTD data like last
shipment, but I not know when that data goes in
SSD & SSH Sales History files last updated last Friday EOM

Now unless something other than INV900 updates them, this tells me that
INV900 successfully got through at least part of a step ... but I still
need to look at MTD, month 01, etc.

I expect these files to change every day and they were in fact last updated
Monday June-2
IIM Item Master
ILI Inventory by Item Warehouse Location
IWI Inventory by Item Warehouse
RCM Customer Master

I am not sure what all updates these  ... they were last updated Monday
June 2
IWM Item Warehouse Master
SSM Salesperson master

I ran a list DSPFD all files when last changed.  I only looking at some of
them.
In most cases the date last used is same as date last changed.

Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
When I not regularly look at some things, I not know what is (ab)normal

The menu launches INV900C whose CL uses a lot of soft coding, so it not
obvious what job calls what job.
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

>From: Al Mac <macwheel99@xxxxxxxxxxx>

Forwarded from the office


>Will do.
>
>You may recall that the reason we not want people doing BPCS transactions
>on the weekend of EOM is that with an EOM date of SATURDAY, that if you
>finish FRIDAY nite then someone posts transactions DATED in the fiscal
>period you just closed, BPCS treats those transactions as if they had in
>fact gone in the month that you just closed ... altering opening balance
>... which Mike discovered by seeing that Opening Balance of CSTOPS had
>changed during course of month.

I checked ITH date ranges ... nothing got posted dated Saturday or Sunday.

>But what you describing sounds OPPOSITE scenario.
>
>There is another wrinkle ... if someone enters transactions LAST MONTH but
>DATES them into the FUTURE, BPCS does not include those transactions in
>the EOM.  We have had a scattering of that kind of scenario in the past,
>and I did not know all the implications of such activity.  Using a wrong
>date on BPCS transactions can occur through human error, where the user
>not realize what they doing, and they can occur through human
>misunderstanding of the role of date in BPCS transactions.
>
>INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have a
>change in procedure a few months ago which would have somewhat lowered the
>run time, but I still expected it to take several hours.  I did ask him to
>track how long various tasks take, and update his check list.  It may be
>that some things have changed significantly in time duration without his
>check list reflecting that.
>
>It is not just inventory opening balance that INV900 updates, also stuff
>related to sales history files.
>
>What I fear is that the job ended normally in IBM terms but abnormally in
>BPCS terms such that there might not be an IBM JOBLOG with clues.

There was no job log for me to examine.

>>Al,
>>
>>
>>Mike had mentioned the month end close on INV900 ran quickly.  I don't
>>believe it ran correctly.  Items show activity in the MTD totals now when
>>they should only show an opening balance.
>>
>>
>>I don't think this will have an impact on operations, but it might create
>>problems at the end of this month.  Please investigate this when you get
in.
>>
>>
>>Thank you,
>>
>>Tim
>>
>>  -
>
>-
>Al Macintyre
>BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>Find BPCS Documentation Suppliers
>http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.htmlFrom
 KASP6281@xxxxxxx Tue Jun  3 13:07:00 2003
Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38])
 by linux.midrange.com (8.12.8/8.12.8) with ESMTP id h53I6g9N025243
 for <bpcs-l@xxxxxxxxxxxx>; Tue, 3 Jun 2003 13:06:56 -0500
Received: from KASP6281@xxxxxxx
 by imo-d06.mx.aol.com (mail_out_v36.3.) id i.1e3.a3bfd58 (25305)
 for <bpcs-l@xxxxxxxxxxxx>; Tue, 3 Jun 2003 14:06:17 -0400 (EDT)
From: KASP6281@xxxxxxx
Message-ID: <1e3.a3bfd58.2c0e3d99@xxxxxxx>
Date: Tue, 3 Jun 2003 14:06:17 EDT
To: bpcs-l@xxxxxxxxxxxx
MIME-Version: 1.0
X-Mailer: 8.0 for Windows sub 6011
X-MailScanner: Clean
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.2+
Subject: Re: Deleting BPCS Customer records (RCM) - mixed mode version 6.04
 heavily mo...
X-BeenThere: bpcs-l@xxxxxxxxxxxx
X-Mailman-Version: 2.1.2+
Precedence: list
Reply-To: SSA's BPCS ERP System <bpcs-l@xxxxxxxxxxxx>
List-Id: SSA's BPCS ERP System  <bpcs-l.midrange.com>
List-Unsubscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,
 <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=unsubscribe>
List-Archive: <http://archive.midrange.com/bpcs-l>
List-Post: <mailto:bpcs-l@xxxxxxxxxxxx>
List-Help: <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=help>
List-Subscribe: <http://lists.midrange.com/mailman/listinfo/bpcs-l>,
 <mailto:bpcs-l-request@xxxxxxxxxxxx?subject=subscribe>

Hi Steve.

I would guess that from your comments you have already looked at any custom
files that you have created for your "heavy modified" version.  Another
thought
would be the quote and RMA files if those are used by your company.  You
may
have included those in your order and sales history comments, but I thought
that I would explicitly state that.

Do you use item substitution?  There is a file with customer number values
available as an input called IAI.

Are you using and Promotions and Deals and need to address the files such
as
PDB and PDM?

Do you use planning bills that can also be tied to customers?  The files
such
as KAO and KPR would need to be investigated.

Do you capture tax data?  There are BPCS tax files such as RTX that need to
be accounted for.  Perhaps you use another package like Vertex that needs
to be
updated as well.

Do you use OLM?  There may be some transaction files such as LLL, LLH. LLX,
AND LLM for the transactions that you have created.  There also may be some
notes in the LNT file.  Also there are other cross reference and master
files
like LEX and LPS that may have been used.

Since you are in the US, I would guess that you are not using Draft (Cash)
Management that also has customer references, but if you are, these would
need
to be considered.

Also, I would say that you addressed A/R, but does that explicitly include
ARP?  There are also files in that area that would need to be addressed.
These
would include RMX and RND.

As for the archiving of data, I would presume that if you reuse the
customer
numbers that the metadata has references to a date range or some other
identifier if you are going to keep multiple years data for analysis
whether for
branding or just trend analysis.

This is all that I can think about right now.

Good luck.
John Kasper
JD Kasper & Associates, Inc.
KASP6281@xxxxxxx

------------------------------

message: 2
date: Tue, 3 Jun 2003 14:14:00 -0400
from: DeeDee Virgei <DeeDee.Virgei@xxxxxxxxxxxxxx>
subject: RE: INV900 Oops

Hi,

We are on 4.05 CD...  When we run inventory M/E (INV900), INV901C then gets
submitted to batch...  Since your INV901C program wasn't used this month
and
from the last dates used on your other programs, it looks like during
submission of your M/E,  the options on the 2nd of screen of INV900 were
set
as follows:
INV900-02 ...
          Print all Outstanding Cycle Counts        Y      (Y or N)

          Continue with Month End Procedure      N      (Y or N)


These are the defaults setting; we have to change them every month to N
then
Y...  This being the case, the impact would be pretty much the same as not
running INV900 at all.  We once forgot to run INV900; ended up running it
the next evening and had to make some adjustments to some of the reports...

Hope this helps.


DeeDee Virgei
Nelson Stud Welding, Inc.
7900 West Ridge Rd
Elyria, OH 44036

 -----Original Message-----
From:       Al Mac [mailto:macwheel99@xxxxxxxxxxx]
Sent: Tuesday, June 03, 2003 1:15 PM
To:   BPCS Users Discussion Group
Subject:    INV900 Oops

I am looking for suggestions while I struggle looking into some things.
We are BPCS 405 CD

I work nites and this info was as of what I figured out last nite

Last Friday night most of the EOM was done, finishing up Saturday
Morning.  I was long gone from the system.  Monday I was informed that
something went wrong with INV900, know not what exactly.  The hope is that
we can do June transactions almost like normal, then some recovery effort
in the next EOM.  What I expect is that there will be NO May totals in the
system except any reports accounting ran from MTD perspective and from
files not affected by INV900, so the total sales for JUNE will really be
MAY plus JUNE combined, and some files will be out of sync with each other
for MAY JUNE.  Thus it might NOT be SMART for me to run the weekly files
REORG until I have a better grasp of what files went thru EOM Ok, and which
will have a double month next EOM..

This means the new sales reports that I developed last month with Y"all
help should be considered as trash for now, and the AMP TYCO report will
not be available for another month.  AMP TYCO is one of our vendors ... we
send them a monthly report on how much raw materials we ordered on behalf
of each of our customers, in which the data is computed using combination
of BOM and Sales History.  Well I consider Sales History to be the same
value as GARBAGE until I figure out what is Ok.

WRKOBJ INV90* gets at a list of related INV900 major steps
8 (eight) enter scroll second screen shows DATE last time that program was
used

The following were last used end of May (last Friday)
INV900PM (prompt screen)
INV900C (Main CL from menu)
INV903 (I think this is involved in the cycle count clean up at the start
of INV900)
INV903O (report associated with cycle count distraction at very beginning
of INV900C)

The following were last used end of April (a month ago)
INV900 (main RPG program)
INV904 (Rel-2 version)
INV901C (I think this runs close to the end of the whole operation)

According to SSARUN03, the files that INV900 messes with are
 IWM IWI ILI RCM SSM SSH SSD ITH and I know that is not a complete story
 and
that we do use ACR900, but I have lots of clues to explore

Some of these files are updated during the course of daily transactions,
while some only EOM hits.  I happen to have been messing with RCM Friday
before EOM due to placement of customers on a report sequenced by customer
name.

I know from past experience that YTH file contains copy of ITH transactions
cleared off in the previous EOM.  Our YTH file is empty of records (DSPFD
list members ... the date not help me ... my speculation is that when a
file is cleared, that does not alter the date of last change, it is only
adding or changing records that updates that).  We used to write off last
month records to tape, not do that any more, I not remember when that
policy changed ... that could be why January 2003 is date of last change of
YTH.

I have some software off GO CMDSCDE that I not check every week, but from
it I see that our ITH Inventory History file had
1.330 million records as of a week before EOM
1.347 million records as of late afternoon of EOM (before final shipping
and some other transactions) = 17 thousand added in the 4 day week
1.347 million records (about 500 more) first thing Monday morning
1.350 million records Monday evening (3 thousand added during Monday)
This tells me that the INV900 did not clear off the records older than our
SYS800 system parameters (should be 365 days ... I still need to check to
make sure no one mucked with that) so I know INV900 did not get to whatever
step where that happens
It also tells me we have not lost anything valuable records wise

There are some files updated by EOM that I not sure if they supposed to get
updated each day ... some of them supposed to have MTD data like last
shipment, but I not know when that data goes in
SSD & SSH Sales History files last updated last Friday EOM

Now unless something other than INV900 updates them, this tells me that
INV900 successfully got through at least part of a step ... but I still
need to look at MTD, month 01, etc.

I expect these files to change every day and they were in fact last updated
Monday June-2
IIM Item Master
ILI Inventory by Item Warehouse Location
IWI Inventory by Item Warehouse
RCM Customer Master

I am not sure what all updates these  ... they were last updated Monday
June
2
IWM Item Warehouse Master
SSM Salesperson master

I ran a list DSPFD all files when last changed.  I only looking at some of
them.
In most cases the date last used is same as date last changed.

Some weird ... RMAs last changed Mon June-6 but last used Fri May-30
When I not regularly look at some things, I not know what is (ab)normal

The menu launches INV900C whose CL uses a lot of soft coding, so it not
obvious what job calls what job.
-
Al Macintyre
BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/

>From: Al Mac <macwheel99@xxxxxxxxxxx>

Forwarded from the office


>Will do.
>
>You may recall that the reason we not want people doing BPCS transactions
>on the weekend of EOM is that with an EOM date of SATURDAY, that if you
>finish FRIDAY nite then someone posts transactions DATED in the fiscal
>period you just closed, BPCS treats those transactions as if they had in
>fact gone in the month that you just closed ... altering opening balance
>... which Mike discovered by seeing that Opening Balance of CSTOPS had
>changed during course of month.

I checked ITH date ranges ... nothing got posted dated Saturday or Sunday.

>But what you describing sounds OPPOSITE scenario.
>
>There is another wrinkle ... if someone enters transactions LAST MONTH but
>DATES them into the FUTURE, BPCS does not include those transactions in
>the EOM.  We have had a scattering of that kind of scenario in the past,
>and I did not know all the implications of such activity.  Using a wrong
>date on BPCS transactions can occur through human error, where the user
>not realize what they doing, and they can occur through human
>misunderstanding of the role of date in BPCS transactions.
>
>INV900 normally takes SEVERAL HOURS to do its thing, but Mike did have a
>change in procedure a few months ago which would have somewhat lowered the
>run time, but I still expected it to take several hours.  I did ask him to
>track how long various tasks take, and update his check list.  It may be
>that some things have changed significantly in time duration without his
>check list reflecting that.
>
>It is not just inventory opening balance that INV900 updates, also stuff
>related to sales history files.
>
>What I fear is that the job ended normally in IBM terms but abnormally in
>BPCS terms such that there might not be an IBM JOBLOG with clues.

There was no job log for me to examine.

>>Al,
>>
>>
>>Mike had mentioned the month end close on INV900 ran quickly.  I don't
>>believe it ran correctly.  Items show activity in the MTD totals now when
>>they should only show an opening balance.
>>
>>
>>I don't think this will have an impact on operations, but it might create
>>problems at the end of this month.  Please investigate this when you get
in.
>>
>>
>>Thank you,
>>
>>Tim
>>
>>  -
>
>-
>Al Macintyre
>BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/
>Find BPCS Documentation Suppliers
>http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.

------------------------------

message: 3
date: Tue, 03 Jun 2003 13:04:15 -0500
from: Al Mac <macwheel99@xxxxxxxxxxx>
subject: Re: Deleting BPCS Customer records (RCM) - mixed mode version
 6.04heavily modified

We on 405 CD mixed mode so you may have some files we not have.
We heavily modified so we have added some files
We not using all applications so there may be files we not see that
relevant to you
Forecasting, Performance

Look at ESH ESL SSH SSD
Look at members other than *FIRST in the Customer Order files EC*

It might be useful to review how many files have more than one member,
related to this topic (most excess related to work stations that not exist
any more)
You can get at that with a DSPFD dump to Quer/400 list

Be careful about partial deletes of some records from files.
Example ... if a file has sequence #s 1 2 3 4 5 for individual records of a
related scenario and you delete # 3, a program that reads in sequence might
never reach 4 5.

We do mass wipes of several files (records coded for deletion) each year,
but I wait until I am told that the auditors are finished for the prior
year before I implement this, just in case they would like to look at some
of that data that is coded for deletion.

When I don't have anything more important to work on, I delve into file
clean up (negative costs are probably the most urgent for me right now),
but have not had much time for that in eons.

We have had problems with ORDERS
We run out of numbers and return to zero
There is history still out there on numbers that get reused
The new order comes pre-supplied (contaminated) with all kinds of stuff
from the last time we used that order #

We have had problems with ITEMS
We delete the item ... that item is still in history all over the place.
We reassign the item ... it comes pre-supplied with irrelevant data that
confuses people

We have had problems with G/L batches trying to use same Journal as already
exists.

We have had problems with REUSABLE VENDOR #s
Our range of #s for one time checks is a bit small for a year's worth.

I have a program SYFILCOUNT which takes DSPFD dump of all BPCS file
statistics and correlates information, alphabetically by file, to help me
prioritize what needs work.

With SQL (the program is not home with me right now, just a copy of the
report from last nite, so I can't give you the precise code right now)
I can count how many records in various files have an
item that is not in IIM
customer not in RCM
vendor not in AVM
etc. to help guide me which files need which kinds of cleanup

I have lots of files I plan to add this kind of thing to
Many files extract date range ... oldest record is nice to know

Ask your various departments how long they need various kinds of data ...
some departments only interested in what happened yesterday, some want to
be able to look at a year's data, some want last 2 years sales price
history but no other datums that far back

Check those associated with A/R
Check those associated with history of stuff associated with customers -
shipments
Do you have old quotes, RMAs? ... look at EC file members OTHER than *FIRST

When does stuff go away from sales history files?
The oldest dates in our SSD and SSH files date back to when we converted
into BPCS 405 CD

There are some files that BPCS never purges ... ES*
ESN Notes can exist on Orders, Customers, RMA, Ship-To that no longer exist

Do you have customer types no longer used?
We have some item classes for particular kinds of customer business
(associated with ECS special charges)

When we close out business with a customer, we have to deal with the fact
that the end items on those customers had an estimated annual usage, which
when factored into the BOM, meant we storing safety stock on raw materials
used on that customer needs, so we have mechanisms for identifying what
changes need to be made to our items retention.

>Hi Steve,
>
>Be very careful - all references to those customers would need to be
>removed - you know how upset BPCS gets otherwise! We are working on an
>archiving program for customers right now, we already have options for
most
>of the other BPCS areas - orders, inventory, etc. If you want to work with
>us on this we'd be more than happy. It looks as though you are based in
the
>US, in which case Unbeaten Path are selling our BPCS Archiving tool over
>there now as 'Locksmith'. Let me know if you need any more info,
>
>hope this helps,
>
>Clare
>
>Clare Holtham
>Director, Small Blue Ltd - Archiving for BPCS
>Web: www.smallblue.co.uk
>IBM Certified AS/400 Systems Professional
>E-Mail: Clare.Holtham@xxxxxxxxxxxxxx
>Mobile: +44 (0)7960 665958



>----- Original Message -----
>From: "Steve Segerstrom"
>Sent: Tuesday, June 03, 2003 5:13 PM
>Subject: Deleting BPCS Customer records (RCM) - mixed mode version
>6.04heavily modified
>
>
> > We are  mixed mode version 6.04 heavily modified
> >
> > We are running out of customer number ranges and need to clean up some
of
>our old customers (I doubt Montgomery Wards, Handy Andy, etc will be
back).
> >
> > I have a list of customers with no activity for over 4 years ... So I
>don't really have problems with deleting things that still have activity
in
>AR, Sales History, etc. Also have another method to archive.
> >
> > Anyway - I am looking at deleting records from ESP (special price), EIX
>(customer part xref), ESN (notes) RCM and EST. AR and CDM are taken care
of.
>These are not EDI customers....
> >
> > Can anyone think of any other files I should look at?
> >
> > Thanks.
> > Steve "trying to be the computer janitor"
> > Intermatic Inc
> > (815) 675-7469
> >
> >
> > _______________________________________________
> > This is the SSA's BPCS ERP System (BPCS-L) mailing list
> > To post a message email: BPCS-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
> > or email: BPCS-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/bpcs-l.
> >
> >
>
>_______________________________________________
>This is the SSA's BPCS ERP System (BPCS-L) mailing list
>To post a message email: BPCS-L@xxxxxxxxxxxx
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
>or email: BPCS-L-request@xxxxxxxxxxxx
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/bpcs-l.

-
Al Macintyre (macwheel99@xxxxxxxxxxx via Eudora)
Al's thoughts http://radio.weblogs.com/0107846/
See Al at http://www.ryze.com/go/Al9Mac
Cure cancer. http://members.ud.com/about/
Emergency notification (homeland, weather, etc.)
http://www.emergencyemail.org/



------------------------------

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) digest list
To post a message email: BPCS-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.



End of BPCS-L Digest, Vol 1, Issue 644
 **************************************
The  information  contained  in this e-mail and any attachments is strictly
         confidential  and  may be legally privileged. It is intended
solely for the use of the individual or entity to whom it is addressed. If
         you are not the named  addressee,  you are hereby notified that
it is prohibited and may be unlawful  to disclose, copy, distribute, store,
         copy the information in any medium or usage for another purpose.