[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/20 00:31 / Filesize : 274 KB / Number-of Response : 998
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【COBOL】コボラー集まれ!!!【事務処理】



1 名前:デフォルトの名無しさん [2006/05/01(月) 18:32:38 ]
いるだろ?語ろうぜ

321 名前:デフォルトの名無しさん [2007/08/20(月) 12:43:21 ]
10 PRINT ゙こぼらー乙゙
20 GOTO 10




RUN

322 名前:デフォルトの名無しさん mailto:sage [2007/08/20(月) 20:25:20 ]
>>321
それはBASIC

323 名前:デフォルトの名無しさん mailto:sage [2007/08/20(月) 23:39:10 ]
warota

324 名前:デフォルトの名無しさん mailto:sage [2007/08/21(火) 00:37:14 ]
DISPLAY 'こぼらー乙'.
STOP RUN.

325 名前:コボちゃん mailto:コボちゃん [2007/08/21(火) 14:42:27 ]
コボちゃん

326 名前:デフォルトの名無しさん [2007/08/22(水) 17:18:26 ]
MAIN
PERFORM DISP-RTN THRU DISP-RTN-EXT UNTIL 10000 TIMES.
STOP RUN.

DISP-RTN.
DISPLAY NC"こぼらー乙".
DISP-RTN-EXT.
EXIT.

久々に書いたよ。ボコル。
久々にNumLockをonにしていたよ。ボコル。

327 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 17:39:11 ]
コンパイル通らないね

328 名前:デフォルトの名無しさん mailto:sage [2007/08/22(水) 19:30:19 ]
>>326
なんて美しいコード…やっぱコボルが一番だな。
CとかJavaの軟弱な小文字ソースを見ると吐き気がする。

329 名前:デフォルトの名無しさん [2007/08/28(火) 23:33:53 ]
ケース1:
A PIC S9(03) VALUE -123.
B PIC X(2).
MOVE A(3:2) TO B
上記だとBには「23」が設定されますよね?

ケース2:
A PIC S9(03) VALUE 123.
B PIC X(2).
MOVE A(3:2) TO B
上記だとBには「23」が設定されますか?

ケース2の実行結果がわかりません。
ご教示願います。 ( ・∀・)ノ





330 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 00:00:25 ]
A領域、B領域...

331 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 00:16:46 ]
ケース1も怪しい気がする。
ZONE形式で符号付きの場合、一番ケツに符号を持ってたと思う。
(持ち方は環境依存かもしれない。)
-123 だからと言ってS9(3)は4文字にはなっていないんじゃないか?

332 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 00:50:04 ]
>>331
その辺は言語仕様として固まって無いんじゃ
俺はCOMPオプションで出力されるデータ型が決まるみたいに考えてた

333 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 00:55:12 ]
>>331
おいおい、MOVEするときに型変換されるに決まってるじゃないか。
つまりケース2は「23」で正しいかと。

334 名前:329 [2007/08/29(水) 08:11:37 ]
みなさん、ご教示ありがとうございます。

ということは・・・
「A PIC S9(03)で変数Aを宣言すると4文字分の領域(符号領域+3桁の数値領域)が
確保され正の数のとき、右詰で数値が設定される」
という認識であってますか?



335 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 09:38:02 ]
>>334
REDEFINES して調べてみたら?

336 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 10:03:06 ]
>>335
>>333 はREDEFINESとMOVEで動作が違うといってるな。
どういう動作になるのかは言語仕様にあるかわかんね。コンパイラ依存だろうか。

337 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 12:50:06 ]
>>329
>>334
俺の環境だとコンパイルすら無理、どっちのケースでも
MOVE A(3:2) TO B
が異常あつかい

俺の環境だとAは3バイトあつかいなので、
3桁目から2バイトだと領域オーバーだから

いぜう

338 名前:デフォルトの名無しさん [2007/08/29(水) 14:45:43 ]
>>318
COBOLだけのシステムって、何が作れるの?
middle wareだらけじゃないの?

339 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 15:38:03 ]
>>338
ミドルウェアに依存しているのはどの言語も同じ
って言うか、オープン系の言語の方がその傾向が強いんじゃねーか?



340 名前:デフォルトの名無しさん [2007/08/29(水) 17:11:43 ]
>>339
開発の規模とプラットフォームによるだろうけれど、例えばCで統一する方が、ミドルウェアから、GUIまで
一貫性があるんじゃないの? それか小規模のシステムなどは、スクリプト型言語でランタイムライブラリに
全部依存する方が開発が早いのでは?


