Sean LX multi language support is pretty advanced and good. But that is LX for you. Now you can setup user based language settings and the CCSID is defined at the job level which can be done no issues. But i am sure you will be having loads of interfaces to non ebcdic systems (for example I had a Encryption ssytem on a Unix server sending to our system) and Java calls from RPG to get encryption keys etc. If the system QCSSID is 65535 then these programs create problems . All LX character fields I think having more than 6 characters in length are datatype "O" so they are pretty flexible and the conversion of these character data like Item descriptions etc are done in the programs themselves. I forgot the name of the service programs that does the job in LX. So Infor is right from there perspective to have a QCCSSID of 65535 but you are right in having you speciifc QCCSSID. For western Europe GSK uses the relevant QCCSSID . For france they use 937 .


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@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@xxxxxxxxxxxx
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
unrelated to your reply and change the subject line so it is meaningful.

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
of 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)
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
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



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

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
something
new out there....;) And don't forget that the special EBCDIC
characters
on the iSeries have to co-exist with ASCII on the PC Client end.
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
setting of 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)
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
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




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

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
probably 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 ?

Our database is corrupt because of that setting (which is defaulted
through to the 5250 jobs). This causes issues with 3rd party data mining
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.

As you have stated, 65535 instructs the Series i not to perform any
translation, so the 285, 297, 273, 280 etc hex values get written
directly to the 937 database without translation, thus causing
corruption of the variant characters.

If the QCCSID setting had been the same as the database, i.e. 937,
translation between the host-code page settings would have occurred
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.

Having QCCSID of 937 does not allow for a user connecting with a
host-code page that does not belong to the Western European CCSIDs, such
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.

I don't understand why, at BPCS LX version, Infor still recommend
65535. QCCSID value of 65535 is for backward compatibility for
applications that were written prior to CCSIDs being introduced (pre
V3R1).

Sean


________________________________

From: bpcs-l-bounces+sean.mcgovern=covidien.com@xxxxxxxxxxxx on behalf
of Clare Holtham
Sent: Tue 12/05/2009 18:54
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
something
new out there....;) And don't forget that the special EBCDIC
characters
on the iSeries have to co-exist with ASCII on the PC Client end.
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
setting of 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)
to ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
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 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.

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
of
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)
to
ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
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: 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.

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
of

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)
to
ensure 5250 job streams use host-code page of 937, wouldn't a QCCSID
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: 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
probably 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 ?

Our database is corrupt because of that setting (which is defaulted
through to the 5250 jobs). This causes issues with 3rd party data mining
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.

As you have stated, 65535 instructs the Series i not to perform any
translation, so the 285, 297, 273, 280 etc hex values get written
directly to the 937 database without translation, thus causing
corruption of the variant characters.

If the QCCSID setting had been the same as the database, i.e. 937,
translation between the host-code page settings would have occurred
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.

Having QCCSID of 937 does not allow for a user connecting with a
host-code page that does not belong to the Western European CCSIDs, such
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.

I don't understand why, at BPCS LX version, Infor still recommend
65535. QCCSID value of 65535 is for backward compatibility for
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 this
probably 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 ?

Our database is corrupt because of that setting (which is defaulted
through to the 5250 jobs). This causes issues with 3rd party data mining
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.

As you have stated, 65535 instructs the Series i not to perform any
translation, so the 285, 297, 273, 280 etc hex values get written
directly to the 937 database without translation, thus causing
corruption of the variant characters.

If the QCCSID setting had been the same as the database, i.e. 937,
translation between the host-code page settings would have occurred
automatically (and correctly) by the platform to the database CCSID of
937 and the database would not be corrupted.

Having QCCSID of 937 does not allow for a user connecting with a
host-code page that does not belong to the Western European CCSIDs, such
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.

I don't understand why, at BPCS LX version, Infor still recommend
65535. QCCSID value of 65535 is for backward compatibility for
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
*************************************

_________________________________________________________________
View your Twitter and Flickr updates from one place – Learn more!
http://clk.atdmt.com/UKM/go/137984870/direct/01/

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.