CFO OBJECT AND SOURCE CONTROL

CONTENTS Contents
SERVICE ORDER ................................................................................................................................... 3 SERVICE ORDER OPENING. .............................................................................................................. 3 INCLUSION OF MODULES IN SERVICE ORDER ................................................................................. 4 CATALOGING OF THE MODULES FOR A SERVICE ORDER (SHUTDOWN) ............................................ 5 CLOSURE OF THE SERVICE ORDER ...................................................................................................... 6 MODULE CATALOGING FLOW ............................................................................................................. 7 CATALOGING FLOW WITH PRIOR APPROVAL OF PRODUCTION......................................................... 9 CATALOGING FLOW IN EMERGENCY ................................................................................................ 10 AUTOMATIC COMPARATOR.............................................................................................................. 12 ONE-TIME PROGRAMS ...................................................................................................................... 12 CFO FUNCTIONS ................................................................................................................................ 13 0 SETUP ...................................................................................................................................... 14 1 MODULE READING .................................................................................................................. 19 2 - INFO ......................................................................................................................................... 19 3 - CATALOGING IN EMERGENCY. ................................................................................................. 20 4 - OPENING OF SERVICE ORDERS. ............................................................................................... 22 5 - DIRECTORY OF SERVICE ORDERS. ............................................................................................ 24 6 - DIRECTORY OF MODULES IN TRANSIT. .................................................................................... 27 7 READING OF MODULES (WITH DESTINY) ................................................................................ 31 U - UTILITIES .................................................................................................................................. 32 P - MAINTENANCE OF PROCS, PARMS, JCL and RPFS ................................................................... 34 CATALOGING FLOW OF RESOURCES FROM CICS .............................................................................. 36 PROFILES FOR FORMATION OF MODELS .......................................................................................... 38 MASKS FOR DIRECTORY FORMATION ............................................................................................... 40 GENERAL CONSIDERATIONS ............................................................................................................. 40

SERVICE ORDER

To add or update modules in a production environment, it is necessary to have a user request so that the work can be performed. After this, the area responsible for the service execution must request through the CFO, the opening of a SERVICE ORDER. SERVICE ORDER OPENING. OPENING. The SERVICE ORDER is opened when a project manager or the HEAD of the area requests its opening or when a programmer requests and the manager accepts the request. At the opening time, the SERVICE ORDER receives a START DATE provided by the CFO. After filling the fields displayed by option 4 from the main menu, the user must answer the RISK ANALYSIS questionnaire. Once this phase is completed, the SERVICE ORDER can be viewed through option 5 (service orders directory), observing that only those involved in the work have access to it: AREA HEAD, the PROJECT MANAGER and his BACKUP, the LEADER of the project and PROGRAMMERS designated in option 4, as well as the Heads of the areas involved in, the CHANGES and CATALOGING department. Are also elected at this time, the authorizers of modules maintenance related to this SERVICE ORDER, the AREA HEAD, the PROJECT MANAGER and his backup and PROJECT LEADER, being that the authorizer must have hierarchical level equal to or higher than the APPLICANT. In addition to responsibility for the maintenance of the modules approval, the AREA HEAD, the PROJECT MANAGER and his BACKUP, will be eligible to change during the lifetime of the SERVICE ORDER, the following fields: PROJECT MANAGER, BACKUP, LEADER, and EXPECTED ENDING DATE and INVOLVED DEVELOPERS LIST. While the LEADER, will be able to update the PROGRAMMERS LIST.

INCLUSION OF MODULES IN SERVICE ORDER To CREATE or MODIFY a productive module, users should use option 5 (service orders directory) from the main menu and run the "C" command next to the SERVICE ORDER in question, as long as it has already received a START DATE that will be obtained in the according to the rules previously described. After this, the user will receive a screen (14 entries) which should be completed as follows: In the case of a NEW module, all displayed fields should be filled, and the description must represent the FUNCTION of the module in question. In the case of an existing module, only the first two fields are required and the description field must represent the maintenance that is being performed, being that in the latter case, the CFO will make a copy of the module to the LIBRARY OF ROSCOE user, in case a copy already exists, a new name is given, being the 1st character of the module name replaced by the "$" character. When you run this option, the user must inform the module type at issue in the NEW module, and the types are: PROGRAM (software area only), ONLINE (for online programs), BATCH (for batch programs), BOOK (for books), NATURAL (natural for programs and their variations), DDM (for data), MACRO (for macros), DOC (for documents) and DOCPROD (for documentation systems in production). Except for modules of type MACRO and PROGRAM, there is no need to inform the modules DESTINATION. In case of EXTERNAL PROGRAMMERS, the modules should be included in the SERVICE ORDER by the project manager, or his backup or project leader, through the command "X". After the execution of this function, the external programmer will be able to continue the cataloging flow through its own ROSCOE LINE, being sent to his LIBRARY, the source of the existing modules. The modules flow connected to the SERVICE ORDER since their inclusion to the cataloging will be described later.

