Hello, I'm new to the group but happy to know that it exists and
looking forward to contributing.
If this is an inappropriate forum for my question, please let me know.
What lead me here, however, is a problem I've been unable to diagnose.
Background: We use Gentran:Server for Unix v5.2-1, we do not have a
current service agreement with Sterling Commerce, the Knowledge Base
has proven (for the first time in my experience) inadequate to the
task, and this error is just plain weird.
One of our custom translate data managers, xmtm, suddenly started
shutting down this past Saturday morning, and the error for the
xmtm.l is:
xmtm:6905:01192005:135106: 0:Began inmtm/HAN40102
14I.00IM9D.010194935:
xmtm:6905:01192005:135111:-16:error writing file:
xmtm:6905:01192005:135111: -1:Ended, pid=6905:
I looked up "-16:error writing file" on the Sterling Knowledge Base
and was told:
Here is the solution: Getting -16 error message from data manager.
GENTRAN:Server for UNIX. This error will shut down the data manager.
Write error for write_chk failure
The data manager is unable to write (update or create) a file to a
critical area. There should be another error close to the error 16
with the information of the exact problem. Possibilities could be:
Not being able to write .chkpt file in scan directory
(WORK_DIRECTORY)
Not being able to write file to the destination directory
Disk drive busy
Disk drive full
Well, the file system is only 72% full, the xmtm is not our only
translate data managers but it is the only one that is failing, and it
only fails intermittently with no discernible pattern to the data that
it fails on. The xmtm_xltr.scr is finishing with a 0 return code and
the data being processed is being passed, but the $XL_OUTFNAME file
(shown in the example above) is not being deleted (which is where the
"error writing file" comes from). Nothing is clear about this issue.
It happens a couple of dozen times a day. We clear the .chkpt.xmtm
file from the scan directory, clear the $XL_OUTFNAME file from the run
directory, and restart the data manager. Sometimes it will continue
running for hours, sometimes it will fail again rapidly. Again, no
pattern.
I've asked the Unix guys to see if they notice any odd behavior at the
OS level: No. I've inserted a bdf command into the translator script
to see what the file system space is at the time of execution: Nothing
abnormal. Nothing about this makes sense. This is neither a new data
manager, nor a new translate script, and nothing has changed about
this entire process and it had been running error free for well over a
year before this Saturday morning.
I am at wit's end and would appreciate ANY thoughts on this
whatsoever.
Regards.
Ron Paquin
Sr. Systems Analyst
Pactiv Corporation
.
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Access the list online at: http://groups.yahoo.com/group/EDI-L
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
