cancel
Showing results for 
Search instead for 
Did you mean: 

Does anyone have script or fast method to add transp. to que?

MPGraziano
Participant
0 Kudos

I have isolated a server for a GoLive Rehearsal and would like to load MANY transports into this new server, rather than load them all one by one (ie. add to que, then transport) , does anyone know of a quicker way to do the WHOLE lot at once?

Thanks in advance for saving me time

Maria

Accepted Solutions (1)

Accepted Solutions (1)

markus_doehr2
Active Contributor
0 Kudos

I'd write a small script (I do that for our TDMS systems too). This depends on the OS you use. On Unix system I have a file with all the transport to be imported and do something like

for transport in `cat transport.lst` do
   tp addtobuffer <SID> $transport pf=<transportprofile>
   tp import <SID> $transport pf=<transportprofile> u1
done

Markus

MPGraziano
Participant
0 Kudos

Thanks Markus

I will have to transport them individually for now... unless the project team indicates they are ok with mass transport

We are trying to verify the transport log order and quality of each transport.

I guess you are not familiar with Windows & SQL

maria

markus_doehr2
Active Contributor
0 Kudos

> I will have to transport them individually for now... unless the project team indicates they are ok with mass transport

> We are trying to verify the transport log order and quality of each transport.

You could check that via transport history in STMS or write the output to a logfile and parse that.

> I guess you are not familiar with Windows & SQL

Well - for Windows system I haven't done such a script but the syntax is likewise, such as

FOR /F %%transport  IN (transports.lst) DO tp addtobuffer... %%transport

Markus

markus_doehr2
Active Contributor
0 Kudos

Another method is creating a batch file with all the transports for Windows:

#!/bin/bash
#
# build cmd script for import on Windows
#
# 10.03.2009
#
#
SCRIPTFILE=import_all.cmd
TARGETSYSTEM=S13
FILESYSTEMLETTER=d
TRANSDIR=$FILESYSTEMLETTER\:\\usr\\sap\\\\trans\\\\bin\\TP_DOMAIN_$TARGETSYSTEM.PFL

for tp in `cat transports`
do
        echo "tp addtobuffer T01K$tp $TARGETSYSTEM pf=$TRANSDIR"
        echo "tp import T01K$tp $TARGETSYSTEM pf=$TRANSDIR"
done

The output looks like

tp addtobuffer T01K938381 S13 pf=d:\usr\sap\\trans\\bin\TP_DOMAIN_S13.PFL
tp import T01K938381 S13 pf=d:\usr\sap\\trans\\bin\TP_DOMAIN_S13.PFL
tp addtobuffer T01K938821 S13 pf=d:\usr\sap\\trans\\bin\TP_DOMAIN_S13.PFL
tp import T01K938821 S13 pf=d:\usr\sap\\trans\\bin\TP_DOMAIN_S13.PFL

Markus

MPGraziano
Participant
0 Kudos

Markus or Nico

the tp addtobuffer command I never used and trying it out in command line, but I think I'm missing params cause I am trying it and errors return that missing params

for me SID= ECP and Trans Dir would be d:\usr\sap\transcopy

