    |
 |
 |
  |
|
|
|
 |
|
| 16. |
Why
can I only have 50 unique files in my Subset? |
50 unique files and 99 links are internal product limits and
represents an optimal compromise between flexibility, useability and
maintainability.
If you encounter the 50 unique file limit it is recommended that
you consider Subsets of smaller dimension. While not entirely unheard
of, it is unusual to find that incorporating so many files leads to a
good Subset.
More usual is that two (perhaps three or four) Subsets will deliver
a more effective reporting environment. End users will find this more
manageable and simpler to use. Maintenance is simplified and
generally, the entire reporting environment becomes more effective and
user friendly.
As a technician designing Subsets, you may think your 50 file
Subset design quite clever. However, if your users have difficulty
grappling with so large a data dictionary, the chances are that they
will not make full use of it and your work , however "well
designed", will not be effective.
|
|
|
|
| 17. |
How
do I change the index key structures in my Subset? |
First you must have exclusive use of the Subset (not only must
there be no other user, but also no reports must be running in batch).
Then press the change function key from the 'Retrieval Map' display
and make the required changes followed by recompiling the existing
reports based on this Subset.
Note: we recommend that you run at least 2 installations of the
report writer server product. You can do this easily by simply
performing a second installation and nominating different library
names. Now you can migrate (EXPORT/IMPORT) Subsets between a
"Production" system and a "Development" system.
Make changes such as this in your Development system. When changes are
complete, you can migrate the new version of your Subset to the
Production system. Working in this way, you will minimize any
interuption to your users in the Production environment.
|
|
|
|
| 18. |
How
do I access the last record of a group of related records on the
target file? |
This requirement can occur in many data bases. For example, where
you have an exchange rate file where currency code and date are the
key fields. In this situation, you may always want the Subset to
select the most recent exchange rate for the currency. You should
define the relationship as one to one and from extended information
(from the "Options" menu) when changing or defining this
link, click on "*LAST" as the response to the prompt for
"Matching records to retrieve".
|
|
|
|
| 19. |
When
adding a file to a Subset, one of the key fields on the source
file was eight bytes long, but its equivalent element on the
target file was ten bytes long. OPEN/DB did not seem to check
this, but the link seems to work ok. Why is this? |
OPEN/DB defines key lists in report programs using fields from the
target file. The key argument values you specify when definining the
link in the Retrieval map are moved into the actual key fields just
prior to the look up.
For numeric fields the RPG (or RPG/ILE) "Z-ADD" (zeroise
and add) operation is used. For character fields, the RPG (or RPG/ILE)
"MOVEL" (move left adjust) operation is used. Thus, OPEN/DB is
only concerned about data types when matching key fields to key
arguments in the retrieval map definition. If your data types are
diffetrent, as can sometimes occur where files are being accessed across
different appliction modules, you will need to use a "key
macro" to define the link. You can read about key macros in the
product documentation and/or you can look at the key macro example
shipped with the product to help you understand how to define your own
key macros.
|
|
|
|
| 20. |
A
twelve character database field actually comprises three
sub-fields. The first four characters are a "Cost Center"
code, the next two are an "Activity" code and the last
six are nominal. Can sorting be done on the "Activity"
sub-field only? |
Yes. The sub-fields should be added to the data dictionary as
derived fields with the original (database) field named as an
"Associated field". The logic for each derived field should
place the appropriate segment of the Associated field into the derived
field. The derived fields can be used for any functional purpose -
just as if they were database fields.
Ideally, being codes, the derived fields will have associated
descriptions available from look-up files. These look-up files can be
built into the Retrieval map definition. Now, when using the new
derived codes, their associated descriptions can be available for
printing to enable greater clarity in your reports.
|
|
|
|
| 21. |
When
and how does OPEN/DB use the OPNQRYF command? |
OPEN/DB will use the OPNQRYF (Open Query File) command to
pre-process select/omit tests before records are presented to the
generated report program. However, it will only do so for select/omit
tests based upon fields from Subset "node" files. Node files
are the Subset based-on-file (BOF) and any link defined as a
one-to-many relationship.
Select/omit tests for fields that come from files linked as
one-to-one, or for derived fields or report work fields do not use
OPNQRYF.
Note that a report may contain select/omit tests using any/all of
the above types of field. OPNQRYF will be used for tests against
database fields from "node" files even when these are not
the only select/omit tests defined for the report.
The advanced capabilities of OPEN/DB in other areas of reporting
means that other features available from OPNQRYF processing are not
appropriate. OPNQRYF is not used for sorting records, joining files,
creating derived fields or any purpose other than record
selection.
OPNQRYF is triggered by pre-compiler commands ($$OPNQRYF FLE=xxxxxxx
etc.) which are constructed dynamically during report execution based
upon SELECT fields in the report definition being identified from the
data dictionary (see: FLDDEF panel #5 under the panel text label,
"Original field detail") as originating from
"this" file. NOTE: fields used in the report definition to
"OMIT" data will not cause OPNQRYF to be used.
Note also that $$OPNQRYF commands are automatically generated into
the skeleton by the Retrieval Map generation (SBSDEF) function for
every "node" file in the Subset.
|
| 22. |
Can you schedule a report to be run at certain times? |
The RPTRUN command resides in your Report Writer Product data library and can be
executed (or submitted for BATCH execution) from your own programs, or
- it can be done using your iSeries
scheduler (see the
operating system command WRKJOBSCDE - Work with Job Schedule
Entries)
- your iSeries may have a specific
product such as Robot Scheduler to facilitate this.
See your iSeries Administrator to set this
up for you.
Like all iSeries commands, RPTRUN can be prompted (using the F4 function key)
either from the iSeries command line or from within SEU when editing Control
Language (CL) program source.
Here is an example of the RPTRUN command:
<your-data-library>/RPTRUN
REPORT(<your-rpt-name>) SELECT(<select-value-1>
<select-value-2> ...)
The RPTRUN command has parameters to control a number of aspects of its execution.
You can cut-and-paste the above example to your iSeries command line then press F4
to prompt the command. If you then press F9, you can explore all its parameters
and read the available help text (press F1, while prompting the command, to see
the help text).
|
| 23. |
What should I be aware of when upgrading the iSeries to V6R1 or
later? |
Momentum
iSeries based report writers (OPEN/DB, MIDAS/Q, Info WorkPlace)
are available for V6R1 and later support with release 8.3. Contact
your supplier for details.
If you upgrade a Report
Writer product, you may still find that there are some programs
that are unable to be converted. These are usually
historic programs no longer in use by the Report Writer and can be
deleted. These may include O#XG3014, O#XG4300, O#XG8175, and
RPTCGI (the actual programs are related to the level you are upgrading from
this time or in the past). RM#nnnnn programs are the compiled
user report programs. You will need to recompile the reports
in the report writer, using the COMPILE option, if they are not
convertible.
Releases of the iSeries report writer earlier than 8.3 will not run
on V61R1 or later and MUST be upgraded before moving to V6R1 or
later.
|
|
|
  |
 |
©
Copyright Momentum Utilities Pty Ltd -
July
2016
Legal Information - Privacy - Contact Us |