CATALOGING OF THE MODULES FOR A SERVICE ORDER (SHUTDOWN)

To begin the process of cataloging the modules connected to a service order, it is necessary that the project manager, his backup or the AREA HEAD request through the CFO the CLOSING of the OS. After this the modules will be available for the PRODUCTION MANAGER to approve the cataloging of the modules and for the department to complete the cataloging process, giving to the cataloger a CHECK-LIST indicating which items are needed as documentation including the SERVICE REQUEST and USER APPROVAL for completion. For service orders of MEDIUM and HIGH risk, the Head of the areas involved must approve the start of the cataloging process through the CFO. After closing the OS it will no longer be possible to include modules. When the SHUTDOWN request of the service order is made up to 24 hours after the date of its opening, it is characterized as an URGENT situation. In this case, the documentation described in the previous item should be delivered within a maximum of 3 business days after the closing of the order service. In the case of non-compliance of this deadline, the cataloging sector is expected to register the reason for the delay in the SERVICE ORDER. For service orders of MEDIUM and HIGH risk, the Heads of the areas involved should take knowledge of the cataloging process retrospectively.

CLOSURE OF THE SERVICE ORDER

The closure of the service order is executed by the cataloging department after receipt of all documentation and end of all modules cataloging. For cases of URGENT service orders and of MEDIUM or HIGH risk, the closure will only be allowed after being acknowledged by the Heads of the areas involved. After the closure of the OS, the cataloging department will receive a report containing the approval history of this and any other information provided by the CFO. Note: A SERVICE ORDER must have its cataloging modules process completed in not more than 3 business days after its CLOSURE. If necessary to postpone the CLOSURE, the cataloger should contact their supervisor who will make the authorization for the delay, and in this case the cataloger should record the reason in the OS (provided because of the closure) and collect the signature from the supervisor. The cataloging department will have access to all service orders whether they are open or not. The cataloger should identify every semester the orders scheduled to end with more than one month late, and charge the manager responsible for the update of this date.

MODULE CATALOGING FLOW

Once included in a SERVICE ORDER, through the "C" command, the modules can be manipulated through option 6 (directories of modules in transit), follows below the module cataloging flow that participates in the CHANGES area: STEP 1 (programmer) Execution of the "C" command next to the SERVICE ORDER in question and filling of the required fields. STEP 2 (programmer) Production or modification of the module in question, compilation and editing link with HASH and testing in right environment. STEP 3 (programmer) Request of TEST IN CHANGES /APPROVAL using specific command through option 6 (modules directory in transit). After running the above, the programmer cannot compile and edit link the program in question, because it may cause problems of NO BEAT OF HASH in STEP 7. STEP 4 (change) The CHANGES area should perform the cataloging module in question, in TEST environment, using its own command through option 6. After that, there should be done the necessary tests to validate the area of maintenance. This catalog will be composed of: Beating of HASH and copy of the module to the TEST-LIB, if there is success in the process of HASH. To this end, all the Books referring to the module in question that has been modified should have gone through STEPS 1-3. After execution of the TESTS, the CHANGES area may inform to the CFO that the tests were successful, passing the module to the next STEP or inform about an ERROR. In this case, the CFO will allow the CHANGES ANALYST to inform the user about the error occurred. In case there is no interest in the module test, the CHANGES ANALYST must inform the CFO to make a BYPASS test, passing the module to the next STEP.

STEP 5 (project manager) At this point, the AREA HEAD responsible for the SERVICE ORDER, the PROJECT MANAGER or his BACKUP or the PROJECT LEADER, must approve the maintenance of the module through the command itself in option 6. This STEP can also be performed before or during the tests conducted by the CHANGES area. STEP 6 The PRODUCTION MANAGER approves the cataloging through the specific command in option 6 and can identify the time of approval whether or not the modules were successfully tested. For the manager to view the output modules to be approved, it is necessary that the project manager CLOSES the SERVICE ORDER. STEP 7 The cataloging is performed by the sector responsible for such service. This process refers to modules of type PROGRAM, ONLINE, BATCH, NATURAL, DDM and DOCPROD. For other types, STEP 4 will be eliminated.

CATALOGING FLOW WITH PRIOR APPROVAL OF PRODUCTION

