JVM と Windows の間のどこかに問題があり、質問をするのに十分な知識がないのではないかと心配していますが、次のようになります。
Javaプロセスを起動し、そのSTDOUTおよびSTDERRストリームをSASの名前付きパイプの概念にリダイレクトするJava以外のコード（SAS SCLコードですが、これに答えるのにSASの知識は必要ないことを願っています）があります. その Java プロセスは、テキストを System.out に書き込みます。次に、SAS コードはパイプからそのテキストを読み取ろうとします。
これは多くのシステムで長い間機能していましたが、最近 Windows で問題が発生しました。問題は、Java 7 に固有のものである可能性があります (ただし、Java 6 も同様である可能性があります)、および/またはWindows 7 以降に固有のものである可能性があります。
このコードを呼び出すコンテキストは 2 つあります。あるコンテキストでは、うまく機能します。もう 1 つの場合、SAS は Java プロセスからの出力を認識しません (他の出力に基づいて正常に実行されているように見えます)。機能しない場合、「fread」呼び出しは、Java プロセスが完了するまでブロックされているように見えます。ただし、その呼び出しは「EOF」を返すだけです。
（具体的には、SAS Workspace Serverプロセスから実行すると機能します。バッチモードSASから実行すると機能しません。プロセスの所有者は異なりますが、これら2つの環境の正確な違いはわかりません. )
それが機能しない場合、SAS が表示するはずの STDOUT 出力を含む Windows コンソール ウィンドウが簡単に表示されますが、表示されません。それが機能する場合、そのようなウィンドウは表示されませんが、ログインしているユーザーとは異なる OS ユーザーでプロセスが実行されている可能性があります。
以上のことから、私の質問は次のとおりだと思います。JVM は、STDOUT の最終的な場所をどのように判断するのでしょうか? JVM は、SAS パイプに接続された目的の STDOUT ストリームではなく、コンソール ウィンドウに出力を書き込んでいる可能性がありますか? この決定を行う際に JVM が調べる環境の顕著な側面は何ですか?
編集 2013-02-20:
さらに調査すると、Java プロセスを起動するときに、SAS が次のことを行うことがわかります。
cmd /C <java command>
これは、コードが実行される両方のコンテキストで行われます。
私は Java 5 でテストしましたが、動作は Java 7 と同じです。これは Java のバージョン固有のものではないようです。
Windows 7 以降が共通のスレッドです。これは、Windows 7/Windows Server 2008 R2 で追加された新しい ConHost.exe プロセスに関連していると推測しています。