Recent Entries
Archives
Search


Links
Powered by
Movable Type 2.64

2010年04月01日

4/1ですね

4/1で世間的にはエイプリルフールですが、フツーに弊社Webページ更新しましたヽ(´ー`)ノ
公式にもblogはあるのですが、ココもそれなりに長く続いておりましたので、
もう少しだけお付き合いください。
こちらは、公式にはソレはどうかというネタとか、展開して参ります
・OpenCOBOLにDBGp使ってデバッガ載せてみたよー とかはあっちに載せます。
 (出来上がったら)
・メシネタとか猫は大体こっち

2010年03月25日

OpenCOBOLを拡張

03 FILLER PIC X(12) VALUES 'HELLO WORLD!'
     CHARACTER TYPE KM-12P
みたいなのを文法的に通るようにしてみたり。
コレで色々な移植の手間がかなり減ったヽ(´ー`)ノ
CHARACTER TYPE KM-12 部分が拡張ですね。 見覚えがあって、なおかつ同様に困ってるトコには配ったり出来るかも。

2009年11月23日

OpenCOBOLで半角カナ変数名等

某所で扱ってるCOBOLソースに半角カナ変数名があって困ったのですが(;´Д`)

とりあえず力業にてパーサ弄って半角カナ変数名については通すように改造ヽ(´ー`)ノ
C言語に変換されてもコメント欄にしか出てきませんから特に問題なかろうということですね。ちなみに半角カナのサブルーチン名/モジュール名はC言語の関数名に変換されるのでもう少し手の込んだコード修正が要ります。全角といいますか漢字については0x5cその他について考慮する必要があったりしてもう少し難しいですね。ShiftJISでソースを取り扱う限りは。
# 時間さえあればすぐにでも実装出来るんですが 時間がが

某所で扱ってるCOBOLソースはCOPY句でREPLACING //HOGE// BY //FUGA//で、全てのHOGEをFUGAに置き換える拡張機能があるのですが、ついでにコレも実装してみたり。ちょっとソースが汚いですが動作はしている模様。

とりあえず以上近況でしたヽ(´ー`)ノ

2009年10月16日

LD_PRELOADつかってOpenCOBOLで

LD_PRELOAD使ってOpenCOBOLでcob_file_openを差し替えとかヽ(´ー`)ノ

 以前にOpenCOBOLとcob_perlとMySQLで等でOpenCOBOLのデータベースファイルアクセスをMySQLへの処理に差し替える等書いてたわけですが、実際に現場で動作しています。

 ただし、この方法だと、CALL文使ってファイル関連の処理を書き換えたりするので、シカケが理解出来ていないとなかなか難しいところもあるのかなと考えていました。また、書き換え後のコードはDB処理に特化していますから、元のファイル処理のコードを書いた人(というか、大抵の場合は他社の社員の人)がメンテナンスしにくくなります。これは困りますね(;´Д`)

 ということで、LD_PRELOADつかって、libcob内のcob_file_open他file関連の関数を差し替えてしまう拡張を実装中ですヽ(´ー`)ノ。これならソース自体も元のままですし、気が向いたときファイル、またはDBを切り替え出来ますし、混在もファイルとDBでデータの突き合わせもやりやすくなります.
イメージ図

ファイル/DBの切り替えですが、特殊なファイル名(DSNとか)が指定された場合に、DBを使用するという方向で実装しています。または、ファイル名をカタログを確認して、処理方法を決める等。いずれにしろ、cob_file_open他ファイル関連の関数の処理に横入り出来ればデバッグにはかなり便利ですよね。

これと、OpenCOBOL-1.1から導入されたデバッグ用の機構を併用して「どのプログラムのどの行でどのようなデータが読み/書きされたか?」をモニタ出来るような拡張も準備中です。

ヽ(´ー`)ノ今月中に実装完了させたいところですね(出来れば)

2009年07月16日

OpenCOBOLへの移植

某所で某メーカー系COBOLソースをOpenCOBOLへ移植してるのですが(´ー`)
色々と困った点など。

