Topic
  • 11 replies
  • Latest Post - ‏2013-11-07T21:11:42Z by TonyLlopis
TonyLlopis
TonyLlopis
59 Posts

Pinned topic Why RAA does not capture the real hash for the aes* files

‏2013-10-06T20:22:48Z |

It seems that if the file(s) was to change there is no way to detect its change via based on hash

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-07T15:25:11Z  

    I do not understand the question...

  • TonyLlopis
    TonyLlopis
    59 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-07T16:46:50Z  
    • jcdelmo
    • ‏2013-10-07T15:25:11Z

    I do not understand the question...

    They have hash_id =0 and does not seem to be a coincidence because I have just changed a character in one of them and rescanning did not change the hash_id.    Can you query on your system  

    select * from dmh.dmh_file where hash_id = 0

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T15:43:40Z  

    They have hash_id =0 and does not seem to be a coincidence because I have just changed a character in one of them and rescanning did not change the hash_id.    Can you query on your system  

    select * from dmh.dmh_file where hash_id = 0

    Yes, I now see the issue -- I will open a work item for it.

  • TonyLlopis
    TonyLlopis
    59 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T15:53:45Z  
    • jcdelmo
    • ‏2013-10-08T15:43:40Z

    Yes, I now see the issue -- I will open a work item for it.

    Is it because there is a somehow custom path for the 'aes* implied auto includes' or would this happen on all unknown includes that are discovered in the file system during the look up for a missing include ?

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T16:28:46Z  

    Is it because there is a somehow custom path for the 'aes* implied auto includes' or would this happen on all unknown includes that are discovered in the file system during the look up for a missing include ?

    The original developer hard coded access to these files in the scanner -- they do not go through normal include handling -- but should!   They did not want to name the files the same as the real include names,  I do not know why (and it has always bothered me).   Perhaps we should rename them, and ship them in a different (non ../data ../bin) directory.   I'll have to think about it.  

    Normally, these files should not be accessed, as the client should provide their production versions of the required files.  They are included in this fashion as some clients wanted IBM to deliver copybooks from products it sells.

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T16:29:25Z  

    Is it because there is a somehow custom path for the 'aes* implied auto includes' or would this happen on all unknown includes that are discovered in the file system during the look up for a missing include ?

    Now you got me started...   Sorry...

  • TonyLlopis
    TonyLlopis
    59 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T16:38:45Z  
    • jcdelmo
    • ‏2013-10-08T16:29:25Z

    Now you got me started...   Sorry...

    I share your feelings :-)

    Those names have always bothered me, plus I believe the client should be able to provide their own versions.    What if 

    1) The files could be provided with the real product member names in a product directory call some thing like "INCL".

    2) The client could provide their own members in client containers

    3) RAA would only use the RAA provided versions if no client provided version is available.

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-08T16:41:16Z  

    I share your feelings :-)

    Those names have always bothered me, plus I believe the client should be able to provide their own versions.    What if 

    1) The files could be provided with the real product member names in a product directory call some thing like "INCL".

    2) The client could provide their own members in client containers

    3) RAA would only use the RAA provided versions if no client provided version is available.

    Exactly what I have in mind.

  • TonyLlopis
    TonyLlopis
    59 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-10-15T21:55:42Z  
    • jcdelmo
    • ‏2013-10-08T16:41:16Z

    Exactly what I have in mind.

    There is also a frustrating quirk, where RAA injects these aes* parts in container

    C:/PROGRA~2/IBM/RATION~4/bin 

    but when a request to rescan the container is made within this container, or from the wizard, it creates a totally different container under

    C:/Program Files (x86)/ibm/Rational Asset Analyzer/bin

    This makes impossible to rescan the parts to force computing the hash in place.

     

     

  • jcdelmo
    jcdelmo
    365 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-11-06T19:20:46Z  

    There is also a frustrating quirk, where RAA injects these aes* parts in container

    C:/PROGRA~2/IBM/RATION~4/bin 

    but when a request to rescan the container is made within this container, or from the wizard, it creates a totally different container under

    C:/Program Files (x86)/ibm/Rational Asset Analyzer/bin

    This makes impossible to rescan the parts to force computing the hash in place.

     

     

    RAA work item 42471 opened for this issue.

  • TonyLlopis
    TonyLlopis
    59 Posts

    Re: Why RAA does not capture the real hash for the aes* files

    ‏2013-11-07T21:11:42Z  
    • jcdelmo
    • ‏2013-11-06T19:20:46Z

    RAA work item 42471 opened for this issue.

    Thank you John.