RE: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
Sun and IBM haven't been playing well together. I believe IBM is currently working on an open-source version of the Java Runtime. The problem is - the Java spec itself runs thru the Java Committee and that Committee is mostly chaired by Sun. So... it'll be hard to be purely open but at least there are non-Sun VM options. /David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Schlehuber Sent: Saturday, December 04, 2004 10:03 PM To: [EMAIL PROTECTED] Subject: RE: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M) The emphasis in the VA is on POJO's Plain Old Java Objects. It looks like Hibernate will be used for SQL access. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy E. Anthracite Sent: Saturday, December 04, 2004 4:14 PM To: [EMAIL PROTECTED] Subject: Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M) I just got off the phone with my son who informed me that Sun's Java has a restricted license - look but don't touch - but there are truly open source versions of Java. So is the VA making any distinction in what they are using? Does it matter to us if we start writing GUI plugins for Pedi that are written in Java in hopes they will eventually be integrated with what the VA is working on? Anybody know anything about Java Script licensing? Does it matter? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
open source Java Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
Brasil is heavily into Java and are at the core of an effort to create an open source Java I'm not exactly sure what that entails but for any that are interested I can connect you offline to one of key participants in that initiative... Joseph David Sommers wrote: Sun and IBM haven't been playing well together. I believe IBM is currently working on an open-source version of the Java Runtime. The problem is - the Java spec itself runs thru the Java Committee and that Committee is mostly chaired by Sun. So... it'll be hard to be purely open but at least there are non-Sun VM options. /David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cameron Schlehuber Sent: Saturday, December 04, 2004 10:03 PM To: [EMAIL PROTECTED] Subject: RE: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M) The emphasis in the VA is on POJO's Plain Old Java Objects. It looks like Hibernate will be used for SQL access. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy E. Anthracite Sent: Saturday, December 04, 2004 4:14 PM To: [EMAIL PROTECTED] Subject: Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M) I just got off the phone with my son who informed me that Sun's Java has a restricted license - look but don't touch - but there are truly open source versions of Java. So is the VA making any distinction in what they are using? Does it matter to us if we start writing GUI plugins for Pedi that are written in Java in hopes they will eventually be integrated with what the VA is working on? Anybody know anything about Java Script licensing? Does it matter? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members . --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
Maury -- There are several cases of linking to consider with GT.M for x86 GNU/Linux. The most common is the default, when a process executes a Do ^XYZ or a ZLINK XYZ. This is dynamically linked. With GT.M the top level of a process does not have to be M code, but can be in C (or another language). Any calls from C to M are dynamically linked, as are calls from M to C. C to C calls can be dynamically linked, or if two C modules are in the a shared library, they are statically linked to each other. Two C modules in different shared libraries are dynamically linked. Thus, for GT.M for x86 GNU/Linux, any code in M is always dynamically linked, and code in C is dynamically linked with code in M, and for two modules in C, it depends on how they are packaged. With GT.M on AIX, HP-UX and Tru64 UNIX, where code in M can be put into shared libraries, the same rule applies to M modules as to C modules on x86 GNU/Linux, namely that two M modules in the same shared library are considered statically linked to each other, and dynamically linked to anything not in that shared library. So, bottom line is that at least as far as GT.M is concerned, linking is always dynamic unless someone explicitly chooses to make it static. This means that if someone makes an add on to VistA under the GPL, and someone else makes another add on to VistA that is under a license incompatible with the GPL, the fact that linking is dynamic means that the GPL license of one module does not affect the GPL-incompatible license of another module. Your question was very incisive, and I guess the answer means that much of our licensing discussion was unnecessary! I am copying the vista-open-source at yahoogroups.com, since much of the licensing discussion happened over there. Hope this explains things satisfactorily. If not, please ask. -- Bhaskar On Fri, 2004-12-03 at 21:42, Maury Pepper wrote: Bhaskar, As long as you have the hood up, I'd like to ask about GT.M with respect to linking. As you know, the recent conversations about open source licensing touched on the issue of static versus dynamic linking. This seems to be the line that separates contaminated from uncontaminated code. (Excuse the euphemisms.) So, what I would like is your explanation of the linking that exists between routines from two different packages running in a single user's job space. For example, if you are running FOIA VistA and an add-on accounting package together, how might they be linked? If there are multiple answers, that's OK. I think this is relevant -- because, based on my understanding of what is going on, I think we may need to redefine certain terms in an M context because I'm not sure that the industry standard terms apply. -maury- - Original Message - From: K.S. Bhaskar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 03, 2004 8:12 PM Subject: RE: [Hardhats-members] Krung Thai Bank goes live on GT.M Steve -- There are some differences down in the detail level, mostly as a result of differences between hardware architectures, operating systems, as well as what development found funding and what did not. There are differences between GT.M on Alpha/VMS and GT.M on UNIX/Linux: the underlying OS platforms are different enough that we have different manuals for them - although the manuals are generated from a common source with conditional text. The UNIX implementations support identical implementations of the M language, but here are some examples of the differences: * Some platforms support a Direct IO flag which turns on the O_DIRECT setting for journal IO, which can either speed things up or slow things down depending on the IO subsystem. * GT.M on Sun SPARC Solaris supports Sun RPC call-ins. The others don't. * The GT.M compiler on AIX, HP-UX and Tru64 UNIX creates object files in a format that can be incorporated into .so shared libraries. The GT.M compiler on Linux and Solaris does not. * There may be differences in the ability to pass parameters in registers when calling between M and C on the different platforms, but I can't remember right now. * A GT.M process on AIX can have fewer database files open at one time than on other platforms (the limit is something like 9 caused by fact that each shared memory segment uses a segment register). -- Bhaskar On Fri, 2004-12-03 at 18:44, Tomlinson, ,Steven B wrote: Aloha Bhaskar, Thanks for the clarification, I have been wondering what (if any) differences there were between the GT.M distributions. Steven B. Tomlinson [EMAIL PROTECTED] Pacific Telehealth and Technology Hui www.PacificHui.org *** This electronic mail transmission contains confidential and/or privileged
Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
I just got off the phone with my son who informed me that Sun's Java has a restricted license - look but don't touch - but there are truly open source versions of Java. So is the VA making any distinction in what they are using? Does it matter to us if we start writing GUI plugins for Pedi that are written in Java in hopes they will eventually be integrated with what the VA is working on? Anybody know anything about Java Script licensing? Does it matter? On Saturday 04 December 2004 01:48 pm, K.S. Bhaskar wrote: Maury -- There are several cases of linking to consider with GT.M for x86 GNU/Linux. The most common is the default, when a process executes a Do ^XYZ or a ZLINK XYZ. This is dynamically linked. With GT.M the top level of a process does not have to be M code, but can be in C (or another language). Any calls from C to M are dynamically linked, as are calls from M to C. C to C calls can be dynamically linked, or if two C modules are in the a shared library, they are statically linked to each other. Two C modules in different shared libraries are dynamically linked. Thus, for GT.M for x86 GNU/Linux, any code in M is always dynamically linked, and code in C is dynamically linked with code in M, and for two modules in C, it depends on how they are packaged. With GT.M on AIX, HP-UX and Tru64 UNIX, where code in M can be put into shared libraries, the same rule applies to M modules as to C modules on x86 GNU/Linux, namely that two M modules in the same shared library are considered statically linked to each other, and dynamically linked to anything not in that shared library. So, bottom line is that at least as far as GT.M is concerned, linking is always dynamic unless someone explicitly chooses to make it static. This means that if someone makes an add on to VistA under the GPL, and someone else makes another add on to VistA that is under a license incompatible with the GPL, the fact that linking is dynamic means that the GPL license of one module does not affect the GPL-incompatible license of another module. Your question was very incisive, and I guess the answer means that much of our licensing discussion was unnecessary! I am copying the vista-open-source at yahoogroups.com, since much of the licensing discussion happened over there. Hope this explains things satisfactorily. If not, please ask. -- Bhaskar On Fri, 2004-12-03 at 21:42, Maury Pepper wrote: Bhaskar, As long as you have the hood up, I'd like to ask about GT.M with respect to linking. As you know, the recent conversations about open source licensing touched on the issue of static versus dynamic linking. This seems to be the line that separates contaminated from uncontaminated code. (Excuse the euphemisms.) So, what I would like is your explanation of the linking that exists between routines from two different packages running in a single user's job space. For example, if you are running FOIA VistA and an add-on accounting package together, how might they be linked? If there are multiple answers, that's OK. I think this is relevant -- because, based on my understanding of what is going on, I think we may need to redefine certain terms in an M context because I'm not sure that the industry standard terms apply. -maury- - Original Message - From: K.S. Bhaskar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 03, 2004 8:12 PM Subject: RE: [Hardhats-members] Krung Thai Bank goes live on GT.M Steve -- There are some differences down in the detail level, mostly as a result of differences between hardware architectures, operating systems, as well as what development found funding and what did not. There are differences between GT.M on Alpha/VMS and GT.M on UNIX/Linux: the underlying OS platforms are different enough that we have different manuals for them - although the manuals are generated from a common source with conditional text. The UNIX implementations support identical implementations of the M language, but here are some examples of the differences: * Some platforms support a Direct IO flag which turns on the O_DIRECT setting for journal IO, which can either speed things up or slow things down depending on the IO subsystem. * GT.M on Sun SPARC Solaris supports Sun RPC call-ins. The others don't. * The GT.M compiler on AIX, HP-UX and Tru64 UNIX creates object files in a format that can be incorporated into .so shared libraries. The GT.M compiler on Linux and Solaris does not. * There may be differences in the ability to pass parameters in registers when calling between M and C on the different platforms, but I can't remember right now. * A GT.M process on AIX can have fewer database files open at one time than on other platforms (the limit
Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
Bhaskar, This may be a bit off topic (re licensing), but it does relate to the linking. I recently divided my program up into modules, with a bunch of debug code all grouped into one TMGDEBUG.m file. When I did this, I noticed that my execution speed went way down. It seemed that the module is being loaded and dumped with every call. Is this true? Kevin --- K.S. Bhaskar [EMAIL PROTECTED] wrote: Maury -- There are several cases of linking to consider with GT.M for x86 GNU/Linux. The most common is the default, when a process executes a Do ^XYZ or a ZLINK XYZ. This is dynamically linked. With GT.M the top level of a process does not have to be M code, but can be in C (or another language). Any calls from C to M are dynamically linked, as are calls from M to C. C to C calls can be dynamically linked, or if two C modules are in the a shared library, they are statically linked to each other. Two C modules in different shared libraries are dynamically linked. Thus, for GT.M for x86 GNU/Linux, any code in M is always dynamically linked, and code in C is dynamically linked with code in M, and for two modules in C, it depends on how they are packaged. With GT.M on AIX, HP-UX and Tru64 UNIX, where code in M can be put into shared libraries, the same rule applies to M modules as to C modules on x86 GNU/Linux, namely that two M modules in the same shared library are considered statically linked to each other, and dynamically linked to anything not in that shared library. So, bottom line is that at least as far as GT.M is concerned, linking is always dynamic unless someone explicitly chooses to make it static. This means that if someone makes an add on to VistA under the GPL, and someone else makes another add on to VistA that is under a license incompatible with the GPL, the fact that linking is dynamic means that the GPL license of one module does not affect the GPL-incompatible license of another module. Your question was very incisive, and I guess the answer means that much of our licensing discussion was unnecessary! I am copying the vista-open-source at yahoogroups.com, since much of the licensing discussion happened over there. Hope this explains things satisfactorily. If not, please ask. -- Bhaskar On Fri, 2004-12-03 at 21:42, Maury Pepper wrote: Bhaskar, As long as you have the hood up, I'd like to ask about GT.M with respect to linking. As you know, the recent conversations about open source licensing touched on the issue of static versus dynamic linking. This seems to be the line that separates contaminated from uncontaminated code. (Excuse the euphemisms.) So, what I would like is your explanation of the linking that exists between routines from two different packages running in a single user's job space. For example, if you are running FOIA VistA and an add-on accounting package together, how might they be linked? If there are multiple answers, that's OK. I think this is relevant -- because, based on my understanding of what is going on, I think we may need to redefine certain terms in an M context because I'm not sure that the industry standard terms apply. -maury- - Original Message - From: K.S. Bhaskar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 03, 2004 8:12 PM Subject: RE: [Hardhats-members] Krung Thai Bank goes live on GT.M Steve -- There are some differences down in the detail level, mostly as a result of differences between hardware architectures, operating systems, as well as what development found funding and what did not. There are differences between GT.M on Alpha/VMS and GT.M on UNIX/Linux: the underlying OS platforms are different enough that we have different manuals for them - although the manuals are generated from a common source with conditional text. The UNIX implementations support identical implementations of the M language, but here are some examples of the differences: * Some platforms support a Direct IO flag which turns on the O_DIRECT setting for journal IO, which can either speed things up or slow things down depending on the IO subsystem. * GT.M on Sun SPARC Solaris supports Sun RPC call-ins. The others don't. * The GT.M compiler on AIX, HP-UX and Tru64 UNIX creates object files in a format that can be incorporated into .so shared libraries. The GT.M compiler on Linux and Solaris does not. * There may be differences in the ability to pass parameters in registers when calling between M and C on the different platforms, but I can't remember right now. * A GT.M process on AIX can have fewer database files open at one time than on other platforms (the limit is something like 9 caused by fact that each
Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
Kevin -- GT.M automatically links a module on the first call, but not thereafter, unless you do an explicit relink with a ZLink. The cause of the performance hit lies elsewhere. Perhaps GT.M's trace capability can help? For example, try: View TRACE:1:^Trace($Job) ... whatever ... View TRACE:0 Followed by a dump of ^Trace($Job). Of course tracing itself has an overhead, but it might explain where your code is spending its efforts. -- Bhaskar On Sat, 2004-12-04 at 18:37, Kevin Toppenberg wrote: Bhaskar, This may be a bit off topic (re licensing), but it does relate to the linking. I recently divided my program up into modules, with a bunch of debug code all grouped into one TMGDEBUG.m file. When I did this, I noticed that my execution speed went way down. It seemed that the module is being loaded and dumped with every call. Is this true? Kevin --- K.S. Bhaskar [EMAIL PROTECTED] wrote: Maury -- There are several cases of linking to consider with GT.M for x86 GNU/Linux. The most common is the default, when a process executes a Do ^XYZ or a ZLINK XYZ. This is dynamically linked. With GT.M the top level of a process does not have to be M code, but can be in C (or another language). Any calls from C to M are dynamically linked, as are calls from M to C. C to C calls can be dynamically linked, or if two C modules are in the a shared library, they are statically linked to each other. Two C modules in different shared libraries are dynamically linked. Thus, for GT.M for x86 GNU/Linux, any code in M is always dynamically linked, and code in C is dynamically linked with code in M, and for two modules in C, it depends on how they are packaged. With GT.M on AIX, HP-UX and Tru64 UNIX, where code in M can be put into shared libraries, the same rule applies to M modules as to C modules on x86 GNU/Linux, namely that two M modules in the same shared library are considered statically linked to each other, and dynamically linked to anything not in that shared library. So, bottom line is that at least as far as GT.M is concerned, linking is always dynamic unless someone explicitly chooses to make it static. This means that if someone makes an add on to VistA under the GPL, and someone else makes another add on to VistA that is under a license incompatible with the GPL, the fact that linking is dynamic means that the GPL license of one module does not affect the GPL-incompatible license of another module. Your question was very incisive, and I guess the answer means that much of our licensing discussion was unnecessary! I am copying the vista-open-source at yahoogroups.com, since much of the licensing discussion happened over there. Hope this explains things satisfactorily. If not, please ask. -- Bhaskar On Fri, 2004-12-03 at 21:42, Maury Pepper wrote: Bhaskar, As long as you have the hood up, I'd like to ask about GT.M with respect to linking. As you know, the recent conversations about open source licensing touched on the issue of static versus dynamic linking. This seems to be the line that separates contaminated from uncontaminated code. (Excuse the euphemisms.) So, what I would like is your explanation of the linking that exists between routines from two different packages running in a single user's job space. For example, if you are running FOIA VistA and an add-on accounting package together, how might they be linked? If there are multiple answers, that's OK. I think this is relevant -- because, based on my understanding of what is going on, I think we may need to redefine certain terms in an M context because I'm not sure that the industry standard terms apply. -maury- - Original Message - From: K.S. Bhaskar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 03, 2004 8:12 PM Subject: RE: [Hardhats-members] Krung Thai Bank goes live on GT.M Steve -- There are some differences down in the detail level, mostly as a result of differences between hardware architectures, operating systems, as well as what development found funding and what did not. There are differences between GT.M on Alpha/VMS and GT.M on UNIX/Linux: the underlying OS platforms are different enough that we have different manuals for them - although the manuals are generated from a common source with conditional text. The UNIX implementations support identical implementations of the M language, but here are some examples of the differences: * Some platforms support a Direct IO flag which turns on the O_DIRECT setting for journal IO, which can either speed things up or slow things down depending on the IO subsystem. * GT.M on Sun SPARC Solaris
RE: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M)
The emphasis in the VA is on POJO's Plain Old Java Objects. It looks like Hibernate will be used for SQL access. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nancy E. Anthracite Sent: Saturday, December 04, 2004 4:14 PM To: [EMAIL PROTECTED] Subject: Re: [Hardhats-members] GT.M inside (was Krung Thai Bank goes live on GT.M) I just got off the phone with my son who informed me that Sun's Java has a restricted license - look but don't touch - but there are truly open source versions of Java. So is the VA making any distinction in what they are using? Does it matter to us if we start writing GUI plugins for Pedi that are written in Java in hopes they will eventually be integrated with what the VA is working on? Anybody know anything about Java Script licensing? Does it matter? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Hardhats-members mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hardhats-members
