Hi Chris,
to be deleted from the folder. The Epicor location for this folder is the
EpicorData folder, which is where the user report data files are also
stored.
From OpenEdge Deployment: Managing ABL Applications
http://documentation.progress.com/output/OpenEdge102b/pdfs/dp4gl/dp4gl.pdf
pp. 5-10
--------------------------------------------------------------------------------
Temporary file I/O
OpenEdge creates temporary files during each client session. Each operating
system has
different temporary files. Table 5�4 describes the temporary files.
By default, OpenEdge stores the temporary files in the user�s working
directory. Use the
Temporary Directory (-T) startup parameter to specify an alternate location.
When a session
ends, OpenEdge deletes these files unless you specify the Save Temp Files
(-t) startup
parameter. For more information about the Temporary Directory (-T) and Save
Temp Files (-t)
startup parameters, see OpenEdge Deployment: Startup Command and Parameter
Reference.
On UNIX, unless you use the Save Temp Files (-t) startup parameter, you do
not see the
temporary files in the directory because they are created unlinked. However,
if your system
crashes, the UNIX file system recovery program, fsck, finds the files. This
program might then
prompt you to delete the files. If this occurs, delete them.
On Windows, these temporary files are always visible during an OpenEdge
session, but the file
sizes are set to zero. Windows does not record file sizes until files are
closed.
Writing to these temporary files creates I/O activity that might slow down
client performance.
The amount of temporary file I/O activity varies among applications.
Table 5�4: Temporary client session files
File Description
.dbi Stores temporary tables
.lbi Local before-image file (subtransaction undo)
.ped Edit buffer contents
.rcd Cache of r-code being run in a session
.srt Temporary sort space; session compile storage
.trp Stores Data Dictionary changes until they are saved
You might find that running a particular procedure results in OpenEdge
abnormally terminating
in a way that indicates the hard disk is full. However, when you check the
disk immediately
afterward, adequate space is available. One possibility is that temporary
files created during an
OpenEdge session become quite large, taking up disk space as they expand.
Since OpenEdge
erases temporary files at the end of a session, they do not appear when you
check the disk. Of
the temporary files, the following files are most likely to cause this
problem:
� Temp table file (.dbi) � OpenEdge uses this file to store temporary
tables. If the
application uses a lot of temporary tables, this file can grow quite large.
� Local before-image file (.lbi) � OpenEdge uses this file to back out of
subtransactions
and variable value changes. If the local before-image file becomes too
large, the
procedures probably use a lot of subtransactions. Examine the transaction
structure of the
application procedures to understand why OpenEdge starts so many
subtransactions. For
more information about transaction processing, see OpenEdge Getting Started:
ABL
Essentials.
� R-code swap file (.rcd) � OpenEdge uses this file to dynamically swap
r-code segments
in and out of the execution buffer. Use the r-code usage statistics startup
parameters to
collect information about I/O to the swap file, as explained in the
�Monitoring r-code
activity� section on page 5�5. Using procedure libraries helps reduce the
amount of I/O
required to load r-code files. For more information, see the �Using
procedure libraries to
improve r-code performance� section on page 5�2.
Note: The AVM swaps codepage-converted text segments for procedure libraries
from
the execution buffer to the r-code swap file and reloads the converted text
segments
from the swap file instead of the library when necessary.
If temporary files grow to exceed disk space, change the application to
reduce the size of
temporary files, or use the Temporary Directory (-T) parameter to store the
temporary files on
a disk with sufficient space to hold the files. To optimize performance,
place the temporary files
on a dedicated disk.
--------------------------------------------------
A couple of thoughts here:
1.) We have a TON of these files left over after an orderly shutdown of
OpenEdge and the rcd files can get quite large (500+ MB). We're going to
modify either our shutdown or startup script to delete these files because
they are certainly not getting deleted by OpenEdge.
2.) Has anyone dedicated a disc to this activity? In light of the
discussions of RAID configurations, has anyone moved their OS temp/swap
files to another drive along with the OpenEdge temp files noted above to get
better performance? What RAID configuration would one use for this drive?
Has anyone considered allocating a RAM Drive for the OpenEdge temp files? My
temp folder is 9GB+, so that may take a lot of RAM...
Mark W.
[Non-text portions of this message have been removed]
> OpenEdge Startup parameters are case sensitive. From OpenEdge Deployment:I misread the documentation. the -T start up paramter SHOULD cause the files
> Startup Command and Parameter Reference:
> Use Temporary Directory (-T) to specify a directory for temporary files.
>
> Use Save Temp Files (-t) to make temporary files visible on UNIX.
>
to be deleted from the folder. The Epicor location for this folder is the
EpicorData folder, which is where the user report data files are also
stored.
From OpenEdge Deployment: Managing ABL Applications
http://documentation.progress.com/output/OpenEdge102b/pdfs/dp4gl/dp4gl.pdf
pp. 5-10
--------------------------------------------------------------------------------
Temporary file I/O
OpenEdge creates temporary files during each client session. Each operating
system has
different temporary files. Table 5�4 describes the temporary files.
By default, OpenEdge stores the temporary files in the user�s working
directory. Use the
Temporary Directory (-T) startup parameter to specify an alternate location.
When a session
ends, OpenEdge deletes these files unless you specify the Save Temp Files
(-t) startup
parameter. For more information about the Temporary Directory (-T) and Save
Temp Files (-t)
startup parameters, see OpenEdge Deployment: Startup Command and Parameter
Reference.
On UNIX, unless you use the Save Temp Files (-t) startup parameter, you do
not see the
temporary files in the directory because they are created unlinked. However,
if your system
crashes, the UNIX file system recovery program, fsck, finds the files. This
program might then
prompt you to delete the files. If this occurs, delete them.
On Windows, these temporary files are always visible during an OpenEdge
session, but the file
sizes are set to zero. Windows does not record file sizes until files are
closed.
Writing to these temporary files creates I/O activity that might slow down
client performance.
The amount of temporary file I/O activity varies among applications.
Table 5�4: Temporary client session files
File Description
.dbi Stores temporary tables
.lbi Local before-image file (subtransaction undo)
.ped Edit buffer contents
.rcd Cache of r-code being run in a session
.srt Temporary sort space; session compile storage
.trp Stores Data Dictionary changes until they are saved
You might find that running a particular procedure results in OpenEdge
abnormally terminating
in a way that indicates the hard disk is full. However, when you check the
disk immediately
afterward, adequate space is available. One possibility is that temporary
files created during an
OpenEdge session become quite large, taking up disk space as they expand.
Since OpenEdge
erases temporary files at the end of a session, they do not appear when you
check the disk. Of
the temporary files, the following files are most likely to cause this
problem:
� Temp table file (.dbi) � OpenEdge uses this file to store temporary
tables. If the
application uses a lot of temporary tables, this file can grow quite large.
� Local before-image file (.lbi) � OpenEdge uses this file to back out of
subtransactions
and variable value changes. If the local before-image file becomes too
large, the
procedures probably use a lot of subtransactions. Examine the transaction
structure of the
application procedures to understand why OpenEdge starts so many
subtransactions. For
more information about transaction processing, see OpenEdge Getting Started:
ABL
Essentials.
� R-code swap file (.rcd) � OpenEdge uses this file to dynamically swap
r-code segments
in and out of the execution buffer. Use the r-code usage statistics startup
parameters to
collect information about I/O to the swap file, as explained in the
�Monitoring r-code
activity� section on page 5�5. Using procedure libraries helps reduce the
amount of I/O
required to load r-code files. For more information, see the �Using
procedure libraries to
improve r-code performance� section on page 5�2.
Note: The AVM swaps codepage-converted text segments for procedure libraries
from
the execution buffer to the r-code swap file and reloads the converted text
segments
from the swap file instead of the library when necessary.
If temporary files grow to exceed disk space, change the application to
reduce the size of
temporary files, or use the Temporary Directory (-T) parameter to store the
temporary files on
a disk with sufficient space to hold the files. To optimize performance,
place the temporary files
on a dedicated disk.
--------------------------------------------------
A couple of thoughts here:
1.) We have a TON of these files left over after an orderly shutdown of
OpenEdge and the rcd files can get quite large (500+ MB). We're going to
modify either our shutdown or startup script to delete these files because
they are certainly not getting deleted by OpenEdge.
2.) Has anyone dedicated a disc to this activity? In light of the
discussions of RAID configurations, has anyone moved their OS temp/swap
files to another drive along with the OpenEdge temp files noted above to get
better performance? What RAID configuration would one use for this drive?
Has anyone considered allocating a RAM Drive for the OpenEdge temp files? My
temp folder is 9GB+, so that may take a lot of RAM...
Mark W.
[Non-text portions of this message have been removed]