There is an online demonstration screen which uses MAGDATE. It allows you to enter into the various request area fields (cont.)
from your keyboard and to see the results immediately. This can be useful in learning how to use MAGDATE. It can also (cont.)
be used to convert or project dates for whatever purpose you might desire.
The online MAGDATE demonstration can be invoked using the function code: **DATE
No key value is required, you will be able to type into the labelled screen fields which correspond to the request area (cont.)
fields. This is a fast way to learn how to use MAGDATE and to see exactly how all of the date information is returned (cont.)
from MAGDATE.
## 
Leap Years
In validating and converting dates MAGDATE is cognizant of the fact that leap years are 366 days long and that leap (cont.)
years are years which are divisible by four, except that years which are also divisible by one-hundred are not leap (cont.)
years unless they are divisible by four-hundred. The year 2000 is a leap year, but the years 1900, 2100, 2200, and 2300 (cont.)
are not.
*Note: When a 2-digit year format is given with a year of 50 or greater, MAGDATE assumes that the date is a 19xx year; (cont.)
if the year is less than 50 it assumes it is a 20xx year.* We strongly recommend clients to *always* use a 4-digit year (cont.)
to avoid confusion!**
## 
Day-of-Week Codes
The day-of-week codes in all cases are values from 1 through 7, where 1 = Sunday, 2 = Monday, 7 = Saturday, et cetera.
# 
Appendix P -- Referencing Screen Fields
## 
Screen Field Names
The Mask copybook which MAGEC generates for your screen Mask includes definitions for all your screen fields plus (cont.)
definitions for all the necessary control fields associated with them. For each field (assuming a screen field named (cont.)
"Sfield") it includes:
Sfield
             
the actual screen field
SfieldA
             
the 3270 attribute byte
SfieldE
             
the field's error flag
Sfield-POSN
             
the field's position on the screen
For numeric edit-type fields:
Sfield-N
             
numeric value of contents of Sfield
Sfield-ED
             
Cobol edit pattern for Sfield
For date edit-type fields:
Sfield-DAY-OF-WEEK
             
Sunday=1, Saturday=7, etc.
Sfield-JULIAN-DATE
             
Julian equivalent of entered date
For color-controlled fields:
Sfield-COLOR
             
color code
SfieldH
             
extended highlighting code
You can reference any of these control fields in your MMP. Your MMP's automatically have symbolic names defined for all the valid colors and extended highlighting options. They are:
Colors:
DEFAULT-COLOR
 
BLUE
 
RED
 
PINK
 
GREEN
 
TURQUOISE
 
YELLOW
 
WHITE
 
BLACK
 
Highlighting:
NO-HILITE
 
UNDERLINE
 
BLINK
 
REVERSE-VIDEO
 
