SPAM Update failed and now transaction wont run

[Former Member]

hi.

SCM 5.0 did the spam update 700 #39 and it bombed half way through. I have run this same spam update in dev and QA plus the ECC and BI environments.

It appears not all the programs got updated and the transaction has programs that have syntax errors. I cannot get into spam or saint to rerun the update or do anything.

Is there a way to run the SPAM update from the unix level? Or any other ideas to fix this problem? I am pretty sure it is more then one program that is out of whack and gets the syntax error.

thanks

brad

[volker_borowski2 · Accepted solution]

Humm,

sounds ugly. I am sure something can be done about this.

It strongly depends on where the abort took place.

If it was in MAIN Import, something can be done on OS level.

I had that once. I do not remember exactly, but it was like just repeating the

main import step (and ONLY this one). Was like "tp r3i ..." and some additional settings in

transport profile aka tpparam. After that, SPAM was restartable.

But again it depends on what exacly your error was like.

I'd strongly recommend to log a call.

Volker

[Former Member]

First question;

Did you follow the standard pre-requisites?

Regards,

Nick Loy

[Former Member]

In general SPAM updates I run in dev and it they work I just run them everywhere. Cant spend my life reading SAP notes.This SPAM update worked in 7 instances and only failed on this one. The message was that it reached unexpected eof.

[Former Member]

SAP finally connected and solved the problem. As mentioned above ran R3trans from unix and then I finished the import in SPAM.

Commands that were run were similiar to below. Not sure if only the last one actually worked or not.

tp R3I all SCP pf=/usr/sap/trans/bin/TP_DOMAIN_SCD.PFL tag=spam -Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

tp showbuffer SCP pf=/usr/sap/trans/bin/TP_DOMAIN_SCD.PFL tag=spam

tp R3I SAPKD70039 SCP pf=/usr/sap/trans/bin/TP_DOMAIN_SCD.PFL tag=spam -Dclientcascade=yes -Dstoponerror=8 -Drepeatonerror=8 -Dsourcesystems= -Dtransdir=/usr/sap/trans

thanks for the general comments.

[Former Member]

Hello,

it is possible to import the SPAM transport request manually on OS level via tp addtobuffer - and tp import - so you have to find out the SPAM transport request number and have to import this on OS.

Please be sure to have a present backup of your system -

When having errors with /usr/sap/trans/tmp/<SID>.LOB massages in your SLOG like that for example:

WARNING: /usr/sap/trans/tmp/E10.LOB is already in use (2660),

then delete those <SID>.LOB entries in your /usr/sap/trans/tmp and repeat it.

Finally you have to start Transaction SPAM again and have to finish implementation as usual from the status you will see at the moment -

Afterward your SPAM Queue should be green again -

good luck

peter

[Former Member]

Hi Peter

This sounds very feasible and I will try tonight after another backup and the users are off the system. I found the transport number KD70039.SAP and this should be it for spam update number 39.

thanks

brad

[former_member204746]

1. take a backup before attempting TP command at Os level

2. add "tag=spam" in yourr TP addtobuffer and tp import commands.

3. you should get a n official statement from SAP. If you try these on your own, you will have problems with SAP support.

good luck.

[Former Member]

SAP support insisted i update the kernel before he (and only him) will import the SAPK900039 as suggested above. I updated the kernel in prod last friday night, but he still has not run this for me. The support on this ticket has been lacking to say the least.

So now i still get dumps everyday, but in general the system is running okay. It would be nice to get this resolved but I dont want to overide SAP support.

thanks

[Former Member]

Escalate the message since it is your Production System.

You can follow Note 90835 - SAP Message Escalation Procedure

Thanks,

Naveed

[former_member204746]

you can hardly escalate this message because your production system is not in jeopardy... is this affecting a go-live or upgrade project? this is also another good reason to escalate.

Read the note supplied by Naveed for more info.

[Former Member]

Yes cant escalate I did call and they did it for me but once online its hard to lie. The system is running.

With the high i did get the initial response, but sporadic since then. He has just got back to me, but as luck will have it our saprouttab was not set up to allow telnet access to this box, so i had to just fix this (i hope) and have let them know. So hopefully i dont have to wait another 2 or 3 days for a response.

thanks

[Former Member]

Do you have a good backup pre patching?

[Former Member]

A restore is not something I will be doing. Remember these are the non Intrusive spam update as SAP says. It is just a matter of updating the right programs and includes which is easier said then done. I have a ticket open with SAP since friday, but no response yet. The SCM system is working okay and just gets the occasional dump when some basis type batch jobs run, but it must be resolved.