.                       .
         __ __._____._____:_____._____._____._____:_____._____._____
        :  Y  :  _  :  _  Y_ _  :  _  :  .  :  ___Y __  :  .  : ____:
--------|  _  |  _  |  |  _/ ___j  _  |  |  l___  | \_  |  |  | \_  |--------
 _\\//_ |  :  :  :  :  :  |  L  :  |  :__:  :  |  |  /  :  |  :  |  : _\\//_
 (_o,O) `--'--'--'--'--'--^-----'--'--'  `--'-----^-----'-----'-----' (O.o_)
   " "                                                                 " "

Manager's Guide To


by Psyclone

I thought i'd better get this file out seen as it's the most recent system that bt have set up. I believe it will actually be in mass use in the near future - about 3 / '96. It's basic use is to request axs on most , (not all) bt internal systems (eg CSS) for a particular work team. The requests are made by the team manager as the rest of the team does not have access to this system. The accounts are set up using a hierarchy structure. It is a big but relatively simple system when compared to others... Read and understand. More at the end. This file is for informational purposes only.



        1. Logging On

        2. Updating/Checking User Details

        3. How to Enter a Request
            a) current/existing users
            b) new users
            c) temporary/agency people
            d) modify existing access

        4. Notification of Passwords and UserID's

        5. Displaying Existing Requests

        6. Expired Temporary/Agency ID's

        7. Deleting Access

        8. Transfering UserID's

        9. Temporary Substitution

        10. Projects

        11. Administrators

        12. Responsibilities

        13. Security

        Appendix A

        Appendix B

     Request Handling System (RHS) has been introduced to provide a standard
and secure method of requesting access to mainframe systems.
     RHS is a management only application and will not be made available to
non-management grades under any circumstances.
     The system is OUC/hierarchy built and will allow line managers to submit
access requests for their direct reports and the reports of their peer
managers with the same OUC structure.

RHS is a menu driven system like CSS and will enable you to, generate a request for system access, monitor any existing access requests input by yourself or by others in your hierarchy, and generate a temporary/agency ID.

It would be advisable on your first entry to RHS to spend a small amount of time (15 mins) checking and where necessary updating your work team members using transaction MPD with their Employee Identification Number (EIN) . You can screen dump these details to check at your leisure and update at your convenience.

In the appendices at the end of this document are listed all the database identifiers and some general searches for common systems.

Please note that when requesting access you can not ask for tnet and ibm applications on the same request. These must always be kept separate as it may cause a delay in reiceiving your requests.

  1. Logging On:-

When first loaded RHS will show the last option on your NC menu. Log on to RHS in the normal manner with your UserID and password. You will be automatically be presented with your personal details screen.


DATE:06/11/95      Modify Personal Details for AG00006       EIN:80197794
 Time:14:04:17                                               User:lcjap04
 Panel:EBT0522                                           Terminal:W41MOA53
 EIN        ==>  AG00006
 Surname        <R> BODY            Building code
 First Initial  <R> A               Post Point   <R> 301
 Second Initial                     Addr line 1  <R> TELEPHONE HOUSE
 Familiar Name  <R> ANDY            Addr line 2      MOOR LANE
 User OUC       <R> NDO651          Addr line 3      PRESTON
 Employee Status<R> AGEN            Post Code    <R> PR1 1BA
 Job function                       User Phone   <R> 01772267454
 Grade                              User Fax
 EMAIL ID                           Home TNET site
 Business unit                      TNET Userid
 CSS Profile                        Home M/S site
 CSS User Manager                   M/S Userid
 NC userid                          NC Acc NODE  <R> LC
 Managers EIN   <R> 811977945       Network Type <R> SNA
 Owned by           LCJAP04
 Transfered to      LCJAP04         Expiry Date      30/01/96
 Please confirm personal details are correct:   Y/N <  >
 Enter "Y" and press ENTER to update the profile

 F1-Help   F-End   F9-Applications   F11-Authority

     If all your details are correct:-
            type Y in the selection field and press ENTER

     If any of your details are incorrect or omitted:-
            type N in the selection field and press ENTER
            This will change your screen to enable you to MODIFY your
            details. When all your personal details are correct press ENTER.
     If you have omitted any mandatory fields <R> you will be unable to exit
