Re: DSPJRN OUTPUT(*OUTFILE) and resulting record length

If the OS journal code could remove an entry such that a non-send [e.g. delete or update] method existed for use by that OS journal code, then that same invocation could be discovered and reverse-engineered. Then some non-OS code could generate that same invocation as a "feature" via that non-OS code, thus violating the integrity of the journal environment; e.g. hacker invokes that function to remove a T-AF entry just deposited by that hacker. Thus I can only conclude that no such method [would] exists. There is little reason to expect that once an entry is deposited, there would ever be the capability to remove or alter that entry, just as purported in documentation about the integrity provided by the OS [journaling feature].

While the LIC journal feature could do that [or anything it desired for that matter] regardless of whether any method was exposed to the OS, there would surely be a means to ensure that the LIC-only data from their own effectively removable entries were never made available to the OS journal component via read methods, specifically to prevent such problems with the OS seeing something never intended. As it is, there are already "internal entries" which are available to the read method provided to the OS, so I would see little reason for the LIC to have additionally some private-internal-entries.

Regards, Chuck

On 3/17/11 5:08 AM, Charles Wilt wrote:

I assume you mean a "non-OS placeholder entry" since the OS can
remove its own internal entries....

I could see where it might be useful to allow U-User entries to be
removed, just like system internal entries...but that doesn't appear
to be possible.

On Wed, Mar 16, 2011 at 9:45 PM, CRPence wrote:

A "placeholder entry" seems questionable as a conclusion, given
that there is only the one method of send\write for the journal
entry via the journal into the attached journal receiver.? That
conclusion would have to suppose there was either a change-entry or
remove-entry method, either of which would be problematic for the
supposed integrity of the journal feature as a means to implement
security auditing.?