341 名前:デフォルトの名無しさん mailto:sage [2007/08/29(水) 17:57:27 ]
小規模のシステムでCOBOLによる開発が早くないことは
最初からわかってることでは? つまり、そんな観点で
COBOLが選ばれている訳ではない。

342 名前:デフォルトの名無しさん [2007/08/29(水) 22:27:31 ]
いざとなったらUNIX-COBOLERになればいいのさ

UNIX自体についてはできる人か講師の先生に教わればいいんだし
経験者曰く、毎日やってりゃ嫌でも覚える、とのこと

343 名前:デフォルトの名無しさん [2007/08/29(水) 22:37:12 ]
アナログ人間の俺にはコボルが精一杯
もう30になるので、これからどうやって食っていくか考えなきゃ

344 名前:デフォルトの名無しさん mailto:sage [2007/08/30(木) 10:00:52 ]
中小企業といっても千差万別だが、
ほとんどの企業でPC2台(一台はバックアップ)で済むよ。

345 名前:デフォルトの名無しさん [2007/08/30(木) 13:15:25 ]
>>314
異常終了とかしたら、ダンプだのトレースだの
他の人が手を加えて継ぎ接ぎだらけのAPをデバックする
次に異常終了したら、担当じゃないとこまで責められる。

俺は銀行系の運用携わってたけど、死ぬかと思った。
夜中に呼び出され知らないことで問い詰められ、
朝までにデバック〜テストして本番に移行する。

この仕事やる前に、運用保守って聞いて受けないでおこうと思ったけど。
金に釣られてやった俺がバカだった。

最後は強引に辞めちゃった。
二度と子守りなんてごめんだ。

346 名前:デフォルトの名無しさん mailto:sage [2007/08/30(木) 13:37:16 ]
>>344
どんだけしょぼい会社しか知らないんだよ。

347 名前:デフォルトの名無しさん [2007/08/30(木) 15:31:55 ]
9月の3日からクレジットカード系のコボルの開発に行くんですが
まったくやったことないんです。 初級、新卒レベルOKの案件なんで大丈夫だと思うんですが
これだけは入場する前にやっておけというのはありますか?

C,C++,JAVA,VBはやってます

348 名前:デフォルトの名無しさん mailto:sage [2007/08/30(木) 21:40:26 ]
>>347
>C,C++,JAVA,VBはやってます
まったく役に立たないからな。むしろ苦痛になるぞ。

349 名前:デフォルトの名無しさん [2007/08/30(木) 22:16:39 ]
頭の切り替えが大変そう w



350 名前:デフォルトの名無しさん mailto:sage [2007/08/30(木) 22:44:34 ]
>>347
他の言語を知ってれば知ってるほど、コボルは辛いかもね,,,

351 名前:デフォルトの名無しさん mailto:sage [2007/08/30(木) 23:59:39 ]
>>348
それはいい過ぎ

Cが出来れば後は文法覚えるだけ
VBが出来れば文法も半分覚えてる

C++ JAVAはいらね。窓から投げ捨てろ

352 名前:デフォルトの名無しさん [2007/08/31(金) 00:10:16 ]
コボルしか知らない俺でも金融系のコボルは苦痛・・・
特にオンライン・・・
プログラムが果てしなく深く、そして汚く、下へ下へと繋がって、他系システムに
連動している・・・
メインフレームのシステムはドキュメントが無い
プログラムとJCLのみ

組んだ奴しか知らないことばかり

運用兼開発は朝から晩まで大変らしいね
開発か運用のどちらかに専念できる会社じゃないと体がもたないよね

353 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:10:19 ]
つか、金融系がCOBOLの最後の砦なんだから
そんなに嫌ならC++かJavaに譲ってやれよ。w

354 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 09:07:39 ]
CやVBのコーディングスタイルに慣れていると、
COBOLはつらいかもね。

うちの会社だけかもしれないけど。

355 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 09:28:21 ]
つ ttp://anond.hatelabo.jp/20070831005830

356 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 09:46:12 ]
漏れも金融系の仕事してるけど、>>355はまあ、そういうものだよな。
COBOLが悪いと言うか、あの辺りはそういう体質なんだから、
慣れるしかないな。

