バッチ処理をサーバ環境へダウンサイジングする方法

現在、ホスト環境で稼動しているバッチ処理をサーバ環境へダウンサイジングすることになりました。

とりあえず小さなシステムから試しにダウンサイジングしてみようという感じなので未知数なことが多い状態です。
サーバ作業の経験がないもので困っているので助けていただきたいです。

(1)ホストのJCLの代わりになるものはbatファイルかなと思っているのですが、batファイルの作成について参考になるサイトがあれば教えて下さい。

(2)現在はCOBOLで稼動しているプログラムをc#にしてという指示がきたのですが、c#は教育で勉強しただけで実務となるとちょっと苦しいのでこれも参考になるものがあったら教えて下さい。

(3)同じような経験がある方の体験談をお聞きしたいです。

よろしくお願いします。

No.2 ベストアンサー 回答者： ultraCS 回答日時： 2006/05/17 02:24

最近のホストのバッチは使っていないので自信なしということで、思いついた範囲で、一応、IBM系(HITAC/FACOMを含む)ということで、ACOS4/6やUNISYSだとまたちょっと違いますから。

・DD文でのデバイスの静的割り当て割り当てが使えないので、すべてOPENに書き換える必要があります。

・ホストのようにデバイス間の違いをDD文で吸収するという仕組みはありません。ですから、テープに書いたりテープやカードにパンチ出力したければ、別プロセスが必要になります。

・SYSOUTは一つしか使えません、複数プリンタに出力するようなジョブだと、いったん中間ファイルに書いて改めて出力(多分プログラムが必要)になります。

・使える外部記憶はディスクだけと言っていいです。テープやカードから読んでいる部分は前もってディスク上にコンバートする必要があります。

・VSAMの互換性が低いので、VSAM部分は、大概書き直しになります。COBOL以外の言語にコンバートする際、一番苦労するのがここです。

・ソート/マージは概念自体がありませんから、プログラムを作る必要があります(コマンドのソートは用途が全く違います)。

・プロセスの考え方が全く違います。ホストではイニシエータがJCLデックにプロセスを割り当て、その中でロードモジュールやユーティリティーが呼び出されるので、途中でABENDすれば、何もしなければJOB終了ですが、shell scriptはバッチとは本質的に違います、これは、一つのプロセスが別のプロセスを呼び出すので、それぞれのプログラムは別プロセスになり、ABEND(という言葉は使わないけど)しても、ユーザーが明示的にエラー処理を指示していなければ粛々と次のプロセスが実行され、場合によっては大惨事になります(笑/泣)。

まあ、C#に書き直すのなら、すべて、そこで対処できる問題ですが、C#移行の工数を考えると。富士通や日立が出しているWindows用のCOBOL(OOCOBOL等)という選択もあると思います。
しっかりとしたドキュメントが残っていればそれほど問題ではないでしょうが、世の中にそんなケースは希有ですから(もしそうだとしたら失礼)。
TSSの移行だと画面が大問題になりますが、バッチなら何とかなるはずなので、がんばってください。

この回答へのお礼

ご回答ありがとうございました。

ソートマージの問題は大きいと思います。
あとはデバイスの割り当てなどが問題でしょうか。

Windows用のCOBOLの存在は知っていましたが、
動作とかどうなのでしょうか。
いろいろ制約がありそうでc#でやろうということになったのですが・・・

なんとかがんばってみます。

お礼日時：2006/05/17 14:57

No.4 回答者： jeee 回答日時： 2006/05/18 19:58

(1)について

ホストでは、ジョブのスケジュール機能やプリント出力結果の制御機能等、ジョブやプリント出力結果を効率よく行う機能がありますが、ＵＮＩＸなどではこのような機能が標準ではありませんので、運用設計等に負担が掛かる場合がありますので、(2)の言語変更よりこちらに重点おいた方が良いと思います。