とりあえず現在はOpenCOBOLには通信関連の機能(COMMUNICATION)は実装されてませんから、コレは何らか代替手段を使う必要(たとえばcob_perlを使用してperlを使った外部通信モジュールの実装など)がありまして、ソースを1対1対応で書き換えるのが難しいというのがあります。ただし、汎用機からLinux上のOpenCOBOLへ持って行くソースでは、そのような機能はほとんど使わないため今のところ問題とはなっていないのですが。同様に、印刷関連についてもメーカー系COBOLではかなり拡張されていますので、これは以前にも書いておりましたが、拡張エスケープシーケンスと仮想ラインプリンタの組み合わせで対応してたりします。

メーカー系COBOLのソースを3000本程度眺めまして、COMMUNICATION、他印刷関連のキーワードが含まれるソース1100本程を除外した残りの1900本のうち1100本についてはほとんど自動的に変換するスクリプトを作成しましたが、残りの800本程については色々と面倒な問題が残っています。

たとえば、項目名に漢字、半角カナが使用されている物もあります。これは処理系(OpenCOBOL)のパーサへのパッチで対応出来そうです。今のところプログラム名(PROGRAM-ID)に漢字、半角カナを使用した物は無いのでいくらか救われています。OpenCOBOLは仕組み上COBOLソースを一旦Cへ変換しgcc等コンパイラを使用してバイナリを生成します。このときPROGRAM-IDは関数名として展開されるため、ここが漢字、半角カナになっている場合は別途変換規則を作ってやる必要があります。項目名は内部的には全く別の連番が降られた変数名(または配列)へ変換されるため、この問題は発生しません。

その他、ファイル関連で汎用機で使えるRDB、VSAS等はOpenCOBOLでは実装されていませんので、vbISAMなど利用したソースへ置き換える必要があります。このときファイル名について汎用機ではバッチからパラメータとして引き渡すことが出来るように、COBOLの処理系が設計されていますが、OpenCOBOLの場合は環境変数なり何かから取り込む必要があります。幸いにしてそのような引き渡しを行っている箇所はファイル名に関する部分だけのようでしたので、これはコマンド起動直前に環境変数へパラメータをセットすることにして対応出来そうです。また、ファイル共有やポインタの引き継ぎに関してBASEDやEXTERNALなどのキーワードが使用されていますが、OpenCOBOLではこれらは実装されおらず、緩い制限にて使用可能のため単純にキーワードを取り去ることで流用可能でした。

COMP-1、COMP-2等の変数についてはメーカー系COBOLによって実装内容は様々ですが、某メーカーCOBOLではCOMP-1が2byteバイナリ整数、COMP-2が4byteバイナリ整数でしたのでそれぞれBINARY-SHORT、COMP-5(またはCOMP-X)にて置き換えてみました。とりあえずバイト長をあわせつつということですが、COMP-5、COMP-5についてx86_64上では8byteとして扱われるという噂(ためしてません)も在りましたので、別のもっと良い代替手段を使う必要があります。

その他FILEに関してLASTが実装されていない等在りますが、当方ではISAMではなくてMySQLへの置き換えを進めておりますので、ORDERを逆にしてやるだけで対応出来ています。

また元のCOBOLソースの定義体自体に問題があったり、長さが異なる項目へのMOVEなども既存ソースには散見されましたので、MOVE用のC言語コードを出力する段でチェックしてwarningとして出力するようにcobcを改造しつつ、安全なmemcpyを出力するようにしました。これでセグメンテーションフォルトも発生せず、問題となる箇所も見えるようになりましたので、元ソースの開発元へ問い合わせを行いながら作業を進めることが出来るようになりました。

その他にもたくさんたくさん在りますが、互換性も残しつつ元々のOpenCOBOLだけでは出来な胃部分については随時拡張していくことでかなりの工数を節約出来るようになっています。

2009年04月24日

opencobol-1.1/cobc/typeck.c

