GT.M V6.2-001 available

[Bhaskar, K.S]

First, let me take this opportunity to wish you all the best for the holiday season, and a Very Happy New Year in 2015.

V6.2-001 brings important enhancements to GT.M: a production grade implementation of auto-relink, triggers for global variables that span regions, SOCKET devices that support Transport Layer Security (TLS), and several other enhancements and fixes.

• Introduced as field-test grade functionality in V6.2-000, auto-relink is production grade in V6.2-001. While the API for programs that use auto-relink is upward compatible, the underlying implementation is more robust & scalable. Whereas in V6.2-000, processes mapped object files directly, in V6.2-001 GT.M dynamically loads object code into shared memory for execution. Instead of each process mapping each object file - potentially hundreds to thousands of object files by each of hundreds to thousands of processes - processes only need to map shared memory segments (as they do for database files) within which the GT.M run-time system dynamically manages object code. As Linux on x86 permits shared memory segments to be mapped using hugepages, V6.2-001 provides the opportunity for further scalability enhancements resulting from smaller page tables, and a greater probability of successful memory accesses directly from on-chip translation lookaside buffers.

• GT.M supports triggers independent of global directory and for global variables that span multiple regions. Previously trigger maintenance required careful choice of a default region and GT.M only supported global variables whose span was limited to a single region. In addition trigger maintenance is more more robust and user-friendly.

• SOCKET devices support encrypted communication using TLS (formerly known as SSL). Because this functionality has a wide variety of user stories (use cases) and has substantial complexity, although the code appears robust, we are not confident that we have exercised a sufficient breadth of use cases in testing. Also we may make changes in future releases that are not entirely backwards compatible. We encourage you to use with this facility in development and testing, and to provide us with feedback. If you are an FIS customer and wish to use this in production, please contact us beforehand to discuss your use case(s). As with all cryptographic functionality, GT.M includes no code that performs cryptographic calculations, uses a plugin architecture, and ships with a reference implementation of a plugin that FIS tests against selected, widely used, cryptographic libraries.

V6.2-001 also has numerous smaller enhancements and fixes.

The online help facilities provided through the ZHELP command in GT.M, and the HELP commands in the utilities, provide current, hierarchically organized information current. These, as well as robustness improvements, fixes to issues, and performance enhancements, are described in the Release Notes.

Please do include an upgrade to V6.2-001 in your plans, and send any feedback our way.  Thank you for using GT.M.  We look forward to continuing to serve you in 2015.

Regards
-- Bhaskar

-- 
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.

[Nancy Anthracite]

Agreed. I am acutely aware of the frequent changes because I have to keep
updating installation scripts. Time to rewrite them and put in a GT.M version
variable so I will have less work to do! :-)

--
Nancy Anthracite

On Saturday, December 27, 2014 08:17:52 AM Kevin Toppenberg wrote:
> Rock solid, lightning fast -- AND always improving. :-)
>
> Happy New Year to the GT.M team, and thanks for the hard work.
>
> Kevin

>
> On Saturday, December 27, 2014 10:12:54 AM UTC-5, K.S. Bhaskar wrote:
> > First, let me take this opportunity to wish you all the best for the
> > holiday season, and a Very Happy New Year in 2015.
> >
> > V6.2-001 brings important enhancements to GT.M: a production grade
> > implementation of auto-relink, triggers for global variables that span
> > regions, SOCKET devices that support Transport Layer Security (TLS), and
> > several other enhancements and fixes.
> >

> > -

> >
> > Introduced as field-test grade functionality in V6.2-000, auto-relink
> > is production grade in V6.2-001. While the API for programs that use
> > auto-relink is upward compatible, the underlying implementation is more
> > robust & scalable. Whereas in V6.2-000, processes mapped object files
> > directly, in V6.2-001 GT.M dynamically loads object code into shared
> > memory
> > for execution. Instead of each process mapping each object file -
> > potentially hundreds to thousands of object files by each of hundreds
> > to
> > thousands of processes - processes only need to map shared memory
> > segments
> > (as they do for database files) within which the GT.M run-time system
> > dynamically manages object code. As Linux on x86 permits shared memory
> > segments to be mapped using hugepages, V6.2-001 provides the
> > opportunity
> > for further scalability enhancements resulting from smaller page
> > tables,
> > and a greater probability of successful memory accesses directly from
> > on-chip translation lookaside buffers.
> >

> > -

> >
> > GT.M supports triggers independent of global directory and for global
> > variables that span multiple regions. Previously trigger maintenance
> > required careful choice of a default region and GT.M only supported
> > global
> > variables whose span was limited to a single region. In addition
> > trigger
> > maintenance is more more robust and user-friendly.
> >

> > -

> > <http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.2-001_Release_Notes
> > .html> .

> >
> > Please do include an upgrade to V6.2-001 in your plans, and send any
> > feedback our way. Thank you for using GT.M. We look forward to
> > continuing
> > to serve you in 2015.
> >
> > Regards
> > -- Bhaskar
> >

[K.S. Bhaskar]

Since one of our unwritten goals with GT.M is no surprises, we are fastidious and go the extra mile to ensure that you almost never have to update your application code or scripting to run on new releases of GT.M.  Owing to the nature and extent of automated regression testing in our development process, it is rare for a GT.M release to have an inadvertent regression.  On those very rare occasions when we must deliberately introduce a regression (for example, a required extra flag in a command line), the release notes explicitly call attention to this.  In the release notes, we use an icon consisting of a check mark in a red circle to flag changes that in our judgement warrant a review for upward compatibility.  The descriptions of items also follow a standard template of describing the new behavior followed by the previous behavior so that you do not have to read the entire item to decide whether it applies to you.

There are two exceptions to this: bug fixes and new features.  If you have application code or scripting that relies on a bug in an existing release, then a new release will be behave differently.  If a new release has a new feature and existing application code relies on the absence of the feature in the old release, then the new release will behave differently (for example, some users were bitten by assumptions in their code about identifier length when we increased this from 8 to 31 characters some years ago).

To the best of my knowledge, the new GT.M release should just drop into all common VistA implementations.  That said, you should always test before deploying anything in production.

Of course taking advantage of new functionality requires changes.  VistA implementations may find the following combination of features in recent GT.M releases to be of interest: relink recursive; the -embed_source flag of the mumps command (and the $ZCOMPILE ISV) when compiling routines; and auto-relink.

Regards
-- Bhaskar

[Bhaskar, K.S]

I would like to add that if the deployment of does not include putting object code in shared libraries, then your largest sites may benefit from functionality in 2014 GT.M releases.  Replacing object files linked in process-private memory with the combination of relink recursive + the -embed_source compilation flag + auto-relink should reduce overall memory usage, and if you also use hugepages to map shared memory, that should reduce the memory usage by page tables.  Linux will use the memory freed up for its file buffer cache, which should improve performance (with the actual improvement of course dependent on the specific situation at each site).

As always, please test before deploying in production.

Regards
-- Bhaskar