2 Replies Latest reply on Nov 16, 2005 1:52 AM by 463130

    CAPI version - URGENT

    463130
      Hi ,

      What should the "capi_storage" parameter in unison.ini be ?

      The SDK that we are using is 9.0.4.10. Its currently set at "FH".

      What are the implications on the client API side if this was set wrongly. What are the max numbers of allowed transactions from an API ? Is there any setting to increase this setting , if so ??


      URGENT PLEASE .
        • 1. Re: CAPI version - URGENT
          414326
          Hi,

          First of all, what is your problem exactly?
          What are the implications on the client API side if
          this was set wrongly.
          Mainly Performance.
          What are the max numbers of
          allowed transactions from an API ? Is there any
          y setting to increase this setting , if so ??
          Could you please clarify what you mean by transaction?
          What should the "capi_storage" parameter in
          unison.ini be ?
          capi_storage is a legacy parameter and should not be specified in the unison.ini anymore, s.t. the default value is used (OPTFH).

          Although you might have to run the calendar server utility unifhconv(should be found in your $OH/ocal/bin) not to loose any event information before removing the keyword from your unison.ini.

          Here is documentation I found for the reason why we would use that utility:
          // Fieldholders are records which are "attached" to other structures as
          // a means of dynamically expanding the fields of a structure. This has
          // been largely obsoleted by attribute lists, but some data is still kept
          // in field holders, notably extra event/instance/attendee information which
          // has been stored by the unical client-side library (used by old versions
          // of CAPI, and old native clients for import/export of iCalendar).

          // With the addition of many attributes in direct support of various
          // iCalendar properties, we don't need to store this data in field holders
          // anymore, and we can do away with the inefficient calls required to
          // fetch and store them. However, we need to convert the existent data
          // on the server to the new attributes.

          Regards,
          Jean-Philippe
          • 2. Re: CAPI version - URGENT
            463130
            Thanks for that reply Jean-Philippe,

            The actual problem we have is that the client API we use was inflicting a significant performance hit ( in terms of CPU) on our Calendar server. Normally, we have about 2500 active users using native client to access and CPU utilization is around 20%.
            When we have about 50 API calls hitting the server doing basic appointments and free dates range searches.

            The API side kept falling over , which a TAR has been logged (TAR#: 4850071.992). While that is being investigated, I am looking from the server side of things. Hence the question of whether the entry of "capi_storage" is affecting the API calls.

            Appreciate your response.