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