OPEN DTASET FOR OUTPUT statement returning non-zero sy-subrc intermittently

[aminpranal]

Hello Folks,

We are using the following statement

OPEN DATASET l_file

FOR OUTPUT IN TEXT MODE ENCODING DEFAULT.

As per SAP F1 help the if the file does not exist it'll create one, This is happening intermittently sometimes a retry will solve the issue but a permanent fix to this is needed

sap-doc.png

We have handled sy-subrc for the OPEN DATASET statement to throw error message likewise.

Can anyone help to understand what could cause this OPEN DATASET statement to fail and a possible solution to handle the same?

Thanks in advance.

[stanislaslemaire]

Hello,

are you sure that processing is done on same application server each time ?
And what is the returned value of sy-subrc ?

[aminpranal]

stanislaslemaire
I was unable to catch it red handed. Every time I reprocess in debug mode it was working perfectly.
Yes, the Application server is same always
I have been trying on Test system and I could see that sy-subrc 8 corresponds to incorrect file path actually. Could be more reasons also.

[Sandra_Rossi]

aminpranal I'm not sure if it's clear to you that a same SAP system (let's say the production system) can be made of several Application Servers to do load distribution, and to know on which server the ABAP program it runs, you have to do a deep search. First of all, check the number of AS by running SM51. If it's only one, please ignore my remark, it's only one server for sure (unless the admins attach servers on the fly...) If it's two or more, how do you check that it's the same server?

[stanislaslemaire]

and do you catch message by use of MESSAGE option, like this ?
DATA mess TYPE string.

OPEN DATASET `` FOR INPUT IN BINARY MODE MESSAGE mess.

IF sy-subrc = 8.
MESSAGE mess TYPE 'I'.
ENDIF.

Perhaps mess content better error description...

[aminpranal]

sandra.rossi
I know that the same SAP system can have multiple application servers and here also I could see there are many.
Please correct me if I am interpreting it wrong, you mean to say that for different application severs of the same system, there could be different AL11 file structure (path hierarchy) causing the statement to fail in case the directory is not present in the application server it is currently executing on?

I don't suspect the file name to be an issue as in FOR OUTPUT mode if the file is missing it will create the same and overwrite/append if it already exists.

stanislaslemaire

The message is not handled the way you have mentioned, Its only the sy-subrc is being checked and a default error message is used.
Thanks for your solution and this is more better than the one being used as it will help to capture the cause there and then handling it in a better way.

[FredericGirod]

AL11 is a list of directories available from an Application Server. Most of these directories are linked using NFS mount (With Linux / Unix system). For example the Transport Request correspond of 2 files, these files are in a central directories available on every system/AS. But ! We don't know where you have put your data, probably in a specific area of the server.

So, to know if the diretory is the same for every AS, you have to ask your system admin.

[Sandra_Rossi]

aminpranal Yes exactly and that's often the problem when OPEN DATASET works most of the time, and sometimes not, and it's difficult to understand why if you don't know that. If the directory is not mounted in one of the application servers (AS), if the ABAP program runs in this AS, the file can't be created because the directory is not there. Frederic has better explained. It's also what Stanislas meant to say in his first comment, I think.

Via SM51, and double-click any server, you can start a session in the selected AS and make sure the directory is there (NB: it should be included in AL11, but it's not mandatory; if not I have to ask the admin to check that, or sometimes I'm authorized to run an operating system command in SM49 to check the directory existence and authorization).

By the way, the problem can also be authorization at operating system in one of the AS.

There can be also many other reasons...

[aminpranal]

sandra.rossi frdric.girod

Thanks a lot for you suggestions on this topic, I'll propose the changes as stanislaslemaire has mentioned to capture the message as an argument to the OPEN DATASET statement itself rather a hard-coded error message.

This will assist in clarifying the issue if its on the AS side in case the file directories are improperly mounted.