HI Folks,
Jerry C. Adams,
Just a note about QS36F data. QS36F is no different from any other
library.The ease of accessing the data depends solely upon whether
or not it is externally defined (SQL-compatible). ....There's
nothing really "strange" about QS36F.
Steven
There is nothing different about the data, per se. It is simple
sequential or ISAM data, without any referential integrity,
relations, editing, field name, etc. built in on a global level.
There is a major difference when programs access the data, compared
to accessing DB2 data
When a smart utility accessed DB2 data, they are accessing the DDS
source (or compiled info returned from the OS), so they have the field layouts.
When QS36F library data is accessed, if it is sequential the
operating system has it defined as one big field, F00001. (As the
result of the initial BLDFILE or FILE, DISP-NEW commands.) The OS
will add the key fields, so perhaps you can have a total of seven
fields defined, something like :
F00001, K00001. F00002. K00002, F00003 K00003, F00004.
(I am guessing that this is how a multi-key-part field looks,
extrapolating from the single key case which I have seen). However,
the RPG programs have internally defined this as maybe 50 or 100
fields. Similarly any F & I spec, IDDU or DDS you have written to
look at the file can show all the fields.
So the utility must be explicitly told not to use the OS data, but to
use either :
1) DDS, IDDU, or F&I
2) data dictionary, e.g. one that is in the utility program
How this is done by various utilities varies. Even native iSeries
utilities like Linoma's Surveyor, Lansa's 4GL and NGS query can use
different methods, but generally they will have a method, solid and
not too difficult, at most some hand-work into their data dictionary.
However, generic SQL lineage systems like Squirrel may or may not
have an easy way to handle this, each case much be examined individually.
Presumably the EGL has a method,
Steven Spencer
Queens, NY
midrange.com
