なんちゃってSEメモ

kshで引数で文字列を渡す際の注意点メモ

2010-11-02T12:53:00.001+09:00

kshで引数で改行を含む文字列の引数を渡す際の注意点。

変数hogeの内容が以下とする。
hoge：
AAA A
BBB B
CCC C

3行の文字列である。

これを、関数：kanに引数として渡す場合、

kan ${hoge}

とすると、1行目の1単語目、つまりAAAしか渡されない。
文字列として明示して関数に引数を渡せば、全行の文字列を渡せた。
kan "${hoge}"

改行を含む文字列の出力。
echoなどで改行を含む文字列の変数の内容を出力する際、明示的に文字列と示すこと。
echo ${hoge}

これだと、
AAA ABBB BCCC C
となり、改行されていない文字列となる。
ダブルクォートでくくり、明示的に文字列とすると、ちゃんと改行された文字列が出力された。
echo "${hoge}"

AIXの/etc下のfb_*ファイルは何？

2010-10-30T14:44:00.000+09:00

アドバンスト

技術情報にこんな記述が。

まず /usr/sbin/fbcheckというスクリプトがinittabから呼ばれます。
このスクリプトの機能は、もしそのシステムが /etc以下にfirstbootというファイルを持っていれば
/etc/fb_04_18_03_01といったファイル名に書き換え（mv）、その時点で一度実行し、もう一度このファイルが実行されない様にします。
したがって一度実行されてしまえば使われることはないはずです。
/etc/firstbootファイルは、クライアント環境を変えるためのファーストブートの際に使用されるスクリプトです。

https://www-06.ibm.com/jp/domino01/sl/alsl390.nsf/AllSearch/F569DE86F90C4E504925682B00420875?OpenDocument

クライアント環境を変える際の再起動の度に増えていくファイルみたい。よって、履歴としてみる必要なければ消して良し。

MQのメッセージと同期点処理メモ

2010-10-28T12:58:00.000+09:00

■メッセージ
MQでデータを扱う単位で、テキストとバイナリの2種類を扱うことが出来、V5.1以降では1メッセージ100MBまで。

メッセージは、「ヘッダ部(MQMDと呼ばれる構造体)」と「データ部」を持つ。

ヘッダ部で代表的というか良く効く属性。
・Expiry
メッセージの有効期限。キューに書き込まれてから指定の時間を過ぎて何も行われなかった場合、キューから削除される。
・CodeCharSetId
俗にいうCCSID。ここで指定したコードに受信側でコード変換をする。
・MsgIdとCorrelId
一意なIDを付与し、複数メッセージを管理する。
任意に指定することも出来るし、キューマネージャに自動生成させることも出来る。
・ReplyToQとReplyToQMgr
送信したキューの結果を受け取るキューとキューマネージャを指定する場所。

キューマネージャによるデータ変換機能
・MQMD.FormatでMQFMT_STRNIGを指定し、全てがテキストデータである事を表している場合変換される。
以下のパターンの場合、文字変換をしない
①シングルバイト文字とダブルバイト文字の区切りを表すSOとSIが1メッセージ中に揃っていない場合
②ダブルバイトの文字列をシングルバイトへ変換しようとした場合
これらの場合で変換したい場合、キューマネージャにやらせずアプリなどで独自に行わせること。

パーシスタント・メッセージとノン・パーシスタント・メッセージ
・パーシスタント・メッセージ
まずログに書き込みを行い、その後にキューのファイルに書き込みに行く。
物理的にデータを取っておくので、テークオーバーなどが発生した場合にリカバリーをした際に、以前の状態で再開できる。
・ノン・パーシスタント・メッセージ
メモリーに書き込みを行い、メモリーから溢れた場合のみキューのファイルに書き込みに行く。
リブートなどをした場合は、当然以前の状態には戻らない。

■同期点処理
考え方は、DBと同じ。
COMMITをすれば確定し、ROLLBACKすれば以前の状態に戻る。
つまり、キューからメッセージを取り出して処理をしていったが、完了前にエラーとなり最初から再度処理を行わなくてはならない場合、処理の最初の状態、つまりキューにメッセージが入っていた状態に戻るという事。
トランザクション・マネージャとして、CICSなどがある。
WASでDBとの連携する場合、XAで2フェーズコミットを実現。

QMIDって？

2010-08-04T01:16:00.002+09:00

設計書どおり、MQの設定がされているかの検証をする事に。

MQパラメータチェックをしていて、キューマネージャの属性のQMIDで、キューマネージャと日時でつけたとおぼしき値があった。
MQ導入者が入力したのかわからないので調べてみたら、キューマネージャが内部で生成した値らしい。
よって、パラメータチェックの対象から外しました。

まぁ、よく考えてみるとQMerのIDって事で、ユニークなIDを自動生成しただけのことなんだな。

QMID についてのインフォメーションセンター内容
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.explorer.doc/e_properties_qmanager.htm?resultof=%22%51%4d%49%44%22%20%22%71%6d%69%64%22%20

MQ V7の監視対象プロセスって何？

2010-08-04T00:57:00.010+09:00

MQ自体良く知らないのに、MQ V7のプロセス管理を考える機会に恵まれ（？）ました。
さっぱり何をしたら良いのかわからないから、ちょっと調べてみた。

こんな資料が目に付いた。
MQ設計虎の巻: 第8回「トラブル・シューティング」
http://www.ibm.com/developerworks/jp/websphere/library/wmq/toranomaki/8.html