this screen and will reiceive a red error message at the bttom of the screen.
Enter the missing details and type Y in the selection field and press ENTER.
You will now return to the initial screen. Type Y in the selection field and
press enter to confirm your details are correct.

You should now be looking at the Managers Main Menu.

NB:You will be asked to check your personal details are correct at each logon. Please ensure that your details are always correct and are kept up to date. RHS is built with OUC hierarchies to ensure that no problems occur you must always keep your own and your direct report's details correct at all times.

     2. Updating/Checking User Details:-

     Enter a transaction MPD  - Modify Personal Details or type 5 - onto the
command line from your managers main menu or type 5 on command line and press

Type the EIN of the person requiring update in the selection field and press ENTER.

This will provide you with an an updatable version of the personal details screen. This is similar to your own personal details screen and must be completed in the same way.

On this screen you can also change the UserID, this would be used when accepting the ownership of transient ID's, for temporary/agency people or when people are transfering between OUC's (for more info see section 8).

When you have completed the required changes and all mandatory fields have been completed, type Y in the selection field and press ENTER to confirm details are correct.

     3. How to Enter a Request:-

Please note : Always make a note of the job referance number for future use.

a)Entering a request for an existing user.

Enter transaction RUAA onto the command line of the main menu. Press ENTER. Enter the EIN for the relevent user into the selection field and press ENTER. You will now have a screen containing the user's details. Confirm user details are correct and if they are type Y into the selection field and press ENTER. If the details areincorrect type N into the selection field to enable you to MODIFY the user. Once you have corrected the details press PF4 to return and press Y to confirm the changes.

You will now be presented with the Application Selection List. To select the required option(s) type S on to the adjacent command line, multiple selections can be made. Press ENTER when you have selected all the required options.

You are also able to search for specific options by entering a generic key into the search field at the top of your screen. For example by entering the key +++CICP1 you should be presented with a list of all CSS databases. If you enter the database identifier i.e. A41* you will be presented with all applications running on that database.(see appendices).

Once your search is complete you must enter * into the search field and press ENTER to return to the main application list. Searches can be made any many times as needed.


Date:06/11/95            Available Applications screen          EIN:80197794
 Time:14:28:38                                                  User:LCJAP04
 Panel:EBT0222                                              Terminal:W41MOA53
     Search for Application => *

  TYPE S against he application you require access to or H for help.

     S   System Name                   For      At       Applid   Symbolic
     - ------------------------------- -------- -------- -------- --------
       LONDON WEST END NETVIEW AOC                       A#OAO    A#OAO
       LONDON WEST END LTS                               A#OCICIP A#OCICIP
       LONDON WEST END CSS                               A#OCICP1 A#OCICP1
       LONDON WE/LW/WR CSS TRAINING                      A#OCICT1 A#OCICT1
       LONDON WEST END EQUIFAX                           A#OCICWP A#OCICWP
       LONDON WEST END CONTROL-D                         A#OCTMS  A#OCTMS
       LONDON WEST END PHOENIX/CBT                       A#OF     A#OF

  NOTE : If NC, TNET or Multsess is required request them as an application.

  F1-Help   F4-Cancel   F7-Back   F8-Forward


NB:Please note only ten applications are allowed per request reference number, but if one of the applications need to be rejectedto you for any reason, the whole of the request will be rejected/returned to you and you will need to re-submit.

Once you have selected all your options you will be asked to validate your selections. If you select an option that already exists on the users NC menu the word duplicate will appear in red next to the option on your validation screen. If the applications listed are correct you must then state what network modifications are needed, either TNET/MULTSESS/NC. NB:If the user already has the option on their MULTSESS/NC menu as in the case of NSVM there would be no network modification therefore all selection fields would read N. Please note you should never enter TNET and NC modifications on the request.
Also this screen has the option for additional TEXT. If further information is required to enable the access to complete successfully ie. printer details or where a user needs reinstating after none use and the option still shows on their menu, it should be entered into the text. Now type Y in the selection field to generate the request. If the options are incorrect type N and drop back to reselect.


