他に代わって質問する事も多々あります。・・・・・・出来れば、「SASテクニカルサポートにお願い出来ない事をこちらに聞かないでほしい」とか思うんだけど。だいぶ病んでます。
SASテクニカルサポートは、運用面でのサポートは引き受けないのが原則。
あそこは、製品のサポートです。
SASは売る時にはカスタマイズ「出来る」と言うんですが、カスタマイズした設定が正しいとか間違ってるとかは、「マニュアル読んで」としか言いません。
ガチな障害であれば、二週間くらいは最低でもかかる＆回避策を飛ばす事もある。
障害を見つけてしまうと、・・・・・・Caryの本社に問い合わせが流れていくんですよね・・・・・・
あくまで原則、なんですが。
SASテクニカルサポートでも、誰に当たるかで回答の方向性が異なる事は多々有ります。
「MSのエラーコードをAMOが拾っているのであって、MSのサポートに確認して下さい」みたいな人と、
「本国に調査を依頼します」みたいな人がいます。
実は両者同じような対応だという事だったりしますが。前者の方が冷たいようですが、実は結構踏み込んで答えてもらっている所でもあります。まずこのパターン、解決不能あるいはパッチが出るパターンです。障害かどうかと言われると、MSの製品のせいもあるかもですしSASの場合もなくはないです。
プログラム開発や保守をしている訳ではないので、SAS Japanで何か解決用のパッチを出せる訳でもない。
回避策を、という場合でも、業務側が考えて回避する事が一番ラクなので、あんまりサポートで対応すべきとも思えないんですよね。
開発のメインルートだと、流石にSASも検証してます。あまり綺麗でない使い方、あるいは、Excelだとマクロ記録してカスタマイズ、みたいなやり方でしている使い方、なんかは、システム開発屋からは見えづらいので、いつまでもバグが残ったりします。
ちょっと綺麗に書くだけでバグってる部分回避出来たりするんだけどー、という所を、頑張っても互いに不幸になるだけだ、とは思います。
あと、SASのソリューション製品の環境を妙にカスタマイズすることは、全くオススメしません。
インストールのオプションの範疇ならわりと分かりやすいですし出来るんですが、アレ、WebServerだとかWebAppServerだとかWebDAVだとかで出来る膨大なパラメータのうち、比較的カンタンに理解されやすい部分だけを抽出しているだけです。
JVMのサイズだとかCacheサイズだとかもぜーんぶ一から設定する事は不可能とは言いませんが、SASがその設定のマニュアルを持っていません（OEMのマニュアルはあるんですがそれもApacheベースとかだとかそういう感じ）し、まるっと売ってるのはそこら辺を自力で構築すると大変面倒だからです。
本来、「/Config/Lev1」とかの下は触るものではない、という風には言われています。
で、このあたりを深掘りして完全なサポートするのは、正直どこの世界に言っても無理じゃないでしょうか。
事前に何が起こるのかとかを設定変更した場合に予測は不可能なんで、故にドライランとか別環境とか持っているものなんですよねえ。
はあ。