OpenCOBOLでcopyする項目の長さが異なるときの処理で(´ー`)検討


素のままだと単にmemcpyするコードが吐かれるんですが、srcとdstのうち短い方に合わせた方が良いんじゃないの?という修正例。ちなみにオリジナルのコードはdstの長さに合わせるようになってますが、src側で確保しているメモリ領域外も複製元としてreadされる(そしてSEGFAULT)場合があるので、おそらくこのコードの方が良いと考えてます。
試しに

こういうコード追加してみればわかりますが、既存のコードのあちこちに結構埋まってるものです(srcとdstの長さが異なるCOPY)

apache-php-OpenCOBOL-perlーMySQL貫通

apache-php-OpenCOBOL-perl-MySQL貫通ヽ(´ー`)ノ

とりあえずapache上のmod_php5から呼び出されたphpスクリプト中でphp_opencobol.so使ってOpenCOBOLで書いたプログラム(*.so形式)を呼び出してその中からcob_perl.so経由でperlスクリプト呼びだしてさらにDBI/DBD使ってMySQL呼ぶところまで完了。

ユーザー

(http)

apache

(mod_php5)

php

(php_opencobol.so)

OpenCOBOL

(cob_perl.so)

perl

(DBI/DBD)

MySQL

シカケは大がかりなんですが、コードは短いです(たいしたことやってないので)。現場の方ではさらにapacheとユーザの間にCurlというリッチクライアントが入ります。つまりコレ(;´Д`)CurlとPHPとCOBOLとperl(+SQL?)という多数の言語が入り交じってる環境です。ただし、COBOL部分に関してはレガシー資産のかなり部分を流用しますし、perl部分についてはこちらが用意したDB/ISAMの変換部分をほとんどそのまま利用して貰うことになってます。

モノ自体のコンセプトは昨年の10月頃には出来てて、基本部分も稼働してたんですが先ほどメモリリーク関連のバグが解決しましてヽ(´ー`)ノapache配下のmod_php5から繰り返し呼び出してもSIGSEGVでオチ無くなりました。CGI版の場合は繰り返しは呼び出さないので顕在化してなかったんですが、module版のphp5では数回呼び出すとオチるという苦しい状況でした。解決。

cob_perlつかって印刷イメージをPDFで吐くとかもやってます。またinitだけじゃなくて環境を再初期化しないpinitとかも実装中ヽ(´ー`)ノまだまだネタは尽きないようです。

2008年11月17日

OpenCOBOL最近の動向

OpenCOBOLの最近の動向(´ー`)

日本国内では動きがほとんど無いのですが、ぽつぽつとキーワードの露出は増えていますね。OpenCOBOLと他言語のリンクなどの記事も見られるようになってきましたし。

海外では、Luaやlibdbi、Tcl/Tkなどの言語とのリンクも進んでいます。またOpenCOBOL自身もGLOBALキーワード周辺の実装などの動きがあったようです。その他CALL/CANCEL周辺の動作について安定性が増すようです(>1.1)

その周辺に関しまして週1くらいのペースで現在のメンテナ他数名でIRCで検討が進んでいます。

弊社内ではOpenCOBOLとPHPの連携は以前から試していましたが、perlとの連携も出来るようになり様々な応用を検討しています。OPEN、CLOSE、READ、STARTの代わりにperlで作成したsubを呼び出す仕様で色々と面白いことを考えています。

Eclipse用のpluginなども実装検討中です~ヽ(´ー`)ノ

2008年10月07日

OpenCOBOLとperl

OpenCOBOLとperl(´ー`)素敵な出会い


CALL "cob_perl_require" USING "barcode.pl".
CALL "cob_perl_call" USING "barcode"
"sample-barcode.png" "1234567890".

#!/usr/bin/perl
use GD;
use Barcode::Code128;

sub barcode {
my ($filename, $value) = @_;
my $barcode= new Barcode::Code128;
$barcode->text(FNC1, $value);
open(PNG, ">$filename") or die "Can't write $filename: $!\n";
binmode(PNG);
print PNG $barcode->png("CODE 128");
close(PNG);
}
1;

これがもう動作していたりする(´ー`)
詳細は今はまだ出せないんだけど、もう少しバグ出ししたり、メモリリーク調べたり、某所で運用して安定性を確認したり速度チューンしたりしたら(´ー`)出てくるかも。
ちなみにちゃんとCOMP-3もBINARYも対応してたりします。

2008年10月04日