つーか今は亡き(w)UFJなんかCOBOLじゃなくてアセンブラ全盛だったぞ。
COBOLで贅沢いうんじゃねーよ。って感覚だったな。

漏れも久しぶりに64Kの壁やらセグメントって概念思い出したし。

357 名前:デフォルトの名無しさん [2007/09/05(水) 14:34:09 ]
Fの汎用機のデータ(VSAM)をCSV形式に落としたいのですが、F*TRAN以外に
何か変換できるソフトはないでしょうか?

データは、EBCDIKとJEFコードで、ファイル転送は、PFDのFIMPORTを使用しています

教えてエロい人・・・スレチの場合は、誘導願います。

358 名前:デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:23:18 ]
>>357
F*TRANだとどういう風に具合が悪かったの?

359 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:31:08 ]
>>357
その流れでF*TRANいるのか?
FIMPORT終了でPC上のファイル(CSV)になっているのでは?
PFDのFIMPORTってPC上でやってるんじゃないの?




360 名前:357 [2007/09/06(木) 10:53:53 ]
358 さん返信ありがとう

F*TRAN が不具合と言う訳ではなく、該当ソフトを模索している最中なので、F*TRANは既に
候補にあがっているので、〜以外としました。

それと、JEF変換の精度が、50%ぐらいだとHPに書いてあったような・・・

359 さん返信ありがとう

>PC上のファイル(CSV)になっているのでは?
確かにCSV形式になっているのですが、1レコード単位なので、基本項目別に、カンマをいれるには
ファイル毎にカンマ編集のプログラムを組んでPCに送らなければならないので、PC側でF*TRAN等
が必要だと思いました。(10〜20程度のファイルならプログラムも組みますが、100を超えるもので)
    
理想的には、VSAMファイルをホストのワークファイルにする
              ↓
          ファイル転送(FIMPORT)でPCに転送
              ↓
          変換ソフトを使いPC内で項目別カンマのファイルに変換 → PC利用

カビの生えたレガシープログラマに愛の手を・・・


361 名前:358 mailto:sage [2007/09/06(木) 12:34:51 ]
>>360
その流れで処理するのがベストです。

よく使われているレガシーデータ変換ツールは、
 F*TRAN+
 AnyTran
 Hulftデータ変換Pro
 Pervasive Data Integrator(旧Data Junction)
のあたりですね。この中からコストと漢字変換機能を重視して選ぶと、
F*TRAN+の一択になってしまうと思います。漢字変換テーブルが標準で
付いてくるのが大きなポイントです。試用版をDLしてまず使ってみては?

もっと大きくEAI/ETLツールという枠組みで考えると、他にもレガシーデータに
対応した製品/システムはいろいろとあります。でも、価格が2桁ほど
跳ね上がってしまうので、現実的ではないでしょう。

362 名前:デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:56:47 ]
358 さん 早速のレスありがとうございます

試用版が、有ったんですか、文字通り試してみます。

363 名前:デフォルトの名無しさん [2007/09/08(土) 01:36:18 ]
そんなあなたに
ACUCOBOL
これ最強!

364 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 02:05:31 ]
COBOLといえば、二つのファイルから一レコードずつ
読み出してのマッチング処理というのが
入門書の例題における定番ですが、
Cなどの参考書ではとんとお目に掛からない。
もしかして、他の言語ではマッチング処理ということ
自体、存在しない概念なのかな?

365 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 04:25:24 ]
>>364
うん。必要ない。

366 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 10:13:03 ]
>>365
なんで必要ないんだ?

367 名前:デフォルトの名無しさん [2007/09/08(土) 12:50:25 ]
>>366
COBOLみたいなファイルを扱う世代から
RDBを扱う世代に移ってSQL使うようになったんじゃね?


368 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 13:16:01 ]
しかしOracleに限っていえば、Pro*CよりもPro*COBOLのほうが
相性がいいというか、可読性が高い気がしている


369 名前:デフォルトの名無しさん [2007/09/08(土) 18:14:35 ]
>>367
ちょい質問なんだけど、中間ファイルを作ったり、シーケンシャルなファイル(テキストファイルとか)
を使ってどうのこうの なんて作業はないの?



370 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 18:59:12 ]
>>369
RDBの勉強しような。

