GT.M V5.3-002 available

GT.M V5.3-002 is a major new release that completes the planned
support for 64-bit architectures by adding Sun SPARC Solaris to the
set of 64-bit platforms. It also adds support for the Mapped Memory
database access method and includes functional & performance
enhancements (especially on platforms running GNU/Linux), as well as
bug fixes. Details follow.

Effective V5.3-002:

* GT.M on the following computing platforms runs as 64-bit
processes: Solaris on SPARC; GNU/Linux on x86_64 and Itanium; AIX on
pSeries; HP-UX on Itanium. With this and future releases, there are
no 32-bit GT.M processes on these platforms.
* GT.M on the following computing platforms continues to run as 32-
bit processes: x86 GNU/Linux; HP-UX on PA-RISC; Tru64 UNIX and OpenVMS
on Alpha/AXP. There are no plans to move to a 64-bit architecture on
these platforms.

Note that 32- and 64-bits refers to the GT.M processes. 64-bit
operating system kernels run 32-bit processes (e.g., 32-bit GT.M for
x86 GNU/Linux runs very well on x86_64 GNU/Linux) and in some cases 32-
bit OS kernels run 64-bit processes as long as the underlying hardware
supports it (e.g, a 32-bit IBM pSeries AIX kernel on 64-bit CPUs can
run the 64-bit GT.M for that platform).

V5.3-002 also adds:

* On Sun SPARC Solaris, the ability to place object modules
generated by the compiler into shared libraries with the standard
system utility ld.
* A field test grade implementation of the MM (Mapped Memory)
database access method for UNIX/Linux. (The field test designation
refers only to the new MM access method for UNIX/Linux. V5.3-002 is a
fully tested and qualified, production grade GT.M release that is at
least as robust as, if not more robust than, any previous GT.M
release.)
* Improved journaling capabilities.
* Source code lines up to 8192 bytes in length.
* Enhanced support for Unicode.
* Improvements to the MUPIP, LKE, and DSE utility programs.
* More compact generated object code code for GNU/Linux on x86_64.
* Formal support for Ubuntu Linux on the x86_64 platform.

