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

Chuck...

I think you're way over my head...as I didn't follow what you're
trying to say. :)

Receiver size options (RCVSIZOPT)

*RMVINTENT
The size of the receiver attached to the journal is
reduced by automatic removal of the internal entries
required only for initial program load (IPL) or
independent ASP vary on recovery when these entries
are no longer required.

My understanding of the above is that internal entries visible via
DSPJRN INCHIDENT(*YES) can disappear.

Charles


On Thu, Mar 17, 2011 at 12:50 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.