371 名前:デフォルトの名無しさん mailto:sage [2007/09/08(土) 20:20:38 ]
>>369
マッチングは完全にDB任せで、
中間ファイルはJavaなんかだとシリアライズして保存するのが多そう

372 名前:369 mailto:sage [2007/09/08(土) 23:06:21 ]
>>370
へ〜い w

>>371
ふむふむ です w

373 名前:デフォルトの名無しさん mailto:sage [2007/09/10(月) 21:49:00 ]
>>368 同意
だが埋め込み SQL は可搬性が無くなる罠。
ロジックの切り分けって観点からしても、速度からしても PL/SQL だろ。
(SQL はどのみち別々に書く覚悟でな)

>>369
>>370 と重なるけど、少し詳しく言うと
通常は一発 SQL でだいたいの処理はできる。
きちんと設計された DB で一発 SQL だと遅いような場合、
中間データを作る事はまれにだがある。

それでもデータは一時テーブル(データを蓄える DB 上のストア)に置く。
Oracle はダメだったはずだけど一時テーブルを最後に捨ててくれたりもするし、
(エラー系の処理の実装が安全になるわけだな)
全てのデータ操作が SQL で書ける。

>>371 みたいな実装はすまんがちょっとイメージできない。
別システムへデータを移すのであれば、確かにあるけど、
処理中に中間データを DB の外に出すのはあまりないと思う。

そうするとソートもマージも全部 SQL で完結するようになるから単純だし、
基本的な操作はこなれたミドルウェア(DB)にまかせるって切り分けも完全だ。
DB のソート/マージ機能をライブラリみたいに使う感じか?


374 名前:デフォルトの名無しさん mailto:sage [2007/09/10(月) 23:53:22 ]
Javaでマッチングとかコントロールブレイクとか要らない理由って、
ユーザ定義クラスとかコレクションクラス使ってCOBOLのレコードより
もっと柔軟なデータ構造が表現できるからじゃないの?

375 名前:デフォルトの名無しさん mailto:sage [2007/09/11(火) 20:26:10 ]
ダメだ…CやJavaを10年くらい独学で
勉強してるけど、ハローワールドから全く進まねえや。
COBOLは三ヶ月で使えるようになったのに。
COBOLもCもJavaもバリバリっつー人いる?
どうやって勉強した?

376 名前:デフォルトの名無しさん mailto:sage [2007/09/11(火) 20:30:28 ]
Cは独学、COBOLは会社の研修、JAVAは独学中だったが飽きた。
別にバリバリっってほどでもないけど、、、
勉強法、1.読む、2.書く、3.試す。

377 名前:373 mailto:sage [2007/09/11(火) 20:40:48 ]
>>374
メモリ上で処理できるなら COBOL だって索引表にデータを蓄えるだろ。
JAVA しかやってない世代には理解できないかもしれないが、
100 万を超えるデータを読み込んで突き合わせ、なんて処理が
COBOL の時代にはたくさんあったらしいんだ。
まさかそんなデータはメモリに読み込まないよな?
で、メモリに持てないから一度ファイルに書き出して処理するんだと。

今はその規模のデータを処理する事になっても、
中間テーブルにデータ持つよってのが >>373 の回答。
まあ、最近は正規化が進んだデータしか扱ってないから
滅多にそんな必要に迫られる事もないけどな。

>>375
C も COBOL も JAVA も使うが特別な事をやったつもりはない。
強いて言えば C のポインタが強敵だった。
あれだけは 5,6 冊本を読んで、
10 本近くプログラムをこなしてようやく何とかなった感じだ。


378 名前:デフォルトの名無しさん mailto:sage [2007/09/11(火) 23:06:58 ]
人の作ったのコピペで修正

379 名前:デフォルトの名無しさん [2007/09/12(水) 15:40:49 ]
Cのポインタってそんなに難しいのかな、アレはアセンブラの動きそのものなんだが
そこら辺をすっ飛ばして勉強しているからかな



380 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 18:53:47 ]
Cのポインタはメモリのイメージが出来ていれば、難しくないはずだが。

が、まあ他人のソースで***pなのを見ると市ねとか思うのはある。

381 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 22:26:51 ]
>>379
俺はBASIC、COBOLと来たもんだから、ポインタはさっぱり。
変数のアドレスか…ふーん…で終わってしまう。
星2つなんてとんでもない話で、変数のアドレスを持つ変数の
アドレスを持つ変数って、それイジメじゃんってレベル。
ああ、ポインタのないCOBOL大好きっ!

