Pythonで DSPF(=表示装置ファイル)をインターフェースとする
5250アプリケーションを開発することができます。
単票型アプリケーションの事例
SFLレコード型アプリケーションの事例
import sys
from as400 import *
CallType(sys.argv[1])
Open("QTROBJ/@SHOINQ", "DSPF") # 表示装置ファイルをオープン
Open("QTRFIL/SHOHIN", "FILE") # 商品マスターファイル
Open("QTRFIL/HINSHU", "FILE") # 品種マスターファイル
while True:
DSPHEAD.Exfmt()
DSPHEAD.SHCODE.SetLL(SHOHIN)
SFCTL = 'SFCTL01'
DSPEND = 'DSPEND01'
while True:
ENDRRN = TOPRRN + SFLPAG - 1
for RRN1 in range(TOPRRN, ENDRRN + 1):
if SHOHIN.Read() == EOF:
break
SFREC01.SHCODE = SHOHINR.SHCODE
SFREC01.SHNAME = SHOHINR.SHNAME
SFREC01.SHTANK = SHOHINR.SHTANK
SFREC01.SHSCOD = SHOHINR.SHSCOD
SHOHINR.SHSCOD.Chain(HINSHU) # 品種マスターファイル
SFREC01.HNSNAM = HINSHUR.HNSNAM
SFREC01.SFLWrite(RRN1)
DSPEND01.Write()
SFCTL01.Exfmt() # SFL コントロール/レコードを表示
わずか25行の短いソースです。
これは商品マスター(QTRFIL/SHOHIN)を読み取って
SFLレコードに一覧表形式で表示するPythonアプリケーションの例です。
DSPHEAD.Exfmt() で初期画面を読み取って
DSPHEAD.SHCODE.SetLL(SHOHIN)
で商品マスターにキーをセットして(SetLL)
while True:で繰り返し
if SHOHIN.Read() == EOF: でEOF(=End Of File)になるまで
break 商品レコードを読み取って
SFREC01.SHCODE = SHOHINR.SHCODE のようにしてサブ・ファイル・レコード(SFREC01)に
: 商品マスター・レコード(SHOHINR)の商品コード(SHCODE)などを
: 次々と埋め込んで
SFREC01.SFLWrite(RRN1)でサブ・ファイル・レコードSFREC01を出力(SFLWrite)します。
SFCTL01.Exfmt() でサブ・ファイル・コントロールを出力して終了する。
出力標識のセットは必要ありません。
しかも実行する演算命令はRPG入出力を模したものではなく
実際にILE-RPGが実行しているものと同じAPIを使用して入出力を行います。
だから信頼性高く安全にレコード・レベルの更新をPythonで実現することができます。
数百万レコードの大量データ・ベースの中からRPG命令と同じように瞬時に求めるレコードを
インタブリタのPythonで取り出すことができます。
Python.400が提供するAS400エンジン(*SRVPGM)はプログラマーに
代わって多くのことを代行して行います。
例えば
SFLCTL01.Exfmt()
と書くだけでExfmtの中では
F3=終了
F12=前画面
ROLL UP/DOWN
の処理がプログラマーに代わって代行して実行されます。
多くの RPGプログラマーでも苦手な ROLL UP/DOWN処理を行うので高い品質のプログラムが
少ないソースで実現することができます。
例えば F3=終了はSAAの基準で定められておりほとんどの場合がF3=終了を記述しなければならないのに
毎回、義務のように繰り返し同じことを記述していたのです。
Python.400ではこのような無駄をなくして内部処理としました。
これがPython.400の代行処理です。
今までのRPG/COBOLでは
何でもできるが何でもすべて自分でやらなければいけない。
ということだったのです。
もちろん代行処理に任せるのではなく明示的にコーディングすれば
それが優先されて実行されます。
代行処理の導入によってプログラマーは
実行する本質の機能だけを書けばよい
少ないソースで見やすくバグの少ない高品質のプログラムが可能
初心者でも実用的なプログラムの開発が可能
という利点に恵まれます。
Python.400の記述では従来のRPG/COBOLによる記述をそのまま踏襲するのではなく 最新のオープン系開発言語としてオブジェクト指向にシフトしています。
RPGも間接的でわかりにくくしていたキー・リストを廃止して直接的な記述ができるようにしました。
他の人が見てもひと目で演算の内容を理解できるソースになります。
URKING = SURYO * TANKA
このようなフィールド名だけの記述の演算ではどのファイルに対してどのような処理をしているのか全くわかりません。
URIRCDR.URKING = DSPDTA.SURYO * DSPDTA.TANKA
キー・リストもRPGの理解を難しくしていた要素のひとつです。
キー・リストを無くして直観的な記述でわかりやすくなりました。
古典的なRPGによるキー・リストの例
KYLIST KLIST
KFLD JUCNO
KFLD JUGYO
:
KYLIST CHAIN FILE 99
キー・リストの記述と CHAIN演算は離れたところに
記述されているため見比べて確認しなければなりませんでした。
そのため CHAIN命令を見ただけではくわしい処理はわかりませんでした。
これは CHAIN命令の演算項目1をひとつのフィールド名として
処理したいためにIBMはキー・リストを作ったのだと思われます。
プログラマーが便利になるためではなかったのです。
キー・リストを廃止してわかりやすくなったPythonソース(SFREC01.JUCNO + SFREC01.GYO) Chain(FILE)
このように キーリストを使わずに直接、キーの内容を記述すれば 処理の内容が直観的によくわかるようになりました。
Pythonプログラマーが自然に理解できるようなソースになります。
RPG命令を継承しつつも古典的でわかりにくかったRPG/COBOLの記述をオブジェクト指向の
直観的でわかりやすい Pythonソースに進化させました。
ソースを見るだけでどなたでも直観的に処理の内容を正確に理解することができるようになりました。
これがオープン化する最大の利点です。