Archive Center writes down every request it serves, and nobody reads it

Somewhere on your Archive Center there is a folder that nobody has looked at since the system went live. A new file appears in it every day and simply stays there. Each one is an ordinary text file, and each one contains a line for every single request the archive answered that day: which document, at what moment, how long it took, how many bytes went back over the wire.

Most organisations meet this folder twice. The first time is when a disk fills up and somebody deletes the oldest few thousand files to make room. The second time is when a question arrives that nobody can answer from anywhere else, usually from an auditor, usually about a document that was opened months ago. By then the answer has been deleted.

This is a short tour of that folder: what the archive writes down, how to read one line of it, and which business questions it settles. You do not need to be an administrator to follow it. You need to know that the file exists, and that it is not cleaned up.

What the archive writes down

Every document in an archived landscape reaches its reader the same way. A user opens an invoice in SAP, a scanner deposits a batch overnight, Content Server checks whether something is still there. All of it becomes a request, Archive Center answers the request, and then it writes one line about what just happened.

One line per request, not per document. Opening a single invoice on screen can produce three or four lines, because the calling system usually asks whether the document exists before it asks for the content, and sometimes asks for its properties afterwards. This catches everybody out the first time they count, and it is the reason a quiet department can look busy.

At midnight the archive starts a new file, named for the date, for example 20260824_WC.acc. These are the accounting files, and people call them ACC files after the extension. Three things about them matter more than the format.

Nothing removes them. Archive Center has no retention setting for its own accounting files, no rotation, no housekeeping job. They accumulate from the day the system was installed until a human deletes them, which is why the deletion usually happens in a hurry during a disk alarm rather than as a decision anyone made.

Nothing backs them up either, unless somebody asked for it. The folder is rarely on a backup list, which turns that hurried deletion into a permanent one.

They contain no documents. No content, no text, no titles, no attribute values, no search terms. Only a description of the request. That is what makes an ACC file safe to copy off the server and hand to an analyst, which is true of very little else in an archive.

To give a sense of scale: the file this post uses holds 20.409 records in 1,7 MB, roughly 83 bytes a line. A busy system handling a million requests a day would write about 80 MB a day, 30 GB a year. Small against the archive itself. Large enough that somebody eventually notices the folder and reaches for the delete key.

Reading one line over the administrator's shoulder

The file explains itself, which is unusual and worth knowing. It opens with a block of notes before the data starts:

################################################################################
# IXOS ARCHIVE VERSION 25.4.0, ACCOUNTING INFORMATION
# Separator        :  <tab>
# Date/Time        :  Mon Aug 24 00:02:00 2026
# Suppressed jobs  :  -1 -7 -25 -26 -33
# Fields (on)      :
#   TimeStamp        (The time of the request in sec. since 1.1.1970)
#   JobNumber*       (The internal number of the request)
...
################################################################################

Most of that is housekeeping. One line is not. Suppressed jobs lists the kinds of request this system has been told not to write down, and on this archive that includes the routine existence checks and monitoring polls. It means the file is an honest record of what it contains and a deliberately incomplete record of everything the archive did. Anybody who reports a request count without reading that line will understate the traffic, sometimes by a factor of several.

Below the notes, the data. Here is one real line, with the tab characters replaced by spaces so it fits on the page:

1787525066  2  222  10.233.82.1  P1      005056166B281FE1A59B1EA3BE9D6093  1  data  197418

It looks like nothing. It is eleven pieces of information, and this is all of them:

Field	Value	What it means
TimeStamp	1787525066	24 August 2026 at 00:44 local time, counted in seconds since 1970
JobNumber	2	The verb. 2 means somebody read a document
RequestTime	222	The archive spent 222 thousandths of a second on it
ClientAddress	10.233.82.1	Where the request came from
ContentServer	P1	Which logical archive, despite the confusing name
UserId	empty	Who asked. In this case, nobody knows
ApplicationId	empty	Which system asked. Also blank
DocumentId	005056166B28…	The document, matching ARC_DOC_ID in the SAP link tables
NumComponents	1	How many parts of the document were involved
ComponentId	data	The content itself, rather than a note or a set of properties
ContentLength	197418	193 kB left the archive