382 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 00:00:43 ]
そっか、自分は初めて触ったのがCだったから
何の違和感も無く使えたけど
確かに、COBOLやBASICで入った人には分かりにくいかも寝

383 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 18:16:03 ]
>彼がいうには、いまだに社保庁のシステムはCOBOLというプログラム言語を使っているという。
>これは彼が学生時代に使っていたもので、40年も前のものだ。
>つまりこの年金の問題は、あまりにも古いシステムとハードを使っていることから起きたのだ。

www.nikkeibp.co.jp/style/biz/column/tahara/070705_18th/index.html

384 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 19:11:34 ]
COBOLのリンケージって参照渡してるよね?

385 名前:デフォルトの名無しさん [2007/09/13(木) 20:51:21 ]
COBOLを使わせてるということは会社の上層部を騙してるってことでしょ
汎用機のほうが信頼性がありますよとかいって
クソ高いマシンを使わせてクソ言語でシステムを組む
コボラーは全員罪人だよ

386 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 23:53:13 ]
>>385
あ?





同意

387 名前:デフォルトの名無しさん [2007/09/14(金) 02:00:10 ]
>>385
でも、コボラーはあそこから出てきて欲しくないってのもあるよ

388 名前:デフォルトの名無しさん [2007/09/14(金) 04:33:56 ]
言語の問題?ハードウェアの問題?どっちもか!?
マシン語で組んだらいいのか?

389 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 06:48:07 ]
どんな言語使ってもRDBを順ファイルフォルダとして使っちゃう人たちだからなあ。
オツムのアーキテクチャの問題でしょ。



390 名前:デフォルトの名無しさん [2007/09/14(金) 11:31:45 ]
A4縦のリストでメートル級の関数書くのは止めて欲しい、保守するとき全面書き直ししたな

391 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 11:56:40 ]
汎用機の信頼性が捨てがたいのと
安いマシンを冗長性持たせてパラで複数台動かすと
ランニングにコストがかかることから
汎用機の大企業での需要はここ最近伸びてるよ

コボル云々は別として汎用機卑下は筋違いでしょ
汎用機下にLPAR切って複数台のUNIX系のサーバ
動かせるしね

どこかの企業が数百台のサーバを数台の汎用機上の
バーチャル環境に集約させたことによって、電気代と
インフラに従事する人員をかなり削減できたため
高額な汎用機のメンテナンス費用を差し引いても
コストメリットが有ったらしい

392 名前:デフォルトの名無しさん [2007/09/14(金) 18:13:51 ]
安くて丈夫なPCサーバの方がパフォーマンスはずっと上だろ
ユーザーを囲い込んで独占商売する汎用機が
ものすごく割高なのは明らかじゃない

393 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 19:25:32 ]
>安くて丈夫なPCサーバの方がパフォーマンスはずっと上だろ

オマイは一度でも汎用機を使ってみてから語ってくれ。

そのPCサーバーは1分間に40万トランザクションくらい軽く走るって事だよな。

394 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 20:08:52 ]
自社開発の汎用機のCPUなんて
Intel製と比べたら遅いなんてもんじゃないぞ
その他あらゆる箇所が自社開発だからパフォーマンスで劣る

GoogleはやっすいPCサーバを大量に並列化してとてつもない
パフォーマンスを叩き出している
その汎用機はGoogleのトランザクションがさばけるのかね

395 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 21:14:25 ]
と言われてもGoogleのデータセンターって火事があったりしたし、
そもそもGoogleのメールも極稀に止まったりして、
トランザクション結構とめてるんだけど、そういうのが許される世界と
許されない世界を無理に比較するのはアマチュアの思想だよな。

あと、googleの鯖は今は特別仕様のはずだが。
昔の広告宣伝のニュースに踊らされるなよ。

396 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 21:20:35 ]
つか、Googleほどの天才集団ならPC使ってもパフォーマンスは出せるだろうが
392みたいな素人が安PCを数揃えても使いこなせんだろう。

397 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 22:22:09 ]
>> そのPCサーバーは1分間に40万トランザクションくらい軽く走るって事だよな。
そもそも普通の会社のバックオフィスの鯖に
分間40万トランザクションを捌く性能は要らない。

それにもかかわらずそんなものを売りつけるんだよ、汎用機屋は。