so to run it interactively (when I get it right I'll put it in a script)

tp addtobuffer ECDK900724 ECP CLNT=200 pf=d:\usr\sap\transcopy\TP_DOMAIN_ECP.PFL

then I get the error SAPEVTPATH not set... I thought that was taken care of in the pf param

trans

btw I am sitting at the transport directory c:\urs\sap\transcopy

and I get the ERROR in d:\usr\sap\transcopy\TP_DOMAIN_ECP.PFL ?

m.

former_member66264
Contributor
0 Kudos

run it from

d:\usr\sap\transcopy\bin

( should contain data)

MPGraziano
Participant
0 Kudos

nope same error ... something to do with the clnt param , the param being too long

ERROR: :parameter CLNT=200 has wrong length

Edited by: Maria Graziano on Nov 17, 2009 3:05 PM

former_member66264
Contributor
0 Kudos

sorry its client200

( no space between client and 200)

MPGraziano
Participant
0 Kudos

Nico... I'm going nuts here...

is it clnt200 or client200 or clnt=200 or client=200?

Former Member
0 Kudos

Imho you may specify a client later on for import, but not for addtobuffer.

hope this helps

former_member66264
Contributor
0 Kudos

Sorry: as in last post:

client200

former_member66264
Contributor
0 Kudos

you are right, but then it goes to 000 and you still have to change the client afterwards.

MPGraziano
Participant
0 Kudos

Thanks Nico..

just putting the script together and I think I'm there...

you guys are great!

maria

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

This is how I do more than 20 transports if I have to re-import into the QA system.

I'll use DEV as the source system sid and QAS as the target system sid

I create 2 txt file from Excel, 1 for adding to the buffer one for importing:

addtobuffer file

tp addtobuffer DEVK900001 QAS pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

tp addtobuffer DEVK900002 QAS pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

tp addtobuffer DEVK900003 QAS pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

" " "

tp addtobuffer DEVK900020 QAS pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

Import file

tp import DEVK900001 QAS client900 U126 pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

tp import DEVK900002 QAS client900 U126 pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

tp import DEVK900003 QAS client900 U126 pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

" " "

tp import DEVK900020 QAS client900 U126 pf=e:\usr\sap\trans\bin\TP_DOMAIN_QAS.PFL

I log onto the server with the <sid>adm user and save these 2 files as .bat files in the run folder on the targte system, (where the tp.exe file is).

Then I open a command prompt and drag the add to buffer.bat file into the cmd screen and press enter. (You should check transaction STMS to make sure all of the transports have been added to the Target Queue. You might have to re-set the target

client.)

Then I drag the import.bat file into the cmd screen and press enter.

I've also used variants of this by writing the outputs to a log or even pausing the imports every 10 or so to review, etc.

Ken

MPGraziano
Participant
0 Kudos

wow, that's awesome Ken, could have used your details yesterday.

I wrote the exact same script, from a list of over 2000 transports in an excel spreadsheet.

wrote a script/macro to concatenate the transports with the verbiage for the addtobuffer

I then used this script in cmd prompt. Mistake I made is that I should have created a log file to capture

the transports that did not get added for whatever reason, I just saw them scroll up the cmd screen (shoot!)

as for the auto import, my clients would will prefer a one to one add as we have to feeback issues and stop and wait to go on for any corrections

This is our first run thru the transport log of the configurations required for our PeopleSoft to SAP HCM migration project

BUT, I may recommend a auto run from a script after we've verified the transports (log) on this rehearsal server

Maria

MPGraziano
Participant
0 Kudos

Hey Ken

How do I add the parameters ? like in stms we have execution mode and opetions

How do I add those options? or is it necessary when we run in background

maria

former_member66264
Contributor
0 Kudos

Hi Maria,

that's done via the u-modes.

http://help.sap.com/saphelp_nw04/helpdata/en/3d/ad5b814ebc11d182bf0000e829fbfe/frameset.htm

Hope this helps !

Rgds

Nico

MPGraziano
Participant
0 Kudos

Yes thank you, I will try it out

Maria

MPGraziano
Participant
0 Kudos

Nico,

will the transports also generate logs? as they would when we transport using STMS?

and if a transport errors using the TP command in a script I would assume the script will continue to the next transport?

However IF there are dependencies how do you stop?

maria

former_member66264
Contributor
0 Kudos

Yes,

1)you will be able to see the logs as normal.

2)

a)you could program a RC check in the script : continue Yes/no?

b)ctrl-c would also stop the cmd or bat script

c)you could start the import from stms itself as soon as you executed the addtobuffer script

as soon as you have done the addtobuffer script , the tp's should be visible in stms, you can import ( with import all) in your testbox , just like you would do in production.

I would go for option C, less posibility on errros.

PS: only work via stms if you have executed the SE06 and created a single system domain controller, if not you could touch your production system!

MPGraziano
Participant
0 Kudos

This server is outside of the transport domain, with independant transports and domain, so I don't beleive that any harm should come to the transport domain (DEV< QAS< PRDN)

I have called it ECP just ... becuz..

The RC check would check for errors and I can control if I want to continue? (I am running this on windows 2003)

I have never done a transport all? and I think would prefer to do the tptransport in the script doingmaybe 100 transports at a time. by doing transport all, can I control the number of transports in a que (kinda like controlling the que when doing support packages)?

You're making me have second thoughts about doing the transports in the backend. This server is a rehearsal server, different IP address and server name, only the instance is the same and is not connected to the DEV transport domain the only similarity i that the instance name is same as the production server.

former_member66264
Contributor
0 Kudos

I would really consider the "import all" option:

also take a look at these notes:

Note 139513 - Merge transports for high availability systems

Note 1223360 - Composite SAP Note: Performance optimization during import