STEP 1 (programmer) Execution of the command "C" next to the SERVICE ORDER in question, and filling of all required fields. STEP 2 (programmer) Execution of the command "Z" in the modules directory in transit, requesting prior approval from the PRODUCTION manager. STEP 3 (production) The PRODUCTION MANAGER approves the cataloging through the command "A" in the modules directory in transit (the modules can only be viewed by the manager of production if they are connected to a service order status "A"). STEP 4 (programmer) Making or altering the module in question, compilation and link editing with HASH and testing environment itself. STEP 5 (project manager The AREA HEAD responsible for the SERVICE ORDER, the PROJECT MANAGER or his or BACKUP or the PROJECT LEADER must approve the maintenance of the module with the command "A" in the modules directory in transit. STEP 6 (cataloging) The cataloging industry makes the cataloging. Note: After the approval of the PRODUCTION MANAGER, the module will bring in the STATUS field, a "*" in byte 3 *.

CATALOGING FLOW IN EMERGENCY

Only some types of module can be cataloged under EMERGENCY, and they are: PROGRAM, ONLINE, BATCH, NATURAL and DDM. Follows the cataloging flow: STEP 1 (programmer) The programmer must compile and link edit the module with HASH, taking care not to use any BOOK that is accidentally in the users LIBRARY. If by any chance there is a need of changing any BOOK, this should be incorporated into the module and regularized after completion of CATALOGING IN EMERGENCY process. STEP 2 (programmer) Run option 3 from the main menu by completing all required fields, when, the source of the module should be in the LIBRARY of the ROSCOE user, after running this option the source is removed from the original location. STEP 3 (technical trainer) The TECHNICAL TRAINER should make the CATALOGING IN EMERGENCY by running the command "C" in the modules directory in transit, this process consists of beating HASH, copying the module to DEST-LIB and listing the MODULE being sent to the WSF2. STEP 4 (Head of the Programmer who cataloged in emergency) The AREA HEAD responsible for the user, who made the request for cataloging, acknowledges the happening through the command "O" in the modules directory in transit. STEP 5 (production manager) The PRODUCTION MANAGER also acknowledges using the same instruments described in the previous item. STEP 6 (cataloger) The cataloging department performs the copy of the source to the LIBRARIAN. There can only be one REQUEST of CATALOGING IN EMERGENCY at a time to a single module, after cataloging has been made by the TECHNICAL PREPARATION, this module will be able to be cataloged in EMERGENCY again. After being carried by the CATALOGING IN EMERGENCY through the TECHNICAL PREPARATION, the module will remain unavailable for update through the normal flow of cataloging until the STEP 6 of the EMERGENCY flow is executed. If there is ever any entry in the modules directory in transit for the module being cataloged in EMERGENCY, the CFO of this will change the status to "CATALOGUED IN EMERGENCY" and will return the source to the user, if necessary. The cataloging department will be responsible for making it known to the involved in the regulation of emergency be reached in a maximum of 2 working days.

After regularization of the cataloging in emergency, the cataloging department will receive the historic of this flow to be filed with the system folder. The CATALOGUER and the TECHNICAL TRAINER may through the command "D" in the modules directory in transit, eliminate requests for cataloging in emergency, returning the source previously withheld to the LIBRARY of ROSCOE of the requesting user. To retrieve the source module between the CATALOGING and the REGULARIZATION, use the "P" in the modules directory in transit. This command will submit a JOB that will make available the source in one of its SYSOUTS.

AUTOMATIC COMPARATOR
As seen above, all maintenance done on production module must be authorized by a MANAGER, BACKUP MANAGER or LEADER on the SERVICE ORDER, before it is cataloged into production. This authorization allows the authorizer to check if the changes made to the module refer to the work being performed described in the O.S. Due to the large number of modules in the installation as well as their size, would be impossible to confront the sources of all maintenance. Thus, the CFO will not obligate the MANAGER to check all maintenance, but part of them as follows: The selection of modules to have their maintenance checked by the MANAGER and made at the same time of authorizing of the same, this selection can be done in two ways:
1. 2.

If the module has the RESTRICTED attribute, attributed by a MANAGER through its function RESTRICTED ACCESS TO MODULES (U.5).
3.

If the module is not restricted, the CFO will make a drawing according to the RISK of the SERVICE ORDER which it is connected.

4.

Once selected the CFO will present on the approvers screen the difference between the amended version and the version cataloged in production. The approver can approve (PF5) or reject.

5.

ONE-TIME PROGRAMS

The programs considered ONE-TIME modules will have the letters "OT" in bytes 5 and 6 of the program name, these modules will be kept in a special library for a period of one month, and sources will be maintained in the LIBRARIAN for 1 year. The elimination of both the object and the source will be automatic. A complete description of the program ONE-TIME should be made through the system PDOC.

CFO FUNCTIONS

0 SETUP

0.1 - POST JOB

In this option you define the characteristics of your card with the information that will be used by the CFO at the time of submission of JOBS. (Member ZZZZYCFO)

0.2 PHONE

In this option, you can change your phone number which will be displayed in logging functions directory of SERVICE ORDERS and directory MODULES IN TRANSIT.

0.3 - MASK FOR THE DIRECTORY OF OS This option will serve to create a mask for the permanent directory of SERVICE ORDERS, as the mask constructed to chat up "PF4" is valid only during the session of the CFO.

0.4 - MASK FOR MODULES DIRECTORY Follows the same criteria of the previous items

1 MODULE READING This option is used to transfer the modules supply ALREADY CATALOGED, to LIBRARY of ROSCOE of the user that runs it. The users can only inform modules that belong to their department.

2 - INFO This option is used to obtain detailed information about modules ALREADY CATALOGED. They encompass destination, log, etc.., But also the last emergency cataloging done. Users can only obtain information about modules belonging to their department, except to all the Heads and to the sectors CHANGES, CATALOGING, TECHNIC PREPARATION and AUDIT.

3 - CATALOGING IN EMERGENCY. Used to request emergency cataloging.

4 - OPENING OF SERVICE ORDERS ORDERS. Used to request the opening of service orders.

5 - DIRECTORY OF SERVICE ORDERS. ORDERS.

This option allows the HANDLING of SERVICE ORDERS, the directory provides some basic information such as: a) NUMBER OF SERVICE ORDER, obtained by the CFO. b) STATUS situated on the right of the number of SERVICE ORDER and may be: I (inactive), meaning that the ORDER is not yet able to receive MODULES for not having been approved by a PROJECT MANAGER. A (active), meaning that the ORDER is active, able to receive modules and not dependent on the approval of any HEAD involved for the beginning of the modules cataloging. * (Closed), means that the SERVICE ORDER was closed because it is URGENT and in need of Heads of SCIENCE involved for your CLOSURE after acknowledgment of the Heads of the OS (will have the status "?") W (Waits) means that this SERVICE ORDER and MEDIUM or HIGH risk, are able to receive modules and are awaiting approval of the Heads involved so that the OS can be closed. F (closed) means that the SERVICE ORDER is in the process of cataloging modules. In this case, the project manager should have delivered all the necessary documentation. ? (Closed), means that the SERVICE ORDER was CLOSED because it was urgent and awaits the completion of cataloging and gathering of the documentation necessary for its closure. E (closed) means that the CATALOGING department already has all the necessary documents about the service and has completed the process of cataloging modules. U (closed) the same description of the prior item to SERVICE ORDERS closed due to EMERGENCY. Note: After a CLOSURE, the OS will no longer be allowed to be included in this module. c) SYSTEM, which refers to maintenance. d) PROJECT MANAGER. e) START DATE, obtained at the time the SERVICE ORDER was actually opened, according to the rules described earlier. f) SCHEDULED DATE FOR SHUTDOWN, prediction for SERVICE ORDER closure, this date may be updated during its existence. g) IDENTIFICATION, brief description of the activity.

