Re: fis-gtm

["Bhaskar, K.S" <ks.bhaskar@fisglobal.com>]

Title: Re: fis-gtm

Thorsten --

Thank you for your message and apologies for this delayed reply.  Depending on where I am, I use three different clients to view e-mail one of which does not give me the opportunity to mark e-mails as Unread to be read again later on a friendlier client.  After seeing your message there, I overlooked it later with the volume of e-mail in my Inbox.  Mea culpa.

More comments below - look for [KSB3].

Regards
-- Bhaskar

On 08/02/2011 01:55 PM, Thorsten Alteholz wrote:

Hi Bhaskar,

On Mon, 25 Jul 2011, Bhaskar, K.S wrote:

[KSB3] <...snip...>

>        Even though they are compiled from the same source code, the 32-
> and 64-bit binaries of GT.M are different and packaged & installed
> separately.

Yes, but in case I want to create the 32-bit version on a 64-bit CPU, I need
to call make twice and do a 'setenv OBJECT_MODE 32' in between, right?

[KSB3] That is correct.

> Why do you say that you don't expect anyone to run GT.M on arm?

While working with ARM processors there have been always resource problems
sooner or later. But you are right, I didn't thought about those things
you mentioned. So we need a bootstrap for arm :-).

[KSB3] I agree wholeheartedly!

> [KSB2] Someone installing a new version would choose the latest release.
> But we have users who distribute applications on top of GT.M.  They may
> have a periodic repackage / release cycle, and if they are running
> stably, there is less work for them to do to continue using an existing
> GT.M version until their next cycle.

Ok, but we are talking about the distribution via Debian/Ubuntu or
whatever derivate. So if someone has another application that depends on
one release, then of course due to this dependency this release won't be
deleted. If someone uses Debian as a basis and adds his own stuff before
distributing it, he should either announce this fact and the needed
release won't be deleted. Or he does his own thing and uses "his" release
in any way.
So I don't see any problem that unused releases might be deleted in a new
Debian release. In this case deleting doesn't mean that the packages
disappears. All of the next 23 releases will remain in the archive and can
be used!

[KSB3] OK

> If GT.M is unfriendly to other UTF-8 locales, I definitelyt want to know
> so that we can fix it.  If GT.M requires en_US.utf8 that may be
> unfriendly, and we'll consider what we can do about it.

There are severeal lines like:
  utflocale=`locale -a | grep -i en_us ...`
in configure and later there is a test:
   if [ $utflocale = "" ]; then
or:
   if [ "$found_icu" -ne 0  -a "$utflocale" != "" ] ; then
      doutf8=1
   else
      doutf8=0
   fi
May I say that this is an unfriendly behaviour?

[KSB] We will look into this.  To support UTF-8 mode, GT.M requires a .utf8 locale, any utf8 locale, except on z/OS where it requires en_US.utf8 because of certain platform dependencies.  The configure script is old and this part of it has probably not been looked at for a long time.  Perhaps the Debian package will not even need it.

But, if you look at the (newer) gtmprofile script that a user would source to set up a GT.M environment, notice that it uses the first available utf8 locale.  For example, on my laptop, even though I am in the US:

kbhaskar@bhaskarks:~$ gtm_chset=UTF-8 /usr/lib/fis-gtm/V5.4-002B_x86/gtm

GTM>write $ztrnlnm("LC_CTYPE")
en_AG.utf8
GTM>halt
kbhaskar@bhaskarks:~$

I have to explicitly set en_US.utf8 to get it:

kbhaskar@bhaskarks:~$ LC_CTYPE=en_US.utf8 gtm_chset=UTF-8 /usr/lib/fis-gtm/V5.4-002B_x86/gtm

GTM>write $ztrnlnm("LC_CTYPE")
en_US.utf8
GTM>halt
kbhaskar@bhaskarks:~$

History is what history is - we try to do better today than we did yesterday. and we'll try to do better tomorrow than we do today.

There is another issue. After updating my sid machine it wasn't possible
to build the package from sources. It says something about missing
include file. Other packages replaced the -I- with -iquote which does not
work in your case. After adding the attached patch, everything was fine again.

[KSB3] This was on our list of things to do.  I know that the changes are small, but since GT.M is built from a highly common code base across a wide variety of platforms and released under a variety of licenses, both free / open source (e.g., GT.M for Linux on x86) and proprietary (e.g,. GT.M for proprietary UNIX flavors), would you please make a statement that you make no claim of copyright to the patch?  Thank you very much.

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________