Cfo - English_v1

7/28/2019 Cfo - English_v1

1/40

CFOCFOCFOCFO

OBJECTAND

SOURCE

CONTROL


2/40

CONTENTSCONTENTSCONTENTSCONTENTS

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


3/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 serviceexecution must request through the CFO, the opening of a SERVICE ORDER.

SERVICE ORDERSERVICE ORDERSERVICE ORDERSERVICE ORDER OPENINGOPENINGOPENINGOPENING....

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 thework 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 theSERVICE 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.


4/40

INCLUSION OF MODULES IN SERVICE ORDERINCLUSION OF MODULES IN SERVICE ORDERINCLUSION OF MODULES IN SERVICE ORDERINCLUSION 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 batchprograms), 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.


5/40

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 documentationdescribed 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.


6/40

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.


7/40

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 modulecataloging 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.


8/40

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.


9/40

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 *.


10/40

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.


11/40

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.


12/40

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:

1. The selection of modules to have their maintenance checked by theMANAGER and made at the same time of authorizing of the same, this selection can

be done in two ways:

2. If the module has theRESTRICTED attribute, attributed by aMANAGERthrough its function RESTRICTED ACCESS TO MODULES (U.5).

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

4. Once selected the CFOwill presenton the approvers screen the differencebetween the amended version and the version cataloged in production.

5. The approver can approve (PF5) or reject.

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.


13/40

CFO FUNCTIONS


14/40

0000 SETUPSETUPSETUPSETUP


15/40

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)


16/40

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.


17/40


18/40

0.4 - MASK FOR MODULES DIRECTORY

Follows the same criteria of the previous items


19/40

1111 MODULEMODULEMODULEMODULE READINGREADINGREADINGREADING

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.


20/40

2222 ---- INFOINFOINFOINFO

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.


21/40


22/40

3333 ---- CCCCATALOGINGATALOGINGATALOGINGATALOGING IN EMERGENCY.IN EMERGENCY.IN EMERGENCY.IN EMERGENCY.

Used to request emergency cataloging.


23/40

4444 ---- OPENING OFOPENING OFOPENING OFOPENING OF SERVICE ORDERSERVICE ORDERSERVICE ORDERSERVICE ORDERSSSS....

Used to request the opening of service orders.


24/40

5555 ---- DIRECTORY OFDIRECTORY OFDIRECTORY OFDIRECTORY OF SERVICE ORDERSSERVICE ORDERSSERVICE ORDERSSERVICE ORDERS....


25/40

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.


26/40

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 lastcataloging 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").


27/40

6666 ---- DIRECTORY OF MODULES IN TRANSIT.DIRECTORY OF MODULES IN TRANSIT.DIRECTORY OF MODULES IN TRANSIT.DIRECTORY OF MODULES IN TRANSIT.


28/40

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 stepsdescribed 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.


29/40

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 beexecuted 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 theLIBRARY 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.


30/40

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.


31/40

7777 READINGREADINGREADINGREADING OFOFOFOF MODULEMODULEMODULEMODULESSSS (WITH DESTINY)(WITH DESTINY)(WITH DESTINY)(WITH DESTINY)

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

the modules.


32/40

UUUU UTILITIESUTILITIESUTILITIESUTILITIES

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.


33/40

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- Rechargethe 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.


34/40

PPPP ---- MAINTENANCE OF PROCS, PARMS, JCL and RPFSMAINTENANCE OF PROCS, PARMS, JCL and RPFSMAINTENANCE OF PROCS, PARMS, JCL and RPFSMAINTENANCE 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 theoption"P", will be transferred to theuser 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 ofmaintenance is through the command"G" in themodules directory in transit, at the moment theamended, would source lies in the

LIBRARY ROSCOEof the user. After the execution of the command, the source no

longer willbe accessed unless the user uses the command "R".

Approval by anotheruser of the same area, at the momentthe CFO willsubmit 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 menuas previously seen.

Approval of catalogs in emergency bythe user, at this time the CFO willsubmitone underwith the characteristics described above, which will make

thecataloging.


35/40

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 userthat did the cataloging in emergency. In this case, the CFO will submit one which willmake the copy of the source to the LIBRARIAN.

For modules of the PRODUCTION area:

Acknowledgment of cataloging by the responsible user that did the catalogingin 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 andDESV @ EASYS00 at the time of cataloging, the CFO will replace * 1 byte by byte module

before the comma, specified in the DEST.


36/40

CATALOGING FLOW OF RESOURCES FROM CICS

This flow of cataloging applies only to CICS resources that can be set online (RDO-

DFEFINITION 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.


37/40

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).


38/40


39/40

SOFTMNGR AREA MANAGER SOFTWARE (USED FOR ADJUSTMENT OF EMERGENCY MADE IN YOUR AREA)CFO AUTHORIZED USER TO DO IN THE MAINTENANCE OF CFODESTSOFT PROFILE FOR THE AREA OF DESTINATION SOFTWAREDESTPROD PROFILE FOR DESTINATIONS OF PRODUCTION AREASOLTSS PROFILE FOR REQUEST FOR ACCESS TO FUNDS MANAGED BY TOP SECRETMNGTSS AUTHORISATION OF REQUESTS FOR ACCESS TO FUNDS MANAGED BY TOP SECRETTSSSOFT RESPONSIBLE FOR IMPLEMENTING AND SCIENCE IN CASE OF EMERGENCY, THE REQUESTS FOR

ACCESS TO FUNDS MANAGED BY TOP SECRETTSSPROD RESPONSIBLE FOR SCIENCE, BY THE PRODUCTION OF REQUESTS FOR ACCESS TO FUNDS MANAGED

BY TOP SECRET, EXECUTED IN EMERGENCYSOFBASIC PERMISSION TO REQUEST SPECIAL COMMANDS TSSDOCPROD ACCESS MODULE TYPE DOCPRODLEADER CFO USER ABLE TO BE THE LEADER OFFACTORY USER OF FABRICS OF DEVELOPMENT RIO


40/40

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.

Date post:	03-Apr-2018
Category:	Documents
Upload:	leandro-gabriel-lopez
View:	229 times
Download:	0 times

Cfo - English_v1

Documents