EnterpriseServer では STRHTPDBG というコマンドが提供されており、ILE-RPG であれば通常のRPG と同じように RPG ソースを見ながらの対話式ディバッグを行うことができます。

またeStudio上でも対話式ディバッグを行うことができます。

RPGIIIでの開発は終了しました。

現在検討中です。

各地に既に EnterpriseServer による開発に精通している ソフトウェア・ハウス をご紹介することができます。 ただし費用に関しましては個々の ソフトウェア・ハウス までご相談ください。

再コンパイルの必要はありません。

Ver4.0 からすべての旧リリース・バージョンで作成された CGI も再コンパイルすることなくそのままで動作します。 しかも再コンパイルしなくてもリリース・アップによる高速化などの恩恵は受けることができます。 新しいバージョンでの機能を使いたいときに初めて RPGエンジンを入れ替えるようにしてください。 新しいリリースでの RPGエンジンのプロシージャーは同じ名前を使用することができます。

また同じ名前のプロシージャーであっても新しいリリースのプロシージャーではパラメータが拡張されている場合がありますが、基本的に拡張された(追加された）パラメータは省略可能なプロシージャーとして定義されますので、ソースを修正することなく、バインドする RPGエンジンを入れ替えるだけで、正常にコンパイルを行うことができます。 今後もこの方針に変わることはなく、つねに上位互換が保証されます。

できません。

以前のバージョンと切り替えての動作確認をされたい場合はライブラリー ASNET.COM の名前を切り替えてご使用ください。

HTTP サーバー Alaska では本稼動用のインスタンス 「ALASKA」とは別にプログラマー用のインスタンス「PGMR」を起動させることができます。

このインスタンス PGMR は Alaska の PORT=80 とは別の PORT=3009 として起動します。 それぞれ内部で起動しているのは同じ HTTPサーバー Alaska なのですが PORT が異なるために独立した別々のインスタンスとして異なる環境下での HTTPサーバーとして稼動します。 このため開発中の CGI が誤動作などによって暴走したとしても本稼動中の適用業務に与える影響は最小限のもので済みます。

年間 480,000 円での導入および開発支援サービスが用意されていますのでお申し込みになることをお奨め致します。 保守契約だけですと製品そのものの使用方法についてのみの Q & A になりますが、導入および開発支援サービスですと個別の案件についてのご相談も可能となります。

これは多くのユーザーさまからのご依頼によって始めたサービスであり、今ではほとんどのユーザー様がお申し込みになっております。

いいえ。特殊な開発言語を新たに学習する必要はありません。
IBM System i は、本来、RPG や COBOL によって開発することができるように設計されていますので、
EnterpriseServer でも RPG や COBOL によってWeb適用業務を開発することができます。
ただしブラウザ上で使用するJavaScript に関しては、やはり学習が必要となります。
IBM System i には数百万件のデータ・ベースへでも一瞬のうちにアクセスできる
RPG という高級言語が用意されているのに、PHP や Delphi を敢えて学習して使用しなければ
ならない理由はどこにもありません。
特殊な開発言語を勉強してください、というのは売り手側の論理なだけです。

一番、特徴的であるのは RPG# はイベント駆動型のソース記述であり、
メイン・ルーチンが無いことです。
RPG# では「あるボタンを押した」とか「画像をクリックした」のようなエンド・ユーザーによる
操作をイベントとして捉えて、そのイベントを処理するだけのプロシージャーと呼ばれる、
処理を記述していくことになります。
これは VisualBASIC や Visual C++, C# などのオープン系の言語の処理体系と全く同じです。
過去にオープン系の開発言語を学習したことのある経験をお持ちの方であれば
非常にわかりやすい言語処理の構造である、といえます。
従来のILE-RPG では必ずメイン・ルーチンが存在していましたが、ボタンやコンボボックスのような
多くのGUIコントロールを制御するようになると、メイン・ルーチンのあるプログラムでは
ソースは非常に見難く複雑なものになってしまいます。
BASIC や C++ も、元々はメイン・ルーチンがありましたが GUI コントロールを制御するようになって
メイン・ルーチンのない、イベント駆動型の Visual BASIC や Visual C++ と進化したように、
RPG もまたイベント駆動の RPG# へと進化する必要があったのです。
�潟Iフィスクアトロではお客様のアイデアと、いち早くこのことに気づいてイベント駆動型の
RPG# を開発するに至りました。
はじめて Web開発されるのであれば、是非、RPG# による開発をご検討ください。

PHP は、PHP の中に結果としての HTML も混在しています。
つまりビジネス・ロジックとビューが混合されているのが、PHP です。
JSP & Servlet は ビューであるJSP とビジネス・ロジックである Servlet と分離されていますので
ある程度、編集作業には向いていますが PHP の場合は、ビューとロジックが完全に入り乱れて
混在しており、これは MVC 3 階層モデルが求められる現代において、後退であると言わざるを得ません。
PHP で開発された Webアプリは HTML デザインやJavaScript に相当、経験のある方で
PHP に習熱している方でないと、開発や修正を行うことはできません。
PHP がオープン系で普及したのは C言語による開発よりは、開発効率がよい、というだけに過ぎません。
また PHP ではデータ・ベースのアクセスは SQL ですので、当然パフォーマンスは悪くなります。

PHP に対して RPG# であれば、

　　・HTMLテンプレートと RPG# ビジネス・ロジックの完全分離
　　・レコード・レベルの超高速データ・ベースへのアクセス

を可能にします。
HTML と RPG# は完全に分離されていますので、HTML だけをデザイナーに渡して編集することも
できますし、HTMLテンプレートは出力結果として、いつでもブラウザ上で表示することができます。
( PHP は、完成しないと表示することはできません。)
データ・ベースへのアクセスはレコード・レベルで数百万件へのデータ・ベースでも
一瞬のうちに任意のレコードを取り出すことができます。

大量のデータを表示する場合は、それに見合ったリソースが必要となりますが
SQL ( ODBC, JDBC ) によるデータ・アクセスのようなパフォーマンス低下はありません。
PHP, JSP & Servlet やこれらの類似するような ODBC によるデータ・ベースへアクセスするような
製品であれば ODBC によるアクセス・パスに作成のために、相当な時間が待たされることに
なってしまいます。
xxxxx/400 という名前の製品は一般的に System i に特化して開発されたものではなく、
Windows を始めとするオープン系で開発された製品である場合がほとんどです。
従って System i の DB2/400 データ・ベースへのアクセスも ODBC を使うことになります。
PHP も動作原理は同じであり、ODBC によってデータ・ベースをアクセスします。
ODBC の場合は、例えば 30 万件のデータ・ベースに、たった一件のレコードを追加する場合であっても
30 万件のデータ・ベースを読み取って、キーの重複がないことを検査してから、初めてレコードを
追加する動作を行なっています。
これではパフォーマンスが悪いことは、明らかです。
EnterpriseServer であれば RPG の WRITE 命令で、瞬時のうちにレコードが追加されるのは
ご存知のとおりです。
ODBC を使っている製品ではパフォーマンスが悪いことは問題になります。
EnterpriseServer であればレコートー・レベルの更新ですので System i の最高のパフォーマンスを
引き出すことができます。

できます。
携帯は、元々 HTML の小さなサイズのものと思って頂ければ問題ありません。
ただし 携帯のメーカーや種類によっては、JavaScript 等の制約はありますのでご注意ください。
iPhone, iPad, タブレットもブラウザがMS-IE とは、異なるという点で十分に注意して開発して頂ければ
EnterpriseServer 製品に係わる制約はありませんので安心してご利用頂くことができます。

できます。
RPGエンジン( *SRVPGM ) には MOBILEプロシージャーと呼ばれる携帯のメーカーと種別を
判別することができる、プロシージャーが提供されていますので、これを利用して頂ければ
ご希望の画像処理を制御することができるようになります。

最も簡単に認証する仕組みを作るのであれば Basic 認証を利用することをお奨めします。
EnterpriseServer では、System i に登録済みのユーザー・プロフィールによるBasic 認証を
利用することができます。
Alaska に対して IPアドレスだけをブラウザで要求すると、Basic 認証ダイアログが
ブラウザに表示されます。

このBasic認証ダイアログに対して、あなたの System i に登録済みのユーザー、パスワードを入力すると、
そのユーザー・プロフィールの「ホーム・ディレトクリー」にある index.html が表示されるようになっています。
この方法によってセキュリティに堅牢な IBM System i のユーザー管理システムによる
ユーザー認証を構築することができます。

また、特定の IFS ディレクトリーには認証を要求するように設定することもできます。
重要なディレトクリーには認証を要求するようにしておけば、不用意なアクセスから守ることができます。

さらに System i をWebサーバーとして利用することの利点は、
ディレクトリーだけでなくIFS のストリーム・ファイルにさえ、

　　　*RX = READONLY, *WX = WRITE, *RWX = READ AND READ, *EXCLUDE = , ....

のような細かな権限を設定することができることです。
Alaska では、これらの権限を設定して利用することができます。

できます。
フォーム認証を利用する利点は、Basic認証にはない、自由なデザインができることです。
認証ダイアログや認証画面ユーザーの事情に応じて、自由にデザインすることができます。
また AutoWeb を利用される場合には、クライアントの装置名を登録して利用することができます。
装置名は Cookie に最初だけ登録され、以降は参照して利用することができます。
装置名を利用することによって、5250 エミュレータの場合と同じように
装置名によってブリンターを割り振ったり、データ・ベースに更新した装置名を登録することもできます。

XML に関しては次の機能があります。

　　・XML の出力 ........ SENDXML プロシージャー : XML をブラウザに送信します。
　　・XML の入力 ........ XML パーサー: XML を DOMデータ・ベースに展開します。

　【解説】
　　　XML のブラウザへの出力では XML で考慮すべき禁則文字のエンコードなどの処理の
　　　入った SENDXML プロシージャーを使って安全に XML をブラウザへ送信することができます。
　　　XML の送信は Ajax のような高度な Webアプリケーションの開発に役立ちます。

　　　また、XML を入力して解析するために、RPG プログラマーのための
　　　XMLパーサーが用意されています。
　　　XMLパーサーとは XML の内容を DOM データ・ベースに展開するツールのことです。
　　　展開される DOM データ・ベースは RPG プログラマーであれば、どなたでも
　　　容易に理解できる簡単なデータ・ベースです。
　　　簡単な DOM データ・ベースであるため、DOM の操作のメソッドを覚えるまでもありません。
　　　SETLL & READ 命令だけで自由に RPG でXML を読み取ることができます。

　【参考】　CPYTOXML と CPYFRMXML コマンド
　　　XML と DB2/400 データ・ベースの互換のためのコマンドとして
　　　CPYTOXML と CPYFRMXML という2つのコマンドが用意されています。
　　　これらのコマンドを利用すればプログラムを開発することなく、
　　　データ・ベースを自由に XML に変換することができますし、
　　　その逆も行なうことができます。

できます。
CPYTOCSV と CPYFRMCSV という2つのコマンドが用意されており、
これらのコマンドを利用すればプログラムを開発することなく、
データ・ベースを自由に CSV に変換することができますし、その逆も行なうことができます。
使用方法はとても簡単で CPYF コマンドとほぼ同じであり、
CPYF コマンドと同じようにコピーするレコード数の設定やレコードの抽出も自由に設定することができます。

できます。
一般に HTML だけでは、横棒グラフ程度のグラフしか表示することはできませんが
VML ( Vector Markup Language ) と Ajax を組み合わせることによって
円グラフ、 折れ線グラフ、 縦棒グラフ等を自由に作ることができます。

ただし他社製品となると、実はグラフ表示ができない製品が多いのも事実です。
これはネィティブな HTML を出力するのではなく、かなりの加工の後で HTMLを
出力するため、グラフとなると、ほとんど実務上、不可能となってしまうためです。
また Ajax を使うことができないのも他社製品の制約に多く見受けられます。

できます。
CGI での出力ストリームの中で画像の位置を示すHTMLタグを埋め込むだけです。
例えば、

　　<IMG SRC="/AS400-NET.USR/IMAGE/AUTOWEB.GIF">

というイメージ・タグ(<IMG SRC=) は IFS の /AS400-NET.USR/IMAGE/AUTOWEB.GIF という
画像の表示を指示しています。
このような HTML タグをCGI で動的に出力するだけで任意の画像を出力することができます。
ご参考までに、画像は別の社内サーバーにあっても構いません。
HTML コンテンツは、System i から出力しても、画像は別のサーバーからのものを
取り出して表示することもできます。
( ただしこの場合は、そのサーバーにも HTTPサーバーが起動されていることが必要です。)

可能です。
データ・ベースを読み取ったら プロシージャー ADDCOMBO によって候補を追加するだけの
簡単な作業で済みます。

　【例 】 品種マスター(HINSHU) を読み取ってコンボボックスを作成する。

     FHINSHU    IF   E           K DISK    EXTFILE(HINSHU_LIB) 
        :
     C     SETKEY        SETLL     HINSHU                                      
     C     1             DO        MAXGYO        RECORD                   
     C                   READ      HINSHU                                 50   
     C   50              LEAVE                                                 
     C*( コンボボックスにデータを追加 )                                        
     C                   CALLP     ADDCOMBO('HNSCOD':HNSCOD:HNSNAM)            
     C                   ENDDO                                                 
     C*( HTML  の出力 )                                                        
     C                   CALLP     WRITE                                       

できます。
アップロードのためのサンプルを用意していますので、ご参考になさってください。
ただし機密保護と安全のため Basic 認証を必ずご利用ください。
認証のないアップロードは保護のため、受け付けられないようになっています。
Excel ブックも System i の IFS に場所を指定してアップロードすることができます。

できます。
Excel ブックを IFS に配置して、それを指定するだけで済みます。
RPG や COBOL で Excel ブックに入出力できる機能も POI と呼ばれるサービス・プログラム
として提供されています。( 別途有償 )

可能です。
Chicago の POI と呼ばれる追加モジュールを利用すると
RPG プログラムによって、Excel ブックへの入出力を行なうことができます。
POI を使えば、Excel ブックのセル値を更新したり読み取るだけでなく、
セルの文字カラーや背景色も好みの色に設定することもできます。
このPOI は、Apache で有名な Jakarta プロジェクトの中で公開されている POI を
�潟Iフィスクアトロが独自に必要な部分を C/400 で書き直したものです。

JavaScript は基本的にどなたでも短時間で学習できる簡単なスクリプト言語です。
EnterpriseServer のヘルプ( オンライン・マニュアル )には JavaScript 解説書や
チュートリアル (自習書)にも、詳しい JavaScript の解説があります。
JavaScript は、いきなり体系立って学習するというよりは、必要が発生したときに
初めて、その部分についてのみ学習する、という程度で十分です。
一般の Web開発者でも、すべての JavaScript の機能に精通している人は少ないはずです。
JavaScript のすべてを学習しないと、Web開発ができない、と考えるよりは
必要になったら、その都度学習すればよい、という程度で気楽に考えてよいでしょう。
何故、JavaScript の学習が必要であるか ? というと、今まで 5250エミュレータを
使っていた場合には、数字フィールドは数字しか入力できないように 5250 エミュレータが
プログラマーに代わって妥当性検査を行なってくれていました。
ところが Webの場合は HTML からの入力は基本的には数字であっても文字であっても入力されてしまいます。
このようなときに5250エミュレータに代わる妥当性検査を JavaScript によって行なう必要があります。
そこで Web化を行なうときには RPGプログラマーも JavaScript の学習を行なう必要がありました。
最近ではさらに進んで Ajax と呼ばれる JavaScript による画面の動的な制御や変化は
Webの世界では当然のことであり、ユーザビリティの向上やグラフの表示にも JavaScript は
必須となってきています。
JavaScript を学習することは、あなたの開発範囲を大きく向上させることに役立ち、
エンド・ユーザーの満足を勝ち得ることは間違いありません。