Archive for Interviews

CA 2E / Synon Interview Series: Question 6

The understanding of parameter context is a very important area in building 2E functions.  Explain the difference in passing parameters by FLD, RCD or KEY contexts. 

Interview Question 5 Answer

List 2 numeric and 3 alphanumeric field types.

[table "3" not found /]

CA 2E / Synon Interview Series: Question 5

List 2 numeric and 3 alphanumeric field types.

Interview Question 4 Answer

What are the available contexts that you will find in an edit record and what are different contexts used for in the edit record? 
 
  • KEY       Key Screen
  • DTL       Detail Screen
  • DB1       Database File
  • PAR       Parameters
  • PGM      Current Program
  • JOB       Current job information
  • LCL       Local work context
  • WRK      Global work context
  • CND      Conditions
  • CON      Constants

Contexts are an interesting feature of Synon 2E. A context is a way to group fields together.  For example, several fields can be placed in the parameter (PAR) context to send values into or out of a function.  There can also be fields in a function that are placed into the local (LCL) context.  Different contexts are available at different points in the function so it is important to understand where you will need the value assigned to a field.  If you place the field and value in the wrong context you may not have access to the value when you need it.

In order to use a field the field must be defined in the model and it must be placed into a context that is used within a function.

 

CA2E/Synon Interview Series: Question 4

What are the available contexts that you will find in an edit record and what are different contexts used for in the edit record? 

Need more? CM First offers technical training on CA 2E / Synon in a variety of delivery channels – onsite, at one of our offices, or via distance learning.

Interview Question 3 Answer

If you have an edit file built over any file and you restrict on all the keys, how many records will display?

Any time you send in the full file key into a DSPFIL only one record will be found if it exists in the database.   A full key can only have one correct answer.

CA 2E / Synon Interview Series: Question 3

The third question in the 2E Interview Series is:

If you have an edit file built over any file and you restrict on all the keys, how many records will display?

Interview Question 2 Answer

What are the 5 relation types and describe each one?

August Poll Results

TopicResults
General 2E navigation.9%
Create a web page from 2E.27%
Web services in 2E.27%
Triggers in 2E.9%
New features in 2E 8.6.27%

•The ‘Known by’ relation defines a primary key field or identifying key field.  You can have as many of these identifying keys defined as required for a unique record key.
•A ‘Qualified by’ relation is another identifying key field.  These are used in situations where you may have data with the same unique primary keys and an additional qualification of a date or quantity field for instance.  (An effective date or a quantity level break)
•The ‘Has’ relation is a simple attribute
•The ‘Owned by’ relation indicates a parent-child relationship between the two files.  This is an identifying key field and is the key from the parent file (all the identifying key fields).
     •Enforces referential integrity in the database
     •Allows for Virtualization of fields (creating a Join Logical)
     •Provides for automatic code generation of record selection capabilities (F4     or ? processing)
•The ‘Refers to’ relation is also a foreign key stored in the record, but it is not an identifying key field to the record.
     •Enforces referential integrity in the database
     •Allows for Virtualization of fields (creating a Join Logical)
     •Provides for automatic code generation of record selection capabilities (F4 or ? processing
•The ‘Includes’ relation allows you to include a specified group of fields in the file.
     •This group of fields is defined as a structure file
•The ‘Extended by’ relation is a relation intended to signify that a file has additional related data in another file. The extension file must still be entered using the ‘Owned by’ relation.
     •This relation doesn’t add any attributes to the file (by default)
     •Enforces referential integrity in the database (interactive functions will need to be ‘told’ to ignore this validation!)
     •Indicates a one to one file relation.
     •Allows for Virtualization
     •Provides for automatic code generation of record selection capabilities (F4 or ? processing)

CA 2E / Synon Interview Series: Question 2

The second question in the 2E Interview Series is:

What are the 5 relation types and describe each one?

 

Need more? CM First offers technical training on CA 2E / Synon in a variety of delivery channels – onsite, at one of our offices, or via distance learning.

What are the pragmatic differences between REF and CPT files?

When looking at the basic technical differences between REF and CPT files there is not a lot of system differences.  Both of them create physical files and both have logical files.

The difference for the 2E model is in how you generally use these two types of files.

The REF files will primarily be used for master data.  This could include something like a zip code file with names of stores or other files that you use. It refers to relationships when you want to have an editable list of values for a prompted field.  The REF file type will automatically create a SELRCD (Select Record) and an EDTFIL (Edit File) as well as the CRTOBJ (Create Object), CHGOBJ (Change Object) and DLTOBJ (Delete Object).

The CPT file is primarily used for transactional data.  An accounting system is a great example of this.  New records are added on a regular basis.  Capturing these detail records or transactions provide the primary difference about the CPT file vs. the REF file.  Also, the CPT file will only automatically create the CRTOBJ, CHGOBJ and DLTOBJ.

 

 
 
© 2013 CM First Group - All rights reserved