398 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 22:39:47 ]
汎用機の性能はいつだってPCよりいいに決まってる
専用の高価なマシンがPC同等スペックだったら売れない

いっぽうでPCサーバーの安定性は昔よりはるかに向上してる
その点を攻めるのは汎用機側の驕りにすぎないね

汎用機が売れてるのは嘘つき営業が上層部騙して売ってるから
今どき汎用機じゃなきゃつとまらない処理なんてほとんどない
(特殊な用途ではあるよもちろん、完全に無用の長物じゃあない)

平時の負荷が全能力の10%とか切っててピークでも40%越えないとか
明らかにオーバースペックな汎用機を入れて喜んでる
ただのアフォだね

ダウンタイムだってそれでロスする損失、賠償とか営業機会なんかが
トータルで保守費用の差分を上回るなんて滅多ない
つまりわずかな利益のために目茶苦茶コストをかけてるってこと
はっきり言って騙されている以外の何ものでもないな

399 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 22:43:17 ]
SunやHPやIBMのUNIX販売屋連中が、汎用機に少しでも近づくのが目標とのたまわっているのに・・・






400 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 22:53:38 ]
汎用機アンチの発言に突っ込みどころ満載なんだけど
面倒なのであまりにもな1つにだけ

>>398
> ダウンタイムだってそれでロスする損失、賠償とか営業機会なんかが
> トータルで保守費用の差分を上回るなんて滅多ない
随分と無責任な世界に生息してるんだね

401 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 23:06:10 ]
汎用機に近づくのが目標って
海外じゃ汎用機は既に置き換えが進んでほとんど消えている
日本は汎用機所有数世界一
保守的で技術に疎い上層部が食い物にされ続けてるのだ

402 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 23:10:58 ]
いやいや、コボル+汎用機は
人類が手にしうる最高の安定稼働環境。
PC鯖なんぞで安く済まそうと考えるような
上層部は無能と断言できる。
システムが企業の屋台骨だとわかっているなら
コボル+汎用機にするはずだ。

403 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 23:15:58 ]
つられないぞ・・・・

404 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 23:46:23 ]
COBOLと汎用機が優秀だとしても、使い手のCOBOLerが無能じゃ仕様がない。

405 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 00:14:04 ]
このスレの住人、実際に実物の汎用機を見たことない香具師が多数なんだろうな


406 名前:デフォルトの名無しさん [2007/09/15(土) 00:50:04 ]
>>405
それより有能なCOBOLer見たこと無いんだが

407 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 01:39:20 ]
見たこと無いね
どこかにいるのかしら

408 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 01:59:36 ]
>>400 >>398
汎用機が必要な業務もあるって書いてるんだし、
そういう重責任な業務は汎用機に責任転嫁してんじゃね?
仕様の変更に柔軟に対応できる低コストかつ無責任なオープン系と
ガチガチに仕様固めなきゃ開発進まない高コストだが安心な汎用機。
漏れもよくそう説明するぜ。

見積もりって意味じゃPCサーバーのダウンタイムって
リスクとしてカタログの数字通り見積もる。
でも確かにでかい数字にはならねー。
汎用機の保守費用と比べて圧倒的に低リスク&低コストなのは間違いないな。
そういう勝負だとよっぽど神経質なとこじゃないと汎用機は売れない。

銀行の会計系のサーバーをPCサーバーにするとかいうのはバカだが、
企業のバックオフィスのサーバーならPCサーバーで十分。
(本当はweb系にこそ汎用機の性能を生かして欲しいんだけどな。
 数千万トランザクションとか安定して捌くよ?)

>>402
最高の安定環境ってのは認めるが、投資対効果が悪過ぎるだろ。
COBOLerだし、バックオフィスにはPCサーバー+COBOLがいいけど。
今だったらよっぽどの事が無い限り汎用機を持ち出さない。
PCサーバーでトランザクションも十分さばけるしな。

ところで最近のPCサーバー、実際のとこどれくらい落ちるよ?
いままで2回落としたけど、スムーズに退避系に切り替わってたし、
漏れ、サービスを実際に完全に落とした経験ないんだけど、
そんなもんなのかな?


409 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 02:18:16 ]
汎用機も落ちるときゃ落ちるよ