Through option 5, the SERVICE ORDERS may be manipulated as an instrument with the following commands: CMD "A" - Elects a PROJECT MANAGER of a SERVICE ORDER when he/she has a status of "I" and the field MANAGER still unfilled. - Approves the CATALOGING of MODULES when the ORDER SERVICE has the status "W", the executor for an AREA HEAD involved.

CMD "C" - Includes modules on a SERVICE ORDER. This inclusion can only be performed by the AREA HEAD, PROJECT MANAGER and his BACKUP, PROJECT LEADER and PROGRAMMERS INVOLVED. These programmers may be users of other areas that have participation in the service. This command can only be executed for SERVICE ORDERS that have the status "A" or "W". CMD "D" - Eliminates the SERVICE ORDER from the directory, however, this function will be executed only if the ORDER has not received modules via the command "C". This can be performed by the AREA HEAD, PROJECT MANAGER and his BACKUP and PROJECT LEADER. CMD "E" - This command can only be executed by the CATALOGING department in the case of the O.S. CLOSING CMD "F" Terminates the SERVICE ORDER. After this, you can no longer receive modules, and may have its existing cataloging process complete. This can be performed by the AREA HEAD, the PROJECT MANAGER and his BACKUP. After the closure of the ORDER, the data for this, as well as data cataloging modules resulting from this work will be stored after the last cataloging module connected to SERVICE ORDER and maintained for a period of two (2) years. CMD "H" - Prevents the SERVICE ORDER for purposes of CATALOGING, as long as it is performed by a HEAD involved in the service. CMD "I" - Allows the viewing of information regarding the SERVICE ORDER such as: detailed description, auditor, elected programmers, risk, etc.. CMD "L" - Allows the viewing of LOG OPEN, APPROVALS, IMPEDIMENTS and CLOSING OF SERVICE ORDER. CMD "P" - Prints THE SERVICE ORDER as well as the log cataloging of modules already cataloged. CMD "Q" - Allows the viewing of risk analysis questionnaire answered by the opening of the OS CMD "S" - Allows the viewing of the MODULES relationship connected to this SERVICE ORDER. CMD "U" - When executed by the AREA HEAD responsible for SERVICE ORDER, PROJECT MANAGER and his BACKUP, it allows the update of the fields PROJECT MANAGER, BACKUP MANAGER, PROJECT LEADER, EXPECTED END DATE and LIST OF PROGRAMMERS INVOLVED. When executed by the PROJECT LEADER, it allows the update to the LIST OF PROGRAMMERS INVOLVED. CMD "X" - Allows the assignment of modules to be changed by a PROGRAMMER. After running this command, the executor must provide the name of the user who will receive the modules, and then the modules that will be changed (the same form of the command "C").

