MOVE SFUNCT TO TEST-FUNCT
MOVE SKEY TO TEST-KEY
IF (TWA-LAST-KEY NOT = TEST-KEY)
OR (TEST-FUNCT-KEY NOT = 'CUS' AND 'CS2')
MOVE 'CUS' TO TEST-FUNCT-KEY
MOVE TEST-FUNCT TO SFUNCT
MOVE FTH-FUNCT TO TWA-NONTP-REQUEST
GO TO AA900-GOBACK.
The above code will ensure that we have come from the first screen, and for the same key value. If not, it will fetch (cont.)
back to the first screen to try to initiate the sequence at the beginning, on the assumption that that is what the (cont.)
operator should have done (meant to do) anyhow.
The second MMP will also need to refrain from re-reading (or trying to read) the record being processed. This is (cont.)
because the first MMP has already read it and the entire record (or, at least, all the Elements we are interested in) (cont.)
are already in TWA-DB-DATA; reading on top of them is both unnecessary and destructive. To suppress those reads we (cont.)
might simply comment out the perform of the I/O call in the insertion points: %REDKY and %RDUKY, as:
****PERFORM AA840-CALL-MAGECIO THRU AA899-EXIT
We also must prevent the default %ADDINIT logic in the second MMP from trying to initialize the Element copybook (cont.)
fields. To do this we would simply add customization into the %ADDINIT insertion point commenting out the MOVE (cont.)
SPACES... code.
The second MMP will follow its natural flow and, if all edits are passed, add or update the database record with all the data from the first and second screens.
##
Second Approach
In the second approach we allow the standard logic of the first MMP to do its normal update or add, then we have it (cont.)
fetch to the second MMP. Since, on an ADD function, the record will be added in the first MMP, we will transfer to the (cont.)
second using a CHG function whether we were doing an ADD or a CHG in the first MMP.
Because we will be adding an incomplete set of data to the database in the first MMP, we should be careful to set (cont.)
appropriate default values into all the fields of the Element copybook(s) being updated. That means that we might need (cont.)
to put some customization code into the %ADDINIT insertion point. The customization would move default values to those (cont.)
fields not updated/added from the first MMP. Some developers will choose to set default values which identify this (cont.)
record as "incomplete" in order to facilitate auditing the database and/or restarting the multi-screen transaction from (cont.)
the point it was aborted.
The first MMP should fetch to the second from the %GOODADD and %GOODCHG insertion points. These insertion points occur (cont.)
after a successful add or update, respectively. The coding to fetch to the second MMP would be:
MOVE 'CS2CHG' TO SFUNCT.
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.)
next: cstm23.md.txt