Open topic with navigation
The comments below specify the scope of each field.
namespace ns1 class class1 ab ,a10 ;Valid within the class subroutine sub1 record ac ,d2 ;Valid within the subroutine proc begin data ad ,i4 ;Valid within the BEGIN-END block end xreturn endsubroutine endclass endnamespace
Access to a structure and all of its members declared within a routine are limited to the scope of the routine in which it was declared.
Constant data is not modified at all during program execution. It is defined with the LITERAL statement or by the class READONLY or CONST field modifiers.
Local data is specific to a routine. It can be defined within a RECORD statement that is not part of a GLOBAL‑ENDGLOBAL block or in a subroutine or function that is declared outside of a class. The LOCAL and STATIC qualifiers on the RECORD, FUNCTION, and SUBROUTINE statements can also designate data as local. See the RECORD‑ENDRECORD Discussion for a more thorough discussion of LOCAL and STATIC.
The lifetime of local data is determined by the lifetime of the routine, and the data goes out of scope when the routine ends.
Instance data is tied to an object variable. When you instantiate an object, it creates data and assigns a reference of that newly created object to an instance variable. Once there are no more references, either because the variable was explicitly cleared or because it went out of scope, the instance is destroyed and the data goes away.
An instance variable is specific to the block in which it is defined. The DATA statement is one way to define instance variables. The lifetime of an instance variable is determined by the block in which the object variable is declared. When the block ends, the variable goes out of scope.
All class instance data operates the same as if the ‑qcheck compiler option was specified. Class instance data cannot be subscripted, nor can arrays be accessed beyond their bounds for any class instance data. This is also true for local DATA statement variables.
Global data remains resident in memory for as long as the program is running. It is defined in a global data section, in a COMMON statement, or as static class data (in other words, as a field within a class that has the STATIC qualifier). Static class data is shared by all instances of the class.
The compiler resolves identifiers in the order given below. (For resolution purposes, two identifiers are considered the same if they are identical after being lowercased.)
Because functions can be called without a % character (and in traditional Synergy, subroutines can be called without “XCALL”), it’s especially important to understand how the compiler resolves identifiers used in the procedure division that are not also the name of a Synergy statement. Note that if the identifier is preceded by a % character, the compiler restricts its search to only look for a function. Similarly, if the identifier is preceded by “XCALL,” the compiler only searches for a subroutine.
Memory can be managed either statically or dynamically. Static memory is persistent throughout the life of the program. A static record’s data is only initialized when the program is started.
Dynamic memory management is the allocation, usage, and deallocation of memory that is controlled at execution time, rather than compile time. The elements of the language that support dynamic memory are
Synergy DBL supports memory access mechanisms using the “handle” concept. A memory handle is an integer identifier that the Synergy runtime associates with a given memory segment. It is to be used whenever that memory segment is referenced.
A memory handle is either volatile (dynamic) or static. Volatile memory handles remain valid until one of the following is true:
Static memory handles are “persistent” and remain valid until one of the following is true:
A memory handle is essentially an index into an access array that is maintained by the runtime. A positive value is a one‑based index into the static handle array, while a negative value is a negative one‑based index into the volatile handle array. Any given memory handle can be stored in whatever numeric Synergy DBL field can represent that handle’s value (although we strongly recommend an aligned i4 field).
Note that we refer to operations in terms of memory handles, not memory (for example, “generate a memory handle,” “release a memory handle,” and so forth). We do so because, even though all memory handles have a memory segment associated with them, different operations can occur for a given memory handle function depending on the class of its associated memory. For example, releasing a memory handle associated with a Synergy DBL window’s user data set does not “free” its user data set’s memory.