OpenCOBOLとmysql、PostgreSQL

本年度の仕事はもうほとんどOpenCOBOLがらみ(´ー`)本当です

で、OpenCOBOLからのDB接続でOracle、MySQL、PostgreSQL、DB2、その他だいたい可能になりました(´ー`)あと半角全角変換サブルーチンとかも持ってますしCOMP-3(OpenCOBOLではPACKED DECIMAL)やCOMP-5(Binary)と外部プログラムでの相互変換、汎用機ラインプリンタのエミュレータ、他言語(PHP,Perl,Python)との連携、COBOLソース上の定義体の他言語でのパーサ、XMLの処理、ネットワーク通信(シリアル、TCP/IP)、GUI(Tk)だいたいOKです。

ただいままとめて準備中。現在OpenCOBOLの開発やってるRoger Whileにも連絡を取りながら進めておりますヽ(´ー`)ノ

2008年09月30日

ある日のOpenCOBOL

ちょっと試してみたくて(;´Д`)


[]$ COB_CC=llvm-gcc COB_CFLAGS="-emit-llvm -c" cobc -c -O2 AIVPA010
[]$

いや(;´Д`)何でもないです。

p.s. 一応モノは出来ました。

2008年09月28日

OpenCOBOLの中で参照される環境変数

OpenCOBOLについてのドキュメントってすごく少ないので(´ー`)ドキュメントプロジェクト方面のお手伝いをしてみたいところ

で、英語は得意ではないので資料が無い部分についてソースリストから資料を作り起こすお手伝いを検討してます。例えば、OpenCOBOLの処理系が参照している環境変数の情報とかまとまってませんよね?ドキュメント無いからコンパイラのソース読んで使われ方を類推する…という訳です。そして資料をまとめて泣きながら英訳して開発者に送って確認してもらうという。(´ー`)どう?


]# grep -R getenv /usr/src/redhat/BUILD/open-cobol-1.1|awk 'BEGIN{FS="getenv"}{print $2}'|cut -f2 -d\"|grep -e ^[A-Z]|sort|uniq
COBCPY
COB_EBCDIC
COB_FILE_PATH
COB_LDADD
COB_LIBRARY_PATH
COB_LINE_TRACE
COB_LOAD_CASE
COB_LS_FIXED
COB_LS_NULLS
COB_PRE_LOAD
COB_SORT_MEMORY
COB_SYNC
DB_HOME
MYOCLIBS
PATH
POSIXLY_CORRECT
TMP
TMPDIR

結構あるんですよ。でも情報が全然無いんですよね(´ー`)だからヤル

OpenCOBOLと日本語文字コード

OpenCOBOLと日本語文字コードについて(´ー`)あまり資料がないようなので調べてみたり

そもそも1000speakers:6にて「日本語対応はどうなってますか?」と質問が来たのに「見たこと無いから分からないですね」とか解答してしまってたので、少しはマジメに調べてみないと…というわけです。一般的に日本語と処理系の間で「\」の扱いが問題になることが多いわけですが…


000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. 日常会話表現.
000030 DATA DIVISION.
000040 WORKING-STORAGE SECTION.
000050 01 日常会話表現.
000060 03 FILLER PIC N(08) VALUES 'こんにちは 日本'.
000070 PROCEDURE DIVISION.
000080 DISPLAY 日常会話表現.
000090 STOP RUN.

とかソースがShiftJISで書かれていたとして。「表」部分は0x955Cで2byte目に0x5C「\」を含んでいます。コンパイルを試してみると:

[]$ cobc -x HELLOJ.cob
HELLOJ.cob:2: Error: syntax error, unexpected "end of file", expecting "Literal" or "Identifier"

怒られちゃいました(;´Д`)。PROGRAM-IDをHELLOJに変更しても

[]$ cobc -x HELLOJ.cob
HELLOJ.cob:5: Error: syntax error, unexpected "end of file", expecting "Literal" or "Identifier"

と今度はSTORAGE SECTIONに書いた日本語変数名で蹴られてます。これは「表」という文字を取り除いても変わりません。それではリテラルはどうかと言いますと:

