Question:
Dear All,
We're on AIX/Oracle 9/SAP 4.70.
I want to clean up our Transport directory but it doesn't do the job with TP Check or Clearold. I've followed Sap Notes 41732 by command:
TP check all pf=TPPARAM (parameter file in /usr/sap/trans/bin)
I've set all lifetime parameters in the parameter.
In the log (CHECK.LOG), it shows the following (i list just some here since it's too big):-
=============================
/usr/sap/trans/tmp/CHECK.LOG
Searching buffer files in buffer directory: /usr/sap/trans/buffer/.
Non buffer file found:
Non buffer file found:
Non buffer file found:
Buffer file found: PRD
Buffer file found: DEV
Non buffer file found:
Collected 2 Systemnames from [/usr/sap/trans/buffer/.]
Collecting transport requests from
New transport request DEVK904840 found in PRD
New transport request DEVK904800 found in PRD
New transport request DEVK904897 found in PRD
New transport request DEVK904903 found in PRD
New transport request DEVK904919 found in PRD
Collected 01512 out of 01512 entries from buffer PRD.
Collecting transport requests from DEV
New transport request DEVK900629 found in DEV
New transport request DEVK900631 found in DEV
New transport request DEVK900603 found in DEV
New transport request DEVK900625 found in DEV
New transport request DEVK901546 found in DEV
Transport request DEVK901408 found in DEV was already found before
New transport request PRDK900051 found in DEV
Collected 00006 out of 00007 entries from buffer DEV.
Found 01518 transport requests from buffers
Reading files from directory: /usr/sap/trans/cofiles
found file: K904804.DEV
found file: K904808.DEV
found file: K904794.DEV
found file: K904818.DEV
found file: K904790.DEV
Collected 1518 filenames from [/usr/sap/trans/cofiles/.]
K904790.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
K904818.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
K904794.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
K904808.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
K904804.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
Found 0 invalid filenames on Cofile-directory
Reading files from directory: /usr/sap/trans/cofiles/BaCkUp
could not open directory /usr/sap/trans/cofiles/BaCkUp
Reading files from directory: /usr/sap/trans/data/.
found file: R904804.DEV
found file: R904808.DEV
found file: R904794.DEV
found file: R904818.DEV
found file: R904790.DEV
Collected 1095 filenames from [/usr/sap/trans/data/.]
R904790.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
R904818.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
R904794.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
R904808.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
R904804.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
Found 0 invalid filenames on Datafile-directory
Reading files from directory: /usr/sap/trans/data/BaCkUp
could not open directory /usr/sap/trans/data/BaCkUp
Reading files from directory: /usr/sap/trans/log/.
found file: Q050629.PRD
found file: ULOG05_3
found file: DEVE904804.DEV
found file: Q050701.DEV
found file: P050701.PRD
found file: DEVI904804.PRD
found file: DEVV904804.PRD
found file: Q050701.PRD
found file: DEVE904808.DEV
found file: DEVI904808.PRD
found file: DEVV904808.PRD
found file: DEVG904808.PRD
found file: DEVE904794.DEV
found file: DEVI904794.PRD
found file: DEVV904794.PRD
found file: DEVG904794.PRD
found file: DEVE904818.DEV
found file: DEVI904818.PRD
found file: DEVV904818.PRD
found file: DEVG904818.PRD
found file: DEVE904790.DEV
found file: Q050702.DEV
found file: P050702.PRD
found file: DEVI904790.PRD
found file: DEVV904790.PRD
found file: DEVR904790.PRD
found file: DEVG904790.PRD
found file: Q050702.PRD
found file: SLOG0526.ALL
Collected 1583 filenames from [/usr/sap/trans/log/.]
SLOG0526.ALL belongs to a transport request NOT appearing in any of the buffers. Thus it is NOT needed.
Q050702.PRD belongs to a transport request NOT appearing in any of the buffers. Thus it is NOT needed.
DEVG904790.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVR904790.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVV904790.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVI904790.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
P050702.PRD belongs to a transport request NOT appearing in any of the buffers. Thus it is NOT needed.
Q050702.DEV belongs to a transport request NOT appearing in any of the buffers. Thus it is NOT needed.
DEVE904790.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVG904818.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVV904818.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVI904818.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVE904818.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVG904794.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVV904794.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVI904794.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVE904794.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVG904808.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVV904808.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVI904808.PRD belongs to a transport request appearing in one of the buffers. Thus it IS needed.
DEVE904808.DEV belongs to a transport request appearing in one of the buffers. Thus it IS needed.
Found 2 invalid filenames on Logfile-directory
Reading files from directory: /usr/sap/trans/log//usr/sap/trans/log/././BaCkUp
could not open directory /usr/sap/trans/log//usr/sap/trans/log/././BaCkUp
Reading files from directory: /usr/sap/trans/sapnames/.
found file: User1
found file: User2
Collected 28 filenames from [/usr/sap/trans/sapnames/.]
Searching User1 for transport requests.
Found transport request DEVK904558.
Searching User2 for transport requests.
Analysed 00028 SAPUSER files.
User's User1 transport request DEVK904919, (3)
User's User1 transport request DEVK903780, (0)
WARNING: DEVK903780 has status T_STEP_UNKNOWN in sapnames/User1
User's User1 transport request DEVK903778, (0)
WARNING: DEVK903778 has status T_STEP_UNKNOWN in sapnames/ User1
User's User2 transport request DEVK900629, (3)
================================
Also on our PRD, we've many requests with "Request is ready to imported again" (yellow triangle symbol) and was imported 6 months ago. Can this be deleted with "TP CLEAROLD ALL PF..." ?
Please help me why this not working, i've tried many things. Much appreciated for your help.
Thaiboy.
Answer:
The transports have to be deleted from STMS on all systems which reference the transport. The tp calls should have their own profile set up with your delete criteria. You need to create a path to store the "archived transports", olddata. We have it successfully set up to run on a weekly basis here. We had to use a 620 version of TP on our 46C systems to get the delete to work, but you are already there with 4.7.
Answer:
HI ScoreKeeper,
Thanks for the information but i'm still puzzled.
The Trans directory is on DEV server so i only need to delete on DEV with TP, is this right?
Also about path for "olddata" directory, you mean i need to explicitly specify in TPPARAM? Can you please give me a sample of your TPPARAM?
Thank you very much for your help.
Thaiboy.
Answer:
Can we delete cofiles and datafiles at OS level?
_________________
Suril
A conclusion is simply the place where you got tired of thinking.
Answer:
You should make your own copy of TPPARAM with a different name that includes the following:
COFILELIFETIME = 360
DATALIFETIME = 180
LOGLIFETIME = 180
OLDDATALIFETIME = 360
This file should be specified with pf= in your tp command line.
In order for the clearold to work, transports have to be removed from all queues in the Transport Domain. You can see the queues by accessing the Imports from STMS. Removing them from the Domain controller will not be sufficient.
You can delete cofiles and datafiles anytime you wish, but the tp job will also remove old logs as well. I would recommend using it to clean up your transport directory and go with manual cleanup on an occasional basis to catch stuff that's obviously been missed.
Answer:
Hi ScoreKeeper,
I've the same parameters as you mentioned but it didn't work?
I guess i need to delete the cofiles + data files at OS level, is it safe?
Thank you.
Answer:
in your STMS buffers. If you feel a transport should be getting deleted because all the deletion criteria are met, it must be still referenced in one of the buffers. You must go to all systems in your landscape which reference the transport you are trying to delete and make sure there is no reference to it. 4.70 is a 620 or 640 Basis system and we have no problem with the tp clearold on our Basis 620 System.
In your original posting:
"Also on our PRD, we've many requests with "Request is ready to imported again" (yellow triangle symbol) and was imported 6 months ago. Can this be deleted with "TP CLEAROLD ALL PF..." ?"
If the transports still appear in your Production system, the Clearold will not work.
In your original posting about the Check Log:
"P050702.PRD belongs to a transport request NOT appearing in any of the buffers. Thus it is NOT needed."
If this meets the date criteria, files associated with this transport will be deleted by the clearold.
There is also a Testold Option, if you want to shorten your number of days criteria and see what might be deleted. In order to properly use the testold option, you must run TP with the Check option followed by TP with the clearold option.
The TP Clearold option does work. We just have to determine what part of the process is missing.
Answer:
Hi ScoreKeeper,
Thank you for the suggestions.
I somehow got it working but NOT TOTALLY. In tcode STMS_IMPORT then select EXTRAS -> Delete Import Requests, after this then apply "TP CLEAROLD..." it did delete those ones that are already imported. However, i still left with over 1 thousand that are with status "Request is ready to import again" (Yellow triangle). Most of them are done from over 6 months ago.
I've two questions:-
1) How can i change the status of imported requests from "Request is ready for import again" (yellow triangle) to "Request is already imported" (green tick). Doing this i can then goto EXTRAS -> Delete Import Requests, this will allow me to delete this requests using TP CLEAROLD.
2) I noticed there are lots of imported requests exists as files in COFILES directory but NOT in DATA directory, is this normal?
Thank you again for the help.
Answer:
1) The yellow triangle is present when the Leave Transport in Queue for Later Transport is checked in the Options tab when bringing in a transport. If this is unchecked you will get a green checkmark. I don't think this is a big concern. The transport can be removed from the queues in STMS_IMPORT no matter what it's status.
2) If you used the parameters I listed earlier, datafiles are moved at 180 days to olddata. The cofiles which match these transports will not be moved. At 360 days, both the data file and cofile will be deleted.
If you have a scheduling tool that can automatic UNIX commands, you should be able to set this process to run on a regular basis and keep your transport directory clean provided the entries which are old are deleted using STMS_IMPORT. If the transport is referenced in any STMS queue in the transport domain, the transport cannot be deleted no matter how old.
Answer:
Hello ScoreKeeper,
Thanx for the reply.
1) i understand this The yellow triangle is present when the Leave Transport in Queue for Later Transport is checked in the Options tab when bringing in a transport. If this is unchecked you will get a green checkmark.
But The transport can be removed from the queues in STMS_IMPORT no matter what it's status. , i CAN NOT remove anything that's with status "Request is ready to import again" (Yellow triangle) using EXTRAS -> Delete Import Requests.
So again my question is how can i change the STATUS from "Request is ready for import again" (yellow triangle) to "Request is already imported" (green tick)?
2) If i use menu REQUESTS -> DELETE (Shift-F2) to delete request with "Request is ready for import again", where does it go? And if i use TP CLEAROLD, will it delete the physical files on OS level?
Thank you very much for your help all this way.
Answer:
1. Requests that are flagged as reimportable will stay in the queue until you delete them in the way you have discovered. When you delete them you are just deleting them from that import buffer, they can be added and imported again if required (I do not recommend such heathen practices myself) Also if you go into history you can block select as many previous items as you want and readd them to the buffer. (this can be useful when building a new system for example)
2. I have answered the shift F2 question above. Note that anything you do in the STMS transaction will not physically delete cofiles or datafiles and these are the only files required to transport to any system.
CLEAROLD will indeed delete permanently data and cofiles. I actually disslike this command. I keep all old data/cofile and log files apart from once created by SAP and client exports. A simple batch file running on a regular basis will do the cleanup you want and you can control it a bit better.
We use extended transport here (CTC=1) and auto imports which mean all authorization is done at export. Only people in the transport team release transports and this means we never need to have yellow triangles or me having to perform exports or imports. I just get involved when the transports fail.
So to sum up
Yellow triangles in the STMS queue/buffer can be got rid of by deleteing the transport from the queue.
The TP clearold does not touch the buffer but is the only thing that will delete data and cofiles which I would never do myself.
_________________
regards,
Chap
Answer:
I am able to delete transports with the yellow triangle on my 620 Basis System. After you are unable to delete, run a SU53 and see if you have a security issue. Our Transport people delete transports with a yellow triangle all the time, so I'm guessing it's probably a security issue for you.
Answer:
Hi Scorekeeper/Sap_Basis_Chap (SBC),
Scorekeeper, i can delete transport...no problems there, what i meant was when i deleted from the import queue for yellow triangle i can not use TP Clearold to clean it up...which i understand why now after SBC explain (so thank you SBC, u r a champ!).
SBC, with regards to the points you raised:-
1) import buffer, they can be added and imported again if required
Also if you go into history you can block select as many previous items as you want and readd them to the buffer. (this can be useful when building a new system for example)
I didn't do a backup of the transport directories before i deleted the requests using TP Clearold. Cacn i recreate the requests in anyway, i mean just like restore the transport request to files on OS?
2) extended transport here (CTC=1) and auto imports
This is very interesting, didn't know we can do that...only one problem i can see is if accidently released from DEV & it's not working so the incorrect request/tasks will stuff PRD. Maybe we can have a QAS in between to solve this issue.
How i can get this Extend Transport setup? I haven't search this forum yet, but will do.
Thank you for all your help.
PS: SBC, please i send you reply to other post "MEMORY USING"...just a reminder in case you over see it. Thank you.
Answer:
1) You can restore from your backups if you have any
The only other option you have is to copy the objects from the old transport to a new one and export this but remember this will be the latest version, not the version you had necessarily. The implication in this is if you import an old set of transports that include this then objects will possibly be changed in an inconsistent way
2) Have a look at http://help.sap.com/saphelp_nw04/helpdata/en/60/e3fcfae36811d184810000e8a57770/frameset.htm
You can use a stopmarker in STMS (the lock button) and move it around using menu option Queue - Move end mark (visible when sto marker is set) and so control how much of the queue is handles by the import all
3) As you log in as guest I am not sure where your reply is but I will have a look now and if it is at the bottom I'll have a look.
_________________
regards,
Chap
Answer:
Hi SAp_basis_chap,
Thank you so much, you are just amazing...i really admire your resourceful knowledge.
Cheers.