6 - DIRECTORY OF MODULES IN TRANSIT.

This option allows the HANDLING of the MODULES. This directory provides some basic information such as: a) MODULE, name of the module in question. b) OS, number of SERVICE ORDER "CO which the module is connected in case of cataloging in EMERGENCY in this field will be EMERGEN. c) USER, the name of the user who executed the command "C" in option 5. d) TYPE, module type, previously described. e) DATE, the date that the module was included in the SERVICE ORDER, using the command "C". f) STATUS, situation in which the module is at the moment. When the module is connected to a SERVICE ORDER with status "W", this will appear in HIGH-LIGHT. Through option 6, the user can manipulate the modules having as instrument the following commands: CMD "A" - Approves the maintenance of the module in question, and should be performed by the AREA HEAD responsible for the SERVICE ORDER, the PROJECT MANAGER or his BACKUP or PROJECT LEADER. Approves the cataloging in production, when executed by the PRODUCTION MANAGER. Acknowledgement of cataloging in EMERGENCY, when executed by the AREA HEAD and the PRODUCTION MANAGER, for modules that have been cataloged in emergency. CMD "B" - This command must be executed by users in the CHANGES area, and when in STEP 4 of the cataloging process, it reports to the CFO that it was not performed to test the module in question passing it to the next STEP ( by-pass). CMD "C" - For modules which await cataloging, via normal flow, this command does the cataloging modules and can only be executed by the Cataloging department. In case the module waits for the CATALOGING IN EMERGENCY, this command can only be executed by a TECHNICAL TRAINER. Upon the completion of cataloging emergency and the implementing of other steps described later, the module will enter the status "AWAITING COPY" ,at this time, the cataloging department should use this command for ADJUSTMENT OF EMERGENCY. For modules that are awaiting for the test CHANGES, catalogs in its test environment. CMD "D" - Eliminates the module of the line of modules in transit, except when the cataloging process has already started. The source module should return to the LIBRARY of the ROSCOE of the performer after the completion of the command. This can be performed by the AREA HEAD responsible for the service, and his PROJECT MANAGER and BACKUP, PROJECT LEADER or the user.