Further details are in the release notes (http://
http://www.fidelityinfoservices.com/...ase_Notes.html).

Software released under the Affero GNU General Public License v3
(http://www.gnu.org/licenses/agpl-3.0.txt) is available at Source
Forge. Please note that the license used has changed. Also the name
of the GT.M project on Source Forge (http://sourceforge.net/projects/
fis-gtm) changed previously.

Please download using binary file transfer, and verify the checksum of
the software using cksum after downloading:

285358813 321167 dbcertify_V53002_linux_i686_pro.tar.gz
3627871073 5002560 gtm_V53002_linux_i686_pro.tar.gz
633865243 2957688 gtm_V53002_linux_i686_src.tar.gz

3734894127 473988 dbcertify_V53002_osf1_alpha_pro.tar.gz
3639410470 6979967 gtm_V53002_osf1_alpha_pro.tar.gz
1206328028 2936825 gtm_V53002_osf1_alpha_src.tar.gz

3414718918 5854349 gtm_V53002_openvms_alpha_pro.zip
1148143872 4194045 gtm_V53002_openvms_alpha_src.zip

Thank you very much for your continued use and support of GT.M.

Regards
-- Bhaskar

P.S. This is a heads up that we are thinking of having a PIP/GT.M
user group meeting in Malvern Thursday/Friday, October 16/17. While I
am not looking for a commitment, would you be able to indicate,
please, whether you would attend? Thank you very much.

K.S. Bhaskar
Senior Vice President
Fidelity National Information Services, Inc.
2 West Liberty Boulevard, Suite 300
Malvern, PA 19355, USA
+1 (610) 578-4265 office
+1 (610) 620-3355 mobile
ks.bhaskar@fnis.com <-- Please note e-mail domain
http://www.fis-gtm.com
http://www.fis-pip.com

Bhaskar

The Mapped Memory database access method sounds interesting. Could
you give some more info on what it's all about?

Rob

On Tue, 19 Aug 2008 09:07:10 -0700 (PDT), "K.S. Bhaskar"
<ksbhaskar@gmail.com> wrote:

>GT.M V5.3-002 is a major new release that completes the planned
>support for 64-bit architectures by adding Sun SPARC Solaris to the
>set of 64-bit platforms. It also adds support for the Mapped Memory
>database access method and includes functional & performance
>enhancements (especially on platforms running GNU/Linux), as well as
>bug fixes. Details follow.
>
>Effective V5.3-002:
>
> * GT.M on the following computing platforms runs as 64-bit
>processes: Solaris on SPARC; GNU/Linux on x86_64 and Itanium; AIX on
>pSeries; HP-UX on Itanium. With this and future releases, there are
>no 32-bit GT.M processes on these platforms.
> * GT.M on the following computing platforms continues to run as 32-
>bit processes: x86 GNU/Linux; HP-UX on PA-RISC; Tru64 UNIX and OpenVMS
>on Alpha/AXP. There are no plans to move to a 64-bit architecture on
>these platforms.
>
>Note that 32- and 64-bits refers to the GT.M processes. 64-bit
>operating system kernels run 32-bit processes (e.g., 32-bit GT.M for
>x86 GNU/Linux runs very well on x86_64 GNU/Linux) and in some cases 32-
>bit OS kernels run 64-bit processes as long as the underlying hardware
>supports it (e.g, a 32-bit IBM pSeries AIX kernel on 64-bit CPUs can
>run the 64-bit GT.M for that platform).
>
>V5.3-002 also adds:
>
> * On Sun SPARC Solaris, the ability to place object modules
>generated by the compiler into shared libraries with the standard
>system utility ld.
> * A field test grade implementation of the MM (Mapped Memory)
>database access method for UNIX/Linux. (The field test designation
>refers only to the new MM access method for UNIX/Linux. V5.3-002 is a
>fully tested and qualified, production grade GT.M release that is at
>least as robust as, if not more robust than, any previous GT.M
>release.)
> * Improved journaling capabilities.
> * Source code lines up to 8192 bytes in length.
> * Enhanced support for Unicode.
> * Improvements to the MUPIP, LKE, and DSE utility programs.
> * More compact generated object code code for GNU/Linux on x86_64.
> * Formal support for Ubuntu Linux on the x86_64 platform.
>
>Further details are in the release notes (http://
>http://www.fidelityinfoservices.com/...ase_Notes.html).
>
>Software released under the Affero GNU General Public License v3
>(http://www.gnu.org/licenses/agpl-3.0.txt) is available at Source
>Forge. Please note that the license used has changed. Also the name
>of the GT.M project on Source Forge (http://sourceforge.net/projects/
>fis-gtm) changed previously.
>
>Please download using binary file transfer, and verify the checksum of
>the software using cksum after downloading:
>
>285358813 321167 dbcertify_V53002_linux_i686_pro.tar.gz
>3627871073 5002560 gtm_V53002_linux_i686_pro.tar.gz
>633865243 2957688 gtm_V53002_linux_i686_src.tar.gz
>
>3734894127 473988 dbcertify_V53002_osf1_alpha_pro.tar.gz
>3639410470 6979967 gtm_V53002_osf1_alpha_pro.tar.gz
>1206328028 2936825 gtm_V53002_osf1_alpha_src.tar.gz
>
>3414718918 5854349 gtm_V53002_openvms_alpha_pro.zip
>1148143872 4194045 gtm_V53002_openvms_alpha_src.zip
>
>Thank you very much for your continued use and support of GT.M.
>
>Regards
>-- Bhaskar
>
>P.S. This is a heads up that we are thinking of having a PIP/GT.M
>user group meeting in Malvern Thursday/Friday, October 16/17. While I
>am not looking for a commitment, would you be able to indicate,
>please, whether you would attend? Thank you very much.
>
>K.S. Bhaskar
>Senior Vice President
>Fidelity National Information Services, Inc.
>2 West Liberty Boulevard, Suite 300
>Malvern, PA 19355, USA
>+1 (610) 578-4265 office
>+1 (610) 620-3355 mobile
>ks.bhaskar@fnis.com <-- Please note e-mail domain
>http://www.fis-gtm.com
>http://www.fis-pip.com

---

Rob Tweed
Company: M/Gateway Developments Ltd
Registered in England: No 3220901
Registered Office: 58 Francis Road,Ashford, Kent TN23 7UR

Web-site: http://www.mgateway.com

Database files consist of a file header and blocks. With the
traditional BG (Buffered Global) access method, GT.M has a pool of
global buffers. When a process needs to read a block, it first looks
in the global buffers. If it is not there, the process reads the
block from disk into the global buffers where it is available for
other processes. With the new MM (Mapped Memory) access method, a
GT.M process simply maps the file into the process address space with
an mmap() system call. Now, the OS virtual memory manager is
responsible for bringing disk blocks into memory, and in theory this
should run faster because it eliminates an entire layer of heavily
used code in GT.M.

But there is no such thing as a free lunch. With BG, GT.M is able to
control when database blocks get written to disk, and can support
before image journaling with (faster) backward recovery after a system
crash. With MM, GT.M has not control of when database blocks get
written to disk, and therefore can only support M level journaling,
with (slower) forward recovery after a system crash. So MM represents
a trade that gives better throughput at the cost of a higher time to
recover after a crash. Either technique gives full recoverability and
can be automated by scripting - it's a matter of how it's done and how
long it takes.

Of course, with GT.M's ability to set up logical multi-site
configurations, you can set up as many as 16 secondary instances to
which the primary instance streams updates as they happen. So, in the
event the primary crashes, you can immediately switch an available
secondary to become the new primary, and live with a longer time to
recover the machine that crashed.

Regards
-- Bhaskar
ks dot bhaskar at fnis dot com <-- send e-mail here

On Aug 19, 1:14*pm, Rob Tweed <rtw...@mgateway.com> wrote:
> Bhaskar
>
> The Mapped Memory database access method sounds interesting. *Could
> you give some more info on what it's all about?
>
> Rob