the less transports, the faster the import, for 2000 tp's... it can make a difference. Normally import all will give less errors.

also less coding needed , after the addtobuffer , just execute:

tp import ALL ECP

Rgds

Nico

MPGraziano
Participant
0 Kudos

it sounds like to do the transport ALL.... and TO ENSURE sequence of transports , the transports should be added EXACTLY in the sequence that they need to be transported (with the addtobuffer)

Correct?

otherwise, I would have to transport them with a script that would transport in the sequence I require. I do have 2-3 days to do the 2000 transports.

I am using this time on the Rehearsal Server to calculate the time required to do them thru a script, and perfect the script. Once we get to production, I cannot do a transport ALL , as there will be other transports that have already been transported and we want to eliminate those, we want to ONLY transport the NEW configuration for HCM (migration of Peoplesoft time & labour, and Payroll to SAP)

Maria

Former Member
0 Kudos

Hi,

From SAP if you start the import all option the transports will never be imported in the sequence. If

consider these as well when performing mass transports.

1. Do the transports need to be imported in a sequence.

2. What if there are any dependencies.

3. If one transport ends with error (RC=8). Can i proceed with importing the rest.

Thanks

Arun

Former Member
0 Kudos

---

Edited by: Arunbharani Ramlingam on Dec 22, 2009 1:32 PM

MPGraziano
Participant
0 Kudos

Thank You for you though provoking answer,

However we went thru a painfull excersice to verify the transport log, because these are all the configurations from our staff and consultants for the HCM system to go live

It took over 2 weeks, then we consolidated the comments and verified the results with the teams.

The next task was to restore our GoLive Rehearsal Server pre-transport state, and then do the automated transports via scripts which transported the transports in the order recommended by the teams. The errors and all.

Next task is for the teams to do a high level verification of the system before I do the SuppStack #16 and the HRSPs

Thank You to everyone who contributed to help me evolve my action plan. If you can see any holes, please do advise

Kind Regards,

Maria

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

My appologises. I roled off the previous project and was on Vacation for some time.

I have a copuple of suggestions with that many transports to be imported.

Do you have any logical break points that the Import process can be stopped?

If yes:

1 - Create several scripts with a smaller number of transports in each (possibly 100 or 200 in each script)

2 - Have the team validate their transports to that point and approve before you start the next script,

3 - also if you have time, it might be a good idea to backup the system at some time during the whole process.

Ken

MPGraziano
Participant
0 Kudos

Ken

Thank you, this is a very good suggestion. It maybe that we will have close to 2,000 transports when we go live that will need to be transported to production

For now we will need to test the process on a Rehearsal Server (stand alone).

I am setting up scripts to ADDTOQUE , of about 200 transports at a time.

When I get to do the transports I beleive it maybe a better solution to transport about 200 at a time, because if we miss some that are supposed to go in order then we may have adverse result.

I thought to break it up , I may put a date / time entry that would pause the import, I'm not sure if the continual import of 2000 entries causes a hickup in the process and so may miss some?

Maria

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

I would add all of the 2000 transports into one "Add To Buffer" script. If possible ensure you have all of the data and cofiles for each transport listed on the script in the correct folders before you run it. Then definately check in the STMS Queue to ensure all of the transports are in the Queue before starting the imports.

Yes, it is a bit time consuming, but absolutely worth it if one or two don't make it into the Queue for any reason.

The importing of the transports is where you want to be careful. I have run into problems when importing large numbers of transports in one script before. The good thing about doing the imports with a script is that (in theory at least) the first import completes before the next starts. Unlike the "Transport All" button in STMS where you may run into problems with that many.

If you haven't gone through a complete "Import" rehearsal yet, I would maybe cut the import scripts down to 50 - 100 transports at a time. What I have done in the past is to create a "Master Import" spreadsheet including the command lines, copying 50 lines at a time into seperate .txt files, sequentially labeling them (i.e. import1.txt, import2.txt, import3.txt, etc). Also the extra time spent having some one else check to ensure all of the transports are accounted for is well worth the extra effort.

After each "Import" script run, I would check to ensure they were successfully imported through the STMS history (or at least they were imported with the same return code as a previous import test run, understanding that if one had a return code of 8 before, that the fix might be imported in a subsequent transport).

I will take you a little bit longer to organize 20 or 40 import scripts and run them separately, but if something does go wrong it will be a lot easier to recover. Considering you'd have to delete them out of the Queue, add that group to the buffer again and run the same (or adjust) script again.

