× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Chuck,

Thanks. You are, of course, correct. Changing RCVSIZOPT to *SYSDFT (i.e.:
*MAXOPT2 *RMVINTENT) does not change the layout of the DSPJRN *OUTFILE. I
wanted to be extra cautious since I'd been sorely abused during the day due
to all those SYSOPR messages...

JK

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Sunday, September 07, 2008 10:07 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPF7091 - space for entry cannot be allocated on journal
receiver

johnking@xxxxxxx wrote:
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
parameter.

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
approaches 1.9G.

To keep this fix as simple as possible I'll try two options on the
CHGJRN:
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
RCVSIZOPT(*MAXOPT2 *RMVINTENT)
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaki/rzakiwha
tsnew.htm
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzaki/rzakisiz
eoptions.htm

Regards, Chuck



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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 [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.