Date:06/11/95        Application selection validation        EIN:80197794
Time:14:39:25                                               User:LCJAP04
Panel:EBTO242                                           Terminal:W41MOA53
 Access is required to the following applications :

  System name                  For      At       Applid    Symbolic

LONDON WEST END CSS A#OCICP1 A#OCICP1 Menu changes :- NET menu..Y/N <N> M/S menu..Y/N <N> NC menu,,Y/N <N> Text Y/N => N Category(Pri) => 3 Target date => 14/11/95 Type Y if correct - N if incorrect => < > PRESS ENTER to generate the request. F1-Help F4-Can __________________________END__OF__SCREEN____________________________________

If you entered Y into the text selection field you will now drop to the text screen. Enter your required text and press PF3 to drop back to the generated request. You should now see a display of your generated request, take a note of the request number for fututre use, check all of the user details are correct then press ENTER.

b)Requests for BT people with no UserID

If you need to enter an access request for a new user (someone who has NEVER accessed ANY mainframe computing system.) Enter the request as a current user but leave the UserID field blank. RHS will automatically enter TBA and an id will be issued during the processing of the request. You will see the UserID on completion.

c)Requests for new Temporary/Agency people

All non BT people must be issued with a Temporary / Agency EIN, which is easily identifiable by its format of AG000001. All these EIN's are programmed to be reviewed at regular intervals. Before these EIN's are issued you must be holding a signed copy of the confidentiality agreement and no request should be made until this has been obtained. Please note as reqesting manager you are responsible for these user's, for the access and for any work they undertake. Temporary / agency EIN's can be transferred between managers but must not be reissued to new incoming people. When you have decided that a temporary / agency ID should be issued enter the transaction RNAID onto the command line from the main menu. Read the warning message on the screen and type Y in the selection field and enter a review date no later than the expected date of leaving.


Date:06/11/95        Add a new AGENCY / TEMP userid             EIN:80197794
 Time:14:47:47                                                  User:LCJAP04
 Panel:EBT0902                                              Terminal:W41MOA53
RNAID _________________________________________________________________

  WARNING   You are about to allocate a userid for a non-BT person. As a
            manager you must hold a signed copy of the CONFIDENTIALITY
            AGREEMENT for the agency or contract person to support this
            request. The use of this ID will be monitored and you will
            be liable for any unauthorized access or misuse.
            By typing Y in the field below you are accepting full
            responsibility for this user in line with the Computer Misuse
            Act and the BT Security Manual & the Data Protection Act.

   Please confirm you understand and accept the above: (Y/N)  <  >

   Please enter a review date for user ID : (DD/MM/YY)  <04/02/96>

   Press "ENTER" to flow to the available application list.

 F1-Help  F4-Can


At the top of the next screen is the temp/agency EIN for your user, in the format, AG00001, please keep a note of this for future use.

You must now enter ALL known personal details for the user, taking care that all mandatory fields are completed, now type Y to confirm that all details are correct.

You should now be in the application selection list and from here be able to enter the request as for a normal user. NB : Please ensure that you have read and understood the warning message on the initial screen of transaction RNAID before issuing a temp/agency ID.

d)Modifying Existing Access

Transaction RUAM allows you to modify existing access.i.e.:adding datasets to existing TSO applications.

Take transaction RUAM from the main menu and enter the EIN of the user requiring the modification.

You will be presented with a list of users with existing access. Select the application requiring modification with an S on the blue command line and press ENTER.

Leave all network details as N as there is no cahnge necessary to the users network details. Check the details and enter Y into the completion field if they are all correct.

Then you will be presented with an additional text screen. You enter the details of the required changes here. (You may not enter profile changes for CSS).

Press PF3 to quit the text screen and you will be presented with a screen showing your modified request. Press enter to complete the transaction.

     4. Notfication of ID's and Passwords:-

     For the initial release of RHS the user will still be notified of his

UserID and password by letter from CSO or the adminisratator.

The letter is notification that CSO have completed their element of the request. Any system adminisrators must complete their work before the user can gain access the the system. If after the letter is received access cannot be gained, the system administrator must be constacted to ensure that their work has been completed.