410 名前:デフォルトの名無しさん [2007/09/15(土) 02:19:36 ]
COBOLのコンパイラは貧弱だとききますが、ホストでコンパイルするのに
人弱なのでしょうか。
パソコン上でただで使える、VC++やbccなどと比べられるなら
どのくらい差がでますかね

411 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 02:20:24 ]
オレも汎用機触ったことあるけど、安定性が高いとか言われる要因がよく分からん。
ハード面/ソフト麺でいったらどっちなの?両方?
F通かどっかが汎用機にLinuxのせたとか言うの雑誌で見たけどそういうのはどうなんだろう?
PCサーバに汎用機用のOSが載せられたとしたら?

で、実際に落ちたのを見た経験があるのは汎用機の方。人的ミスでショートさせたとか。
業務を止めるのは、その上で動いてるアプリケーションのバグだったりする方が多いと思うけど、
これらだと汎用機もPCも関係ないよな。

OSごと落ちるのはWin以外見たこと無いな。

412 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 07:20:15 ]
汎用機とはちょっと違うがAS/400なんかはPCベースなHP-UXに比べると
タフではあるな。

これは使い方が悪い例でもあるがDisk使用率が99%使っても気合で動いていたりする。(w

それとは複数のJOBをガンガン並列に走らせても性能の劣化はPCサーバとは
比にならんと言うか、CPUスペックの数字だけ立派なPCと違い、
I/O周りがしっかりしているので、月末とか期日とか重めのバッチが
走っても他のオンライン系の処理も影響なく走るしな。

あとノーツとか動かすとやっぱPC鯖の方が落ちてる回数多い。
あれもトランザクション結構走る業務(?)だと思うが。

まあ、現代はオープン系が人気なので安PC並べる方がパフォーマンス云々
いいたい気持ちは解るが、やっぱ使い手による面が多いぞ。
COBOLerの99%くらいはアフォなので文句言いたい気持ちは解るけど。

客からすると中途半端なしったかオープン系の方が性質悪いケースが多いし。

413 名前:デフォルトの名無しさん [2007/09/15(土) 07:28:49 ]
そういや汎用機といえばPL/Tって完全に消えたの?

414 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 07:31:45 ]
まだメーカーの研修ってやってた希ガス

415 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 22:16:35 ]
>>412
すさまじく同意

416 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 23:16:33 ]
日本じゃまだ商売できてるからっていつまでも汎用機だのCOBOLだのの
幻想にしがみついてると社会保険庁みたいになるぞ

417 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 01:38:03 ]
>>412
対応は真摯だけれども、詐欺同然にお金だけはキッチリ取る汎用系もどうなのかなぁとw
お客からすればどっちがマシなんだろうか

418 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 01:56:24 ]
>>417
ヤフオクや楽天みたいな
システムダウンしてもお客が舌打ちすりゃ
済むようなシステムならともかく、社の威信のかかった
大事なサービスを提供するシステムなら、
信頼性と迅速なサポートの付いた汎用機だろうね。

419 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 02:05:41 ]
信頼性って指標値が今ひとつ納得できないんだよなあ
可用性ってことなら、単に待機系のマシン増やせばいいだけなんじゃないの?って思っちゃう



420 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 08:23:26 ]
>>419
信頼性ってのが胡散臭いなら、以下の記事を読むといい。
ttp://www.nikkeibp.co.jp/style/biz/management/yajima/050606_manzokudo/

AS/400(iSeries)は知っているエンジニアからすると突き抜けて評判がいいのは事実だ。

待機系のマシンを増やせば?って意見もわかるが、PC鯖にOracleやらあれこれアプリケーション
突っ込んでRACやらWEB鯖の分散やらやっていくと管理や構成がウザくなっていくので、
ある程度以上の金が出せて自社の抱えるエンジニアに難のある企業(ココ重要w)
はAS/400の様なマシン買う方が安いのは事実ではある。

こういうのをやらずに「安PC鯖、オープン系ソフト、技術者は偽装派遣(w)」なんて
組み合わせは「安物買いの銭失い」の典型的パターンだしな。

まあ、「無能なのに金をボるCOBOLer」ってのも事実だけど、機械の方は
あんまり罪はないぞ。そういうのは主に営業が悪いんだし。

421 名前:デフォルトの名無しさん mailto:sage [2007/09/16(日) 14:00:03 ]
このスレにオープン系と汎用系の両方をやっている人間何人いるの?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<274KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef