Good Day Akshay
What do you think, should be a stickler approach? I don't have any limitations/constraints on this!
For sure you can reorganize the PSAPSR3702X to PSAPSR3702 and drop PSAPSR3702 if you know how to proceed with that.
Two more curious queries:
1) If I intend to keep PSAPSR3702X and drop PSAPSR3702 and do a second upgrade via SUM, it will required another tablespace? Or is it possible that if I extend my tablespace big enough, to upgrade the system it will work? What is the reality check here? How does this work? i.e. To have a new tablespace and upgrade the system in there and then switch over?
If you do an upgrade to the SAP components within the same release/EHP the tablespace will have the same name but with a different extension, maybe somthing like PSAPSR3702X1.
Check this link for SAP tablespace naming conventions:
http://help.sap.com/saphelp_nw70/helpdata/en/9f/4a56b2185851468b39b719daa2d3aa/content.htm
2) What do you think of the SUM directory, its around 20GB and contains the DVEBMGS02 (Shadow Instance) mainly. Complete SUM directory can be dropped, without any consideration, if the upgrade has happened successfully?
The shadow instance has no relevance once the downtime has been completed.
During the downtime phase the system does a switch of the shadow instance to the main instance with the new kernel and that is the reason why the SUM tool prompts you to back up the database, the upgrade directory and the old kernel before you proceed with the downtime phase.
If the upgrade has been completed the you may finalize the steps in the SUM tool and then complete all the post upgrade activities and remove the upgrade activity.
Regards
RB