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

[CRPence <CRPbottle@xxxxxxxxx>]

  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.?