Hmmm... 1TB is what an initial reading of the manual led me to
believe also, but further excavation into the details shows there is
one more layer of complexity. The 1TB limit is good _only_ if the
journal has one of the *MAXOPT values specified on the RCVSIZOPT
You can specify whatever you like for the receiver's THRESHOLD value,
but if the journal lacks the *MAXOPT value the system will throw
error messages at your operator as soon as the receiver's size
To keep this fix as simple as possible I'll try two options on the
1) set RCVSIZOPT = *RMVINTENT to reduce the number of
'internal' entries in the receiver.
2) set RCVSIZOPT = *MAXOPT1 or *MAXOPT2
to allow the 1TB receiver size
Must make sure these changes don't affect the layout of the *outfile
of DSPJRN before putting them in production. Guess I know what I'll
be doing this evening...
Not to imply testing is worthless... But I can write with effective
certainty, that the size options will not impact the file layout. The
layout is established by what is specified on the parameters of DSPJRN.
Given no changes to the DSPJRN request, the size changes will not be
manifest as differences in the output file, even if *CALC was specified
or defaulted on any of the output file layout related parameters.
Even with larger size options, keeping THRESHOLD(*NONE) will leave
the same condition as an eventual outcome, without having added
monitoring for the warnings that the receiver is going to be full due
either to the maximum sequence or maximum physical size limit. Making
the journal system managed would put the onus on the system to effect
the change, instead of writing an application or having an operator
respond to the warnings. However with the larger maximum size option,
beyond just system managed, it may be prudent to actually specify a
threshold due to the larger maximum physical size.
The default for CRTJRN receiver size option has long since moved to
one of the higher number *MAXOPT values, specifically to avoid the
limitations of the journals that were being created versions ago. In
V5R4 the newest default became *SYSDFT to effect same as
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact