CA Gen EDGE

Expand all | Collapse all

CA Gen 8.5 Support Client model lock

Jump to Best Answer
  • 1.  CA Gen 8.5 Support Client model lock

    Posted 10-19-2017 07:10 PM

    Recently we moved our gen cse DB from windows oracle to unix oracle (both v12).

    What I noticed is that the support client is now reporting just a 9 digit model id instead of 10 digits when viewing model locks.

    Also, the cse api is also reporting the same issue - dropping off the first numeric. (ie model id 2052427376 is reported as 52427376 as the zero is also dropped)

    I checked the DB via sql_developer (and sqlplus) and the model id is reporting correctly(2052427376)

    This is for any model id that has 10 numbers ... 9 and below are reporting back ok.

    Anyone seen this before?

    I have the odbc with the right 'workarounds' for number to float. NLS_LANG is set to AMERICAN_AMERICA.AL32UTF8

     

    thanks for your insights!



  • 2.  Re: CA Gen 8.5 Support Client model lock
    Best Answer

    Posted 10-19-2017 08:18 PM

    Hi Aldred,

    I just tested on my 8.6 Windows/Oracle 12c CSE after manually updating the model id to have 10 digits i.e. 1234567890 

    When I check the Locks during a checkout using the Detail option I see the same symptoms as you reported i.e. the model id loses the first digit and is visible as 234567890

    I suspect this has not been discovered before because it needs a relatively obscure combination of 10 digit model id and either views lock details or using the CSE API.  Also it is only impacting reporting and not the actual stored data.

    The MODEL_ID column in the  DMDL table is defined as NUMBER(10) so it looks like there is some incompatibility with the CSE Client & API being able to handle the final 10th digit. I am think it is possibly something related to the database version/properties.

    Could this problem have existed on your Windows Oracle 12c DB prior to moving it to UNIX and you did not notice it? Did you just export/import the DB ?

    Please raise a support case and we will investigate it further.

     

    Thanks

     

    Lynn



  • 3.  Re: CA Gen 8.5 Support Client model lock

    Posted 10-20-2017 12:47 AM

    thanks for the check Lynn ... I'll raise a support case.



  • 4.  Re: CA Gen 8.5 Support Client model lock

    Posted 10-22-2017 10:49 PM

    Thanks Aldred

    During further testing I also recreated with 8.6 SQL Server CSE, so root cause appears to be DB/DB platform independent.

    So am I thinking this problem may have always existed but previously went unnoticed. I have now passed on to Engineering via your support case.



  • 5.  Re: CA Gen 8.5 Support Client model lock

    Posted 10-23-2017 05:32 PM

    .... and after checking the docops all the CSE API functions reference model id (nModelId) with value 9 so that would also explain the behaviour with the API e.g.

    https://docops.ca.com/ca-gen/8-6/en/reference/encyclopedia-api-reference/model-information/eapifetchmodelinfo



  • 6.  Re: CA Gen 8.5 Support Client model lock

    Posted 10-25-2017 07:50 PM

    I think value 9 refers to the value passed to the modelId not the length of the variable (so same as 1234567890 in your example).

    in the encyapi.h MODELIDis defined as long, which should have the 10 digit resolution according to the MS Data Type Ranges for VS2010

    (here is defn from encyapi.h)

    typedef long              MODELID;

    So, I guess there is still an issue ...



  • 7.  Re: CA Gen 8.5 Support Client model lock

    Posted 10-25-2017 08:46 PM

    Thanks Aldred - agreed



  • 8.  Re: CA Gen 8.5 Support Client model lock

    Posted 11-21-2017 07:28 PM

    For the benefit of the community:

    • We confirmed that the Support Client Model Locks/Detail has a display problem with 10 digit model ID (UI display problem only). Fixing the problem would require changing the model_id from a long to a double which affects pretty much every module & many external action blocks. Due to the potential downstream effects of making that change and the low impact of this pure display problem it was decided that a fix will be deferred at this time.
    • Further testing by support and Aldred showed no 10 digit limitation/problem with the CSE Ency API.


  • 9.  Re: CA Gen 8.5 Support Client model lock

    Posted 11-21-2017 10:36 PM

    Lynn, do yourself a favour - never, ever look at using a double.  It's a lesson I've learnt the hard way (it'll kill Oracle performance if you write Gen code assuming num 10, fwiw).

     

    If you have to enlarge, look at using a 64-bit int - it's very standard these days.  For C++, it's intN_t where N is 8,16, 32 or 64 (see <cstdint>).  For C, stdint.h.

     

    Having said all that, you still get partial 10 digit numbers already, up to around 2 billion or so (4 if unsigned).  So you could still expand the display mask, and it's what would fit with SQL Server, as that's in the DB as a type of int (see https://docs.microsoft.com/en-us/sql/t-sql/data-types/int-bigint-smallint-and-tinyint-transact-sql).  Given that, you have a bigger problem if you want to expand beyond 2 billion, as you'd have to change the data structure on the CSE for SQL Server by making it a bigint or similar, and it does assume signed.



  • 10.  Re: CA Gen 8.5 Support Client model lock

    Posted 11-22-2017 01:30 PM

    Am I missing something? A model id can only be in the range 2^31 which can be accommodated in a 32 bit int (and 10 digits, i.e. 2,147,483,648). The issue is purely display, so is this not just a case of needing to ensure that the displayed data in the support client outputs all 10 possible digits rather than 9. It wouldn't have thought it would need a double or long int. If the display is in a Gen GUI client (I think the support client is a Gen application), then the change would be isolated to adding a separate view in the client to display the data which will be passed into the client as an int and then moved to a view of 10 digits. You will need to use a numeric attribute of length 10 (which becomes a C double) since Gen C code will not allow you to use another data type.

     

    However, that said, there are probably higher priority fixes and enhancements to work on...