This chapter provides an overview of TFG2000 Engineering Data Support (CEDS). It describes the aspects of the product that are not directly related to individual transactions, such as:
TFG2000 products can process data in three ways: online, asynchronous, and batch processing.
Online transactions can be entered at a terminal. The system uses the normal online facilities of CICS/VS to process them immediately. The terminal cannot be used again until the transaction has been completed. You can enter any online transaction from any of the TFG2000 products in any sequence.
Some transactions within CEDS are processed asynchronously. The functions performed as asynchronous processing tasks can be long running and process while the terminal is used for other transactions. These asynchronous tasks are initiated by online programs. After the asynchronous task has been scheduled, the terminal is free to be used for another transaction. When the programs are run, progress messages are written to CICS/VS Temporary Storage to indicate whether or not the requested functions were completed successfully.
Some programs within CEDS operate in a batch processing mode. The format of any control records required for these programs is described in Chapter 3. "Batch programs". Sample Job Control Language (JCL) statements to run these batch jobs can be found on the TFG2000 Base Product tape.
These jobs should be scheduled as separate batch runs. They cannot be run while CICS/VS is running, unless the Multi-Partition Support (MPS) feature of DL/I is installed. Even then, inconsistent results are possible because data can be updated online during the time that the batch program is running.
The functions described in this chapter are included within CEDS, but are not strictly part of the application itself. They should, however, be considered when planning the implementation of CEDS because they are necessary for the successful operation of CEDS in a production environment.
The TFG2000 products are designed to be online real-time applications. Any online application demands a complete operational backup/recovery procedure. In the event of a system failure, such procedures are necessary to prevent data loss and database damage. Because TFG2000 products utilize DL/I and CICS/VS, the responsibility for backup and recovery lies with these two system products and not in the TFG2000 application code. All eventualities must be considered when the backup/recovery procedure is implemented. Backup/recovery procedures should be reviewed and tested regularly, especially when new releases of software are installed, to make sure that they remain complete and reliable in the event of system failure.
All TFG2000 online transactions can be recovered using normal recovery considerations. If the CICS/VS system is run using Program Isolation (PI), automatic transaction restart should be used to restart those transactions that are abended by DL/I.
The CEDS load edit version of the Product Definition Database can be recovered by resending information from the engineering system. The master copy of the Engineering BOM is maintained within the computer-aided design system, while the master copy of the Manufacturing BOM is maintained within the production version of the Product Definition Database. The BOMWORK database can be reloaded and replaced from a sequential interface file.
Two types of asynchronous transactions require special consideration:
To have full recovery for the Transient Data-initiated transaction, the following steps should be taken:
To have full recovery for Interval Control-initiated transactions, specify the leading characters of DATAIDs as "DF" for which CICS/VS provides protection in the Temporary Storage Table (TST).
Asynchronous transactions can be recovered by restarting. If Program Isolation and Dynamic Transaction Backout are installed, a transaction abend results in a backout of all database updates that have occurred since the last syncpoint. The syncpoints are placed at the end of logical units of work, such as the end of processing for an item.
A standard screen layout is used for all transactions within CEDS. The size of the screen is 24 lines, each of 80 characters. Whenever possible, data that appears on more than one screen layout is displayed in the same position on each.
Figure 1-1. Example of CEDS screen layout
+--------------------------------------------------------------------------------+ | DSMR Env.: X| | Fn: CEDS Maintain Options | | | | Item No: Date: | | E/C No: Comp No: Pref: Suff: | | ----- -----| | | | Engineering Data Load Restart Interval (HHMMSS): 000500 | | Engineering Change Effective Date (D, T): D | | Create Dummy Item During Load (Y, N): Y | | Load Bill of Material to Production Environment (Y, N): N | | | | | | | | | | | | | | | | | | | | ----- EMT068E: Current record -----| | Functions: INQU - Inquire (default) REPL - Change | | | | Enter F1=Help F2=Message help F10=Save F11=Restore | +--------------------------------------------------------------------------------+
Figure 1-1 shows an example of the CEDS screen layout. It consists of the following sections:
This area contains the codes that identify the transaction and function code you are requesting. A transaction description appears in line 2 when you initiate a transaction by pressing ENTER. Check this description to make sure that the required transaction has been selected. The current database environment is shown in this area.
This area contains the identification necessary to find a particular set of data. This varies slightly depending upon the transaction requested, but shows such data as the Item Number and Item Description. The date also appears in this area. The date defaults to the current date, but you can specify a different date. The layout of this screen area remains constant from one transaction to the next, unless the identification fields required are different. For example, if you are using a transaction that only requires the Item Number (line 4), line 5 would show the content of the previous transaction. You can ignore unnecessary fields.
This area contains the actual data you want to maintain. The content varies depending upon the transaction used, but generally shows a brief description of each data field beside its appropriate value. You enter all data you want to add or change in this area in the appropriate place.
This area contains any message generated by CEDS. The messages can indicate an error condition or they can be informational, such as a confirmation of the transaction status.
This area contains a list of the valid functions that you can enter for the current transaction.
This area contains a list of the function key assignments for the transaction available for the next action.
The transactions are independent of one another and no predefined sequence is required. You can follow any path as long as it makes logical sense.
Header data remains on the screen from one transaction to another, so you normally do not need to re-enter it for a subsequent transaction. Entering the transaction code and any changes to the header data is normally sufficient.
When entering data in the Application Data area, make sure that no old information remains in any field before pressing the ENTER key. If any old information remains, remove it using the ERASE EOF key. For example, erase all question marks (?), which indicate that the field must be entered, and the old numeric values displayed at the beginning of a change transaction. Always use the ERASE EOF key before entering new data because the new data may not completely overwrite the old data.
Data fields displayed on the 3278 type display station can be defined as protected or unprotected and can be displayed with normal contrast or highlighted. If you use an IBM 3279 type color display station, data can be displayed in red, white, green, or blue.
The various elements provided with CEDS conform to the following standard naming conventions. The only exceptions are some of the general TFG2000 transactions and programs, (mainly those connected with the Standard Text Database).
Transaction codes take the form "DSaa."
Program names take the form "cccdeeee"
For example, EMTODSDL is the Display Delta Reports online program.
Copybook names take the form "cccCffff"
Mapset names take the form "cccSffg"
PSB names take the form "cccPffv"
Help Text for both transactions and messages can be obtained during online activity by pressing a function key (default is either PF1 or PF2). These functions keys invoke transactions HETR or HEER, which save the contents of the current screen, and display either Help Text for the transaction being used (default is PF1) or Help Text for the error message displayed (default is PF2). After checking the text, press ENTER to return to the running transaction.
The Help Text for all TFG2000 online transactions and messages is provided with the TFG2000 Base Product. You can modify the Help Text by using the transactions HEXT and HERE of the batch programs DXQHLBC and DXQHUBC. The batch programs load and unload the database to or from a sequential file that can be maintained using an online editor.
See the TFG2000 Administration, Operations, and Users' Guide for more information.
The following function keys are the default function keys for displaying the TFG2000 Help Text:
Note: If the transaction HETR is used, a general explanation of transaction Help Text is displayed.
Note: If the transaction HEER is used, a general explanation of message Help Text is displayed.
Help transactions will not work after you have entered data for transactions that require Basic Mapping Support (BMS) paging.
The SAVE transaction lets you save the current screen image, including any data that has been entered or modified. Using this transaction, you can interrupt the current transaction to run other transactions. You can retrieve the saved screen at any time by using the BACK transaction from the same terminal.
To initiate the SAVE transaction, enter a transaction code of SAVE and press ENTER, or press a defined PF key (default is PF10). If you use the PF key, the retrieved screen will show the original transaction code. Otherwise, the retrieved screen will show a transaction code of SAVE.
To initiate the BACK transaction, enter a transaction code of BACK and press ENTER, or press a defined PF key (default is PF11). If no more screens remain to be retrieved, an error message is displayed. The saved screens are retrieved in "last-in-first-out" sequence.
Note: The SAVE and BACK transactions will only save and restore one page of data with transactions that require Basic Mapping Support (BMS) paging, which are transactions needing more than one screen display.
See the TFG2000 Administration, Operations, and Users' Guide for more information about saving and restoring screens.
The DSHE transaction displays the CEDS main product menu. It lists all the available transaction codes within CEDS, a brief description of each, and the data that must be entered to initiate each transaction. From this screen, you can run any other transaction by typing the transaction code, typing the required data, and pressing ENTER.
For more information on the CEDS main product menu, see the EMTODSHE program description in Chapter 2. "Online application programs", of this manual.
The TFG2000 Base Product has an optional security program. It controls which users can initiate various transactions. Setting the Environment Table entry SECURITI to "YES" activates the security program. Each CEDS online transaction calls the program.
The Security program has two main functions:
You can sign on to CEDS with the SION transaction, which stores user data (department, function, employee). This data controls the security checks performed and is held until you sign off using the SIOF transaction.
See the TFG2000 Administration, Operations, and Users' Guide for more information about the Security program.
The Standard Text Database contains various textual information, some of which has special significance to application programs and some of which is for any form of user text. The structure of the database is as follows:
The root segment (TEROOT/STDXID) identifies the text required.
The Text Responsibility Segment (STXRES/STDRESP) defines the department, function, and individual who is authorized to modify this data.
The Standard Text Segment (TEDATA/STDATA) holds the various text data.
Note: The segment names show the logical segment name first followed by the physical segment name. For example, (TEROOT/STDXID). TEROOT is the logical segment name and STDXID is the physical segment name.
Having installed one or more of the TFG2000 products, you may want to change the wording used in some or all of the error messages that may be displayed during transaction processing.
All error message texts displayed by the online CEDS programs are stored on the Standard Text Database, which is a part of the TFG2000 Base Product. The TFG2000 Base Product provides two transactions to maintain and display the text data and text responsibility from the Standard Text Database. These transactions (TEXT and TXRE) are described in the TFG2000 Administration, Operations, and Users' Guide.
To display these texts, the Environment Table entry ERRDEBUG must be set to "YES"; otherwise, only the error number is displayed.
The online programs within CEDS retrieve error message texts from the Standard Text Database and display this text as required.
For more information about changing error messages, see the TFG2000 Administration, Operations, and Users' Guide.
The Environment Table (ENVTABLE) is the means of communicating to all TFG2000 products which other products or databases are installed. Often, a particular product has functions that duplicate essential functions of other products. These functions are inhibited or activated depending on whether or not the other products are installed.
This table allows for progressive implementation of TFG2000 products, while maintaining control over the integration of the products.
The Environment Table is catalogued in a library and loaded into main storage when required by a program. The Environment Table is described in more detail in the TFG2000 Administration, Operations, and Users' Guide. CEDS dependent entries, are described in Chapter 4. "TFG2000 Engineering Data Support integration and tailoring", of this manual.
CEDS has been designed to work in a multiple language environment. The product can be used in the same way regardless of the language chosen. You can specify the required language, and the screens and the error messages will be displayed in the specified language. The screen maps are used according to the language requested and have the same name except for the last character, which differs for each language. The language supplied with CEDS is English (suffix E).
You can choose the screen and error message language in one of the following two ways:
When customized, the bill of material can be copied from the load edit version of the database to the production version (the E environment) in a controlled manner. The production version of the bill of material is used by the production planning and control systems in planning and tracking actual work and materials through the production process. They would not be affected by the work in progress in the engineering environment until that bill had been released to the production environment.
MES is transparent because you only need to select an environment when signing on to the TFG2000 system. Thereafter, the system handles the selection of the correct version of the data.
See Appendix K. "Multiple environment considerations" if you plan to have CEDS work with more than one production environment in a CICS region.
For more information about implementing Multiple Environment Support, see the TFG2000 Administration, Operations, and Users' Guide.
The results of processing by one TFG2000 product can be passed to another TFG2000 product by two methods that avoid the need to fully scan the databases involved. The techniques employed use the Activity Database and Communication Oriented Message System (CORMES).
Data is written to the Activity Database whenever a change that necessitates replanning an item is made to the Product Definition Database or the Planning Database. Such changes include modifications to item planning data values or bill of material changes. TFG2000 Advanced Function Material Requirements Planning (AF/MRP) processes the Activity Database and replans all items contained in it. In this way, only those items in need of replanning will be processed and considerable computer effort is saved.
In certain cases, TFG2000 application products may determine that further action is required. For example, to resolve a problem or to enter new data. If CORMES is installed, action messages are directly communicated to the responsible department or individual in that situation, saving time and effort normally involved in the manual transfer of information. Messages are communicated directly and accurately, enabling action to be taken promptly and, therefore, providing an additional level of control within the TFG2000 system.
Within the TFG2000 system, action messages are generated when certain transactions are processed. These action messages inform relevant departments that action is now required to fulfill their respective functions.
The action messages are distributed to the appropriate departments using CORMES. In order to use CORMES successfully, you must define some data tables to the system to provide details of the recipient of the message. The tables required and the method used to send messages using CORMES are outlined below.
See the CORMES Program Reference Manual for more information on setting up a Message Information Block and the CORMES Action Table and Action File.
Note: CORMES is not a prerequisite for CEDS. If CORMES is not installed, the COPICS-CORMES Interface (CCI) also provides an option to process action messages and place them into a VSAM file which can be printed and maintained using your own procedures. The VSAM file must first be initialized using the DDXBCCIL program.
The action messages issued by programs within CEDS are designed to be distributed by CORMES. Integration of CEDS with CORMES is accomplished by using the COPICS-CORMES Interface program, CCIASYCR. The action messages issued are processed by this program and passed to CORMES so that the information can be communicated to specific users.
Although CEDS was designed as a stand-alone application, it uses TFG2000 Bill of Material Online II (BOM/O) or its equivalent to process bill of material information.
Data received from the Product Engineering Support (PES) and Product Data Interface (PDI) formats can be loaded directly into the TFG2000 production environment (the E environment). However, data received from the EMI format is always loaded into the load edit environment (the X environment). CEDS uses TFG2000 Bill of Material Online II transactions to review or change bill of material data in the load edit environment.
Bills of material can then be copied from the load edit environment to the production environment and deleted from the load edit environment. Status and error messages allow you to monitor the copy process.
Figure 1-2. CEDS load and translate process
CEDS updates the following databases:
CEDS accesses the following TFG2000 databases for reference:
CEDS message texts are stored in the Standard Text Database.
All of these databases are used by other TFG2000 products.
For details of the design and contents of all TFG2000 databases, see the TFG2000 Database Guide. This manual covers the structure of each TFG2000 database for all TFG2000 products together with the segments and individual data elements that make up these databases. It also includes a product-database cross-reference and a description of each CORMES database.