## 
Symbolic Screen Field References
When you are coding customization logic for your MMP's, you will usually be more familiar with the database field (DIT) (cont.)
datanames than with the screen field (MSK) datanames. For that reason, you may prefer to utilize MAGEC's **Symbolic (cont.)
Screen Field Referencing** feature which is described in detail in the "Database Administration" chapter of the (cont.)
"Programmer's Reference Guide.
Briefly, it enables you to use the database name to indirectly access screen fields. The mapping of database names to (cont.)
screen field names is controlled by the associations defined in the screen's Mask definition. The associations are (cont.)
defined using the "Source/Target" specifications for screen fields.
Assuming that you had a screen field named SAMOUNT with a source/target named CUS01-AMOUNT, you could code:
MOVE +10.00 TO @CUS01-AMOUNT@-N @CUS01-AMOUNT@-ED
MOVE RED TO @CUS01-AMOUNT@-COLOR
rather than having to look up the screen field name (SAMOUNT) in order to access it.
MAGEC will, as the program is being generated, translate the symbolic references into the proper Cobol datanames. You (cont.)
can append any of the appropriate suffixes to the symbolic reference, as shown above. Assuming that the screen field (cont.)
having CUS01-AMOUNT as its source/target is named SAMOUNT, the above coding would translate into:
MOVE +10.00 TO SAMOUNT-N SAMOUNT-ED
MOVE RED TO SAMOUNT-COLOR
Symbolic references are a good way to access screen fields in routines which are to be stored as copybooks to be (cont.)
included into many programs. This way you are not concerned with knowing the datanames used for screen fields in (cont.)
several places, your coding becomes more "portable".
**
NOTE:
**
You should read the topic, *Symbolic Screen Field References* in the "Database Administration" chapter before coding (cont.)
symbolic references. This feature was provided primarily for the coding of Business Rules and Referential Integrity (cont.)
Rules, however, it is also available to Application Developers.
# 
Appendix Q -- SQL
## 
SQLCRE Function
In order to generate MMP's which access an SQL database, such as DB2, you must provide customization coding (using SQL) (cont.)
to replace the default I/O routines. You could do this manually, or you can have MAGEC generate the necessary (cont.)
customization coding automatically. The automatic generation process is online and involves only a single online (cont.)
command:
SQLCRE nnn
where nnn is the Mask# (SHD number) of the application for which you wish SQL accesses generated.
The SQLCRE function will automatically generate customization for all of the I/O insertion points. They are:
%ADDIT
**%DELET
%LOCKY
%REDNX
%RDUKY
%REDKY
%UPDAT
%RELES
and for two other insertion points where it is necessary to define the host variables and to move them to and from the standard MAGEC data definition copybook. The two other insertion points are:
%LITERAL
%SUBRTNM
The customization will be added to the dictionary with names which include modifiers to identify them as generated (cont.)
code. The modifiers will all be "MAGECSQL". For example, for application 600 there would be customization generated (cont.)
as:
600/ADDIT/MAGECSQL
600/REDKY/MAGECSQL
et cetera
If you modify these generated routines you should be aware that re-executing the SQLCRE command will overlay your modifications with newly generated, unmodified routines.
The generated code assumes that there is a member defining the host variables for each Element accessed stored on the MAGEC library. The member must have a name of
eeeee-c/SQL
where eeeee is the element name. Such a host variable definition library member will be generated by the DITGEN (cont.)
function (see the *Data Definition* tutorial) automatically, if the Data Class has an access method of SQL or DB2 (cont.)
specified.
If you have generated an application for SQL and wish to revert it back to VSAM, or some other access method, you must (cont.)
remove all of the SQL customization. This allows the application to be re-generated using the default logic which (cont.)
accesses the MAGEC I/O module.
To remove the SQL customization, you could either manually delete it piece-by-piece; or you could use the SQLPUR (SQL Purge) function to remove all of it in one fell swoop. The format is:
SQLPUR nnn
where nnn is the applications's Mask number, as before. Any modifications you nave made to the generated SQL routines (cont.)
will be deleted along with the routines since the SQLPUR function erases all customization code for the specified (cont.)
application which has a modifier of MAGECSQL.
The generated SQL customization is for the Primary Data Class only. The Primary Data Class may be a single table or it (cont.)
may be a view, joining several tables. Restrictions of your database management system may prevent updates or deletes (cont.)
whcn accessing a joined view, rather than a simple table.
If you wish, you can do standard MAGEC joins of multiple tables, thereby circumventing the database management system's (cont.)
restrictions against updating joined views. To do that you would code SQL accesses to other tables in the standard (cont.)
%JOIN insertion point, or elsewhere in the MMP's logic. MAGEC will not automatically generate such accesses; however, (cont.)
the built-in Named Proforma facility will help you quite a lot since it contains all the SQL command formats pre-coded (cont.)
for you.
SQLPUR will not purge any customization except for that which has the MAGECSQL modifier, and is in the designated (cont.)
insertion points (listed earlier). Your manually added SQL code in other insertion points (such as %JOIN), or with any (cont.)
other modifiers, will not be purged!
# 
Appendix R -- Attach / Detach
## 
Purpose for this Facilty
As of release 2.6, MAGEC has added the Attach/Detach facility which provides a standardized technique for coding (cont.)
"nested" screens. Nested screens are simply a sequence of screens wherein the operator can be entering into one screen (cont.)
and can "pop-up" another screen and then return to the first screen with all data as it was left and with the ability (cont.)
to pass information from one to another.
Some people would use the nomenclature "push/pop stack", or "call/return", to describe MAGEC's Attach/Detach facility. (cont.)
The name "Attach/Detach" is intended to avoid confusion with any other existing facility of CICS or other environmental (cont.)
software.
An Attach is a call from one transaction to invoke another transaction, retaining all data necessary to enable the lower-level transaction to Detach, or to return to the calling transaction.
This facility supports multiple levels of nesting. The Attach function preserves TWA data, file positioning, and screen (cont.)
data for the transaction so that control is passed back to it in the same status as it was left. The transactions are (cont.)
also able to pass data back and forth.
The Attach/Detach facility is particularly beneficial when used in conjunction with the MODELWIN feature which (cont.)
generates pop-up windows applications. A full-screen application can easily Attach to a pop-up window application which (cont.)
can perform any number of processes, then Detach back to the full-screen application which invoked (cont.)
it.
Rather than using the FTH-FUNCT (Fetch Function) command, which would require the programmer to save and restore TWA (cont.)
data for each task, using Attach/Detach automatically saves and restores the TWA as appropriate and supports passing (cont.)
data from one task to another.
## 
Design Criteria
The Attach/Detach facility retains much of the feel of existing MAGEC facilities, in fact, it is very similar to fetch (cont.)
function (FTH-FUNCT) which is a well known and established MAGEC programming technique. The facility uses existing (cont.)
MAGEC common areas, i.e. the common screen fields, SFUNCT, SKEY, SERRMSG, SCOMPL, and TWA-MSK-AID are in the same (cont.)
relative positions in every TWA, thereby making them the ideal common areas for the applictions to use. There is also (cont.)
the benefit that the use of these fields is completely environmentally neutral, creating no CICS dependencies. Having (cont.)
an unlimited number of levels introduces the problem of too much overhead, so a limit of thirteen (13) levels is (cont.)
designated as being sufficient for most needs. The facility should be usable from either of the active MAGEC windows (cont.)
(swapping windows is done using the PF9 key) at the terminal and each session is completely independent of the other. (cont.)

Next: <a href="https://magec.com/DOC/markdown/cstm17.md.txt">https://magec.com/DOC/markdown/cstm17.md.txt</a>