Good luck and run as many trial runs as you can.

Ken

MPGraziano
Participant
0 Kudos

Ken , many, many thanks!

I have actually broken down the import scripts to about 5 with about 200 entries each.

I do find that about a dozen entires have errored with parameter has wrong length, the odd thing is all the TPIMPORT statements were created from the same Excell macro. ie., the transports were sequentially entered in an excell spreadsheet to ensure the correct sequence

I then created a macro (as recommended from this thread) that created a large script for import

I took this one step further and split this large file into smaller files/scripts of about 200 entries.

I have only run the first of 5 entries, and it is puzzling to me why I get the error 'parameter has wrong length' the statements are cookie cutter statements, exactly the same. see error below

E:\SAP Software\SAPPHYR Transport Log\TPImport Scripts>tp import ECDK901251 ECP client=200 U126 pf=d:\usr\sap\transcopy\bin\TP_DOMAIN_ECP.PFL

This is tp version 372.04.40 (release 700, unicode enabled)

ERROR: : parameter U126 has wrong length

And a successfully statement result below

E:\SAP Software\SAPPHYR Transport Log\TPImport Scripts>tp import ECDK900229 ECP client=200 U126 pf=d:\usr\sap\transcopy\bin\TP_DOMAIN_ECP.PFL

This is tp version 372.04.40 (release 700, unicode enabled)

This is R3trans.exe version 6.14 (release 700 - 28.07.08 - 15:52:00).

unicode enabled version

R3trans.exe finished (0004).

tp finished with return code: 4

meaning:

A tool used by tp produced warnings

You can observe the statements are identical starting at "tp import ECDKxxxxx ECP etc...

any ideas why they would error?

Regards,

Maria

MPGraziano
Participant
0 Kudos

Ken OR anyone

I think I could resolve my problems from my previous posting with errors IF you or someone could provide a command that would check the results of the TPIMPORT for error codes other than 0 or 4...

This way I can stop the script and verify with the ABAP'er for instructions to continue.

For the IMPORTs that failed completly, that DID NOT get imported AS WELL I want to stop the script for me to investigate and possibly do the transport manually AND then go back to continue the script for automated imports

This is the only way I can guarantee doing the whole list of 2000 transports without getting any of the transports out of order.

Any advice would definitely be appreciated!!!

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

I've never been able to find a command that would stop the import if the return code is greater than 4. But I have used the "pause" command after every 5 import lines or so in the script. This stops the process and you have to manually press the enter key to move to the next command line on the script. But this does create a lot of baby sitting during the process. You might want to use it during the test runs you're doing and then take it out for the "Go Live" run once you have all the Bugs worked out.

I've never encountered your error about the parameter U126 being to long before. Is it possible there's an extra space (or other character) after some of the U126's? You mentioned that you created a macro to create the command lines, might be something in there.

The way I've created the command lines before was to type tp import in the first cell of an excel spreadsheet, then in the second column I'd copy the list of transports to be imported and in the third cell I would type the rest of the import command line. Then I copy and paste the "tp import" into all of the cells required of the first column, as well as the third cell into all of the cells in the third column. That way any mistake or typo would effect all of the commands not just random ones. Although I have had problems before where some of the transport numbers in the original list had a space after them and that would cause errors when being transported.

Ken

MPGraziano
Participant
0 Kudos

Hey Ken,

Good experience . I really like your suggestions on how you put together your scripts. And you are correct in that it maybe extra characters that maybe causing my problems with some of my errors

However as for the identifying of errors in the script, unfortunately we don't have alot of time to test it out. AND when I run the transport and there is an error the script MUST stop so that we can decide how to proceed. If we don't stop and the transports get out of sequence there would be issues with the configuration that is being transported.

Do you know a way rolling back the transport? other than for me to do a restore back to baseline before transport (because this is what I have to do to test out every new plan that I come up with)

The sequence of transports is very very important. I am working on a script that will write a file and then parse for the error code I expect or not expect. This should be fairly quick as this file would be temporary and just get dropped as soon as the parsing is done.

so it would go something like this

TP stmt,,,,,,,,,, > write out to temp file

parse temp file for error code and make decisision to stop or go

delete temp file

TP stmt,,,,,,,,,, > write out to temp file

parse temp file for error code and make decisision to stop or go

delete temp file

TP stmt,,,,,,,,,, > write out to temp file

