若いプログラマーはなぜメインフレームに興味がないのですか？
メインフレームの重要な問題は、プログラマーをサポートするコホートが減少していることです。通常、これはプログラマーの供給の減少が給与の増加によって相殺され、需要と供給の法則を介してプログラマーの供給の増加を引き起こすという点では問題にはなりませんが、これが本当に起こっているのかはわかりませんメインフレーム。
彼らは依然として多くの企業にとって重要なインフラストラクチャを形成していますが、単純な事実は、サポート人口を維持するためにやって来る十分な数の若いプログラマーがいないことです。
どうしてこれなの？メインフレームが若いプログラマにとって魅力がないのはなぜですか？
私は古いプログラマーであり、メインフレームには興味がありません。私の理由はおそらく、若いプログラマーによって与えられた理由と似ていますが、これらの答えの多くで明らかなテクノロジーを知らないわけではありません。
まず、無知を片付けましょう：
- メインフレームを試すことができないというさまざまな主張は誤りです。 Hercules は1999年以来利用可能であり、おそらく多くの回答者がプログラミングを行っているよりも長い間です。そして、IBMがそれを騒いでいるにもかかわらず、すぐになくなる可能性はごくわずかです（特にオープンソースであることを考えると） ）。実際、高価なソフトウェアを（合法的に）実行できないことは事実ですが、canで実行できるソフトウェアはたくさんあります、実際にはまだかなり一般的に使用されているソフトウェアを含みます。
- 繰り返しになりますが、世論とは異なり、メインフレームにはCOBOL、CICS、RPG2よりも多くの機能があります。確かに、Linuxを実行しているPCで実行できるほとんどすべての（まったくそうではない）ものは、メインフレームで実行できます。 <irony> 理由はわかりません </ irony>
では、メインフレームを学校で遭遇した後、一生ずっと避けてきたのはなぜですか。上手：
- メインフレームでCOBOL、CICS、RPG2などを使用することができることは事実ですが、オッズは非常に高く、それらを使用する場合、これがあなたの仕事ですすることに追いやられました。さらに悪いことに、COBOLは過去20年ほどで大規模に「近代化」されたにもかかわらず（私はそれがまだ非常に現代的な言語であるとは思わないので、引用を怖がらせて）、COBOLで行うコーディングのほとんどはまだ古いままです-スタイルのコード...
- メインフレームで行われている実際の新しい開発はほとんどありません。メインフレームのR＆D部門で働いているIBMに就職した場合、新しい開発を行う機会が得られる可能性があります（その場合、あなたの仕事は本当に楽しいかもしれません！）。ただし、実際にはそれに直面します。そこで働くことはありません。金融機関の奥の部屋などで、64KBは途方もない巨大なRAMだとまだ考えている人が書いた50年前のCOBOLコードを維持しているでしょう。 （この同じ人はおそらくあなたの上司になるでしょう。）
- Linuxをメインフレームで実行できるため、IBMのメインフレームのR＆Dでの作業と同様に、希望するほとんどすべてのプログラミング言語または環境にアクセスできることは事実ですが、その仕事は得られません。 50年前のCOBOLの保守に戻ります。
- コーポレートプログラミングは、魂を吸い取るのに非常に効率的です（そして、幸運でない限り、これはメインフレームプログラマーとして行うコーポレートプログラミングです）。
- それはゲットーであり、常に縮小しているものです。 （これは [〜＃〜] mumps [〜＃〜] のようです。）メインフレームの知識に浸りすぎると、メインフレーム以外のあらゆるものから遠く離れます。 試してみてください追いつくことはできますが、そうはいきません。メインフレームの売り上げが伸びている一方で、他のサーバーセクターは少し縮小していると誰かが指摘したのを知っていますが、最近はサーバープログラミングが少数派です。地獄のPCは一般的に重要性を失っています。プログラミングの世界は非常に広く非常に多様であり、その一部が別の極小部分と比較して成長することは、たとえば、iPhone（それ自体は、少数派プラットフォーム–はるかに）。いいえ、メインフレームで作業を開始すると、他のメインフレーマーだけが自分の考え、喜び、怒りを共有できます–そして、それらは死にかけている品種です。これにより、群れがさらに速く収縮する負のフィードバックループが発生します。
メインフレームプログラマーが、キャリアがやりがいを感じ、喜びと興味深い課題に満ちている理由を説明できる理由はたくさんあると思います。実際、私を現場に募集しようとしている人々からそれらの多くを聞いた。しかし、結局のところ、主にゲットーの問題が原因で、私は確信が持てないままでした。入場して気に入らなかった場合、どうやって出ますか？
私は27歳で、4年以上プロの開発者として働いています（そのため、私はまだ若いと見なされています）。私は統合スペシャリストとしても働いているので、メインフレーム開発の世界に多くの機会を得ています。
- コミュニティで起こっている革新はほとんどないか、まったくないようです。
私はこれが正確にそうではないことを知っていますが、カジュアルな観察者にとってはそう思われます。 「印を付ける」ことが難しい領域に関与したくはありません。 - どのくらいの新しい開発または新しいプロジェクトが起こっていますか？
私が知る限りではありません。この領域に入ると、あなたは永遠にメンテナンスプログラマであると非難されます。 - カジュアルな学習者はアクセスできません。
ほとんどの人は自宅のPCでプログラミングする方法を学び始めました。繰り返しますが、ほとんどの人は自分が知っていることから切り替えることを好みません。したがって、一方から他方に移行するには、時間とモチベーションが必要です。他の2つの理由を考えると、受験者はそれほど多くありません。
9月に40歳になるので、それが若い人としての資格があるかどうかはわかりませんが、誰かがメインフレームプログラマーになりたくない理由を直接知っています。
私の過去10年間はメインフレームプログラミングに専念してきました。バッチ、jcl、Cobol、アセンブラー、Easytrieve、CICS、およびWebサービスについて知っておくべきことはすべて学んでいます。私はそれを非常に楽しんでおり、傾向に気づかない限り、それを続けています。私の最後の就職先では、Web開発者（jsp、javascript、spring、およびhibernate）と一緒に仕事をしていましたが、会社は相当な年数の経験を持つWeb開発者をより多くのお金で獲得していることに気付きました。 Web開発者の立場がはるかに少ないストレスであったという事実は言うまでもありません。
この傾向にうんざりした後、私はメインフレーム事業から撤退することにしました。現在、Java=およびJavascriptを使用したフロントエンドUIを使用してWebサービスを開発しています。このスタイルのプログラミングは、メインフレームで行ったものと同じくらい簡単ですが、今ではより多くのお金を稼ぎます頭痛が減りました。午前2時に問題が発生し、コアシステムプロセスが私の問題を修正するのを待っているという電話を受けなくなったので、メインフレームプログラマーとして留まる理由を1つ挙げてください。分散システムプログラマとしての生活で、より多くのお金を稼ぐことができ、ストレスを減らすことができますか？
企業がメインフレーマーや分散システムの人に支払いをする状況があると私は確信していますが、私は個人的にそれらを見つけていません。また、私は両方の視点から仕事の検索を開始し、分散システムの求人リストがメインフレームの求人リストよりも少なくとも10対1を上回っていることを発見しました。これは、現時点で私がより良い仕事の機会を得るにはメインフレームが適していないことを示しています。あります。
私がこれまで見てきたことから、そしてLinuxやWindowsと比較して、メインフレームとミッドフレームの基本的な問題は、あなたがMUST payを前もって使うことです。そして、たくさん払ってください。毎年。全てにおいて。
彼らはそれを買う余裕がないので、これは単に学生に何かに興味を持たせる方法ではありません。彼らが興味を示さなければ、彼らはおそらく自発的にそれをキャリアとはしないでしょう。
残念ながら、IBMのビジネスモデルでは、学生がマシンを安価に入手できるようにすることはできません。
プログラマーとしての最初の夏の仕事の1つは、主にグリーンスクリーンとPRNファイルのスクレイピングに基づいていました。当時は、おそらくCOBOLで自分の手を汚すことを考えていなかったでしょう（つまり、学生として私をそのコードに入れるように私を十分に信頼していました）が、今日同じ見通しについて同じように感じるかどうかはわかりません。
問題は実際にはmainframes自体にあるとは思いません。それは私たちの業界の（しばしば正当化される）新しくて光沢のあるものへの執着です。
Cを見てください。Cは依然として明らかに非常に重要な言語です。ほとんどすべての埋め込みコードとほとんどのオペレーティングシステムはCで書かれています。すぐにはどこにも行きません。それでも、Cプログラマーを見つけるのは難しくなっています。 Stack Overflowタグページ をざっと見てみると、[c#]のサイズの1/6と[Java]のサイズの1/4になっています。 Cが基本的に主要な言語であり、おそらく町で唯一のゲームだった時期を覚えている人はいますか？
プログラマーは強力なツールを愛しています。 （SPECULATION ALERT）ほとんどのプログラマーが男だからなのかもしれません。 Javaまたは.NETプログラマーにファイルのコピーなどのタスクを与えます。多くの場合、多くの場合、まだJavaまたはDOSバッチファイルや* nixシェルスクリプトを作成する代わりにC＃を使用すると、作成と展開が50倍速くなります。500匹の魚を捕獲できる巨大な格納式ネットがあるのに、なぜロッドとリールを使用して魚を捕まえるのでしょうか。
はい、COBOLとPL/Iはoldですが、Pascalもそうであり、それはまだ生きており、Delphiの形で動き続けています。前者への嫌悪感は、おそらくそれらの言語が現代のツールと比較して扱いにくいであるという事実に由来します。オブジェクト指向は、COBOLの世界ではまだ比較的新しい概念です（を相対的に強調します）が、C＃の世界では、LINQとジェネリック、およびAJAX革命が何年も前に中止されました。それらのツールに慣れている開発者にメインフレームでのプログラミングを開始するよう依頼することは、バンジョーで演奏を始めるようにロックミュージシャンに依頼するようなものです。
もちろん、自己永続的なステレオタイプの問題もあります。若いプログラマーがメインフレームに何もないと信じている限り（それが真実であるかどうかにかかわらず）、次にdoそれに行くことを選択すると、はるかに高齢の人々の周りでほとんどの日を過ごすことになります。 ITは、そもそも社会的に魅力的な職業ではありませんが、世代間のギャップに対する追加の阻害要因は、多くの人々の痛みのしきい値を下回る傾向があります。違反は意味しません-私は個人的に私の人生のほとんどをかなり年上の人々と一緒に働いてきましたが、誰もがそのような背景やその能力を持っているわけではありません。
最後に、ほとんどのプログラマーはメンテナンス作業を楽しんでおらず、メインフレーム作業のほとんどすべてがメンテナンス作業です。 PL/Iで書かれているnewソフトウェアはそれほど多くありません。メンテナンスコードの周りに定義されているジョブ全体または大きく自動的に開始負のスコアで。
レガシーコード（メインフレームや他の多くのものを含む「レガシー」）での作業には肯定的なareがあり、もしそうなら、おそらくプレイする必要があるでしょう。若い群衆を引き付けようとしている：
システムは、あなたが言うように、重要なインフラストラクチャです。少なくともビジネスの世界（Google/Microsoftではない）の若い開発者は、実際に影響を与える機会を得られないことがよくあります。数か月または数年後に放棄または置き換えられることがわかっているシステムで作業するのはがっかりします。すでに50年間実行されているメインフレームアプリは、企業がそれらを再構築する意味がないので、おそらくもっと長く実行されるでしょう。したがって、そこで実行する作業は実際には重要です多くの人に。
あなたが実際にやっているそれらの数少ない会社の1つである場合は、「アップグレード」する傾向があります。その機会に惹かれます。ミッションクリティカルなコードとに取り組む機会が2つあり、それらのC＃/ Javaの筋肉の一部を柔軟にするためです。当然のことながら、メインフレームを廃棄してゼロから再構築する正気な会社はありませんが、（たとえば）Javaコンポーネントと統合するCOBOLコアを備えたシステムを見てきました。
最後に、不可欠性があります-少なくとも、私たちは部外者がそれを認識しているように。すべてのコードが.NETにある場合、コストを削減しようとする見当違いの試みにおいて、所有者が大学を卒業したばかりの卒業生またはさらに悪いオフショアチームと交換するリスクが常にあります。私はそうではありませんメインフレームの世界では非常に頻繁に起こると思います、特にあなたの言うことが真実であり、供給が減少しているようである場合は特にそうです。もちろん、十分に支払っていなければ、この点は意味がありません。給与は、供給の減少を反映するように調整する必要があります。そうしないと、人々は「売り」ません。
若い従業員にとって魅力的な職場環境を作るために邪魔になっているように見える会社からのかなり寛大な提案を拒否しないであろう若い開発者がたくさんいると思います。しかし、彼らにリーチしたいのなら、あなたは自分の強みを試してみるのが賢明であり、あなたはいくつかのマーケティングを始めなければならないかもしれません。私たちはメインフレームを別の非常に異質な世界と見なす傾向があり、10年前のキャンパスフェアでその認識を変えるために働いている皆さんに会ったことはないと思います。
要約すると、1つの文になります。メインフレームを作成するものがない魅力的ではない、それだけでは、それらが魅力的なものになることはありませんどちらか、そしてそれは私たちに大きな生産性の向上と無料のソフトドリンクを提供する出血エッジと比較すると、それらを深刻な不利な立場に置きます。
私は若々しく（30代半ば）、現在メインフレームサポートで働いています。 RPG、COBOL、独自の4GLがらくた。開発は遅く、可能な場合は、より新しい言語を使用してより新しいハードウェアに移行されます。
メインフレームの開発は、最新のシステムに比べて手間がかかるため、メインフレーム自体がバックエンドに追いやられる傾向にありますが、メインフレーム自体で行われていた種類のレポート作成やデータ変換には、より新しい言語が使用されます。この時点で、ほとんどのデータ入力をバッチ駆動プロセスに変えたので、サーバーに残っているのは課金に関連するものだけです。
飛び込むのは良いニッチのように思えるかもしれませんが、多くの企業は、これらのシステムが実際には必要でないことを認識し始めていると思います。金融の世界では変化はゆっくりと起こりますが、それは起こります。
個人的には、メインフレームに対する市場での利点が何であるか理解できません。
高速な数値とデータの処理？それを処理のためにファーム全体に分散したり、頑丈な「通常の」サーバーを購入できないのはなぜですか。
高い冗長性とスケーラビリティ？ Linuxサーバーファームまたは仮想サーバーのセットが必要です。
仮想化と複数のOS？おそらく、「クラウド」戦略の代わりにこれを使用すると、かなりのパフォーマンスの違いがありますか？
これらすべてをより詳細に理解したいのですが、メインフレームを差別化するものについての有用な説明がないことが、これらのシステム用にプログラミングしない理由の主な理由です。
私は25歳で、現在MSCSプログラムに参加しています（私の経歴はCSではありません）。メインフレームに間違いなく興味があります。問題は、どこから始めればよいかわからないことです。私はCOBOLを調べましたが、適切なコンパイラをどこで入手できるかわかりません（COBOL用の適切なコンパイラが何であるかさえわからない、オープンソースコンパイラがあることはわかっていますが、その品質はわかりません）。私はそれについて多くの情報を見ていません、そして正直に言うと、それを探すのに費やされた時間は私が.NetまたはJava（ .Netですが、学校の仕事はJavaで行われています。@ Joshua Smithのように、メインフレームに入るとしたらそれが私の人生になるのではないかと心配します。でも私にとっては、Javaを習得してからSAPにつなぐことの方がはるかに簡単です。それで十分な仕事が得られることも知っています。
結論はこれです：
（1）メインフレームプログラミングを行うために何を学ぶ必要があるかを知るための情報がすぐに入手できない
（2）私の人生のこの時点で、私は生活と.Netのためにプログラムできるようにしたいだけで、Javaを使用すると、学校にいる間にこの目標に向けて取り組むことができます私の学歴の終わりにポートフォリオを手に入れるために私が頼りにして必要なことを学ぶことができるたくさんのリソースがあるので
（3）自分が楽しんでいないことをしていると行き詰まるのは難しく、キャリアのためにメインフレームだけを行っている場合に行き詰まる可能性は、私を怖がらせるようなものです（ただし、私の自由な時間に新しいことをブラッシュアップし、オープンソースに貢献するなどの方法があります）
メインフレームの労働力への参加を検討する2つの理由：
- それはうまくいきます
- たくさんの開口部があります
メインフレームフィールドの灰色の労働力は、フィールドに膨大な数の開口部を作成します。
私は大規模な金融会社で働いており、今後5年以内に退職後の労働力の約30％が失われます。その数は10〜15年で指数関数的に増加します。
その他の理由：
- 私はこの分野に25年以上携わっており、飽きることはありません。
- 仕事の競争が少ない。
- テクノロジーについて文句を言うのをやめてください（上記のいくつかの投稿を参照）。 HTML-休憩してください。それは私が30年前に大学で取ったBasicにとても似ています。私たちはそれをはるかに超えています。
- メインフレームは高速で信頼性が高く、実証済みです。
- あなたが非常に明るく、トラブルシューティングが大好きな場合は、システムプログラミングを試してください。
- チームリーダーとして、私は若い、訓練を受けた技術者を見つけて開口部を埋めることができれば幸いです。
- 私はそれがうまくいくと述べましたか？
- ソフトウェア開発以外のメインフレームのキャリアオプション-ハードウェアエンジニア、ストレージ技術、ネットワーキングなど。
- それは楽しく、刺激的で、挑戦的で、素晴らしいキャリアの成長があります。
- メインフレームを古いテクノロジーと考えるのはやめてください。チェックして、私が言ったことをすべて確認してください。
また、IBMのSystem z Academic Initiativeも確認してください。
私がメインフレームの仕事を始めたのは、10年前に従業員に入ったときです。これまでにメインフレームに触れたことはありません。
面白くない点がいくつかあったので、できるだけ早くメインフレームの作業をやめました。
- コードの編集は非常に原始的でした。あなたは基本的にテキストエディターで作業していて、すべて大文字で80文字の行に固定されていました。コード補完や構文チェックはありません。
- コンパイルはバッチジョブを開始することによって行われ、その後、スケジュールされ、ある時点で実行されました。運がよければ、通常は次の5分で実行されました。タイプミスがあり、コードがコンパイルされなかった場合は、数回繰り返します。
- いかなる種類のデバッガもありませんでした。デバッグは変数値を出力し、その長いコンパイル手順を繰り返すことによって行われました。
- 私たちが行った変更は常に信じられないほど保守的でした。私たちは20年間のレガシーコードを基に構築しており、唯一のドキュメントはどこかでファイルキャビネットの紙に手書きされていました。さらに、これは財務コードであるため、エラーに対する許容度はありませんでした。そのため、実際のコーディング手順は、事前に必要な調査と比較して最小限でした。
（OTOH、期間中、非常に高度なバージョン管理とコード昇格がありました。）
これは、若いプログラマーとしての私の個人的な見方にすぎません。私はこれまでメインフレームに取り組んだことがないので、実際の経験から話すことはできません。しかし、それが問題です。私はこれに取り組んだことがなく、いつかそれが起こるとは予測していません。メインフレームと単純なサーバーのどこに線を引くかはわかりませんが、メインフレームだと思うと、Zシリーズ900のような巨大なIBMマシンが1日35ドルの電力だけを消費することを想定しています。私はいつかすぐに地下室にそれらの1つを置いて、暇なときにいじるつもりはありません。特に私が古いマシンをつかむことができるとき、ubuntu-serverをそれに投げて、とても簡単に好きなようにホストします。私が問題を抱えている場合、Linuxコミュニティは巨大であり、他の誰かが私の問題に遭遇し、解決策をオンラインで投稿した可能性があります。私は推測しているだけですが、メインフレームの問題についてオンラインでそのレベルの情報が利用できるとは思いません。
見て、私は42歳ですが、メインフレームには興味がありません。まあ、それを修飾しましょう。コンピューティングの歴史に興味があります。私はある程度メインフレームアーキテクチャを研究しており、たとえばIBMメインフレームがモトローラ68000や80386などのマイクロプロセッサアーキテクチャにどのように影響したかを理解しています。思い出。それらの環境に慣れている人々にとって、初期のマイクロプロセッサは多くの点で失望し、マイクロプロセッサベースのアーキテクチャが同様の機能とパフォーマンスに追いつくのにかなりの時間がかかりました。
しかし、それらのアーキテクチャに追いついて、メインフレームはずっと昔から「流行り」でなくなっていました。ハッカーがベンチにミニコンピュータを設置できるようになったとき、その直後にワークステーションでUnixが実行されていました。
メインフレームは、1980年初頭以降、若いプログラマーにとっては異質でした。メインフレーム企業が自分自身に質問する絶好の機会だったかもしれません。
今日の答えは世代を超えて再帰的です：若いプログラマーはメインフレームに興味がありません世紀前。
とにかく、今日、携帯電話はメインフレームが30年前に使用されたタスクを処理できます。安価なサーバーボックスのファームが新しいメインフレームです。ですから、今日、新しいメインフレームプログラマがいるのですが、彼らの専門は、ネットワークマシンをまとめてクラウドを構築することだけです。一見すると、マーク・ザッカーバーグと彼のギャングは、ディスクを備えた単純なマイクロプロセッサで実行されるのは単なるアプリケーションではないという意味で、Facebookを作成したときに新しい種類のメインフレームプログラミングを行っていたと言えます。
ちなみに、メインフレームの最後の専門分野の1つは仮想化でした。しかし、これは現在、デスクトップ/サーバーマシンのいたるところに存在しています。人々は最初、ソフトウェア技術を使ってひどく始めました。 VMは非常に有用であったため、ユーザーはパフォーマンスへの影響を気にしませんでした。その後、インテルのような企業はメインフレームを再度検討し、ハードウェアの仮想化をサポートして高速化することにより、さらにいくつかの教訓を学びました。
私はまだ若々しいプログラマー（私は29歳）であり、メインフレーム向けの開発を学ぶことに特に興味はありません。私は.NETチームの保険会社で働いていますが、昔ながらのメインフレームプログラマーの大規模なチームとも協力しています。
メインフレームの世界を私にとって魅力のないものにするいくつかのことがあります。まず、COBOLです。世界の多くがCOBOLで実行されていることは理解していますが、それによって言語が醜くなったわけではありません。
次に、「サイクル」の概念があります。これがメインフレームに共通するのか、それとも私たちのやり方にすぎないのかはわかりませんが、メインフレームから最新のデータを取得するには、メインフレームが一晩のサイクルを実行する必要があります。当店の.NET側は、メインフレームへのデータの送信とメインフレームからのデータの処理（特に、エージェント用の内部LOB Webサイトに大量のデータを表示する）に大きく関与しています。ビジネスは、エージェントに表示されるデータが最新のものであることを望んでいます。ただし、メインフレームは私の（限られた）リアルタイムの概念では動作しません。翌日のメインフレームからの実際の出力を予想するものをWebサイトでシミュレートするために、いくつかの非常識な回避策があります。
最後に、この時点でメインフレーム開発に移行すると、それが私のキャリアの大半を占めるようになると確信しています。現代の開発者としての私のスキルはどんどん遅れてしまい、結局COBOLメンテナンスが私の唯一の選択肢となるポイントに到達すると思います。現在、特に10年後には、稼ぐのに十分なお金があることはわかっていますが、私のお金は私のキャリアの優先事項のリストの4番目または5番目です。それが新しくて面白いことに取り組むことを意味するならば、私はむしろまともな給料を作り続けたいです。
私は主にJavaを使用していますが、バックエンドにはメインフレームを使用しているため、メインフレームを頻繁に処理する必要があります（RPG）。私が抱えている最大の問題は、公開されているドキュメントが不足していることです。ほとんどiSeries DB2に変換されるDB2のSQLドキュメントを見つけることができますが、publib.boulderはSunのjavadocに比べると恐ろしいものです。
もう1つ私が気に入らないのは、主要なメインフレーム言語の構文が読みにくいことです。 RPGにはローカルスコープの概念がないため、巨大な変数宣言ブロックが必要になります。 Cobolも同じ問題に苦しんでいると思います。また、意味のない変数名や隠された意味にもつながります。また、多くのさまざまな組み込み関数があり、私はそれを見つけるのに苦労しています（上記を参照）。真面目なプログラミングにBASICを使わなくなった理由を思い出します。ありがたいことに、IBMは全員をJavaに移行しようとしていますが、これらのレガシー言語がすぐになくなるわけではありません。
このような環境でプログラミングを学ぶことにワクワクするのは難しいと思います。
Web、携帯電話、またはPC開発の学習は、かなり安く簡単です。
古いメインフレームでも、ハードウェアコストは非常に高く、IBMは Herculesエミュレータープロジェクト （システム/ 370、ESA/390、およびzSeriesをエミュレートできる）に頻繁に不満を感じます。ヘラクレスがなければ、これは、最も裕福な愛好家を除いて、メインフレームアーキテクチャとアプリケーション開発を学ぶためのエントリーコストになります。
80年代以来、私が通っていた大学には、学生が使用できるメインフレームがありませんでした。 IBMとメインフレーム業界の残りのゴーストは、足を踏み入れて学習しにくくしていると思います。
IBMメインフレーム、特にzSeriesに関するいくつかの事実から始めましょう。
ハードウェアはブランドスパンキングの光沢があり、新しいです。最先端のエレクトロニクスとチップ設計がいくつか含まれており、高速です。
Z/OSは1960年代にルーツを持っていますが、継続的な開発と少なくとも2回の完全な書き直しを経て、下位互換性に対するIBMのフェチから生じる癖とは別に、おそらく一般的に使用される新しいOSの1つです。
主なセールスポイントは次のとおりです。
- 前述の下位互換性は、プログラムがMVS/MVTマシンで1976年に実行された場合、再コンパイルすることなく最新のzSeriesで実行され、まったく同じ結果を生成する可能性があります。
- 帯域幅により、アクセスを移動し、大量のデータを非常に高速かつ非常に細かいレベルで格納できます。
- 可用性。過去15年ほど使用可能だったSYSPLEXは、ロードバランシング、自動フェイルオーバーなどを備えた複数のサイトでシームレスなクラスタリングを提供します。その多くはハードウェアで実装されています。ほとんどの* nixクラスタリングがプリミティブに見えます。
- 収束。これは少し奇妙に聞こえますが、完全なPOSIXサポートと超高速JVMを備えているため、最新のメインフレームは、それを使用したい場合、他の* NIXボックスと実質的に区別できません。
これまでのところ、メインフレームは、専門家が言っていたものに取って代わるだろうと言っていたほとんどすべての機能を上回っています。
いくつかの欠点があります：-
- 下位互換性とは、多くのショップが20、30、場合によっては40年前のシステムを実行していることを意味します。それらはうまく機能し、ビジネス機能をうまく実行します（または、まだ実行されていません！）一方で、コーディングスタイルと過ぎ去った時代の執着を反映しています。
- 後方文化。古代のCOBOLシステムのゲットーで作業しているプログラマーは、世界が進んでいることに気づいていないようです。
- 可用性の欠如。あなたが実際にこれらのモンスターのいずれかで作業するために支払われていない限り、あなたはそれにアクセスすることはできません。あなたが働いている場所もあるかもしれませんが、あなたの直接の仕事の説明がそれに取り組んでいることを含まないなら、あなたはログインを取得しません。 「ヘレキュレス」エミュレーションソフトウェアに関する他の投稿で多くのことが言われていますが、確かに優れていますが、それは専門家のみに非常に適しています。オペレーティングシステムの古いバージョンを実行し、CICS、COBOLなどの標準コンポーネントのほとんどが不足しています。ほとんどの実行中のメインフレームアプリケーションのフレームワークを形成するDB2。
私は28歳で、10年間プロの開発者を務めています。私はメインフレームで3年間働いた。
環境は難解で古く、停滞していて混乱していた（JCLとISPFは誰か？）。そうは言っても、私はシステム、それがどのように機能したか、その規模について非常に尊敬していました。システムには150M SLOCのようなものがあり、SOAを介してUNIXサーバーのミッドレンジファームをサポートし、文字通り国の大部分を占めていました。
それで、なぜ若いプログラマーは興味がないのですか？これが、「若い」プログラマーとしての私の見解です（私は23歳でこのシステムを使い始めました）。これは、私が取り組んでいたシステムと私が行った研究からの私の見解です：
- 新しいメインフレームの開発はほとんどありません。その多くはレガシーです。
- 参入には大きな障壁があります
- 行われた作業は、財務、大企業、政府のためのものです。これは、最先端の技術ではありません。
- 開発ツールは古く、ほとんど時代遅れです。デバッグはVSに似ています。
メインフレームは常に経済の中で位置づけられます。彼らは莫大なコストとサポート要件のために、初期のビジネスを推進していません。
おかしい、あなたはこれを尋ねるべきです。大学でメインフレームについて話し合ったところですが、IBMはメインフレーム開発者のレベルに不満を持っています。つまり、メインフレーム開発者が大学でメインフレームモジュールを実装し、メインフレームプログラミングを教え、リモートでメインフレームの1つにアクセスできるということです。
私は実際にこのモジュールを9月に受講します。これは、今後行うことではないかもしれませんが、「異なる」何かに取り組み、新しいパラダイムに目を開く機会を与えてくれます。
その答えは、そこには未来がないということです。私はメインフレームプログラマとして22年の経験があり、5年間仕事を休んでいます。私はウェブ開発の学士号を取得するために学校に戻ります。なぜ彼らの右心にいる誰かがメインフレームのCOBOLプログラマーになりたいのでしょうか？
ケン
メインフレームにはおそらく非常に興味深い仕事があると思いますが、実際に自分のキャリアをその方向に動かすのは恐ろしいことです。 10年後には、あまりにも大きな可能性があり、私の経験は役に立たなくなり、メインフレームプログラマーが利用できる作業がなくなります。私は、インストールベースが縮小する停滞したテクノロジーに多くの時間を費やして、時代遅れになりたくありません。