OPEN DATASET reading file from network causing 6 minute delay

[ChadRichardson]

We have a function module that is called 3,000+ times a day.  It usually take 3-5 seconds but sporadically about a dozen times a day it takes 6 minutes and it's always 6 minutes.  We have narrowed down the offending logic to

OPEN DATASET p_pathfile FOR INPUT IN BINARY MODE.

READ DATASET p_pathfile INTO gt_bitmap-orblk LENGTH g_len.

CLOSE DATASET p_pathfile.

p_pathfile is a BMP file located on our network.  The size of the file is always the same.  The 6 minute delay is never the same time of day or during any common processing.

Anybody have any ideas???

We are stumped...

[former_member601402 · Accepted solution]

Hi Chad,

I am not sure if this one will help but when it comes to reading file there's a new FM called GUI_UPLOAD that reads the data from a file. I am not sure if this is an option for you but this will help you read your data easily without the need to commit and open and close.

If it is possible to rewrite or replace the OPEN DATASET, please do so as this is the new means of reading the file without hassle especially in basic reading of files.

Hope this helps,

Regards,
Ryann

[former_member182550 · Accepted solution]

This is a background job.  There is no gui.

Rich

[ChadRichardson · Accepted solution]

GUI_UPLOAD did seem promising but the job running is indeed a background job and GUI function modules do not work in background processes.  Is there a background equivalent???

[former_member182550 · Accepted solution]

Open dataset ?

I think that if you had this problem with open data set you'd get the same with any data transport across the network.  We had a similar problem which was traced to (and I'm not a network person),  but something to do with Virtual network paths being dropped and then re-isnated.  It was traced to a problem with a router os some sort in the data centre.

[matt · Accepted solution]

It's extremely unlikely to be something that can be fixed by an ABAP coding. That's why I've moved it to Netweaver Administrator,in the hope that Basis people might be able to suggest some approaches.

[Jelena · Accepted solution]

Ryann Ong wrote:

I am not sure if this one will help but when it comes to reading file there's a new FM called GUI_UPLOAD that reads the data from a file. I am not sure if this is an option for you but this will help you read your data easily without the need to commit and open and close.

If it is possible to rewrite or replace the OPEN DATASET, please do so as this is the new means of reading the file without hassle especially in basic reading of files.

Um, where are you getting this information? Not only GUI_UPLOAD has not been "new" for years but it is also not a replacement for OPEN DATASET in any way.

And this is the only helpful answer here? Holy moly...

[former_member601402 · Accepted solution]

Is the background job you are running can be modified? I mean remove OPEN_DATASET and instead call the FM from the code and provide the path alongside it?

For more information, you can use this:

Thanks and warmest regards,

Ryann Ong

[former_member182550 · Accepted solution]

This is still wrong - A background job is divorced from the terminal or pc that started it hence why the GUI_functions etc will not work.

What happens if the user schedules the job,  logs off and, turns off and goes home ?

Rich.

@Mods:  Sorry - wasn't logged on!

[Jelena · Accepted solution]

Ryann, it's not feasible to replace OPEN DATASET with a GUI function, period. These are two completely different things. Even the link you posted says the same.

- this has been open for several weeks already, kindly follow up and consider closing the discussion. See this blog: http://scn.sap.com/community/support/blog/2013/04/03/how-to-close-a-discussion-and-why

[Sandra_Rossi]

You should post your question to the Administration forum. You should also give the details of your landscape (network, OS, application servers), file systems, and so on.

By the way, could it be possible that you have several application servers, and only one have a problem? (in the trace, retrieve the current AS)

[ChadRichardson]

Thank you for your responses Sandra
.

I went ahead and posted on the System Admin forum as you suggested.

We are running our SAP instance on an iSeries using the DB2 database.

[matt]

Cross-posting isn't allowed - and in any case, you picked the wrong space (I hope!). I've moved the thread to the correct space for you.

[Sandra_Rossi]

If your function module is started from within a job, do you see a delayed start in SM37? Maybe the job cannot start immediately (no BGD workprocess available at the second it is launched, and you have a delay of 300 seconds in the profile parameter rdisp/btctime?

[ChadRichardson]

The function module starts when expected.  We added logging (writing entries into custom logs) within the function module to pinpoint exactly what code is causing the issue.  We moved the logging around until we were able to figure out what commands were causing the delay.  We were able to pin point these commands because we wrote a START log message prior to the OPEN DATASET and an END log message after the CLOSE DATASET command and the difference in times was the mysterious 6 minute delay.

[Juwin]

Network problems during the read may be the issue. Solution may be to redesign this function module to get the BMP file from local drive.

And then, design a separate report job, to periodically check the update timestamp of BMP file on the network server, and if changed, then copy that file onto the local drive.

Thanks,

Juwin