5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

【ABEND】メインフレーム万歳5【JCL ERROR】

1 :S0C4:03/10/09 00:23
かげりゆくメインフレームを熱く語ろうではないか!!
前々スレ
http://pc.2ch.net/test/read.cgi/prog/1043768277/
前スレ
http://pc.2ch.net/test/read.cgi/prog/1054870550/l50


2 :仕様書無しさん:03/10/09 00:24
メインフレーマー AND コボラーは事故死してくれ。

3 :仕様書無しさん:03/10/09 00:24
汎用機用語の基礎知識

JCL:仕事制御言語
SUBMIT:投入
ABEND:異常終了
TSS:時分割体系
TSO:時分割体系
ES:拡張記憶装置
DASD:直接接触記憶装置
PU:物理装置
LU:論理装置
PACK:圧縮(数字)
IPL:初期プログラム読込
IML:初期マイクロコード読込

4 :仕様書無しさん:03/10/09 00:25
参考リンク

「汎用コンピュータのひろば」
http://homepage1.nifty.com/KSudou-NET/ks0D0D01.htm

Gartner Column:第60回 メインフレームのすごさについて技術的に解説しよう[1]
http://www.zdnet.co.jp/enterprise/0208/26/op_01.html

Gartner Column:第61回 メインフレームのすごさについて技術的に解説しよう[2]
http://www.zdnet.co.jp/enterprise/0209/02/op_01.html

Gartner Column:第62回 メインフレームのすごさについて技術的に解説しよう[3]
http://www.zdnet.co.jp/enterprise/0209/11/op_01.html

Gartner Column:第56回 メインフレーム・リホスティングという選択肢
http://www.zdnet.co.jp/enterprise/0207/23/op_01.html

5 :仕様書無しさん:03/10/09 00:26
主要各社の汎用機Webページ (オフコンやスパコンは除く)

IBM (eServer zSeries) <--- S/390, MVS, OS/390系
http://www-6.ibm.com/jp/servers/eserver/zseries/

富士通(Globsl Server) <--- 旧Mシリーズ(IBM OS互換)および米アムダール製(IBM H/W互換)
http://globalserver.fujitsu.com/jp/

