メモ書き。
クロスプラットフォームなのは、「データセット」だけ。
大変残念なお話ではある。
本質的に単なるテキストファイルなのでどうしようもないSASプログラムの問題はおいておくとしても。
非互換なのが、SASカタログ形式も含まれるのが地味に痛い。
FORMATやMACROなどをふっつーにぶち込んだのが悪いと言えば悪い。たまにPNGなどの画像ファイルも入る訳だが。
プラットフォームの境目は、OSもだがbit数も問題になる。
これ、大変出来が悪いというか何というか。非互換の壁が単に32bitと64bitで壁になってしまう。何で？とは真剣に思う。
UTF-8エンコード下でのSASプログラミングは本当に心臓に悪い。
元々バイト長指定での定義っつーのも悪いんだが（悪い事バッカリだなあ）、想定文字数×３倍を想定する必要があるのが、S-JISの場合の２倍に比べてイメージもしにくいし大変。
無駄に長いしなあ。32767バイト→おおよそ一万字が最大長というのも、正直どうなんだという気はする。
変換で問題になるのは、「データセット名」も「変数名」も「ラベル」も。
データセット名も変数名もSASNameでお願いします。だが、ここら辺の区切りを勝手にSASが拡張し、SAS謹製のものでは平気でぶち込んでくるのが仕方ないのは仕方ないが。
治験関連では一切見たことないが、BIでの分析では平気でその手のデータセットを作って来る。
使い勝手も悪かろうに、とは思うのだが、それ以上に問題になるのが、「この手の非ASCII文字も移行の壁になる」という所。
化けますしラベルはよく切れます。はい。
移行に際してSASのライセンスの二重持ち期間が発生するパターンがががが。
これも大変厄介で、単にバージョンを上げたい・bit数を変えたプラットフォームで、というような話でも、移行期間が契約上の期間に縛られる。無論、32bit環境がなくなれば、非互換のものをどうにかテキスト抜く（フォーマットカタログならデータセットに抜ける）事が出来なくなる。
中途半端なSASの「サポート」が問題。
テクニカルサポートの話じゃなくて。
クロスプラットフォームと言いながら非互換がかなりあるとか、資産移行に関して元の環境から抽出することが必要とか、まあ、結構コアな次元からコンピュータ知っていて初めてピンと来るような話が沢山ある。
これ、2000年代に遭遇してたら、まだ客に理解してもらいやすかったんだが、今だとIT化第一世代の人が退職してたりする為、顧客企業にノウハウ持ってる人も減ってる。
説明するのがホント面倒なんだよね。「当たり前に出来るでしょ？」みたいに思われてるから。
Officeのbit数とSASのbit数をあわせたりあわせなかったりの問題。
ちっと前まではOSがx64化してもOfficeは32bit版というのが結構あったのよ。Officeの64bit版でいくつも障害があったりして。
あ、Officeも32bitと64bitではコンパイル済みのVBAがbitに影響されたりして最悪だったなあ。
この、bit数の違いを対応するのに、「bit数の違いがある場合には、PC File Server経由アクセスで」「そうでない場合には今までどおり」という風にコードが分かれた（機能的にも分割された）という所がまた厄介。
何かxlsxエンジンとかも追加されたけどねえ。
コード側で細かく条件つけて連携したりインポートしたりエクスポートシたり出来ないので（ここの機能制限が本当に腹立たしいのだけど、変数の自動作成＋自動判定をACEエンジンに任せている都合もあって、SASのバグではなくOfficeの機能制限だったりする）、SAS/ACCESS Interface to PC Filesはナカナカ簡単な機能ではなくなってしまってる。
ま、EGに実装されているExcelインポートも、実際の所.net側で特殊区切り文字のテキストファイルにしてからサーバ側で読み書き実行しているので、最早SASから直接Excel読み書きする「べきでない」のかも知れない。
ああ、もう、64bitでも互換性の為に32bitエンジン積んでいるとかでもいいのでそうしておいてほしいなあとは思う。ライセンス料２倍とかは要らんでしょ？
