MOVE FTH-FUNCT TO TWA-NONTP-REQUEST.
 
GO TO AA900-GOBACK.
 
In this case, we are always fetching to the CHG function for the second MMP since the record is already on the (cont.)
database, having been just added or updated by the first MMP. It is not necessary to suppress the normal reading in the (cont.)
second MMP, for the same reason.
What should be done, though, is suppression of the ADD function in the second MMP. This is done by simply de-selecting (cont.)
the ADD function from the list of available functions for this MMP. Refer to the MMP header screen discussion and (cont.)
Figure 02 inthe Application Developer section of this book. The Application Developer section is the first index tab in (cont.)
this Tutorials manual. Removing the ADD function in this manner prior to generating the MMP causes MAGEC not to (cont.)
generate a FCD (Function Code) definition record for an ADD function and also suppresses the generation of code into (cont.)
the MMP to support an ADD function.
It is possible to use the same coding in %PREINIT to ensure that the operator begins on the first screen before getting (cont.)
to the second screen; however, it is not necessary. Using this approach there is not a real reason why an operator (cont.)
should not directly access the second screen, if desired. An ADD function, of course, must begin from the first screen. (cont.)
That is ensured by the fact that the second screen has no ADD function at all.
## Toggling Between Screens
In either approach it might also be appropriate to provide a PF key in both MMP's to "swap" from screen one to screen (cont.)
two, and vice-versa for SEE functions. It would be acceptable (maybe preferrable) to use the same key in both such that (cont.)
it "toggles" between the two screens. Such coding could be done in the insertion point %PFKEYM. It would use the (cont.)
standard FTH-FUNCT logic as described in "Appendix B and the PF key logic as described in "Appendix G, both of this (cont.)
same chapter. It might also be advisable to restrict this toggling only to SEE and NXT functions via the condition name (cont.)
provided, i.e.:
IF (SEE-FUNCTION)...
 
## Sets of Masks
Some developers are accustomed to creating one program which utilizes several screens, rather than creating separate (cont.)
programs as described above. MAGEC supports the use of multiple screen Masks in any MMP; however, it is not (cont.)
recommended.
When a program, whether it is a MAGEC-generated program or not, utilizes multiple screen masks, the definitions for (cont.)
those masks must redefine one another. The CICS "map set" facility is a good example of screen definitions redefining (cont.)
one another. This redefinition opens up the possibility for many types of programming errors and greatly complicates (cont.)
both coding and debugging of the programs.
The program which utilizes multiple screens must constantly be aware of which screen format is active at any given time (cont.)
and must not make any references to screen fields not contained in the active screen mask.
At first glance it might seem that the technique of creating separate MMP's for each screen in a multiple screen (cont.)
sequence is less efficient; however, because of the architecture of MAGEC, it is approximately as efficient as a single (cont.)
program using multiple screens. The simpler, more modular, structure of the separate programs also eliminates the need (cont.)
for procedural logic to distinguish between the various screen formats in order to prevent references to an inactive (cont.)
screen from common routines.
Maintainability of the simpler programs is as good as for any ordinary MAGEC-generated program, since there is very (cont.)
little customization involved. It is even possible to add additional screens into the sequence with very little (cont.)
difficulty.
# Appendix T -- Accessing Global Parms
## Table #243
For various reasons, you may occasionally wish to interrogate the Global Parameters table of MAGEC from your (cont.)
application programs. That enables you to see exactly what settings have been specified for your MAGEC installation, (cont.)
and to take action accordingly. One example of why you may wish to access this information would be to learn what (cont.)
highlighting option has been specified for error fields on a screen (for 7-color terminals). We will use that example (cont.)
to illustrate accessing the table. Of course, any of the other parameters could be accessed (cont.)
similarly.
It is possible, but not recommended, to update the table from your programs. The reason it is not recommended is (cont.)
because the intrinsic functions provided with MAGEC to maintain the table include appropriate editing and formatting (cont.)
which your program might not adhere to; thereby creating an error condition. The intrinsic functions (cont.)
are:
243ADD
243CHG
et cetera
 
There is a discussion about Table #243, Global Parameters, in the *Installation Guide*.
Table #243 is merely a standard MAGEC Lookup table. It can be accessed just as any other table can be accessed, by (cont.)
reading the TBL file. To properly access this table, you should include the standard copybook into your program to (cont.)
define the TBL file records. To do that, code:
-MAGECINC TBL01-C
 
This would usually be in the %DATADEF, or %VARSTOR, insertion points.
In your Procedure Division, you should place code to read the file. For example, in an MMP:
MOVE '243' TO TBL01-TBL-NBR.
 
MOVE 'ERROR-HIGHLIGHT' TO TBL01-CODE-VALUE.
 
