Skip to Content

Support pack Modification Adjust Transport  warning “Transport does not fit or Internal Error : This request not marked as modification request”

I would like to share my recent experience with SPAM Modification Transport on the DEV system.  When we were going thru SPAM steps (display define queue, Target Package Selection), in the target package selection, some of the component did not appear.  This is obvious because we need to use SAINT in order to perform the delta upgrade and the new release level support packages. 


Modification transport different release leavel.GIF

So after completing the SPAM including SPAU/SPDD transport, we performed the SAINT steps,  in the Support Package Selection screen, one of my colleagues forgot to select the latest Support Package Selection from the drop down and continue. So, when SAINT finished, it did not upgrade that particular component to the latest release level because of wrong selection in the Support Package Selection screen.

Modification transport SAINT different release leavel.GIF

Since SAINT can only be used for Add-on, delta upgrade, and the new release level.  We had to perform SPAM steps again to upgrade that particular component to the latest release level that was missed in SAINT.  Finally we finished the SPAM and that component updated to the new release level.  Also, in this second step of SPAM, it did not prompt to create Modification adjust transport, because SPAU/SPDD was cleaned up in the first SAPM steps.

Mistake made:

So after performing the SPAM, SAINT and SPAM, we released the Modification Adjustment Transport and here we made mistake.  The released transport took the snapshot of the source release level, so in the subsequent system, you get warning Transport does not fit or  Internal Error : This request not marked as modification request  when you try add Modification Adjustment Transport in QAS, PRD.  We continued SPAM with that warning and when it prompts to Call SPAU/SPDD,  click on call SPAU/SPDD and confirm SPAU/SPDD without making any changes and finally when SPAM finished, confirmed the SPAM Queue.  After confirming the SPAM queue, we manually imported the Modification Adjust transport, when you import click on options tab and tick all check boxes for  Ignore then proceed with the import process.  Go back to SPAU/SPDD and you should see everything clean and looks similar to DEV system.

Modification transport ignore check.GIF

So what we learned with the above experience is to immediately release the SPAM Modification Adjustment transport after confirming the SPAM queue and before starting SAINT.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Rajarshi Chatterjee

    Nayeem, thanks for sharing the information. There’s a level of honesty in the way you share your experiences and we after going through them only become more enriched. I’ll look forward for more of your posts as I learn things. One question – when you say,

    ” The released transport took the snapshot of the source release level, so in the subsequent system, you get warning Transport does not fit or  Internal Error : This request not marked as modification request

    can you explain more about the snapshot of the source release level; is it for the normal support packages that we upgrade from SPAM or for the add-ons (applied via SAINT)

    (0) 
    1. Nayeem Adil Post author

      Hi Rajarshi

      Just want to give you brief overview of this project.

      Note: We did the second SPAM step only in DEV system because of the wrong selection of the release level and we did not perform the second SPAM step on QAS and PRD.

      The support pack and patches were downloaded thru Maintenance Optimizer (MOPZ)

      Yes this is normal support pack and we used SPAM/SAINT to performed the upgrade.  As I mentioned in the document, SAINT is used  to perform the delta upgrade (ST-PI, ST-A/PI) and the new release level for example (BI_CCONT 736 to 737). Since we selected the correct release  and wrong patch level, the released level was upgrade thru SAINT based on selection but not the patch level. We had to use SPAM again to upgrade to BI_CONT patch level (004 to 008)

      When we did the support pack uggrade on QAS/PRD, we selected the correct release level, so we did not have to perform the second SPAM step.

      As you may are aware the Modification Adjustment Transport in created on the Dev system so that you don’t have to perform the SPAU/SPDD activities on QAS and PRD.

      When we tried to assign the Modification Transport on QAS/PRD systems, we got that error(Internal Error : This request not marked as modification request)  due to SPAU/SPDD transport was not released on DEV after completing the first SPAM so it captured the snapshot of source level and on the target system (QAS, PRD) it was different level because we selected the correct patch level.

      Please let me know if you have any more questions or concern.bi cont.GIF

      (0) 

Leave a Reply