Two of those eleven fields are empty, and that turns out to matter more than the nine that are filled. We will come back to it.

The number in the second column

Everything interesting hangs off JobNumber. It is the verb of the sentence, written as a number because the archive was designed by people who were paying for disk by the megabyte. Learn five of them and you can read almost any accounting file:

Job	Operation	What happened
2	GETCOMP	Something was read. The most important number in the file
7	INFO	Somebody checked whether a document exists. High volume, often suppressed
9	CREATE	Something was stored
20	DELETE	Something was deleted. On a records-managed archive this should be zero
23	MCREATE	A bulk load. The fingerprint of a migration

The rest is reference material, useful on the day you meet an unfamiliar number rather than something to memorise. Document handling first:

Job	Operation	Job	Operation
3	PUTCOMP	13	SEARCHATTR
4	CREATECOMP	14	SEARCH
5	UPDCOMP	15	SEARCHFREE
6	APPCOMP	16	DGET
8	PUT	17	GETATTR
10	UPDATE	18	SETATT
11	LOCK	19	DELATTR
12	UNLOCK	35	RESERVEID
		36	SETDOCFLAG

Then security, administration and long term signatures:

Job	Operation	Job	Operation
24	PUTCERT	34	ANALYZE_SEC
25	ADMINFO	37	ADS_GETATS
26	SRVINFO	38	ADS_VERIFYATS
27	CSRVINFO	39	ADS_MIGRATE
28	VALIDUSER	40	ADS_DOCHISTORY
29	VERIFYSIG	41	ADS_CREPLACEH
31	SIGNURL	42	ADS_CSRVINF02
32	GETCERT

A number that appears in neither table is internal to the product or new in a release. It is worth noticing rather than ignoring, because an upgrade is exactly when one turns up.

Four questions the file settles

What follows comes from a single ordinary Tuesday at a Dutch organisation running Archive Center 25.4: 20.409 records, fifteen logical archives, four kinds of request, and not one user id.

Is anyone actually reading what we archive?

This is the question behind every storage budget and every archive that nobody wants to own. Sorting one day by logical archive answers it directly.

Archive	Requests	Reads	MB moved
V1	6.322	4.349	1.543
A0	5.454	2.726	888
S2	2.937	846	740
00	2.880	0	0
S1	1.362	172	174
F2	510	230	117
P1	387	376	4.018
eight others	557	76	129

Three readings, and all three are ordinary.

V1 is the healthy one: 69 percent of its traffic is people reading, so the content there is part of somebody's working day. S1 is 13 percent reads. It is being filled steadily and consulted rarely, which is the honest profile of content that belongs on slower and cheaper storage. That is not a criticism of S1. It is the beginning of a business case, and it is the difference between moving content because someone had a hunch and moving it because a year of measurement said so.

Then there is 00, with 2.880 writes and not a single read. It is not a business archive at all. It is the system checking on itself, writing and then updating a fourteen byte document once a minute, around the clock, forever. That accounts for 14 percent of the entire day's records. Every archive has something like it, and anybody who reports a request count without removing it first has inflated their own numbers.

And P1 is the reason request counts should never reach a storage conversation on their own. It produced under two percent of the day's requests and moved 4,0 GB, more than every other archive combined, because the documents in it are large. Requests measure how busy a system is. Bytes measure what it costs. They are different questions and they rank the archives differently.

Who opened that document?

Sometimes the file answers this beautifully. On the Tuesday above, it cannot answer it at all.

UserId was empty on all 20.409 lines. Not hidden, not anonymised, simply never supplied, because the connection between SAP and the archive uses one technical account and passes no individual through. The archive faithfully wrote down the name of the person, and the name of the person was nothing.

ClientAddress does not rescue it. Every one of those 20.409 requests arrived from one of three addresses, because the traffic passes through a gateway. In the file, the entire organisation looks like the same computer.