If the people still cannot gain access after password and ID's have ben issued then please report this lack of access as a fault via the Service Desk on 0345 414243.

     5. Displying a Request:-

     a) DAR - Display Access Request

     To display individual jobs use transaction DAR, these requests are

entered by yourself or your peer managers from the hierachy structure.

From the main menu enter transaction DAR onto the command line and press ENTER. You will then be presented with a multiple choice menu for different search options.

 Request     = >  If you have the number of the request you wish to view
                 enter it here and no further fields need be completed. This
                 will then display your individual request.

 OUC         = >  By entering a line managers OUC All requests entered for
                 that OUC will be available to any line manager in the same
                 OUC hierarchy.

Symbolic = > If you enter the symbolic of any system (i.e. a41cicp 1 LC

                 CSS) you will bring up a list of requests containing that
                 symbolic , including mixed requests.

 EIN         = >  If you search by EIN you will bring up a list of all
                 current requests for that user.

From Date = > A list of all requests on and from tha particular date.

To Date = > A list of requests on or before a particular date.

Closed Y/N = > All closed requests for your OUC structure. Rejected Y/N= > All rejected requests for your OUC structure.

From any of the above you will be presnted with an Access Request List. To select request details type S on the adjacent command line and press enter. This will display the individual request.

From here you can check the progress of the request, the individuals User ID and any other details.

Using PF keys you can navigate your way around extra detail, a list of accessible information is available at the bottom of the screen. A help screen is available on PF1.

b) DOR - Display Outstanding Requests

This will give you a breakdown of all your recent requests.

Type DOR on to the command line from your main menu and press enter.

This will bring up a multiple choice screen, from here you can have a quick over view of the progress of your requests.

Please take note of the requested and completed queues as it is your responsibility to to close these requests once you have read and understood any messages the user has physically accessed on the systems.

     i) Rejected Requests:-
     These are your responsibility to close. Please ensure that you always
     monitor this queue.

     Take option 1 off the multiple choice menu and you will be presented
     with a list of the rejected requests.

     To check the details of any of these requests type S on the adjacent
     command line and the reason for rejection appears on the bottom of the
     screen. Please ensure that you read and understand the reason for
     rejection before closing the request.

     To close the request
      -press PF4 to return to the main list
      -type C on the adjacent command line and press enter.

     If you have closed the job successfully the request will disappear from
     main list.
     ii) Completed requests
     Like the rejected requests these are your responsibility to close. It is
     advisable that you do not close any request until the user has access
     the system. Although RHS will tell you that the job has been completed,
     users must not attemp to access the system until they have received
     their password etc. After the user has physically gained access to the
     required system you can now close the request.

     Take option 2 from the multiple choice menu of DOR.

     You now have a choice
     -if you are sure the user has gained access and you know the request
     number concerned you can close the job from this screen by typing C on
     the adjacent command line.

     -if you do not know which request number you wish to close you can check the
     details by typing S on the adjacent command line and then returning via
     PF3 to close.

     Once the request is closed it should disappear from the list.

     iii) Waiting Authorization
     When selecting this option you will be presented with a list of all your
     jobs awaiting authorization. To check the detail of any of these type S
     on the adjacent command line and navigate around the details screen
     using the PF keys. To return to the main list press PF3.

     iv) Waiting Completion
     This option will provide you with a list of all your requests held by
     computer services and operations (CSO). These requests have been
     authorized and are now awaiting completion. The letter you receive is
     sent out on the day of completion so this is a good check to see if your
     user has access to the system. As before you can check the details of
     individual requests.
     6. Expired Temporary / Agency Ids:-

When you have entered a temp/agency ID you were gived or stated a request review date. When the IDs reach this expiry they show on the transaction DUPPU option 2.

This will bring you up a list of all temp/agency IDs which are past their review dates.

You now have two alternatives.

If the temporary / agency ID user is still working for the company, you can select the user ID by typing S on the adjacent command line. You can now modify personal details with a new expiry date.

If the temp/agency person has left the company - all that pesrons company must be deleted using transaction RDTUA.

