Internet経由でのz/OS PTF入手
一応USなどでは一般的になってるそうです。
日本ではまずありえないですが、メインフレームが直接インターネットにつながっている場合もあるそうです。
日本では、専門の方がPTFをセレクションし、適用を行います。
その際にPTF適用情報として登録を行い、サポートセンターからPTFを媒体でデリバリーしてもらえます。
日本でもInternetからのPTF入手は可能です。
（ただし顧客先のサービスレベルによって異なる。私がなぜ入手できたかはさておき・・・）
まず手順ですが、
これもz/OS DVD導入と同じく、zFSにPTFを一度展開してから実際のPTFがReceiveされます。
同じくpax圧縮がかかっています。
まずはSMP/Eでbitmapと呼ばれる、プロダクト導入情報、PTF適用情報をリストします。
それを元に、Shop zSeriesでこのリストを添付し、特定のPTF、RSUを選択します。
これで自動的にPRE REQとなるPTFも自動的にチョイスされてインターネットでデリバリーされます。
あとはReceive/Applyを行えば、適用が可能になります。
私も緊急的にUnicodeにバグがあるのでいち早くほしいと言われつかいました。
意外に便利。
これからお取り寄せはこっちかな（笑）
まぁLinuxだとサポートに入ってると当たり前のようにInternetからパッチを入手できますがとうとうz/OSまで・・・。
便利になりましたね。
日本ではまずありえないですが、メインフレームが直接インターネットにつながっている場合もあるそうです。
日本では、専門の方がPTFをセレクションし、適用を行います。
その際にPTF適用情報として登録を行い、サポートセンターからPTFを媒体でデリバリーしてもらえます。
日本でもInternetからのPTF入手は可能です。
（ただし顧客先のサービスレベルによって異なる。私がなぜ入手できたかはさておき・・・）
まず手順ですが、
これもz/OS DVD導入と同じく、zFSにPTFを一度展開してから実際のPTFがReceiveされます。
同じくpax圧縮がかかっています。
まずはSMP/Eでbitmapと呼ばれる、プロダクト導入情報、PTF適用情報をリストします。
それを元に、Shop zSeriesでこのリストを添付し、特定のPTF、RSUを選択します。
これで自動的にPRE REQとなるPTFも自動的にチョイスされてインターネットでデリバリーされます。
あとはReceive/Applyを行えば、適用が可能になります。
私も緊急的にUnicodeにバグがあるのでいち早くほしいと言われつかいました。
意外に便利。
これからお取り寄せはこっちかな（笑）
まぁLinuxだとサポートに入ってると当たり前のようにInternetからパッチを入手できますがとうとうz/OSまで・・・。
便利になりましたね。
System zとFCP Disk
汎用機を昔からやっている人からは？？？でしょう。
汎用機といえばDASD！ですから（笑）
サーバーの世界では内蔵Diskがあって、外部Diskとして、FCP Diskを使うのがスタンダードです。
今どきのメインフレームで使うストレージはあくまで論理的に作り出したDASDで、この手のストレージはFCPDisk、DASDを混在して使うことも可能です。
今のSystem z （IBM メインフレーム)にはFCP Diskが接続できて使えてしまいます。
こうなるとそこらのサーバーと全く変わらんという（笑）
厳密には昔からあったのですが、z/Linuxが出てきてからはかなりフューチャーされた感があります。
普通にFCP DiskからBoot(IPL)も可能です。これはサーバーでいうとこのSAN Bootですかね。
DASDだと今は主にFICONで接続されていて複数本のFICONで使用しても１本使えなくても動的にリカバリーをしてくれていて完全仮想化されているのであんまりマルチパスというのを意識しません。
ただ、FCP Diskを複数本のFCPでつなぐとほかのサーバーと同様、OS上でのMultipathでの制御となります。
使うドライバーもいたって一般的なSCSIドライバーを使うので、割とどんなFCP Diskともつながります。
体感的にはDASDよりFCP Diskのほうが早いですね。
DASDだと3390の型式に制約がかかるため、大規模な領域を作るのがかなりめんどくさいですが信頼性は高いです。
一方FCP DiskだとでかいLUNを作ってしまうとそれで終了なんですよね。
たまにz/Linux+OracleでDiskの構成ってどんなのがお勧めですか？と聞かれますが、
個人的には、それほどパフォーマンスは要求されないが信頼性が重要なところはDASDで作ってOracleのDBなんかはFCPDiskでとご提案しております。
Linux自体の信頼性も上がってきたので、大規模なLinuxサーバーとして使う価値は技術的にもありだと思います。
企業さんによっては、メインフレーム部門、サーバー部門と分かれているとこが多いですがここまで来ると垣根がないです。
この辺がまだ浸透してないのはもっと宣伝しないとだめですね（笑）
汎用機といえばDASD！ですから（笑）
サーバーの世界では内蔵Diskがあって、外部Diskとして、FCP Diskを使うのがスタンダードです。
今どきのメインフレームで使うストレージはあくまで論理的に作り出したDASDで、この手のストレージはFCPDisk、DASDを混在して使うことも可能です。
今のSystem z （IBM メインフレーム)にはFCP Diskが接続できて使えてしまいます。
こうなるとそこらのサーバーと全く変わらんという（笑）
厳密には昔からあったのですが、z/Linuxが出てきてからはかなりフューチャーされた感があります。
普通にFCP DiskからBoot(IPL)も可能です。これはサーバーでいうとこのSAN Bootですかね。
DASDだと今は主にFICONで接続されていて複数本のFICONで使用しても１本使えなくても動的にリカバリーをしてくれていて完全仮想化されているのであんまりマルチパスというのを意識しません。
ただ、FCP Diskを複数本のFCPでつなぐとほかのサーバーと同様、OS上でのMultipathでの制御となります。
使うドライバーもいたって一般的なSCSIドライバーを使うので、割とどんなFCP Diskともつながります。
体感的にはDASDよりFCP Diskのほうが早いですね。
DASDだと3390の型式に制約がかかるため、大規模な領域を作るのがかなりめんどくさいですが信頼性は高いです。
一方FCP DiskだとでかいLUNを作ってしまうとそれで終了なんですよね。
たまにz/Linux+OracleでDiskの構成ってどんなのがお勧めですか？と聞かれますが、
個人的には、それほどパフォーマンスは要求されないが信頼性が重要なところはDASDで作ってOracleのDBなんかはFCPDiskでとご提案しております。
Linux自体の信頼性も上がってきたので、大規模なLinuxサーバーとして使う価値は技術的にもありだと思います。
企業さんによっては、メインフレーム部門、サーバー部門と分かれているとこが多いですがここまで来ると垣根がないです。
この辺がまだ浸透してないのはもっと宣伝しないとだめですね（笑）
z/OSの中のUNIX
最近z/OS触っている方ならご存知でしょう。
z/OS(MVS)の中にUNIXが存在していることを。
しかもTelnetでつなげるという・・・。
割と前からあり、OpenMVSとも言われていました。最近は、Unix System Serviceとも呼ばれます。
z/LinuxでJavaが動くのは当たり前ですが、z/OSでもJavaが動きます。
ご丁寧にSDKまで用意されている。もちろんタダ。
これらはすべて、USS上で稼働します。
いわゆる、Unixでいうところのプロセスにあたる部分が、z/OS(MVS)の１アドレス空間して稼働します。
WASもこの仕掛けで動きます。
最近は導入とかもDVD、PTFもインターネットで入手できますが、これらはすべて、USS上のファイルシステムにおいて処理を行います。
ご丁寧にXMLをパースして適用するという・・・。
Javaがないと何もできなくなってしまいました。
この辺の領域になってくると国産メインフレームは太刀打ちできないですね・・・。
W/Wではこの辺あたりがかなり使われているようですが、日本ではやはり旧来のイメージが非常に強いですね。
COBOL/アセンブラ/3270の画面。この辺のイメージでしょうか？
Linuxが動いて、Javaが動いて、動かないのはWindowsくらいでしょうか？
z/LinuxだともちろんOracleも動きます。ご丁寧にRACまで組めます。
途中で放置してますが、Bochsというx86エミュレーターもコンパイルして移植するとかろうじて動きます。
FreeDOSは動きました。WindowsXPあたりになると、ちょっと厳しかったかな・・。
日本でももう少しメインフレームのイメージが変わるといいなと思います。
z/OS(MVS)の中にUNIXが存在していることを。
しかもTelnetでつなげるという・・・。
割と前からあり、OpenMVSとも言われていました。最近は、Unix System Serviceとも呼ばれます。
z/LinuxでJavaが動くのは当たり前ですが、z/OSでもJavaが動きます。
ご丁寧にSDKまで用意されている。もちろんタダ。
これらはすべて、USS上で稼働します。
いわゆる、Unixでいうところのプロセスにあたる部分が、z/OS(MVS)の１アドレス空間して稼働します。
WASもこの仕掛けで動きます。
最近は導入とかもDVD、PTFもインターネットで入手できますが、これらはすべて、USS上のファイルシステムにおいて処理を行います。
ご丁寧にXMLをパースして適用するという・・・。
Javaがないと何もできなくなってしまいました。
この辺の領域になってくると国産メインフレームは太刀打ちできないですね・・・。
W/Wではこの辺あたりがかなり使われているようですが、日本ではやはり旧来のイメージが非常に強いですね。
COBOL/アセンブラ/3270の画面。この辺のイメージでしょうか？
Linuxが動いて、Javaが動いて、動かないのはWindowsくらいでしょうか？
z/LinuxだともちろんOracleも動きます。ご丁寧にRACまで組めます。
途中で放置してますが、Bochsというx86エミュレーターもコンパイルして移植するとかろうじて動きます。
FreeDOSは動きました。WindowsXPあたりになると、ちょっと厳しかったかな・・。
日本でももう少しメインフレームのイメージが変わるといいなと思います。