This is worth checking on your own system today rather than during an incident, because it is not something an administrator can fix afterwards. Whether the archive can name the reader was decided years ago, when somebody chose a technical account over a real one, and it is usually a decision nobody remembers making.

The archive already knows who read which document. The only question is whether anyone looked before the auditor did.

— an investigation that came down to one text file nobody had kept

Where the field is populated, the most valuable thing to do with it is also the simplest. Count reads per person per hour. A person opening documents and a script extracting them look nothing alike, and the difference is obvious in the first result. That is bulk extraction detection, built out of a file you already have.

Why does it feel slow?

RequestTime is the honest answer, because it measures only the archive. Not the network, not the SAP screen, not the browser. Just the seconds the archive itself was working.

Operation	Requests	Median	95th percentile
GETCOMP	8.775	53 ms	364 ms
CREATECOMP	6.001	192 ms	463 ms
CREATE	4.193	130 ms	257 ms
UPDATE	1.440	196 ms	320 ms

The two columns on the right need a word of explanation, because they are the standard way performance is described and they are not obvious.

Take every read of the day, all 8.775 of them, and line them up from fastest to slowest. The median is the one in the middle: half of all reads were quicker than 53 milliseconds, half were slower. The 95th percentile is the one 95 percent of the way along the line: 364 milliseconds, meaning roughly 8.336 reads finished inside that and the slowest 439 did not.

That second number exists because the two figures people normally reach for both mislead. An average is dragged upward by a handful of enormous documents, so it ends up describing an experience nobody actually had. The slowest request of the day describes one unlucky moment out of nearly nine thousand. The 95th percentile sits between them and answers what people really mean when they complain: not how fast is it usually, but how bad does it get for the unluckiest one in twenty. When the median and the 95th percentile are close together, the system behaves consistently. When they are far apart, something intermittent is going on and it is worth finding.

Here they are seven times apart, which sounds worse than it is. The slowest single request of the day took 22,6 seconds, and the same line records why: the document was 20,8 MB. The archive delivered roughly 0,9 MB per second and did nothing wrong. Plot a full day of reads against document size and the points fall along a straight diagonal, which is what a healthy archive looks like. Big documents take longer. Small ones do not.

Which is exactly why this matters to a business reader. When somebody reports that a 200 kB invoice took forty seconds to open, this file is how you establish, in an afternoon and without a project, that the archive spent 53 milliseconds on it and the other 39,9 seconds happened somewhere else. Most of the time the archive gets blamed because it is the last thing in the chain and the easiest thing to name.

What will this cost us next year?

Add up ContentLength per archive per month and you have a growth curve built from measurement rather than from a sizing spreadsheet written before go-live. Do the same by hour of day and you have the real load profile: this system sits under 200 requests an hour overnight, wakes up at 07:00, holds around 1.500 through the working day and peaks at 2.472 between four and five in the afternoon.

Both numbers change conversations. The growth curve turns a budget discussion from an estimate into an observation. The load profile means a migration window or a storage move is chosen from evidence, and it explains, afterwards, why the last one at four in the afternoon generated complaints.

What the file cannot do

It is not an audit trail, and it should never be introduced as one. It is an ordinary writable text file sitting on a server, and anybody with administrative access to that server can edit it. That makes it excellent monitoring and weak evidence. If you want it to carry evidential weight, the lines have to leave the machine quickly and land somewhere the archive administrators cannot write to.

It is also personal data when the user field is populated, and it holds network addresses either way, so it needs a documented purpose and a retention period like any other record of who did what. The awkward part is that it currently has neither, because nobody decided to keep it. It just accumulated.

And it only knows what it was told to write down. The suppressed jobs in the header, the empty user field, the gateway address standing in for four thousand people: none of those are failures of the file. They are decisions made elsewhere in the landscape, faithfully recorded.

---

The folder is still there, on your system, filling up at about 80 MB a day. Nobody has to build anything to start using it. The first useful step is smaller than a project: find out whether the user field on your archive is populated or empty, and find out how far back the oldest file goes. Those two answers tell you what questions this archive will ever be able to settle, and how much of its history you have already thrown away.