MOVE TBL01-KEY TO TWA-KEY-VALUE.
 
MOVE REDKY TO TWA-DB-CMD.
 
MOVE 'TBLK1' TO TWA-DB-FILE-NAME.
 
MOVE 'TBL01' TO TWA-ELT-LIST.
 
CALL 'MAGECSET' USING TWA-DB-AREA-A
 
TBL01-ELEMENT.
 
PERFORM AA840-CALL-MAGEC-IO THRU AA899-EXIT.
 
IF ( REC-FOUND )
 
MOVE TBL01-DESC TO some-work-field
 
ELSE
 
 
there is no ERROR-HIGHLIGHT specified (default will apply).
 
Remember to check in the "Insertion Points" chapter of your *Programmer's Reference Guide* to determine whether it is (cont.)
necessary to save and restore the I/O request area when doing I/O in the insertion point you choose. In %EDIT or %JOIN (cont.)
it is not necessary, for some others it may be.
# Appendix U -- List-type Update Screens
## Multi-Record Updates
You might frequently find it useful to develop screens on which the operator maintains multiple records from a single (cont.)
transaction. Such a screen typically lists records much like the browses do, but allows the operator to modify the (cont.)
listed records on the screen. The program senses which records were modified on the screen and updates, adds, or (cont.)
deletes accordingly.
An example of a function which might work this way is an Accounts Payable screen which shows the vendor information at (cont.)
the top and lists open invoices below. The operator might be allowed to modify the Release-to-Pay date on one or more (cont.)
of the invoices. He or she might also be allowed to delete invoices by typing a code into a designated field on that (cont.)
invoice's line, or to add new invoices by typing them into blank lines shown below the last open invoice on the screen. (cont.)
Such a program would read (and likely update) the vendor master record as well as one or more invoice (cont.)
records.
While this process might seem very different from the standard MAGEC-generated functions, it is not difficult to (cont.)
create. It requires surprisingly little customization to do so. Here is one technique which many MAGEC customers have (cont.)
used to develop hundreds of list-update MMP's. You may wish to modify this technique to accommodate some special (cont.)
requirement of your own. Once you have developed your first list-update program you will likely use it as a model for (cont.)
many other similar programs.
## General Premises
Before we discuss the technique it is helpful to review a few of the standards employed in the generated MMP's. (cont.)
Regardless what type function is being processed, the generated MMP's are designed to build a "logical record" or (cont.)
"view", then to do the desired process against the data within that logical record. In other words, the program reads (cont.)
one or more files or tables, calculates derived values, and places all of the resulting data into predictable locations (cont.)
(usually that means in the appropriate element copybooks in %DATADEF) early in the processing cycle. Thereafter, the (cont.)
logic is unconcerned about from whence the data came; all data is available to use however (cont.)
necessary.
An example of that is the Vacation MMP (MMP600) which you developed in these tutorials. It gathers data from two files (cont.)
(VAC and SIF) plus derived values (the calculated days due). The %JOIN insertion point is used to build the logical (cont.)
record.
If you have reviewed the Screen Painting section of your Programmer's Reference manual, you should have noticed that (cont.)
MAGEC allows you to easily define "repeating fields" on a screen. These repeating fields constitute an array, or table (cont.)
which is accessed using a Cobol subscript or index. You can have more than one such array on your screen. You can (cont.)
specify as the Source/Target database field for these repeating screen fields any valid Cobol dataname which OCCURS. It (cont.)
is perfectly legitimate for the Source/Target field to be a "Working-Storage" field, rather than an actual database (cont.)
field. You specify a relative subscript using an asterisk " (*) " to denote that the corresponding occurrence of each (cont.)
screen field and its Source/Target field will be MOVE'd to one another at the appropriate times.
All of the routines which do I/O in the MMP can be modified by you using customization in insertion points such as (cont.)
%REDKY, %RDUKY, %UPDAT, et cetera. When you add customization logic into these insertion points, MAGEC presents a (cont.)
proforma on the screen which strongly resembles the default I/O logic. This facilitates your making modifications to (cont.)
the I/O logic without having to re-type the default code.
## One Technique
While there are probably many ways to skin a cat, professional developers usually find one good way to do something, (cont.)
then adopt it as a standard and use it many times over. Below is a technique which was developed by some accomplished (cont.)
MAGEC users and has been shared with many others.
Specifications**
For this example we will assume the vendor/invoice problem referenced earlier. The screen is to show vendor data at the (cont.)
top and is to list ten (10) invoices below. To the left of each invoice there is to be a one-byte action code into (cont.)
which the operator will type "A", "C", or "D" to cause an add, change or delete of that invoice. The standard MAGEC PF7 (cont.)
and PF8 keys will bump to the previous or next vendor, the PF4 and PF5 keys will scroll backward or forward through (cont.)
this vendor's invoices.
The vendor file is keyed by vendor number, the invoice file is keyed by vendor number plus invoice number concatenated. (cont.)
The vendor number must already exist on the vendor file, thus this program will have only SEE and CHG maintenance (cont.)
functions. To add or delete vendors the operator will have a different vendor maintenance screen.
**Auto-Join**
To begin, you define the screen and MMP headers just as you would for any other new application. You specify the vendor (cont.)
file as your primary data class. Using the fully-automated development process to create the screen, you select the (cont.)
invoice file for MAGEC to join to. *Note, this presumes that the vendor number is the high-order portion of the invoice (cont.)
file key and that it belongs to the same domain as the vendor number in the vendor file.* MAGEC will generate a (cont.)
partial-key join ("left Join") to the invoice file; that is, it will generate (in %JOIN) a LOCKY, REDLE to read the (cont.)
first invoice for this vendor. You will be able to customize this join to then do REDNX to get subsequent invoices. If (cont.)
you are not familiar with these database I/O commands, refer to the Database Administration section of your (cont.)
Programmer's Reference manual.
**Screen Painting**
After you have selected the fields (Data Items) you wish to present on your screen from both the vendor and invoice (cont.)
record elements, MAGEC will generate a screen containing fields to display one vendor's data and one invoice's data. (cont.)
Using the manual screen painter, arrange the vendor data at the top of the screen and arrange the invoice data across (cont.)
one line. Delete the screen prompts which were generated to the left of each invoice field, you will be drawing a (cont.)
column heading above the invoice fields to replace these prompts. Leave one blank line (optional) below the vendor (cont.)
data, plus one line for the column headings. Place the invoice fields on the next line below the column headings line. (cont.)
Manually draw one column heading field with appropriate literals in the line immediately above the invoice data (cont.)
line.
Modify each invoice field by cursor-selecting it using PF18. Change the Occurrence to "*10", this will cause MAGEC to (cont.)
repeat that field ten times vertically. Of course, if you wished to have other than ten occurrences, you would modify (cont.)
the entry into Occurrence. Also modify the Source/Target to be an arrayed Working-Storage field, rather than the (cont.)
database field name which was generated for you. For ease of understanding, you should use a similar name with only the (cont.)
prefix altered. For instance: if the database name was IVC01-AMOUNT, you might alter it to WS-AMOUNT (*). The asterisk (cont.)
in the subscript tells MAGEC to generate MOVE's back and forth between the arrayed screen fields and their (cont.)
corresponding occurrences of "WS-" fields. Do not forget to add a one-byte Action-Code field which OCCURS just like the (cont.)
invoice fields. Its Source/Target might be WS-ACTION (*).
**%DATADEF**
Define a table of Working-Storage Source/Target fields. Use Cobol level 03 for the group item defining the entire (cont.)
table. Use Cobol level 05 (or as desired) for the entry below the group item. This 05 item should contain the OCCURS 10 (cont.)
TIMES clause. Define each "WS-" field using Cobol level 07 below it. Also define an index or subscript [PIC S9(4) COMP (cont.)
SYNC is recommended].
MAGEC will generate MOVE's from the fields in this table to the screen for displays and from the screen fields to this (cont.)
table for updates. For all intents and purposes, MAGEC now "thinks" this table is the database record which was read or (cont.)
will be updated. Do not forget the action code which also occurs.
Be sure to include all the primary key fields necessary to read each invoice record. If some of the key fields will not (cont.)
be displayed on the screen, include them in the table anyhow--you will need the complete primary key to add, delete, or (cont.)
update these records.
Also, add a field in %DATADEF to store the "beginning invoice number". This field will be used to start the browse looking for invoices for this vendor.
**%REDKY**
The default logic here does an exact key read of the vendor record, then it performs the join logic. Add one line of (cont.)
code before performing JA100-LOGICAL-JOIN to set the beginning invoice number to zero.
**%JOIN**
In %JOIN you will find generated logic to read the first invoice for the vendor being processed. That means that at the (cont.)
bottom of this generated join logic you will have the vendor data and one invoice's data in their appropriate element (cont.)
copybook areas.
First, alter the logic which builds the generic key for the invoice records. The generated logic fills in the (cont.)
high-order portion of the key using the vendor number and sets the low-order portion (the invoice number) to zeros. You (cont.)
must move the beginning invoice number from your %DATADEF holding field into the invoice number portion (low-order (cont.)
portion) of the key. This results in positioning to the first invoice for this vendor having an invoice number equal to (cont.)
or greater than the beginning invoice number.

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