We are in the middle of a support pack project for our SRM system, and I've run into a snag as I prepare to move them into QAS. We've had this system for many years, and when DEV was originally installed in 2000 it was as a B2B 2.0a system. It was upgraded to 2.0b before GoLive, and the QAS and PRD systems were installed directly as 2.0b systems. The entire landscape has been upgraded several times in the twelve years since, and today it is on release SRM 5.0.
The problem is that the DEV system still shows an installed software component of NDI_ERM (Extended Relationship Management) in release 20A. Obviously that is actually long gone, but it still shows up in SPAM in the Display Package Level function, and under Attribute SAPCOMPONENT in the properties of all transport requests released from this system. It should have been passively deleted during the first (or subsequent) upgrade long ago, but for whatever reason that didn't happen. This software component never existed in QAS or PRD and does not show up in SPAM in those systems.
This hasn't been an issue in the past, and so I've just ignored it as I always had bigger fish to fry. I've performed upgrades and support packages for these systems without an issue, but we hadn't done any of these tasks for the past three years.
I successfully installed support package stack 28 for SRM 5.0 into DEV a few months ago, and I performed the required modification adjustments in SPAU, creating the usual modification adjustment transport. Now, however, when I am trying to import the support packs into QAS, I have a problem when defining the queue, at the step for adding the modification adjustment transport. The transport is marked with a Software Component Vector that includes the defunct ghost NDI_ERM 20A, and NDI_ERM doesn't exist in QAS. SPAM finds the transport, but marks it with a red light ("Transport does not fit"). Drilling into details shows me that everything matches perfectly except for my ghost. On that line I get "The software component is not installed," and SPAM will not allow me to add the transport into the queue.
I should point out that I can import regular transports just fine, and I'm pretty sure I could just import the queue without the modification adjustment transport, and then import it manually when SPAM gets to the step about performing the adjustment. No doubt that would work, and that's almost certainly what I'm going to end up doing. But it bugs me that I can't fix this.
I have some thoughts about fixes that might work, and I'd like input on whether anyone else has dealt with (and solved) this problem before.
I think that I could probably just delete the line in DEV in table CVERS for NDI_ERM and so have it no longer show up in the attributes of future transports. That might solve the problem going forward, though it won't fix the mod adjust transport I've already released. Any thoughts about this?
I was able to get the existing transport to no longer show NDI_ERM in its attributes by deleting the appropriate line in DEV in table E070A. After doing that the transport looked fine in the STMS queue for QAS when drilling into its properties. However, this apparently isn't enough for SPAM. As I had already uploaded the transport in SPAM once, SPAM 'remembers' it and seems to have therefore cached its properties, including the NDI_ERM software component. I haven't been able to figure out how to get SPAM to 'forget' this transport so I could completely upload it anew and hopefully get new attributes that will then match the correct software component vector for the target system. Resetting the queue status doesn't do it.
Any thoughts on where (what tables) SPAM stores information about modification adjustment transports, and how to clear that information out? Any thoughts on the (admittedly drastic) measures I've mentioned above?
Thanks in advance,
Yes, that is certainly true, and I would typically agree with that. However, SRM 5.0 has gone out of mainstream maintenance as of April 1 of this year. I have been working with my employer and account rep to get extended maintenance, and that is finally happening, but the wheels of bureacracy turn slowly and so we still aren't in support as of this moment. Meanwhile, I can't wait; I'm on a tight deadline for this project.
So, I ignored my SPAU transport, imported the queue without it, and then imported the transport when SPAM stopped for modification adjustment. It worked just fine like that, as I knew it would. This means, however, that when I get to production I will need to do things the same way in order to use a tested method. So now any fixes that might be suggested will only be relevant for the next round of support packages or upgrade, which means now I can afford to wait for extended support to kick in.
Nevertheless, I'm still curious to know where SPAM is caching the transport information.
While I never did find a way to clear the attribute cache for 'uploaded' SPAU transports in downstream systems, I did confirm how to eliminate the 'ghost' component from fouling the attributes of future transports. As it turns out, the component had to be deleted from tables CVERS, CVERS_LAN, and CVERS_REF, and the system needed to be restarted to clear out all the buffered/cached information. Deleting it from CVERS was enough for it to no longer show up in SPAM and System Status, but SE10 was still adding it to the transport attributes upon release. I was able to confirm with function module OCS_GET_INSTALLED_COMPS that it was still stuck in a buffer, but not in the underlying tables. I tried resetting the Generic Key buffer, but that wasn't enough. I tried /$SYNC, but that wasn't enough (which really surprised me). A system restart, and double-checking that the information was also up-to-date in SLD and SMSY in Solution Manager, did the trick. It's possible re-syncing the buffers and re-syncing SLD would have been enough without a system restart, but the restart made sure.