Ben, There needs to be an overall look at the issues you are having -- please submit the issues and concerns to the support team and they can be investigated. There is always the chance that an error was made that needs to be corrected and that will definitely be looked into and action taken to correct the problem.
But, I want to pursue the topic of API version that you have brought up in your recent messages. API version != product version We sometimes change the API version multiple times between releases. We sometimes change the API version for a maintenance release. We sometimes don't change the API version for a maintenance release and there are occasions where the API version may not change for a release. It is all about the API version and whether there was a notable change made such that we have to map the protocol between clients and servers of different versions. If you are using the API version as a product release version, that is incorrect and will not work. We do not always change the API even when there are new releases. Yes, it changes with many releases, but not with ALL releases. To tell what release you are using, you should be using AR_SERVER_INFO_VERSION (code 4). This will give you the version of the server and it includes details about version and service pack and patch. THIS will be changed in each release for sure --- well I sure hope you find it being different between releases as it sure is supposed to be different..... I just want to be sure that the right value is being used for the right purpose. I am concerned and want to find out why you have found some differences in the server information results returned -- that is not supposed to happen. I also want to be sure you are using the right setting for the right purpose. On the other hand, I want to be sure you are not misusing the API version to determine server version -- they are not the same thing. Now, did 9.1 change the API protocol? And, should the number have changed from server info? That can be double checked, but it very well may not have changed. I hope this helps, Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys Sent: Thursday, March 17, 2016 7:21 AM To: arslist@ARSLIST.ORG Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0 Hi Misi, Not true re keeping the c API up-to-date. BMC still delivers many binaries with the c API (in both 32 and 64 bits) in the 9.1.0 installation. And the point is beyond BMC anyhow. They publish it and it should work. It should also allow a higher API to communicate with lower servers. Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: March-17-16 05:57 To: arslist@ARSLIST.ORG Subject: Re: Confusion over AR_SERVER_INFO values as changed in the Rel 9 API - even worse with 9.1.0 Hi Mark, Do you really think that the server will map 379 to 380 depending on the client API version? The API version in ar.h seems to be the same in the sample Ben gave us. To me it seems unsettling that the C-API is not updated in the same way as the Java-API. But I guess this was bound to happen. If there is no longer a C-API-Admin-Tool but instead a Java-API-DevStudio, there is no point in keeping the C-API up to date. In any event I will be increasingly afraid to do Admin-changes through the C-API... Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Ben, > > I'm not 100% certain but my understanding is that the API version does > not indicate the server version but the version of the API > specification - the values below are from the ar.h file? If so this > is the API/RPC revision level that a client built using that API will > conform to. The server will have a corresponding max API revision > number and the two will negotiate to the highest supported by both. > If you want the server version you'll have to make a GSI call for operation > number 4. > > If you check the API logs from a 9.1 server you should see some > clients with protocol version 23 so it looks like the C and Java APIs > may be at different levels in 9.1. > > I've tried to put together a list of release and protocol/db versions > here - > https://communities.bmc.com/docs/DOC-37267 > > Mark > > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys > Sent: 17 March 2016 02:17 > To: arslist@ARSLIST.ORG > Subject: Re: Confusion over AR_SERVER_INFO values as changed in the > Rel 9 API > - even worse with 9.1.0 > > ** > Well folks, > > I'm afraid it just got a lot worse!!! > > 9.1.0 identifies itself as 9.0.0 but has a different set of > AR_SERVER_INFO > values: > >>From 9.0.0 > #define AR_CURRENT_API_VERSION 21 /* current api version */ > #define AR_MAX_SERVER_INFO_USED 426 /* set "highest" server info */ > >>From 9.1.0 > #define AR_CURRENT_API_VERSION 21 /* current api version */ > #define AR_MAX_SERVER_INFO_USED 443 /* set "highest" server info */ > > I suppose it is too late for BMC to fix this absolute mess. How is one's > source code to differentiate between 9.0.0 and 9.1.0 - given that they > both identify themselves as the same release and given that they have > different symbols defined? I suppose it means that > AR_CURRENT_API_VERSION is NOT to be used to identify the API release > but rather AR_MAX_SERVER_INFO_USED (as long as you don't go back far > enough that that symbol is not defined) or possibly a combination of the two > symbols. > > I have yet to look at the actual INFO values themselves and shudder to > think what I may find. > > Cheers > Ben > > From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] > Sent: March-01-16 10:24 > To: 'arslist@ARSLIST.ORG' > Subject: Confusion over AR_SERVER_INFO values as changed in the Rel 9 > API > > Hi Folks, > > I am just trying to get my head around the AR_SERVER_INFO changes > introduced in release 9. > > ARS 9 does something not done previously with these values: > It changes the integer in some Info values and deletes some Info > values > > Image this scenario: You have a release 9 API accessing a Release 8 server. > Which symbol do you use for a release 8 value? There are no symbols > for deleted values which are still legitimate on the 8 server. The > symbol defined in the 9 API will request the wrong value on an 8 server. > > Similarly, you have a release 8 API accessing a release 9 server: > When you ask for an Info that has had a number change, what do you get? > > For now, I will have to get around the problem by not asking for > contentious info values. Heaven forbid that someone wants these > values :) > > I question how something this basic and simple could have been turned > into something this obtuse and convoluted. I also question what the > API itself does when "maintaining compatibility" across server releases. > > Kudos to BMC, they have maintained excellent compatibility across > server releases when it comes to the data portion of the API. > This is the first release which does not. Any comments from BMC would > be welcome. > > Details: > > Release 8.1 API > > - These are all dropped in 9: > #define AR_SERVER_INFO_MESSAGE_BROKER_URL 374 /* char - Message Broker > URL */ > #define AR_SERVER_INFO_NUMBER_OF_SELECTOR_THREADS 375 /* int - Number > of selector threads. */ > #define AR_SERVER_INFO_MESSAGE_BROKER_PORT 376 /* int - Messsaging(JMS) > broker port. */ > #define AR_SERVER_INFO_JMX_PORT 377 /* int - JMX Port */ > #define AR_SERVER_INFO_PEER_LISTENER_PORT 378 /* int - (Cache) > Peer-listener-port */ > > - These are renumbered in 9: > #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 379 /* int - > Update Interval for API Monitoring */ #define > AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE 380 /* char - API Recording > on for specific Client Type */ > #define AR_SERVER_INFO_API_RECORDING_ENABLE 381 /* int - Enable Flag > would be set to T or F */ > #define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE 380 /* char - API > Recording on for specific Client Type */ > #define AR_SERVER_INFO_API_RECORDING_ENABLE 381 /* int - Enable Flag > would be set to T or F */ > #define AR_SERVER_INFO_OBJ_RESERVATION_REPOSITORY_TYPE 382 /* int - > Object reservation repository type - 0 ARS; 10 External */ > > - This value has a different meaning in 9: > #define AR_SERVER_INFO_SERVICE_RECORDING_ENABLE 383 /* int - flag to enable > the Service Monitoring */ > > - Now they align with 9 > #define AR_SERVER_INFO_STATS_APISQL_CONTROL 384 /* Bitmask for controlling > API/SQL display to console, exception logging option, etc. */ > > Release 9 API Release 9 has no 379 :) > #define AR_SERVER_INFO_API_MONITORING_UPDATE_INTERVAL 380 /* int - > Update Interval for API Monitoring */ > #define AR_SERVER_INFO_API_RECORDING_CLIENT_TYPE 381 /* String - > API Recording on for specific Client Type */ > #define AR_SERVER_INFO_API_RECORDING_ENABLE 382 /* int - > Enable Flag would be set to T or F */ > #define AR_SERVER_INFO_OBJ_RESERVATION_REPOSITORY_TYPE 383 /* int Object > reservation repository type - 0 ARS */ > /* > > - 10 External */ > #define AR_SERVER_INFO_STATS_APISQL_CONTROL 384 /* bitmask Controls API > and SQL recording */ > > > Cheers, > Ben Chernys > Senior Software Architect > [logoSthInc-sm] > > Canada / Deutschland > Mobile: +49 171 380 2329 GMT + 7 + [ DST ] > Land: +1 403 240 4377 > Email: > ben.cher...@softwaretoolhouse.com<mailto:ben.cher...@softwaretoolhouse.com> > Web: www.softwaretoolhouse.com<http://www.softwaretoolhouse.com/> > > We are a BMC Technology Alliance Partner > > > > Check out Software Tool House's free Diary Editor and our Freebies > Section for ITSM Forms and Fields spreadsheet. > > Meta-Update, our premium ARS Data tool, lets you automate your data > changes, imports, migrations, in no time at all, without programming, > without staging forms, without merge workflow. > > Meta-Archive does ITSM Archiving your way: with your forms and your > multi-tenant rules, treating each root request as the tree of data and > forms that it is it is. Output to Archive forms, an archive server, > CSV and HTML with all attachments extracted and linked. > > Pre ITSM 7.6.04? Clarify? Roll your own? No problem! > You can keep your valuable data! > > http://www.softwaretoolhouse.com/ > > > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ BMC > Software Limited Registered Office: Building E2, Eskdale Road, > Winnersh, Wokingham, Berkshire, United Kingdom, RG41 5TS Registered in > England No.. > 1927903 The content of this email is confidential. If you are not the > addressee, you may not distribute, copy or disclose any part of it. If > you receive this message in error, please delete this from your system > and notify the sender immediately. > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
