Part 2 in the series around screen function types will concentrate on the Select Record (SELRCD) function type.
This is often overlooked as a valuable function as it always appears to be generated on your behalf by 2e when you create a file. However, it has a few useful quirks that require a little thinking and I have often seen everly complicated logic added to them due to a lack of understanding where a simple workaround works quite nicely.
Below I summarise some of the key points when using the SELRCD:-
In general there should only be one SELRCD record per file, the default. I propose you rename your default select per for to '*SLT filename'. (See posts on naming standards). However, there may be occasions when it is necessary to select by a variety of different styles, or by a different key value. For example, where the primary key is a surrogate#.
These reasons may justify having more than one selection program, probably built over different ACPs. All other selects other than the default must be name SLT name and not *SLT name. This ensures correct ordering in the file. If using a different access path I would name them 'SLT By access path'.
The *SLT function is named this way as it will be used by the generator when building implicit field prompting code. The routine is also used to validate a record existence in relation checking. (The check restirction within functionaity). As such a default select must be first on the file and also never have its parameter interface changed unless the keys to the file changes.
CA:2E always regards the first SELRCD it finds on the model file as the default. If an alternative SELRCD should always be called for certain relation checks then that should be assigned via the Access Path relation settings. This situation might arise when a file refers to itself. E.g. Horse Refers to Horse for Mare and Horse Refers to Horse for Sire. At the relation level for the access path it is possible to set a default select record for each relation. Therefore the ordering considerations for the generator to substitute a select record are Function Level – Access Path Level – File Level (First on alphabetically on file).
The standard SELRCD should only perform a selection facility. That is, X=Select. However, a display option may be necessary in some cases as is F9 to Add a record.
Selection logic is usually performed one entity level at a time. Therefore if the SELRCD is for a lower level entity, e.g. 'Owned by', then the high order part of the key(s) will normally be RST.
The standard SELRCD should not pass back values other than the selected key. Validation and passing back of attributes is best left to standard RTVOBJ functions since the user may bypass a selection prompt and enter key values directly.
The SELRCD should not be modified to do anything unusual. If a user exits with *Exit key the default SELRCD will always exit program with return code Y2U0016='no value selected' and also send the same completion message. This processing should not be altered.
The parameter key values passed back should have NOERROR set. This is because CA:2E does not treat a 'no value selected' exit (Y2U0016) as an error when called implicitly. But it would be an error if called explicitly in an action diagram.
Closedown option should be set in the context that the program would be called.
These reasons may justify having more than one selection program, probably built over different ACPs. All other selects other than the default must be name SLT name and not *SLT name. This ensures correct ordering in the file. If using a different access path I would name them 'SLT By access path'.
The *SLT function is named this way as it will be used by the generator when building implicit field prompting code. The routine is also used to validate a record existence in relation checking. (The check restirction within functionaity). As such a default select must be first on the file and also never have its parameter interface changed unless the keys to the file changes.
CA:2E always regards the first SELRCD it finds on the model file as the default. If an alternative SELRCD should always be called for certain relation checks then that should be assigned via the Access Path relation settings. This situation might arise when a file refers to itself. E.g. Horse Refers to Horse for Mare and Horse Refers to Horse for Sire. At the relation level for the access path it is possible to set a default select record for each relation. Therefore the ordering considerations for the generator to substitute a select record are Function Level – Access Path Level – File Level (First on alphabetically on file).
The standard SELRCD should only perform a selection facility. That is, X=Select. However, a display option may be necessary in some cases as is F9 to Add a record.
Selection logic is usually performed one entity level at a time. Therefore if the SELRCD is for a lower level entity, e.g. 'Owned by', then the high order part of the key(s) will normally be RST.
The standard SELRCD should not pass back values other than the selected key. Validation and passing back of attributes is best left to standard RTVOBJ functions since the user may bypass a selection prompt and enter key values directly.
The SELRCD should not be modified to do anything unusual. If a user exits with *Exit key the default SELRCD will always exit program with return code Y2U0016='no value selected' and also send the same completion message. This processing should not be altered.
The parameter key values passed back should have NOERROR set. This is because CA:2E does not treat a 'no value selected' exit (Y2U0016) as an error when called implicitly. But it would be an error if called explicitly in an action diagram.
Closedown option should be set in the context that the program would be called.
If a SELRCD is not sufficient because of action diagramming restrictions then a DSPFIL may be used instead. But it should have a naming convention of 'SLT By or filename'. It should follow the same logic that a SELRCD would do, i.e. Same parameter definition and same action diagram style. This is often used if additional processing like F9 = Add is required.
The advantages of the DSPFIL method is it allows increased flexibility. But if you do choose this approach then this function will never implicitly be used and developers need to handle the output parameters. That said you could template this kind of function.
Using a Neither MAP input parameter does allow you to set CTL values for additional filtering.
Thanks for reading.
Lee.
Lee.
