Time-out in PRD
when i run my report in PRD, it times out causing a short-dump. is there any way around without asking Basis to help? they are not very helpful here
If standard program - check OSS to see if their are any notes on improving performance. Possibly narrow your selection criteria.
If custom program - there are a whole bunch of things. Search this forum for 'performance tuning' or similar phrase.
If it is allowed by Basis, execute in background.
i need to debug it so want to run in foreground. background is fine, doesnt time out. problem is only in foreground.
this is a custom program written by me, as with performance tuning, can't tune it to better perform anymore. it takes lot of time as its reading a large number retro results in a loop for every employee. the number of employees is 4000.
Is there any logical place to put a COMMIT WORK ? That resets the time for foreground?
It is a wonder why you need to run the whole database to perform debugging, if possible use selection-option to zoom down into problem area/data. If it has to be done, maybe execute the job when there is no one using it where you can get the most of the CPU time.
On performance tuning, besides tuning the program you will be surprise of the improvement in tuning the table as well, eg adding indexes.
Is there any logical place to put a COMMIT WORK ? That resets the time for foreground?
aussie,
no i dont think so. im using LDB PNP (for HR/PY). ive seen standard report and they dont use commit work after get statement.
It is a wonder why you need to run the whole database to perform debugging, if possible use selection-option to zoom down into problem area/data. If it has to be done, maybe execute the job when there is no one using it where you can get the most of the CPU time.
On performance tuning, besides tuning the program you will be surprise of the improvement in tuning the table as well, eg adding indexes.
bktee22,
i need to know the problem employee, as a result can't zoom down into problem area/data area. i wish i could. again, can't add indexes as im reading data from internal tables that gets filled up when i read PY cluster results
Why are you debugging in PRD anyway?
Create a test case in QAS and debug it there using a minimized test set.
Why are you debugging in PRD anyway?
Create a test case in QAS and debug it there using a minimized test set.
because QA data is old and out of date. master data hasn't been copied from PRD for a long time now. i dont know what the problem with a set of employees, so can't replicate data in DEV or QA thats why debugging in PRD, no other option.
I'am not sure how much my experience can help you.
While debugging in Production, If I have 50,000 records, I normally set a watch point for SY-TABIX = 10,000 and once the watch point reaches the place, I reset it to 20,000 and continue until it reaches and so on.
The advantage is every time you program reaches your Watch point you time is reset preventing TIME OUT. (Probably COMMIT WORK is executed).
In between you can set another Watch point to debug whatever value you want.
KRK
I'am not sure how much my experience can help you.
While debugging in Production, If I have 50,000 records, I normally set a watch point for SY-TABIX = 10,000 and once the watch point reaches the place, I reset it to 20,000 and continue until it reaches and so on.
The advantage is every time you program reaches your Watch point you time is reset preventing TIME OUT. (Probably COMMIT WORK is executed).
In between you can set another Watch point to debug whatever value you want.
KRK
most realistic solution without troubling the Basis well done Kumar, your suggestion is much appreciated, i'll try it on right now. i might have to create a number of watchpoints for that but its ok. you r right, it will prevent the timeout as when it reaches the watchpoint the timeout parameter is initialized. i know this will work without even trying it on system good on you mate, thanks again