アカウント名:
パスワード:
まともなプログラマなら、初めて扱う言語のプロジェクトにアサインされても、1～2週間で慣れるだろ。ただグローバル変数盛り盛りの古くさい言語ってだけで、特別に習得が難しい言語なわけででもない。
COBOL言語そのものの原型は単純明快なんだけど、処理系依存の方言が激しいし、既存のJCLの流れにうまく沿うように書かなきゃいけないしで、他の現場での経験があまり転用できないイメージだな。あとメインフレームは、プログラム言語よりJCLやDSNのオペレーションの方がしんどい印象なんだよな。IBMしか知らないけど。細かい事はもう忘れちゃったけど、DSN定義したりJCL作って実行したりログ読んだり、PCOMMでの接続後のこういったオペレーションとかにまず慣れないと、まともに実装業務できない。WindowsともUNIXとも考え方が違うので、慣れるまで苦労した憶えがあるわ。COBOLプログラム経験者は、だいたいオペレーションもできるので、それで経験者募ってるんだと思う。
JCL、初めて使ったとき、なんか、どこかに隠されている大型の電算機に計算を投げる、という感じがちょっとドキドキした。スパコンもUNIXになって、普通に./a.outでジョブが流せるのも、なんか違和感あって面白かった。
少し納得した。枯れた言語だからこそ、COBOLを使える人間くらい養成できるだろうと思ったら、メインフレームいじれる人を探してるわけね。
会計系の枯れた言語として、デスクトップCOBOLやってみたいんだが。。
やってみるか ?
https://ja.osdn.net/projects/sfnet_open-cobol/releases/ [osdn.net]OpenCOBOLは、オープンソースのCOBOLコンパイラで、COBOLコードをCのコードに変換してGCCでコンパイルします。
JCLとかVSAMとか直接COBOLの言語仕様でないものも知らないと話にならないわけで、MVSの操作方法から説明していたら1,2週間じゃ全然足りない。それに、その間それを知ってる人間が教えるために手を停めないといけない。
経験者募るほうがいいと思うぞ。
そんなもの他のOSの環境を触ってたら、慣れるのに時間はかからないだろ。直接の経験者は募集しようにも足りないんだろ？
そういうお前は、実際に現場行ったら「実行するまでSyntax Errorさえ検出できないなんて人間が使うものじゃない｝と言う。IDEなんてないのよ。バッチで長ーい順番待ちしてやっと結果が出る。それでも一文字打ち間違っただけでSyntax Errorで終わりだ。オレも含めて今の人にはできないし、勧めない。
VSCode使えよw
VSAMとか「他のOS環境」じゃファイルシステムのドライバとかDBのエンジンとかで隠ぺいされててだいたいのOSじゃ慣れる時間なんてはいなずやで。
メインフレームも対話的に使うとか思ってそう。
なんて言えばいいんだろ。MSPしか触ったことないけど、きっとMVSに似てるんじゃないのかなぁ。なのでMSPでの説明。
例えば、JCLってのがあって、シェルプログラムに近いんだけど、ハードウェアに深く食い込んだプログラム言語でもあるイメージ。プログラムはアウトプットのデバイスを指定できるんだけど、どういった名前のデバイスに書き込みされるかは、JCL内の確かDD文に依らないといけなかった。ここはメインフレームを管理している人しか基本的に触る場所じゃなく、長大なログをプリントアウトする人が近くにいる時、別のプリンタに出力する時に管理者から指定されるような時に触るもの。その他にも初期値の与え方とか、unix系とはかなりお作法が違ってたと思う。むしろ、windowsの方がunixに近いと思うくらいだ。
つまり、考え方がかなり違うので、他のOS知ってたら、なんてレベルじゃなかなか仕事にはならないです。
仕様もらってコード書くだけの兵隊ならそれでもいいけど。今必要なのは、COBOLで動くレガシーシステムや失業給付システムの経験ある人じゃないの？即戦力が欲しいのであって、今から勉強しますって人向けではないでしょう。
リンク先の冒頭でもこうある。
Are you an experienced COBOL programmer interested in assisting agencies and employers needing additional COBOL skills as they respond to public needs during the COVID-19 pandemic?
敗退的言語を覚えたいか？その時間で他にできることがあろう。
(#3800294)みたいなやつほど2,3年で寿命がきれるウェブ技術なんかを習得するのに血眼になっている
ウェブに限らんよ。C#もJavaも当初と比べたら別の言語といってもいいぐらいに変わってる。Cだってプラットフォーム依存だけでなく、仕様もだいぶ変わってて古い書き方してるとコンパイラが警告出しまくりだったりする。
JavaScriptとか人生を捨ててるとしか思えない。半年もしたら別のライブラリやフレームワークが流行ってるし
根本的に言って、言語の話なんですかね？COBOLがやっていたのは違う問題だとしたら、話はまったく変わって来ます。 ・ブラックボックスでシステムを扱う（開発から引き継いで運用を行う）・1以上のリレーション（複数のテーブル）を他人の思惑でホワイトボックスで操作する・1のテーブル（と枝葉の複数のテーブル）を自分の思惑でホワイトボックスで操作する の様に問題を、解法の面から分類するとすると、上の方がリスクが大きく、お金ももらえやすいですが、一番上は、あまりにもぼろ儲け過ぎて、しかもまれにしか起きないが必ず起きる
slashdotでは繰り返し繰り返し出てくる類だな。いまだに新人が来ているという証拠だと思うのでそれはそれでめでたい。
で、お前は銀行業務のCOBOLコードをどれくらい他の言語に置き換えたの？敗退的言語からオレ最強言語に移行を提案したら怒られたから、ここで憂さ晴らししてるの？
経験者募集は普通でしょう。Javaができる人募集など特定言語経験者募集は普通のこと。
さらに今回は即戦力が欲しい緊急対応である。素人雇ってどうする。
#親切に教えますなんて言う会社のほうがブラックだったりするし。
現実知らない馬鹿の戯言。こういうのが人月に対して人増やせば何とかなると炎上させる。
人月は人月でも、元コメのような作業だけする人は0.3人相当、作業者をまとめて成果出せる人が2人相当、仕様検討して問題解決できる人が3人相当といった運用ができればそれほど炎上しないよ。上の数字はあくまで例えだけど。どんな人だろうと1人は1人としてカウントして、それを顧客に請求する商習慣が炎上の元。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
なぜわざ経験者を募るのだろう (スコア:0)
まともなプログラマなら、初めて扱う言語のプロジェクトにアサインされても、1～2週間で慣れるだろ。
ただグローバル変数盛り盛りの古くさい言語ってだけで、特別に習得が難しい言語なわけででもない。
Re:なぜわざ経験者を募るのだろう (スコア:4, 参考になる)
COBOL言語そのものの原型は単純明快なんだけど、処理系依存の方言が激しいし、
既存のJCLの流れにうまく沿うように書かなきゃいけないしで、他の現場での経験があまり転用できないイメージだな。
あとメインフレームは、プログラム言語よりJCLやDSNのオペレーションの方がしんどい印象なんだよな。IBMしか知らないけど。
細かい事はもう忘れちゃったけど、DSN定義したりJCL作って実行したりログ読んだり、
PCOMMでの接続後のこういったオペレーションとかにまず慣れないと、まともに実装業務できない。
WindowsともUNIXとも考え方が違うので、慣れるまで苦労した憶えがあるわ。
COBOLプログラム経験者は、だいたいオペレーションもできるので、それで経験者募ってるんだと思う。
Re: (スコア:0)
JCL、初めて使ったとき、なんか、どこかに隠されている大型の電算機に計算を投げる、
という感じがちょっとドキドキした。
スパコンもUNIXになって、普通に./a.outでジョブが流せるのも、なんか違和感あって
面白かった。
Re: (スコア:0)
少し納得した。枯れた言語だからこそ、COBOLを使える人間くらい養成できるだろうと思ったら、メインフレームいじれる人を探してるわけね。
会計系の枯れた言語として、デスクトップCOBOLやってみたいんだが。。
Re: (スコア:0)
やってみるか ?
https://ja.osdn.net/projects/sfnet_open-cobol/releases/ [osdn.net]
OpenCOBOLは、オープンソースのCOBOLコンパイラで、COBOLコードをCのコードに変換してGCCでコンパイルします。
Re:なぜわざ経験者を募るのだろう (スコア:3, すばらしい洞察)
JCLとかVSAMとか直接COBOLの言語仕様でないものも知らないと話にならないわけで、
MVSの操作方法から説明していたら1,2週間じゃ全然足りない。
それに、その間それを知ってる人間が教えるために手を停めないといけない。
経験者募るほうがいいと思うぞ。
Re: (スコア:0)
そんなもの他のOSの環境を触ってたら、慣れるのに時間はかからないだろ。
直接の経験者は募集しようにも足りないんだろ？
Re: (スコア:0)
そういうお前は、実際に現場行ったら「実行するまでSyntax Errorさえ検出できないなんて人間が使うものじゃない｝と言う。
IDEなんてないのよ。バッチで長ーい順番待ちしてやっと結果が出る。それでも一文字打ち間違っただけでSyntax Errorで終わりだ。
オレも含めて今の人にはできないし、勧めない。
Re: (スコア:0)
VSCode使えよw
Re: (スコア:0)
VSAMとか「他のOS環境」じゃファイルシステムのドライバとかDBのエンジンとかで隠ぺいされてて
だいたいのOSじゃ慣れる時間なんてはいなずやで。
Re: (スコア:0)
メインフレームも対話的に使うとか思ってそう。
Re: (スコア:0)
なんて言えばいいんだろ。
MSPしか触ったことないけど、きっとMVSに似てるんじゃないのかなぁ。なのでMSPでの説明。
例えば、JCLってのがあって、シェルプログラムに近いんだけど、ハードウェアに深く食い込んだプログラム言語でもあるイメージ。
プログラムはアウトプットのデバイスを指定できるんだけど、どういった名前のデバイスに書き込みされるかは、
JCL内の確かDD文に依らないといけなかった。ここはメインフレームを管理している人しか基本的に触る場所じゃなく、長大なログを
プリントアウトする人が近くにいる時、別のプリンタに出力する時に管理者から指定されるような時に触るもの。
その他にも初期値の与え方とか、unix系とはかなりお作法が違ってたと思う。むしろ、windowsの方がunixに近いと思うくらいだ。
つまり、考え方がかなり違うので、他のOS知ってたら、なんてレベルじゃなかなか仕事にはならないです。
Re:なぜわざ経験者を募るのだろう (スコア:3, すばらしい洞察)
仕様もらってコード書くだけの兵隊ならそれでもいいけど。
今必要なのは、COBOLで動くレガシーシステムや失業給付システムの経験ある人じゃないの？
即戦力が欲しいのであって、今から勉強しますって人向けではないでしょう。
リンク先の冒頭でもこうある。
Are you an experienced COBOL programmer interested in assisting agencies and employers needing additional COBOL skills as they respond to public needs during the COVID-19 pandemic?
Re: (スコア:0)
敗退的言語を覚えたいか？
その時間で他にできることがあろう。
Re: (スコア:0)
(#3800294)みたいなやつほど2,3年で寿命がきれるウェブ技術なんかを習得するのに血眼になっている
Re: (スコア:0)
ウェブに限らんよ。
C#もJavaも当初と比べたら別の言語といってもいいぐらいに変わってる。
Cだってプラットフォーム依存だけでなく、仕様もだいぶ変わってて古い書き方してるとコンパイラが警告出しまくりだったりする。
Re: (スコア:0)
JavaScriptとか人生を捨ててるとしか思えない。
半年もしたら別のライブラリやフレームワークが流行ってるし
Re: (スコア:0)
根本的に言って、言語の話なんですかね？
COBOLがやっていたのは違う問題だとしたら、話はまったく変わって来ます。
・ブラックボックスでシステムを扱う（開発から引き継いで運用を行う）
・1以上のリレーション（複数のテーブル）を他人の思惑でホワイトボックスで操作する
・1のテーブル（と枝葉の複数のテーブル）を自分の思惑でホワイトボックスで操作する
の様に問題を、解法の面から分類するとすると、
上の方がリスクが大きく、お金ももらえやすいですが、
一番上は、あまりにもぼろ儲け過ぎて、しかもまれにしか起きないが必ず起きる
Re: (スコア:0)
slashdotでは繰り返し繰り返し出てくる類だな。
いまだに新人が来ているという証拠だと思うのでそれはそれでめでたい。
で、お前は銀行業務のCOBOLコードをどれくらい他の言語に置き換えたの？
敗退的言語からオレ最強言語に移行を提案したら怒られたから、ここで憂さ晴らししてるの？
Re: (スコア:0)
経験者募集は普通でしょう。
Javaができる人募集など特定言語経験者募集は普通のこと。
さらに今回は即戦力が欲しい緊急対応である。素人雇ってどうする。
#親切に教えますなんて言う会社のほうがブラックだったりするし。
Re: (スコア:0)
現実知らない馬鹿の戯言。
こういうのが人月に対して人増やせば何とかなると炎上させる。
Re: (スコア:0)
人月は人月でも、元コメのような作業だけする人は0.3人相当、作業者をまとめて成果出せる人が2人相当、仕様検討して問題解決できる人が3人相当といった運用ができればそれほど炎上しないよ。
上の数字はあくまで例えだけど。
どんな人だろうと1人は1人としてカウントして、それを顧客に請求する商習慣が炎上の元。