CMD "E" - This command can only be executed by the CHANGES area and informs the user that the test module were unsuccessful. In this case, the CHANGES ANALYST, must complete a screen, describing the problems in the test, after that, the module entered in an error condition and can only be manipulated by the commands "D" and "R". CMD "G" - This command requests TEST / APPROVAL of the module, which can only be executed by the user, and the source should be in the LIBRARY ROSCOE. After running this command, the user will no longer have access to the source until the end of cataloging. CMD "I" Allows the access to relevant information to the module such as, DESTINATION LIBRARIAN, TEST-LIB, LIB-DEST, LANGUAGE, DESCRIPTION, etc.. CMD "K" - Tells the CFO that the tests performed by the CHANGES area, were successful. This command can only be executed by a CHANGES ANALYST. CMD "L" - Tells the user DATES, NAMES, TELEPHONE, etc.., of all who participated in the process of module cataloging, as well as the comments made by the user to the CATALOGING department or by the CHANGES ANALYST during the error in the test CMD "M" - Transfers the module that is in transit to another user, may only be performed by MANAGER / BACKUP or HEAD of the area. CMD "N" - Transfers the module that is in the LIBRARY of ROSCOE of the user to NATURAL. CMD "O" - Allows the user to view the LOG INFO and the OS which the module is connected. CMD "P" - Prints the MODULE source in question, this command can only be run by user with profile PROGRAMR and involved with the service. CMD "Q" Informs the list of module Books in question and its location, could be the LIBRARY ROSCOE (prefix user), BOOK (librarian of books) and CFG (in transit). CMD "R" - This command returns the module to the initial STATUS, returning the source to the LIBRARY of ROSCOE user. This can only be run by the same. When the module is already in 1 * status, this command clears the queue of previous trials such as the production manager's approval, by-pass area changes and comments given by the command "V". CMD "U" - This allows the update of DESTLIB when the target is variable, it can only be run by the cataloging department. CMD "V" - This command allows any user involved in the flow of module cataloging, send messages to the cataloging department, these messages will appear to the cataloguer at the time of execution of the command "C", who may opt for running the command or not. Note: In case you need to refer the cataloging under HOLD, HOLD = TYPRUN specify in the comment field.

CMD "Z" - This command requests PRIOR approval from the PRODUCTION manager for modules cataloging. This approval will allow the continued flow of cataloging module without the need of involving the changes area, so when you run the command "G" for the module in question, this will only need the approval of the PROJECT MANAGER for it to pass to the status "AWAITING CATALOGING. Note: The approvals will be made by a previous manager of production regardless of whether the work order is closed or still active. The commands performed in the option 6 can be executed for groups of modules as follows: Type XX (where x represents the desired command) to the left side of the first module block, XX again to the left side of the block and the last module hit "ENTER . " All modules resident queued modules in transit will be automatically deleted one year after its date of creation.

7 READING OF MODULES MODULES (WITH DESTINY)

This function is identical to the number 1, but allows you to inform the user that will receive the modules.

U UTILITIES

This option gives access to a menu containing some support functions for users of CFO.

U.0 - Printing SERVICE ORDERS closed. This option allows the printing of data referring to the service orders already closed.

U.1 - Requesting DELETE / MOVE of MODULES. This option allows you to request DELETION and CHANGE to another department, of modules already cataloged. After executing this function, the request must be authorized by a PROJECT MANAGER, PRODUCTION MANAGER and finally executed by the cataloging department (CMD "C").

U.2 - Registering USERS / MODELS. This option enables the creation, updating and deletion of USERS and TEMPLATES, it must be performed by any user and approved by the MANAGER user who is being CREATED, DELETED or UPDATED (via the main menu option 6).

U.3 - List of registered users. This option allows you to view the list of users that are registered in the CFO.

U.4 - Print log. This option allows you to print the log by selecting the desired types, dates, department, etc...

U.5 - RESTRICTION / RELEASE of modules. This function allows the HEAD of the AREA or PROJECT MANAGER to restrict the manipulation of a module. The modules may be restricted to UPDATE / READ or UPDATE only. Only the user who made the restriction may release the module to another, except when who is releasing it, is the HEAD of the AREA.

U.6 Printing of modules. This function allows you to print the source of the modules that are already cataloged in the CFO.

U.7 - ACTIVATION/DEACTIVATION of CFO This option will be used by the SOFTWARE area, for possible clearance of problems or to temporarily disable the system. Types of function:

ORDERS Starts the service orders MODULES Starts the modules in transit USERS Starts the users list TUTORIAL Starts the tutorial RE-LOAD - Recharge the resident modules HALTED Stops the CFO ACTIVE Activates the CFO

U.8 - Directory of cataloged modules This issues a report of cataloged modules, from the MASK training of the modules directory in transit.

P - MAINTENANCE OF PROCS, PARMS, JCL and RPFS This function allows the user to request the update/ addition of a new PROC, PARM, JCL or RPF. Upon request, the user has to inform the module name, its description, its type and destination library, after the request follows the process below: NORMAL process.

The most current version of the module or specified in the field "VS" of the option "P", will be transferred to the user library. In case there is a module with the same name, the CFO will make a RENAME switching the 1* byte name for "$".

Requests for approval of maintenance is through the command "G" in the modules directory in transit, at the moment the amended, would source lies in the LIBRARY ROSCOE of the user. After the execution of the command, the source no longer will be accessed unless the user uses the command "R".
Approval by another user of the same area, at the moment the CFO will submit a JOB that will do the module cataloging, which will have the following profile: CFO ... XX where XX and the prefix LINE of ROSCOE the requestor.

