CO_COSTCTR Archiving Write Job Fails

[Former Member]

Hello,

The CO_COSTCTR archiving write job fails with the error messages below. 

Input or output error in archive file \\HOST\archive\SID\CO_COSTCTR_201209110858

Message no. BA024

Diagnosis

An error has occurred when writing the archive file \\HOST\archive\SID\CO_COSTCTR_201209110858 in the file system. This can occur, for example, as the result of temporary network problems or of a lack of space in the fileing system.

The job logs do not indicate other possible causes.  The OS and system logs don't have either.  When I ran it in test mode it it finished successfully after long 8 hours.  However, the error only happens during production mode where the system is generating the archive files.  The weird thing, I do not have this issue with our QAS system (db copy from our Prod).  I was able to archive successfully in our QAS using the same path name and logical name (we transport the settings). 

Considering above, I am thinking of some system or OS related parameter that is unique or different from our QAS system.  Parameter that is not saved in the database as our QAS is a db copy of our Prod system.  This unique parameter could affect archiving write jobs (with read/write to file system). 

I already checked the network session timeout settings (CMD > net server config) and the settings are the same between our QAS and Prod servers.  No problems with disk space.  The archive directory is a local shared folder \\HOST\archive\SID\<filename>.  The HOST and SID are variables which are unique to each system.  The difference is that our Prod server is HA configured (clustered) while our QAS is just standalone.  It might have some other relevant settings I am not aware of.  Has anyone encountered this before and was able to resolve it?

We're running SAP R3 4.7 by the way.

Thanks,

Tony

[paul_power · Accepted solution]

Hi Tony,

Where are the archive files being saved to? Is it a local drive?

If not, try saving to a lcoal drive as a test to see if it completes when network is not part of the job.

Hope this helps.

Regards,

Paul

[Former Member · Accepted solution]

Hi Paul,

Thanks for your reply.  The archive directory is local to the server because we use the \\<host>\archive\<SID> parameter.  This setting was transported DEV-PRD so the path should caters for all systems.  So it will just read the host server name and the SID. (see below)

Archive Directory Path: \\<host>\archive\<SID>\<filename>

They are all pointing to a shared folder inside the local drive of the server. In effect:

DEV  \\devhost\archive\DEV\<filename> ---> is actually "J:\archive\DEV" of devhost server

QAS \\qashost\archive\QAS\<filename> ---> is actually "J:\archive\QAS" of qashost server

PRD \\prdhost\archive\PRD\<filename> ---> is actually "J:\archive\PRD" of prdhost server

I have successfully executed other archiving objcets using the same archive directory.  The error only happens in CO_COSTCTR.  The archiving objects MM_SPSTOCK, FI_DOCUMNT and the others were archived successfully.

Thanks,

Tony

[Former Member]

Hello,

Apparently, this can be resolved by using a direct local drive instead of a shared folder.  Using shared folder is constrained with timeout setting that can disconnect your session, thus losing connection to your shared drive and files.  I changed my archive directory from \\<host>\archive\<SID>\<filename> to just simply J:\archive\<sysSID>\<filename> and it was able to go through.  A good lesson learned indeed.

Thanks,

Tony

[Former Member]

Hi Tony,

How many actual runs did you execute? if at first, it fails, try again. The may have really been a connectivity during your first run that you have not detected early.

try to rerun the write job and check logs while writing.

Regards,

Rod

[Former Member]

Hi Rod,

We tried a couple of times already. They all got cancelled due to the error above. As much as we wanted to trim down the variant, the CO_COSTCTR only accepts entire fiscal year. The data it has to go through is quite a lot and the test run took us more that 8 hours to complete. I have executed the same in our QAS without errors. This is why I am bit confused why in our Production system I am having this error. Aside that our QAS is refreshed from our PRD using DB copy, it can run the archive without any problems. So I made to think that there might be unique contributing factors or parameters, which are not saved in the database that affects the archiving. Our PRD is configured with High availability; the hostname is not actually the physical host but rather a virtual host of two clustered servers. But this was no concern with the other archiving objects; only in CO_COSTCTR it is giving us this error. QAS has archiving logs turned off if it’s relevant.

Archiving 2007 fiscal year cancels every after around 7200 seconds, while the 2008 fiscal year cancels early around 2500 seconds. I think that while the write program is going through the data in loops, by the time it needs to access back the archive file, the connection has been disconnected or timed out. And the reason why it cancels almost consistently after an amount of time is because of the variant, there is not much variety to trim down the data. The program is reading the same set of data objects. When it reaches to that one point of failure (after the expected time), it cancels out. If this is true, I may need to find where to extend that timeout or whatever it is that is causing above error.

Thanks for all your help.  This is the best way I can describe it.  Sorry for the long reply.

Tony