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

On 3/17/11 11:18 AM, Charles Wilt wrote:

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

  Just think objects and the methods that can applied to the object or
the data ["within" the object].  The methods are exposed to the OS and
optionally even to the user by some callable interface.  Any method
exposed to the OS from the LIC can be utilized by a user even lacking a
provided callable interface.  Thus to maintain integrity of the system,
methods that are potentially hazardous to the integrity of the OS
[feature] would not typically be exposed, not even to the OS; I will
ignore "blocked" instructions entirely, as that is not germane, in case
some[one] might want to interject.  The LIC is another world entirely,
having its own methods [or just about any mucking about even outside of
the concept of methods] as applied to the objects\data.

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.

  What the LIC can do, does not reflect what the OS code or user code
can accomplish by available methods.  That attribute simply informs the
LIC journal component that any internal entries deposited strictly for
that component's temporary purposes can be removed, but no remove-entry
method need have been exposed to the OS for that to happen, since the
LIC does all the work to implement that below the MI interface.  FWiW
that attribute is also specific to any receiver such that all entries in
any one receiver follow the same rule; a CHGJRN would need to specify or
generate a new receiver to apply that attribute to the new receiver to
which the journal is attached.  So the method provided to the OS in that
case was to assign\activate that attribute to a journal when the
effective attach-receiver method is invoked, rather than the OS invoking
some remove-entry method each time an [internal] entry is deemed
removable by the OS journal component [or by some rogue user code].

Regards, Chuck
--
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.