parse temp file for error code and make decisision to stop or go

delete temp file

etc,,,

This way we remove any likelihood of manual errors, and it would definitely go much quicker.

Not sure if you've done this way, or if anyone with cmd line experience has done it this way as well

Maria

ken_halvorsen2
Active Participant
0 Kudos

Interesting, I've never used your "write to temp file parse temp file" command before, let me know how it works.

I just noticed one other thing. In you command line (E:\SAP Software\SAPPHYR Transport Log\TPImport Scripts>tp import ECDK900229 ECP client=200 U126 pf=d:\usr\sap\transcopy\bin\TP_DOMAIN_ECP.PFL) you have "client=200", it might be the same, but I've always just used "client200". No "=" sign. It's possible there's a space \ extra character after the client and before the U126 that is causing the problem.

No there is NO way to "roll back" a transport. The only way would be for the developer to create another transport with the previous version in it and transport that in.

MPGraziano
Participant
0 Kudos

Well the command is not exactly write to temp and parse temp file, this was just the explaination

re: tp command , all the statements are client=200, and they work fine.

But, I will try your method as well client200

I did'nt think there was any way to rollbak transports, but I was hoping I missed something

thanks

MPGraziano
Participant
0 Kudos

Ken OR Anyone else,

I've been trying to find the options for the "tp addtobuffer" that will add a transport to the import que with the status to import again.

We can do this thru the GUI in stms by extras >> other requests >> add

typing in the Transport number then check off the option to transport again?

thanks,

Maria

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

It's actually in the tp import phase that you can do that. It's one of the options that you put in after the "U" for example U126.

I found this link of what each means on the internet. http://www.sap-img.com/basis/meaning-behind-those-unconditional-tp-command-mode.htm

If up wanted you could test it out by creating an empty transport and using STMS import it into one of you systems with only that option selected. After it's been imported take a look at the history and it should show you the option number somewhere.

Hope that helps

Ken

MPGraziano
Participant
0 Kudos

Ken

I am using the options on the tp import, but if I don't use these same options in the addtobuffer (because this server is a copy of production) retains the information of the transport queue

I'm not sure how to change that other than adding to the queue manually and selecting the option for re-import. I was hoping there was an option on the automatic tp addtobuffer that would do the same

maria

ken_halvorsen2
Active Participant
0 Kudos

Hi Maria

I'm a little confussed about yoru concern here.

In the STMS you can delete all of the "Already Imported" transports from the Queue, and then use the Add to Buffer script to add them back again, ready for re-import.

Ken

MPGraziano
Participant
0 Kudos

Ok... that was easy

Thanks!

Answers (2)

Answers (2)

MPGraziano
Participant
0 Kudos

Issues resolved, thank you so much for ALL your inputs

former_member66264
Contributor
0 Kudos

i think already i gave some explaination on this one:

if you have access to TP command on os level , a simple excel can help

look at the help here: http://help.sap.com/saphelp_nw70ehp1/helpdata/en/3d/ad5b744ebc11d182bf0000e829fbfe/frameset.htm

then create an excel:

A B C D

tp addtobuffer TPNR CLNT=xxx? SID CLNT=100 pf=/usr/sap/trans/bin/TP_DOMAIN_QE1.PFL

concatentate all in 1 cel and save this file as txt file

check content , should look like:

tp addtobuffer BLABLALBA1.SID SID CLNT=100 pf=/usr/sap/trans/bin/TP_DOMAIN_QE1.PFL

tp addtobuffer BLABLALBA2.SID SID CLNT=100 pf=/usr/sap/trans/bin/TP_DOMAIN_QE1.PFL

tp addtobuffer BLABLALBA3.SID SID CLNT=100 pf=/usr/sap/trans/bin/TP_DOMAIN_QE1.PFL

copy past these commands in cdt /( usr/sap/trans/bin)

SMTS Q should now be filled with these transports

normally you don't need the u mode

here is an example for unix, but it might be usefull on Wintel also:

http://www.unix.com/shell-programming-scripting/66222-shell-scripting-bulk-transports-unix.html

MPGraziano
Participant
0 Kudos

Nico

modified my tp addtobuffer command, now complains about the clnt param being too long?

tp addtobuffer ECDK900778.ECP CLNT=200 pf=d:\usr\sap\transcopy\bin\TP_DOMAIN_ECP.PFL

Edited by: Maria Graziano on Nov 17, 2009 2:59 PM