Re: does this logical get the order# -- MIDRANGE-L

On 12-Oct-2015 17:14 -0600, Hoteltravelfundotcom wrote:

our ERP is very very old. this is a logical it holds order notes.
I don't see an actual 'ORDER' field but other reports are using the
customer number to link to this notes file (not shown). I am thinking
that this LF is something I can use for the order? According this
link, SST is substring

Conspicuously missing, was any provided link; the following was added, with the presumption that was the intended URL [and included doc snippet for context]:

[https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rzakb/rzakbmsttdsst.htm]
_SST (Substring) keyword—logical files only_
"You can use this field-level keyword to specify a character string that is a subset of an existing character, hexadecimal, zoned field, or graphic.

The format of the keyword is:

SST(field-name starting-position [length])

The field-name parameter specifies the name of the field from which the substring is taken. This field must be defined in the same logical file format before the SST field (which is the field you are defining) or it must exist in the physical file specified on the PFILE or JFILE keyword. ...
..."

- question is can I use the "ORDER" as a named field in the reporting
tool?

If a field by the name ORDER is included in the Record Format (RCDFMT) of the file that get named to be referenced by the reporting tool, then that reporting tool should have access to that column name.

The following Logical File (LF) DDS source, AFaIK, will not compile, because none of the key fields [other than the first] exists in the record format; i.e. each will give msg CPD7948 "Key, select, or omit field name not found in logical file." in the compiler listing, because the RCDFMT includes only one field. And the field-name ORDER would not exist in that logical file [if indeed the file can be created from that specific source], because the data from the field ORDER is only partially included, and the one field name included is UANOTL; i.e. just like none of the secondary key fields [UARIDC through UANOT#] were included in the record format, neither was the field ORDER, although the first eight bytes of the values of that field will be included.

So "Re: does this logical get the order#", the answer is perhaps and\or somewhat, and the answer depends greatly on the accuracy of what was provided [as the DDS source] and if the first eight bytes of the values for the ORDER field qualify as the "order#" or if only the column name ORDER [and the full physical storage that entails] qualifies as the "order#".

If the reporting tool is SQL-based [or uses the SQL-like tooling capabilities provided by the Classic Query Engine (CQE)], then just refer to the underlying physical file instead of the logical file to gain access to the ORDER column; let the Query Optimizer determine whether or not the keyed Access Path (ACCPTH) of the LF will be used.

LOGICAL FILE - NOTEH10

**************************************************************

R NOTEHDRR PFILE(NOTEHDUA)

UANOTL I SST(ORDER 1 8)
K UANOTL R
K UARIDC R
K UATMPC R
K UAFLWD R DESCEND
K UANOTT R
K UANTK R
K UANOT# R

I am unsure why the DDS compiler for LF does not diagnose the 'R' in position-29 as an error. See:

[https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzakb/pfrefer.htm]
IBM i 7.2 ->Programming ->DDS ->DDS for physical and logical files ->Defining physical and logical files using DDS ->Positional entries for physical and logical files (positions 1 through 44) ->Reference for physical and logical files (position 29)

_Reference for physical and logical files_ (position 29)
"You use this position to specify reference for physical files only.

For a logical file, leave this position blank. All logical files automatically provide the reference capability for all specified fields. Any attributes that are not specified explicitly in the logical file are furnished from the corresponding field in the physical file record format.
..."