query
trans am kid
36EE (and it runs great). However they have a consultant who is
familar with query and wants to do query and I know that will either
require the files to be defined for such in either DDS or with sql in
DDL.
They are not planning on migrating the code to native in the near
future and so which is the better approach to go with (DDS or SQL) And
what happens when they need to add fields, etc. which does happen on
these files, etc.
I know if you are native, there are level checks, etc. that you can
run into but since this will be done via s/36EE rpg, what sort of
issues and what is the easiest way to get around (and rewriting at
this time is not an option).
So surely someone has some experience with this...
iseriesflorida
What have you done in the past to support this system, has it all been
DDS?? Can you give an example of why you would need to add fields
once your db was designed etc.
trans am kid
"flat files" running under S/36EE. And things are constantly changing,
new fields added, etc. (there is "blank space" in the record).
iseriesflorida
I would probably try to stay the course of what you have unless you
want to convert from the flat file approach to db2 type files etc.
CRPence
> have a situation where they are running on a new i on 6.1 and in
> familiar with query and wants to do query and I know that will
> with sql in DDL.
No such requirement exists to define the files using DDS or SQL
DDL, for use by Query/400. The Query/400 has the same support to
query files as QRY/36 on the S/36; i.e. the definition for the file
that the query feature uses, is the one applied to the file as
created in the IDDU and /linked/ to the file [IDDULINK or the native
command LNKDTADFN].
> They are not planning on migrating the code to native in the near
> future and so which is the better approach to go with (DDS or
> SQL) And what happens when they need to add fields, etc. which
> does happen on these files, etc.
Continue as if on the S/36, by performing activity within the
S/36EE, if the approach intends not to move to native.
> I know if you are native, there are level checks, etc. that you
> can run into but since this will be done via s/36EE rpg, what
> sort of issues and what is the easiest way to get around (and
> rewriting at this time is not an option).
>
> So surely someone has some experience with this...
>
I can not recall how the application of changes to the IDDU file
definitions are manifest in the *QRYDFN object for reference to the
changed file at runtime. I do not recall for example if level check
is an issue. However adding field definitions and shortening the
field from which it was carved-out, is probably not generally too
problematic because the Query/400 feature would require the reports
to explicitly de-select [by not selecting] any /reserved-space/
fields. A unselected field in the report will not affect the
report; i.e. it remains omitted. IIRC the S/36 IDDU and Query/36
had a capability to hide fields that were defined but unused, so a
query that selected all fields by default would actually not _see_
the reserved fields... or something like that... I do not want to
think about it ;-)
Regards, Chuck
Kent Milligan
Web Query - then the data can be left in S/36 files and user-defined table
functions can be written to call the programs that understand how to retrieve
the data from these non-database files.
The following article was written on this exact subject:
http://ibm.com/systems/resources/systems_i_software_db2_pdf_ExternalUDTF.pdf
--
Kent Milligan
ISV Enablement - System i
km...@us.eye-bee-m.com (spam trick) GO HAWKEYES!!
>>> ibm.com/iseries/db2
(opinions stated are not necessarily those of my employer)