2004 Nov 04 9:24 AM
Hello All,
A scenario which every programeer might have come across - When an object (Program) is executed in Background with an option to download the data to an Text file, if the folder to which the path has been specified is full to the brim and when the output starts writing to the folder, the job fails/aborts. Is there an way to avoid this i.e identify the folder size and if the folder is full to write that data to an alternate folder specifically created to over come this.
U r pointers are very much welcome.
Thank you,
- Sravan
Hello All,
A scenario which every programeer might have come across - When an object (Program) is executed in Background with an option to download the data to an Text file, if the folder to which the path has been specified is full to the brim and when the output starts writing to the folder, the job fails/aborts. Is there an way to avoid this i.e identify the folder size and if the folder is full to write that data to an alternate folder specifically created to over come this.
U r pointers are very much welcome.
Thank you,
- Sravan
2004 Nov 04 9:30 AM
Hi Sravan
I guess you mean some folder at presentation layer. If so, unfortunately, it is <u>not</u> possible to execute functions related to the presentation layer during backgroud processes.
However you can download your file to the application server for future usage.
*--Serdar
2004 Nov 04 10:17 AM
Hi Serdar,
The download is with regard to Application server, for ex we have a Common tmp folder \ABC\TMP\ So the users generally set the download path to this tmp folder and later extract there files, as such this folder when full and when other reports also use the same folder as the space is nil, the jobs get abort .....
Thank you,
- Sravan
2004 Nov 04 10:34 AM
Hi Sravan,
An option would be to check whether the OPEN DATASET and/or WRITE statements are succesfull. If not you could do the OPEN DATASET with a different pathname.
Regards,
John.
2004 Nov 04 2:17 PM
Hi Sravan
If you can assess the load, you may write a dispatcher function to send files to different folders and schedule a job to delete the content of folders at the end of the day.
I do not know a way to retrieve information whether a folder's quota is reached, so to assure you may use the subrc value of the statement "OPEN DATASET" (this can be done at the dispatcher function too) as John mentioned. But if the result is a dump and thus interruption of the background process, this will also fail.
As far as I know, SAP lets to execute some operating system commands. For the moment, I can't remember the tcode. It may also be utilized.
*--Serdar
2004 Nov 06 6:14 AM
Hi,
The following command would give you the current occupied size of the folders.
call 'SYSTEM' id 'COMMAND' field g_commstr
id 'TAB' field itab_result-sys.
where g_commstr value is
ls -la <directory path> (/cidata/DVC/interfaces/FI)
The result line will look like below where 200 is the size.
rw-rw---- 1 dvcadm sapsys 200 Jan 9 2002 <file/folder name>
Regards
Raja
2004 Nov 08 5:32 AM
Hello Raja,
Thanks for the posting and informing of a method to get the size of the folder. May be we need to get the size of the folder (with the command that u have provided)and the size of the file that is to be written to that folder and if the size does not match, we need to transfer it to another folder. Correct me if i am wrong.
TQ,
- Sravan
2004 Nov 08 5:40 AM
2004 Nov 08 5:44 AM
Hi Raja,
In the approach which i mentioned, how do we get the size of the file, as the data is written into the text file, the file size increases and once the file is complete How can we get the file size because after step we need to compare this file size with that of the Folder space.
TQ,
- Sravan
2004 Nov 08 5:58 AM
Hi,
Check out the following from Thomas Jung in this forum.
If you are on release 620, have a look at class CL_ABAP_MEMORY_UTILITES method GET_MEMORY_SIZE_OF_OBJECT. It will tell you how much memory is allocated and how much is actually used. Here is some sample code:
TABLES: sflight.
DATA: isflight TYPE TABLE OF sflight.
SELECT-OPTIONS: carrid FOR sflight-carrid.
SELECT * FROM sflight INTO TABLE isflight
WHERE carrid IN carrid.
DATA: size1 TYPE abap_msize,
size2 TYPE abap_msize,
size3 TYPE abap_msize,
size4 TYPE abap_msize,
flag1 TYPE char128,
size5 TYPE abap_msize,
size6 TYPE abap_msize,
flag2 TYPE char128,
flag3 TYPE char128.
TRY.
CALL METHOD cl_abap_memory_utilities=>get_memory_size_of_object
EXPORTING
object = isflight
IMPORTING
bound_size_alloc = size1
bound_size_used = size2
referenced_size_alloc = size3
referenced_size_used = size4
is_part_of_non_trivial_szk = flag1
szk_size_alloc = size5
szk_size_used = size6
low_mem = flag2
is_in_shared_memory = flag3.
ENDTRY.
WRITE: / 'Size of Bound and Allocated Memory:', size1.
WRITE: / 'Size of Bound and Used Memory:', size2.
WRITE: / 'Size of Referenced and Allocated Memory:', size3.
WRITE: / 'Size of Referenced and Used Memory:', size4.
WRITE: / 'Strongly Connected Component of Object:', flag1.
WRITE: / 'Size of Allocated Memory of SCC:', size5.
WRITE: / 'Size of Used Memory of SCC:', size6.
WRITE: / 'Flag, whether only bound_size_* are filled due to mem.short.:', flag2.
WRITE: / 'Flag, whether ONJECT is in the shared memory:', flag3.
If you aren't on 620 or don't need to be that precise, you might try the following:
DESCRIBE TABLE isflight LINES size1.
WRITE: / 'Number of Lines:', size1.
DATA: wa_sflight LIKE LINE OF isflight.
DESCRIBE FIELD wa_sflight LENGTH size2 IN BYTE MODE.
WRITE: / 'Size of one Line:', size2.
size3 = size1 * size2.
WRITE: / 'Total Size:', size3.
Please note that the addition IN BYTE MODE only works in 610 and higher. It isn't neccesary before that release. However it is important to get accurate resuls in an Unicode System.
Regards
Raja
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |