Field-Groups, Extract Dataset - Extract errors on a job (standard program)

[Former Member]

Hi,

We have a job running daily, which uses program RFDOPR10 & a custom variant.

This job fails a few times a month (1-3), with ST22 showing Extract files errors like EXTRACT_READ_ERROR & EXTRACT_OPEN_EXTRACTFILE_OPEN (Could not open the extract file "/archive/PR5/arch_transfer//E000005M" for writing.)

The data is stored in field groups and then extracted with the extract statement.

According to [http://help.sap.com/SAPHELP_NW04S/helpdata/en/9f/db9ed135c111d1829f0000e829fbfe/content.htm] , u201CExtracts larger than 500 KB are stored in operating system files. The practical size of an extract is up to 2 GB, as long as there is enough space in the file system.u201D

Could this be happening because the extracts for some cases are very large but there isnu2019t enough memory in the system or a limit to the memory for extracts? Why else would this happen? Like I said, the job works fine for weeks and then fails with these extract errors.

Please help. Thanks.

[Former Member]

Hi,

We have a job running daily, which uses program RFDOPR10 & a custom variant.

This job fails a few times a month (1-3), with ST22 showing Extract files errors like EXTRACT_READ_ERROR & EXTRACT_OPEN_EXTRACTFILE_OPEN (Could not open the extract file "/archive/PR5/arch_transfer//E000005M" for writing.)

The data is stored in field groups and then extracted with the extract statement.

According to [http://help.sap.com/SAPHELP_NW04S/helpdata/en/9f/db9ed135c111d1829f0000e829fbfe/content.htm] , u201CExtracts larger than 500 KB are stored in operating system files. The practical size of an extract is up to 2 GB, as long as there is enough space in the file system.u201D

Could this be happening because the extracts for some cases are very large but there isnu2019t enough memory in the system or a limit to the memory for extracts? Why else would this happen? Like I said, the job works fine for weeks and then fails with these extract errors.

Please help. Thanks.

[Former Member]

What does the dump indicate that the problem is? Have you read that in detail? The answer is quite probably there.

[Former Member]

Thanks.

I have read the dumps in detail, but there is no specific information on the error.

The following is the only relevant information I get from the dumps, which is different in each case:

Runtime Errors EXTRACT_READ_ERROR

Short text

Error when reading the temporary extract file.

What happened?

Runtime error

The current ABAP program "RFDOPR10" had to be terminated because one

of the statements could not be executed at runtime.

Error analysis

An error occurred when reading the extract file.

Error number: 0

Error text: "Error 0"

Runtime Errors EXTRACT_OPEN_EXTRACTFILE_OPEN

Short text

Could not open the extract file for writing.

What happened?

Runtime error

The current ABAP program "RFDOPR10" had to be terminated because one

of the statements could not be executed at runtime.

Error analysis

Could not open the extract file "/archive/PR5/arch_transfer//E00BWQEY" for

writing.

Error number: 70

Error text: "Stale NFS file handle"

-

---

As you can see, there isn't much info pointing to a specific problem. As such, I have to investigate different areas.

The main issue is with storing the temp extract file and reading it. However, I can't replicate this issue and it only happens 1 or 2 times a month.

[Former Member]

Actually, there's good information here....

Runtime Errors EXTRACT_OPEN_EXTRACTFILE_OPEN

Short text

Could not open the extract file for writing.

What happened?

Runtime error

The current ABAP program "RFDOPR10" had to be terminated because one

of the statements could not be executed at runtime.

Error analysis

Could not open the extract file "/archive/PR5/arch_transfer//E00BWQEY" for

writing.

Error number: 70

Error text: Stale NFS file handle

-

---

The stale file handle telss me that the file was opened for output so long ago that, in the meantime, SAP or the operating system has lost track of it and is not sure of the state of the file at the time you tried to write into it....

I don't know the program you're using, but if this is custom work, only open the file when you are ready to immediately write to it, and check the return code for zero before attempting to write anything out to the file.

An alternative would be to look at the data that you're attempting to extract to see if there is something you can do to limit the runtime involved.

[Former Member]

The program is standard - RFD0PR10, so it's not a custom work.

Thank you for the analysis of the "stale" file error. I wasn't sure how to understand that but now it makes sense.

I'll take a look to see what we can do to limit the runtime. If that's not possible, we might have to open an OSS note with SAP.

It's just interesting that it happens 1 or 2 times a month. The rest of the time, it works just fine.

Thanks again!

[Former Member]

Hi,

I had the same EXTRACT_OPEN_EXTRACTFILE_OPEN dump and on detailed analysis observed SAP creates temporary files in directory provided in profile parameter DIR_DATA and files would start with E*

like E0000160 and if those files are used or locked by some other process you will get this dump.

In my case AS400 is the server and MIMIX is an application that replicates files from application server so we stopped MIMIX from replicating those files in directory and this stopped from locking these files and the dump stopped.

These are temporary sort files that SAP creates in data directory for bulk jobs and deletes after the purpose is done. But these should not be locked by other processes but only SAP.

Hope this helps.

Thanks - JR