This hasn't impacted me yet, but I think BMC created a lot of this mess by having CMDB = Asset Management for so long and now splitting it out further. Based on what you've said, it will be interesting to me as well to see what happens with ADDM because we're discovering the location based on part of the hostname and sending that through ADDM's integration with Atrium. Either way, we come up with a lot of smart ways to track asset data on computer systems that we would like to pass through Atrium Integrator or whatever tool to eventually synchronize with our CIs even though it's technically Asset Management data. Fortunately we aren't using our CMDB heavily yet so it won't impact my organization like it has Jesus's, but it seems like it would be helpful for BMC to provide a migration path for things like this.
Thanks, Shawn Pierson Remedy Developer | Energy Transfer -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of RainingRemedy Sent: Friday, January 17, 2014 1:07 AM To: [email protected] Subject: Re: CMDB 8.1 Status bug? Jesus, This is not considered a bug. The AssetLifeCycle status field has been effectively moved from the CMDB forms and placed on the AST:Attributes form. The Status field you see is just the leftover core field that is not being used. From what I've read, I don't think there is any plan to use that field in the future. Would be curious to see what BMC says about it. The whole point of the CMDB and Asset split was to separate the configuration(discovery) of CIs with the lifecycle managing (Asset Mgmt) of the CI. That is why they reconstructed all of the joins and now all the classes are joined with the AST:Attributes form. This is the form where all lifecycle managed attributes will be stored. These are typically non-discovered attributes like financial info, location info, status, etc. The CMDB forms are now in theory supposed to only be tracking what is discovered, or the configuration of a CI. The configuration may change several times during the lifecycle of the CI however, the actual lifecycle attributes can remain the same. This is the vision BMC had when they split the attributes up. Config data in one spot, lifecycle management data in another spot. As far as your current scenario is concerned, why do you need to use the status field as the trigger to promote the data into the production dataset? Would it be possible to bring in the data as you do now, allow the asset admins to modify the data as you stated, and then when they are finished the admins could set a custom attribute to "Ready for Import" for example? Then during the Identify and Merge job you could just set the Status field of these CIs to Constant "In Inventory" as stated in your process? Not sure if something like this would work in your case without knowing more info about your integration and process. Just trying to throw an idea out there as a work around. -- View this message in context: http://ars-action-request-system.1093659.n2.nabble.com/CMDB-8-1-Status-bug-tp7594610p7594641.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