EMERGENCY process Solicitation of emergency catalogs through the command 3 in the main menu as previously seen.
Approval of catalogs in emergency by the user, at this time the CFO will submit one under with the characteristics described above, which will make the cataloging.

For modules in the SOFTWARE area:

Acknowledgment of cataloging by the manager of the SOFTWARE area.

Acknowledgment of cataloging by the responsible department by the user that did the cataloging in emergency. In this case, the CFO will submit one which will make the copy of the source to the LIBRARIAN.

For modules of the PRODUCTION area:

Acknowledgment of cataloging by the responsible user that did the cataloging in emergency. In this case, the CFO will submit one JOB which will make the copy of the source to the LIBRARIAN.

Note: For both areas, the module will only be released to be cataloged through the normal process after the regularization of their emergency. In the case of libraries with the same names in two systems, i.e., SYS1.PROCLIB, SYS1.PARMLIB, etc.., its members should have different names for the CFO but may have the same names in the library ex.: @ EASYS00 (CFO) free destination = I SYS1.PARMLIB VOLUME = ESADES free destination IEASYS00 = SYS1.PARMLIB VOLUME = ESAPRO. For the modules to be different in the CFO, the 1* byte of the module belonging to DEVELOPMENT, should be replaced by "@", i.e.: IEASYS production will be IEASYS00 and DESV @ EASYS00 at the time of cataloging, the CFO will replace * 1 byte by byte module before the comma, specified in the DEST.

CATALOGING FLOW OF RESOURCES FROM CICS

This flow of cataloging applies only to CICS resources that can be set online (RDODFEFINITION ONLINE RESOURCE). The cataloging process will follow the following steps: STEP 1 (programmer) Performance of the command "C" next to the SERVICE ORDER in use, and filling of the required fields. The MODULE field must follow the following naming convention for its validation: RDOtxxrs, wherein: RDO ==> prefix T ==> Resource type: (G) = Group; (L) = List XX ==> Abbreviation system / Number affiliate or Cimos (Terminals) R ==> Resource: (F) = File (I) = Printer (T) = Transaction (P) = Program (C) Connections = (G) = Groups (O) = Other O ==> Segment: (G) = GCB (I) = IBF The TYPE field shall be filled with RDO. The DESTINATION field should be: G0 = CSD file of the GCB (CONSUMER) I0 = CSD file IBF (CORPORATE) STEP 2 (programmer) Making or altering the module in question on CICS through the transaction CEDB. Updates will run into one file "cold." STEP 3 (programmer) Request of APPROVAL from the MANAGER, using the specific command through option 6 (modules directory in transit). STEP 4 (project manager,) The AREA HEAD responsible for the SERVICE ORDER, the PROJECT MANAGER or his BACKUP or the PROJECT LEADER, must approve the maintenance of the module through the command itself in option 6. STEP 5 (change) The CHANGES area should allow the groups, using its own command through option 6.

STEP 6 (security code) The SECURITY CODE area should list the groups that are being updated through the option 6 with the command "P". This command will print a list of the group (s) (s) in question. After the conference of the listing, the person responsible for the SECURITY CODE must authorize the module through specific command in option 6. STEP 7 (production) The PRODUCTION MANAGER approves the cataloging through specific command in option 6. In order for him to view the modules to be approved, it is necessary that the project manager CLOSES the SERVICE ORDER. STEP 8 (cataloging) The cataloging is done by the responsible department for such service, through specific command of the option 6. This command will cause the group(s) to be copied from the file "cold" to "hot" (effective).

PROFILES FOR FORMATION OF MODELS

PROFILE
FILDHEAD MNGRPROJ PROGRAMR READONLY INFO

DESCRIPTION
AREA HEAD PROJECT MANAGER PROGRAMMER ABLE TO BE ELECTED IN AN SERVICE ORDER ACCESS OPTION MODULE READING, READING MODULE WITH DESTINY AND PRINT MODULE ACCESS OPTION INFO

