Mixing Latin-1 and Latin-2 Languages

[caseywhite]

I am trying to support the Polish language in a mixed web event and WAM application. One of the issues I have noticed is that if the character is part of latin-2 it is not working even in WAMs where the character set is UTF-8.

My question is whether anyone has run LANSA under any of the Latin-2 languages like Polish, Slovakian, etc and if so what approach was used so that web event, WAMs worked correctly.

I see the database files are all created with CCSID 37 which from what I read doesn't support Latin-2.

Does this mean I need to convert all database files from CCSID 37 to something else? Could I just create a different data library for the Polish language and create the files with a different CCSID in that library and still use the same OAMs that work over the CCSID 37 files.

Any thoughts are much appreciated.

[René Houba]

Hi Casey,

We have a LANSA partner in Czech Republic, I will ask them

Kind regards,
René

[caseywhite]

Thanks René. Much appreciated.

[René Houba]

Hi Casey,

Our partner for this is on holiday this week and will return next week, so we can get more details next week, but I already received this from him:

*************************************************************************
We had all original LANSA for the Web, as well as WAM, as well as VL-web, as well as aXes and RAMP working with correct Czech (LATIN2 – Windows 1250 codepage) working.

We are using page 870 on IBMi and windows-1250 on PC (or 1208 unicode for some technologies).

For some usage (like L4W HTML editor, based on LANSA/Server and Superserver for codepage conversion, we had to prepare some translation objects (many years ago:
- Translation pages Q870to1250 and Q1250to870 on IBM I, which are used by Superserver RDML Client/server connection
- PC file LCOECHAR.DAT for Server based tools.

The AS/400 tables already has LANSA (I sent them a many years ago)

Having own database files in 37 is not a good idea, better is to use original Polish codepage (do not know what, but probably similar to out 870), as well as CCSID.

But we managed correct code translation also in UNIQA, which is using different CP (037 or 283 (Germany), but it is more complicated.
Using native CP for appliaction files is better and more simple to manage the codepage translations to get working.

So, you can answer them and note us - , yes, we managed almost all the problems.
*************************************************************************

Kind regards,
René

[caseywhite]

Thanks René. That is helpful. I was able to get a little further if I created a LANSA system that runs in code page 870 with a file that has code page 870. There are still some other issues I am sorting through but based on his comments it sounds like I am going down the right patch.

My biggest hurdle is going to be running both code page 37 and 870 in the same LANSA system. I am going to try and create a second web user with cod page 870 so that I can have an XXXPGMLIB and YYYPGMLIB users running both HTTP jobs and LWEB_JOBS that are different code pages. I think I might be able to accomplish this by making a copy of DC@W12 to a library that only YYYPGMLIB user has access to. It would sit higher in the library list than the library XXXPGMLIB.

Since we already use virtual hosts in our web server I am going to try to create a separate domain like polish.myapp.com which would start jobs under user YYYPGMLIB which would be code page 870.

I will report back once I get further along.

[caseywhite]

I have hit the following issue. Hoping someone might have an idea which file or data area I am not copying in order to solve the error.

I am getting my LWEB_JOBs to start up in my new subsystem XXXPGM870 which is the subsystem that will be used to run the LWEB_JOBS under CCSID 870 associated with my XXXPGMLIB system. I can't get a page to serve but I suspect it is due to this error in the LWEB_JOB. It doesn't cause it to fail but since it isn't initializing correctly I suspect that is why I can't get a page to serve.

Here is the error.
Message . . . . : PASE for i program not found or in use. Path name is
/QOpenSys/-lansa-root-unknown-/x_lansa/bin/uxstart32.

Any ideas on why there is the -lansa-root-unknown? I have the following objects copied to my 870 CCSID specific COM, DTA and PGM libraries but maybe there is another one that is needed. Any ideas/guesses?

Data Areas
DC@A01
DC@LWEB
LCOA01
W3@P2000

Files:
DC@W08

[René Houba]

Hi Casey,

This was not setup by a normal LANSA install?

Every LANSA install has some related programs in QOpenSys on the IFS:

QOpenSys 1.PNG (8.5 KiB) Viewed 18547 times

QOpenSys 2.PNG (13.46 KiB) Viewed 18547 times

Kind regards,
René

[caseywhite]

Hi René, the install was a normal LANSA install. If I try to run the entire install under CCSID 870 then things work fine. What this potentially means is that I need to install a completely separate LANSA install to handle CCSID 870. I would have one LANSA install for CCSID 37 and another one for CCSID 870.

I want to avoid this if a I can and see if I can create the second install directories of only XXXCOMLIB and XXXPGMLIB by manually copying the objects with the assumption that I don't want to have a duplicate set of IFS directories and partition program libraries etc. I was then going to set up DC@W08 (the DFTUSR) record to using the user profile that is set up for CCSID 870 and has a slightly different library list. Looks like I can't get this to work though because which LANSA creates the DC@W05 session record in my CCSID 870 COMLIB it still uses the DC@W08 user definition from the CCSID 37 DTALIB. Even if I copy the DC@W08 records to the CCSID 870 COM or PGM lib which are the libraries in the library list something must fail because it won't switch the job to the user at all.

I know what I am trying to do is non standard but still trying to get it to work because I really don't have to have to do a full LANSA install every time I need to set up a language that is a different CCSID. Greek will eventually get set up so I really want to try to work out a solution that is simple to manage.

[Theo de Bruin]

How about using CCSID 65535 ( i.e. no translation) fro LANSA , databtase tables etc , and only covert to the client ?

[caseywhite]

Hi Theo. I think I tried something like that but it didn't work. I think I have what I need which is run the second character set (Latin 2 in this case) in a second partition. Then I need to set up a separate web virtual host and make other web admin config changes. I am working on testing what I think will work to see what remaining gaps I have. Once I have it all sorted I will post my findings back here.

[Dino]

Hi Casey
wondering if you found where that value -lansa-root-unknown- was stored?
/QOpenSys/-lansa-root-unknown-/x_lansa/bin/uxstart32
kind regards,

[caseywhite]

Hi Dino,

I never did figure that out. We ended up going with 2 different partitions which is much easier than the approach I was trying to use.