This queue must be monitored and kept up to date at all times. As a manager you are responsible for these IDs and the people who have access via them. This is inline with the Computer Misuse Act , the BT Security Manuel and the Data Protection Act. The use and user of this ID will be monitored and you are liable for any unauthorized access or misuse and as such are auditable.

     7. Deleting Access:-
  1. RUDA - Request User Deletion from Application
     This option is to delete specific applications from your main menu when
     other access is still required.

     Reqest transaction RDUA from a users main menu.

     Enter the persons EIN that requires an application deleting from their
     TNET/NC/MULTSESS menus.

     You will be presented with a list of the users applications. From this
     list select the application requiring deletion by typing S on the
     adjacent command line.

     You will be asked to validate your request. Before doing so check the
     applications listed are the correct ones you wanted. You are also asked
     to state where the option requiring deletion resides, NC , MULTSESS ,
     or TNET. There is also a text option on this screen for you to add extra
     information where necessary. To use this option type Y in the text
     selection field.

     Once you have completed this screen to your satisfaction type Y in the
     selection field and press enter to generate the request.

     Take a note of the generated request number and then press enter to

b) RDTUA - Request Deletion of Total Users Access

     This transaction is for total deletion of of the user computing access.
     It must only be used when people:-
           a)are leaving or have left the company
           b)no longer require ANY computing access to BT systems.

     For the total deletion of a users access select transaction RDTUA from
     the main menu and enter the users EIN.

     You will now be presented with the users personal details and a list of
     their current applications. There is also a text field available if
     required. Check the automatic target date is agreeable with your time
     scales if so type Y in the confirmation field and press enter. If not
     then type a realistic timescale date.

     If you entered Y in the text selection field you will now have
     opportunity to enter your required message. To return to the generated
     request press PF3.

     Make note of the generated request number and press enter to complete.

     NB : This transaction is yet to be installed but bt will probably have
     it done by may i suspect...
     8. Transferring UserID's:-

RHS also gives you the ability to transfer users between managers. You do this using transaction MPD from the main menu.

Go into the transferring persons details and type the receiving managers User ID into the transfered ID field remembering to update the users OUC and address details.

When the ID's are transferred they appear on the receiving managers DUPPU queue option 1.

To accept ownership of the ID's just type Y in the selection field and then press enter to confirm.

     9. Temporary Substitution:-

Non managers will not have access to RHS.

This means that during periods of annual leave a managers substitute will not be permitted to submitt any requests.

However any other manager in the same tier three group will have the facility to enter any necessary requests for your people.

10. Project Work:-

Occasionally in BT you find that all of your people need access to the same option. For example when all engineers needed access to CSS to input their time sheets. We realise that in cases like this it would be unrealistic to expect managers to input requests for each work team member.

In this case N&SO Access Management would be willing to treat these requirements as a project and would expect to receive a paper (available from Access Management on request) listing all details and input this information direct. This would only be done once managers and N&SO Access Management had dates and required timescales.

If any further information is required on the requesting of project work please contact your local N&SO Access Management group.

11. Administrators:-

Some systems require background work done by adminisrators to allow you to access your required system successfully. Although you can see the option on your screen, there may be extra work to be done.

The administrators in most cases are contacted by N&SO Access Management and you would never have to have any dealings exept with access management. Unfortunately some system administrators require their own forms completing and the managers signature for audit purposes.

Users must refer to local documentation issued by the administrators to confirm whether a separate form must be completed. Failure to complete this criteria could result in a lack of access to the reqired system.

12. Responsibilities:-

With RHS there are clear responsibility demarcation lines.

  1. Line Managers - Line managers are responsible for the upkeep of their peoples personal information. They must always ensure that they are kept up to date.

Managers are auditable on their peoples access. Users should only have access to the systems required for their present jobs. All non-relevant access should be deleted from the users menus.

Managers are responsible to ensure that their RHS queues for completed or rejected requests are up to date.

They must also keep DUPPU lists up to date.

b) N&SO Accesss Management -
Access managememt is responsible for the authorizing of all N divisions access request. All N division access requests come through NDO65 access teams.

