|
From: bpcs-l-request@xxxxxxxxxxxx
Subject: BPCS-L Digest, Vol 7, Issue 60
To: bpcs-l@xxxxxxxxxxxx
Date: Thu, 14 May 2009 09:35:19 -0500
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..."
*** NOTE: When replying to this digest message, PLEASE remove all text unrelated to your reply and change the subject line so it is meaningful.
Today's Topics:
1. Re: BPCS-L Digest, Vol 7, Issue 58 (McGovern, Sean)
2. Re: QCCSID & 65535 (McGovern, Sean)
3. LX source question. (Bryce Martin)
----------------------------------------------------------------------
message: 1
date: Thu, 14 May 2009 09:41:06 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] BPCS-L Digest, Vol 7, Issue 58
Thanks for the info Debasish,
Sounds like I may have a reason to learn Java, not sure if that is a
good thing. I'm glad AS/SET is going, but not so glad that the AS/SET
generated source is still in use ! But why are you debugging - surely
there are no bugs anymore ?? ;-)
The setup at GSK seems appropriate, QCCSID should be set to whatever is
relevant for the LPAR. What do GSK use for the Western European LPAR,
937 ?
Reading through the Infor NLV documentation again, I see that if the MLS
product is being used, the job CCSID will be changed at the startup of
ERP LX (to match SYS600 settings), thus making the QCCSID irrelevant for
the BPCS users. But it seems that the host-code page should be set
differently depending on whether the user is performing database events
against the MLS files or against the rest of the BPCS files. Not sure
how that is going to be managed ! I guess I just need to get ERP LX
installed and start testing...
Cheers,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On
Behalf Of debasish chakraborty
Sent: 14 May 2009 06:01
To: BPCS GROUP
Subject: Re: [BPCS-L] BPCS-L Digest, Vol 7, Issue 58
Hi Sean,
If you are implementing LX then the technology to learn is how to
Weblicate customised menus/programs. LX does not have client server so
it is either web or full grenn screen and I mean full including cea, OLM
etc etc, websphere, webtop etc. The web uses IBM websphere and java and
sort of screen scraping and create wrappers around the display programs
for web. Oh I forgot no AS/SET but you have to debug AS/SET code in
RPGLE. Have fun.
As far as the ccsid is concerned I think keeping a default at the
highest level is recommended probably for backward compatibility. I am
working for GSK and probably they have the second largest user license
using BPCS (Bent Nielsen is there I dont know if you remember him). They
have different CCSIDS for different servers and they not only have
western european but chinese , arabic , Japanese etc. Like for there
arabic language based servers the QCCSID is 420. So I think keeping the
CCSID right is the ideal way to go. IBM if I am not wrong does not
recommend 65535 if you are using multi language multi environment.
Thanks & Regards
Debasish
The past, it's a story. The future, it's a mystery. The present, it is a
gift.
IBM System i - For when you can't afford to be out of business.
From: bpcs-l-request@xxxxxxxxxxxxunrelated to your reply and change the subject line so it is meaningful.
Subject: BPCS-L Digest, Vol 7, Issue 58
To: bpcs-l@xxxxxxxxxxxx
Date: Wed, 13 May 2009 12:00:07 -0500
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..."
*** NOTE: When replying to this digest message, PLEASE remove all text
of 65535. This doesn't seem like a very good choice to me and one that I
Today's Topics:
1. QCCSID & 65535 (McGovern, Sean)
2. Re: QCCSID & 65535 (Clare Holtham)
3. Re: QCCSID & 65535 (McGovern, Sean)
4. Re: QCCSID & 65535 (rob@xxxxxxxxx)
5. Re: QCCSID & 65535 (McGovern, Sean)
6. Re: QCCSID & 65535 (CRPence)
----------------------------------------------------------------------
message: 1
date: Tue, 12 May 2009 18:41:19 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: [BPCS-L] QCCSID & 65535
We are planning to install BPCS LX. Infor recommends a QCCSID setting
would like to change.
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
If we keep the database as the shipped value of CCSID 937, and (try)
value of 937 be a better choice than 65535 ? This would ensure that if
(when) anyone did connect via a 5250 job stream with a host-code page
other than 937, at least the System i platform will attempt to correctly
translate the data. 99% of the users we support are Western European
users, so translation should be handled correctly be the system.
something
Sean
------------------------------
message: 2
date: Tue, 12 May 2009 18:54:52 +0100
from: Clare Holtham <Clare.Holtham@xxxxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
Hi Sean,
All the Western European BPCS users I know, in fact all BPCS users I
know, use 65535 which means 'no translation', probably because the
translation function has never worked properly! Unless there's
new out there....;) And don't forget that the special EBCDICcharacters
on the iSeries have to co-exist with ASCII on the PC Client end.setting of 65535. This doesn't seem like a very good choice to me and
If you've ever tried to get CEA working by fiddling with translation
tables in Turkey or the Czech Republic (where they have extra
diacritics) you wouldn't want to even go there....
cheers,
Clare
McGovern, Sean wrote:
We are planning to install BPCS LX. Infor recommends a QCCSID
one that I would like to change.
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
If we keep the database as the shipped value of CCSID 937, and (try)
value of 937 be a better choice than 65535 ? This would ensure that if
(when) anyone did connect via a 5250 job stream with a host-code page
other than 937, at least the System i platform will attempt to correctly
translate the data. 99% of the users we support are Western European
users, so translation should be handled correctly be the system.
probably explains why you have never come across a BPCS implementation
Sean
------------------------------
message: 3
date: Tue, 12 May 2009 21:19:35 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
Clare,
BPCS recommends that the QCCSID setting is set to 65535, so this
with a different setting. But how many of those BPCS implementations
have had corrupt databases precisely because of the 65535 setting ?
through to the 5250 jobs). This causes issues with 3rd party data mining
Our database is corrupt because of that setting (which is defaulted
tools which leads to development workarounds. The corruption occurs
because users have been connecting through to the BPCS package with a
iSeries Access for Windows host-code page other than the database CCSID
(which is the shipped value 937). Users have been connecting with 285
(UK), 297 (France), 273 (Germany), 280 (Italy) etc.
translation, so the 285, 297, 273, 280 etc hex values get written
As you have stated, 65535 instructs the Series i not to perform any
directly to the 937 database without translation, thus causing
corruption of the variant characters.
translation between the host-code page settings would have occurred
If the QCCSID setting had been the same as the database, i.e. 937,
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.
host-code page that does not belong to the Western European CCSIDs, such
Having QCCSID of 937 does not allow for a user connecting with a
as Turkey or Czech Republic, as translation of the variant characters is
not possible. But this setup is better than having QCCSID of 65535, I
believe.
65535. QCCSID value of 65535 is for backward compatibility for
I don't understand why, at BPCS LX version, Infor still recommend
applications that were written prior to CCSIDs being introduced (pre
V3R1).
of Clare Holtham
Sean
________________________________
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx on behalf
Sent: Tue 12/05/2009 18:54something
To: BPCS ERP System
Subject: Re: [BPCS-L] QCCSID & 65535
Hi Sean,
All the Western European BPCS users I know, in fact all BPCS users I
know, use 65535 which means 'no translation', probably because the
translation function has never worked properly! Unless there's
new out there....;) And don't forget that the special EBCDICcharacters
on the iSeries have to co-exist with ASCII on the PC Client end.setting of 65535. This doesn't seem like a very good choice to me and
If you've ever tried to get CEA working by fiddling with translation
tables in Turkey or the Czech Republic (where they have extra
diacritics) you wouldn't want to even go there....
cheers,
Clare
McGovern, Sean wrote:
We are planning to install BPCS LX. Infor recommends a QCCSID
one that I would like to change.
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
If we keep the database as the shipped value of CCSID 937, and (try)
value of 937 be a better choice than 65535 ? This would ensure that if
(when) anyone did connect via a 5250 job stream with a host-code page
other than 937, at least the System i platform will attempt to correctly
translate the data. 99% of the users we support are Western European
users, so translation should be handled correctly be the system.
--
Sean
This is the 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.
Delivered-To: sean.mcgovern@xxxxxxxxxxxx
------------------------------
message: 4
date: Wed, 13 May 2009 09:48:30 -0400
from: rob@xxxxxxxxx
subject: Re: [BPCS-L] QCCSID & 65535
We're in the states. I changed our system value to 37 quite awhile ago
during the middle of the business day and have never had a reason tois
regret it. Makes downloading data much better than 65535. Yes, 65535
doable but you keep having to turn on switches to "translate 65535data".
We're in the process of upgrading from 405CD to ERPLX 833 and have had
Infor consultants on site to assist us to do so.of
Running 6.1 of i.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
"McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
To:
<bpcs-l@xxxxxxxxxxxx>
Date:
05/12/2009 01:42 PM
Subject:
[BPCS-L] QCCSID & 65535
Sent by:
bpcs-l-bounces+rob=dekko.com@xxxxxxxxxxxx
We are planning to install BPCS LX. Infor recommends a QCCSID setting
65535. This doesn't seem like a very good choice to me and one that Ito
would like to change.
If we keep the database as the shipped value of CCSID 937, and (try)
ensure 5250 job streams use host-code page of 937, wouldn't a QCCSIDvalue
of 937 be a better choice than 65535 ? This would ensure that if(when)
anyone did connect via a 5250 job stream with a host-code page otherthan
937, at least the System i platform will attempt to correctlytranslate
the data. 99% of the users we support are Western European users, so
translation should be handled correctly be the system.
Sean
--
This is the 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.
Delivered-To: rob@xxxxxxxxx
------------------------------
message: 5
date: Wed, 13 May 2009 15:15:30 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
Thanks Rob.
We are currently going through the process of upgrading from V61, V8 &
V82 to ERPLX 833 and upgrading from V5R4 to 6.1 of i. I believe we are
the largest users of BPCS worldwide (7000 BPCS user licenses).
I'd like to get the setting of QCCSID right but don't think the
recommendation from Infor is correct.
I'd welcome further comments on this subject.
Any 'gotchas' with upgrading to ERPLX 833 ? Any new technologies to
learn ?
Cheers,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On
Behalf Of rob@xxxxxxxxx
Sent: 13 May 2009 14:49
To: BPCS ERP System
Subject: Re: [BPCS-L] QCCSID & 65535
We're in the states. I changed our system value to 37 quite awhile ago
during the middle of the business day and have never had a reason to
regret it. Makes downloading data much better than 65535. Yes, 65535
is
doable but you keep having to turn on switches to "translate 65535
data".
We're in the process of upgrading from 405CD to ERPLX 833 and have had
Infor consultants on site to assist us to do so.of
Running 6.1 of i.
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From:
"McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
To:
<bpcs-l@xxxxxxxxxxxx>
Date:
05/12/2009 01:42 PM
Subject:
[BPCS-L] QCCSID & 65535
Sent by:
bpcs-l-bounces+rob=dekko.com@xxxxxxxxxxxx
We are planning to install BPCS LX. Infor recommends a QCCSID setting
to
65535. This doesn't seem like a very good choice to me and one that I
would like to change.
If we keep the database as the shipped value of CCSID 937, and (try)
ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID(when)
value
of 937 be a better choice than 65535 ? This would ensure that if
anyone did connect via a 5250 job stream with a host-code page othertranslate
than
937, at least the System i platform will attempt to correctly
the data. 99% of the users we support are Western European users, soprobably explains why you have never come across a BPCS implementation
translation should be handled correctly be the system.
Sean
--
This is the 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.
Delivered-To: rob@xxxxxxxxx
--
This is the 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.
Delivered-To: sean.mcgovern@xxxxxxxxxxxx
------------------------------
message: 6
date: Wed, 13 May 2009 10:27:25 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
McGovern, Sean wrote:
BPCS recommends that the QCCSID setting is set to 65535, so this
with a different setting. But how many of those BPCS implementations
have had corrupt databases precisely because of the 65535 setting ?
through to the 5250 jobs). This causes issues with 3rd party data mining
Our database is corrupt because of that setting (which is defaulted
tools which leads to development workarounds. The corruption occurs
because users have been connecting through to the BPCS package with a
iSeries Access for Windows host-code page other than the database CCSID
(which is the shipped value 937). Users have been connecting with 285
(UK), 297 (France), 273 (Germany), 280 (Italy) etc.
translation, so the 285, 297, 273, 280 etc hex values get written
As you have stated, 65535 instructs the Series i not to perform any
directly to the 937 database without translation, thus causing
corruption of the variant characters.
translation between the host-code page settings would have occurred
If the QCCSID setting had been the same as the database, i.e. 937,
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.
host-code page that does not belong to the Western European CCSIDs, such
Having QCCSID of 937 does not allow for a user connecting with a
as Turkey or Czech Republic, as translation of the variant characters is
not possible.. But this setup is better than having QCCSID of 65535, I
believe.
65535. QCCSID value of 65535 is for backward compatibility for
I don't understand why, at BPCS LX version, Infor still recommend
applications that were written prior to CCSIDs being introduced (pre
V3R1).
Sorry if this is a duplicate; tried before I subscribed
Not sure what the QCCSID is relevant to in their claim; for
anything really, since that is only the highest level of all
possible sources for CCSID value resolution. What do they say about
setting each user profile to have language specific settings
*including* CCSID? The CCSID of course can be set even for any job.
Are the QLANGID or each user\job LANGID at least being set
correctly, to establish the /job default CCSID/ if the CCSID
resolution down to the job remains 65535?
Perhaps what they really intend, is that some user profile for
the product, according to some work management established for that
user & job(s) must remain CCSID(*HEX). Perhaps they /assume/ that
with QCCSID set to 65535, that means /system profiles/ would be
affected similarly to what I allude for their own profile; e.g. if a
user & job setup requires CCSID(*HEX), but instead of their own
profile, some system profile like QUSER which by default resolves
from QCCSID due to CCSID(*SYSVAL)? Perhaps the true intent of their
recommendation has no bearing whatsoever on what any individual
users can nor should have, in their profiles or jobs.? If so, then
even honoring their recommendation of keeping QCCSID=65535, the
users can still benefit from proper CCSID translations because their
user profiles can be used establish their language specific settings.
Regards, Chuck
------------------------------
--
This is the 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 7, Issue 58
*************************************
_________________________________________________________________
Beyond Hotmail - see what else you can do with Windows Live.
http://clk.atdmt.com/UKM/go/134665375/direct/01/
--
This is the 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.
Delivered-To: sean.mcgovern@xxxxxxxxxxxx
------------------------------
message: 2
date: Thu, 14 May 2009 09:42:51 +0100
from: "McGovern, Sean" <Sean.McGovern@xxxxxxxxxxxx>
subject: Re: [BPCS-L] QCCSID & 65535
Chuck,
Re-reading the Infor documentation, I now see that it is more
complicated at the latest release. Job CCSID is controlled, whereas it
hasn't been at previous releases (so defaulted to QCCSID, which was
recommended to be 65535).
I need to get the product installed and tested !
Cheers,
Sean
-----Original Message-----
From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx] On
Behalf Of CRPence
Sent: 13 May 2009 16:27
To: bpcs-l@xxxxxxxxxxxx
Subject: Re: [BPCS-L] QCCSID & 65535
McGovern, Sean wrote:
BPCS recommends that the QCCSID setting is set to 65535, so thisprobably explains why you have never come across a BPCS implementation
with a different setting. But how many of those BPCS implementations
have had corrupt databases precisely because of the 65535 setting ?
through to the 5250 jobs). This causes issues with 3rd party data mining
Our database is corrupt because of that setting (which is defaulted
tools which leads to development workarounds. The corruption occurs
because users have been connecting through to the BPCS package with a
iSeries Access for Windows host-code page other than the database CCSID
(which is the shipped value 937). Users have been connecting with 285
(UK), 297 (France), 273 (Germany), 280 (Italy) etc.
translation, so the 285, 297, 273, 280 etc hex values get written
As you have stated, 65535 instructs the Series i not to perform any
directly to the 937 database without translation, thus causing
corruption of the variant characters.
translation between the host-code page settings would have occurred
If the QCCSID setting had been the same as the database, i.e. 937,
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.
host-code page that does not belong to the Western European CCSIDs, such
Having QCCSID of 937 does not allow for a user connecting with a
as Turkey or Czech Republic, as translation of the variant characters is
not possible.. But this setup is better than having QCCSID of 65535, I
believe.
65535. QCCSID value of 65535 is for backward compatibility for
I don't understand why, at BPCS LX version, Infor still recommend
applications that were written prior to CCSIDs being introduced (pre
V3R1).
Sorry if this is a duplicate; tried before I subscribed
Not sure what the QCCSID is relevant to in their claim; for
anything really, since that is only the highest level of all
possible sources for CCSID value resolution. What do they say about
setting each user profile to have language specific settings
*including* CCSID? The CCSID of course can be set even for any job.
Are the QLANGID or each user\job LANGID at least being set
correctly, to establish the /job default CCSID/ if the CCSID
resolution down to the job remains 65535?
Perhaps what they really intend, is that some user profile for
the product, according to some work management established for that
user & job(s) must remain CCSID(*HEX). Perhaps they /assume/ that
with QCCSID set to 65535, that means /system profiles/ would be
affected similarly to what I allude for their own profile; e.g. if a
user & job setup requires CCSID(*HEX), but instead of their own
profile, some system profile like QUSER which by default resolves
from QCCSID due to CCSID(*SYSVAL)? Perhaps the true intent of their
recommendation has no bearing whatsoever on what any individual
users can nor should have, in their profiles or jobs.? If so, then
even honoring their recommendation of keeping QCCSID=65535, the
users can still benefit from proper CCSID translations because their
user profiles can be used establish their language specific settings.
Regards, Chuck
--
This is the 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.
Delivered-To: sean.mcgovern@xxxxxxxxxxxx
------------------------------
message: 3
date: Thu, 14 May 2009 09:51:29 -0400
from: Bryce Martin <BMartin@xxxxxxxxxxxx>
subject: [BPCS-L] LX source question.
"Oh I forgot no AS/SET but you have to debug AS/SET code in RPGLE. Have
fun."
In LX is the AS/SET code generated into RPGII like in earlier versions or
did they convert it to ILE source files?
Thanks
Bryce Martin
Programmer/Analyst I
Ext. 4777
--- This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us and destroy this message immediately. ---
------------------------------
--
This is the 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 7, Issue 60
*************************************
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
