OSをSolarisからRed Hat Enterprise Linux Serverへ移行します。…
OSをSolarisからRed Hat Enterprise Linux Serverへ移行します。このとき、Solaris上C言語で作成したプログラムについて、どのような注意点・修正が必要でしょうか？具体的な移行作業を示して下さい。 【OS情報】 Solaris(SunOS 5.10、CC:Sun C 5.8 2005/10/13、GCC：version 3.4.3、32bit) Red Hat(Enterprise Linux Server release 5.3、CC：GCCへのリンクまたはsunstudio12.1、GCC：4.1.2.20080704(Red Hat 4.1.2-44)（GNU Make 3.81）、64bit) 【なんとなく分かっていること(これらを掘り下げて回答として頂いてもかまいません)】 1.アーキテクチャが異なるため再コンパイルが必要、その際Makeのオ
Java／.NET開発者のための「ここが変だよ、COBOL」
Java／.NET開発者のための「ここが変だよ、COBOL」：COBOL - Getting Started（1）（1/2 ページ） 50年前に事務処理用に開発されたCOBOLは、いまでも多くの企業で使われ続けている。基盤部分が近代化してもCOBOLは生き残るかもしれない（編集部） さあ、COBOLを始めてみようか マイクロフォーカスの小林純一です。今回、COBOL言語入門の連載をCoding Edgeで書かせていただくことになりました。最後までよろしくお願いします。 企業活動の迅速性とコスト削減を目指したITモダナイゼーションの潮流の中で、メインフレーム中心の情報システムの見直しが進んでいます。Java EE（Java Platform, Enterprise Edition）や.NETフレームワークを基盤としながらも、COBOLで書かれたコアとなる計算ロジックをサービスとして活用する手
データセンター統合の基盤としてLinuxを活用する
Linuxはデータセンター統合に威力を発揮する。それはなぜか。まず、現在の経営環境の下で大規模なITインフラプロジェクトが承認を得るには、プロジェクトによるビジネス価値の実現が見込めなければならない。そこでこれらのプロジェクトは、大きなROI（投資利益率）を達成することが求められる。達成できれば、TCO（総保有コスト）の負担も軽減されることになる。以下に説明するように、Linuxはこうした要求を満たすのに役立つ。 データセンター統合プロジェクトの主な目的は、電力および冷却コストの削減、省スペース化、サーバリソースの全体的な使用率の向上だ。データセンター統合には通常、サーバ統合が含まれるため、こうしたプロジェクトはサービス契約コストやソフトウェアライセンスコストの大幅な削減を実現しながら、サーバリソースの全体的な使用率を大幅に向上させるだろう。わたしが率いたプロジェクトの中には、コスト削減効
104台の基幹系サーバーを20台に 2年かけLinux上に基盤を集約
みずほ銀行は2007年10月、「AIX」で稼働していた基幹系システムをLinuxに移植すると同時に、UNIXサーバー104台を20台に集約するプロジェクトを完了させた。狙いは保守費の削減。業務アプリケーションの修正を最小限に抑える、動作検証を徹底するなどのリスク削減策が奏功し、70億円を投じた開発に成功した。 投資額70億円、開発工数3000人月に及んだプロジェクトの最大の特徴は、絶対止められない銀行の基幹系システムにLinuxを採用したことだ。 インターネットバンキング、テレホンバンキングなど、トラブルが顧客サービスに直接影響を来すチャネル系システムのOSを「AIX v4.3」から「SUSE Linux Enterprise Server 9」に刷新。アプリケーションは、業務ロジックに一切手を加えず最低限の修正にとどめた。同時に、日本IBM製UNIXサーバー「RS/6000」104台を、
メインフレーム的事情 - novtan別館
増田での議論が面白いことになっている。 日立製作所はまともな会社になるべき 日立のメインフレームがバカ高い話 http://anond.hatelabo.jp/20080720205422 Unixマシンも高い話 http://anond.hatelabo.jp/20080721015612 理由についての解説。主に垂直統合による高コスト化とリスクヘッジの話 今サーバー更改とかやり始めているところなので他人事ではない。 なんでメインフレームを使うのか 上記増田にも書かれているけど、メインフレームの高可用性というのは無駄にすごい。いや、新聞に「ATMがXX分停止」とか載らないようにするためには無駄じゃないんだけど。システムダウンを検知するとコンマ何秒かの間に待機系に切り替わる。富士通なんかはメインフレームの開発をやめたって言っていたけど、じゃあそういう高可用性のあるシステムをどうするか、とい
[NRI]レガシーマイグレーションのすすめ〜メインフレームの問題を根本から解消する “リライト”を中心としたアプローチ〜
情報システムはこれまで、メインフレームからクライアント/サーバ(C/S)システム、Webシステムへとパラダイムシフトを繰り返してきた。そしていま、さらなるパラダイムシフトを遂げつつある。“いつでもどこでも”ITサービスにアクセスできる、ユビキタスネットワークへのシフトである。 しかし現在でも、メインフレームを抱えている情報システムは少なくない。古くからIT化を推進してきた企業の多くは、メインフレームとC/Sシステム、Webシステムが混在しているのではないだろうか。しかしこのようなシステムは今後、大きなリスクを抱えることになるだろう。メインフレームの存在が、システムに様々な問題を突きつけることになるからだ。 まず第1にメインフレームは、保守や運用費用が高額である。第2にシステムの硬直化の原因になる。メインフレーム上のアプリケーションは、度重なる改修によって構造が複雑化しており、新たな機能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
IBM Developer