This diagram illustrates the logical flow of the DELETE function — typically coded as "xxxDEL" — within a MAGEC-generated online Maintenance and Message Program, or MMP. The DELETE function allows an authorised operator to remove a record from the primary Data Class. Processing is divided into two distinct phases: the NEW TRANSACTION MODE, in which the operator supplies a key and the system reads and displays the record for confirmation; and the CONTINUATION MODE, in which the operator presses ENTER (or a configured PF key) to confirm and the system performs the actual deletion. Throughout the flow, MAGEC provides customisation hooks called Insertion Points — each prefixed with a percent sign — where developers may insert site-specific COBOL logic without altering the generated framework. An important referential-integrity rule named RULDELT may be inserted immediately after the percent-DELEDIT insertion point; if RULDELT sets the ERROR-FOUND flag, processing follows the error path out of the BB400-EDIT-FOR-DELETE routine rather than proceeding to the actual delete. The referential integrity rule (RULDELT) which pertains to any of the MMP's elements from its primary Data Class will be inserted immediately after the %DELEDIT coding. The RULDELT logic could set the error flag causing the program to follow the ERROR-FOUND path out of the BB400-EDIT-FOR-DELETE routine. Developers should be aware that MAGEC may automatically insert a referential-integrity rule called RULDELT directly after the percent-DELEDIT insertion point. If RULDELT detects that dependent records still exist, it sets the ERROR-FOUND condition, which diverts the flow away from the delete operation and back to the send-screen routine, presenting an error message to the operator. The very first execution point for every transaction, regardless of function or mode. %PREINIT is called before VARIABLE-STORAGE is initialised and before TEST-FUNCT / TEST-KEY are set. No 88-level condition names (ADD-FUNCTION, DEL-FUNCTION, etc.) are yet reliable unless the developer first MOVEs SFUNCT to TEST-FUNCT. Processing begins at the CHECK-FUNCTION paragraph, where the percent-PREINIT insertion point fires. This is the earliest possible customisation hook — it executes on every single transaction, in both new-transaction and continuation modes, for every function the MMP supports. Developers commonly use this point for database binding, such as scheduling a DL-one PCB or issuing an SQL CONNECT statement, or to alter the key delimiter character used by the normalise-key routines. Initialisation routine for all MAINT-FUNCTIONs. VARIABLE-STORAGE is set to LOW-VALUES immediately before %INIT executes. Developers use this point to initialise custom COMP-3 work fields or other variables defined in %VARSTOR or %DATADEF. Next, control passes to the storage-initialisation paragraph. Here the percent-INIT insertion point fires. At this stage, VARIABLE-STORAGE has already been cleared to low-values by the generated logic. If the developer has defined custom packed-decimal or binary work fields, they must initialise them here to avoid data-exception abends later in the flow. Top of the maintenance mainline. Executed for every MAINT transaction in both modes. Default logic handles PF7/PF8 (browse backward/forward), PF4 (transfer to LOC), PF1/PF2/PF11 (help), PF16/PF17 (copy/paste), and cursor-movement detection. Developers can intercept or override PF-key handling here. The maintenance mainline paragraph fires next, calling the percent-PFKEYM insertion point. The generated default logic at this point processes the standard SAA-compliant PF keys — PF-seven for backward browse, PF-eight for forward browse, and others. Developers may test for additional PF keys here, alter the SKEY or SFUNCT values, or bypass the rest of the mainline entirely by branching to the send-screen or GOBACK routines. Attribute initialisation for MAINT functions only. Fires at the end of the attribute-init routine, just before BA299-EXIT. Developers may override 3270 field attributes or set variable screen headings based on function code, operator ID, or other criteria. Control then reaches the maintenance-screen attribute-initialisation paragraph, where the percent-INITATB insertion point is called. This is executed only for maintenance functions — not for browse functions. A developer might use this point to set colour attributes, to make certain fields protected or non-display, or to alter screen headings dynamically based on who is logged on or which terminal is in use. Normalises the operator's key entry from SKEY into FILE-KEY, then MOVEs FILE-KEY to NORMALIZED-KEY. %NORMKEY fires after standard editing and reformatting, and only if no key errors were detected. Developers may add extra key edits or massage the key value here. Branching to BA480-BAD-KEY raises the INVALID-KEY condition. The normalise-maintenance-key paragraph executes next. Its job is to convert whatever the operator typed in the SKEY field into the internal file-key format required to read the primary Data Class. The percent-NORMKEY insertion point fires after all standard key validation has completed successfully. A developer could add custom key edits here — for example, verifying that the key falls within a range permitted for this operator — or could augment the key with a prefix or suffix derived from the terminal ID or operator ID. If the key value fails normalisation — for example, because it is blank, malformatted, or fails a custom edit coded in percent-NORMKEY — the flow branches to the INVALID KEY path, which eventually sends the screen back to the operator with an error indication. When the operator has already seen the record and is pressing ENTER to confirm the deletion, the MMP is in continuation mode and bypasses the new-transaction read path, proceeding directly to the read-for-update paragraph. On a fresh transaction — the first time the operator submits the DEL function — the flow follows the new-transaction path to read the record by key for display. Read the primary Data Class by key (non-exclusive) in new-transaction mode. Default logic: FSTAT to check file status, REDKY to read using NORMALIZED-KEY, then PERFORMs JA100-LOGICAL-JOIN. Also saves the Audit-Stamp for later comparison in %RDUKY. Must exit to AAM440-TEST-RETURN-CODE. In new-transaction mode, after a successful key normalisation, the MMP calls the read-by-key paragraph, where the percent-REDKY insertion point fires. The default generated logic first checks that the file is open using the FSTAT command, then issues a REDKY command to the MAGEC I/O module to read the primary record using the normalised key value. It then performs the logical-join routine to read any secondary files. Finally, it saves the record's audit stamp so it can detect concurrent updates later. Read the primary Data Class with EXCLUSIVE CONTROL in preparation for delete. Default logic: RDUKY command, then PERFORMs JA100-LOGICAL-JOIN, then compares the current Audit-Stamp against the saved one to detect concurrent updates. Must exit to AAM440-TEST-RETURN-CODE. In continuation mode, when the operator confirms the delete, the MMP calls the read-by-key-for-update paragraph, triggering the percent-RDUKY insertion point. This time the record is read with exclusive control, locking it against concurrent updates by other tasks. The logical-join routine is performed again to refresh secondary data. The audit stamp is then compared against the one saved during the new-transaction read; if another task has modified the record in the meantime, an error is raised. PERFORMed after every primary read. Reads secondary Data Classes and/or computes derived fields to build the MMP's Logical Record. Executed for both MAINT and BROWS functions. Exit via GO TO JA900-RETURN (not JA999-EXIT). MAGEC may auto-generate join code here from Screen Painting definitions or SQL. The logical-join paragraph — containing the percent-JOIN insertion point — is performed after every read of the primary Data Class. Its purpose is to construct the complete logical record by reading related secondary files or by computing derived fields. For example, if a customer record is the primary Data Class, percent-JOIN might read the customer's credit record from a secondary file and make that data available for display. MAGEC will have auto-generated join code here if Automatic Logical Join was configured during screen painting. If the primary read returns a not-found condition — meaning no record exists for the key the operator entered — the flow exits to the not-found path. This typically results in the blank-screen routine being called and the operator being informed that no matching record was found. Mode decision point after a successful read and join. In NEW-TRANSACTION MODE, flow goes to %COMP (BB200-FILL-SCREEN) to display the record for operator confirmation. In CONTINUATION MODE, flow goes to %DELEDIT (BB400-EDIT-FOR-DELETE) to validate the deletion. After a successful read and logical join, the MMP reaches a decision point. If this is a new transaction — the operator just submitted the key — the record is displayed so the operator can review it before confirming. If this is a continuation — the operator has reviewed the record and pressed the confirm key — the MMP proceeds to the delete-edit validation step. Reached when the key is INVALID or the record is NOT FOUND. Default logic MOVEs underscores to all screen variables. %BLNKSCR fires at the very end, allowing the developer to override individual field values, display a custom error message, or look up related data based on any partial key entered. When the key value is invalid or the requested record cannot be found, the flow diverts to the blank-screen routine. Here, all screen fields are set to underscore characters — the standard MAGEC "empty field" indicator. The percent-BLNKSCR insertion point fires at the end of this routine, giving the developer the opportunity to customise the blank screen — perhaps moving a more descriptive error message to SERRMSG or pre-filling certain fields based on partial key information. Fires in NEW-TRANSACTION-MODE after a successful read, when REC-FOUND. Default logic MOVEs all database fields to their corresponding screen fields. %COMP fires at the end, before BB299-EXIT, allowing the developer to translate codes, compute derived display values, or set 3270 colour attributes. Not executed in CONTINUATION-MODE unless the developer explicitly PERFORMs it. In new-transaction mode, after the record is successfully read and joined, the fill-screen routine populates the maintenance display with the record's data. All database element values are moved to their corresponding screen fields by generated MOVE statements. The percent-COMP insertion point then fires, giving the developer a final chance to translate database codes into human-readable descriptions, compute display-only calculated values, or dynamically alter field attributes before the screen is sent to the operator. The MAGEC referential integrity rule RULDELT is inserted immediately after %DELEDIT. If RULDELT sets FATAL-ERR = E, the ERROR-FOUND path is taken. See diagramNote NOTE01. Entire BB400-EDIT-FOR-DELETE routine is composed of %DELEDIT logic (no default generated code). Only executed in CONTINUATION-MODE for DEL functions. Developer may check for subordinate records, non-zero balances, or require a specific PF key before allowing deletion. Setting FATAL-ERR = E here prevents the delete and sends an error message. RULDELT (referential integrity) is also inserted here by MAGEC. TWA-DB-REQ-SAV holds the saved TWA-DB-REQUEST; do not corrupt it. In continuation mode, before the actual deletion is performed, control passes to the edit-for-delete paragraph. The percent-DELEDIT insertion point constitutes the entire body of this paragraph — there is no generated default logic. Developers are expected to supply any validation logic required before a record may be deleted. For example, one might read a related invoices file to ensure no open invoices exist for a customer before permitting the customer master record to be deleted. Immediately following percent-DELEDIT, MAGEC may insert its own referential-integrity rule, RULDELT. If either percent-DELEDIT or RULDELT sets the ERROR-FOUND condition, the flow diverts to the error path. If the delete-edit logic or the RULDELT rule sets the ERROR-FOUND condition, the delete is suppressed. The flow bypasses the actual delete and proceeds to the send-screen routine with an appropriate error message displayed to the operator. Performs the actual physical deletion of the primary Data Class record. Default logic calls the MAGEC I/O module with the DELET command. Only executed in CONTINUATION-MODE and only when ERROR-FOUND is NOT set. Developer may override to access non-MAGEC files/DBMS. Must exit to AAM750-TEST-RETURN-CODE. When no errors have been detected, the delete-from-database paragraph fires, containing the percent-DELET insertion point. The default generated logic issues the DELET command to the MAGEC I/O module, which physically removes the primary record from the file. Developers may override this logic entirely to delete from a non-MAGEC database, or may augment it with additional steps — such as updating a control record or writing a deletion audit log entry — immediately before or after the physical delete command. Executed when the DELET I/O fails (bad return code from MAGEC I/O module). Default logic: MOVE DB-ERR-MSG to SCOMPL, GO TO AA800-SEND-SCREEN. Only for DEL (and ADD/CHG/DUP) in CONTINUATION-MODE. Developer may attempt custom recovery but this is rarely necessary. If the physical delete operation returns an error code from the MAGEC I/O module — indicating that the deletion could not be completed — the update-error paragraph fires, containing the percent-UPDERR insertion point. The default logic moves a database error message into the completion message field on the screen and then proceeds to the send-screen routine. Custom recovery logic is rarely coded here; true I/O errors are usually handled by MAGEC itself, which may abend the task before returning control to the MMP. Last execution point before the MMP returns to MAGECCP. Fired for all functions and both modes. Developer may make final screen adjustments — blanking zero-value fields, highlighting out-of-range values, or massaging SKEY — before the screen is sent or a FETCH command is executed. Exit via GO TO AA900-GOBACK. The send-screen paragraph — containing the percent-SNDSCRN insertion point — is called just before the MMP hands control back to the MAGEC control program for screen transmission. It fires regardless of whether the delete succeeded, failed with a business-rule error, or is simply presenting the record for the operator's confirmation. Developers use this final hook to apply finishing touches to the screen — suppressing zero-value fields, applying highlight attributes to exceptional values, or adjusting the SKEY display for browse cursor-selection purposes. Executed only after a SUCCESSFUL delete of the primary record. Default logic: MOVE DELETED-MSG to SCOMPL. Developer may update related files, post to a control record, or FETCH to another function/screen after the deletion. Must exit to AA800-SEND-SCREEN or AA900-GOBACK. When the deletion completes successfully, the good-delete paragraph fires, containing the percent-GOODDEL insertion point. The generated default simply moves the "RECORD DELETED" message into the completion field on the screen. Developers often extend this logic to perform post-delete housekeeping — for instance, decrementing a record count in a control file, cascading the delete to related secondary records, or automatically fetching another function to show the operator the effect of the deletion on related data. Absolute last execution point for ALL functions in ALL modes. Executed for every function — MAINT and BROWS. No default code. Developer may insert final housekeeping — for example, TERMINATE for an IMS PCB. Must be aware that screen Mask context must be tested before referencing screen fields. The GOBACK paragraph — containing the percent-GOBACK insertion point — is the absolute final point of execution for every online function in every mode. After this point, the MMP issues its GOBACK instruction and returns to the MAGEC control program, which will either transmit the screen to the terminal or execute a pending FETCH command. Developers use this rarely-customised point for final resource release — such as terminating an IMS Program Communication Block. The DELETE function in a MAGEC-generated online Maintenance and Message Program begins execution at the CHECK-FUNCTION paragraph, where the percent-PREINIT insertion point fires for every transaction, regardless of mode. Control then passes to the storage-initialisation paragraph containing percent-INIT, where VARIABLE-STORAGE has already been cleared to low-values. Next, the maintenance mainline paragraph fires, calling percent-PFKEYM, which by default handles standard PF-key routing such as browse-forward, browse-backward, and help. Attribute initialisation follows through the percent-INITATB insertion point, where the developer may customise 3270 screen attributes before any data is displayed. The flow then reaches the normalise-key paragraph and its percent-NORMKEY insertion point. If the operator's key entry is invalid, the flow diverts immediately to the blank-screen routine. If the MMP is in continuation mode — meaning the operator has already seen the record and is confirming the deletion — the flow bypasses the new-transaction read path and proceeds directly to the read-for-update paragraph. Otherwise, in new-transaction mode, the MMP calls the read-by-key paragraph containing percent-REDKY, which reads the record non-exclusively and saves the audit stamp. In either mode, after the primary read, the logical-join paragraph performs the percent-JOIN insertion point, reading secondary files and computing derived fields to assemble the complete logical record. If the record is not found, the flow diverts to the blank-screen routine. After a successful read, the MMP reaches a mode decision point. In new-transaction mode, the fill-screen routine fires the percent-COMP insertion point, moving all database element values to their corresponding screen fields so the operator can review the record before confirming. The flow then proceeds to the send-screen routine so the MMP can return the display to the terminal and wait for the operator's response. When the operator responds — typically by pressing ENTER — the cycle repeats and the MMP is now in continuation mode. After the read-for-update with exclusive control via percent-RDUKY, and after the logical join, the mode decision directs the flow to the edit-for-delete paragraph containing percent-DELEDIT. The developer is expected to supply all validation logic in percent-DELEDIT. MAGEC also inserts its RULDELT referential-integrity rule immediately after percent-DELEDIT. If either sets the ERROR-FOUND condition, the flow bypasses the delete and goes directly to the send-screen routine with an error message. If no errors are found, the delete-from-database paragraph fires the percent-DELET insertion point, which calls the MAGEC I/O module with the DELET command to physically remove the record. If the delete I/O fails, the percent-UPDERR insertion point fires and moves a database error message to the screen. If the delete succeeds, the percent-GOODDEL insertion point fires. The default logic moves the "RECORD DELETED" message to the completion field. Developers may extend this to perform post-delete housekeeping or to automatically navigate to a related screen. In all paths, the flow eventually reaches the send-screen paragraph containing percent-SNDSCRN, where final screen adjustments may be made, followed by the GOBACK paragraph containing percent-GOBACK, which is the absolute last execution point before the MMP returns control to the MAGEC control program.