Re: AR System 7.1.00 delayed until end of August / early September
How about ARSSSO ? any news on that ? On 8/13/07, Papolu, Appajee [EMAIL PROTECTED] wrote: Axton, While I cannot give you a pretty concrete statement about this, the general thinking is as follows: Yes, plug-ins can be developed using the first class SDKs - C or Java. Thus the plug-ins existing or newly developed with either language will be supported. While the above holds true for the plug-ins themselves, the plug-in server itself may be a different story though. Once we attain equal or better functionality/stability/performance goals, the plug-in server implementations in C and Java would simply be redundant -- thus I see the possibility of consolidating into only one plug-in server deliverable in future release(s). I am already seeing follow up questions on this comment, so here go few answers: 1. Did you not attain these goals yet? A. For most part yes, but not 100%. For example, we know that on Solaris - hosting C plug-ins in Java plug-in server, we ran into some stability issues especially if some other Java plug-in uses AR System native libraries (like Java API or CMDB API). In such environment, we encourage users to do side by side deployment of C plug-in server to host C plug-ins and Java plug-in server to host only Java plug-ins ( disable hosting any C plug-ins in it). Eventually we're hopeful that we'll resolve such limitations. 2. Any other issues? A. We would like to see the transition rate/ease for users from C Plug-in Server into the new Java plug-in server. Or, at least side-by-side deployment of both of them. Hopefully in 7.1 release we accomplish this smoothly. 3. Which plug-in server would stay (OR) which one will go? A. We implemented an all new implementation ground up now. So draw your conclusions. Any way, the eventual decision will greatly be helped by the readiness of users, rate of deployments of Java plug-in server and of course the elimination of rough edges in the Java plug-in server in all supported platforms. Your questions/comments/concerns/suggestions are welcome. Regards Appajee PS: Comments about future features/roadmap are just indicative of what our current thinking is; by no means it is set in stone and is pretty much subject to change depending on various factors. Another side note -- in future, I see the possibility of filter API plug-ins may indeed have SDK/mechanisms, so that they can indeed be created using other (Java hosting friendly languages) such as JRuby, Rhino/JavaScript, Jython and so on. As Filter API is the way to integrate 'scripted/custom logic' into AR app workflow, I believe opening it up for other languages is pretty powerful. (Lacking this, users with such needs will either give up or resort to cooking up their own plumbing code themselves.) -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Monday, August 13, 2007 7:24 PM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September With the new java api/plugin server, does the roadmap include ongoing support for both c and java plugins? Axton ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are -- Patrick Zandi ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
Appajee, In an earlier email you said that you can use the 7.1 Java api to connect to a 7.01 server What that means is -- the client program runs the pure Java code in issuing AR API's underlying RPC calls when interacting with servers of version 7.0 or greater Can the java plugin-server connects to a 7.01 server? Since the 7.1 java api fallback to old JNI when connecting to version 6.3 or earlier, would it be a good practice to use the 7.1 java api to write clients even when the server is an old version? I suspect the 7.api is more Java than the old one... -- Jarl On 8/14/07, Papolu, Appajee [EMAIL PROTECTED] wrote: Axton, While I cannot give you a pretty concrete statement about this, the general thinking is as follows: Yes, plug-ins can be developed using the first class SDKs - C or Java. Thus the plug-ins existing or newly developed with either language will be supported. While the above holds true for the plug-ins themselves, the plug-in server itself may be a different story though. Once we attain equal or better functionality/stability/performance goals, the plug-in server implementations in C and Java would simply be redundant -- thus I see the possibility of consolidating into only one plug-in server deliverable in future release(s). I am already seeing follow up questions on this comment, so here go few answers: 1. Did you not attain these goals yet? A. For most part yes, but not 100%. For example, we know that on Solaris - hosting C plug-ins in Java plug-in server, we ran into some stability issues especially if some other Java plug-in uses AR System native libraries (like Java API or CMDB API). In such environment, we encourage users to do side by side deployment of C plug-in server to host C plug-ins and Java plug-in server to host only Java plug-ins ( disable hosting any C plug-ins in it). Eventually we're hopeful that we'll resolve such limitations. 2. Any other issues? A. We would like to see the transition rate/ease for users from C Plug-in Server into the new Java plug-in server. Or, at least side-by-side deployment of both of them. Hopefully in 7.1 release we accomplish this smoothly. 3. Which plug-in server would stay (OR) which one will go? A. We implemented an all new implementation ground up now. So draw your conclusions. Any way, the eventual decision will greatly be helped by the readiness of users, rate of deployments of Java plug-in server and of course the elimination of rough edges in the Java plug-in server in all supported platforms. Your questions/comments/concerns/suggestions are welcome. Regards Appajee PS: Comments about future features/roadmap are just indicative of what our current thinking is; by no means it is set in stone and is pretty much subject to change depending on various factors. Another side note -- in future, I see the possibility of filter API plug-ins may indeed have SDK/mechanisms, so that they can indeed be created using other (Java hosting friendly languages) such as JRuby, Rhino/JavaScript, Jython and so on. As Filter API is the way to integrate 'scripted/custom logic' into AR app workflow, I believe opening it up for other languages is pretty powerful. (Lacking this, users with such needs will either give up or resort to cooking up their own plumbing code themselves.) -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Monday, August 13, 2007 7:24 PM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September With the new java api/plugin server, does the roadmap include ongoing support for both c and java plugins? Axton ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
Jarl, My guess (and I stress guess) is that if the 7.1 client connects to anything older than a 7.1 ARServer then it will need to fall back to the JNI layer. ( And in some cases even the 7.1 client to 7.1 server might still need some JNI stuff. But that might just be my skepticism/mis-understandings kicking in there too.) I would expect that after the Java RPC universe matures a bit then a totally pure Java API will happen with no chance for a fall back to JNI when using client and server versions = X.X. However for full backwards compatibility the fall back to JNI will still be possible when talking to a server =7.1. (or maybe just =7.0.1?) At least that is how I have read the info posted on this topic so far. And you also asked about... Can the java plugin-server connects to a 7.01 server? Again.. my guess... The new Java plugin server can use the ARS API to connect to any ARS server. ( And if it need the JNI layer will be determined by the above details.) However, my guess is that the Plugin server will still only be supported on the supported server platforms too. So the JNI stuff should be available anyway. It does remain to be seen if an ARS server v6.x or v7.0.1 can make a call to a v7.1 Java based Plugin Server too. ( But that might be an animal of a different shape than what you want to fight with too. :) I hope that makes sense.. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 8/14/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Appajee, In an earlier email you said that you can use the 7.1 Java api to connect to a 7.01 server What that means is -- the client program runs the pure Java code in issuing AR API's underlying RPC calls when interacting with servers of version 7.0 or greater Can the java plugin-server connects to a 7.01 server? Since the 7.1 java api fallback to old JNI when connecting to version 6.3 or earlier, would it be a good practice to use the 7.1 java api to write clients even when the server is an old version? I suspect the 7.api is more Java than the old one... -- Jarl ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
I just refering to an earier email from Appajee: In fact in the 7.1 Java API, we have implemented the necessary rpc version mapping infrastructure as well, but it is validated for 7.0/7.0.1 only. What that means is -- the client program runs the pure Java code in issuing AR API's underlying RPC calls when interacting with servers of version 7.0 or greater. However if the client is interacting with older servers (say 6.3 or even older), then the Java API silently falls back to delegating the calls to underlying JNI code, which in turn calls C API which has rich implementation of RPC version mapping. All of this happens transparently to client program any ways, so in essence, the Java API clients of 7.1 version can indeed talk to same or older or newer versions of Server as were before. Only thing is that for legacy server interactions, the Java API relies on its legacy infrastructure (JNI/C API combo) in 7.1 release. In future, as indicated in previous email note, this will change (i.e. improve RPC version mapping layer within Java API) so that this native dependency is also eliminated. -- Jarl On 8/14/07, Carey Matthew Black [EMAIL PROTECTED] wrote: Jarl, My guess (and I stress guess) is that if the 7.1 client connects to anything older than a 7.1 ARServer then it will need to fall back to the JNI layer. ( And in some cases even the 7.1 client to 7.1 server might still need some JNI stuff. But that might just be my skepticism/mis-understandings kicking in there too.) I would expect that after the Java RPC universe matures a bit then a totally pure Java API will happen with no chance for a fall back to JNI when using client and server versions = X.X. However for full backwards compatibility the fall back to JNI will still be possible when talking to a server =7.1. (or maybe just =7.0.1?) At least that is how I have read the info posted on this topic so far. And you also asked about... Can the java plugin-server connects to a 7.01 server? Again.. my guess... The new Java plugin server can use the ARS API to connect to any ARS server. ( And if it need the JNI layer will be determined by the above details.) However, my guess is that the Plugin server will still only be supported on the supported server platforms too. So the JNI stuff should be available anyway. It does remain to be seen if an ARS server v6.x or v7.0.1 can make a call to a v7.1 Java based Plugin Server too. ( But that might be an animal of a different shape than what you want to fight with too. :) I hope that makes sense.. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap Pick two. On 8/14/07, Jarl Grøneng [EMAIL PROTECTED] wrote: Appajee, In an earlier email you said that you can use the 7.1 Java api to connect to a 7.01 server What that means is -- the client program runs the pure Java code in issuing AR API's underlying RPC calls when interacting with servers of version 7.0 or greater Can the java plugin-server connects to a 7.01 server? Since the 7.1 java api fallback to old JNI when connecting to version 6.3 or earlier, would it be a good practice to use the 7.1 java api to write clients even when the server is an old version? I suspect the 7.api is more Java than the old one... -- Jarl ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
Hi The new Java plugin server can use the ARS API to connect to any ARS server. ( And if it need the JNI layer will be determined by the above details.) However, my guess is that the Plugin server will still only be supported on the supported server platforms too. So the JNI stuff should be available anyway. It does remain to be seen if an ARS server v6.x or v7.0.1 can make a call to a v7.1 Java based Plugin Server too. ( But that might be an animal of a different shape than what you want to fight with too. :) Plug-in server itself does not directly issue AR System Java API calls. [Rather it is the AR System server that initiates calls into the plug-in server.] Any way, individual plug-ins themselves can issue API calls as they wish and the API version they bind to can be of older or 7.1 (although I would advocate folks to use the 7.1) version as long as the dependency listing is properly defined in the plug-in configuration. Same thing applies to any other external package class/jar dependency your plug-in may have. Can old version server talk to 7.1 Java Plug-in server? Technically yes. However old server new plug-in server is completely an unsupported combination. So, honestly, we did not spend any effort in ensuring that this in fact works. We indeed are aware of some use cases where folks wanted to deploy 7.1 plug-in server with their Java plug-ins into a pre-7.1 Server environment. Regards Appajee ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
In this release, the existing C plug-ins will be delivered as were before. Remember we do still deliver native C based Plug-in server also note that the new Java based plug-in server supports running C plug-ins too. There is a newly implemented web service plug-in built in Java as well. Yes, it will be part of the 7.1 deliverables. Hopefully you'll find this plug-in more usable than the previous version offering. Another side note though, we did not (get a chance to) implement all of our previously delivered C plug-ins (like server admin console's backing plug-in for example) as Java plug-ins. As Java based plug-in server is able to host even the existing or newly developed C plug-ins, we believe this is not a big problem. Regards Appajee From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, August 11, 2007 12:38 AM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September ** Hi, Will the BMC provided plugins be delivered in a java version? Ie:Will the Web service plugin still be C based or is it Java based? The C based web service plugins leak memory like a sieve... Thanks, Jarl ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
With the new java api/plugin server, does the roadmap include ongoing support for both c and java plugins? Axton On 8/13/07, Papolu, Appajee [EMAIL PROTECTED] wrote: ** In this release, the existing C plug-ins will be delivered as were before. Remember we do still deliver native C based Plug-in server also note that the new Java based plug-in server supports running C plug-ins too. There is a newly implemented web service plug-in built in Java as well. Yes, it will be part of the 7.1 deliverables. Hopefully you'll find this plug-in more usable than the previous version offering. Another side note though, we did not (get a chance to) implement all of our previously delivered C plug-ins (like server admin console's backing plug-in for example) as Java plug-ins. As Java based plug-in server is able to host even the existing or newly developed C plug-ins, we believe this is not a big problem. Regards Appajee From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Jarl Grøneng Sent: Saturday, August 11, 2007 12:38 AM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September ** Hi, Will the BMC provided plugins be delivered in a java version? Ie:Will the Web service plugin still be C based or is it Java based? The C based web service plugins leak memory like a sieve... Thanks, Jarl __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
Axton, While I cannot give you a pretty concrete statement about this, the general thinking is as follows: Yes, plug-ins can be developed using the first class SDKs - C or Java. Thus the plug-ins existing or newly developed with either language will be supported. While the above holds true for the plug-ins themselves, the plug-in server itself may be a different story though. Once we attain equal or better functionality/stability/performance goals, the plug-in server implementations in C and Java would simply be redundant -- thus I see the possibility of consolidating into only one plug-in server deliverable in future release(s). I am already seeing follow up questions on this comment, so here go few answers: 1. Did you not attain these goals yet? A. For most part yes, but not 100%. For example, we know that on Solaris - hosting C plug-ins in Java plug-in server, we ran into some stability issues especially if some other Java plug-in uses AR System native libraries (like Java API or CMDB API). In such environment, we encourage users to do side by side deployment of C plug-in server to host C plug-ins and Java plug-in server to host only Java plug-ins ( disable hosting any C plug-ins in it). Eventually we're hopeful that we'll resolve such limitations. 2. Any other issues? A. We would like to see the transition rate/ease for users from C Plug-in Server into the new Java plug-in server. Or, at least side-by-side deployment of both of them. Hopefully in 7.1 release we accomplish this smoothly. 3. Which plug-in server would stay (OR) which one will go? A. We implemented an all new implementation ground up now. So draw your conclusions. Any way, the eventual decision will greatly be helped by the readiness of users, rate of deployments of Java plug-in server and of course the elimination of rough edges in the Java plug-in server in all supported platforms. Your questions/comments/concerns/suggestions are welcome. Regards Appajee PS: Comments about future features/roadmap are just indicative of what our current thinking is; by no means it is set in stone and is pretty much subject to change depending on various factors. Another side note -- in future, I see the possibility of filter API plug-ins may indeed have SDK/mechanisms, so that they can indeed be created using other (Java hosting friendly languages) such as JRuby, Rhino/JavaScript, Jython and so on. As Filter API is the way to integrate 'scripted/custom logic' into AR app workflow, I believe opening it up for other languages is pretty powerful. (Lacking this, users with such needs will either give up or resort to cooking up their own plumbing code themselves.) -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Monday, August 13, 2007 7:24 PM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September With the new java api/plugin server, does the roadmap include ongoing support for both c and java plugins? Axton ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
Re: AR System 7.1.00 delayed until end of August / early September
Hi, Will the BMC provided plugins be delivered in a java version? Ie:Will the Web service plugin still be C based or is it Java based? The C based web service plugins leak memory like a sieve... Thanks, Jarl On 8/10/07, Easter, David [EMAIL PROTECTED] wrote: ** All, BMC has decided that more time is needed to ensure the quality of AR System prior to release. Based on the tests that need to be completed to verify AR System's quality in an enterprise environment consisting of highly available architectures and multiple BMC Products, the management team has extended the delivery date by several weeks. We hope to make it available on the web for download (a.k.a. Web GA) no later than *August 31st, 2007*. The physical GA date for AR System will then be Friday September 7th, 2007. Because this extension is being used only to perform further testing, the feature set has become solid enough that I have been granted permission to share the What's New document that contains details on the new features found in AR System 7.1.00. This document can be found on the new BMC Developer's Network at: http://developer.bmc.com/jiveProd/entry.jspa?categoryID=501externalID=1926 Here's the quick bulleted list of features: *Enterprise** features* - Customer-driven license enforcement system - Server security attack prevention - Mid-tier security attack prevention for Tomcat installations - Forcing and allowing password changes - Web client IP address logging - Safari browser support - BMC Remedy Mid Tier performance (persistent cache) - Prefetching specified forms - Web services enhancements - Multiple escalation pools - HTTP tracing in the mid tier - Broadened operating system support for Full Text Search on UNIX and Linux *Server features* - Java plug-in server and plug-in API - Updated AR System Java API - Filter error handling - Multiple Field API Calls - Store database views with schema definitions - Service workflow condition and active link action - Disable status history recording and retrieval - Simplified System Form Handling - IBM DB2 9.1 support - HP-UX 11i v3 support - Novell SuSE Enterprise Linux support - Red Hat Enterprise Linux 5 AS/ES support - Enhanced support for Mozilla Firefox 2.0 support - Enhanced support for Microsoft Internet Explorer 7.0 support *Client features* - BMC Remedy AR System Administration Console - Data visualization field updates - Results color in tree fields - Page holder enhancements - Ability to change labels for navigation bars - Locale-aware table fields - Customizable background color on rows - Table refresh on interval - Automatic maximizing of windows on target location for web clients *Usability features* - Displaying version information - Pop-up blockers - Wait cursor - Context (right-click) menus - Rounded corner option for trim boxes *BMC Remedy Migrator features* - Enhancements to Differences report - Enhancements to Results report - Ignore Prefix option - Packaged view migrations (ability to migrate a specific view and its fields) - Option to keep or delete dependency and database files Of most interest to customers will be the first bullet - the Customer-driven license enforcement system. Here's some more info on that from the What's New document: Unlike previous versions, AR System 7.1.00 does not use license keys to enforce limits for any license types *except *AR Server licenses. Instead, customers must self enforce limits for all other AR System and application license types, such as AR User Fixed, BMC Remedy AR FTS Fixed, BMC:Asset Mgmt Application, and BMC:Change Mgmt User Floating. Regardless of the type or number of licenses purchased by a customer, AR System 7.1.00administrators can add an unlimited number of most licenses to their systems through the Add or Remove Licenses link in the AR System Administration Console. Using this link, administrators can also modify and remove licenses whenever necessary. This enables them to meet users' AR System licensing needs immediately without waiting for BMC Software to provide a key. I'm sure this will generate a lot of questions and I will endeavor to answer what I can on this forum both during this pre-release phase and once the product is released. This topic will also be covered in a focused presentation at BMC UserWorld. In addition, I will post a second message right after this one that has an extensive FAQ. I appreciate our customer's continued patience in releasing this new product and look forward to answering questions and gathering feedback on this new version of AR System. Thanks, *David J. Easter* Product Line Manager [image: BMC Software] http://www.bmc.com/ AR System - BMC Service Management Business Unit
Re: AR System 7.1.00 delayed until end of August / early September
This one seems nice: Service workflow condition and active link action Then we can trigger a filter command from an active linke. No more need to do a sumit or modify to trigger a web service :-) -- Jarl On 8/10/07, Easter, David [EMAIL PROTECTED] wrote: ** All, BMC has decided that more time is needed to ensure the quality of AR System prior to release. Based on the tests that need to be completed to verify AR System's quality in an enterprise environment consisting of highly available architectures and multiple BMC Products, the management team has extended the delivery date by several weeks. We hope to make it available on the web for download (a.k.a. Web GA) no later than *August 31st, 2007*. The physical GA date for AR System will then be Friday September 7th, 2007. Because this extension is being used only to perform further testing, the feature set has become solid enough that I have been granted permission to share the What's New document that contains details on the new features found in AR System 7.1.00. This document can be found on the new BMC Developer's Network at: http://developer.bmc.com/jiveProd/entry.jspa?categoryID=501externalID=1926 Here's the quick bulleted list of features: *Enterprise** features* - Customer-driven license enforcement system - Server security attack prevention - Mid-tier security attack prevention for Tomcat installations - Forcing and allowing password changes - Web client IP address logging - Safari browser support - BMC Remedy Mid Tier performance (persistent cache) - Prefetching specified forms - Web services enhancements - Multiple escalation pools - HTTP tracing in the mid tier - Broadened operating system support for Full Text Search on UNIX and Linux *Server features* - Java plug-in server and plug-in API - Updated AR System Java API - Filter error handling - Multiple Field API Calls - Store database views with schema definitions - Service workflow condition and active link action - Disable status history recording and retrieval - Simplified System Form Handling - IBM DB2 9.1 support - HP-UX 11i v3 support - Novell SuSE Enterprise Linux support - Red Hat Enterprise Linux 5 AS/ES support - Enhanced support for Mozilla Firefox 2.0 support - Enhanced support for Microsoft Internet Explorer 7.0 support *Client features* - BMC Remedy AR System Administration Console - Data visualization field updates - Results color in tree fields - Page holder enhancements - Ability to change labels for navigation bars - Locale-aware table fields - Customizable background color on rows - Table refresh on interval - Automatic maximizing of windows on target location for web clients *Usability features* - Displaying version information - Pop-up blockers - Wait cursor - Context (right-click) menus - Rounded corner option for trim boxes *BMC Remedy Migrator features* - Enhancements to Differences report - Enhancements to Results report - Ignore Prefix option - Packaged view migrations (ability to migrate a specific view and its fields) - Option to keep or delete dependency and database files Of most interest to customers will be the first bullet - the Customer-driven license enforcement system. Here's some more info on that from the What's New document: Unlike previous versions, AR System 7.1.00 does not use license keys to enforce limits for any license types *except *AR Server licenses. Instead, customers must self enforce limits for all other AR System and application license types, such as AR User Fixed, BMC Remedy AR FTS Fixed, BMC:Asset Mgmt Application, and BMC:Change Mgmt User Floating. Regardless of the type or number of licenses purchased by a customer, AR System 7.1.00administrators can add an unlimited number of most licenses to their systems through the Add or Remove Licenses link in the AR System Administration Console. Using this link, administrators can also modify and remove licenses whenever necessary. This enables them to meet users' AR System licensing needs immediately without waiting for BMC Software to provide a key. I'm sure this will generate a lot of questions and I will endeavor to answer what I can on this forum both during this pre-release phase and once the product is released. This topic will also be covered in a focused presentation at BMC UserWorld. In addition, I will post a second message right after this one that has an extensive FAQ. I appreciate our customer's continued patience in releasing this new product and look forward to answering questions and gathering feedback on this new version of AR System. Thanks, *David J. Easter* Product Line Manager [image: BMC Software] http://www.bmc.com/ AR System - BMC Service Management Business Unit
Re: AR System 7.1.00 delayed until end of August / early September
David, When I tried to access the Whats New document (from your hyper-link below) I received an error that the document had expired. Russ From: Easter, David [EMAIL PROTECTED] Reply-To: arslist@ARSLIST.ORG To: arslist@ARSLIST.ORG Subject: AR System 7.1.00 delayed until end of August / early September Date: Thu, 9 Aug 2007 17:40:31 -0700 All, BMC has decided that more time is needed to ensure the quality of AR System prior to release. Based on the tests that need to be completed to verify AR System's quality in an enterprise environment consisting of highly available architectures and multiple BMC Products, the management team has extended the delivery date by several weeks. We hope to make it available on the web for download (a.k.a. Web GA) no later than August 31st, 2007. The physical GA date for AR System will then be Friday September 7th, 2007. Because this extension is being used only to perform further testing, the feature set has become solid enough that I have been granted permission to share the What's New document that contains details on the new features found in AR System 7.1.00. This document can be found on the new BMC Developer's Network at: http://developer.bmc.com/jiveProd/entry.jspa?categoryID=501externalID=1 926 Here's the quick bulleted list of features: Enterprise features * Customer-driven license enforcement system * Server security attack prevention * Mid-tier security attack prevention for Tomcat installations * Forcing and allowing password changes * Web client IP address logging * Safari browser support * BMC Remedy Mid Tier performance (persistent cache) * Prefetching specified forms * Web services enhancements * Multiple escalation pools * HTTP tracing in the mid tier * Broadened operating system support for Full Text Search on UNIX and Linux Server features * Java plug-in server and plug-in API * Updated AR System Java API * Filter error handling * Multiple Field API Calls * Store database views with schema definitions * Service workflow condition and active link action * Disable status history recording and retrieval * Simplified System Form Handling * IBM DB2 9.1 support * HP-UX 11i v3 support * Novell SuSE Enterprise Linux support * Red Hat Enterprise Linux 5 AS/ES support * Enhanced support for Mozilla Firefox 2.0 support * Enhanced support for Microsoft Internet Explorer 7.0 support Client features * BMC Remedy AR System Administration Console * Data visualization field updates * Results color in tree fields * Page holder enhancements * Ability to change labels for navigation bars * Locale-aware table fields * Customizable background color on rows * Table refresh on interval * Automatic maximizing of windows on target location for web clients Usability features * Displaying version information * Pop-up blockers * Wait cursor * Context (right-click) menus * Rounded corner option for trim boxes BMC Remedy Migrator features * Enhancements to Differences report * Enhancements to Results report * Ignore Prefix option * Packaged view migrations (ability to migrate a specific view and its fields) * Option to keep or delete dependency and database files Of most interest to customers will be the first bullet - the Customer-driven license enforcement system. Here's some more info on that from the What's New document: Unlike previous versions, AR System 7.1.00 does not use license keys to enforce limits for any license types except AR Server licenses. Instead, customers must self enforce limits for all other AR System and application license types, such as AR User Fixed, BMC Remedy AR FTS Fixed, BMC:Asset Mgmt Application, and BMC:Change Mgmt User Floating. Regardless of the type or number of licenses purchased by a customer, AR System 7.1.00 administrators can add an unlimited number of most licenses to their systems through the Add or Remove Licenses link in the AR System Administration Console. Using this link, administrators can also modify and remove licenses whenever necessary. This enables them to meet users' AR System licensing needs immediately without waiting for BMC Software to provide a key. I'm sure this will generate a lot of questions and I will endeavor to answer what I can on this forum both during this pre-release phase and once the product is released. This topic will also be covered in a focused presentation at BMC UserWorld. In addition, I will post a second message right after this one that has an extensive FAQ. I appreciate our customer's continued patience in releasing this new product and look forward to answering questions and gathering feedback on this new version of AR System. Thanks, David J. Easter Product Line Manager http
Re: AR System 7.1.00 delayed until end of August / early September
Russ - Not sure what your link looked like before you forwarded this to the list, but it appears to have gotten wrapped and broken. The last chunk should be 'externalID=1926' Thanks, Ron Legters Tools Administrator Data Systems Services Univar USA Inc. 425.889.3952 Office 425.889.4111 Fax www.univarusa.com -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Russ Grant Sent: Friday, August 10, 2007 1:51 PM To: arslist@ARSLIST.ORG Subject: Re: AR System 7.1.00 delayed until end of August / early September David, When I tried to access the Whats New document (from your hyper-link below) I received an error that the document had expired. Russ From: Easter, David [EMAIL PROTECTED] Reply-To: arslist@ARSLIST.ORG To: arslist@ARSLIST.ORG Subject: AR System 7.1.00 delayed until end of August / early September Date: Thu, 9 Aug 2007 17:40:31 -0700 All, BMC has decided that more time is needed to ensure the quality of AR System prior to release. Based on the tests that need to be completed to verify AR System's quality in an enterprise environment consisting of highly available architectures and multiple BMC Products, the management team has extended the delivery date by several weeks. We hope to make it available on the web for download (a.k.a. Web GA) no later than August 31st, 2007. The physical GA date for AR System will then be Friday September 7th, 2007. Because this extension is being used only to perform further testing, the feature set has become solid enough that I have been granted permission to share the What's New document that contains details on the new features found in AR System 7.1.00. This document can be found on the new BMC Developer's Network at: http://developer.bmc.com/jiveProd/entry.jspa?categoryID=501externalID= 1926 Here's the quick bulleted list of features: Enterprise features * Customer-driven license enforcement system * Server security attack prevention * Mid-tier security attack prevention for Tomcat installations * Forcing and allowing password changes * Web client IP address logging * Safari browser support * BMC Remedy Mid Tier performance (persistent cache) * Prefetching specified forms * Web services enhancements * Multiple escalation pools * HTTP tracing in the mid tier * Broadened operating system support for Full Text Search on UNIX and Linux Server features * Java plug-in server and plug-in API * Updated AR System Java API * Filter error handling * Multiple Field API Calls * Store database views with schema definitions * Service workflow condition and active link action * Disable status history recording and retrieval * Simplified System Form Handling * IBM DB2 9.1 support * HP-UX 11i v3 support * Novell SuSE Enterprise Linux support * Red Hat Enterprise Linux 5 AS/ES support * Enhanced support for Mozilla Firefox 2.0 support * Enhanced support for Microsoft Internet Explorer 7.0 support Client features * BMC Remedy AR System Administration Console * Data visualization field updates * Results color in tree fields * Page holder enhancements * Ability to change labels for navigation bars * Locale-aware table fields * Customizable background color on rows * Table refresh on interval * Automatic maximizing of windows on target location for web clients Usability features * Displaying version information * Pop-up blockers * Wait cursor * Context (right-click) menus * Rounded corner option for trim boxes BMC Remedy Migrator features * Enhancements to Differences report * Enhancements to Results report * Ignore Prefix option * Packaged view migrations (ability to migrate a specific view and its fields) * Option to keep or delete dependency and database files Of most interest to customers will be the first bullet - the Customer-driven license enforcement system. Here's some more info on that from the What's New document: Unlike previous versions, AR System 7.1.00 does not use license keys to enforce limits for any license types except AR Server licenses. Instead, customers must self enforce limits for all other AR System and application license types, such as AR User Fixed, BMC Remedy AR FTS Fixed, BMC:Asset Mgmt Application, and BMC:Change Mgmt User Floating. Regardless of the type or number of licenses purchased by a customer, AR System 7.1.00 administrators can add an unlimited number of most licenses to their systems through the Add or Remove Licenses link in the AR System Administration Console. Using this link, administrators can also modify and remove licenses whenever necessary. This enables them to meet users' AR System licensing needs immediately without waiting for BMC Software to provide a key. I'm sure
Re: AR System 7.1.00 delayed until end of August / early September
Wow! It sure looks like BMC has been busy giving us some great stuff. I am especially looking forward to this feature: Disable status history recording and retrieval Check it out by clicking on the hyperlink below and then open up the .pdf This should definitely improve performance at the most basic level of all data operations! Bruce Wilson Datastream Consulting, LLC. From: Ben Cantatore [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 9:40 PM Subject: Re: AR System 7.1.00 delayed until end of August / early September I'm glad that BMC is taking more time to throughly test the product. This will cut down on fustrations when trying to implement it. Thank you for the update. Ben Cantatore Remedy Administrator Avon (914) 935-2946 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
WG: AR System 7.1.00 delayed until end of August / early September / MidTier
_ Von: Christian Janovic [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 10. August 2007 14:50 An: 'arslist@ARSLIST.ORG' Betreff: AW: AR System 7.1.00 delayed until end of August / early September David, many Remedy Users around the globe were desperately waiting for a better MidTier Performance on initial loading and will be most thankful for the new release. There is just a point - not clearly explained in the .pdf - on which more information would be helpful: One of the major troubles with MidTier is that it seems to generate different versions of HTML-Forms for each combination of user groups even if those groups are not relevant permission groups form or field visibility. I don't understand if THIS point will be improved. If not its only half way, as persistent MidTier caching will only slightly improve performance. In other words: I cannot prefetch forms for any existing group combination that my users have, unless I want to wait a very long time until MidTier is running. Could you please provide more information on this topic, so Remedy Customers can plan whether to switch to MidTier for a broader number of users? Kind regards, Christian _ Von: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Im Auftrag von Easter, David Gesendet: Freitag, 10. August 2007 02:41 An: arslist@ARSLIST.ORG Betreff: AR System 7.1.00 delayed until end of August / early September All, BMC has decided that more time is needed to ensure the quality of AR System prior to release. Based on the tests that need to be completed to verify AR System's quality in an enterprise environment consisting of highly available architectures and multiple BMC Products, the management team has extended the delivery date by several weeks. We hope to make it available on the web for download (a.k.a. Web GA) no later than August 31st, 2007. The physical GA date for AR System will then be Friday September 7th, 2007. . __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:Where the Answers Are