Emergence ACCESS OPTION IN EMERGENCY Cataloging OPENOS OSDIR MODIR SPECIAL AUDITOR PROGRAM SHIFT MUDBK MNGRPROD CATALOGS PTECNICA ONLINE BATCH MACRO BOOK DOC RESTRICT MAINT CADAUSER CADAPERF REPORTS REPORTB REPORTC ONETIME APROVESP UTILITI TECNHEAD MAINPROC PROCSOFT PROCPROD EMERSOFT EMERPROD REGLSOFT REGLPROD PROC PARM JCL RPF OPEN ACCESS OPTION OF SERVICE ORDERS ACCESS OPTION DIRECTORY OF SERVICE ORDERS ACCESS OPTION DIRECTORY MODULE IN TRANSIT ACCESS OPTION enabling / disabling of CFO AUDITOR ACCESS MODULE TYPE PROGRAM GENERAL PROFILE OF CHANGES PROFILE CHANGES WITH PERMISSION COMMAND BEK PRODUCTION MANAGER CATALOGUER Technical preparation ACCESS MODULE TYPE ONLINE ACCESS MODULE TYPE BATCH ACCESS MODULE TYPE MACRO ACCESS MODULE TYPE BOOK ACCESS MODULE TYPE DOC (DOCUMENTS) ACCESS RESTRICTION OPTION MODULES SERVICING (DELETE / MOVE MODULE) REGISTRATION OF USERS REGISTRATION OF MODELS REPORT OF SERVICE ORDERS CLOSED LOG LIST OF DEPARTMENT LIST OF REGISTRATION CFO Cataloging ACCESS MODULE TYPE ONE-TIME APPROVAL OF SERVICING AND CREATION / UPDATE USERS / MODELS ACCESS TO UTILITY FUNCTION OUTSTANDING RESPONSIBLE FOR REGISTRATION OF USERS ACCESS TO RINSE FUNCTION OF PROCS, E JCL PARMS Authorizer OF PROCS, ETC THE AREA OF SOFTWARE Authorizer OF PROCS, ETC THE AREA OF PRODUCTION CATALOGUER OF PROCS emergencies, ETC THE AREA OF SOFTWARE AND ENFORCEMENT IN EMERGENCY COMMAND TSS CATALOGUER OF EMERGENCY PROCS, ETC AREA OF PRODUCTION Regularization EMERGENCY MADE BY AREA SOFTWARE (SOFTWARE USER) Regularization EMERGENCY MADE BY AREA OF PRODUCTION (USER OF PRODUCTION) ACCESS MODULE TYPE PROC ACCESS MODULE TYPE PARM ACCESS MODULE TYPE JCL ACCESS MODULE TYPE RPF

SOFTMNGR CFO DESTSOFT DESTPROD SOLTSS MNGTSS TSSSOFT TSSPROD SOFBASIC DOCPROD LEADER FACTORY

AREA MANAGER SOFTWARE (USED FOR ADJUSTMENT OF EMERGENCY MADE IN YOUR AREA) AUTHORIZED USER TO DO IN THE MAINTENANCE OF CFO PROFILE FOR THE AREA OF DESTINATION SOFTWARE PROFILE FOR DESTINATIONS OF PRODUCTION AREA PROFILE FOR REQUEST FOR ACCESS TO FUNDS MANAGED BY TOP SECRET AUTHORISATION OF REQUESTS FOR ACCESS TO FUNDS MANAGED BY TOP SECRET RESPONSIBLE FOR IMPLEMENTING AND SCIENCE IN CASE OF EMERGENCY, THE REQUESTS FOR ACCESS TO FUNDS MANAGED BY TOP SECRET RESPONSIBLE FOR SCIENCE, BY THE PRODUCTION OF REQUESTS FOR ACCESS TO FUNDS MANAGED BY TOP SECRET, EXECUTED IN EMERGENCY PERMISSION TO REQUEST SPECIAL COMMANDS TSS ACCESS MODULE TYPE DOCPROD CFO USER ABLE TO BE THE LEADER OF USER OF FABRICS OF DEVELOPMENT RIO

MASKS FOR DIRECTORY FORMATION

Due to the large number of SERVICE ORDERS and MODULES IN TRANSIT, managed by the CFO, through the PF4 (for service orders) and PF5 (for modules in transit), the user can create the directory according to the needs combined with the data in one MASK, having as the replacement character "+". Each filled in field will be connected to the same through the operation BOOLEAN "AND". After filling in the desired fields and hitting "ENTER", the user will have formed the directory according to the criteria specified.

GENERAL CONSIDERATIONS
a) All the CFO screens will be assisted by HELP for each field to be filled, so in order to know what to type in a field, just position the cursor in the desired field and hit "PF1". b) Certain functions of the CFO will be LOGGED in a VSAM file and may be listed when necessary, they are: Reading of modules Cataloging in emergency and all its regularization process Opening of service orders, its approvals, impediments and updates - Creating of modules in the service order, as well as the whole cataloging process - Registration, updating and deletion of users. c) Through the main menu (PF2) the CFO user will have access to a function that allows you to send messages to other users of the CFO; these messages are displayed upon entry in the CFO.