ここでは、みなさんから寄せられた情報を、まとめてみました。みなさんのお名前は、伏せさせていただきます。メールを下さった方、この場をお借りして、御礼申し上げます！
文中で、斜体の文章は、私からのコメントです。
ところで、Zeller の公式の有効範囲は1583年からと記述がありますが、一つ気になるところがあります。
1752年9月は、11日ほどごそっとなくなっています。何の理由だかちょっと忘れましたが、Solaris
などではこれをサポートしていて、こんなふうに出力されます。
% cal 9 1752
1752年 9月
日 月 火 水 木 金 土
1 2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Zeller の公式では、9/1, 9/2
について、これと異なる曜日が計算されます。9/1 は金曜、9/2
は土曜と計算されます。これはSolaris かZeller
かのどちらかが間違っているということですが、、、
ということで、気になることなのでした。
またこの方からの、フォローアップメールで、Solarisサイドでは、9/3
- 9/13の11日間を閏年の調整による、欠乏と説明しているようです。でも、閏年にまつわるグレゴリー歴の制定では、1582年10月５日より14日までの10日を暦から除いたので、1752年になにがあったのか、SK様同様、不可解です。下のgif画像は、EXCELでの確認画面です。
 追記 1999/4/29
分かりました。1752年9月3日から13日の11日間は、イギリス議会が旧（ユリウス）暦をグレゴリウス暦に合わせるために、除いたものでした。1582年のは、ローマ教皇グレゴリウスが暦のずれをただすため、10月5日から14日を除いたものでした。全世界が一様に、行ったわけではないのですね。やれやれ。この関連の書籍は、こちらを見て下さい。
ＭＫ様より
最近、XXXシステムでジャーナルがパンクする事件が２回 起きました。
XXXではＤＢ更新のレスポンス向上の為にデータベースとジャーナルのディスクを物理的に分けており、ジャーナル用のディスクは余裕を見て８.４ＧＢ 割り当てていたが、パンク時のディスク使用率は２回とも約２４％でした。また、ジャーナルも*NOMAX（無限大）と指定していたので、何故パンクしたのか ＩＢＭに調査依頼したところ、「ジャーナルは無限大と指定しても最大値は２ＧＢである（AS/400の仕様）」との回答でした。（8.4GBx24%=2GBで納得）
日常業務でジャーナルを２ＧＢ書き出すシステム(利用者数・業務量)はXXX だけかと思うので対応方法はここでは省略しますが、他部門でも「ジャーナルは 無限大に指定してあるので心配いらない」と思って、日中（シ゛ャーナル稼働中）にジャーナルされているデータベースを大量に更新する処理（リカバリー等）を流すと同じ『罠』にはまり、
１．ジャーナルがパンクした時は、その時の事情に関わらず一度全業務を終了させてジャーナルを切り離さないと業務が再開出来ない。
２．パンク時にＤＢ更新途中の業務が有るとリカバリー処理が大変になる。こういった場合のリカバリー手順は準備していない。
どうやら、ジャーナルレシーバのサイズ指定（THERSHOLD)のようですね。マニュアルを参照しみましょう。
1.6.110 CRTJRNRCV(ジャーナル・レシーバー作成)コマンド
THRESHOLD
ジャーナル・レシーバーの記憶域限界値 (KB 単位)
を指定します。ジャーナル処理中に限界値を越えると、次のうちの
1 つが行われます。
ジャーナルがMNGRCV(*USER)属性をもっている場合、メッセージCPF7099が、ジャーナル・メッセージ待ち行列に送信されます。
ジャーナルがMNGRCV(*SYSTEM)
属性をもっている場合、システムは、新しいレシーバーを作成してから接続しようとします。以前のレシーバーが切り離されると、メッセージCPF7020が、ジャーナル・メッセージ待ち行列に送信されます。この試みがロックの対立が原因で失敗した場合は、システムはメッセージ
CPI70E5 を出し、ジャーナル操作の変更が成功するまで、10分おきに再試行します。
システムがジャーナルに MNGRCV(*SYSTEM)
属性があるかどうか判定できないときか、または、新しいジャーナル・レシーバーを作成して接続しようとする試みが、ロックの競合のために失敗する場合には、メッセージ
CPI70E3 が送信されます。
ジャーナル・メッセージ待ち行列は、CRTJRN (ジャーナル作成)
またはCHGJRN (ジャーナル変更) コマンドに指定されます。
注: MNGRCVパラメーターの値は、CRTJRNまたはCHGJRNコマンドのジャーナルに指定されます。システム・ジャーナル変更管理(*SYSTEM)
を指定しないで、限界値を越えると、CHGJRNコマンドを出すなどの処置を取ることがあります。
*NONE:
限界値は指定されません。このレシーバーをジャーナルに接続するときは、メッセージCPF7099は送信されず、MNGRCV(*SYSTEM)を指定することはできません。
限界値:1から1920000までの範囲の値(キロバイト(KB)単位)を、記憶域として指定してください。1000KBごとに、1,024,000バイトを記憶域として指定することになります。ジャーナル・レシーバーのスペース・サイズが、この値により指定したサイズよりも大きい場合は、識別されるメッセージ待ち行列(適用可能であれば)にメッセージが送信され、ジャーナル処理が続行します。
注:
1. 限界値は5000以上をおすすめします。そうでなければ、限界値を越えたというメッセージが頻繁に出される可能性があります。また、限界値が小さすぎると、ジャーナル作成(CRTJRN)
コマ
ンドまたはジャーナル変更 (CHGJRN)
コマンドで、ジャーナル・レシーバーをジャーナルに接続する際に、限界値を越えたというメッセージが出される場合があります。
2.
システム・ジャーナル変更管理サポートの使用を予定している場合は、限界値は最低でも
5000KBにしなければなりません。
かろうじて、1920000KBというサイズが出ていましたが、確かに、*NOMAXでも、ここまでのサイズと読むのは、苦しいですね。1920000KB=1875MB=1.8ＧＢですね。
“９．３３
ＳＴＲＰＣＯの気になるメッセージを変えよう”の中で“必要なＰＣプログラム（ＰＣＯ．ＥＸＥ）・・・・・・”というメッセージがでてくるのが気になるのであれば、このメッセージを出なくすればよいのではないでしょうか
方法
パーソナルコミュニケーションズのＡＳ／４００接続時に起動するファイル（“ｘｘｘｘ．ｗｓ“）をメモ帳などで開いて次の行を追加してください
[5250]セクションの最後に“SuppressPCoScreen=True”を追加（大文字小文字関係あり）
さらに
TCP/IP接続のときは上記で良いのですが、それ以外のときは最後の“True”を“true”と小文字にしてください。
例
[5250]
System36=N
ScreenSize$x80
SessionType=Display
HostGraphics=N
HostCodePage？-JK
WorkStationID=
PartnerLU=APPN.
LocalLU=APPN.
StatusIcon=Show
AutoLogon=N
BypassSignon=N
UserProfile=
MsgQueue=QSYSOPR
MsgLibrary=*LIBL
HostFont=Courier10
HostPrintTransform=N
ASCII899=N
ManufacturerType=*IBM3812
PaperSource1=*MFRTYPMDL
PaperSource2=*NONE
EnvelopType=*NONE
WsObject=QWPDEFAULT
WsLibrary=*LIBL
CPName=N
PrinterType=IBM3812
SuppressPCoScreen=True
ちなみにこの方法はＩＢＭアンサーラインよりの入手情報です。
なるほど。メッセージを抑止してしまおう、と言うものですね。メッセージを変更するより、止めてしまおう、というのも、手ですね。CAの方は、出来るのかな？
これからも、皆さんからの情報をお待ちしています！
1999/1/23 | 