日立(Enterprise Server) <--- 旧Mシリーズ(IBM OS互換
http://www.hitachi.co.jp/Prod/comp/Mparallel1/mp/mpintro.html

NEC(ACOS Series) <--- 旧ハネウェル系
http://www.sw.nec.co.jp/acosclub/

6 :仕様書無しさん:03/10/09 01:20
ちょっといんたらぷと

7 :PL/I ◆pcQESPR2ks :03/10/09 02:05
乙。

8 :仕様書無しさん:03/10/09 14:48
スレ立て乙。

9 :SEくずれ:03/10/11 16:13
ブランク10年の元メインフレーマー&コボラーですが、
再就職できまつか?

10 :仕様書無しさん:03/10/11 22:58
>>9
今、HOST系の仕事は無いです。たぶんこれからも。

11 :仕様書無しさん:03/10/11 23:43
Server Consolidation とか z/Linux とかならまだしも

12 :仕様書無しさん:03/10/12 01:46
>>9
無理です。
警備員かタクシー運転手でもして食いつないでください。

13 :仕様書無しさん:03/10/12 02:18
2種免許持ってません。
第2種情報処理技術者なら15年前にとりました。

14 :仕様書無しさん:03/10/12 15:35
>>13
タクシー会社がとらせてくれるよ

15 :仕様書無しさん:03/10/12 19:19
>9
SEとPGがごっちゃになってる?

16 :仕様書無しさん:03/10/13 11:34
すでにメインフレームは「なくなった」
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20031009/1/


17 :仕様書無しさん:03/10/13 20:57
まぁ、I以外は無いも同然だからな、すでに

18 :仕様書無しさん:03/10/13 22:32
微妙にタイトルが違ってるな。ちょっとメインフレームよりだが、既ね的を
得ていると思う。

19 :仕様書無しさん:03/10/13 22:43
オフコンが無くなったとき、それを需要としていたPG/SEはすんなり
オープン系やメインフレームへ移行できたのだろうか?

俺、実際メインフレームからオープン系へ仕事変わったとき、最初は
苦労したからさ。

20 :仕様書無しさん:03/10/13 22:51
ボコラーの皆様、ご苦労さんですw

21 :仕様書無しさん:03/10/13 23:18
モレはアセンブララーだ。もっと悲惨か...

22 :仕様書無しさん:03/10/14 00:45
>>17
しかし、未だにNに固執する役所も多い訳で。
J隊とか、いい加減になんとか汁。

23 :仕様書無しさん:03/10/14 01:36
J隊ってOじゃないの?
K札はN大好きみたいだけど

24 :仕様書なしさん:03/10/14 22:55
J隊のメインフレームはHだろ

25 :仕様書無しさん:03/10/15 01:08
>>24
陸海空全部?

26 :仕様書なしさん:03/10/15 01:15
>>25
漏れが聞いた話は横須賀だから海だろうな。

27 :仕様書無しさん:03/10/15 07:59
空はN

28 :仕様書無しさん:03/10/15 07:59
陸でもN有り

29 :仕様書無しさん:03/10/15 13:14
前スレ・ガイシュツだが、入門用にはこれだろ

http://itpro.nikkeibp.co.jp/free/NC/TOKU1/20030912/1/
社内で稼働するシステムの数が増大し、かつ、それらなしでは
業務が滞りかねない状況にある今、サーバーには従来以上に
「ダウンしない」、「急変する処理要求に即応できる」機能が
求められている。メインフレームが磨き上げてきた技術は、
まさにこれらの要求に応えるものだ。その技術の一部は、
大規模化を指向するUNIX/パソコン・サーバーが取り入れつつある。
しかし現在でも、メインフレームが頭一つ抜きんでていることは
間違いない。米IBMが5月に発表した新メインフレーム
「zSeries 990(開発コード名T-Rex)」は“何が”“どうすごいのか”
を明らかにすることで、大規模サーバーの未来を探った。

30 :仕様書無しさん:03/10/15 13:23
>>24,25,27
これこれ、素人な事を書いちゃだめよ。

役所だから、自動車でも兵器でも、わざわざメーカーは分散してるんだよ。
建前は入札だし、よく言えば中立な振りで競争させて危険分散してる。
実態は天下りとかの癒着度で発注比率が決まっていて、談合して
ファミリー同士で食ってる訳。

いきなり1社に絞って表標準化とか、役所じゃ聞かないでしょ。
(発注窓口が天下り先企業に一元化されてるってのは多いが、
メーカーをやると目立つからね。それにボトムアップだし。)

31 :仕様書無しさん:03/10/15 20:11
技術力や性能差なんかよりも、
政治の力の方が影響する。
ちょっと嫌だ。

32 :SEくずれ:03/10/15 22:19
COBOLとPLIとJCLで年収500マソは無理でつか。


33 :3年半やってきたが・・・:03/10/15 23:38
もうM/Fは沢山だ・・・

34 :仕様書無しさん:03/10/17 22:26
>>32
まず、無理ちゃうの!!
それと、DBの知識はありまっか?

35 :仕様書無しさん:03/10/17 23:12
>>34
俺超えてるよ。チョットだけだけど。

36 :仕様書無しさん:03/10/17 23:56
>>34
むしろ希少価値が高まっていると思われ。
PL/I使いはワシントン条約で保護されてるし。

37 :仕様書無しさん:03/10/18 00:53
>>36
確かにPL/I使いは貴重ですね。
>PL/I使いはワシントン条約で保護されてるし。
ワロタ!!
後、IMS・CICS知っている人間もある意味貴重じゃないですか?

38 :仕様書無しさん:03/10/18 00:58
CICSは最近WEB系(WebSphereとかかな?)で使ってる人増えてるんじゃない?
やっぱPL/Iだよ。

39 :仕様書無しさん:03/10/18 01:00
IMSでぐぐったらこんなところに行き着いた。
ttp://www.ims-judo.com/

40 :仕様書無しさん:03/10/18 02:02
>>38
そうですかね・・・⇒PL/I使い。
WEB系でCICS使えるんだ。知らんかった。
因みに、私は「貴重な」PL/I使いでつ。

41 :仕様書無しさん:03/10/18 02:08
>>39
そこのホムペは「IMS柔道どっとこむ」だった。
因みに、兵庫県の柔道倶楽部(?)でした。

42 :仕様書なしさん:03/10/18 03:10
PL/I COBOL ASM 運用全般で600万だったな。去年までは。

43 :仕様書なしさん:03/10/18 03:13
>>36
銀行でもCOBOL派とPL/I派があるよね。
信託銀行はほとんどPL/Iじゃないかな。

44 :仕様書なしさん:03/10/18 03:15
IBMのPL/Sも一般開放してほしいよな。
OSやユーティリティー作るのに便利だし。

45 :仕様書無しさん:03/10/18 10:07
>>30
「コンピュータ ユーザ調査年報2003年度版」
(日本経営科学研究所、\47,000)より

陸上自衛隊
・補給、会計、人事:NEC ACOS 3xxx
・各通信隊、通信群:富士通 M7xx

海上自衛隊
・補給、会計、人事:NEC ACOS 3xxx
・各補給所の物品・給与・人事:富士通 M1xxx

航空自衛隊
・補給:富士通 M7xxx
・通信:富士通 M7xxx
・技術計算:三菱 MELCOM COSMO

機密性の高いシステムは当然記載されて無いが、通常業務に
必要ないわゆる基幹系は、メインフレームばかりですね。

これは警察、消防、都庁など自治体でも同じ。
ACOS、 Mシリーズ、HITAC、TOSBAC、MELCOMなど。
ごく一部にNCR、IBM 43xx、PFUなどが混じっている。
民間以上に保守的だし、予算主義・前例主義でコスト意識低いし、
業者丸投げでオープン系でも自分でメンテできないし、
下手にオープン系にして価格指摘を議会からされたくないし。

46 :仕様書無しさん:03/10/18 10:14
先月の日経コンピュータの「99の疑問」だったかでは、
うわさは多いが実際に調べると、言語による価格差は今ではほとんど無いとか。

しかし、DBやTPモニタとかミドルの他、複数言語使えると高くなる。
でも、VBとC/C++とJavaとか、新しい言語だけだと余り変わらず、
COBOLとJavaとか、PL/IとC++とか、新旧知ってると高くなる
(移行や連携のアドバイサーにもなれるから)....だそうでした。

ま、単に言語を知ってるだけじゃ駄目で、両方の文化やメリデメしってて、
比較と使い分け、さらには提案ができる人には需要が高いってことみたい。

47 :仕様書無しさん:03/10/18 11:25
>>38,40
そなの?
基幹連携とかでCICSとWASを併用させてる事例は多いけど、
基本的にはCICSもWAS(EJB)もアプリから見れば一種のTPモニタなので、
新規の独立したシステムなら両方は要らない筈だけど。

細かい運用管理(稼動中のモジュール更新時の影響範囲とか)では、
CICSが今でも優位があり、WASが急速にキャッチアップしつつある、とおもふ。

Iが最近発表した金融コアバンキングのNeFISは、こんなだね。
http://www-6.ibm.com/jp/domino07/fss/finnetjp.nsf/list01/B7D982AE8156ED9049256DB3000C2746

従来:汎用機、IMS/DB、SAIL(またはCAP)、PL/I(またはCOBOL)など
今後:マルチプラットフォーム、WAS、J2EE、corebank(パッケージ)

FはProBankでまだメインフレーム中心、
NはBankinWeb21でUNIX(HP-UX)中心に移行しようとしてるけど、
IはWASとJ2EEが全面に出したって感じかなぁ。

48 :仕様書無しさん:03/10/18 11:29
>>47
NeFISの記事は、こんなんもあった
http://www.nikkei.co.jp/sp1/nt32/20031007AS1D0707E07102003.html
http://www.ibm.com/news/jp/2003/10/10083.html

メインフレーム牙城の金融コア(勘定系)も、これからはJavaかね。
でもWebばかりの人はセンターカットとか今の仕組みや運用を知らないから、
実際の移行には、今と両方わかる人が需要が高まるんじゃないかな。

49 :仕様書無しさん:03/10/18 11:35
>>43
経緯だと、I中心だったとこはPL/I中心、国産(F,N,H)はCOBOLすね。
PL/I:東京三菱、りそな、日銀...
COBOL:みずほ(富士はPL/Iだった)、SMBC(さくらはPL/Iだった)...

「PL/I」の「I(アイと書いてワンと読む)」は、「DL/I」と同じで、
「ひとつでできる」と「IBM」を兼ねてるし。国産が嫌うはず。

50 :仕様書無しさん:03/10/18 11:37
>>49
PL/Iのコンパイル時メッセージは「IBMnnnx」ってのも露骨

51 :仕様書無しさん:03/10/18 12:18
>>46
> ま、単に言語を知ってるだけじゃ駄目で、両方の文化やメリデメしってて、
> 比較と使い分け、さらには提案ができる人には需要が高いってことみたい。

それ、普通は、PGとSEの違いだね。

52 :仕様書無しさん:03/10/18 13:21
やっぱりこのスレの住人でもIMS使いは少ないのかな。
最近V7にあげました。

53 :仕様書無しさん:03/10/18 14:53
>>52
使いまくってるよ〜
PL/Iは久しく使ってないけど

54 :仕様書無しさん:03/10/18 17:22
MQ-IMSブリッジどうよ。
けっこうCPU使ってくれるなあ。

55 :仕様書なしさん:03/10/18 17:44
>>49
PL/IはProgramming Language number 1の事だったと記憶している。

56 :仕様書無しさん:03/10/18 21:18
>>32
元請、元請子会社なら可能です。派遣・協力会社では未来永劫不可能です。
まあ、そのくらい貰える頃には実作業は部下に任せる開発リーダークラスだろうけど。

57 :56:03/10/18 21:22
>>32
訂正。600万以上じゃなくて500万以上か。
それなら残業がんばれば担当者レベルの派遣・協力会社社員でも可能。

58 :SEくずれ:03/10/18 22:26
すでにブランク10年36才ですが、この際400マソに値下げしても
いいので誰か雇って下さい。
第3次オンライン(銀行)の開発経験ありです。
C++とかJAVAとか何のことか判りませんが大丈夫ですか。


59 :仕様書無しさん:03/10/18 22:41
>>58
10年間何をやっていたかによるな

60 :仕様書無しさん:03/10/18 22:42
タクシー運転手だったりして・・・

61 :仕様書無しさん:03/10/18 22:45
>>58
みずほに来なさい!!
でも、10年のブランクは「うん〜と」開き過ぎじゃないかな・・・

62 :仕様書無しさん:03/10/18 22:49
前に「10年前までCOBOLerだった」と言う人を雇ったんだけど(COBOLのPJだったので)
ぜーんぜん使いものにならなかったYO!
>>58はうちの会社には来ないでね。

63 :仕様書無しさん:03/10/19 21:53
>>53
おおお、いるんだ!ちょっとうれしい。

>>54
ブリッジ君は既存DL/Iアプリがそのまま流用できるんで、ホスト側の改変が少なくてすむんだけど、
基本1方向UOWのMQに対して、IMSは問い合わせ応答型だから、そこら辺のデザインが難しいなあ。
CPUはIMSから直接MQPUT/GET出すよりはましだった。

マニアックすぎスマソ

64 :仕様書無しさん:03/10/19 21:56
>>63
うちの会社には掃いて捨てるほどいるよ>IMS使い
MQは使ってないけどなー

65 :仕様書無しさん:03/10/19 22:51
>>58
>ブランク10年36才ですが、この際400マソに値下げしても
図々し杉。
どんなに頑張っても300万ぐらいしか出せん。

66 :仕様書無しさん:03/10/20 00:01
もう10年IMSとアセンブラだけでメシを食ってるよ。そろそろ足洗いてぇ。
タクシー会社かな。

67 :仕様書無しさん:03/10/20 00:03
>>44
PL/X でなくてかい?
PL/Iみたいなアセンブラー

68 :SEくずれ:03/10/20 00:05
時効なので白状しますが、10年前、ある開発で設計からコーディングまで
(約2年)任されました。顧客仕様もほとんど理解できず、ズルズルと2年たって
しまい(進捗報告は順調とごまかし定時退社)、テスト段階でやばくなり、
いきなり退職しました。
後で聞いた話によると、在籍していた会社は即効でその開発から外されたそうでつ。



69 :仕様書無しさん:03/10/20 00:11
>>68
まさか、あのときの・・・
突然旅に出たくなくなったとかいって1ヶ月ほど行方をくらまし
その後当然クビになったMさんですか?

70 :仕様書無しさん:03/10/20 00:15
>>66
最近のタクシードライバーは手取り15マソぐらいだよ。

71 :仕様書無しさん:03/10/20 00:21
じゃ食えなくなるまではこのままいくしかないか、なんとかその倍はあるから。
でも秋田。

72 :仕様書無しさん:03/10/20 00:41
>>68
そんな香具師に600マソも出すヤツおらん。

73 :仕様書無しさん:03/10/20 23:17
手取りで15マソはいればマーシーなんじゃない

74 :仕様書無しさん:03/10/21 22:27
「メインフレームは死ぬ」とIBMが宣言
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20031020/135735/


75 :仕様書無しさん:03/10/22 00:17
西暦2030年(日付は忘れた)にCで書かれたアプリは死ぬ

76 :仕様書無しさん:03/10/22 01:24
>>75
ひょっとして2038年問題のことか?

77 :仕様書無しさん:03/10/22 03:57
>>76
なにそれ?

78 :仕様書無しさん:03/10/22 07:34
>>76
OS/390上のUSS(UNIXシステムサービス)も、古いやつは残ってるんだろなぁ

79 :仕様書無しさん:03/10/22 07:45
>>77
をいをい、業界人の常識だよ
http://member.nifty.ne.jp/shyu/20xx/20xx.htm
http://www.matsusaka-u.ac.jp/~okumura/linux/y2038.html
http://biztech.nikkeibp.co.jp/biztech/it/y2k/about/non-y2k.html

最後のにはこんなのも入ってた
IBMメインフレームの2042年9月18日問題

80 :仕様書無しさん:03/10/22 07:52
メインフレーム v.s. UNIXサーバー

http://www-6.ibm.com/jp/servers/eserver/zseries/zvsu/
ITに関わる人で、その名を(少なくとも、名前だけは)知らぬ者なし、ともいえる 著名なOS、UNIX。
例えば、これをOSとするハードウェアと、IBMの"エンタープライズ・サーバー"であるzSeriesとは、
違うものであることは理解できても、ではどこがどう違うか、となると、知っている方は少ないの
では……と思います。 そんな皆さんにご紹介します。ココが違う、zSeriesとUNIX!

81 :仕様書無しさん:03/10/22 08:21
>>80
こんなのも。しかしI以外では見かけない。内容はほぼ同じなんだが。
http://www-6.ibm.com/jp/servers/eserver/zseries/rensai/

82 :仕様書無しさん:03/10/22 11:04
>>80 >>81
ありがとう。とても勉強になった。
まあ話を商用に限ってしまえばunixはその目的で設計され発展してきたシステムには敵わないのは自明の理かもしれないな。
にも関わらずUNIXサーバーが使われる理由はどこにあるんだろう。
(って自分なりの答えは持っているが、他者の見解を知りたくて振ってみる)

83 :仕様書無しさん:03/10/22 12:08
>>82
UNIX:とりあえず安い・速い、選べる、手軽、情報が多い、PG/SEが支配できる世界
Mainframe:高価、選択少、長期計画、一蓮托生、専任・分業・階層化された固い世界

84 :仕様書無しさん:03/10/22 22:02
そんな事より2006年がどうなるかが問題だな

85 :仕様書無しさん:03/10/22 22:49
>>83 別にUNIXは安くないぞ。

86 :仕様書無しさん:03/10/22 23:23
>>84
2006年って何?

87 :仕様書無しさん:03/10/22 23:42
2007年とは別?
ん〜Y2Kシリーズたくさんありすぎ

88 :仕様書無しさん:03/10/23 02:14
おれも2007年だと思う。
でも2010年ともいう。

89 :仕様書無しさん:03/10/24 19:49
はぁ、、、


テープ世代情報壊しちまった・・・
_| ̄|○

90 :仕様書無しさん:03/10/24 21:03
Sortで出来る事だったのにSortで書いたら変人にされてしまった。
はいはい、あんたはCobolしか読めないのね。

_| ̄|○
Cobolで書き直します・・・・・

91 :仕様書無しさん:03/10/24 21:04
>86
ワールドカップだよ
>90
でかいトコは「データ抽出はプログラム組め」ってトコがよくあるね

92 :仕様書無しさん:03/10/25 01:10
>>90-91
ツールで済む事はなるべくツールですべきと思うし、
ウチはOS/390だけどDFSORTでできる処理はDFSORTでやってる。

でもメンテを考えて業務系の言語は強制的に標準化してる会社も多い。
最初はツールでできても、機能追加で結局COBOLに書き直すなら、最初からと。

ま、汎用機やCOBOLに限った話じゃないけどね。部分最適か全体最適かとか。

93 :仕様書無しさん:03/10/25 01:15
Y2K「危険日リスト」
http://www.merlyn.demon.co.uk/critdate.htm#AD

2006年、2007年、2010年って言っても、色々あるのね。

94 :仕様書無しさん:03/10/25 01:17
>>85
でも汎用機の保守費(H/W, S/W)は今でも高いってのも事実。
APAR(FIXとか)の緊急作成やサポート内容を比べると、Win/UNIXとは大差なのも事実だが。

95 :仕様書無しさん:03/10/25 01:22
へぼオープンプログラマーです。今までのメインはVBとかCとか
なのに今JCL書かされてます。
「人手がないから」という理由で(泣)
誰か私の代わりにこれ書いてくれる人いないかなあ。

96 :仕様書無しさん:03/10/25 01:47
VBでJCL吐き出すツールでもつくれ。

97 :仕様書無しさん:03/10/25 02:42
三菱の「汎用機」は現役です。
http://www.mhi.co.jp/gsh/

98 :仕様書無しさん:03/10/25 02:48
なつかしの汎用機の写真
http://jp.fujitsu.com/museum/products/facom/
http://www-6.ibm.com/jp/event/museum/rekishi/cpu1964a.html

99 :仕様書無しさん:03/10/25 02:49
開発しながら、お客からバグ上がってきたら即APAR作成する。
サポートするほうもしんどいよ。

100 :仕様書無しさん:03/10/25 02:52
100げt。
某社のAPAR番号も、もうすぐキリ番だよ。ちょっと前、うちの近所に
7がいっぱい並んだAPAR番号とったやつがいるらしい。

101 :仕様書無しさん:03/10/25 03:01
ホストを捨て基幹をLinuxで再構築,保守料金3億円を6500万円に
http://itpro.nikkeibp.co.jp/members/SI/JIREI/20031015/1/


102 :仕様書無しさん:03/10/25 05:27
>98
それは汎用機じゃないだろ
科学技術計算用!!
でかきゃ何でも汎用機って思っているし・・・。
それに360シリーズが汎用機って呼ばれた最初のマシンってじいちゃんが言ってぞ

103 :仕様書無しさん:03/10/25 07:13
http://www-6.ibm.com/jp/servers/eserver/zseries/library/jirei/takenaka/
全社規模のグループウェアをz/LINUX上で稼働。
基幹系システムと高度に共存させた、将来型インフラ整備に取り組む。
基幹系システムとz/LINUXをzSeries1台に統合し、運用管理コストを削減

104 :仕様書無しさん:03/10/25 07:39
>>102
富士通ミュージアムとしてはFACOM100を「汎用機」と読んどるぞ
http://jp.fujitsu.com/museum/products/

105 :仕様書無しさん:03/10/25 07:45
>>104
http://www.atmarkit.co.jp/aig/04biz/mainframe.html
これみると >>102 のじいちゃんが正しいケド

106 :仕様書無しさん:03/10/25 10:11
Fは「Iの後発」とみられるのが嫌なんだろ。
ORACLEは最初のORACLEが汎用機用だった事を社歴から読めないようにしてる。
この業界、歴史の改竄や修正は日常茶飯事。ジョージオーウェルの世界ですな。

107 :仕様書無しさん:03/10/25 14:48
いまどき"汎用"機じゃないコンピュータの方が珍しいっての

108 :仕様書無しさん:03/10/25 20:25
>>102
360が最初の汎用機であるのは正しい。
ちなみの360は商用として最初に仮想記憶を実現したと聞く。
でも「じいちゃん」はひどいな。わずか40年前だぞ。

109 :仕様書無しさん:03/10/25 21:04
>>74
『「メインフレームは死なない」とIBMが宣言』

逆じゃねーかよ!
俺は汎用機しか出来ね-んだからマジであせったぞ!


110 :仕様書無しさん:03/10/25 23:24
漏れも汎用機しか出来ないな。専用機なんて触った事ないしな

111 :仕様書無しさん:03/10/26 00:17
汎用機を「ぼんようき」と読んだT君に乾杯

112 :仕様書無しさん:03/10/26 01:56
>>108
最初の汎用機はS/360で、命令セットやI/Oの標準化や、ファミリー化がされた。
OSの製品名は「OS/360」

仮想記憶はS/370(の途中の機種)から。
http://www-6.ibm.com/jp/event/museum/rekishi/visual3.html

このIBMの年表は簡略化されてるが、この仮想記憶をサポートしたOSが
「OS/VS(Operationg System/Virtual Storage)」で、
PGから見えるアドレス空間は(初期のDOS/VSのように)仮想だが単一だった。
(DOS/VSEのように複数区画に分かれていたかもしれないが、
アドレッシング自体は1空間だった)

その拡張版が「OS/VS2」で、複数の仮想アドレス空間を実現した。
この「OS/VS2」の別名が「MVS(多重仮想空間)」で、徐々にこちらが正式名になった。
当時のマニュアルは表紙に「OS/VS2(MVS)」なんて書かれてたよん。

113 :仕様書無しさん:03/10/26 02:17
IBM汎用機OSの系譜

(大型汎用機用)
OS/360:世界最初の「オペレーティングシステム」
OS/370:仮想記憶(OS/VS)
OS/VS2(MVS):多重仮想記憶
MVS/XA:31ビット、動的チャネルサブシステム
MVS/ESA:ハイパー空間
OS/390:周辺サブシステムとのパッケージ化
z/OS:64ビット
z/OS.e:ニューワークロード専用の低価格版

TPF:航空など特殊用途用(アセンブラのみ)

(中型汎用機用:主に43xx用)
DOS/VS:仮想記憶
DOS/VSE:複数区画(アドレス空間は1枚)
VSE/ESA:ESA対応(アドレス空間は4枚?区画は計12?)

VM:仮想計算機
VM/SP:パッケージ化(ゲストOSのCMS付き)
VM/XA:XA対応(ゲストOSの31ビットサポート)
VM/ESA:ESA対応
z/VM:ゲストOSの64ビット対応

http://www-1.ibm.com/servers/eserver/zseries/os/

...VMは面白かったな。
VMの中からMVSやVSEやVM自身を起動できて、テストに便利。
対話型重視だから、学校や研究所では、汎用機でのUNIXのような役割も果たしていたし。
(今なら汎用機にそのままLinuxを乗せてしまうけど)

114 :仕様書無しさん:03/10/26 03:06
>>113
http://www-6.ibm.com/jp/servers/eserver/zseries/library/pdf/computopia_0108.pdf
3ページ目の図1にも、アーキテクチャとOSの流れが出とる

115 :仕様書無しさん:03/10/26 08:06
>>111
前はマ板で「汎用機」と書くと、「2ch的には凡庸機」と毎回書かれた。
無視して「汎用機」と書いてたら、最近は見かけなくなった。
隠語も楽しいけど、この多様化の時代に、人にもおしつけんなっつーの。

116 :仕様書無しさん:03/10/26 08:55
>>107
用途は汎用でもPC/UNIX/オフコンは、普通は「汎用機」とは呼ばない。
携帯してもPHSやサイフは、普通は「携帯」とは呼ばないのと同じだね。
どちらも特定の系列を指す呼称になっちゃったからね。
(ま、オフコンを「汎用機」に含めるマスコミはあるが)

117 :仕様書無しさん:03/10/26 09:56
>>113
「DOS(Disk Operating System)」と言って通じる人は、今では汎用機関係者でも少ないだろな。
PC用の「DOS(Disk Operating System)」とフルスペルまで同じだが、
別物で、実は汎用機用の方が2年早い。(MSが買ったQDOSとか言われるとわからんが)

1979 43xx用のOSとして「DOS」発表(後のVSE系統)
1981 初代IBM PC登場(PC DOS 1.0、このOEM版がMS-DOSとなった)

118 :仕様書無しさん:03/10/26 09:59
>>117
QDOSはスペル違い【Quick and Dirty Operating System】

http://e-words.jp/w/QDOS.html
http://ew.hitachi-system.co.jp/w/QDOS.html

CP/Mクローンだしね。

119 :仕様書無しさん:03/10/26 10:05
CMSもいれてよ。shell?とか言われそうだけど。

120 :仕様書無しさん:03/10/26 10:12
>>119
CMSは >>113 のVM/SPの中に入ってるよ。VM専用ゲストOSだと思うし。

DISKをMINI-DISKとして切って、A-DISK, B-DISK...と仮想的にアサイン(マウント)して、
実行モジュールやスクリプトは、Aから順に探していく(Aがカレントディレクトリ風になる)んだよね。

強力なXEDITとか人気だったね、とか老人の会話(z/VMは現役だけど)

121 :仕様書無しさん:03/10/26 15:59
LOGOFFすると落っこちちゃうのはやめてください >VM
あれは初めてに人にはわからんよ・・・

122 :仕様書無しさん:03/10/26 16:28
>104
それはあれだろ 富士通ミュージアムを作成したヤシが >98 と同等ってことだろうよ
ちなみにFACOM−128Bを直せる人が数年前にFSASを定年退職したと聞いたぞ
(ん。ココはメインフレームオンリ?)


123 :仕様書無しさん:03/10/28 00:19
スレタイが・・・


ゴメン、何でもない。

124 :仕様書無しさん:03/10/29 23:46
ある日の会話
「くそっ、またおちた」(マウスぐるぐるK/Bバンバン!!)
「(また画面が青くなってる・・・)」
「こんなんでよくOSなんて言うよなー。
 OS(オペレーティングシステム)って対障害性とかもしっかりしているもんだろ?」
「でも一応OSだよ」
「これじゃ、オペレーティングシステムじゃなくて、落っこちても仕方ないの略じゃねーのか」
「あ〜なるほど。確かに(笑)」

125 :仕様書無しさん:03/10/29 23:53
>>124
で?

126 :仕様書無しさん:03/10/30 16:12
>124
個人ユースで390使いたいなら好きにすれば?
漏れは家で使うならWin2kがいいや

127 :仕様書無しさん:03/11/01 11:09
>124
語りつくされているけれど、理解
メモリとHDの空き、割り込みの競合を調べ、なお不安定ならクリーン・インストール。

1.メモリ
不十分だとナニをロードしたときに、オンメモリになにがあるかでも状況が違うが、トラブルのもと
実行するに足るメモリをのせる

2.やっぱりSWAPはしてるようなので、ナニとの兼ね合いでHDの空きを確保する

3.ソフトを選ばないとへたな小細工でレジストリを汚すナニもある。

4.クリーンで初めてトラブルの原因がわかったことがある

マニュアルを読み、調べて試してみる、という基本的なことをしないと、なんでも使えるように
ならないよ。

個性をみてトラブルの回避をしないとね。いいところもあるんだし。ナニとはさみは使いよう。



128 :仕様書無しさん:03/11/01 12:55
128MB

129 :仕様書無しさん:03/11/04 01:19
連休になるとカキコが減る傾向にある・・・

130 :仕様書無しさん:03/11/04 01:37
そうだね。

131 :仕様書無しさん:03/11/04 02:15
MP5600EXってLinuxとVOS3が両方とも使えて
過去の5600シリーズのDASDが引き継げるっていう
認識でいいの?

132 :仕様書無しさん:03/11/04 06:06
>124
じゃおまえがWindowsと遜色ないOS作ってくれよw


133 :仕様書無しさん:03/11/04 22:20
>>132
ユーザーインターフェース以外は全部勝ってるんじゃないか?
誰かWindows3.1みたいなのをMF用に作ってくれれば・・・

134 :仕様書無しさん:03/11/06 01:58
みなさん、来年四月からの消費税内税表示義務化で仕事は出そうでしか?


135 :仕様書無しさん:03/11/06 11:55
消費税の表示方式でドタバタするのは小売だろうし、
汎用機の出る幕じゃないだろう?



136 :仕様書無しさん:03/11/06 14:42
\DF

137 :仕様書無しさん:03/11/06 14:43
\TOJxxx,ALL,HOLD=OPER

138 :仕様書無しさん:03/11/06 14:45
rr,/STA DC

139 :仕様書無しさん:03/11/06 20:34
この板のみなさんは契約はとりあえず来年の3月までは継続なの?

俺のところは不景気の煽りで今年一杯で100人ほど切られるんだよね。


140 :仕様書無しさん:03/11/06 22:41
>>139
このご時世だし、どこも大変だね。
3月まで継続って言われてる所だって、
いつ終了になるか。 ((((((;゚Д゚))))))ガクガクブルブル

141 :仕様書無しさん:03/11/06 23:29
>>135
チェーンストア協会の動向がメーカーに影響を・・・

142 :仕様書無しさん:03/11/09 16:03
金融系ハード屋は新札対応のため大変だって


143 :仕様書無しさん:03/11/10 00:40
金融って言うより札を扱うハード屋だろ
自販機とか含めて・・・

144 :仕様書無しさん:03/11/10 00:47
選挙対応もあと少し
担当の人、もう少しだガムバレ

145 :仕様書無しさん:03/11/10 22:02
別にホスト屋さんはATM端末が更改されようと知ったこっちゃないぜぇ
端末管理チームはATMのテストが大変そうだ

146 :仕様書無しさん:03/11/11 15:25
なんでシステム構成を考えないで思いつきカキコするかなぁ。



147 :仕様書無しさん:03/11/11 22:07
>>146
ここは2chですよ

148 :仕様書無しさん:03/11/12 00:32
>>143
自動機を触らないハード屋もシステム部やらなんやらと
自動機の新札対応のスケジュール調整で忙しいぞ

>>145
苦笑・・・
>>142
ファーム屋も大変だぞ

149 :仕様書無しさん:03/11/14 20:32
IBMマンセー!!

150 :仕様書無しさん:03/11/14 20:57
わーーーーー
CSKだぁ

151 :仕様書無しさん:03/11/14 22:27
>>150
どした?

152 :仕様書無しさん:03/11/15 00:51
わーーーーー
TCだぁ

153 :仕様書無しさん:03/11/16 06:53
>>149
なんだかんだでメインフレームはIBMの独壇場だよな
>>150
CSKって聞いたことあるな・・・なんだっけ?

154 :仕様書無しさん:03/11/16 10:33
>>153
> CSK
ろくな社員いねぇ…。

155 :仕様書無しさん:03/11/16 10:59
>>150
ってか、なんでCSKでてきたんだ?

156 :仕様書無しさん:03/11/16 12:10
>>155
自動機がCSK用語だからだろ。

157 :仕様書無しさん:03/11/16 12:24
巻き舌宇宙で有名な紫ミミズの剥製は、
ハラキリ岩の上で音叉が生瞬きすると良いらしいぞ。
要ハサミだ。>>61

158 :仕様書無しさん:03/11/16 21:22
CSKってまだあるの?

159 :仕様書無しさん:03/11/16 21:35
           ttp://www.csk.co.jp/
        彡
(ノ ゚Д゚)ノ 

160 :仕様書無しさん:03/11/16 23:27
そろそろ .PQ して DEACT かな・・・

161 :仕様書無しさん:03/11/17 08:57
>>160
INACTIVEでまたーり汁。

162 :仕様書無しさん:03/11/18 00:51
プログラマー板になんでJCLなの?JCLってプログラプじゃないじゃんそう思わないオペレーター君?

163 :仕様書無しさん:03/11/18 10:24
香ばしいな、おい。
そうやってPGとOPの対立を煽りたいのか?


164 :仕様書無しさん:03/11/18 22:12
JCL無かったらPG動かせない

165 :仕様書無しさん:03/11/18 23:17
JCLも広く見れば、スクリプトやシェルの一種。
カタプロ化して反復させたり、リターンコードで分岐させたり。
つか、JCL書けないPGなんて存在するのか?

166 :仕様書無しさん:03/11/18 23:22
「JCLは俺らは・・・」<純コボラー

167 :仕様書無しさん:03/11/18 23:59
設計書いて、コード書いて、
JCL書いて、データ作って、
テストまでするのがPG。

じゃないの?

168 :仕様書無しさん:03/11/19 00:41
JCLちゃんとかけなきゃどんなにすばらしいプログラム書いても台無し

169 :仕様書無しさん:03/11/19 01:44
>>167
PGにはJCLサンプル作ってやらないと。
1からJCL書ける香具師は滅多にいない。
中にはBLKSIZE=100000とか書いて「おかしいです」とか言ってくる香具師もいるし。

170 :仕様書無しさん:03/11/19 01:56
>>169
「マニュアル読め。ファイルシステムくらい常識だろ!」
っと言ってやれ

171 :仕様書無しさん:03/11/19 02:01
>165
スクリプトだけどシェルじゃないでしょ

172 :仕様書無しさん:03/11/19 04:39
>>168
極論言っちゃうと、
OPいないとPGの作ったものなんて、ただのジャンクだしな。
逆にPGの作ったものがないとOPも仕事がないわけだが。
持ちつ持たれつだろ。

173 :仕様書無しさん:03/11/19 04:45
>>169
真理。でもサンプルPGM作ってやらないと、全く書き始められないPGもいる。

174 :仕様書無しさん:03/11/19 04:47
カタプロ書けないOPも困る。何でもベタに展開して書くなっつーに。

175 :仕様書無しさん:03/11/19 07:53
何十人もが一つのプロジェクトに参加してる大手に限って、

ろ く に サ ン プ ル す ら 整 備 さ れ て い な い 。

特定目的に特化した完成品見せて、どれとどれが重要かも指し示さずに、

「これ見れば作れるだろ?」

ヘエー。解析が無駄に面倒そうデスネ。解析しやすさを優先する先見性はその灰色の脳味噌
には存在しないんデスネ。もしや、誰も彼もにこういう無駄な時間を費やさせているんデスカ?

ああ無能 ああああ無能 ああ無能 -- 心の俳句

176 :仕様書無しさん:03/11/20 02:39
>>175
まともな大手じゃ、そんなん見たことないなぁ。業種にもよるのかな。
標準化やサンプルが多すぎ・古典すぎて、閉口する方が普通だが。

177 :仕様書無しさん:03/11/20 20:00
JCLとか技術的な分野は少しでも勉強すればある程度理解は出来る。
そんなことより業務内容が難し過ぎるぞ。
特に生保・損保!!
俺いまだに理解できんわ。多分これからもずっと。

178 :仕様書無しさん:03/11/20 20:46
最近のOPはレベルが下がったよな
まぁ、そんな流れなんだろうけど
コケたらダンプリスト持って殴り込んでくる頼もしい奴や
コケるバッチをあらかじめ予測して夜間バッチ前に忠告してくれたOPや
一般文書と同速度でパンチカードをスラスラ読むOPや
磁気テープを透かして見るだけで、レコード長とブロック長がわかる超能力OP
彼らはいったい何処へ・・・

179 :仕様書無しさん:03/11/20 21:13
>>178
仮にブロック長がわかるOPが存在したとしよう。
しかし、ブロック化されていないレコードであればわかるだろう。
ブロック化されていたら、レコード間ギャップはないからレコード長はわからんよ。
あくまで濃淡からブロックを識別してるだけだろうから。
まさか、ラベルを読んでいるわけじゃないだろうし。

180 :仕様書無しさん:03/11/20 23:43
>>177
保険は数学のプロフェッショナルの世界だよ
JCLなんかとはレベルが違う

181 :仕様書無しさん:03/11/20 23:54
このスレ、JCLって良い燃料入ったら一気に燃え上がりましたね

182 :仕様書無しさん:03/11/21 00:31
>>181
そうですね
ところで、おまいらDD文書くときどういう順番で書く?
おれはDISP、(LABEL)、(DSN)、(UNIT)、(DCB)、(SPACE)
貧乏性なのでSPACEはTRKを頻繁に利用してます(ショボイテスト環境なので)

183 :仕様書無しさん:03/11/21 00:38
ウチは内部規約で
//IN DD DSN=AAA.BBB,DISP=SHR,
// UNIT=SYSDA,VOL=SER=TEST01,
// SPACE=(TRK,(5,1),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=15440)

って、順番になってる
LABELはSPACEの行に置き換えてる。

184 :仕様書無しさん:03/11/21 00:46
>>183
おたくのDISKのトラックサイズいくつ?
規約のブロックサイズが微妙に気になるのですが

185 :仕様書無しさん:03/11/21 00:49
>>184
詳しくは知らないが47476BYTEだったかな?
一応 ブロックサイズは15476BYTEに近づけるようになってる。

186 :仕様書無しさん:03/11/21 01:01
>>185
すげー非効率だな

187 :仕様書無しさん:03/11/21 01:06
>>186
なんで?

188 :仕様書無しさん:03/11/21 01:12
>>187
47476/15476=3.06・・・・
47476-15476*3=1048
いまどき1048バイト程度はどうでもいいか?
俺としては47476/2=23738を目指すぐらいがいいと思うのだが

それにしても47476バイトってずいぶん古そうなDISKだな

189 :仕様書無しさん:03/11/21 01:20
47476/2=23738 で丁度23738BYTEのブロックサイズだと
ブロック間ギャップの分がオーバーして2BLOCK/TRKにならないから
若干余裕を持たしていると聞いたことがあるから納得してたんだけどなぁ

DISKの場合はギャップって発生しないのかな?

190 :仕様書無しさん:03/11/21 01:30
IBGってもともとテープをぶん回すときの緩衝のための予備分じゃないの?
お皿が何枚も重なってる構造のDISKにそんなものが必要なのかね?
誰か教えて〜

191 :仕様書無しさん:03/11/21 01:33
明日は仕事暇暇だし、一度試してみるわ
ほな、おやすみ〜

192 :仕様書無しさん:03/11/21 07:14
>>178
数メートル引き出したあとにあるシールの後ろでないと記録してないわけだが
そんなに引き出すのめんどいだろ


193 :仕様書無しさん:03/11/21 08:26
システム欠陥の原因は凡妖気

http://www.smbc.co.jp/news/j100159_01.html

194 :仕様書無しさん:03/11/21 10:16
ブロック長 試行結果

固定長ファイル
レコード長 83
ブロック長 23738
ブロック化係数 286

で、572レコードのデータセットを作った結果 割当てトラックは2トラックとなった

本当に最適な計算式ってどんなんかな?

195 :仕様書無しさん:03/11/21 21:20
ウチもVolume不足なんだけど、いまどきのお客さんは潤沢なDASDがあるのかと思ってました。

196 :仕様書無しさん:03/11/21 23:09
>>194
R0のオーバーヘッドだとかいろいろな要素があるが忘れた。
TRKCALCマクロに計算させるのが一番だが、JCLでBLKSIZE=0にしたら最適なブロック長にしてくれるYO

197 :仕様書無しさん:03/11/21 23:47
すwごwすwぎwるwww

198 :仕様書無しさん:03/11/21 23:47
誤爆だ。
邪魔してすまぬ。


199 :仕様書無しさん:03/11/22 00:56
>>193
亀岡孝彰氏(現三井住友銀行の副頭取)が心不全のため死去とのことだが・・・


200 :仕様書無しさん:03/11/22 01:27
ああ、あったあったこのスレ。
漏れワシントン条約で保護されているはずのPL/I使いなんだけど、
業務端末からの電文入力を受け取るような制御部分って
PL/Iではできないの?
開発環境にもDOS窓のような実行中の割り込み入出力
画面がないし、言語仕様からしてないのかな。
なんか、数あてゲームすら作れないのが寂しい。

201 :仕様書無しさん:03/11/22 01:32
>>200
ホストはI?漏れはIしか知らんが、普通はCICSやIMSなんかのミドルウェアを使うと思うのだが・・・
使わないんならVTAMマクロを自力でコーディングすれはLU0なりLU2なり制御できるのでは。

202 :仕様書無しさん:03/11/22 03:44
この板で0C4ダンプを追えるやつってどのくらい居んだ?
昔は、ダンプリストを風に吹き流していたっけなぁ。なつかしい。

203 :仕様書無しさん :03/11/22 04:40
ダンプリスト、何回か出したことあるけどそれでエラーの原因が分かったことって無いな


204 :名無しさん:03/11/22 08:33
む?じゃあバグ修正後は再コンパイル?そんな贅沢させてもらえんだろ?
それとも、時代がちがうんかのぅ。


205 :仕様書無しさん:03/11/22 10:05
>>ダンプリスト、何回か出したことあるけどそれでエラーの原因が分かったことって無いな
OPじゃ無理じゃない無論OPじゃなくても追うのは難しいと思うが
これだけははっきり言える「OPにはダンプを解析する必要無し!!」


206 :仕様書無しさん:03/11/22 10:15
>203
ってことは・・・
オヌシはペーペーとみた!!

207 :仕様書無しさん:03/11/22 10:32
ソースよりはダンプ。昔LM格納用のDSをコンプレスし忘れてて
なぜバグが直らないのか悩んでたんをダンプで発見したなー。

208 :仕様書無しさん:03/11/22 15:42
ITは先が短い趣旨の発言を2chでよく見るのですが、
汎用機系の世界でも同じことなんでしょうか?
私は中小正社員で派遣なんですが、今の派遣先には
派遣会社(協力会社)でも40過ぎの人を結構見かけます。
彼らはお客の業務のことを何でも知り尽くしているという感じで、
昔大規模なシステム改変前の状況などにも詳しく、生き字引のようです。
業務上で使う技術は誰でもできるようなことなので、
生き残るには業務知識に精通して、管理的ポストに就かないとだめなんでしょうね。

209 :仕様書無しさん:03/11/22 16:16
>183
ウチは内部規約で
//INFILE DD DSN=AAA111.BBB222,DISP=SHR
//OUTFILE DD DSN=AAA111.CCC333,
// UNIT=SYSDA,DISP=(NEW,CATLG,DELETE),
// DCB=(RECFM=FB,LRECL=400,BLKSIZE=27600),
// SPACE=(TRK,(5,1),RLSE), VOL=SER=TEST01
こんな感じ。知っている香具師少なくて守られてないけど

210 :仕様書無しさん:03/11/22 19:51
>>202
ミドルウェアの0C4ならメーカ呼ぶし(ソースないから解析は無理、)
最近めったにアプリの0C4は見ないから、ダンプ読む機会はもう無いかも

211 : :03/11/22 20:11
0C7とか0C4とかだったら(それも大変だけど)DB系のエラーメッセージなんかが出るともうわやくちゃ。

エラーコードをたよりにマニュアルを見てもはぁ?で「だから何を言いたいんだ、おまえは?」とマニュアルに
向かっていったことも何度か。


212 :仕様書無しさん:03/11/22 21:10
操作員に連絡してください・・・・
操作員っておれのことじゃねーか!

213 :仕様書無しさん:03/11/22 21:17
>>202
アセンブラで組んでた時はダンプリストは重宝しましたね。
COBOLやPL/Iだとダンプ追う前に経験と勘でデバックしちゃいますけど。

214 :仕様書無しさん:03/11/22 21:38
オペレータがプログラマを語るスレはここですか?

215 :仕様書無しさん:03/11/22 21:44
>>214
違います(藁

216 :仕様書無しさん:03/11/23 16:51
>>213
それはあるね

217 :仕様書無しさん:03/11/23 16:55
>>183,209
渡り歩いてるけど、大半のユーザーではDSNとDISPが先だよね。
開発環境から本番環境とかの際は、物理属性の明示指定を取って、
以降を落とすとかしやすいし。

>>182 みたいのは、初めて見た。

218 :仕様書無しさん:03/11/23 16:59
>213
デバックってなに

219 :仕様書無しさん:03/11/23 17:01
>>183
//IN DD DSN=AAA.BBB,DISP=SHR,
って書いたら
//IN DD DSN=AAA.BBB.CCC,DISP=SHR,
って一時的に直してSUBMITするときダルイだろうがゴルァ!
//IN DD DISP=SHR,DSN=AAA.BBB,
って書けやモルァ

220 :仕様書無しさん:03/11/23 17:02
>>218
ゾーン十進に戻すことじゃないか?

221 :仕様書無しさん:03/11/23 17:03
>>208
マジレスしちゃうと、汎用機に限らず、そりゃそうでしょ。

若さで体力だけじゃ段々やっていけないし、
実力主義とはいえ扶養家族も増えるので収入増が求められるし、
シニアになると能力とは別に、会社もお客も自然と管理を期待してくる
(将来案件や工数や契約や業界動向とかの相談が増えてくる)からね。

ただ汎用機の場合、大規模システム構築経験者が40才台に多いとか、
昔の技術(話題のダンプトレースとか)がそのまま使えるとかで、
若手は汎用機(保守が多い)を嫌がるとかで、
オープン系よりは年寄りの比重が確かに多いけどね。

222 :仕様書無しさん:03/11/23 17:04
位置パラメータ指定だとどの順番だっけ?汎用機離れて十三年、忘れるよな〜

223 :仕様書無しさん:03/11/23 17:05
>>218
虫とり。ちゃんとした英語らしい。

http://www2.alc.co.jp/ejr/index.php?word_in=DEBUG&word_in2=%82%A0%82%A2%82%A4%82%A6%82%A8&word_in3=1xnNakOXFq05IYjYXA

debug
【発音】di`:bΛ'g、【変化】《動》debugs | debugging | debugged
【名】 《コ》デバッグ◆コンピュータ・プログラムのミスを見つけて修正すること
【他動-1】 〜から虫を除く、除虫{じょちゅう}する
【他動-2】 〜から盗聴器{とうちょうき}を取り除く
【他動-3】 〜の欠陥{けっかん}を捜して直す
【他動-4】 《コ》デバッグする

224 :仕様書無しさん:03/11/23 17:08
>>219
こういうユーザーも確かに多かった

225 :仕様書無しさん:03/11/23 17:13
>>221
業務系や管理者の他に、セキュリティ(製品だけでなく設備や運用も含めて)とか、
プロジェクト管理技法(PMBOX, CMMI推進とか)とかに特化するとか、
ITアーキテクトになるとかあるね。実際周囲でもかなりいるよ。

実は、仕事はいくらでもあるんだよ。いつも募集してるし。
会社から見ると使える人が少ないだけで。

226 :仕様書無しさん:03/11/23 17:13
>223 debugはわかるがデバックがわからん

227 :仕様書無しさん:03/11/23 17:14
>>226
ほもの事

228 :仕様書無しさん:03/11/23 17:17
語尾のグはおうおうにしてクと発音されるぞ。
少なくとも洩れにはそう聞こえる。<デバック

229 :仕様書無しさん:03/11/23 17:35
>>226
どっちでもいいじゃん。意味が通じれば。
細かいことを気にすると、頭皮によくないよ。

230 :仕様書無しさん:03/11/23 17:41
おまいらはロギンクとかクラスタリンクとか言ってろ

231 :仕様書無しさん:03/11/23 17:48
>228
それは方言だ。
促音の後にそうなる。
デバックは有るが、ロギンクやクラスタリンクは無い。

232 :仕様書無しさん:03/11/23 17:48
>>230
2年後ハゲケテーイ!!

233 :仕様書無しさん:03/11/23 18:55
発音はともかくカタカナで書くと頭悪そうに見えるぜ

234 :仕様書無しさん:03/11/23 22:54
>>233
舶来コンプレックス(´,_ゝ`) プッ

235 :仕様書無しさん:03/11/24 00:01
>>227
それはバックデ

236 :仕様書無しさん:03/11/24 04:00
アセンブラやってると、期待と違った出力で正常終了してしまうバグのほうが、0Cxより厄介。


237 :仕様書無しさん:03/11/24 09:00
>>236
それは言語にかかわらず

238 :仕様書無しさん:03/11/24 14:13
アセンブラやってると、アルゴリズムが明らかに間違ってるのに期待通りの出力で正常終了してしまうバグのほうが0Cxより厄介。

239 :仕様書無しさん:03/11/24 19:46
>>238
それはソースとロードモジュールが微妙に違うという ありがちなオチ?

240 :仕様書無しさん:03/11/24 20:46
>>238
どんな場合に発生するのかちと興味をもちますた

241 :仕様書無しさん:03/11/24 22:00
>>238
テストデータが悪いんだろ

242 :仕様書無しさん:03/11/24 22:43
プログラマがトウシロってことで一件落着

243 :仕様書無しさん:03/11/24 23:13
胃の調子が悪いんですよね。
でも腹減ったな。
でも喰ったらまた気持ち悪くなりそうだし。
困ったもんだ。

244 :仕様書無しさん:03/11/25 16:44
http://itpro.nikkeibp.co.jp/free/NT/NEWS/20031125/2/
カブドットコム証券,オンライン・トレーディング・システムに64ビットの
Windows Server 2003とHPのIA-64サーバーを採用


プププ。凡妖気なんて見向きもされませんな。

245 :仕様書無しさん:03/11/25 20:17
>>244
買えないだけだろ

246 :仕様書無しさん:03/11/25 21:01
>>244
っつーか「カブドットコム証券」って知らねーし。
そんなマイナーなところは基幹業務に汎用機は必要ねーだろ。

247 :仕様書無しさん:03/11/25 21:17
>>244
毎週火曜日はシステムリブートの日だなw

248 :仕様書無しさん:03/11/25 21:47
>>246
244もどうかと思うが、カブドットコムを知らないお前もアホ
コンピュータばっかり見てないで普通の社会人として新聞ぐらい読めよ

249 :仕様書無しさん:03/11/25 21:55
>>248
漏れも知らんかった。逝ってきます。

250 :仕様書無しさん:03/11/25 22:30
カブドットコム証券に是正命令
http://www.mainichi.co.jp/digital/netfile/archive/200304/07-5.html

くぷぷ。さすがWindowsを使っているだけの事はあるな。

251 :仕様書無しさん:03/11/25 22:49
カブドットコムとジャスダックって、どう違うの?

252 :仕様書無しさん:03/11/25 22:58
まあこれから新規で1からシステム作る時にわざわざ汎用機は選ばんし、選ばんよね。
ノウハウ全然ないからそもそも絶対無理。

Iなんかは盛んにニューワークロードとか言ってるけど、結局は既存顧客のzServerへの囲い込みだし。
(Iは自社内でもシェア喰いあってる)

253 :仕様書無しさん:03/11/25 23:08
>>251
前者は証券会社、後者は証券取引市場

254 :仕様書無しさん:03/11/25 23:19
カブドットといえば三和系
三和といえば日立系
なのに汎用機を選択しなかった意味は大きい

255 :仕様書無しさん:03/11/25 23:26
フローラを選択したのか?

256 :仕様書無しさん:03/11/26 10:46
カブドットコムの法人株主にマイクロソフトが入ってるなw

257 :仕様書無しさん:03/11/27 13:17
日立の汎用なんか10年前に終わってるからな
今更使うかってーの

258 :仕様書無しさん:03/11/27 21:42
>>244-257
素人な会話が繰り広げられてるね
・カブドットを知らないのは論外
・ネット銀行、ネット証券では、基幹のオープン系は別に珍しくない
・一般の地銀・都銀では、基幹のオープン系はかなり珍しい(毎回記事になる)

259 :仕様書無しさん:03/11/27 21:43
>>251
JASDAQは証券取引所だろが

260 :仕様書無しさん:03/11/27 21:47
>>252
昔から当然、部門内(汎用機、UNIX、IA、AS)で食い合ってるんだが、
最近は全体でも伸びてるのがブキミ

http://www.zdnet.co.jp/enterprise/0311/27/epi01.html
世界サーバ市場、流れに反しUNIX好調なIBMが首位キープ

食い合ってるといえば、HP、Sunも程度問題かね(自社RISC&自社UNIX,IA&Linux)

261 :仕様書無しさん:03/11/27 22:00
>>260
サーバーブランド統一とイメージ戦略(オートノミック)の効果かな。

ただし、zのオートノミック関連機能に関しては、どれだけ本当に使われてるかは疑問だなあ。
IRDが勝手にLPARをまたがってCPU配分する恐怖に、SRMガチガチのユーザーは耐えられるか?
WLMゴールモードの浸透具合すら疑問なんだが。

262 :仕様書無しさん:03/11/27 22:07
>>260
この記事読むとWinもシェアを確実に伸ばしてるようですね。
WinよりUNIX(Linux)のほうがいいと思うんだけどね。
とにかくWinのレジストリをなんとかしてくれ。

263 :仕様書無しさん:03/11/27 23:28
汎用機の思い出

FACOM M760でオンライン終了後のバッチ処理が朝方近くまで、かかっていたのが
M1800に変わって夜中の0時頃で終了して、びっくりしたことがあった。
(外見もM760よりM1800の方が見栄えが良かった。)

オペレーションプロシージャを良く作ったなあ。

264 :仕様書無しさん:03/11/28 02:47
>>258
最初の2行は同意するが

地銀で一般とか言うのはまぁわかる気もするが、都銀で一般じゃないっていうとこあんのかよ
都銀を見て一般って言ってんだろ
地銀なんてもともと都銀のシステム買ってっただけなんだし

おまいは全ての金融機関のシステムを取り仕切ってるのかよ

265 :仕様書無しさん:03/11/28 09:48
>>264
何を都銀と言うかもあるが、旧長信銀の新生銀行は、今は都銀でオープン系だよ。
ただし店舗、端末、口座、トランザクション量は多くないけど。

4大メガバンクも、勘定系メインは汎用機だが、対外接続など基幹周辺系は、
徐々にオープン系を組み合わせてる。

地銀が都銀を買ってるってのは完全に誤解。確かに2次オン、3次オンと
都銀が一段落してから地銀などに回った経緯とか、基盤面とか業務共通系
パッケージ(SAILとか)もあるが、アプリ面では地銀に不要な機能・項目が
多すぎなので、基本は個別開発してる。

例えば「じゅうだん会」参加行は八十二銀行パッケージが基本。

地銀が都銀の基幹パッケージをそのまま採用ってのは、先日発表の
東京三菱パッケージくらいじゃないか?

仕事上関係するのは数行程度だけど、別に全部の金融機関を取り仕切ってなくても、
こんな話はこのスレでも、日経コンピュータでも、さんざん既出だよ。







266 :仕様書無しさん:03/11/28 09:56
>>265
>こんな話はこのスレでも、日経コンピュータでも、さんざん既出だよ。

既に前スレみたいすね。地銀のオープンは八千代銀行(NEC BankingWeb21)とかすね。



267 :仕様書無しさん:03/11/28 10:16
銀行の勘定系

新生銀行(都銀でWin系)
http://www.idg.co.jp/CIO/contents/casefile/casefile90.html

八千代銀行(NEC BankingWeb21、UNIX系)
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20030610/1/
http://www.nec.co.jp/press/ja/0306/1001.html

じゅうだん会(82BANK、IBM汎用機系)
http://www.82bank.co.jp/news/2001/news20010418.html

NTTデータの地銀共同化(BeSTA、日立汎用機系)
http://www.nttdata.co.jp/release/1999/1130.html

日本金融新聞
http://www.fin-bt.co.jp/comment52.htm

東三「地銀共同パッケージ」(IBM汎用機系)
http://www.google.co.jp/search?q=cache:LPvump-av-0J:www.btm.co.jp/press/news2003/pdf/news185.pdf+%E5%9C%B0%E9%8A%80%E5%85%B1%E5%90%8C%E5%8C%96&hl=ja&ie=UTF-8
http://www.ibm.com/news/jp/2003/07/07112.html

東邦銀行(富士通 PROBANK、F汎用機+オープン系)
http://pr.fujitsu.com/jp/news/2003/09/16.html
http://www.fin-bt.co.jp/comment136.htm

268 :仕様書無しさん:03/11/28 10:23
ま、今では適材適所が常識。MF至上主義も、OPEN至上主義も迷惑。

269 :仕様書無しさん:03/11/29 16:59
IBM「次世代金融システム」(J2EEで、汎用機・オープン系どちらでも動く、まだ実績なし?)
http://www-6.ibm.com/jp/domino05/ewm/NewsDB.nsf/2003/10083

270 :仕様書無しさん:03/11/29 17:04
国有化される足利銀行は、北拓・日債銀・長銀・りそな等と同様、Iだったみたいね。
http://www-6.ibm.com/jp/domino02/finance/finimwww.nsf/0/a8daef23f6f88002492569bb001d9ea3?OpenDocument

271 :仕様書無しさん:03/11/29 17:12
>>270
足利は、ATM・WANは富士通、ALMはUNISYS
http://telecom.fujitsu.com/jp/solution/case_study/case12.html
http://www.unisys.co.jp/users/unisys_news/9809/9809uza.html

東三パッケージに移行予定だったが、国有化で延期・中止か???
http://www.mediaselect.co.jp/news/0304/25/0304250111.html

272 :仕様書無しさん:03/11/29 18:51
>>265
誤解って・・・
誰も地銀が都銀のシステム買ってそのマンマ使ってるなんて言ってないじゃんw

あなたが既出といってることはもちろん認識しておりますよ。

258と264の文章に対してのレスとしてなんか変じゃないかい?

ま、どうでもいいけど。

273 :仕様書無しさん:03/11/29 20:44
>>272
最初の >>264 の書き方が簡単すぎるから、誤解されるんでは?
あれじゃ「そのマンマ」と読んじゃう人も大勢いると思うけどな。

ま、どうでもいいけど。

274 :仕様書無しさん:03/11/29 21:04
足利、去年までいた会社で人を出してたな。
でも対応悪くてメインバンクは栃木銀行だった。

そして資金援助要請にこたえて足銀にいくらか出資してたよ。
どーなるのかなー、あのかいしゃー。




275 :仕様書無しさん:03/11/30 00:54
メインフレーム離れてもうすぐ2年。
ネットワーク系よりメインフレームの方がやり甲斐があったなー。
金融系なんて1個のバグで何千万もすっ飛ぶようなスリルとか。
今やってる仕事はWeb関係だけど、最初からネットワーカーな連中に追いつくのは至難の業。
そこそこ憶えは早い方だって言われるけど、根本から脳味噌改造する必要があるしな。
おまけに流行ってる割には単価安いからもうからないしさ。
コード書いててさぁ「ああ、この手法メインフレームでもこんな時に使えるなぁ」とか、つい考えちゃったりして。
メインフレーマーに戻りたいな…2年ブランクできるときついかな…。

276 :仕様書無しさん:03/11/30 00:55
なんて言うか、大きな会社や経済を動かす位のシステムに参加したい。(鬱)

277 :仕様書無しさん:03/11/30 00:58

180 名前: 仕様書無しさん Mail: sage 投稿日: 03/11/29 22:18
FutureshockかKraftwerkだな
FutureshockのCDジャケットはメインフレーム好きの人にはたまらんかもw
http://www.amazon.co.jp/exec/obidos/ASIN/B00007KK7J/qid=1070111765/sr=1-1/ref=sr_1_2_1/249-6162025-2745156

↑さっぱりわからん
ロボットみたいなのが写ってるけど、どの辺がたまらないの?


278 :仕様書無しさん:03/11/30 01:01
漏れも>>275さんと同じような経歴。
Webは開発期間短いし単価も安いよね。
ただどこもシステム構築の基本的な考え方は一緒でしょ。
そう考えるとメインフレーム(とゆーか金融系)の仕事は
スケジュール的に余裕もあるし、そっちに戻りたくなる気持ちには
同意できますね。


279 :仕様書無しさん:03/11/30 09:15
>>277
カートリッジ・システム・テープ(CST)のテープユニットだね。
日立かKEL(正確には日立のOEM)だったかな?この形は


280 :仕様書無しさん:03/11/30 12:23
>>277
こいつらelectraglideきてて、フロアの巨大スクリーンにこの装置写しまくりだったんだよ。
筐体までは判別できなかったんだけど、テープユニットだったのね。

パネルはIBMの3490Eも一緒だなぁ。

281 :仕様書無しさん:03/11/30 12:53
>>280
うほっ
漏れはUnderworldとLFOで踊りまくって
昨日の夜から朝まで全身筋肉痛状態で客先で仕事でつた


282 :仕様書無しさん:03/11/30 23:31
>>275
新卒から会社の指示でメインフレーム系官公庁の仕事をして3年になります。
やはり最初は流行のオープン系に憧れていたのですが、
このままメインフレームで業務に精通して言ったほうが得策なんでしょうか?
なんというか、オープン系の話を聞いてると、こっちと時間の流れる速さが違いすぎますね。
こっちはいつまでも同じような仕事をしていますが、
オープン系は時々刻々と流行り廃りが変遷していって、正にウサギとカメみたいなんですけど。

283 :仕様書無しさん:03/11/30 23:46
>>282
どっちでもいいんじゃない?業務知ってれば強いのは同じ。
Web、TPモニタ、運用管理、セキュリティとかは、どっちでも基本は同じだし。

284 :仕様書無しさん:03/12/01 00:03
「無常」で、世は「憂き世」であっても、人生にはそれを十分に享楽できる要素も少なく

285 :284:03/12/01 00:06
http://pc.2ch.net/test/read.cgi/prog/1069960905/
の誤爆スマソ。

286 :仕様書無しさん:03/12/01 18:22
>>279
日立のに見えるな。

287 :仕様書無しさん:03/12/01 22:13
ウィンドウズで銀行システム――マイクロソフトとユニシス 
http://it.nikkei.co.jp/it/news/newsCh.cfm?i=2003113007719j0&h=1
新システムは他行との取引データのやり取りなど中核業務を担う勘定系と、
人事・給与など周辺業務を行う情報系を一体化する。高い信頼性が必要な
勘定系までウィンドウズで構築する例は欧米金融機関にもない。

http://itpro.nikkeibp.co.jp/free/NC/NEWS/20031201/137027/index.shtml
日本ユニシスのWindows勘定系、三重県の百五銀行が第1号ユーザーに


------------------------------------------------------
日経の「世界初」は誤報。新生銀行も勘定系がWindowsの筈。
Microsoftの発表を間に受けるから。日経コンピュータの方がマシ。


288 :仕様書無しさん:03/12/01 22:15
メインフレーマーはしねぇ

289 :仕様書無しさん:03/12/01 22:16
いつまでたっても「世界初」なような。まともにいくのはね。

290 :仕様書無しさん:03/12/01 22:41
>>287
百五銀行大丈夫か?.NETで作るのか?月末にサーバー落ちるに
2000ガバス。


291 :277:03/12/01 23:09
遅レスすみません
なるほど、メインフレーム用のテープドライブだったんですね。
DATやDLTの親分みたいな物と考えて問題無いのでしょうか?
(DLTで80GBとかだから100GB位バックアップ出来るのかな?)

292 :仕様書無しさん:03/12/01 23:31
>>291
CSTは15年前ぐらいに出たテープだからと初めに言い訳してみるが非圧縮で200Mだ(w
IBMで3592って最新のテープで非圧縮で300Gだから圧縮で約1Tか<時代は変わったな
でもこんなテープで1JOBでちょろんと書いて終わりってのももったいないな(w
参考
ttp://www-6.ibm.com/jp/supply/storage/cst/tape.html

293 :277:03/12/01 23:41
>>292
200MB!
写真のドライブは昔の規格だったんですね。
今は1巻1TBですか・・・
さすが銀行や官庁で使うコンピュータだけあって桁が違いますね。
DLTで感動してる漏れは井の中のなんとやらだw


294 :仕様書無しさん:03/12/02 00:14
金融板に百五銀行のWindows基幹系のスレが立ってます。
http://money.2ch.net/test/read.cgi/money/1070281136

お前ら、コンピュータの素人どもにガツンと言ってやれ!

295 :仕様書無しさん:03/12/02 01:13
百五銀行のシステム2007年稼動?
それまでに何回Windowsの変化があるかな・・・
ホントに汎用機よりコスト安いのか?

296 :仕様書無しさん:03/12/02 13:05
だれかVTAMマクロの日本語マニュアル知ってたら教えてください。
先人が作ったソースがあって見よう見真似でいじってるんですが、
意味を正確に理解したいんです。

297 :仕様書無しさん:03/12/02 13:44
英語のマニュアルがあるならそっちを調べてみたら


298 :仕様書無しさん:03/12/02 22:46
日本語マニュアルでは正確に理解するの難しいんじゃね?
面白い訳をみるならお勧めだが

299 :仕様書無しさん:03/12/03 00:37
先月の月次処理のPG修正をミスっていた為、
客先に5千万の損害を与えてしまいました。

もうだめぽ・・・

300 :仕様書無しさん:03/12/03 00:42
>>日本語マニュアルでは正確に理解するの難しいんじゃね?
はげしくどうい。
IBMの日本語マニュアルはさっぱり×

301 :仕様書無しさん:03/12/03 00:51
いまだにキーボードが鍵盤で
インストールが導入になってるの?

302 :仕様書無しさん:03/12/03 05:49
アプリケーションが適用業務だっけ?

303 :仕様書無しさん:03/12/03 14:01
公開されてて検索できるが、今は普通の用語になっているよ

IBM 情報処理用語英和対訳集
http://www-6.ibm.com/jp/manuals/nlsdic/nlsdic.html

304 :仕様書無しさん:03/12/04 21:00
>>299
リアルだな。
まぁガンガレ!

305 :仕様書無しさん:03/12/06 23:08
controler → 制御プログラム
manager → 管理プログラム

306 :仕様書無しさん:03/12/09 14:48
CPU → 中央演算処理装置
Processor → 処理装置
Monitor → 表示装置
Printer → 印刷装置
Modem → 変復調装置
DASD → 直接アクセス記憶装置 (HDD)
Tape Drive Unit → 磁気テープ装置
TSO → 時分割多重化オプション
VSAM → 仮想記憶アクセス方式
IMS → 顧客管理システム
CICS → 顧客情報管理システム
SNA → システムネットワーク体系
shutdown → 遮断 (OS/2)

307 :仕様書無しさん:03/12/09 22:37
>>299
大丈夫だよ5000くらい。資本金の10%超えなければ

308 :仕様書無しさん:03/12/10 14:36
ibmの3文字って同じ3字で意味違うのあるから、キライ

309 :仕様書無しさん:03/12/10 23:45
金融でウナフリってなんですか?

310 :309:03/12/10 23:57
わかりました。すみません。
モールスなんですね。

311 :仕様書無しさん:03/12/11 00:51
NLPは?

312 :仕様書無しさん:03/12/11 13:30
Nihongo Line Printer

313 :仕様書無しさん:03/12/12 21:57
ソウキン、ウナソウ、コクソウ、ジフリ

314 :仕様書無しさん:03/12/12 22:01
ウナジュウ、ウナドン

315 :仕様書無しさん:03/12/14 14:44
JOB NOT RUN - JCL ERROR

316 :仕様書無しさん:03/12/14 15:22
>>4
「汎用コンピュータのひろば」
http://homepage1.nifty.com/KSudou-NET/ks0D0D01.htm
これ、無いけど、どこへいったの?

317 :仕様書無しさん:03/12/14 16:57
>>316
そうなんだよね。何ヶ月も前から見当たらず、検索でも発見できず。
各社JCLの違いとかあって面白かったんだけど、これも時代か。

318 :316:03/12/14 21:10
>>317
http://homepage1.nifty.com/KSudou-NET/
あったよ

319 :316:03/12/14 21:11
http://www.google.co.jp/search?q=KSudou-NET&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=
ついでに、このスレが2番目に

320 :仕様書無しさん:03/12/14 22:36
Fのかかわるところはことごとくだめだな。

321 :仕様書無しさん:03/12/16 01:03
>320
おまえHか?

322 :仕様書無しさん:03/12/17 00:29
F,H,I,B,Uほかに何かあります?略称。

323 :仕様書無しさん:03/12/17 00:39
N、あととっくの昔に無いけどT,M,O

324 :仕様書無しさん:03/12/18 00:37
AとSは?
日本国内は無縁・・・


325 :仕様書無しさん:03/12/18 11:01
>>322
Bってバローズ? ブル?

326 :仕様書無しさん:03/12/18 11:04
>>323
NはNCRもあったね。紛らわしい。

IBM vs BUNCH時代の、BUNCHの内訳ってこんなだっけ?
バローズ、UNIVAC、NCR、CDC、ハネウェル。
ハネウェルがNEC ACOSの1つの流れだたっと思う(昔はダブルロゴだった)

327 :仕様書無しさん:03/12/18 11:06
>>324
アムダールは、一時、親会社の富士通が国内販売もしてた。
IBMからOSライセンス受ける必要もあって、ほとんど(全く?)売れなかったみたいだけど。

Sって?

328 :仕様書無しさん:03/12/18 16:23
>>326
そーいやNCRもNか、BUNCHは多分それで合ってる。

ACOS6がハネウェルの流れ組んでいたと思われ
ACOS2は今やIA…時代だなあ

329 :仕様書無しさん:03/12/18 20:57
昔ファコムハイタックって保守会社があった


330 :仕様書無しさん:03/12/18 21:21
バロース 万歳
高千穂交易 万歳

331 :322:03/12/18 23:08
>>325
そうBは、でも古いかった。

332 :仕様書無しさん:03/12/18 23:08
>>325
あって、場ロース

333 :仕様書無しさん:03/12/18 23:13
パナファコムってのもあったな。
名前のとおりパナとファコム。
ソード電算機ってのもあった。潰れた。
メインフレームと関係なくてスマソ

334 :仕様書無しさん:03/12/18 23:58
>327
S=SIEMENS
FのマシンをOEMで売ってた

335 :仕様書無しさん:03/12/19 08:18
>>329
そうだね、件坂登ってFHL通ったな。今や懐かしい思い出だ・・

336 :仕様書無しさん:03/12/19 14:29
>>334
そっか。古河とシーメンスの提携で富士電機ができ、
その子会社が富士通だったんだね。歴史あるなぁ。

日本におけるシーメンスの歴史
http://www.intersystem.jp/www/opening_page_htm/history.htm

http://www.mainichi.co.jp/digital/computing/199906/17/01back.html
富士通とシーメンスの関係は古く、富士通の親会社にあたる富士電機は、
古河電工とシーメンスが出資し、両社の頭文字、古河の「ふ」と
シーメンスのドイツ語読みのジーメンスの「じ」を取って誕生したという
経緯がある。富士通のメインフレームを欧州地域でシーメンスが販売する
など、これまでもビジネス面で提携関係にあった。

337 :仕様書無しさん:03/12/19 21:46
じじむさいスレだなぁ

338 :322:03/12/19 23:10
>>337
お気を悪くされました?ゴメンヨゴメンヨ。

339 :仕様書無しさん:03/12/19 23:51
JCM
何の略?

340 :仕様書無しさん:03/12/20 00:19
Job Control Manguage

341 :仕様書無しさん:03/12/20 06:04
まんげ?

342 :仕様書無しさん:03/12/20 15:06
Job Control Mangling

343 :仕様書無しさん:03/12/21 22:18
>>339
Japan Compati Maker:日本のIBM互換機メーカー(F,Hのこと)

欧米から見た用語だが

344 :仕様書無しさん:03/12/22 02:03
Makerかよ

345 :仕様書無しさん:03/12/22 03:54
製造業だから

346 :仕様書無しさん:03/12/22 03:57
ケツからはみでたものを掃除したくね?

347 :仕様書無しさん:03/12/22 04:28
F3 F3 F3

348 :仕様書無しさん:03/12/22 04:46
FP3 FP3 FP3

349 :仕様書無しさん:03/12/22 17:37
コマプロでJCL自動実行したら、TSSでABENDしたよ。

350 :仕様書無しさん:03/12/22 21:40
この間の三井住友銀行のトラブルの原因
ttp://itpro.nikkeibp.co.jp/free/NC/NEWS/20031219/137728/index.shtml


351 :仕様書無しさん:03/12/22 21:44
何回ミスってもテスト期間を削るんだねぇ

352 :仕様書無しさん:03/12/22 22:25
>>350
トラブルメーカーはいつもFだね

353 :仕様書無しさん:03/12/22 23:21
>>テスト期間を削るんだねぇ

それだけじゃない。設計はやっつけ。テスト方法もいいかげん。
バグが何件出たと言う表面上の数字ばかりに拘る。テスト期間中
はできるだけ多くのバグを出して潰すべきなのに逆にバグ件数が
多すぎると怒る。


354 :仕様書無しさん:03/12/23 02:04
テストの話題が出たところで基本的な質問が。

仕事してて、未だにフェーズの区別が良く分かってません。
PH2 → 概要設計
PH3〜6-1 → PG・単体テスト
PH6-2 → 結合
PH8 → 本番

ぐらいな大雑把な括りしか。。。
今更聞くに聞けず、なんとなくで区切ってんですが。
フェーズってもしかしてFだけの話なんですか?
こんな調子で仕事してたら、いつか>350みたいな障害出しそうで
こわいです。

355 :仕様書無しさん:03/12/23 09:53
富士通さん、国内の銀行システムから手を引いたら如何でしょうか・・・

356 :仕様書無しさん:03/12/23 11:19
>>355
無理.....。ホストだけならまだしも端末側はFがかなりのシェアを占める。
端末側がIだと保守料が高くなるのでユーザが嫌がる。

357 :仕様書無しさん:03/12/23 13:52
>352
全銀がFで
それに接続している三井住友のシステムが抑止要求に対応できなかったのでは・・・
(他の銀行はトラブル出てないし)
記事を読む限り三井住友の中継システムがFとは書いていないがFなの?

358 :仕様書無しさん:03/12/23 19:01
オブジェクト指向で設計するようになってわかったよ、
汎用機系で概要設計って、もまいら仕事してないじゃん。

359 :仕様書無しさん:03/12/23 19:21
最近の銀行システムって不具合が出たら直せばいいじゃんて感じで、最小限
の工程で構築してんの?

360 :仕様書無しさん:03/12/23 20:38
>>359
全てがそうという訳じゃないけどそういうとこが多い。

361 :仕様書無しさん:03/12/23 21:32
GS8800の処理能力が低すぎなんだよ
電々公社製超高速超大型コンピュータDIPSを使わないからこんなことになるんだよ

362 :仕様書無しさん:03/12/23 22:48
>>358
新技術を知って有頂天になり汎用機系のみんなが馬鹿に見えるってか?

363 :仕様書無しさん:03/12/23 23:30
>>358
オブジェクト指向ってプログラミング・フェーズでの思想でしょ?
システム構築の基本設計は一緒だと思ったりしてみた。


364 :仕様書無しさん:03/12/23 23:38
>>363
お願いですから、ちっとは勉強してくださいよ、
おいらの3倍くらい給料もらってんでしょ。


365 :仕様書無しさん:03/12/24 00:26
仕事上どっちが上とかは考えたこと無いけど、
フリーの身分から言わせてもらうと、営業的には技術的進歩の無い
汎用機が仕事探すのは楽。
ただオジサンばかりでつまらないので、たまにはweb系で若い娘とも
仕事したいと、無理して探してみたりもするけど、短期で不安定なのが
ちとキビシイ。

366 :仕様書無しさん:03/12/24 01:15
>>365
フリーで凡妖気の仕事なんてあるんか?
本当はフリーじゃなくて一人偽装派遣でしょ。

367 :仕様書無しさん:03/12/24 02:05
>仕事上どっちが上とかは考えたこと無いけど、

だってさ、今の開発は汎用機系システムのWeb化が多いでしょ。
で、汎用機系のおっさんが、どっさっと上流工程に居るわけ。
あきらかに奴らは自分が上だと思ってるよ。
それをJavaで開発、そりゃ、デスマるよ。

368 :仕様書無しさん:03/12/25 00:04
>>367
>汎用機系のおっさんが、どっさっと上流工程に居るわけ。
おっさん等がメイクもやってるの?そりゃ人件費が大変だね。


369 :仕様書無しさん:03/12/25 00:57
>>364
3倍だと?
じゃあお前は月に8マソしか貰ってねーのかYO!

370 :仕様書無しさん:03/12/25 01:02
>>368
上流行程でmakeは行わないし、そもそも汎用機にmakeなどは無い。

371 :仕様書無しさん:03/12/25 01:19
>>369
まぁ、もちけつ

372 :368:03/12/25 01:21
>>370
釣られてみるが、
367のレスを読んだところ、おっさんが上流工程で設計して、
プログラミング工程でそのままメイクするのかと思っただけさ。
>>そもそも汎用機にmakeなどは無い。
そんなに突っ込まなくても意味は通じるでしょ?
汎用機のCompile/Linkの意味合いを込めてます。

373 :仕様書無しさん:03/12/25 01:35
>>368
やってますが何か?
人件費の心配も要りませんが何か?。・゚・(ノД`)・゚・。

374 :仕様書無しさん:03/12/25 01:40
>>373
なにもゆーことはないね。

375 :仕様書無しさん:03/12/25 01:50
上流工程でおっさんが汎用機系っぽい設計書つくって、
Javaプログラマに、ほれ、作れ。一日2画面だべ、
ってパターン。

プログラマは逃げるしかない。(派遣の場合)
か、過労死(会社員の場合)

376 :仕様書無しさん:03/12/25 02:01
汎用機おじさんは、いわゆる 「画面設計=データ構造」 ってやつですか?

377 :仕様書無しさん:03/12/25 02:08
>>376
ある意味正解。一画面分がひとかたまり。webアプリにおぢさんがなじむ?のは
作り方が同じだから。

378 :仕様書無しさん:03/12/25 18:50
>>353
多すぎれば「品質が悪いのでは?」
少なすぎても「テストの網羅性が低いのでは?」

プロマネ的には、プラットフォームに限らず、適正値を予測し検証する必要があるね。

379 :仕様書無しさん:03/12/25 19:59
>>358,368
まじれす。
・ADSGなどの局面化開発技法(フェージング)は、汎用機全盛時代に確立した
・OOでのGUIツールを使ったスパイラル開発は、フェーズの概念が無いと良く言われる
・でも大規模開発では、やはり多少のフェージングが無いと出戻りが頻発して自滅する

これは基本だよん

380 :仕様書無しさん:03/12/25 20:32
>多すぎれば「品質が悪いのでは?」

これは結合フェーズ以降ならあてはまるかもしれんが
単体テスト中にはあてはまらん。

381 :仕様書無しさん:03/12/25 22:40
>372
makeだなんていわずにビルドっていってりゃ余計な突っ込みも入らなかったのにな。
まあ汎用機のことを何も知らないんだろうけど・・・

ちなみに、USS とか Linux for zSeries なら make もあるだろ

382 :仕様書無しさん:03/12/25 22:43
>>380
普通のプログラマならコーディング中に単体テストも結構こなすでしょ
いわゆる単体テストのときまでそんなにバグを持ち越さないよ

383 :仕様書無しさん:03/12/25 22:48
>>361
それもF製

384 :仕様書無しさん:03/12/25 23:10
>>382
スケジュールきつい時や開発規模によっては机上デバッグするより
ガンガン動かしてバグ出した方が早い場合もある。


385 :仕様書無しさん:03/12/26 02:03
もまいら、テストファーストじゃないのか。

386 :仕様書無しさん:03/12/26 02:20
>>385
メインフレーム系の開発プロセスの改革/改善は、歴史が古いだけに一番遅れている。
web系が一番進んでいるような気がする。

387 :仕様書無しさん:03/12/26 11:12
>>384
確かに場合にもよるが、小さくてもちゃんと設計してから書けよ...

388 :仕様書無しさん:03/12/26 23:00
汎用機系にはブラックボックステストが理解できないらしい。
こりゃ〜こまったぞい。

389 :仕様書無しさん:03/12/26 23:04
web系でも汎用系でも金を取れる人が勝ち。
技術が進んでるだの、遅れてるだの言ってるのは単なるオナニー。

390 :仕様書無しさん:03/12/27 01:35
>>389
不景気な時代なので、それに加えて流動性も確保しておきたい。
金を取れるといっても倒産したらおしまいだよ。

UNISYSのように汎用機自体がなくなっちゃうかもしれないし、
COBOLだと市場自体が縮小傾向にあるから転職は厳しいよ。

391 :仕様書無しさん:03/12/27 01:58
>>390
ってか要件定義〜設計までで、プログラムは丸投げなんで、
実際に自分でCOBOLでプログラム組むことも殆どなくなった。
業務ノウハウがあればOK

392 :仕様書無しさん:03/12/27 02:15
上海に発注でもしまつか、
顛末をよく考えようや、

391の様な考えをもつのは、汎用機系40歳代の中核となってる
奴らだから始末におえない。

そもそも、業務ノウハウが必要という発想が痛い、
業務ノウハウは顧客から得るもんだ。とチャイニーズは言いまつ、

奴らは技術を日本の案件で習得している、次は、頭からの案件。
このストーリーがわからないのかな。

393 :仕様書無しさん:03/12/27 02:29
40、50代は後は老後の年金生活が待っているので
後先考えず、若手の育成はしないんだろう。


394 :仕様書無しさん:03/12/27 02:52
>>392
ん?日経雑誌の受け売りかい?
自分の頭で考えようね。

395 :仕様書無しさん:03/12/27 03:41
>>394
そいういやそんな記事あったなあ。

それはそうと日経コンぴゅう太面白いよ。記事が恣意的で。
「メインフレームは無くなる!」→「でもIのメインフレームはこんなにすごい」
笑える。まあ、あっちにもこっちにも振りたい提灯がぶら下がってるんだろうけど。

396 :仕様書無しさん:03/12/27 06:51
最近のニケーイピュー太はライターのレベルが下がりまくりだからなぁ・・・

397 :仕様書無しさん:03/12/27 06:57
>>395
まぁマッチポンプは出版業界の常。両論あれば後は各自で判断しろと。

煽り(賛美)だけの大半のPC雑誌は、もっと始末が悪い気もするけどね。

398 :仕様書無しさん:03/12/27 09:10
祝☆巨大掲示板2ちゃんねる『血祭り』記念!祭りだワッショ〜イ♪(w
-期間限定☆2ちゃんねら〜訪問会員様-

メリークリスマス♪(アニメヲタには関係ないイベントか・・・汗)

ヲマエラにくれてやる画像はありましぇ〜ん(ぷ〜♪)

っつ〜か年末なんやからHPなんか覗いてる暇があんなら大掃除でもしたら?(w

そいでわ良い年末を♪(^0^)

だってさ・・・
ttp://akuma666.fc2web.com/akumatop.htm

399 :年金生活目前爺:03/12/27 11:47
>>393
育ててもらおうなんて魂胆が間違ってんだよ
自ら学べ>脳なし若手

400 :仕様書無しさん:03/12/27 18:34
>>391
ようるすにお前は業務知識だけで食えると思ってるみたいだね。
業務知識なんて現場が一番知ってるんだから、お前はシステム知識と業務知識をつなげるのが仕事。
システム知識が古くて朽ち果ててるんだから、システム知識がないのと一緒。
残ったのは、現場の人より貧弱な業務知識のみ。

401 :391:03/12/27 19:22
>>400
想像力のない奴だな。
技術はあって当たり前だ。

402 :仕様書無しさん:03/12/27 21:14
>>401
Webシステム開発に関する、J2EE、OOD、固有なアプリケーションサーバーの深い知識
セキュリティの知識があれば使ってやるよ。もまいらの作った設計をすみやかに実装するために
チャイニーズを指導してください。おや!詳細設計などどと口走ってはいけませんよ。

403 :仕様書無しさん:03/12/27 21:22
使ってやるよ。。。。ぷ

404 :391:03/12/27 21:43
>>402
頭の悪さが滲み出ている。

405 :仕様書無しさん:03/12/27 21:44
>>401
今の時代、COBOLができることを技術とは言いません。
しいていえば、「伝統の技」くらいしか言えないね。
せいぜい、民芸品レベルのシステムでも作っておすごし下さいませ。


406 :仕様書無しさん:03/12/27 22:16
まぁ、おっさんコボラーを相手にしても仕方がないじゃないか!

実際にシステム開発するWeb系の技術屋は、その業務知識を
得て、次の仕事をすればよい。その時、必要なら、コボラーは必要ない
と断言すればいいだけだ。

407 :仕様書無しさん:03/12/27 22:25
>>406
 >システム開発するWeb系の技術屋
はいずれ
>>405
 >今の時代、COBOLができることを技術とは言いません。
COBOL と入れ換わるんだろうなー。シミジミ


408 :391:03/12/27 22:32
>>405
本当に考えの浅はかな奴だなあ。
COBOLだろうがJavaだろうが、プログラミングできることが技術とでも思ってんの?
いずれにしても、今後はITの現場作業は大学でてまでやる仕事でなくなることは断言しておく。

409 :391:03/12/27 22:34
>>406
あと、汎用系だろうがオープン系だろうが、
現場作業なら「やれば誰でもできる単純作業」に変わりないことをお忘れなく。

410 :仕様書無しさん:03/12/27 22:44
>>391
本当かなぁ
それって10年以上前から言われてただろ?

411 :仕様書無しさん:03/12/27 22:49
>408-409
MDAが早い所現場レベルまで落ちてきてくれるといいよね
人の仕事は「考える事」であるべき。

プログラミングも楽しいけど・・・

412 :仕様書無しさん:03/12/27 22:51
>>やれば誰でもできる単純作業
いかにも、業務知識マンセーのコボラらしいな。
それで、あなたのプロジェクトは成功しましたか?
あっ、丸投げでしたね。
そんなんで、飯が食えるあなたがうらやましいです。
まぁ、顧客も、元請もそろそろ気が付き始めましたけどね。

413 :仕様書無しさん:03/12/27 23:01
COBOLが残っているのでシステム移行の時にCOBOLのスパゲティを解読せにゃならんのが鬱
早く亡くなって欲しい

414 :仕様書無しさん:03/12/27 23:04
>>391
そういう歳だけとった上流行程が作る仕様は古臭くてやってらんない
もっと技術の移り変わりを見よ

415 :仕様書無しさん:03/12/27 23:04
つーかアプリケーションのプログラミングはこれからオフショアとか海外との競争がきついんで・・・
今の給料維持するには業務/上流に特化するか、OS/ミドルウェア/運用のプロになるかしないと・・・

プログラマでも、オープンソースのコミュニティでイニシアティヴ取れたり、
OSやミドルウェア開発、リアルタイムができるくらいなら喰っていけるんだろうけど、
漏れには無理だ。

416 :仕様書無しさん:03/12/27 23:17
>>413
そういうおじさん(50歳以上)働いていますね。
でも、30歳くらいのコボラと一緒になってやってる。
おじさんはおとなしいけど、若いコボラはキーボードを
たたく音がうるさいです。

仕事はWeb化の為、ホストでどんな入力チェックかをしらべて
Java開発のチームに渡すことなんですが。

417 :仕様書無しさん:03/12/27 23:30
日経なんとかから出てる本に
「COBOLは無くなっていく」と言われて久しい現在も
言語シェアの50%以上はCOBOLって書いてあったんですけど本当ですか?
たとえ10年後もこの経済情勢の中、世の企業が一気にCOBOL資産を
リプレースするとは考えにくく、COBOLが過半を占める状況に大きな変化はないとも書いてありました。

418 :仕様書無しさん:03/12/28 00:01
業務アプリケーションでなくても、数学関係のライブラリもまだまだFortranだったりするし。
概して過去のアセットはそう簡単には捨てられんもの


ホスト全面リプレース、J2EE移行でもすればPL/IやCOBOLとおさらばできる

419 :仕様書無しさん:03/12/28 00:29
COBOLerには技術を軽んじる輩が多い。
これは彼らが技術職ではないからである。

T型フォードを乗りこなして、
「車は動けばいいんだよ。実用本位だぜ」と言っているのがCOBOLer。

ただ問題なのは、一般人から見ると時速30kmで走る物体を自動車とは申しません。


420 :仕様書無しさん:03/12/28 00:38
COBOLがまずいんじゃなくて、一部のCOBOLプログラマがまずいんだ

421 :仕様書無しさん:03/12/28 01:30
>>420が、いい結論を出した

422 :仕様書無しさん:03/12/28 02:42
おい、おい、結論じゃねーだろ。
COBOLプログラマに罪はない、時流に乗れなっかった奴は消えるのみ。
10年以上前に消えたと思ったがな。
問題は生き残りが、Web系のシステム開発の「頭」になってることだ。
やれ、考え方が違う、などと言うものの決してJava言語を扱うに必要な
オブジェクト指向を理解しようともせず、10年以上も昔の手法をつかう。
結果は知ってのとおりだ。プロジェクト破綻の原因はもまいらだ!
要件定義->基本設計->詳細設計などとやるのは、もう通用しないんだよ。
しかも、Webアプリケーションなのに、頓珍漢な画面設計するし。
まだ、汎用機系の仕事はあるんだし、しゃしゃりでてくるなよ。

423 :仕様書無しさん:03/12/28 02:46
>>422
もう少し、詳しく教えてくれ。

>オブジェクト指向を理解しようともせず、10年以上も昔の手法をつかう。
>要件定義->基本設計->詳細設計などとやるのは、もう通用しないんだよ。
この辺


424 :仕様書無しさん:03/12/28 04:18
>>422
俺も聞きたい

425 :仕様書無しさん:03/12/28 05:31
>>422
Web+J2EE+分散オブジェクトの大規模開発であってもウォーターフォールでやって成功した例なんて腐るほどあるぞ。
それは明らかにお前とお前の会社のPMがクソなだけだよ。

開発手法はシステム要件(顧客の要求精度の煮詰まり具合)、納期、ワークロード、成果物(の精度)によって選択されるべきものだろ。
言語なんていうのは2の次3の次なんだよ。(ベンダー/SIerが「Java/J2EE」を売り物にするケースはあるが。)
COBOLだろうがVBだろうがCだろうが例えばアジャイルでやろうと思えばできるに決まってるじゃねーか。

さらに追加するなら今現在のJavaのオブジェクト指向技術がどこまで開発生産性に寄与するかなんて激しく未確定だろ。
まあお前が何の「オブジェクト」の話をしているかにもよるがな。>>423&>>424が聞きたいのもそこら辺だよ。
最低限こんな話を持ち出すなら「トランザクションの振舞いとClass設計」あたりから始めろよ。CMP Beanデザインまでとは言わんが。

ついでに「Webアプリケーションなのに頓珍漢な画面設計」ってなんだよ。それがどうJava/オブジェクト指向と絡むんだ?
お前のオブジェクト指向ってSession Objectか?単にJSP/Servlet&MVCモデリングの話をしてるだけ?
おめでてーな。まあ画面設計の実装なんて、特にお前にはお似合いだけどな。

426 :仕様書無しさん:03/12/28 06:44
>>425
で、おじさんはどうして、夜中仕事してたのかな。
適当な字面をならべなでいでさ、ひとつ、ひとつ勉強しようよ。

>>423
>>424
おじさんは設計を、画面ベースで顧客と話を進めるよね、
そうすると、設計書にはユーザインタフェースおよび、システムの処理が混在して記述される。
これをJavaで開発すると、開発者は画面ベースでしかプログラムをかけない。
昔のシステムなら、画面とプログラムはくっついていても何とかできた。
しかしWeb系で、おじさんの設計書でやり始めると処理があちこちにちらばり始める。
つまりプログラマは勝手に作っていく。できたシステムはもう手のつけようがない
ほど、魑魅魍魎の世界と化す。たとえば、バグをとっても、同じだけバグが発生するとか、
意図した通りに画面をつくれない、直せないとか。延々と終わらない。
実際のケースではバグが発生が収まらなく、作り直しを決定したことすらある。
おじさんの下ではたらくJavaプログラマは、わけも分からず、生気を失っていく。


427 :仕様書無しさん:03/12/28 07:42
君たちは現場を知らない素人ぞろいだね

428 :仕様書無しさん:03/12/28 08:51
>>427
設計を画面から始めるSEを実際に見たぞ。ビックリした。
発注先受注元ともに東証の上場会社だった。

429 :仕様書無しさん:03/12/28 10:18
>>426

いるいる。そういうダボじじい。

430 :仕様書無しさん:03/12/28 10:21
>>426
画面設計の入力欄の数=DBのテーブルのカラム数
っての見たことある。

なんでこのひといきてるのかな、と思った。

431 :仕様書無しさん:03/12/28 11:31
要するに、凡妖気だろうがWeb系だろうが、業務系はアホバカチンカスってことですね

432 :仕様書無しさん:03/12/28 13:05
うーん?なんか皆さん燃えてますね。

ここはマ版だから、すぐ「COBOLだから」とか「技術が判ってない」てな発言が出て、
提案や運用やプロマネの話題が出ると続かないのは、半分あきらめましょう :-)

・業務系COBOLerの大半からは、内部技術が見えないのは事実(汎用機の理想ではある)
・技術系の人は、技術優位で盲目になりがち(周囲の業務や運用が見えない)
・大規模開発では、UNIX & Webでもフェージングが成否を分けるのは事実
・ただ、汎用機文化を形式的にオープン系に適用して、無駄の塊になってる事も非常に多い
・基本設計・詳細設計って用語は、曖昧なので最近は使わない(せめて、外部と内部)
・画面ベースだけで話を進めるのはDOA以前(汎用機でもデータの流れ・格納の方が重要)
・画面は画面で重要(ユーザー要件が違うと後で地獄。中身の設計開発は分離して進めればいいでしょ)

433 :仕様書無しさん:03/12/28 13:28
>>432
開発モデル、データモデリング、MVC、ユースケース
ってくらいで間違い無い?

434 :仕様書無しさん:03/12/28 13:29
>>432のレスからも分かるとおり、一番投げやりに書かれているのが
>中身の設計開発は分離して進めればいいでしょ
の部分である。

この部分には言語やフレームワークに依存した比較的新しい技術が
必要なのだが、そのための設計を行わない(または行えない)
COBOLあがりの設計者は、実現しやすさを無視した仕様を決めるため
タチが悪い。

「自分がほとんど決めてやったのに、PGは何故ヒーヒー言っているのか?」

と疑問に思うならまだマシだが、「このくらい朝飯前でしょ」といった
感覚で実現を迫る者となると目も当てられない。

是即ちデスマーチの始まりである。

435 :仕様書無しさん:03/12/28 14:18
>>434
自分のプログラミング能力の低さを棚に上げて
文句ばかりの低脳プログラマにも困ったもんだよ

436 :仕様書無しさん:03/12/28 14:36
>>435 つまんね

437 :仕様書無しさん:03/12/28 15:56
COBOLネタつまんね。ここだけ番長。
匿名で他人を罵倒するような奴がリアルでも好かれてるとは思えんなあ。

438 :仕様書無しさん:03/12/28 16:00
>>435
だな。
散々技術を標榜しておいてそのザマかよって感じ。
COBOLerよりもずっと技術があるんじゃなかったのかよ。ほんと口だけだな。

439 :仕様書無しさん:03/12/28 16:05
>>434
サーバサイドのJavaフレームワークって乱立気味だけど、どの話をしてる?
何か使ったことある?

440 :434:03/12/28 16:25
>>435 いるね。こうやって「実現不可能な仕様」を自覚することを棚に上げて人を低脳呼ばわりする奴。
>>438 技術は万能では無いんだよ。
   一部の糞COBOLerが口走る世迷い事を実現できる技術なんてものはこの世に存在しない。
>>439
「Javaのなんたるかも理解していないCOBOLerSEの下で働くPGに、
 フレームワークの選択権なんてものがあると思っているのか?」
とでも言って欲しいのかね?
Strutsなら使ったことあるよ。もっとも、Struts使ったくらいで
COBOLerの妄想癖をどうにかできるなら愚痴りゃしないけどね。

441 :仕様書無しさん:03/12/28 16:27
以上悲惨なリーダーと悲惨な下っ端の悲哀ですた。

442 :仕様書無しさん:03/12/28 16:31
悲惨なリーダーにならないよう気をつけろよ。
>>1-1000

443 :仕様書無しさん:03/12/28 16:32
>>440
ということはあなたは低脳呼ばわりされている奴隷プログラマな訳ですね
上司も悲惨だなぁ

444 :仕様書無しさん:03/12/28 17:59
>>440
いずれにしても覚えりゃ誰でもできるような作業だろ。
フレームワークだのStrutsだのほざいているが、
結局は誰かが用意した「技術」という名の便利ツールを使わされているに過ぎないのさ。
オープン系が汎用系より優れてるとか、発想がお子様なんだよ。

445 :仕様書無しさん:03/12/28 18:27
2007年以降、ここの会話見てる限り大変かもしんない。
頑張れよ現役リーダー!

446 :仕様書無しさん:03/12/28 20:10
おいらは、PGにおっさんの作った概要設計、詳細設計を次の様に分析して、作業を進めるように言っている。
1.画面表示項目(画面の各イベントで対象となる画面項目を明確にします)
2.画面遷移(画面の各イベントに対する画面遷移を明確にする)
3.リソースアクセス(イベントにおけるリソースの利用を明確にします)
4.業務処理、業務クラス、業務クラスメソッド(イベントの業務処理を抽出し、業務クラスとメソッド処理名を設定します。すでに設定済みの処理はそれを再利用します。)
5.フレームワーク(画面遷移、データベースアクセス、業務クラスの範疇でない処理がないか明確にします)
目標は、MVCモデルを極限まで実現することです。最終的には、実装するクラスは、すべてが軽微になります。商用のフレームワークを採用するので、それを加味して作業は進行します。
おっさんには、業務クラスを設計するべきと言ってみましたが、拒否されました。よって、それはPGがおこないまつ。


447 :汎用系の人:03/12/28 21:02
MVCってなんだい?
最近流行ってんの?

448 :制御系:03/12/28 21:03
はぁ。業務システムって大変なんだねえ

449 :仕様書無しさん:03/12/28 22:40
たかが画面設計で大げさなことだねえ。

450 :仕様書無しさん:03/12/28 23:35
>>447
MVCとは?
M もういやんなっちゃう
V ヴァカ
C COBOLerの相手するのが

451 :仕様書無しさん:03/12/29 00:06
MVC・・・・
汎用機のアセンブラにそんな命令があったような・・・

452 :仕様書無しさん:03/12/29 00:19
>>451
MoVe Character

453 :仕様書無しさん:03/12/29 07:08
>>449
ずーっと画面設計でしかシステムを語れないヤシなのでしょうがないです。

454 :仕様書無しさん:03/12/29 21:33
JavaやれるならCobolもできるだろ、勉強すれば。
Lv・あわせて やれ

455 :仕様書無しさん:03/12/30 23:49
http://itpro.nikkeibp.co.jp/free/WAT/ITARTICLE/20031226/3/
2004年の1月と4月、自動車業界とビール業界のそれぞれで、ビッグネームのメーカーが
基幹業務をメインフレームからオープンシステムへ

456 :仕様書無しさん:03/12/31 03:11
>>455
それぞれの企業名をうp汁

457 :仕様書無しさん:03/12/31 10:32
富士通のソフト・サービス共通技術センター長があほぅと言う話ですな。

がんじがらめに手間のかかるCOBOLプログラムを作ったのはこいつらだ。
でも、こいつらが、Javaでやってもやっぱり手間のかかるプログラムができる
できるんだなこれが。

458 :仕様書無しさん:03/12/31 18:51
正月の保守作業ご苦労さんage

459 :仕様書無しさん:03/12/31 20:31
さて、今夜の夜間バッチはノートラブルで終わるかな

460 :仕様書無しさん:03/12/31 21:12
これからスーツを着てお客様のところに出かけます。
よいお年を!

461 :仕様書無しさん:03/12/31 21:56
俺もこれから、客先で立ち会い。

462 :仕様書無しさん:04/01/02 21:34
http://www.sentaku.co.jp/backnumber/not_member/html/S0305098.htm
平井卓也のほか松下忠洋や岩屋毅といったすっかりIT通となった
若手国会議員五人はそろって、社会保険庁にヒアリングに乗り込み、呆れ返った。
同庁はいきなり約二十人の職員をズラリと並ばせ、五人の議員がなにか質問する度に、
二十人の職員が質問内容を「伝言ゲーム」のように隣の職員に繰り返し、
二十番目がいいかげんな回答をする「牛歩戦術」に出た。
露骨な時間潰しに、議員たちは怒りをあらわにしたという。

社会保険庁の対応は、誰が見ても、愚か極まりない。
だが、どんなに愚かとあざ笑われたとしても、社会保険庁には、
NTTデータとの契約内容を白日の下にさらしたくない「特別の事情」があったのだ。

463 :462:04/01/02 21:37
【システム開発】中央省庁、「隠れ債務」清算へ 先送り開発費用一括払い【現状他社参入出来ず】
http://book.2ch.net/test/read.cgi/bizplus/1072959550/l50
↑こういう話はここの人に関係あるんですか?

464 :仕様書無しさん:04/01/03 15:15
月曜が楽しみ♪

465 :仕様書無しさん:04/01/03 16:03
>>464
なんで?

466 :仕様書無しさん:04/01/03 19:21
汎用機マンセーじじいの設計書でプログラム作るのが嫌になったので、
派遣PG3名、業務放棄しまつ。

467 :仕様書無しさん:04/01/03 23:07
>>464 おれも楽しみだw

468 :茶魔:04/01/04 00:42
ぽっくんも楽しみぶぁい!

469 :魔性ネロ:04/01/04 00:43
ワタシモタノシミデス

470 :仕様書無しさん:04/01/04 09:37
>>462
NTTデータの官公庁向け「利用料(という名の残債支払)」は業界で悪名高い。
これがあるから、公開入札はされないわ、ユーザーが拡張できないわ。

普通は請負契約(ベンダーに著作権)でも、支援契約(ユーザーに著作権)でも、
ユーザー側が常識的な使用権(自社で使うのに必要な改変など)は持っている。
ところがNTTデータのは、ユーザー改変禁止だから、長期の残債がある場合は、
途中のカスタマイズを含め、事実上永遠に支払わないといけなくなる。

ちょうと「高速道路料金(無料になると言われて、値上げばかり)」と同じ構造。

471 :仕様書無しさん:04/01/04 09:54
>>470
「NTTデータって商売巧いんだね」では済まない問題だな。
元が税金だからね。

472 :仕様書無しさん:04/01/04 14:22
構造改革してホスィよ
血税がつまらんことに使われてる

473 :仕様書無しさん:04/01/04 17:03
○○○しか動かない初日からこれか・・・
明日が怖い・・・とんずらしていいですか?

474 :仕様書無しさん:04/01/04 18:21
>>470
そういう話ってどういう本・雑誌で知れますか?
>>473
どう怖いのですか?

475 :仕様書無しさん:04/01/04 22:07
>465
ほら,あれだよ,あれ.

476 :仕様書無しさん:04/01/04 22:09
んもうっ、じらさないではっきり言ってちょ!

477 :仕様書無しさん:04/01/05 10:37
>>474
日経コンピュータで時々、官公庁の不明朗な「随意契約」が触れられてる。
http://itpro.nikkeibp.co.jp/NC/
でもWeb上では無料では参照できない

478 :仕様書無しさん:04/01/06 14:12
アイワイバンク銀行(IYバンク)が勘定系システムの全面オープン化に
踏み切ることが分かった。日立製作所のメインフレームから、日本ユニシスの
大型IAサーバーES7000に乗り換える可能性が高い。OSにはWindowsを採用。
稼働時期は2005年秋の見込みだ。日立は同行の主要株主である。

****
百五銀行(ユニシス、IAサーバー、Win)に次ぐ動きですかね

479 :仕様書無しさん:04/01/06 20:01
日立よか窓の方がましか・・・


                          そりゃそうだよな( ・∀・)

480 :仕様書無しさん:04/01/06 22:18
>>478-479
IYバンクは銀行業務全体からみると単純な業務ばかり。
百五銀行はフルバンキング。

同じ土俵で比べるようなシステムではありません。
百五銀行の方が遙かに複雑でレガシー。

481 :仕様書無しさん:04/01/06 22:45
特化して業務フローを単純化すればシステム投資も少なくて済むという事か
銀行さんは人もシステムも太りすぎ。もっとダイエットしろ

482 :仕様書無しさん:04/01/06 23:48
>>481
ちがう。
IYバンクは普通預金とそれに伴う口座引落、内国為替の一部だけ。
これだけで銀行業務を語ることは不可能。
というか、銀行であって銀行ではなく、ただの決済屋さん。

百五銀行は、IYバンクの業務に加えて
当座預金、(別段預金)、通知預金、貯蓄預金、納税準備預金、定期預金、積立定期預金、財形貯蓄などの預金業務と、
手形貸付、証書貸付、手形割引、代理貸付業務などがある。
貸付業務には多彩な商品があり、数え切れないほどの種類がある。
当座預金には手形や小切手の発行、交換、決済業務がある。
生命保険、損害保険、国債、投資信託もある。
外国為替に関してはその業務だけでそこらへんの大企業のシステムよりも規模がでかい。
それぞれにかなりの規模のシステムが要求されて、全てが一つの勘定として矛盾なく動かなくてはならない。

プログラムの量も数十倍から百倍以上の開きがあるはずです。
システム規模も百五銀行とは桁違い。資金量も桁違い。

携帯電話のテトリスと、プレステ2のファイナルファンタジーとを比較するようなものです。

483 :仕様書無しさん:04/01/07 00:07
>482
結局、ミニゲームのほうが面白いって事?

484 :仕様書無しさん:04/01/07 00:08
社会保険庁の年金給付システムとはどのようなものでしょうか?
銀行と似たようなものですか?

485 :仕様書無しさん:04/01/07 00:14
>>483
おもしろさは百五の方がおもしろそう。
でも俺は入院したくない。胃も痛めたくない。
失敗して新聞にも出たくない。

だからどちらかの仕事をしろといわれれば、迷わずIYバンクの方を選ぶね。


486 :仕様書無しさん:04/01/07 00:21
210.199.112.22
↑こういうのをIPっていうんですか?

487 :仕様書無しさん:04/01/07 00:24
いいません。そういうのは10進数をピリオドで区切った並びって言います。

488 :仕様書無しさん:04/01/07 00:27
>>482
481の話が通じてなさそうな答えだね

>>485
IYバンクって24時間営業だぜ〜
単価も普通の銀行より安いんじゃないか?母体の社員の給与を考えてみ

489 :仕様書無しさん:04/01/07 00:36
>>487
ごめんなさい。良くわかんないです。
っていうか空気呼んでなくてすいません


490 :仕様書無しさん:04/01/07 01:23
口立
曰立
日立
目立
貝立
見立


491 :仕様書無しさん:04/01/07 01:24
メインフレームである必要はないと言うことだな。
どうする、メインフレームマンセー。

492 :仕様書無しさん:04/01/07 15:03
メインフレーマーがちょっとオープン系の仕事を手伝うと
「新技術で案件をこなした」って評価されるのに、
俺らオープン系がメインフレームの仕事を手伝って
デスマってもなーんも評価なし・・・・ふざけんんなああああ!

メインフレームの方が書籍が全然なくて、よっぽど「新技術」だ



493 :仕様書無しさん:04/01/07 15:28
>>492
仕方ないよ。出版社も営利事業だから。メインフレームの書籍出したって売れないもの。

494 :仕様書無しさん:04/01/07 16:14
>>493
論点がずれてるぞ

495 :仕様書無しさん:04/01/07 23:15
メインフレームの技術は門外不出・一子相伝の技術です。
書籍なんかは出せません。

496 :仕様書無しさん:04/01/07 23:21
   ,.´ / Vヽヽ
    ! i iノノリ)) 〉
    i l l.´ヮ`ノリ <>>1先生!こんなのがありました!
    l く/_只ヽ    
  | ̄ ̄ ̄ ̄ ̄|
http://my.post-pe.to/w1000yen/?id=MVS_urajijou

497 :仕様書無しさん:04/01/08 00:15
>>493
オーム出版から出てるじゃん。
入門COBOLとか入門アセンブラとか。

498 :仕様書無しさん:04/01/08 00:17
メインフレームの技術情報は、メーカーから昔は紙で、今はWebから、
製品別・機能別・バージョン別に細かく得られるから、
一般化して書かざるを得ない書籍という形態は、あんまり役に立たない。

発電所やタンカーの一般書籍が少ないのと同じ。

499 :仕様書無しさん:04/01/08 00:27
>>488
銀行は装置産業だが、機能を絞れば手軽なサーバーでもできるというのは正解。
新規参入で決済特化とかリテールのみとかは、今後も増えていくだろう。

ただ、既存の「総合銀行」が簡単にダイエットできる訳ではない。
新規販売をやめても既存の商品・顧客・業務は残るし簡単に転売できない。
仮にできても組み上げたシステムから「抜く」のは却って手間もリスクも高い。

既存の銀行でメインフレームが今も大多数なのは、センターカット(オンバッチ)、
大量帳票、口座残高の全国リアルタイム更新など、業務にあわせた処理に向いてるから。

24H稼動自体は、たいした技術じゃない。フロントエンドでも吸収できるし。

500 :仕様書無しさん:04/01/08 00:54
>>499
24H稼働はたいした技術だよ。
特定の技術だけではない、総合力という名の技術だよ。

止まっても地方新聞にすら掲載されないシステムと、
1時間停止すると全国紙夕刊の一面に掲載されて6時のニュースでも報道されるシステムとでは、
使う技術も資金も装置も本質的に全く違う。

501 :仕様書無しさん:04/01/08 01:03
>>499
既存の銀行がメインフレームが今も大多数なのは、
昔はメインフレームしかなかったからメインフレームで作った。
そんでもって、オープン系に移行するのが恐ろしいから。
CIOは任期満了までトラブルがなければそれでよいと思っている。
「信頼性・可用性」という魔法の言葉が、膨大な予算を正当化しています。

性能的にメインフレームでなければ実現できないシステムなんて存在しません。
DBにしても、RDBを使わなければオープン系でも早いし、
プリンタだってメインフレーム用のプリンタをUNIXで使える。
ディスクだって今じゃメインフレームでも部品レベルでは同じ物使ってる。

メインフレームの連中はチャネルチャネルと連呼するが、
SGIのクロスバースイッチの方が遙かに速いでしょ。

マシンの論理分割だと言っても、遅いマシンを3分割するよりも、
速いUNIX機を6台買った方が安くて超速い。

502 :仕様書無しさん:04/01/08 01:04
>>498
それもそうなんだけど、何か技術コミュニティみたいなものがあってもいい思ったりする。
せめてIぐらいは・・・

503 :仕様書無しさん:04/01/08 01:18
>>501
>オープン系に移行するのが恐ろしい
これは違うと思う。
「絶対安全レベル」を保証するために必要なテストにかかる費用は
オープン系よりもメインフレームの方が安くつく。ハードウェアやOS
のメーカーもテストに協力してくれるし、、、。

504 :503:04/01/08 01:21
「絶対安全レベル」を契約書で保証してくれないものを買える訳ないでしょ。

505 :仕様書無しさん:04/01/08 01:41
>>499
24時間は技術って意味で言ったんじゃないよ
世間にさらされてるシステムに24時間体制で
こっちが付き合わなきゃならんのがつらいってことを
言いたかっただけさ。
そんなことを実現してるのは>>500がいうとおりすごい技術なんじゃない?

それから既存のシステムから「抜く」なんてどこにも出てないじゃん
リプレースするときの話だろ
それにダイエットの話だってダイエットすべきような銀行の話だろ。
やらないほうがいいような業務を無理にやって赤字出して国有化なんて
馬鹿馬鹿しい。だったら


506 :仕様書無しさん:04/01/08 01:57
>>484

507 :仕様書無しさん:04/01/08 12:07
>>504
そんなん、IBMの標準契約書でも保証してませんが。
アウトソーシングでのサービスレベルは個別の契約の話だし。

508 :なぎさっち ◆Nagi/FmYMM :04/01/08 13:43
>502
メーカー主催のユーザー会(ファミリ会)、は毛色が違うかな....?

509 :仕様書無しさん:04/01/08 21:01
>>502
こんなのはどうじゃ? IBMメインフレームのリンクが盛りだくさん
http://www.cbttape.org/links.phtml

その中でも、これなんか最高! (System/370, ESA/390, z/Architecture Emulator)
http://www.conmicro.cx/hercules/

510 :仕様書無しさん:04/01/08 22:02
コンピュータで飯食ってる奴の口から「絶対」なんて言葉が出るとはね・・・
素人じゃないんだからさぁ

511 :仕様書無しさん:04/01/08 22:19
OK。これで絶対安全だぜ。
          ∧_∧
    ∧_∧  (´<_`  )  流石だよな、俺ら。
   ( ´_ゝ`) /   ⌒i
   /   \     | |
  /    / ̄ ̄ ̄ ̄/ |
__(__ニつ/  FMV  / .| .|____
    \/____/ (u ⊃


512 :仕様書無しさん:04/01/08 23:22
>509
既出だったりする

513 :仕様書無しさん:04/01/09 00:45
「絶対、間に合わせます」なんてよく言ってないか?

514 :仕様書無しさん:04/01/10 02:45
>>510
おいらも最近、言わなくなったよ。
とりあえず、「やってみないとわからん!」と言うことにしてる。

515 :仕様書無しさん:04/01/10 10:12
>513
営業だけのセリフとなる・・・

516 :仕様書無しさん:04/01/10 12:19
で、>503は素人、でFA

517 :仕様書無しさん:04/01/10 14:25
>>516
FA!!

518 :仕様書無しさん:04/01/10 17:24
>>500,505
いや、私も銀行24H対応は少し関わってたから、技術面でも運用面でも大変なのはわかる。

特に既存の「総合銀行」の運用(つまり、オン中に多数のセンターカットが走り、
その先行関係も複雑で、DB再編・バックアップや保守変更の時間も確保が必要)で、
24H化するのは大変だ。

ただ、海外の銀行のように非常に割り切れば(全国レベルのリアルタイム残高合わせを
しない、残高は月次バッチで郵送、ATMはほとんど無い、各地域の上限値まで引き落とし、
ユーザー向けには安いフロントエンドで対応)なら、24H化は簡単だと思うね。

ただ、既存の邦銀が、いくらシステム再構築時でも、そこまで革命的な業務変更を、
顧客や行内に行えるとは到底思えない。(本当は色々な銀行があるべきだけど)




519 :仕様書無しさん:04/01/10 17:24
厨房サイト入れ食いウマー(・∀・)
http://www.geocities.jp/lll_the_legend_of_zelda_lll/

520 :仕様書無しさん:04/01/10 17:41
>>501
典型的なオープン派の主張だけど、世の中はそう単純ではないよ。

現在、日本の全銀行の勘定系でオープン系採用は1〜2%(数行)と思われる。
今後5%、20%と増えていく事は間違いない。
大手行は既に、数百〜数千のUNIX/IAサーバーを併用してる(対外接続、
CRM、ALM、営業店サーバー、行内イントラネット、外向けWebなどなど)。
ベンダー(F,N,I,H,U)も、なんらかオープン系を取り込んでいる。

ただ、小規模行はともかく、大手行の勘定系をオープン系に置き換えるのは、
技術面でもまだ困難。

例えば多くの銀行ではATMのタイムアウトは1分前後で、超えると顧客や店舗に
迷惑がかかるから、1分以内(つまり通常は30秒以内)に、障害検知・判断・引継ぎを
する必要がある。汎用機(IBM XRFとか)は、OSのワークロード割振が徹底してるから、
障害発生が10秒程度で判断できるが、UNIX/Win系は負荷が高いと全体のレスポンス
が遅くなる(応答時間の保障が低い)ため、誤引継防止を考えると判断に2分はかかる。

検知・判断後の引継ぎ(DBプロセス、DB DISK)も、XRFはほぼ瞬時(10秒程度)で、
ATMから見るとネットワーク切断は無い。UNIX/Win系の大半のクラスタリングは、
引継に(起動DBが大きいほど)数分かかり、ネットワーク切断や相互のリトライも
走り回る。

サーバー本体価格はオープン系は安いが、ワークロード分離でサーバーが増えて、
合計の運用コストが増えがち。

これらを乗り越えるには、やはり欧米の銀行のように、最初から全国レベルの
残高一元管理を回避するしかないが、そこまで割り切れるかどうか。

521 :仕様書無しさん:04/01/10 21:21
>>520
欧米の銀行はどういった残高管理をしているの?
分散でつか?

522 :仕様書無しさん:04/01/10 21:47
で、技術的に困難だからといってやらないと、いつまでもできない訳だ。
MVSもIMSも、最初からこのレベルの信頼性を備えていた訳ではないし、
導入して試行錯誤してレベルアップしていった。
新しいものへのシフトの際は、しばらくダウングレードが起こるのはしかたない。
そのリスクを負ったものが次世代の覇者となる。
という訳で、誰かやってくれよ。
早くしないと、XRFの前提である37x5がこの世から消え去るぞ。あと何年だったかな。


ところで、UNIXでも1分程度の引継は可能。チューニングが必要だが。

523 :仕様書無しさん:04/01/10 23:19
>で、技術的に困難だからといってやらないと、いつまでもできない訳だ。

まあ、やりたがってるかどうか疑問なわけだが。
費用対効果、信頼性両方で勝つのは結構難しい。
寝た子を起こすなという表現もあるし。
現状は客がバカばっかだから、費用も負担してくれてるし(w

524 :仕様書無しさん:04/01/10 23:41
やりたくないからといってやらないでいると、3745がなくなっちゃうわけで。

525 :仕様書無しさん:04/01/11 11:52
>>521
既出だけど、まず通帳は無い。残高は月次郵送。ATMはほとんど無い。
ある地域での引き落としは、他地域ではリアルタイムには伝わらない。
そこで地域単位で引き落とし限度額を設ける。(つうかローカル銀行が大半)

だから地域単位のサーバーとか、24H対応の専用のフロントエンドで足りてしまう。

526 :仕様書無しさん:04/01/11 11:58
>>522

やらないじゃなくて、段階的に進みつつある訳だ。
>>520 も、小さい銀行や、大手行でも周辺から進んでいて、
各ベンダーも進めていると、最初から書いてるでしょ。

UNIXクラスタリングで1分程度の引継ぎは確かにできるが、
引継ぎ開始前の検知・判断に同程度かかるし、
1分程度というのはメモリ上に巨大テーブルを展開する場合は苦しいし、
ネットワークが切れてATMに障害が見えてしまうし...

要は「できる・できない」の話じゃなくて、
メリデメを把握して、どこまで容認するか(割り切るか)の話」だと思う。

527 :仕様書無しさん:04/01/11 12:12
勘定系の動向は >>267

528 :仕様書無しさん:04/01/12 12:17
BTMのATMやってしまったのか

529 :仕様書無しさん:04/01/12 12:27
見出しだけ見て「またFか・・・」と思ってしまった。ごめそ。

530 :仕様書無しさん:04/01/12 12:38
そうみたい。どっかに細かいこと出てないかな。

ttp://www.nikkei.co.jp/news/shakai/20040112AT1G1101R11012004.html
ttp://www.asahi.com/business/update/0111/009.html
ttp://www.yomiuri.co.jp/national/news/20040112i301.htm
ttp://www.mainichi.co.jp/news/flash/keizai/20040112k0000m020118001c.html


531 :仕様書無しさん:04/01/14 00:54
http://www.ibm.com/news/jp/2004/01/01121.html
統合ATM接続における障害のお詫びについて

障害の原因は、当該金融機関の「対外系システム」と金融機関同士の
システムを結合する「統合ATMセンター」を接続する当社の対外接続
システムよるもので、弊社ソフトウェア製品に一部不具合が発生した
ことによるものです。

532 :仕様書無しさん:04/01/14 00:55
>>531
IBMの対外接続ソフトって、全銀用のFINEACEとか?

533 :仕様書無しさん:04/01/14 10:53
Fでなくてよかった。

534 :仕様書無しさん:04/01/15 21:31
メインフレームってRedBook扱いなのか。。。
http://www-6.ibm.com/jp/support/redbooks/#as400

535 :main:04/01/15 22:05
最近古PCにLINUXいれることを考えてる。

536 :仕様書無しさん:04/01/16 01:38
>>532
6000のほうね。

537 :仕様書無しさん:04/01/17 20:32
>>535 いっぱい、入れれ
漏れはすぐリプレイスするPCサーバ引き取ってlinuxいれて隠れ部門サーバ立ててる
PCはすぐ買い換えてもらえていいよなー、値段違うからしゃぁないけど

538 :仕様書無しさん:04/01/17 21:42
>>534
AS/400はMainframeじゃないよ。日本で言う「オフコン」。
マスコミによっては含めて呼んでいるところもあるが。

539 :仕様書無しさん:04/01/17 21:45
http://www.yomiuri.co.jp/national/news/20040117ic21.htm
千葉銀行(千葉市中央区、早川恒雄頭取)で17日、
本店のコンピューターシステムがダウンし現金自動預け払い機(ATM)
や現金自動支払機(CD)などが、約4時間にわたって使用不能になった。

-------------------------------
ダウンしたのは勘定系本体(汎用機)か? 途中のアプリサーバー等か?


540 :仕様書無しさん:04/01/17 21:47
>>536
この件は影響が大きかったのに日経コンピュータは速報で触れてない。
例によって、特集か「動かないコンピュータ」にするのかな。

541 :仕様書無しさん:04/01/18 00:31
>>539
よくやるね、ばかみたいね

542 :仕様書無しさん:04/01/23 21:47
要るヤシ居る?
ttp://page2.auctions.yahoo.co.jp/jp/auction/b47435094

543 :仕様書無しさん:04/01/24 21:26
>>540
日本IBMと日経はお互いにお得意様だからね

544 :仕様書無しさん:04/01/24 22:14
千葉銀行の勧業系システムってチェリーベイブが開発したらしい

545 :仕様書無しさん:04/01/26 21:42
今日のりそなATMのトラブルの原因ってなに?

546 :仕様書無しさん:04/01/27 09:23
>>544
チバレーだから?

547 :仕様書無しさん:04/01/27 09:53
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040126/138742/index.shtml
日本全国でATMトラブルが同時発生、NTTデータが開発した「統合ATM」に不具合

統合ATMの開発を手掛けたNTTデータは1月26日午後6時30分現在、「原因は調査中でまだ分からない」としている。

548 :仕様書無しさん:04/01/27 10:41
>>547
http://www.yomiuri.co.jp/main/news/20040127i403.htm
NTTデータは27日、原因は「取引情報の流れを制御するプログラムの不具合」だったと発表

549 :仕様書無しさん:04/01/27 15:29
よくまぁ問題を起こすなぁ、どんなやつがやってるんだぁ。

550 :仕様書無しさん:04/01/27 17:53
NTTデータの発表では発生箇所(サーバー?OS?アプリ共通処理?)が全然わからんなぁ。
http://www.nttdata.co.jp/release/2004/012700.html

551 :仕様書無しさん:04/01/27 21:41
俺は今日、金融機関向けの資料を読んだ。
内容を教えてあげたいのはやまやまだが、教えてあげない。

552 :仕様書無しさん:04/01/28 00:52
この問題に関わったひとは全員退職するんでしょう?

553 :仕様書無しさん:04/01/28 00:53
google でたまたまメインフレーマーの人のページが引っかかったんだけど、
なかなか仕事は大変みたいね。

うっかりこの世界にどっぷりはまってしまうと、中年以降のキャリアがかなりあやういみたいで。
日記読んでて、かわいそうになったよ。

554 :仕様書無しさん:04/01/28 01:47
>>553
どこ?
だめならキーワードだけでも

555 :仕様書無しさん:04/01/28 23:21
おいらの側にいるメインフレーマはまったりしてるが。

556 :仕様書無しさん:04/01/29 01:27
>>554
いえるわけないでしょ。


557 :仕様書無しさん:04/01/29 01:52
あるサイトでコボル難民なる記事を見ました。
2000年問題対応後、中年コボラーが大量に失業したらしいですが、
その時は学生だったので、その時の状況が良く分かりません。
失業したコボラーの大半は中小ITの派遣社員だったそうです。
現在彼らはどうしているのでしょうか?
私は去年入社し汎用機の仕事場に配属されたのですが、
仕事がなくなるというような危機感は全く感じられません。
リアルタイムで新規プログラムもコボルで作成しています。

それでも自己啓発を怠らないなどの警戒は必要なんでしょうか?

558 :仕様書無しさん:04/01/29 11:27
そんなこと心配しなくても君らも解雇されるから。かわいそうにね。

559 :仕様書無しさん:04/01/29 13:11
そうだよ
新入社員でもすむような仕事しかないのなら
新入社員でやったほうが安上がりだからね

560 :仕様書無しさん:04/01/29 23:16
>>329
亀レススマソ。
うちに、そこが作った仕様書が残ってまつ。どうしようもない糞な仕様書だけどさ。


561 :仕様書無しさん:04/01/30 00:35
またまた、凡妖気の火が消えます。

http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040122/1/
IYバンク、勘定系をWindowsで全面刷新へ
2001年5月の開業以来、3台の日立製メインフレーム「MP5600」を使って勘定系システムを動かしてきた


562 :仕様書無しさん:04/01/30 00:47
>>561
IYバンク程度だからこそできるんじゃない?
大きな銀行が全部を移植するのは何十年かかりそうだから。

563 :仕様書無しさん:04/01/30 00:53
>>562
そう思っていつまでもしがみついてると食べていけなくなるぞ

564 :557:04/01/30 01:58
>>558
職場には自分より20歳以上も年上の派遣コボラーおじさんもいます。
業務にも技術にも他者よりずばぬけて優れている訳でもなく、
「こんなのでもやってけんの?」と思ってしまいます。
ただ、周りの多くの人と親しいです。
あと自分のところの場合、プログラミングよりも業務関係の事務的作業
の方がずっと多いです。

565 :仕様書無しさん:04/01/30 21:35
>>561
窓機は怖い

566 :仕様書無しさん:04/01/30 21:50
>>562
大銀行は移行しないだろ。
Windowsなんか入れてトラブったら言い訳ができん。

567 :仕様書無しさん:04/01/31 14:31
>>566
そう思っていつまでもしがみついてると食べていけなくなるぞ

568 :仕様書無しさん:04/02/01 16:42
プロならどんなプロジェクトだって乗り切れ・・・
どう考えたってプロじゃなくて神だよなぁ・・・

569 :仕様書無しさん:04/02/02 12:25
一部の人はがんばってシステム構築に携わっているが、ごくまれにDQNがいるから
問題ばかりおきるんやね。もうこの業界は不景気も重なりかなり腐りきっているな。


570 :仕様書無しさん:04/02/02 19:23
1bitに精魂込めてコーデング。

571 :PL/Iのマ:04/02/02 21:20
俺もう決めた、やっぱ転職するよ。
って雇ってもらうトコがあったらね…

ちょうど契約更新の時期だけど、営業には内緒だね

572 :仕様書無しさん:04/02/03 00:01
bit毎にフラグの意味を持たすPGMに男を感じる

573 :仕様書無しさん:04/02/03 00:56
>>572
PL/Iを使ってた頃はフラグはbitを使うルールの職場がありました。
男ばかりの職場でした。

574 :仕様書無しさん:04/02/03 22:52
1バイトで8つ以内の状態を表すのにフラグを使っていると
殴り殺したくなる。マスクにして256の状態まで拡張可能に汁








575 :仕様書無しさん:04/02/04 03:32
>>569
>>567みたいなDQNだろ?w

576 :仕様書無しさん:04/02/09 22:45
静かだ・・・
平穏とは最大の幸福よ

577 :仕様書無しさん:04/02/10 01:21
年度末。嵐の前の静けさかな。
金融庁の検査が気になるところだ。

578 :仕様書無しさん:04/02/10 05:03
JavaPGって共通関数作らないらしいな。

579 :仕様書無しさん:04/02/10 08:32
Javaには関数なんてないからな。

580 :仕様書無しさん:04/02/10 23:52
だからよ、共通クラスとやらと作れや!ゴラァ。

581 :仕様書無しさん:04/02/11 00:35
クラスライブラリくらい誰でも作るだろ。
JavaでもC++でもSmalltalkでも

582 :仕様書無しさん:04/02/11 00:52
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040209/139547/
富士通がオープン勘定系、「みずほ」

583 :仕様書無しさん:04/02/11 01:36
あらあら

584 :仕様書無しさん:04/02/11 18:50
>>582
Nのオープン系勘定系(BankingWeb21)、Iのcore bank(J2EE)に遅れ、Fもやっと。

問題は、元となるPROBANK自体の汎用性(東邦専用と化したという噂)と、
いくら部品化したからって、汎用機上で構築したPROBANKをオープン上に、
本当にそのまま移植できるか(大幅な書き直しになる?)ってとこね。

585 :仕様書無しさん:04/02/11 19:31
他の人の確定申告書が流出、国税庁ホームページに欠陥
これはどこがやったのぉ

586 :仕様書無しさん:04/02/11 22:12
自家製という噂が

587 :仕様書無しさん:04/02/12 22:22
http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040204/1/
東証が基幹系を「オープン化」
2010年にメインフレームを完全撤去


588 :仕様書無しさん:04/02/12 23:01
>587
未練

589 :仕様書無しさん:04/02/13 01:53
へい、へい、コボラーもJ2EEやってますよぉー、
今週も、JAVAオタクがなにやらわけのわからん事言って
辞めていきましたなぁ、ということでうちではクラス図無し
ということに決まりましたがな。

590 :仕様書無しさん:04/02/14 00:46
新聞はメインフレームコンピューターと同じ運命を辿るのか(毎日)
ttp://www.mainichi.co.jp/digital/coverstory/archive/200402/10/1.html


591 :仕様書無しさん:04/02/14 10:23
>>590
たしかに・・新聞は、もういらないと思うよ
偏った新聞ばかり読んでいるより、ネットで色々な情報を見てた方が
はるかにプラス!!

592 :仕様書無しさん:04/02/14 13:45
いや、だからなんでそこでメインフレームを引き合いにだすのかと…。

それに新聞ってなくならないよ。






ネットのニュースなんか、弁当つつめないしトイレットペーパーとも交換できないじゃん

593 :仕様書無しさん:04/02/14 15:40
新聞は最低3誌は見ないと記事の誤りに気が付かない
紙が勿体無い
半日以上遅れの情報なんてイラン
勧誘ウザイ
っていうか1件1件人で配るなんて人件費が勿体無い
ASA、ノーヘルで爆走すんじゃねー
聖教○聞、偏った記事書くんじゃねー
朝日○聞、誤解を招くよーな表現使うな
読売○聞、なべ常、逝ってヨシ
日○本工業新聞、高い
日経、記事の室が落ちた
参詣晦日・… ウ〜〜〜〜〜ワンがるるぅ

594 :仕様書無しさん:04/02/14 19:31
メインフレームを、独自H/W、独自OS、独自プロトコル、COBOL中心の世界と見れば、
無くならないにしても減る一方なのは自明。

でも、それでいいんだよ。
元々、汎用サーバー(今ならIAやUNIX)でできる処理は、汎用サーバーですべき。
汎用機ならではの利点が無いシステムには、汎用機を選ぶべきじゃない。

ただ、WebとかLinuxとか、いわゆるNew Workloadのサーバー集中用途を含めれば、
減るかどうなるかはわかんないけど。最近、身近でもかなり聞こえて来たからなぁ。

595 :仕様書無しさん:04/02/14 20:35
適材適所

596 :仕様書無しさん:04/02/14 20:56
>>594
超同意。

597 :仕様書無しさん:04/02/14 21:15
>>594
どんな方向に行ってもメーカーには振り回されそうだけどな〜

598 :仕様書無しさん:04/02/14 21:41
日経BPでコボルの特集をやった本があったのですが、
まだ世の中の大部分がコボルを使ったシステムというようなことが書かれていました。
実際どうなんですか?
求人はオープン系ばかりだけど、IT系職種の人口は汎用系が圧倒的だったりするんですか?

599 :仕様書無しさん:04/02/14 23:43
その本は、COBOLな人が自らの置かれた状況に目を背け、安心するための書籍です。
みんな安心したいから、お守りと同じ感覚で購入するのです。

さらにCOBOLなコンサルタントに依頼することは、神社でおはらいを受けることに相当します。
自動車でも立証されていますが、おはらいには何の効果もありません。

600 :仕様書無しさん:04/02/14 23:53
汎用機をクラッキングする漢が現れると状況も一変するのだろうが。
セキュリティー面を考えると汎用機使ってる方が楽。

601 :仕様書無しさん:04/02/15 00:19
最近はIPで繋がっていることも多いから、FirewallやIDSを乗り超えることが出来ればやられるかもね。
汎用機の運用は、人的なセキュリティーは完璧なところが多いが、
ネットワークセキュリティー的にはかなり脆弱です。

なにせ汎用機の管理者は、スプーフィング、Dos、バッファオーバーフローの概念がない。
せめてもの救いは、攻撃しそうな輩はテストするための環境を持っていないということだけ。

602 :仕様書無しさん:04/02/15 00:22
>テストするための環境を持っていない
ある意味最強!

603 :仕様書無しさん:04/02/15 00:55
>テストするための環境を持っていない
hercules

604 :仕様書無しさん:04/02/15 02:02

それってMVSだよな。
いまどきMVSでテストしたからって通用するのかね?
ベースは変わってないとは思うけど。

605 :仕様書無しさん:04/02/15 16:13
>604
z/OSまで動きますが何か?

606 :仕様書無しさん:04/02/15 16:46
z/OSのランセンスってどうなるの?

607 :仕様書無しさん:04/02/15 21:26
まだCOBOL85に混じって、COBOL、ASMが動いていますが何か?
(クレジット業界だけどね)

608 :仕様書無しさん:04/02/15 22:28
新規プログラムはまだまだCOBOL85で作ってるよ。
こちらは某省庁関係ですけど。

609 :仕様書無しさん:04/02/15 23:44
うちなんて、自作言語をCOBOL85に変換するコンパイラ使ってるよ。
同じく省庁関係です。

610 :仕様書無しさん:04/02/15 23:56
うちは、汎用機メーカ独自の言語を使っています。
そのコンパイラはCOBOL85のソースを吐き出して、それをCOBOLのコンパイラに突っ込みます。
こないだまで省庁だったけど、最近そうではなくなった金融関係です。

611 :仕様書無しさん:04/02/16 00:18
メインフレームが雇用を守るのです

612 :仕様書無しさん:04/02/16 01:42
みんなLE使ってルー?

613 :仕様書無しさん:04/02/16 17:55
最近うちの会社でも汎用機の受注は殆ど無いみたいですね。
COBOLの発注はまだまだありますけどね。

614 :仕様書無しさん:04/02/17 02:07
>>612
使ってません。

615 :仕様書無しさん:04/02/17 20:50
>>612
某銀行は使ってる。他行も多いみたい。

616 :仕様書無しさん:04/02/17 21:03
>>601
ちょっと違うと思うよ。

汎用機もIP、Web、UNIX互換環境(USS)が進んだから、セキュリティ対策の中身も共通化した事は事実。

ただ、IPネットワークの先からUSSまで侵入できても、更にOS本体(MVSとか)の制御がとれるかは別問題。
汎用機本来の独自OS部分の(H/Wでのアドレス間管理を含めた)セキュリティの壁がある。
USS上のWebを壊したりはできちゃうし、Linuxをネイティブ起動してたら勿論別だけど。

あと、ハッキング側に汎用機ユーザーが少ないってのは、世間に多い誤解だと思うよ。
学生や趣味プログラマはともかく、セキュリティ侵害の大半は実は業界関係者だし、
汎用機上のデータは世界中で預金や軍事機密が集中してるから、テロ支援国家やライバル会社や暴力団を含め、
50億円かけても突破できれば、即元が取れる。

学生がWebを改竄して世間を騒がせたり、オンラインショッピング詐欺するのとは、
直接発生する損害も桁違い。

実際、まともな汎用機管理者なら、新旧組み合わせたセキュリティ対策してるよ。

617 :仕様書無しさん:04/02/17 22:44
>>616
でもね、あなたが考える「まともな汎用機管理者」っていうのは、
実際のところほとんどいないわけで・・・・。

618 :仕様書無しさん:04/02/17 22:47
>汎用機上のデータは世界中で預金や軍事機密が集中してるから、テロ支援国家やライバル会社や暴力団を含め、
大きな誤解だと思うが・・

619 :仕様書無しさん:04/02/17 23:54
>616
>あと、ハッキング側に汎用機ユーザーが少ないってのは、世間に多い誤解だと思うよ。
>学生や趣味プログラマはともかく、セキュリティ侵害の大半は実は業界関係者だし、

それは内部漏洩であってクラッキングではないっす。


メインフレーム管理のセキュリティっていうと権限管理、パスワード管理しか考えてない人多いし。


620 :仕様書無しさん:04/02/18 00:36
>>616
コストパフォーマンスのセンスがないですね

50億もかけなくても、500万位で内部からゴッソリ行けますよ



621 :仕様書無しさん:04/02/18 01:02
>>620
このご時世なら100万ぐらいでも結構いけそう

622 :仕様書無しさん:04/02/18 10:05
>>617
そっか。知ってる会社では、みんなまともで、緊急情報も即、横展開しあってるけどなぁ。

623 :仕様書無しさん:04/02/18 10:09
>>619
ちゃうちゃう。

そのデータのアクセス権限を持ってる人が漏洩するだけじゃなくて、
そのシステムの元開発者、更には同業別社の人が、
「あそこはこんなネーミングと運用だったから、隣のシステムも似てるだろう」
てなパターンが多いんだよん。それが結構当たってしまうし。

624 :仕様書無しさん:04/02/18 20:42
メインフレームでも導入時の有名なアカウントがそのままの所、多いし
入ったらすぐばれるが、な

625 :仕様書無しさん:04/02/18 21:02
root?

626 :仕様書無しさん:04/02/18 21:07
今時、メインフレームかよ。時代に取り残されてメンテばっかり
新しい人間が来たらお払い箱で行くところは何処にもない
かわいそうにメインフレーマーたちの逝くところは窓際

627 :仕様書無しさん:04/02/18 22:55
>622
それは最低レベルの話で、まともでもなんでもない。

628 :仕様書無しさん:04/02/19 02:46
>>625
rootと言ってる時点でUNIX厨だとわかるな。
メインフレームの導入用最強のIDは○○○USERってんだよ。
導入後も消されずに残ってる場合が多い。

629 :仕様書無しさん:04/02/19 17:23
>>628
SYS1ユーザーのことね。書籍にも出てるし、伏字にする程の話でもない。
汎用機と言っても、IBM MVS系(およびMVS互換国産OS)の話だけど。
(ACOSやClearPath、IBMでもVMやTPFは別。VSEは忘れた)

630 :仕様書無しさん:04/02/19 21:33
sys1userではない。
ちなみにDB2入ってればこりれまた、DB2最強ユーザのアカウントがそのまま
パスワードも・・・・

631 :仕様書無しさん:04/02/19 22:40
>626
まだそんなくだらんこと逝っているのかヨ

632 :仕様書無しさん:04/02/20 01:53
>>630
DB2・・・
SYSADAMとかだっけ?
忘れたλ...

633 :仕様書無しさん:04/02/20 08:29
そう。SYSADAMとSYSEVE。
この二人がいないと他のユーザーが作れない。

634 :仕様書無しさん:04/02/20 11:28
汎用機は残ります。
ただ単なる巨大なデータ貯蔵庫として。

635 :仕様書無しさん:04/02/20 21:25
まぁめったに使わないデータ置き場所としちゃ最強だわな

636 :仕様書無しさん:04/02/21 00:48
>>634,635
価格高杉
チャネル遅杉
信頼性高杉

637 :仕様書無しさん:04/02/21 00:56
チャネル遅いっていつの時代の話だ?

638 :仕様書無しさん:04/02/21 03:33
>>631
最新技術について行けない、メインフレーマーの言い訳か?
所詮この程度ってことか

639 :仕様書無しさん:04/02/21 15:11
とりあえず最新のメインフレームを知ってから言えよ
メンテだけやってて時代についていけてない奴はメインフレームにもオープンにもいるさ

640 :仕様書無しさん:04/02/21 15:12
最新のメインフレームはJava使うらしいな

641 :仕様書無しさん:04/02/21 15:21
つーかけっこう前からJavaどころかLinuxが動いてるが?



642 :仕様書無しさん:04/02/21 16:45
ガキっぽい連中が増えたな・・・

643 :仕様書無しさん:04/02/21 16:56
多分20年まえの汎用機しか知らんやつだろ

644 :仕様書無しさん:04/02/21 19:06
20年も前に汎用機なんかあるわけないだろ
Windows3.1だってまだ出てねー頃だぜ

645 :仕様書無しさん:04/02/21 20:39
>644
釣り?

646 :仕様書無しさん:04/02/21 20:43
>>645
反応すんなよ

それとも優しさか?

647 :仕様書無しさん:04/02/21 22:21
でも40過ぎのフリーなら汎用機の方が仕事つきやすいよ。
オープン系は年寄り嫌うのよ。
派遣会社営業なんですが、汎用系は期間が長いし(金額は安いけど)、
やりやすいけどな。
前に突然オフコンの仕事がきて、56歳の技術者が仕事についたこともあったし。

648 :仕様書無しさん:04/02/21 23:56
20年前といえば、BASICで抽選機やブロック
崩し作ってたな。


649 :仕様書無しさん:04/02/22 09:21
>>637
ブロックマルチャン、ESCON、FICONと、単体で見ると確かに早くない。

ただ汎用機の利点は、1〜数台で集中処理した場合に、
多数のI/Oが実際に同時に動いても、多数経路が自分で考えて、性能劣化しにくいこと。

オープン系もFC SAN(ファブリック)なら近いことができるが、高価だし、
最終的な共有DISK上でもファイルシステム自体は直接はOS間で共有しにくいし。
(SAN版のNSFもどきとか併用しないと)
結果、サーバーが用途別に数十とか無闇に増えがちではある。

650 :仕様書無しさん:04/02/22 12:25
>>640
Cは、FORTRANとCOBOLに並んで、1970年台のIBM標準言語(SAA CPI)にも採用されてたし。
(IBM系言語のPL/IやAPLやRPGは、入っていなかった)

651 :仕様書無しさん:04/02/22 13:40
>>650
スマン、SAA発表は1987年だった。
http://www-6.ibm.com/jp/event/museum/rekishi/visual4.html

652 :仕様書無しさん:04/02/26 12:51
「汎用機 = COBOL」は日本だけの発想。
汎用機というとCOBOLer叩きを始める安直な人が2chには多いが、無知を公言してるようで恥ずい。

世界的でも業務開発は確かにCOBOLが一番多いが、C/C++はかなり昔から使われてる。
汎用機用のIBM製ミドルも、昔はASMばかりだったが、今はC/C++で書かれたものが多いし、
C/C++との業務インターフェースも持っている。
COMやCORBAもMVS系には10年以上前から、ほぼデフォルトで入っている。

ま、確かに日本では、MVS上でC/C++で業務を書く人は少ないけどね。

653 :仕様書無しさん:04/02/26 18:34
しつも〜ん。汎用機やAS(iシリーズだっけ)とかのEBCDIC環境のC/C++って、
やっぱあのトライグリフ?だかを使うんですか?教えてエロい人。

654 :仕様書無しさん:04/02/26 20:00
汎用機でCを使うなんて狂ってるよまともなコンパイラがあるんだか?
コンパイルするのにJCLきってやっているのかな?
だっせー な C使うんだったらUnixが一番良いよ


655 :仕様書無しさん:04/02/26 20:10
マ板なのに

656 :仕様書無しさん:04/02/26 20:30
マ板てなによ?

657 :仕様書無しさん:04/02/26 20:56
>>656
ム板と双璧をなす2ちゃんの最重要拠点

658 :仕様書無しさん:04/02/26 21:01
だっせー なんて久しぶりにみた
何年前の人でつか

659 :仕様書無しさん:04/02/26 21:05
英数半角を全角で入力する奴は皆年寄りだ
SI/SOが嫌いなのだ

660 :仕様書無しさん:04/02/26 23:02
MS、次期X−ぼXにIBMのzアーキ採用か!?

661 :仕様書無しさん:04/02/27 21:06
メインフレームの仕事も下流工程は中国やインドに出すようになって来てるんですか?

662 :仕様書無しさん:04/02/27 22:12
>>661
そんな話は聞いたことがありません。

663 :仕様書無しさん:04/02/27 22:40
>>662
コボルのコーディングとか単体デバッグとか出したりしてません?

664 :仕様書無しさん:04/02/27 22:42
学生には何聞いても無駄。

665 :仕様書無しさん:04/02/27 23:18
バブル期の人手が足りない時期は中国や韓国の人がコーディングしてた。
コメントの日本語がメチャクチャでかえってないほうがマシでした。
ちなみにCOBOLじゃなくてPL/Iでした。

666 :仕様書無しさん:04/02/27 23:41
インド人がおすすめよん てへっ

667 :仕様書無しさん:04/02/28 12:50
メインフレームの仕事は日本人が守ります






爺ばっかだけど・・

668 :仕様書無しさん:04/02/28 15:00
>>661
汎用機でもオープン系でも、海外開発は増えてるよ。
ただ、新規開発でやる場合が多いから、レガシーでは動きが低い傾向はあるかも。

669 :仕様書無しさん:04/02/28 15:03
>>654
Cで書かれたUNIXが、Cと親和性高いのは当然すね。
ただプラットフォームの選択と、開発言語の選択は、プロなら別問題。
UNIX上のCOBOLも、汎用機上のCも、歴史はそこそこ古い。

670 :仕様書無しさん:04/02/28 15:19
>>667
>爺ばっか
その爺が死んだ後はどうする?

671 :仕様書無しさん:04/02/28 15:32
>>670
失われた高度文明として遺跡になる。

672 :仕様書無しさん:04/02/28 19:33
http://www.itmedia.co.jp/news/articles/0402/28/news010.html
IBMのメインフレーム売り上げ大幅増
Gartnerの調査では、25万ドル以上のサーバ市場で2003年10〜12月期、
IBMの売上高は前年同期比30%増の18億ドルとなった。
この市場全体では8%伸びて総額49億ドルとなっている。

うーーーん? 数字にはハイエンドUNIXやスパコンも一緒?

673 :仕様書無しさん:04/02/28 23:25
>>その爺が死んだ後はどうする?

メインフレーム爺を侮るなかれ、もしかしら俺や漏まいらより生てそうなくらい生きがいいで

674 :仕様書無しさん:04/02/29 12:18
>>その爺が死んだ後はどうする?
そりゃ当然、再構築さ。
・・・そして、歴史は繰り返す。

675 :仕様書無しさん:04/02/29 13:39
技術よりも政治的戦略で食いつなぐのが賢いやり方。

676 :仕様書無しさん:04/02/29 15:38
若手が数十人やってるけどな

677 :仕様書無しさん:04/02/29 18:07
COBOL - wikich http://pwiki.chbox.com/pukiwiki.php?COBOL

678 :仕様書無しさん:04/03/01 15:38
http://itpro.nikkeibp.co.jp/members/NC/ITARTICLE/20040218/1/
オリックス信託がUNIXで基幹系刷新
メインフレームの撤廃に取り組んだ

679 :仕様書無しさん:04/03/01 21:12
>>678
一方、同じ号の中で「国産メインフレーム、次はこうなる」という記事もあるんだよな。
5年後はなくなるといいながら、メインフレーム新機種の宣伝って・・・

680 :仕様書無しさん:04/03/01 21:57
>>679
マッチポンプは世の常でつ。
ていうか日経コンぴゅう太の言うこと真に受けてたら
この業界なんて10回ぐらいひっくり返ってるって。

681 :仕様書無しさん:04/03/01 22:04
IBMのメインフレーム売り上げ大幅増
ttp://www.itmedia.co.jp/news/articles/0402/28/news010.html

メインフレーム=COBOLといった図式ではなく、
ミッションクリティカルな用途の為の統合サーバみたいな
感じになるってことなのかな?



682 :仕様書無しさん:04/03/01 22:04
そもそもオリックス信託銀行で今までメインフレーム
を使ってたのが不思議なくらい。

そんなに客いるのかよ?取引あるのかよ?

683 :仕様書無しさん:04/03/02 00:01
>>681
>>672 と同じね。
多数のOSやミドルを同時に(設定した比率で)動かすのは、メインフレームの得意分野だからね。

684 :仕様書無しさん:04/03/04 11:51
http://japan.cnet.com/news/ent/story/0,2000047623,20064606,00.htm
恐竜、躍進--サーバ市場に食い込む、IBMのメインフレーム「T-Rex」

市場調査会社のGartnerによると、価格が25万ドル以上のサーバ市場における、
2003年第4四半期のIBM製メインフレームの売上は、前年同期比30%増

2003年のメインフレームの年間総売上は前年比20%増の68億ドルだったという

IBMのT-Rexが暴れ始めた



685 :仕様書なしさん:04/03/04 20:13
ここはひどいセンターカットですね

686 :PL/Iのマ:04/03/04 21:21
IT業界の仕事が無くなる?
ttp://japan.cnet.com/column/pers/story/0,2000050150,20063068,00.htm

「SE」が消える日がやってくる?
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040301/140687/


なんだかねぇ、キチンとスキル・キャリアについて考えないとね・・・


ITスキル標準センター
ttp://www.ipa.go.jp/jinzai/itss/index.html

ITSSユーザー協会
ttp://www.itssug.org/



687 :仕様書無しさん:04/03/05 09:10
JCL…懐かしい響きよ…

688 :仕様書無しさん:04/03/05 13:33
日本の大手企業や自治体で、JCL使ってないとこは無いだろう

689 :仕様書無しさん:04/03/05 13:54
http://www.itmedia.co.jp/news/articles/0403/05/news017.html
米IBMは3月4日、分析ソフトを組み込み自己管理機能を強化した
メインフレーム向けデータベース最新版「DB2 for z/OS 8」を出荷開始した。
Javaを使ったアプリケーション開発環境を整え、
データベースのクエリー作成の簡易化が図られている

690 :仕様書無しさん:04/03/05 23:25
うちの会社はOS390・・・

691 :仕様書無しさん:04/03/06 16:47
>センターカット
懐かしい言葉だ。洋服屋から転職したやつが、言語しらないからバグレスでやっておったなぁ。あいつ。

692 :http://jugem.cc/:04/03/07 11:57
【ABEND】メインフレーム万歳5【JCL ERROR】 (プログラマー@2ch掲示板)のまとめ

http://pwiki.chbox.com/pukiwiki.php?COBOL

693 :仕様書無しさん:04/03/07 13:32
>>690
まだMVSのとこもあるよ

694 :仕様書無しさん:04/03/07 13:51
>>691
オンバッチ

695 :仕様書無しさん:04/03/07 16:19
>>693
保守切れてないの?

696 :仕様書無しさん:04/03/07 16:24
>>695
切れてるけど使ってるとこは多い
新規の問題はFIX作ってもらえないが、既知のなら調査してくれる

697 :仕様書無しさん:04/03/07 16:35
日立のAP8000なかなか良いよ!

698 :仕様書無しさん:04/03/07 19:54
>>697
どこらへんが?速さ?

699 :仕様書無しさん:04/03/07 21:04
>>691
Fの金融系ユーザーであることがまるわかり。

700 :仕様書無しさん :04/03/07 21:39
700


701 :仕様書無しさん:04/03/07 23:45
>センターカット
なぜにセンターカット?

カットするのぱいぷで十分

702 :仕様書無しさん:04/03/07 23:53
センター一括
センターカット
C/C
好きなように呼べ

703 :仕様書無しさん:04/03/08 00:50
>>699
昔ね、今は金融からあしあらった。

704 :仕様書無しさん:04/03/08 00:51
「センターカット」を転職した会社のやつに、この言葉をいったら、道路を横切るのか?と言われた。懐かしい。

705 :仕様書無しさん:04/03/08 01:09
センターカットって「大体こんなの」ってのは解るんだが
正確な定義を聞いた事が無い。誰か定義・利点をまとめてけろ。


706 :仕様書無しさん:04/03/08 19:15
ワレメ?

707 :仕様書無しさん:04/03/08 20:22
センターカットとは、髪の毛のセンター部分だけそりこみを入れる髪形です。
センターだけを残すモヒカンとは全くの逆になります。

次のワールドカップでは、ロナウドあたりがセンターカットでバッチリ決めます。

708 :仕様書無しさん:04/03/08 20:39
>>707
お侍?

709 :仕様書無しさん:04/03/08 20:48
計算センターで自振でカットする。

710 :仕様書無しさん:04/03/08 21:29
アベンドってどういう意味ですか?
初心者なもので・・・・・。誰かおしえてください。

711 :仕様書無しさん:04/03/08 21:51
ドイツ語で「夕方の催し」の意味です

712 :仕様書無しさん:04/03/08 21:52
気に食わないCOBOLerに向かってつぶやくと、12ポイントくらいのダメージを与えられるかもしれない呪文のこと。

713 :仕様書無しさん:04/03/08 22:04
>>710
>>3

>>712
warata


714 :仕様書無しさん:04/03/08 23:35
あぶのーまるな終了。

バグレスは一回目はコボルで、つぎが機械語。

715 :仕様書無しさん:04/03/08 23:50
>>705
オンライン中のセンターでの大量DB更新バッチ。口振とか。
本来は夜間バッチだったが、24H対応もあり日中に。
日中の普通の処理と整合性をあわせるため、日付処理や性能評価が大変。

716 :仕様書無しさん:04/03/08 23:57
失敗すると小指カット

717 :仕様書無しさん:04/03/09 00:30
>>716

でも、センターカットトラブルが多かった、昨年までは。
センター一括チームの責任ではないが。

718 :仕様書無しさん:04/03/09 01:01
今日の国会答弁でいかにも大型機がちいさなPCでできることをいまだにやっているような、言い方をしていたのには
笑ってしまったが、金の使い方は難しいものである。

719 :仕様書無しさん:04/03/09 01:36
>>718
実際やってる部分もあるよね。
そんなのエクセルで十分だろ〜が!
みたいなのまでバカ上司がメインフレームしか知らないせいで
無駄遣いシステム作ったりしてる。
外注ソフトハウス大喜び

720 :仕様書無しさん:04/03/09 01:41
まあ、必要性の薄い仕事で食ってる奴がいるのはこの業界だけじゃないし。
ほっといても淘汰される。

721 :仕様書無しさん:04/03/09 11:12
しかし、古くても他からの攻撃がないコンピュータのほうが安心な場合もある。
Winでやるとやられるからな。

722 :仕様書無しさん:04/03/09 14:23
[ワシントン 8日 ロイター] 米労働省の統計担当者は8日、米卸売物価指数(PPI)の
発表が遅れていることについて、コンピューターが古いことが原因であり、発表がいつになるか
不明だ、と述べた。
 米労働省は、新しい産業分類にデータを変換する際に問題が生じているとし、1月と2月のP
PIの発表を無期限に延期した。当初は、1月PPIは2月19日、2月PPIは今週12日に
発表する予定だった。
 1月のPPIは3週間近くも発表が遅れており、米政府の統計として例がない。PPIは企業
収益や雇用の先行指標として注目されている。
 米労働省でPPIデータを担当する職員は、正確な集計が可能になり次第早急に、1月と2月
の統計を別々の形で発表する、と話している。

(入電 = 2004/03/09 10:57:52)


723 :仕様書無しさん:04/03/09 18:18
そんなん良いよ、もう。
メインフレームは今の若者には攻撃できないものなんだから、Winは公開されている技術だからな。

メインフレームなら安心。



724 :仕様書無しさん:04/03/09 21:41
昨日の民就のまっちゃんのあっそう政調会長あてへの、質問、答弁はなんかおかしい。
実情をご存知ない。
汎用機が古いと国民に印象つけている。
WinPCを使えといわんばかり。

Winはだめ、リナックスでもいいが、まだ早い。

725 :仕様書無しさん:04/03/09 21:56
ビッグ・ブルー万歳

ttp://www-6.ibm.com/jp/servers/eserver/zseries/rensai/


726 :仕様書無しさん:04/03/09 22:14
>>724
汎用機上で作って、今は陳腐化してるシステムが山とあるのは事実だが、
今の政府・官僚の、脱レガシーの置換需要喚起も困り者。

727 :仕様書無しさん:04/03/10 20:18
そうそう、そのスバルかなんかしらんが、なかじまひこうきのレガシー、なんちゃって。
レガシーはよくない。

728 :仕様書無しさん:04/03/10 20:22
完了達は、いまのままメンテナンスしていくといっているのは、昔に特定の企業に情報システムを依頼した過去の官僚さんの
お荷物をどうしようとなやんでいらっしゃる。
それは時代の流れであるがために。

難しい問題である。

特定の企業にお金が流れるのだが。困った問題である。

729 :仕様書無しさん:04/03/10 20:47
だれか>>728を読解できる人?

730 :仕様書無しさん:04/03/10 20:58
多分、暗号だろ

731 :仕様書無しさん:04/03/10 21:05
確かにこれはトリッキーなコードですな。

732 :謎はとけた:04/03/10 21:11
この場合のヒントとして、完了達、昔、情報システム、官僚さんのワードが浮かび上がってくる

完了達 = "俺たち"の新しい表現として最新と読める
昔、情報システム = これはそのままレガシーシステムだな
官僚さん = 愚劣な者の表現であろう、おそらくかっこ悪いだな

これを置き換えると
"最新は、いまのままメンテナンスしていくといっているのは、レガシーシステムを依頼した過去のかっこ悪の
お荷物をどうしようとなやんでいらっしゃる。"
となる、"は、いまのままメンテナンスしていくといっているのは、システムを依頼した過去のお荷物をどうしようとなやんでいらっしゃる。"
はノイズと見られるので取り除くと・・

"最新レガシーはかっこ悪い"となるこれが真実だ!

733 :仕様書無しさん:04/03/10 22:07
ますます、ワカンネ

734 :仕様書無しさん:04/03/10 22:40
最初のレガシー:専用機(機種別のOSと言語)
次のレガシー:汎用機(長寿命のファミリーOSと、業界標準の高級言語)
現在のレガシー:クラサバ(陳腐化激しい機種/Solaris/Win/Oracle/VB)

735 :728:04/03/10 23:00
これだけ、レスをいただきましたので、アリガト。
問題提起はタノシ。


736 :仕様書無しさん:04/03/11 10:00
JCSって知ってる?

737 :仕様書無しさん:04/03/11 10:11
>>736
DOS/VSE

738 :仕様書無しさん:04/03/11 11:44
IBM汎用機(S/360 --> S/370 --> S/390 --> zSeries)のOSの系譜

VM --> VM/SP --> VM/XA --> VM/ESA --> z/VM

DOS --> DOS/VS(仮想記憶) --> DOS/VSE(複数空間) --> VSE/ESA

OS/360 --> OS/VS(仮想記憶) --> OS/VS2(多重仮想記憶。別名MVS) --> OS/390 --> z/OS(64bit)

TPF(アセンブラ専用OS) --> 特定用途のみ

AIX(汎用機版) --> 消滅

Linux on zSeries

739 :仕様書無しさん:04/03/11 20:16
OS/VS2 --> MVS --> MVS/SP --> MVS/XA --> MVS/ESA --> OS/390 --> z/OS

じゃないの?

740 :仕様書無しさん:04/03/11 21:24
ディレードとはどういう意味ですか?

741 :仕様書無しさん:04/03/11 21:26
>>740
遅延

742 :仕様書無しさん:04/03/11 22:27
遅漏?

743 :仕様書無しさん:04/03/11 23:37
まだ大丈夫じゃ。

744 :仕様書無しさん:04/03/12 00:03
>>739
そうそう。詳しいね。

745 :仕様書無しさん:04/03/12 00:03
用例:ディレード・オンライン

746 :仕様書無しさん:04/03/12 00:05
銀行の情報系は、ほとんどディレード・オンライン。
勘定系からログを持ってくる時間差があるから。

747 :仕様書無しさん:04/03/12 00:33
ちなみに情報系の「ディレード」ってどれぐらい遅れてるの?
つーか実は情報系がどういう風に使われてるのかイマイチ分かってない・・・・

教えてエロい人

748 :仕様書無しさん:04/03/12 00:39
>>747
銀行によって違うが、早くて数ヶ月、遅いところでは2年以上。

749 :仕様書無しさん:04/03/12 00:39
情報系はよくわかりませんが、
官能系のディレードのことなら任せて下さい。

ディレードだからといって、一人で悩んでいる時代は過去の話。
最近はとても良いソリューションがそろってきています。
ファイザーのバイアグラなんてのは最高です。

750 :仕様書無しさん:04/03/12 00:49
>>748
そんな遅いんだ。意外・・・
取引ログ当て込み形式で反映だったら日次単位ぐらいだと思ってた

>>749
そりゃ遅漏じゃなくて勃起不全だろ

751 :仕様書無しさん:04/03/12 01:17
>>740
その程度の英語がわからんのではコンピューター業界から
足を洗ったほうがよいのでは?空港等で遅れが発生してる
時にも表示されてるだろ。

752 :PL/iのマ:04/03/12 01:28
おいら決めたよ。
ミッションクリティカルな分野でのJ2EEの発展に賭けて、
資格取得して転職するよ

ついでに、マからも足を洗ってもっと上流工程の仕事をするんだ!


753 :仕様書無しさん:04/03/12 01:56
DBのDB2とIMSって、どう違うの?

754 :仕様書無しさん:04/03/12 02:01
>>750
んな遅い訳ないだろ。マジで反応すんなよ。普通は数時間〜2日。
そうでないと情報系にならんだろ。
(情報系の中でも分析系サーバーは月次更新てのも多いが)

755 :仕様書無しさん:04/03/12 02:05
>>753
DB2はRDBMS。SQLで照会する。ORACLEやSQL鯖の仲間。

IMSはIMS-DBとIMS-TPがある。
IMS-DBは階層型DBMS。DLI(GUとかGNとか)で照会する。応答性優先。

IMS-TPはTPモニタ。CICSのMVS特化版のように思えば良い。

756 :仕様書無しさん:04/03/12 02:14
IMS-DBはMVSにしか無い。製造の部品管理や大手銀行の勘定系とか。
弟にDLI/VSてのが、VSEやVMで使われてるが、マイナー。
国産だと階層型ではなくて、ネットワーク型(階層とRDBの中間)。

757 :753:04/03/12 02:25
>755-756
ありがとう。

758 :仕様書無しさん:04/03/12 18:55
>>736
JCL
JCF
なら知ってますが。

759 :仕様書無しさん:04/03/12 20:13
>>758
JCS:Job Control Stateme (昔のVSE用のJCL。今はVSEもJCLらしい)

JCFってなぁに?

760 :仕様書無しさん:04/03/12 20:23
>>759
きっとFacilityだろ

761 :謎はとけた:04/03/12 20:43
>>759
JCF:Job Control Fax

762 :仕様書無しさん:04/03/12 21:24
VSEとJCSの説明
http://www.4reference.net/encyclopedias/wikipedia/VSE.html
http://cis.sunydutchess.edu/jcl.htm

763 :仕様書無しさん:04/03/12 22:42
JCFはねた。会社名

764 :仕様書無しさん:04/03/12 23:12
Japanese Cunnilingus Fuck

765 :仕様書無しさん:04/03/13 00:55
>755
IMS-TM と IMS-DB じゃないの?

DB/DCがそのまま分かれてる

766 :755:04/03/13 01:05
>>765
あ、それ正解。ごめ。
昔はIMS/DB、IMS/DCだったんだよね。で、IMS/DBでもMSDBはメモリ上なので高速。

767 :仕様書無しさん:04/03/13 02:33
MSDBじゃなくてもIMSのDBはDB2と比べりゃ高速
MSDBは用途が限られすぎ。
DEDBもアプリケーション作成する場合に気を使う。

スキルの低い連中が交じり合う開発体制の中では
DL/IのHIDAM中心が安全。

RDBはみんなが使いやすい反面、ヘッポコも多い

IMS/FPを利用するプロジェクトにアホを混ぜてはならない

768 :仕様書無しさん:04/03/13 07:20
いまどきFPでなきゃスピード追いつかないシステムなんてあるの?
シロートな印象としては、CPU速くなってるからDB2でムダムダコーディングでも
余裕でカバーできてしまうような。

769 :仕様書無しさん:04/03/13 09:38
XDM/RD
TMS-4V
ってなに?

770 :仕様書無しさん:04/03/13 16:47
>>768
現在は微妙なとこだね。
金融・製造も大手はIMSだが、負荷の軽いとこはDB2の基幹も増えてきてる。

見積上の応答性が確保できる確実性では、やはり階層型(どんな処理なら、
何クロック使うかまで出せるから)。

システムの発想として、RDBやTCP/IPやUNIXは、使えるリソースを最大限使って
速く処理しようとする。その結果、個々の応答性は他に依存する傾向が強い。
UDBもコストベースのアクセスパスだから、事前に計算した通りに内部処理され
るかは、ユーザーから見ればIMSよりブラックボックス。
(全体としてはUDBの方が、システムで自律してる訳だが)

車でいうなら、IMSはマニュアル、UDBはオートマ。
自家用車にはオートマが便利だが、プロの車はマニュアルと。

771 :仕様書無しさん:04/03/13 17:04
>>770
あと、大手ユーザーから見てIMSとDB2の決定的な違いは、可用性。
IMSはXRF(クラスタリング)で、片系障害時でも仕掛中のTRXもほぼ救われる。
DB2やWebのクラスタリングでは、まだここまで至らない(障害がユーザーに見える)。

ま、そこまでの可用性は不要とか、ATM側でカバーするからいい、
とか割り切れるユーザーが、徐々にRDBに移行してるけど。

772 :あぼーん:あぼーん
あぼーん

773 :仕様書無しさん:04/03/13 17:43
まだダム端使ってる所って、どれぐらいの割合なんだろう。

774 :仕様書無しさん:04/03/13 21:42
>>773
割合はわからんが、うちの客先では
パンチャーの人たちがフツーに使ってる

775 :仕様書無しさん:04/03/13 21:52
未だにCICSでDB2とIMSの情報を同時検索するCOBOLプログラムを書いている30台の私は馬鹿ですか?_| ̄|○
それがWeb系アプリ開発のため、皆がJAVAでアプリ作ってるのに、一人だけメインフレームのデータ参照用に
CICS-TG用のプログラムと言ったら、更に馬鹿者扱いされますか?_| ̄|○


776 :755:04/03/13 22:38
>>773
物理的なダム端末はさすがに骨董品だと思うが、
Windows上の3270エミュレータ画面で開発・運用したり、
一見GUIでも3270にGUIを被せただけってのは、かなり多いぞ

777 :仕様書無しさん:04/03/13 22:40
>>775
CICSもDB2もIMSも現役じゃん。
古いのはBTAMインターフェース書いてたりする奴

778 :仕様書無しさん:04/03/13 23:14
>>775
大手メーカの人ですか?

779 :仕様書無しさん:04/03/13 23:19
つうかXRFはもうやばいだろ。3745いつまであるんだ
東三みたいにしないと

780 :仕様書無しさん:04/03/13 23:33
>>767
今はVSOやShared VSOもあるねー。あんまり使われてないけど。

確かにDEDBは設計が多少難しいかも。
ランダマイザーアクセスって観点からはHDAMと一緒だけど、FP特有の性質
(書き出しは同期点後!)を意識したアプリ設計が必要だしね。

XRF/MADSはサーバクラスタリング手法としては最高の可用性を持ってると思う。
可用性以外の点は考慮の余地はあるけど。ALT側のCPUもったいないとか。

>>775
あ!TGってTransaction Gatewayね。
ECI/EPI呼び出しされる側を書いてると。いや、フツウにいるでしょ。
呼び出す側も書けるようになれば、これ最強。

781 :仕様書無しさん:04/03/14 00:01
IMS-MQブリッジつかうならMSDBをDEDBにせんといかんのでVSOにしないと

782 :仕様書無しさん:04/03/14 00:35
>>775
お前の仕事を運送会社でたとえるのなら、
「軽トラックを2000万円かけて改造して、速度は50キロしか出ませんが4トンの荷物を積載できるようになりました。」
お前はそんな仕事をしているのだよ。

そういったことをしても許されるのはカーマニアであって、運送会社ではないのですよ。
経営者はそんなことを許すはずが無く、そのうちお前はお払い箱だよ。

783 :仕様書無しさん:04/03/14 00:55
>>782
マネジメントが承認したからプロジェクトが実施されてるに決まってるだろ・・・

784 :仕様書無しさん:04/03/14 08:23
>>779
東三はXRFやめたの?

785 :仕様書無しさん:04/03/14 12:11
>>782
釣られたな

786 :仕様書無しさん:04/03/14 15:22
>>784
アクセスハブは組んだけどXRFはやめてないと思ったが

787 :仕様書無しさん:04/03/14 16:53
>>786
アクセスハブは各行で入ってるけど、XRFは別物だかならぁ

それともアクセスハブがWebの負荷分散装置のような役割するって事?
(2系統バックアップで計4台の場合、生きてる2台への端末からの振り分けってことで)

788 :仕様書無しさん:04/03/14 17:38
汎用機系の派遣PGですが
>>780みたいな話をさらっとできる人って
どれほどの企業、立場にいらっしゃる方なんでしょうか?
自分は末端で業務プログラムの設計とかしてるだけで、
そういう話は全然したことも聞いたこともねえです。

789 :仕様書無しさん:04/03/14 19:15
>>788
開発系じゃなくて運用系じゃないの?

790 :仕様書無しさん:04/03/14 19:33
>>788-789
780ではありませんが、運用系のひとの予感がしますね。
業務アプリの開発でも新システムの立ち上げに関わったり
すればあの手のことも当然手がけることになりますが。
あまり企業の規模云々より、どれほどのスキルがあるかどうか
で決まるのではないでしょうか?
もちろんユーザーのシステム部門にいたり、元受であるほうが
関わるチャンスが多いことも事実です。でも、スキルの高いひと
は企業の規模に関係なくご指名も多々あることです。


791 :仕様書無しさん:04/03/14 23:57
>>788
メーカーSEとか、一緒にセリングする協力会社、
あるいは基盤系SE(OS/390やIMSとかの導入設定など)とかかも。

業務系PGとは、明確に分かれてるとこですね。普通は知らなくて当然かと。

792 :仕様書無しさん:04/03/16 00:02
自分で書き込んだ内容を自分で絶賛するのは見苦しいぞ

793 :仕様書無しさん:04/03/16 01:09
自作自演ハズカスィー

794 :仕様書無しさん:04/03/16 01:34
790ではありませんが、自作自演とは思えませんね
私はスキルがあるのでスキルの無い人は一生派遣で
コキ使われて下さいね

795 :仕様書無しさん:04/03/16 22:49
自分でスキルがあるというヤツほどスキルがない。
俺は偉いんだというヤツほど、たいして偉くもないのと同じ。

お前、教授・教師・医師・弁護士等法律家でないのに「先生」と呼ばれているだろ。
辞書で調べればわかるが、「先生」という呼び方には馬鹿にする使い方もあるのだよ。
ねっ、先生さんよ。

796 :仕様書無しさん:04/03/16 22:54
自作自演かどうかなんて、どうでもいいじゃん。指摘した奴も真実はわからんのが2ch。
反応すること無いよ。(と反応するヤツ)

797 :仕様書無しさん:04/03/16 23:53
790ですが・・・
こんなに反響があるとは思いませんでした

それにしても皆さん僻みっぽいんですか?

それから私は釣り師でもありません。

798 :仕様書無しさん:04/03/17 00:24
>>797
まーまー。反応する事ないよ。
誰が本人なんてのも互いに証明できないし、好きに書いてればいいのよ。

2chは普通っぽい長文は、素人と思われて変なレスが付き易いってだけ。

799 :仕様書無しさん:04/03/17 09:51
メインフレームなんて相手にされないのね

http://itpro.nikkeibp.co.jp/members/SI/JIREI/20040308/1/
キャパシティは2倍を確保 7月の“大波”も乗り越えた---オンライン証券

800 :仕様書無しさん:04/03/17 20:39
まさかここに書き込む人で、
メインフレームを昔ながらの使い方しか知らない香具師はいないよね?


801 :仕様書無しさん:04/03/17 20:49
学校でせっかく習ったパチョコンの学習が、社会人になってからまったく異なる業務に就いて
悪戦苦闘しているひとの集まり。

802 :仕様書無しさん:04/03/17 21:52
「パソコンの使い方」を習うってのが
どーしても違和感があるんだが
「Winの使い方」だろ?どうせ

803 :仕様書無しさん:04/03/17 22:21
>>800
 真上にひとり居るようだが・・・


ここで恨み節やら煽りやら書いてんのはどゆ意図からなんだろ・・・
意見交換・情報交換の場でしょ、ココは

年度末で、プロジェクトから撤退する競合他社のPGの背中を見つつ
だんだんと狭くなってゆく自分の居場所を感じる3月の晴天・・・


804 :仕様書無しさん:04/03/17 22:28
>>803
まあ2chだから。爽やかにスルーしよう。


805 :仕様書無しさん:04/03/17 23:04
>>804見てふと思ったんだが



って、仁王立ちしてるエルビス・プレスリーに似てない?

806 :仕様書無しさん:04/03/17 23:25
現実を見れない爺さん婆さんが集まってるのはここですか?

807 :釣られてみた:04/03/18 00:31
>>806
現実ってなんだ?
COBOLもIMSも現実に存在してるぞ


808 :仕様書無しさん:04/03/18 01:45
>>807
現実とは、
 ・メインフレーム=COBOLと考えてる人がまだまだ多い
 ・何故かCOBOLerは煽られる

俺の現実は
 ・新規開発の仕事が少なくなって、単価が下がるのは死活問題




809 :仕様書無しさん:04/03/18 07:28
>>800
昔ながらの使い方をしないのなら尚更メインフレームを使う理由はないな
安いパソコンサーバ並べりゃ充分だ

810 :仕様書無しさん:04/03/18 09:50
ていうか、上司と同僚の頭の悪さにたまに絶望する。
まあ、むこうもそう思ってるんだろうけど。

811 :仕様書無しさん:04/03/18 21:31
>>809
・昔ながらの使い方:高信頼性、全国DB一元管理、大量帳票、専用ミドル(IMS,CICS,DB2/MVS...)、EBCDIC
・今風の使い方:巨大Webサーバー、J2EE基幹系、サーバー統合(Linux数百台を1台でまとめて運用軽減)

812 :仕様書無しさん:04/03/18 21:32
コボラーなら残業せずに、サッカー観戦だよな!
PGなんて金を稼ぐ手段だ!

813 :仕様書無しさん:04/03/18 21:33
>>811
安いパソコンサーバ並べりゃ充分だ

814 :仕様書無しさん:04/03/18 22:57
別に汎用機文明を全面支持するわけではないが、
汎用機をろくに触ったこともなかったり、
末端PGとしてしか見たことのないやつが
うだうだ言わないでくれる?

815 :仕様書無しさん:04/03/18 23:11
>>806
見れない・・・・

日本語勉強しようぜ

816 :仕様書無しさん:04/03/18 23:25
>>814
禿同


817 :MVSSE:04/03/18 23:34
>>814
そういう勘違い野郎の書き込みを見て楽しむ

という利用法もあったり

しませんかそうですか

818 :仕様書無しさん:04/03/18 23:46
汎用機ユーザー技術を継承するように次世代小型汎用機?がでてきますので、
技術者は安心しろ。でも、向上心は忘れないでね。

819 :仕様書無しさん:04/03/18 23:49
いいじゃん。
本当に安いパソコンサーバー並べて済む業務(システム)なら、それでいいのよ。
汎用機が必要じゃないとこにまで、汎用機種使ってはいけない。
(昔はメールまで汎用機だったしな)

820 :仕様書無しさん:04/03/18 23:54
でも、そのまたユーザーが磁気テープなどを使用してる場合があるので、周辺機器は残るなぁ。
バンキングは最後までメインフレームが残るはず。

821 :仕様書無しさん:04/03/19 00:55
飯が食えるならそれでいい
適材適所を喜び取引が増えるような取引先には適材適所を
何でもかんでも汎用機でやりたがる取引先には汎用機を
PC大好きならPCで
客が喜んで自分が儲かるそれでいい
客が喜ばなくても自分が儲かればそれでいい
世の中金さ

822 :仕様書無しさん:04/03/19 01:20
言っていることは理解できます。
企業などが情報投資できるかぎりメインフレームは存在する。はてまた、技術者も必要とされる。
だな。

Web本位になろうとも。

823 :仕様書無しさん:04/03/19 07:03
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040318/141616/
日本IBM、他社製ホストからUNIXへの移行プログラムを発表
他社製メインフレームを自社のUNIXサーバー「pSeries」へ置き換えるプログラムを発表した


824 :仕様書無しさん:04/03/19 18:25
>>823
AS/400を切り捨てたってこと??

825 :仕様書無しさん:04/03/19 20:43
>>824
他社メインフレームからの移行先を、従来のzSeriesやiSeries(旧AS/400)に加え、
pSeries(RS/6000)を追加した、って書いてあるでしょ。

文字コードや運用を考えると、zやiが向いてるけど、最近pが急成長してるからでしょう。

826 :仕様書無しさん:04/03/19 21:51
俺、商用UNIXやWin2K、IBM系汎用機、UNISYS汎用機
など、様々なクラスのマシンを見てきたけど、マルチユーザ
マルチプロセスの環境で、長時間安定稼動できるのは汎用
機だけだったよ……。
それになにより、汎用機はいかにもコンピュータって感じが
するし、一般人は絶対に触ることもない特殊な世界。
パソオタ君にはわからんものがあるよ……。

827 :仕様書無しさん:04/03/19 22:15
>>826
その安定性と引き換えに「地獄を見ながら技術力(?)向上」
という図式がなくなる。
分からなくなったらベンダー呼んじゃえという安易な方向へ進む。
(ROI考えると正しいかもしれないけど)

会社に無駄遣いさせて(自分は損せず)、自分の技術を挙げようとする者にとっては、
魅力なし。

828 :仕様書無しさん:04/03/19 22:20
「いかにもコンピュータ」な感じがするのは、汎用機ではなく3420だと思う。

829 :仕様書無しさん:04/03/19 23:40
汎用機設計してる人は技術力あると思う。

830 :仕様書無しさん:04/03/19 23:44
とんかつ屋で設計しませう。

831 :仕様書無しさん:04/03/20 00:30
http://that.2ch.net/test/read.cgi/onsen/1067142460/
メインフレームの新情報らしい。

832 :仕様書無しさん:04/03/20 02:55
>>826
汎用機でビデオ編集とかすれば不安定になるだろうね。

833 :仕様書無しさん:04/03/20 04:06
>>826
汎用機使ってるオンラインシステム等のほとんどが毎日再起動していると思うが‥
UNIX使ってるWebサーバ、メールサーバ等のほとんどが365日連続稼動だが‥

834 :仕様書無しさん:04/03/20 04:34
再起動つーてもパワーオフしないけどな、再IPLは。

835 :仕様書無しさん:04/03/20 04:44
>>833
IPLやってるわけではないよ。
バッチやバックアップのためにオンラインだけ落としたり立ち上げたり。

836 :仕様書無しさん:04/03/20 07:36
>>835
最近、オンラインを毎日再起動なんてしなくなったよね?
昔はDBMSの関係上、毎日再起動(といってもJOB停止するだけ)してたけど。

837 :仕様書無しさん:04/03/20 08:51
前の会社では夜間バッチが終わったらきっちり電源OFFまでやってたけどな。んで、朝一に電源オンして〜
てな感じで。


838 :仕様書無しさん:04/03/20 13:13
>>837
それも汎用機使いの醍醐味
各機器に次々に電源が入っていくのも壮観
落とすときも、電源が落ちていくのも同様
空調も落として、静けさを取り戻したマシン室も結構好き


839 :仕様書無しさん:04/03/20 13:27
>>838
今ではパソコンでできることを、そんな大袈裟なことしてたわけです。

840 :仕様書無しさん:04/03/20 13:29
>>839

         \   ∩─ー、    ====
           \/ ● 、_ `ヽ   ======
           / \( ●  ● |つ
           |   X_入__ノ   ミ   そんな餌で俺様が釣られクマ――!!
            、 (_/   ノ /⌒l
            /\___ノ゙_/  /  =====
            〈         __ノ  ====
            \ \_    \
             \___)     \   ======   (´⌒
                \   ___ \__  (´⌒;;(´⌒;;
                  \___)___)(´;;⌒  (´⌒;;  ズザザザ
                               (´⌒; (´⌒;;

841 :仕様書無しさん:04/03/20 13:50
>>840
汎用機スレでAAは、珍しいな。
30過ぎてやってたら、かなり恥ずかしい。

842 :840:04/03/20 13:55
   ||
 ∧||∧
( / ⌒ヽ
 | |   | 
 ∪ 亅| 
  | | |
  ∪∪

843 :仕様書無しさん:04/03/20 14:25
>833
ApacheやsendmailとIMSやCICSを一緒にされても困る訳だが。

844 :仕様書無しさん:04/03/20 14:40
sendmailとIMSはともかく、apacheとCICSなら一緒にしたくなる気持ちもわからんでもない

845 :仕様書無しさん:04/03/20 14:46
            ∧_∧
     ∧_∧  (´<_`  ) 流石だよな俺ら。
     ( ´_ゝ`) /   ⌒i
    /   \     | |
    /    / ̄ ̄ ̄ ̄/ |
  __(__ニつ/  3270  / .| .|____
      \/____/ (u ⊃


846 :仕様書無しさん:04/03/20 15:05
幼稚ですね

847 :仕様書無しさん:04/03/20 15:14
汎用機のOSやミドルは99.999%の可用性はあっても、
その上で動いているオンラインは糞なので、毎日再起動が必要です。
また、年に数回はダウンしますが、オンラインの大バグが原因です。
可用性は99%程度です。

それならば、可用性99.99%のオープン系で99.9%のオンラインを開発すれば、99.89%の可用性を実現できます。
ほとんどの汎用機よりもワンランク上の可用性で、費用は半分程度。
さらに性能は数倍で、いうことなし。

ただし、COBOLer社員が大量に余るので人材の受け皿が必要です。
どうやって人材の受け皿を作るか、お前らが考えて下さい。

848 :仕様書無しさん:04/03/20 15:20
>>840-843
ワラタ

849 :仕様書無しさん:04/03/20 16:28
            ∧_∧
     ∧_∧  (´<_`  ) 幼稚だよな俺ら。
     ( ´_ゝ`) /   ⌒i
    /   \     | |
    /    / ̄ ̄ ̄ ̄/ |
  __(__ニつ/  5250  / .| .|____
      \/____/ (u ⊃


850 :仕様書無しさん:04/03/20 16:34
>>847
子会社として、タクシー会社を設立汁!

851 :仕様書無しさん:04/03/20 18:18
>>850
ど、どうしよう!!?
俺、免許もってないぞ!?

852 :仕様書無しさん:04/03/20 19:00
>>847
どんなバグを経験したのか聞かせてほしいな

853 :仕様書無しさん:04/03/20 19:02
>>827
まぁそうだ。しかし、本来ユーザー企業は本業の仕事をしたいのに、
2年ごとに陳腐化する「最新技術」を覚えないと、まともな設計や発注や運用が
できないって現状が、異常だと思う。

ユーザーのシステム部門は、本来は業務知識を持って、システムの最適化の企画
をすべき。

TVや自動車の内部も進歩が早いが、ユーザーは気にせずつかってる。

854 :仕様書無しさん:04/03/20 19:04
>>844
ちと違う。CICSと比べるなら、Apacheではなく、アプリサーバー(WASとか)。
どっちもTPモニタ。


855 :仕様書無しさん:04/03/20 19:06
>>847
「その上で動いているオンライン」って、CICS上の制御共通系とか?

アプリの不具合でミドル自体をしょっちゅう再起動してるなんて、
汎用機ではありえないけど。

856 :仕様書無しさん:04/03/20 19:31
>>841
そうでもないよ。AA自体はBBS黎明期からあったからね。
当時は2400BPSモデムが高速だったが(w

857 :仕様書無しさん:04/03/20 20:38
>>847
お前、どっちも使ったり作ったことないな。それとも学生か?

ちなみにCOBOLerの問題はあと数年。
2007〜2010年の間に団塊の世代が消えていくので一気に減る。
完全に消えてしまわないから保守要員は確保できるだろうし。

今後、メインフレームのアプリケーションより、
バブル期に多発した変な言語やDBMSで組まれたアプリケーションの
保守が一番厄介だったりする…殆ど作り直しだし。

858 :仕様書無しさん:04/03/20 21:17
>>857
情報系のどうでもいいアプリを作り直すだけだろーが。
大袈裟なんだよ!

859 :チンポコーマン:04/03/20 23:16
若いけど派遣でコボルやってるボクちゃんの食い扶持はどうなるにょ〜?

860 :仕様書無しさん:04/03/20 23:41
他の言語もお勉強しなさ〜い。なんでもできる人になりなさぁ〜い。

861 :仕様書無しさん:04/03/20 23:45
>>857
古い汎用機の大量のCOBOL資産も大変だが、保守手順は一応確立してる。
このクラサバ全盛機の、VBでOracleで、ホイできあがりてな方が、もっとタチ悪いレガシー。

862 :仕様書無しさん:04/03/20 23:47
>>853
そいつはMSに言ってくれ。
あいつがペースを乱している

863 :仕様書無しさん:04/03/20 23:49
>>860
それより金はたいて変換ツール買ったほうがはやい。
最近のはバカにできない精度だ。

変換できないのは、外注に押し付けて金ふんだくればいい。

864 :仕様書無しさん:04/03/21 02:13
>>863

「最近のはバカにできない精度だ」という意味は、
(1) 変換ツールとは思えないほど精度がよい
(2) COBOLer(= バカ) が新しい言語を覚えて移植するよりも精度がよい

(1)か(2)のどちらですか?

865 :仕様書無しさん:04/03/21 02:54
ツールなんて飾りですよ
偉い人にはそれがわからんのです

いや・・・まじで・・・

866 :仕様書無しさん:04/03/21 09:58
>>865
激同。

ツールって、新技術原理主義で言い訳しか言わない新人プログラマと同じ。
全く応用がきかん。使い方間違えるとすぐ消える…

867 :仕様書無しさん:04/03/21 12:11
>>859
管理のお勉強をしなさい。
コンピューターの言語なんていくら覚えても稼ぎなんて
頭打ちだよ。

868 :仕様書無しさん:04/03/21 12:38
>>867
管理なんか勉強したら上司の粗が見えて上司に嫌われるぞ。

869 :仕様書無しさん:04/03/21 13:31
自分が上司の上司になればいい

870 :仕様書無しさん:04/03/21 13:44
は!
JCLエラーはJES2のエラーであって
フツウはABENDしないということに今気づいた

871 :仕様書無しさん:04/03/21 14:07
>>867
そそ。運用管理自体は、ほとんど変わらないからね。
いつ、どうバックアップするか、保守パッチ当てるか、冗長性のレベルは、
業務上のサービスレベル要件は...

872 :仕様書無しさん:04/03/21 16:47
839は838のどの辺についてResしているのだろう・・・。

873 :仕様書無しさん:04/03/21 17:26
>>870
JES3かもよ

874 :仕様書無しさん:04/03/21 17:44
>>870
フツウじゃないときもあるのか?

875 :仕様書無しさん:04/03/21 18:00
>>873
JES3は使ったこと無いからしらないなあ

>>874
JES2にユーザー出口をかますかベンダーツールなんかで強制アベンド?
なにぶんホストだから手段はありそう

876 :仕様書無しさん:04/03/21 18:56
>>875
それは、JCLエラー後のプログラムでABENDさせてることになる。

877 :仕様書無しさん:04/03/22 00:49
JOB NOT RUNとJOB FAILEDの差がわからんやつもおる

878 :仕様書無しさん:04/03/22 22:00
お仲間か、先輩に、これでやってとJCLを教わりそのままやってるといつまでたっても
わからずじまいだね。JCLの文法書などみないとね。

879 :仕様書無しさん:04/03/23 00:21
移転age

880 :仕様書無しさん :04/03/23 07:49
移転sage

881 :仕様書無しさん:04/03/24 00:28
DATASET NOT FOUNDの理由は移転だったのか

882 :仕様書無しさん:04/03/25 22:31
//DOUDEMO JOB
// EXEC PGM=JDJDUMMY
//SYSIN DD DDNAME=SYSIN
//SYSPRINT DD DSN='NULLFILE',DISP=SHR
//


883 :仕様書無しさん:04/03/25 23:12
SHRって共有だったっけ?

884 :仕様書無しさん:04/03/25 23:42
shareを英和辞典で引いてごらん

885 :883:04/03/26 01:25
share
共用する:特定の世代,又はファイルを,タスク間で相互に参照すること。
制御プロでは
本来排他的にのみ使用されるシステム資源を、時間的に分割して複数のデータ処理システム
又は複数の利用者が使用ですること。共用直接アクセス記憶装置。
とかいてありました。

886 :仕様書無しさん:04/03/26 12:21
>>882
出力をSHRすんなボケぇ

887 :仕様書無しさん:04/03/26 12:59

         _人人人人人人人人人人人人人人人_
           >  シャア♪  シャア♪  シャア♪  <
           ̄^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄
     ll     ll          ll     ll          ll     ll
     l| -‐‐- |l  __     l| -‐‐- |l  __     l| -‐‐- |l  __
    ,イ」_  |ヽ_| l、〈〈〈〈 ヽ  ,イ」_  |ヽ_| l、〈〈〈〈 ヽ  ,イ」_  |ヽ_| l、〈〈〈〈 ヽ
   /└-.二| ヽ,ゝl.〈⊃  } /└-.二| ヽ,ゝl.〈⊃  }./└-.二| ヽ,ゝl.〈⊃  }
   l   ,.-ー\/. 、l |   |. l   ,.-ー\/. 、l |   | l   ,.-ー\/. 、l |   |
  |  /.__';_..ン、!   ! |  /.__';_..ン、!   !|  /.__';_..ン、!   !
  / /<二>  <二>!゙、 // /<二>  <二>!゙、 // /<二>  <二>!゙、 /
 //--─'( _●_)`ーミ /.//--─'( _●_)`ーミ / //--─'( _●_)`ーミ /
<-''彡、   |∪|  / <-''彡、   |∪|  /  <-''彡、   |∪|  /
 / __  ヽノ /     / __  ヽノ /    / __  ヽノ /
 (___)   /     (___)   /     (___)   /



888 :仕様書無しさん:04/03/26 16:38
スプールがぁ、イニシエーターがぁ、どうでもいいや。
JCLで何回もマシンデバッグしてね。

889 :http://naoya.dyndns.org/feedback/app/search?keyword=cobol:04/03/26 16:42
【ABEND】メインフレーム万歳5【JCL ERROR】 (プログラマー@2ch掲示板)のまとめ (wikich)

http://pwiki.chbox.com/pukiwiki.php?COBOL

890 :仕様書無しさん:04/03/27 20:23
JCL構文エラーは、まずTYPRUN=SCANしろ!

891 :仕様書無しさん:04/03/27 21:57
JCLでデバッグ?

892 :仕様書無しさん:04/03/28 00:31
>>890
他力本願なやつめ。

893 :仕様書無しさん:04/03/28 14:54
家にOSW/F4 MSP入門のテキストありました。107ページもあります。
なんとか勉強できそうです。

894 :仕様書無しさん:04/03/28 18:37
富士通の新社長は「汎用機に将来は無い」と公言しとるな。

895 :仕様書無しさん:04/03/28 18:57
>>894
「(富士通の)汎用機に将来は無い」です
ソース:ガートナー


896 :893やくざ:04/03/28 19:46
ヤパリ

897 :仕様書無しさん:04/03/28 19:50
じゃぁFさん、また黒電話屋さんに戻るのかなぁ

898 :仕様書無しさん:04/03/28 20:48
TYPRUN=SCANってなんか役に立つか?

899 :仕様書無しさん:04/03/28 21:30
今度初めてメインフレームの仕事することになったんですけど、
これを知らないヤシはモグリ、みたいな知識あります?
あと、こんなことやってみせると玄人っぽい、みたいなテクとか。

900 :仕様書無しさん:04/03/28 21:41
そんな下らない事考える前に研修でもいけ。マニュアル嫁。
それより前に環境書けよ厨房。

901 :仕様書無しさん:04/03/28 23:18
>899
本番機入って Z EOD

902 :仕様書無しさん:04/03/29 00:34
非常停止を押す

903 :仕様書無しさん:04/03/29 09:18
>>899
IBM系だったら
・文字コードの違いとSO/SIの存在
・ISPF/PDF画面 (特に =2 と =3.4)、入っていればSDSFも
・JCL

904 : :04/03/29 14:04
>>899
マシン本体の電源入れて安心せずに、
空調機の電源の入れ忘れに気をつけるw



905 :仕様書無しさん:04/03/29 20:11
899です。IBM系です。
>>901
本番用の環境に入ってソース全消し、みたいな事ですかね
>>902
エスカレーターの非常停止ボタン並みにヤバイ事ですか
>>903
そのへんググる事から始めます
>>904
はい。

906 :仕様書無しさん:04/03/30 00:05
エマージェンシー牡丹だけは押すな!、どえりゃぁことになってもしらねぇぞー〜〜〜。

 あと、早朝など起動時にMTデッキがリレーで、順番に立ち上がるのはめったにみられないからね。
 早起きは三文の得だ。まじで。

907 :仕様書無しさん:04/03/30 01:25
引くエマージェンシースイッチも有るわけだが・・・

908 :906:04/03/30 01:29
引くのもあるな、押すのは危険だから引くようにしてあるな。
アクリル叩き割るのもな。
でも、雄、引くな。

909 :仕様書無しさん:04/03/30 03:18
47F0 0000

910 :893:04/03/30 12:24
GSはどうだろう?小型汎用。

911 :仕様書無しさん:04/03/30 19:56
>>908
エマージェンシー引くと、外からは戻せないタイプもある。
(CEが鍵で蓋あけて、中の引き金で戻す)

停電中だからとふざけて押すと、後でCEに怒られる (w

912 :仕様書無しさん:04/03/30 20:20
そんなことしても知らないよ〜。新人さんへ w

913 :仕様書無しさん:04/03/30 20:28
>>899
ちと遅いが
$PJES2で周りがあたふたしたら
$Sで逃げろ

914 :仕様書無しさん:04/03/31 01:11
エマージェンシーがあるなんて原子炉みたいでかっこいいでつね。

915 :仕様書無しさん:04/04/01 00:48
>>913
そういえば、$Pとか言っても通用しない所もあるね。
\Pじゃないと。

>>914
データ漏洩とか、そういうの防ぐ為だっけ?

916 :仕様書無しさん:04/04/01 17:04
退職する前に、一度だけエマージェンシー・ボタン押していいですか?

917 :システム切替で夜間作業のマ:04/04/01 18:55
>>916
許可する

918 : :04/04/01 20:28
>>916
退職金で損害賠償を支払う事になるな

919 :仕様書無しさん:04/04/02 01:28
懲戒免職は退職金でないワナ

920 :仕様書無しさん:04/04/02 11:49
916新人で汎用機やらされるからといってそんなに早くやめなくても(ねただとおもうが)

921 :& ◆goxwo8eeRg :04/04/02 18:29
>>916
早く汎用機爺に気に入られて、仕事もらえ

922 :仕様書無しさん:04/04/03 01:01
今度のプロジェクトXはHのお話しでしゅ

923 :仕様書無しさん:04/04/03 01:10
NのJCLもIのもF,Hもなんか全く同じように思えるのはなぜだろう?
互換機?

924 :仕様書無しさん:04/04/03 01:46
>>923
何をいまさら。

1971年に、資本自由化を前に通産省の行政指導で、当時の国産6社は、2社づつ3グループでIBMに対応した。

富士通・日立はIBM互換、NEC・東芝はハネウェル(GE)と提携、三菱電機・沖電気が独自路線(スペリーランド寄り)。

FとHのMシリーズは、IBM互換機。
いわゆるOS互換で、FやHの専用OSが必要だが、アプリはIBMのが原則動く。
OSコマンドもJCLもほぼ同一(上位互換なので、国産拡張あり。だから逆の移行は手間)

なお米国アムダール(今はFの子会社)は、いわゆるH/W互換で、IBM製OSを動かす。
日本ではほとんど使われてない。

これが詳しいよ
http://web.kyoto-inet.or.jp/people/s-oga/jcomhist/ron-b.htm

925 :マルスのマ:04/04/03 10:09
>>922
第140回 4月6日放送予定
「100万座席への苦闘」
〜みどりの窓口・世界初 鉄道システム〜
http://www.nhk.or.jp/projectx/140/index.htm

社内でも見ろ見ろって、うるさい位言われてる
言われなくても見るての!

4月切替終了!

926 :仕様書無しさん:04/04/03 14:18
>>924
COPYしたんだぁ。産業スッパイもあったそうですね。

927 :仕様書無しさん:04/04/03 14:59
産業スパイはHITACとMELCOM

928 :仕様書無しさん:04/04/03 23:49
>>909
0番地へとぶの?

929 :仕様書無しさん:04/04/04 10:38
>>928
ヌル(ry

930 :仕様書無しさん:04/04/04 17:19
ヌル? NOPなら
4700 0000

931 :仕様書無しさん:04/04/04 19:03
9C00 0100

932 :仕様書無しさん:04/04/04 21:01
SIOですね

933 :仕様書無しさん:04/04/04 23:56
>>932
日清のカップ麺のことですか?

934 :仕様書無しさん:04/04/06 21:16
>>925
いまやってるこれか 日立の宣伝

935 :仕様書無しさん:04/04/06 21:17
二十八件?デットロックしないのか?

936 :仕様書無しさん:04/04/06 21:20
歯痛制御してないのか。

937 :仕様書無しさん:04/04/06 21:30
大型コンピュータと通信回線を通して瞬時に繋ぎます。

938 :仕様書無しさん:04/04/06 22:03
マルサって何だぁ?

939 :マルスのマ:04/04/06 23:12
プロジェクトX見た
今も昔も変わらんのね…

現在のマルスは501(2002.10〜)
次のバージョンアップのときには
どんなシステムになるんだろ…


940 :仕様書無しさん:04/04/06 23:20
>>938
国税査察官の通称です。査察の「サ」。

941 :仕様書無しさん:04/04/06 23:28
>>940
マルスのようですね、失礼。
でも、電気機関車を東芝とか川崎とか日立がEF65をやっていたが、券売機はモムロン
発券システムはHだったんですな・

942 :仕様書無しさん:04/04/06 23:57
激しくつまらんかったぷろじぇくとエックス。

943 :仕様書無しさん:04/04/07 00:09
Fに続くへ立ちのHNKにより企業再生宣伝効果番組。
Winが全部悪いのぉ。

944 :仕様書無しさん:04/04/07 01:49
作業メンバの面、ながめてたり、いきなり電源落としたり
とんでもねー馬鹿リーダーだな。でもこういうのが実際
にいるからな。

945 :仕様書無しさん:04/04/07 01:56
>>941
昔は端末も目立だったよ。

946 :仕様書無しさん:04/04/07 02:03
9時にMTが回り始めるのが理解できなかった。
オンラインなのにMTを使うのか?
磁気ドラム作ったって言ったばかりじゃないか?
ログ用なのか?
最初からマウントしてあるのか等。

947 :仕様書無しさん:04/04/07 04:09
DASD系は効果だからHLF軟化はMTにしたんじゃないの?
シーケンシャルだし

948 :仕様書無しさん:04/04/07 04:33
>>947
MTでシーケンシャルだと目的のレコード探すのに超時間がかかるよ。
とてもオンラインには使えない。
VSAMかDBでないとな。
また、ログアーカイブ用だとすると、ログデータセットがいっぱいになってからテープに吐くから9時丁度には動かない。

949 :仕様書無しさん:04/04/07 08:50
列車事故で関係無いとこまで一気に止まったり
駅員がぜんぜん状況を把握していなかったりは
すべて目立が悪いということか?

950 :マルスのマ:04/04/07 12:30
>>946
座席データは磁気ディスクにあるが、
発券の際のログ(障害回復用)はテープに取ってたんじゃないの?

なんなら部長に聞いてみるが

951 :仕様書無しさん:04/04/07 16:15
HITAC8150で紙テープを読ませてアセンブリプログラムをやってました。昔。

952 :仕様書無しさん:04/04/07 20:33
>>948
その当時は磁気ディスクor磁気ドラムは高価だったから、ログデータセット
は直接MT出力じゃなかったかな。ALTERNATE MTを複数指定して順番に
MT交換していくの。だから9時から回りだすの

953 :952:04/04/07 20:45
あげちゃったんで、再度。
http://hyperws1.ism.ac.jp/Japanese/HTMLs/Outlines/Computers/1971.html
いい例見つからなかったけど、その当時の磁気ディスクor磁気ドラムの容量
では、ログをとることすら出来なかった。

954 :仕様書無しさん:04/04/07 21:16
ログってジャーナルのことか?

今の(H)のXDM+XDM/RDの場合、まずVSAMデータセットに
ジャーナルをはき出して、それをSWAPの後、MT等に
アンロードするのだが

もしかしてXDMの前のDBと言うものが存在したのか?
と言うかマルス自体がDBなのか。

XDMはマルスの技術を継承したものだったりして。


955 :仕様書無しさん:04/04/07 21:29
そうそう。ジャーナルですね。
DBもなく、OSもない(モニタっていってた)時代じゃなかったかな。

956 :仕様書無しさん:04/04/07 21:32
XDMの前がADMでしたっけ。VOS1系でPDM

957 :仕様書無しさん:04/04/07 21:38
その前が、TMS-3V

958 :仕様書無しさん:04/04/07 22:27
この間のプロジェクトXで写ってたMTドライブ、
うちの職場のと一緒だった。

おもわず、飯吐いたね。

959 :仕様書無しさん:04/04/07 23:16
モニタ! モニタだって? CRTとかTFTとかじゃない方のアレかよ!
おじさんたち、ぼくそんな時代知らないよ!

単語知ってるだけでも歳だったりして。

960 :仕様書無しさん:04/04/08 00:16
>958 まだ使ってたのかヨ
やっぱ3480っしょ

961 :960:04/04/08 00:16
スマソメーカ違った


962 :仕様書無しさん:04/04/08 01:22
近頃MT媒体の供給元が・・・

あたりまえか、音楽用のカセットテープすら巷から姿を消しつつあるし

963 :仕様書無しさん:04/04/08 12:59
うちには、8インチFDが
ありますが・・・

964 :仕様書無しさん:04/04/08 17:11
http://headlines.yahoo.co.jp/hl?a=20040408-00000002-cnet-sci

「不惑」を迎えたIBMのメインフレーム--絶滅の予言もどこ吹く風

 IBMのS/360は、同社メインフレーム製品の流れをつくりだしたコンピュータだが、7
日(米国時間)はそのS/360が発売されてから40年めにあたる。しかし、同社のメイン
フレームビジネスは一向に衰えを見せていない。


965 :仕様書無しさん:04/04/08 20:55
>>958
MTデッキ って今は言わないの?

966 :仕様書無しさん:04/04/08 21:44
うちはMTデッキって言ってるよ

967 :仕様書無しさん:04/04/08 22:20
DDS−4なら新しいところ、自振などでまだ大きいのを使っているところもあるね。

968 :仕様書無しさん:04/04/08 22:31
DDS-4など使いません。
メインフレームでは普通、 1/2インチCMTです。

仮に、その手のテープを使うとしたら、絶対にDDSには行かずDLTに行くはずです。
メインフレームのテープに、信頼性の低いヘリカルスキャンなど使うはずが無い。
おまけに、DDSの磁性体は接着剤で付けています。
普通、高級機なら真空蒸着だろ。

969 :仕様書無しさん:04/04/08 22:48
オープン系でもLTOとかDLTだろ
DDSは常用するもんじゃない

970 :仕様書無しさん:04/04/09 00:05
DLTは聞かないぞ
やっぱりLTOだろ

971 :仕様書無しさん:04/04/09 00:10
Fオープンリール限定なら
F613がいい
F619は使いにくい
MTの連続マウントには613が使いやすい


972 :仕様書無しさん:04/04/09 01:35
>>952
そそ。昔はログは直接MT(オープンリール)にとってた。

973 :仕様書無しさん:04/04/09 01:43
>>968-970
ちゃんと世代で考えよう。

第一世代:オープンリール(サイズや密度は色々。IBM 3420とか)

第二世代:1/2インチCMT(IBM 3480,3490とか。CSTともいう)

第三世代:DLTまたはLTO(シェア争い中)

別格:DDS(汎用機では普通使わない)

http://www.keyman.or.jp/search/30000047_3.html
バックアップツール 基礎講座

http://e-words.jp/w/LTO.html

974 :仕様書無しさん:04/04/09 02:17
LTOに1票

975 :仕様書無しさん:04/04/09 04:07
10年ほど前、RS6000のバックアップを8mmテープで取ってたけど、エラーだらけだった。
だからヘリカルスキャンは信用できない。
やっぱ、メインフレーム万歳の漏れは3490がいい。

976 :仕様書無しさん:04/04/09 09:19
>>975
どんなドライブでも不良は多いよ。ヘッドとかセンサーとか。

2.5世代というか、RS/6000は3590てのもあるね(3490とは互換性なし)。
今後はIBMやHPはLTOだけど。

977 :仕様書無しさん:04/04/09 09:28
>>964
http://www.itmedia.co.jp/news/articles/0404/08/news016.html
米IBM初のメインフレーム「System/360」の登場から4月7日で40周年を迎えた。
IBMではこれを記念して同日、中堅企業向けのメインフレーム新製品
「eServer zSeries 890」を発表した。


http://www-6.ibm.com/jp/servers/eserver/zseries/40years/history.shtml
メインフレーム誕生から40年の歩み

http://www-6.ibm.com/jp/servers/eserver/zseries/40years/s360-main-v01-2mbps.wmv
S/360誕生40周年

http://www.atmarkit.co.jp/news/200403/19/ibm.html
国産メインフレームを狙い撃つIBMのUNIX

978 :仕様書無しさん:04/04/09 09:29
http://nc.nikkeibp.co.jp/jp/articles/features/20000828/main.html
Java普及に立ちふさがるCOBOL

COBOLは2000年が40周年だったのね

979 :仕様書無しさん:04/04/09 15:42
IBM、メインフレームOS/390のサポート終了へ
http://japan.cnet.com/news/ent/story/0,2000047623,20065349,00.htm

980 :仕様書無しさん:04/04/09 15:42
マイクロソフト、IBMのメインフレーム顧客に照準
http://headlines.yahoo.co.jp/hl?a=20040409-00000007-cnet-sci

981 :仕様書無しさん:04/04/09 23:35
>>979
OS/390では、最初から各リリースのサポート期限は決まってたと思ったが...

982 :仕様書無しさん:04/04/09 23:36
>>980
1990年頃から「5年後にはWindowsはメインフレームを追い越す」と
いい続けてるけど、まだ言ってるのね

983 :仕様書無しさん:04/04/09 23:41
>>977
これで驚いたのは、フェードアウトすると思われたVSEが、
z/VSEとして継続されたこと。

z環境(64bit)でも、z/OS、z/VM、z/VSEと伝統の3OSの選択肢があるのね。
これにLinux for z を含めて、4つ。

984 :仕様書無しさん:04/04/10 00:13
>>977
「国産メインフレームを狙い撃つIBMのUNIX」か。
まず自分のところをリプレイスしろよな・・・
IBMのBP向け資料も、pSeriesの資料では「Sun→pSeries」の事例や移行の試算例が出ているし、
xSeriesの資料では「Sun→xSeries+Linux」の事例や試算例が出ている。
俺は「z→p/i/x」「i→p/x」「p→x」の試算例が見たいよ・・・

985 :仕様書無しさん:04/04/10 08:01
国産メインフレームの中にはIBM互換機もあるわけで、
角度を変えて見れば自社の製品で自社の製品を狙い打ち(w


986 :仕様書無しさん:04/04/10 19:04
>>984
IBMは機種(ブランド)ごとに営業活動するからね。
パートナーはpやxの取り扱いが多いから「他社→p」「他社→x」が目立つだけで、
「他社→i」「他社→z」の試算例も山とあるんだよ。

各資料は作成部門の都合のいい事しか書かない訳だが、
性能重視ならp、価格重視ならx、運用重視ならi、集中管理重視ならzかね。

987 :仕様書無しさん:04/04/10 19:28
上の方のテープの話を読んでたら
テストデータのMTでI/Oエラー出して(開発チームには使い古しのMTしか支給されなかった)
MTデッキのドア開けてアルコールに浸した布でヘッドを掃除した事を思い出したよ。
オペに「ボロいテープ掛けてデッキ汚すんじゃねぇよ!馬鹿野郎!」とか罵倒されながらw

OMTなんてまだ現役?

988 :仕様書無しさん:04/04/11 00:47
>>987  (小型Fメインフレームユーザです)
うちは、去年の9月に廃止した。MT400本くらい処分した。
ラインプリンタも廃止して、PCと共用のプリンタにした。
11インチのストックフォームの連続用紙をやめて、PC用A4カット紙
に替えたが、これが事務の省力化に一番貢献した。机の上の書類の
山の量が半減したし、倉庫に保管する量も半減した。

989 :仕様書無しさん:04/04/11 00:54
>>987
現役のアヒャってるオペレータでございます。

>OMTなんてまだ現役?

(月1で来るピークの日だと、1日で30本ぐらい付けてたりします)

もっとも、5月頃で保守切れの為、退役するようですが…

990 :仕様書無しさん:04/04/11 01:10
3420じゃないと銀行がうけつけねーんだ

991 : :04/04/11 11:47
職場でオペレータやってた奴が辞めるときに、
不要のMTのテープをリボンの代わりにして
記念品を包んでたのを思い出すよ


992 :仕様書無しさん:04/04/11 12:04
以前金融やってたとき、ユーザーの自振のMTをつかったが、なんと先端がくちゃくちゃのを
給与用に送ってきていた。
なんと、その大手会社は磁気テープを製造する会社であった。

新品使えよ。

自社の給与どうでもいいみたいだ。

993 :仕様書無しさん:04/04/11 12:08
先端なんてくちゃくちゃでも問題無いの判ってるから使ってんじゃねーの


994 :960:04/04/11 12:17
>990
どこの地銀?

大抵の銀行は、3480/90だろ?

995 :仕様書無しさん:04/04/11 16:03
>>992
オペレーターからみたら、にっくき取引先だったのかもよ

996 :仕様書無しさん:04/04/11 18:22
>>994
どの都銀も3420タイプは外部データ互換用に必ず残してる筈。

EB(オンライン)化してない取引先ごとの口座振替とか多いし、
3420タイプは業界標準規格だし(3480/90はIBM独自規格)。

自行内のバックアップとかは3480/3490CSTでいいけどね。

997 :仕様書無しさん:04/04/11 19:58
耐久テストとか・・・

998 :仕様書無しさん:04/04/11 20:29
COUNT DOWN 2

999 :仕様書無しさん:04/04/11 20:30
COUNT DOWN 1

1000 :仕様書無しさん:04/04/11 20:30
1000!!!

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

211 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)