(2)について
ＣＯＢＯＬから他の言語に変更する場合、小数点の取り扱いを注意する必要があります。
ＣＯＢＯＬの小数点は、一般的に固定小数点ですが他の言語では浮動小数点ですので、例えば０．１はＣＯＢＯＬでは０．１と処理されますが、他の言語では近似値としての０．１（実際には０．０９９・・・になると思われます）になりますので、特に制限がない場合には、言語の変更をしない方が良いと思います。
変更する場合、小数点を考慮する必要がある計算では、特に注意する必要があります。
言語特性によっては、ＣＯＢＯＬ等で作成したプログラムを利用する必要が生じます。

この回答へのお礼

返事が遅くなりましたが、ご回答ありがとうございました。
(1)については市販のジョブスケジュールソフトを使おうかなと思っています。小規模なシステムであればbatファイルを手作りでもいけそうですが、規模が大きくなると管理が難しくなると思うので。

(2)については実際に誤差が生じるのはよくないですが、小数点以下の数字はあまり重要としないので特に問題ないと思います。

お礼日時：2006/05/23 08:49

No.3 回答者： ultraCS 回答日時： 2006/05/18 03:58

#2です

Windows用のCOBOLはがんばっていますよ、出しているのが富士通と日立というのでわかるように、ホストの資産を継承することを真剣に考えてくれています。特に画面周りのコンバーターは感謝すら覚えます。PC系から入ったエンジニアにはわからないことを考えているんだあと思います。
それでも、OSの不親切さで苦労はしているようですが、一度アポイントを取って話を聞いてみるのは有意義かもしれません。こういうこと言うと贔屓になるかもしれませんが、なんでもかんでもダウンサイジングをお題目にする営業SEよりよほど誠実な人たちです。
こういうスキルを持った人材が少ないことが本当の危機なんでしょうね。

もう一つ思い出したことがありますが、WindowsやUnixではABENDのステータスをユーザーが知るのは困難です。プログラムの中で注意深くコーディングすれば別ですが、俗に言うx36系のリソース不足のABENDにたいして、unixやWindowsは完全に無力です。また、derailやmemory fault、divide errorについても、頼りにならないコアダンプしか出ず。ホストのエラー時のコアダンプとは話にならないくらい情報量が少ないのです。これは、OSの作り方の問題で、multics当時はサポートしていたのがunixでは省かれたのが大きいですね。windowsだとデバッガで(というより、いにしえのcodeview)くらいしか使えません。

この回答へのお礼

何度もありがとうございます。

ホストメーカは顧客を逃がさないようにがんばっているわけですね。

しかしながら、上司の考えは現在はマイクロソフト中心の世界なのでマイクロソフト製品で作っておいた方が無難だろうということでCOBOLは使わないと思います。

お礼日時：2006/05/18 14:33

No.1 回答者： mac_res 回答日時： 2006/05/16 16:07

メインフレームからPCへ移行しようと言うことでしょうか?

「サーバー環境」が何を指しているか不明確ですが、bat, C# 云々からWindows OSへの移行を考えているってことですね。

まず、WindowsでC#を使ってJCLのようなバッチ環境で作業すると言うイメージを改めたほうがよいでしょう。

GUIによる対話環境に移行するか、さもなければLinuxなどを使いCOBOL環境を温存するかを選択すべきです。

Windows、C#に固執しなくても、Linux+COBOLは移行に当たって十分検討に値するのではないでしょうか?

参考URLに示すとおり、FORTRANもCOBOLもLinux上で使えます。
shell scriptはJCLよりずっと快適なバッチ処理環境を提供します。

参考URL：http://japan.linux.com/enterprise/03/05/28/02162 …

この回答へのお礼

ご回答ありがとうございました。
私の言葉足らずで申し訳ありません。

メインフレームからPCへの移行で間違いありません。
そしてすでに.NET環境で稼動しているGUI環境にバッチ処理を追加することになったのでc#を使用することになりました。

お礼日時：2006/05/17 14:46