000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. HELLOJ.
000030 DATA DIVISION.
000040 WORKING-STORAGE SECTION.
000050 01 HELLOJ.
000060 03 FILLER PIC N(08) VALUES 'こんにちは 日本'.
000070 PROCEDURE DIVISION.
000080 DISPLAY HELLOJ.
000090 STOP RUN.

こう書いてみました。

[]$ cobc -x HELLOJ.cob
[]$ ./HELLOJ
{
[]$ ./HELLOJ | nkf -Sx
こんにちは 日本
[]$

大丈夫ですねヽ(´ー`)ノ特に自動では文字コード変換してくれませんので、出力がShiftJISで行われることを仮定してnkfを通してみればしっかりと狙ったとおりの出力が得られます。
cobc -C として中間で吐かれるCのソースを見てみれば分かりますが、

memcpy (b_5, "\202\261\202\361\202\311\202\277\202\315\040\223\372\226\173\040", 16);

と8進数に変換して取り扱ってくれていますのでリテラル中にバックスラッシュがあっても問題ないわけです。項目名やプログラムIDについては処理系にちょっとだけパッチを当てれば対応出来るものと思われます。ただし、現状では項目名やプログラムIDに単体で「\」が含まれていてもエラーになりますので、何らかのオプションがある場合にはチェックを緩くしてくれるようにしないと難しそうです。とりあえずL10Nヽ(´ー`)ノそしてI18N。

2008年08月01日

OpenCOBOL 1.1にはSTART FILENAME LAST RECORDが…

OpenCOBOL 1.1にはSTART FILENAME LAST RECORDが…(;´Д`)ないみたいですね未実装

どうする?
1.諦める
2.コンパイル対象のCOBOLソースを弄って何とか対応する
3.実装されるまで待つ

急いでるときには答えはこの中にはないわけです(´ー`)。
「4.実装する」
それが答えでも良いですよね。しかも自分でやる。
登坂ルートを考えてみました。OpenCOBOLのコンパイラ(cobc)そのものに手を入れるという凶悪な方法もあるんですが、ちょっと大がかりすぎるし将来的に本家でやるでしょうからとりあえずCALL文で対応します。そこでCALL文で ファイル名(FILENAME)渡せるのかというと渡せるようです。少なくとも内部的には h_FILENAME としてポインタ渡ししてくれます。
そして、libcob/fileio.c には

case COB_READ_LAST:
fh->readdir = ISPREV;
if (isread (fh->isfd, (void *)f->record->data, ISLAST | lmode) == -1) {
ret = isretsts (COB_STATUS_10_END_OF_FILE);
}
break;

こういうコードもあります(しかし、このcase文を通るようなselect()の値は設定されませんが)。
ということで(´ー`)たぶん良い子の皆さんが寝て起きた頃には実装してしまうことでしょう。

OpenCOBOLでdebug

OpenCOBOLでdebugヽ(´ー`)ノOpenCOBOL 1.1は便利ですよ

OpenCOBOL用に書いた、または他のCOBOL実装から持ってきたコードのdebugをする際に知っておくと大変便利な話いろいろ。

OpenCOBOL forum: debug with gdbでも取り上げられていますが、

OpenCOBOL 1.1にて --ftraceallや --ftrace オプション(または -g )をつけてcobcコマンドを実行すると吐かれた実行ファイル(または *.so 動的ライブラリファイル)に cob_set_location関数が埋め込まれます。これは処理の各行に埋め込まれ「これから実行する処理は元のCOBOLソースのどの位置か?」について情報を内部変数に保存します。
さらに、内部変数 cob_line_trace が1のとき(cob_ready_trace()が呼ばれているとき/ --ftraceall、--ftrace 時)は現在実行中の処理行についての情報を標準エラー出力へ出力します。自動的にprintfデバッグできるわけですね(-gの場合は、cb_flag_source_location = 1 だけ行われるため、cob_set_location関数はプログラム中に埋め込まれますが、トレース表示はされません)。


void
cob_set_location (const char *progid, const char *sfile, const unsigned int sline,
const char *csect, const char *cpara, const char *cstatement)
{
cob_current_program_id = progid;
cob_source_file = sfile;
cob_source_line = sline;
cob_current_section = csect;
cob_current_paragraph = cpara;
if (cstatement) {
cob_source_statement = cstatement;
}
if (cob_line_trace) {
fprintf (stderr, "PROGRAM-ID: %s \tLine: %d \tStatement: %s\n",
(char *)progid, sline, cstatement ? (char *)cstatement : "Unknown");
fflush (stderr);
}
}

void
cob_ready_trace (void)
{
cob_line_trace = 1;
}

void
cob_reset_trace (void)
{
cob_line_trace = 0;
}

実行結果ですが:


[root@po SAMPLE]# cobc --ftraceall SICB0515
[root@po SAMPLE]# cobcrun SICB0515
PROGRAM-ID: SICB0515: ENTRY SICB0515
PROGRAM-ID: SICB0515: MAIN SECTION
PROGRAM-ID: SICB0515: MAIN-RTN
PROGRAM-ID: SICB0515 Line: 290 Statement: PERFORM
PROGRAM-ID: SICB0515: OPEN-RTN
PROGRAM-ID: SICB0515 Line: 308 Statement: INITIALIZE
PROGRAM-ID: SICB0515 Line: 309 Statement: INITIALIZE
PROGRAM-ID: SICB0515 Line: 313 Statement: MOVE
Segmentation fault
[root@po SAMPLE]#


という感じです(´ー`)。Line:313を実行後にSegmentation faultが発生しているのがわかりますね(原因は集団項目のサイズ分確保しない状態でSICB0515プログラムを呼び出したことでした)。PROCEDUREを外部からCALLで呼んでいるのにUSING以降に指定した変数に十分な長さの領域を確保して渡していないと… MOVE時に変数の領域外から読みだそうとして Signal 11が発生することもあります。

2008年07月23日

OpenCOBOLと文字コード

OpenCOBOLがアツイ(´ー`)というか日々OpenCOBOLしてます

OpenCOBOLで日本語を扱いたいという需要もあるんじゃないかと思います。というか結構あります。しかし文字コードは?という問題が(;´Д`)

うちでは、とりあえずShiftJIS使ってます。古くからのCOBOLのコードには結構半角カナが埋まってましてカナ1文字=1byteとして扱ってるコード多いわけです。EUCだと3byteとかになったりしますからPIC句以降を総書き換えになって泣きそうな目にあいます。そして都合がいいことにOpenCOBOL中ではバックスラッシュ(0x5C)は特に特殊な文字としては取り扱われていないため、ShiftJIS全角で漢字を埋めていっても漢字1文字=2byteとしてスムーズに取扱できます。

ただ、他の言語とのやり取りでは結構ややこしくなりますよね(´ー`)ということでiconv周辺使ったりいろいろと画策中です。進捗についてはメールなどでお問い合わせください。 mine (AT) lancard.com OpenCOBOLについて結構おもしろいコードを書き溜めてますよ。特にLinux環境用ですがDB連携とかイロイロ。

OpenCOBOLとtests/run

最近OpenCOBOLへの注目度が高いようですね(´ー`)

OpenCOBOLをコンパイルしてインストール…してる人も増えてきてるかと思いますが、gmpとかncurses入れてない状態で「コンパイルできないよー(;´Д`)」って唸ってる人も多いんじゃないかと思います(入れてください)。

また、OpenCOBOLのインストールに成功してcobc放題してる人もいるかと思いますが…

Use `-mtune=' or '-march=' instead.


のメッセージがいつも表示されちゃってる人も多いんじゃないかと思います。これcobcが内部でgcc呼び出すときに -mcpu というオプション付けてたりするんですが、インストールされているgccのバージョンによっては

`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.


とwarningが出ます。気にしないという手もあるにはありますが、これが出る状態だと tests/run のスクリプトが大量にFAILUREになりますので、cobcが正しく動作しているか不安になります。ということで、-mcpu -march な箇所を -march -mtuneとなるようにパッチをあててから cobcを作成し、testsディレクトリ下のrunスクリプトを実行しますと…


[root@po tests]# ./run
## ------------------------------------ ##
## OpenCOBOL 1.1 test suite: Run Tests. ##
## ------------------------------------ ##
1: DISPLAY literals ok
2: DISPLAY literals, Decimal Point is COMMA ok
3: Hexadecimal literal ok
4: DISPLAY data items with VALUE clause ok
5: DISPLAY data items with MOVE statement ok
6: non-numeric subscript ok
7: The range of subscripts ok
8: Subscript out of bounds (1) ok
9: Subscript out of bounds (2) ok
10: Value of DEPENDING ON N out of bounds (lower)ok
11: Value of DEPENDING ON N out of bounds (upper)ok
12: Subscript bounds with ODO (lower) ok
13: Subscript bounds with ODO (upper) ok
14: Subscript bounds with ODO ok
15: Subscript by arithmetic expression ok
16: Separate sign positions ok

(略)

## ------------- ##
## Test results. ##
## ------------- ##

All 170 tests were successful.


となりますヽ(´ー`)ノめでたしめでたし

2008年06月19日

OpenCOBOLとSCREEN SECTION

OpenCOBOLとSCREEN SECTION(´ー`)

というわけで、OpenCOBOL 1.1、1.0のコード眺めたりしてたんですが、screenio関連に結構ncurses使ったコードが実装されてるんですね。


SCREEN I/O is used or extended ACCEPT/DISPLAY is used
** NOTE - all the following packages are normally part of a Linux/Unix
distribution. Cygwin also has these as installable packages
ALWAYS install the distro packages when available !!
**
o Unix curses (Not Linux/Cygwin/MingW)
or
o Ncurses (libncurses) 5.2 or later
http://www.gnu.org/software/ncurses/ncurses.html

libncurses is used to implement SCREEN SECTION and extended
ACCEPT/DISPLAY.

Ncurses is distributed under a BSD style license.


てなことで、SCREEN SECTIONちょっとだけ試してみようかなって気になりました。しかしヘタに行制御されるとチョット困ることがイロイロ(個人的には)あるんですが(;´Д`)

 OpenCOBOLからの印刷関連で書いてるコードがあるんですが、コード中にエスケープシーケンスを埋め込んでプリンタ(というかPDF生成daemon)の制御やってるので、そのへんにSCREEN SECTION周辺の変化が影響及ぼさないかなあとかなんとか。

 まあ、それはそれでヽ(´ー`)ノこちらのコードを直せば済む話ですが(たぶん)

2008年06月08日

OpenCOBOLを使用したマイグレーション

OpenCOBOLを使用したレガシーマイグレーションについてヽ(´ー`)ノ

 コンサルタントサービスやってもいいかなと思う今日この頃。とりあえずネタ蓄積中。中のコード(コンパイラ、libcob他ライブラリ等)も読んでますんで色々出来ます。SCREEN SECTIONについても工数が少なく済む方法で、結構リッチなクライアント対応など色々アドバイスしたり実作業できたりすると思います。その他MySQLやPostgreSQL他Oracle等DBとの接続、耐障害、いろいろご相談にはのれますおそらく。

 22Uのハーフラックに9台~14台くらい詰めてるのが2本ありまして、imapメールサーバの高負荷対応の実験用に使ってたんですが、最近は高可用性システム向けのネタで実験中です。OpenCOBOL自体のチューニングとかもやりたいところですね。x86に限ればMOVE周辺のコードをガチガチに弄るだけで結構速くなりそうです。ネイティブWin32版とか.net版も検討中(コンパイラ無しで)。

とりあえず困ってる人連絡くださいヽ(´ー`)ノ095-840-0021

2008年05月31日

OpenCOBOLのアレ

とりあえず狙ってたところまで動作確認完了ヽ(´ー`)ノこれは面白い

OpenCOBOL側のSTOP ABOUT.踏むと読んだ側が死ぬ(OpenCOBOL側でexit()呼んでるので)とかいろいろありましたが、アレがarrayに積んだ値をOpenCOBOL側から読み出して変数に設定したり、OpenCOBOL側の変数をアレが読んだりとか結構楽しいものができました。

 詳細はいずれ発表されるでしょうからヽ(´ー`)ノご期待アレ。