4.1 MQ関連のシステムプロセスの確認
で、MQ V7でのプロセス監視についてふれられていた。
しかし、「環境によっては、すべてのプロセスが起動しているわけではありませんので、正常稼動時のプロセス状態を事前に取得しておくといいでしょう。」
という玉虫色の回答で終わっていた。

MQ V7のプロセスとしてあげられていたプロセスは以下。
名前も意味も初見だったので、メモっておこう。

　amqzxma0 実行コントローラー
　amqzlaa0 キュー・マネージャー・エージェント
　amqzmuc0　クリティカル・サービス　(V7)
　amqfcxba　Pub/Subストリーム (V7)
　amqzmur0 再始動可能サービス (V7)
　amqzmgr0 外部プロセス (V7)
　amqfqpub　V6互換Pub/Sub　
　amqrrmfa リポジトリー・マネージャー
　amqzmuf0 Pub/Subユーティリティー
　amqzfuma OAM プロセス

　runmqchi チャネルイニシエーター　
　runmqlsr リスナー
　amqzdmaa 据え置きメッセージ・プロセッサー
　amqrmppa 受信側のチャネル
　amqpcsea コマンド・サーバー

なお、別の資料になるが、V6についてはそれなりに監視対象プロセスについて書いてあるPDFを見つけた。
WebSphere MQ 入門書
「第12章WebSphere MQの監視(キュー・マネージャーとキューの監視)」
http://www.ibm.com/developerworks/jp/websphere/library/wmq/mq_intro/
にて、
プロセス・ダウンがキュー・マネージャーの稼働に影響を与えるものは、
　amqzxma0
　amqzmuc0
　amqzmur0 (プロセスがダウンすると再起動するので、必須ではありません)
　amqzfuma
　amqzmgr0

場合によって、影響を与える可能性があるものとして、以下のプロセスと記載してあった。
　amqpcsea (コマンド・サーバー使用時は必須)
　runmqtrm (トリガー・モニター使用時は必須)
　amqrrmfa (キュー・マネージャー・クラスター使用時は必須)
　runmqchi (監視を推奨)
　runmqlsr (監視を推奨)

V7と重なる部分が多いので、かなり絞れてきた気がする。

IBMのサポートにて、監視対象を質問しているものがあったので、そちらも見てみた。
「MQ: IBM Directorを使用した監視」
http://www-01.ibm.com/support/docview.wss?uid=std34c442aa0510ee6dd4925750700143121
では、Windows版ながらV6とV7の監視について、以下のようになっていた。
<監視が必須となるプロセス>
　amqzxma0.exe ：実行コントローラー
　amqzmuc0.exe ：重要なプロセス・マネージャー
　amqzfuma.exe ： OAMプロセス
　amqxssvn.exe ：共用メモリー・サーバー

<環境に応じて監視が必要となるプロセス>
　amqrrmfa.exe ：リポジトリー・マネージャー（MQクラスターを使用しているときは監視必須）
　amqzmgr0.exe ：サービス・マネージャー（MQリスナーなどの関連コンポーネントの自動起動/停止しているときは監視必須）
　runmqlsr.exe ： MQリスナー
　amqpcsea.exe ：コマンド・サーバー
　runmqchi.exe ：チャネル・イシニエーター
　runmqtrm.exe ：トリガー・モニター
　 amqfcxba.exe ：ブローカー・ワーカー・ジョブ（v7のPub/Subで使用）
　 amqfqpub.exe ：キューに入れられたパブリッシュ/サブスクライブ・デーモン（V7のPub/Subで使用）

結論

☆必須☆
　amqzxma0.exe ：実行コントローラー
　amqzmuc0.exe ：重要なプロセス・マネージャー
　amqzfuma.exe ： OAMプロセス

○条件付き必須（環境次第）○
　amqzmgr0.exe ：サービス・マネージャー（MQ リスナーなどの関連コンポーネントの自動起動/停止しているときは監視必須）
　 amqpcsea (コマンド・サーバー使用時は必須)
　amqrrmfa (キュー・マネージャー・クラスター使用時は必須)
　amqfcxba.exe ：ブローカー・ワーカー・ジョブ（v7のPub/Subで使用）
　amqfqpub.exe ：キューに入れられたパブリッシュ/サブスクライブ・デーモン（V7のPub/Subで使用）
　 amqzmuf0 Pub/Subユーティリティー

△推奨△
　runmqchi (監視を推奨)
　runmqlsr (監視を推奨)

amqzmur0とamqzdmaa は自動再起動されるプロセスなので、監視不要。

とした。

各プロセスの概要についてもよくわからないので、先のV6の第12章WebSphere MQの監視」PDFを見るか、インフォメーション・センターを見てみた。PDFの方が、プロセス同士の関係や詳細がわかり、ためになったな。
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.amqwag.doc/ia11210_.htm

しかし、クラスターを使わなかったり、環境に応じて違うというのはもっとももな気がするので、amqfcxba、amqfqpubは場合によるのかな。
ちなみに、プロセスが予期せずして落ちた場合に、勝手に起動してくる場合がありますが、その場合はキューマネージャーやコントローラーを停止しても、なぜかそれは一緒に落としてくれなかったりしました。
この時は残ったプロセスはkill -9で消さないと、次にキューマネージャーが立ち上がらないので（プロセスが残っていると、立ち上がらない仕様みたいだから）、気をつけないと。
windowsは、キューマネージャを落としてもプロセス残っていたら、システムをリブートして下さいと言うのをみたんですが、なかなか凄い事をいうものです。