Access management must ensure that:-

      -the requested access is relevant to the users job.
      -the user has not already got access to the system.
      -all administrators of the required systems have been contacted and
       have done their extra work.
      -check that system profiles are proper to the users job description.
      -requests are entered on to CSO's work queues correctly.
      -new UserID's are issued in the correct format according to the
       National Access Manual.

Access Management must also:-

      -liaise with CSO / administrators / users about any problem jobs.
      -liaise with / advise managers where they have queries about which
       access is applicable for their people.

CSO - Computing Service and Operations.

CSO are responsible for:-

     -the addition of the option to the users network menu.
     -providing the network links from terminal to required systems.
      Software only, any hardware required requests must go through on
      computing services requests forms which are obtained via the helpdesk.
     -completing the requests and issuing the users with letters informing
      them of their UserID's and passwords.

13. Security:-

BT's security policy is documented in the new COMPUTER SECURITY MANUAL available from ISIS distributors.

RHS has been introduced to provide a SECURE and auditable medium for the control of access to all BT's mainframe systems. All requests must be input by a manager - line managers are the only people who will have access to RHS.

RHS is OUC based and managers will be able to access the requests of their peer managers within the same Tier 3 structure.

Managers are also responsible for the deletion of any access no longer required by their people. Be that through change of responsibility or the user leaving BT. If the access is no longer needed for any user, a manager MUST issue a deletion request.


        Appendix A:-

All the databases have identifiers, here is a short list of the most common ones.

    BLETCHLEY A            -  AFA
    BLETCHLEY B            -  A10
    BRISTOL RDC            -  A2D
    CENTRAL MIDS           -  A37
    CITY OF LONDON         -  A98
    COSMOSS                -  ACOA
    EAST ANGLIA            -  A19
    EAST OF SCOTLAND       -  A8A
    EXETER RDC             -  A2DID
    GLASGOW FOMIS          -  AFMG
    IPSWICH A              -  AIPA
    IPSWICH B              -  AIPB
    LANCS & CUMBRIA        -  A41
    LIVERPOOL              -  A09
    MANCHESTER             -  A4B
    NEWCASTLE              -  A23
    PRESTON RDC            -  A5F
    SCOTTISH STORES        -  A5F
        APPENDIX B:-


TNET application symbolics are usually the same as the name on your TNET menus but you are still able to search on these to be sure on your request before you send it. Here are a few of the most common TNET applications.

WORKMANN - Workmanager networks
WORKMANC - Workmanager customer facing.

To check if there is more that one symbolic for these applications enter a (*) after the application name to check for extra symbolics. For example WORKMAN* will bring up all workmanager symbolics.


You will find once you start requesting your peoples access using smbolics that you will use some of them over and over again. Here is a list of the most common cymbolics used by N&SO Access Management.


   A1DCIC*                     ACPS
   +++CICP1                    CSS
   ++++CIZ*                    COSMOSS
   AFMG*                       FOMIS-Glasgow
   A2D*                        MIDLANDS STORES
   A14CICPB                    MID WALES & WEST FOMIS
   +++MULT*                    MULTSESS
   +++NCAC                     NC ACCESS
   A32CICPC                    NI FOMIS
   AIPACI1F                    OHMS
   A5FSNWUR                    PRESTON RDC STORES


hmmmmmm... the security on this system looks to be relatively high as there are so many people involved in validating an account , I would be willing to bet that the actual method of validating accounts detailed in this document is not what actually has to happen. BT seem to have these rigid structures which look very strict and secure , but is reality the officials are cutting corners all the time - if an engineer needs access to css to continue with a job , he isnt gonna want to wait for a few weeks just so that all the highly ranked people can look at his request form before validating it and say hmmmmmmmm look what power we have. It all seems to be a waste of time. Anywaze this system looks to be pretty important and i suspect after a while it will be looked upon as the 'central' BT mf system.

hav' phun ... P/meD

 o \_  _   _  \__   _    \______    \_O
   _/   \_/   _/    ______/    |   __/
 +-\     |    \     |    \     l    \-+
 :  \____l____/\_________/\_________/ :
 :                            present :
 :a breakdown of bt's newest mf system:
 :  the  Request Handling System      :
 :                      by Psyclone   |
 `-------- -- -- -------- --  - -- ---'