the present invention will now be described below . for the convenience of the reader , additional components and information will be hereinafter described with reference to the terminology and references utilized in the above - noted documents . as shown in fig1 a and 1b , greta interfaces with wfa , hilda and a react 2001 host . the react 2001 host system is a product of hekimian , inc ., located in rockville , md . the wfa host is a product of bellcore , located in murray hill , n . j . a connection between greta and the wfa host may be provided via a tcp / ip socket ( see fig1 b ) and , for example , an ibm 3270 interface of an ibm rs6000 computer , where greta emulates a printer port to the wfa host . such hardware is known to those skilled in the art , and thus , is not described in detail herein . the connection between greta , the react 2001 host and the hilda host , and the connection between hilda and the nma host may also be provided by tcp / ip protocols . in particular , greta may connect to the react 2001 host and hilda via tcp / ip or telnet , and hilda may connect to the nma host via tcp / ip or telnet . it is noted that telnet - will provide the user with an interface to execute procedures that are run on the remote device . although shown in fig1 a as separate systems , greta and hilda may be provided on the same client / server platform , wherein information and data are transferred via a file access or memory access . in addition , greta provides a system wherein a user may login and utilize a single password to access other systems , with no need to login and enter a password for each of the other systems . as denoted by the double arrows in fig1 a , greta may support simultaneous sessions with multiple wfa hosts . as noted above , the user interface provides a mechanism to transfer data among the various applications and platforms connected to greta , such that data may be quickly and easily accessed to speed the process by which customer trouble reports are resolved . greta , which was written using a high level language application programming interface ( hllapi ) and tcp / ip , automates the sending and receiving of data from the wfa / c interface . greta connects to a plurality of servers and uses its gui interface to communicate with wfa / c . greta &# 39 ; s scheme allows users to eliminate the need to perform redundant and tedious actions within wfa / c by clicking a button , clicking a menu option , or hitting the “ enter ” (“ return ”) key on a keyboard . information is laid out in a list and scrolling window form . two main windows are displayed when greta is executed . the first window is the menu bar , which contains a series of menus that the user will need to handle routine setup , logging on and off the system , choosing colors , displaying already selected windows , and bring up on - line documentation . the second window is the toolbar . the toolbar is a row of buttons that can bring up the screens necessary for proper maintenance analysis on a given trouble ticket , bring up windows to specify circuits and ticket numbers , and call a pick - up command . from the toolbar , the user can also start up hilda , which is an automated isdn test tool , react 2001 gui and a semi - automatic testing window . both the menu and the taskbar are always open and can only be closed when greta is terminated . the ticket window in greta is opened from the toolbar and gives the user the ability to view multiple trouble tickets within different centers , function level codes , and color . unlike wfa / c , greta automatically updates the ticket display window , so the user does not have to worry if the most current ticket list is being viewed . the ticket window also allows the user to sort the ticket according to the ticket status , bring up a trouble report screen , and print the ticket list , all with the click of a mouse button . another significant screen is the trouble report screen . the user can point - and - click to the screens that will allow quick and accurate handling of the trouble ticket , including the adding of remarks , checking the status , etc . fig2 illustrates the flow chart of greta . according to the present invention , user default files are read in ( inputted ) at step s 1 when the system is first initialized . thereafter , a series of default files , such as , for example , a file related to authorized users , are inputted ( step s 3 ), and a menu and taskbar are displayed on , for example , a display associated with the computer system ( step s 5 ). at this point , greta begins a main application event loop process ( step s 7 ), which is illustrated in greater detail in fig3 . as shown in fig3 , the main application event loop process enables the user to select from a plurality of activities . these activities ( routines / options ) include , but are not limited to : a routine to select and setup a desired printer ( step s 100 ); an employee activity routine ( step s 200 ); a time sheet routine ( step s 300 ); a greta size routine ( step s 400 ); a greta color routine ( step s 500 ); a greta bell sounding routine ( step s 600 ); an e - mail routine ( step s 700 ); a greta color setting routine ( step s 800 ); a work force and administration ( wfa ) backup routine ( step s 900 ); a wfa screens routine ( step s 1000 ); a greta security routine ( step s 100 ); a window cascade routine ( step s 1200 ); a greta help routine ( step s 1300 ); a window select routine ( step s 1400 ); a save placement routine ( step s 1500 ); an about routine ( step s 1600 ); a maintenance ticket window routine ( step s 1700 ); a ticket specify routine ( step s 1800 ); a specify circuit window routine ( step s 1900 ); a pickup ticket routine ( step s 2000 ); an osstr screen routine ( step s 2100 ); a test routine ( step s 2200 ); a semi - automatic test routine ( step s 2300 ); a wfa screens by ticket routine ( step s 2400 ); and a close application routine ( step s 2500 ). the printer setup activity routine of the present invention is illustrated in fig5 . when the printer setup routine is executed , step s 102 is performed to display a list of printers on an associated monitor . meanwhile , a determination is made as to whether the user selected a close ( exit ) button on the display ( step s 104 ). if the close button was selected , processing proceeds to exit the printer setup routine ( step s 106 ). on the other hand , if the close button was not selected , processing proceeds to step s 108 to determine whether a printer has been selected . as long as a printer has not been selected , the list of available printers to select from is displayed on the monitor ( steps s 102 to s 108 is continuously repeated ). however , once a printer is selected from the displayed list , step s 110 is executed to confirm the selected printer , and a user printer file of the selected printer is created at step s 112 . thereafter , processing returns to step s 102 to display the list of available printers and determine whether the close ( exit ) button has selected . the employee activity routine is illustrated in fig4 . when the employee activity routine is selected ( step s 200 ), a determination is made as to whether a user is logged into the system ( step s 202 ). if the user is logged in , processing proceeds to obtain wfa employee activity ( ossea ) information and determine whether , the ossea is successfully obtained ( steps s 204 and s 206 ). if the ossea is not successful , an error message is produced and the user is permitted to edit the user input ( steps s 208 and s 210 ). however , if the ossea was successful , step s 208 is skipped , and thus , the error message is not produced . the wfa request is then processed step s 212 ) and a determination is made as to whether the “ exit ” button has been selected ( step s 214 ). when the “ exit ” button is not selected , a determination is made to determine if the time sheet activity should be executed . if the determination is affirmative , the employee activity routine is terminated and the time sheet activity is executed ( steps s 214 , s 216 , s 218 and s 300 ). on the other hand , if the determination at step s 216 ( e . g ., whether to execute the time sheet routine ) is negative , processing loops back to step s 210 to permit editing of the user input . however , if it is determined that the “ exit ” button has been selected , processing terminates ( step s 220 ) without executing the time sheet routine . similarly , if it was determined at step s 202 that a user is not logged in , processing exits . fig1 illustrates the time sheet activity routine performed by the present invention . according to this routine , an initial determination is made as to whether the user is logged in . when it is determined that the user is logged in ( step s 302 ), wfa vos1sign information ( e . g ., sign on , sign off information ) is obtained . if the information is valid , the user is able to edit the input data , which is then processed by the wfa ( steps s 300 to s 2310 ) if it was determined that the wfa vos1sign information is invalid , an error message ( step s 307 ) is produced prior to allowing the user to edit the input . after the information is processed , it is determined , at step s 312 , whether the “ exit ” button has been selected . when the “ exit ” button is selected , processing proceeds to step s 314 to exit the time sheet routine . otherwise , processing loops back to s 308 to allow the user to edit the input data . fig6 illustrates the greta size activity routine that can be selected from the program illustrated in fig2 . according to this routine , the user is able to select desired system size parameters , such as , for example , the desired size of the menus and toolbar ( steps s 402 and s 404 ). thereafter , step s 406 is executed to exit the greta size routine . the greta color setting activity routine , which enables the user to select desired screen display colors , is illustrated in fig8 . as shown in fig8 , a plurality of colors available to the user is displayed on the monitor . the user selects the desired color ( s ), and then a determination is made as to whether the user accepts the selected colors , or wishes to exit without making a color selection ( steps s 502 and s 504 ). if the user indicates that the colors have been selected ( e . g ., step s 504 is “ ok ”), processing proceeds to step s 506 to set the selected colors . thereafter , the displayed menus , toolbar , ticket window , etc . are redrawn using the desired colors selected by the user , and this routine exits ( steps s 508 and s 510 ). on the other hand , if it is determined at step s 504 that the user does not wish to change ( select ) display colors , processing skips steps s 506 and s 508 , and exits without changing the display colors . fig9 illustrates the activity routine that is executed to provide either a visual or audible indication ( alarm ) to the user when , for example , an error occurs . in this routine , the user selects whether an audible ( e . g ., beep through a speaker ) or a visual ( e . g ., monitor screen color change ) alarm is to be provided at step s 602 . if the audible option is selected , the system is set to initiate an audible beep through an associated speaker when any changes are made ( steps s 604 , s 606 and s 608 ). however , if the visual option is selected at step s 604 , processing proceeds to step s 610 to activate the maintenance ticket border color changes in accordance with the ticket list changes . fig1 illustrates the activity routine for the user to set his / her default e - mail address . if the user selects this activity , the user is shown an e - mail window , with the cursor located at a position where the user enters his / her e - mail address . after entering the user &# 39 ; s e - mail address , the user selects an “ ok ” button on the e - mail window . this results in the user &# 39 ; s e - mail address being saved to a user file associated with the user for future use , and the exiting of routine ( steps s 702 to s 708 ). however , if the user selects an “ exit ” button instead of the “ ok ” button , the routine exits without saving the e - mail address to the user file . this activity routine , illustrated in fig7 , is one of the activities available in the greta application shown in fig2 and enables the user to either exit the greta application , or to close the pop up window to , for example , make another selection in the greta program . according to this activity , a pop up window is displayed on the monitor , asking whether the user wishes to exit the program ( step s 802 ). if the user selects an “ ok ” button , step s 804 is performed to exit the application . on the other hand , if the user selects a “ cancel ” button , step s 806 is executed to close the pop up window without exiting the application . fig3 illustrates the wfa backup routine that is performed by the present invention . when this option is selected by the user , a test is made to determine whether the index file has been found . if the index file is found , the indexed tickets are listed . then , the selected backup is loaded to memory , and the index file is closed . when the osstr , osslog , or owddoc activity is backed up , the selected ticket is backed up , and then the respective tr file , log file , or doc file is read , and the respective osstr window , osslog window , or owddoc window is brought up in a view only mode . the backup activity routine writes all trouble report screens , osslog screens , or owddoc screens that are viewed during the wfa / c up time to a file on a server before the mainframe is shut down . the trouble report , log and word document screens can then be viewed using a view - only window to review certain circuit or trouble ticket activities . when the user selects the bellcore work force and administration — control , the user is present with a series of activities to chose from . these options include , for example , owddoc ; osscn ; osschi ; ossmg ; ossimg ; osshmd ; ossff ; osslr ; ossosstre ; and ossoi . these activities are described in detail in “ work and force administration / control ( wfa / c ) user manual ”, published by bellcore practice , br 190 - 513 - 323 , issue 8 , may 1996 , wfa / c 1 . 7 , the subject matter of which is expressly incorporated by reference in its entirety herein , and thus , is not described in detail herein . the owddoc activity window is a word document window with text search capabilities . when this activity window is selected from the wfa / c screens by circuit , shown in fig3 , processing proceeds to the flowchart illustrated in fig4 , which permits a user to display a word document and circuit / word notes . the word document shows the end - to - end layout of a designed circuit ( message , special service , and carrier ). the screen produced when this window is opened is illustrated at , for example , page 4 - 3 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. in this activity , a word document is retrieved ( step s 100202 ), and a test is performed ( step s 100204 ) to determine whether the retrieval was successful . if an error occurred during the retrieval of the word document , an error message is produced ( step s 100206 ), and the owddoc window is closed ( step s 100208 ). if the document was successfully retrieved at step s 100204 , a document similar to that shown at page 4 - 3 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ” is brought up ( step s 100210 ). at this point , the user can enter data into the document . thereafter , the user can select a load to react activity routine ( step s 100214 , to be discussed below with respect to fig4 ), a test activity routine ( step s 100216 , to be discussed below with respect to fig4 ), a word search activity routine ( step s 100218 ), or a print activity routine ( step s 100220 ). alternatively , if the user is finished with the document , he / she can exit the owddoc window ( step s 100208 ). the load to react activity routine , illustrated in fig4 , determined whether an isdn line or analog line is to be tested . in this routine , a test is initially performed determine whether the user is logged onto the system . if the test results are affirmative , another test is performed to determine whether a ticket or circuit has been called up . if a circuit is called , a determination is made as to whether the circuit is an isdn line . when the circuit is not an isdn line , react 2001 is activated ( steps s 101214 , s 102214 , s 103214 and s 104214 ). when it is determined that the circuit is an isdn line , hilda is activated to test the line ( steps s 101214 , s 102214 , s 103214 and s 105214 ). on the other hand , if it was detected , at step s 102214 , that the document is a ticket , the wfa process is called at step s 106214 , to get a circuit id , prior to testing whether the circuit is an isdn line . similarly , if it was determined at step s 101214 that the user is not logged in , an error message is produced ( step s 107214 ) and processing opens a wfa / c trouble report / activity ( osstr ) window ( illustrated in fig3 ), to be described below . the test activity routine ( s 100216 ) is shown in fig4 , and is similar to the load to react activity routine . for an explanation of the operation of this routine , reference should be made to the load to react activity routine . when the circuit notes ( oscccn ) activity window ( option ) is selected , a window , similar to the window illustrated on page 8 - 7 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ” is pulled up to allow the user to enter and update necessary circuit information in a free - text format . the flowchart for this activity is shown in fig5 and 54 . this screen allows the user to update , for example , circuit notes and customer name , address and telephone number for special services . in addition , the user is given the option of printing the data to a local printer , refreshing the display screen , updating the data displayed on the osscn screen ( window ), copying the data to another location , or exiting the osscn window . when the circuit history ( osschi ) activity window ( see fig5 ) is selected , the user is presented with a circuit history report . this report allows the user to view ( and / or print ) order and trouble report activities for a particular circuit a sample osschi window is shown at page 8 - 4 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. thereafter , processing returns to the wfa / c screens by circuit . the wfa / c multipoint circuit list ( ossml ) activity window ( used to select circuit identifications ), the flowchart of which is shown in fig5 , displays all segments of a multipoint circuit to a user of the system . this window ( a sample of which is illustrated at page 6 - 16 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”) lists all segments with partial circuit identifications that match a “ backbone ” circuit id that was entered in a ckt field . the flowchart for the ossimg and osshmd activities is shown in fig5 . the ossimg window ( step s 1008 ) is used in an order screening process . this window , which is illustrated at page 5 - 2 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ” allows a user to display service order image data stored in the network and services database ( nsdb ). the history measurement data ( osshmd ) activity ( step s 1010 ) is used to display and update ( input ) circuit history information , maintenance and analysis plan for special services ( mapss ) inventory data , and work unit data after orders are completed in the circuit history database . a sample of this window is shown at page 8 - 2 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. in both windows , after the user has input the appropriate data , the user is presented with the option of outputting the data to a printer , or exiting the window and returning to the wfa / c screens by circuit activity window . the ossff activity window , the flowchart of which is illustrated in fig5 , is provided to enable the user to view the nsdb facility - to - circuit database relationships . that is , the user can display the circuits riding directly on a given facility or display the facility that the given circuit is riding on . a sample ossff window is shown , for example , at page 4 - 67 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the line record display ( osslr ) activity window is a “ find only ” screen that shows the entire line record for a given circuit id ( ckt ), circuit access code ( cac ), order number ( ord ), or tracking key / circuit layout order number ( trk / clo ). since this window is a “ find only ” screen , retrieved information may not be over typed and updated by the user . the flowchart for - this activity window is illustrated in fig5 and is shown , for example , at page 4 - 22 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the flowchart for the osstre activity window ( step s 1016 ), shown in fig6 , is provided to allow a user to enter a trouble report on a special device , a message , a carrier , and a non - designed service . the user can add a “ miscellaneous ” trouble report in this window . in addition , the user can add , update , cancel and transfer trouble reports . a sample window is shown at page 6 - 21 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the wfa / c order information ( ossoi ) activity window is a two page screen that shows administrative , tracking and customer / premise order information . in addition , the user can also issue an auto - test request from this screen . the flowchart for this activity is illustrated in fig6 . sample windows are illustrated at pages 5 - 26 to 5 - 28 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. when the ossoi window is opened , the user can select to go to the wfa / c work log ( osslog ) window to display a detailed account of activities on an order or trouble report . this screen , which is a display - only screen , shows activities in date / time sequence with the most recent activity at the top . alternatively , the user can select to go to the word access ( owddoc ) activity screen , discussed above , or exit the ossoi window . the greta security flowchart is illustrated in fig1 . when this activity window is selected by the user , a new menu is presented to the user . in the disclosed embodiment , the new menu provides five options from which to choose : a sign on option , a sign off option , an automatic sign on option , a security file creation option , and a password field update and sign on option . the sign on option executes the flowchart illustrated in fig1 . in this routine , the user attempts to log onto the system and a determination is made as to whether the logon and password are valid . if the inputted data is valid , the user is given access to the system , a confirmation message is produced , and the program exits the sign on window ( steps s 110202 to s 110216 ). otherwise , an error message is produced and the program exits . the sign off option executes the flowchart illustrated in fig1 . in this routine , when the user logs off the system , a log off message is displayed , and then the system exists the sign off window ( steps s 110402 to s 110408 ). on the other hand , if it is determined that the user is already logged off in this region ( e . g ., the user is not currently signed on the system ), an error message is produced at step s 10410 and the sign off window closes . the automatic sign on option executes the flowchart illustrated in fig1 . in this routine , an encrypted sign on file is read and processed to log onto the system . if the encrypted file was successfully processed , a confirmation message is produced , and the automatic sign on window closes ( steps s 110602 to s 110614 ). otherwise , an error message is produced ( step s 10616 ) and the automatic sign on window closes without the user gaining access to the system . the create security file option executes the flowchart illustrated in fig1 . a determination is made as to whether an information file already exists for the user attempting to create a security file . if an information file does not exist , required information is entered by the user , which is then encrypted before this window closes ( steps s 110802 to s 110810 ). should the user make a mistake while inputting the required information , the user is given the option ( step s 110812 ) of reentering the information by clearing all the edit fields . if it was determined at step s 110804 that an information file already exists on the user , the information file is loaded ( except for the password ) ( step s 110814 ), thus reducing the amount of data that needs to be inputted by the user . the update password file and sign on option executes the flowchart shown in fig1 . this option is provided to allow the user to update his / her user profile for signing onto the system ( steps s 111002 to s 111016 ). if the user makes a mistake while updating the user profile , the edit fields can be cleared ( step s 111018 ). the window cascade activity option is illustrated in fig1 . this routine is executed when the user prefers to have the various windows stacked in a cascaded order . when this routine is run , step s 1202 instructs the system to cascade the various windows , as opposed to tiling the various windows . the greta help / tutorial option is illustrated in fig2 . this routine is executed when the user wishes to obtain assistance ( help ) with the operation of greta . when this option is executed , step s 1302 is executed to activate a mosaic session that reads a html help file for display . it is noted that mosaic runs independently of greta . the flowchart for the window select activity option is illustrated in fig1 . this routine is executed to enable the user to activate the desired window ( option ). according to this routine , a list of available windows is displayed . if the user selects a desired window , the selected window is activated and the window select window closes ( steps s 4102 to s 1410 ). on the other hand , if the user decides against selecting a desired window , and instead selects a “ close ” button ( step s 1404 ), the current window closes without selecting a new window to open , the save placement window ( routine ), illustrated in fig2 , operates to write the positions of the menu , toolbar , and maintenance ticket window to a file that is read when the greta application is started . that is , this file contains default information for the particular user , such as , for example , whether the windows should be tiled or cascaded , positions of the menu and toolbar , etc . the greta about window routine is illustrated in fig2 . when this window is selected , information specific to greta , such as , for example , the version number , program creation date and programmer &# 39 ; s names are displayed . the flowchart for the maintenance ticket window is illustrated in fig2 . when this activity window is selected , the system connects to the greta ticket manager ( step s 17002 ), to be discussed below . if a connection can not be established , the maintenance ticket window closes ( steps s 17004 and s 17006 ). on the other hand , if a connection is established , a determination is made as to whether a user subscription file exists . if the user subscription file exists , the information contained in the file is provided to the greta ticket manager and the data sorted by the greta ticket manager is dynamically updated ( steps s 17008 to s 17012 ). on the other hand , if a user subscription file is not found , an error message is produced ( steps s 17008 and s 17014 ), and steps s 17010 and s 17012 are skipped . thereafter , in the disclosed embodiment , the user is able to select from the following options : available tickets only all tickets in progress tickets click on ticket double click on ticket print ticket ticket colors refresh activate set list close maintenance ticket window based upon the above , the user can select to update either all available tickets , all tickets or only those tickets that are in progress ( steps s 17014 , s 17016 , or s 17018 ). thereafter , the greta ticket manager connection is dropped ( step s 17020 ), the connection is re - established ( step s 17022 ), and processing loops back to step s 17010 . when the activate set list activity window is selected , the program illustrated in fig2 is executed . first , the greta manager connection is terminated ( step s 170241 ) and then , the center and specific work group ( flc ) file is selected ( step s 170242 ). the user is then presented with the option of setting a list ( step s 170243 ), using a default list ( step s 170244 ), saving a list ( step s 170245 ), or exiting . when the list set option is selected , the center and specific work group file selected at step s 170242 is stored to the memory before processing proceeds to step s 170246 . when the default option is selected , the user &# 39 ; s center and specific work group selected at step s 170242 is read into the memory before proceeding to step s 170246 . if the save option is selected , the information selected at step s 170242 is saved to the user &# 39 ; s center and specific work group file before processing proceeds to step s 170246 . if the user elects to exit from this window , processing returns to step s 17022 in fig2 . at step s 170246 , the center and specific work group ( flc ) list is provided to the greta ticket manager , after which the activate set limit window is closed ( step s 170248 , and processing returns to step s 17022 in fig2 . when the print option is selected , the program illustrated in fig2 is executed . an initial determination is made as to whether a printer is defined . if the printer is defined , the current ticket is printed , and the print window exits ( steps s 170301 to s 170303 ). however , if it is determined at step s 170301 that a printer has not been defined , another window pops up to allow the user to select a printer ( step s 170304 ). when the refresh activity option is selected , the program illustrated in fig2 is executed to resize the maintenance ticket window to show a maximum of 30 tickets ( steps s 170261 and s 170262 ). when the ticket colors activity option is selected , the program illustrated in fig2 is executed . when this window appears , the user is presented with a choice of new colors . the user can either : accept general default colors ( step s 170282 ), or select a user &# 39 ; s default colors ( step s 170283 ). the user is able to save the ticket colors to a file for future use ( step s 170284 ), and when the user clicks ( selects ) the “ ok ” button , the user &# 39 ; s default colors ( selected new colors ) are activated ( step 170285 ) and the window closes ( step s 170286 ). it is also noted that the user can also exit this window without selecting the ticket colors . when the click on ticket option is selected , the flowchart illustrated in fig2 is executed . in this routine , a ticket that is clicked upon ( using a mouse ) is highlighted and placed in the system memory as an active ticket . thereafter , processing returns to the maintenance ticket window of fig2 ( steps s 170321 to s 170323 ). when the double click on ticket option is selected , processing proceeds in accordance with the flowchart shown in fig3 . specifically , a ticket that is clicked upon is highlighted and placed in the system memory as an active ticket . thereafter , a determination is made as to whether the user is logged into the proper region . if the determination is affirmative , processing proceeds to activate the wfa / c trouble report / activity ( osstr ) screen , which will be described below ( steps s 170341 to s 170344 ). however , if it is determined that the user is not logged into a proper region , an error message is produced and processing returns to the maintenance ticket window of fig2 ( steps s 170341 to s 170343 , s 170345 and s 170346 ). the user may also decide to close the maintenance ticket window . when this option is selected , the flowchart shown in fig2 is executed to close the maintenance ticket window , after which the greta ticket manager connection is terminated ( steps s 170061 and s 170062 ). the greta ticket manager ( see fig6 and 63 ) is called by the maintenance ticket window ( at step s 17002 ) of fig2 . in this routine , multiple connections are established to the wfa / c via tcp / ip sockets . a configuration file ( e . g ., greta . ctr ) is read , and then , a wfa / c pending trouble list ( osspnd ) screen is brought up , via the tcp / ip sockets , for all centers and specific work groups ( flcs ). thereafter , the system waits for a predetermined period of time ( e . g ., 60 seconds ) for requests from the greta ticket window . after the time period elapses , a determination is made as to whether a center / specific work group ( flc ) list was requested . if the determination is negative , it is determined whether a new greta user is online . if this determination is negative , the osspnd screens for all defined centers and specific work groups ( flcs ) are retrieved ( steps s 170021 to s 170027 ). next , another determination is made as to whether the greta user is connected via the tcp / ip sockets . if the determination is positive , the , subscribers are updated ( steps s 170628 and s 170029 ) and processing returns to step s 170024 . however , if the greta user is not connected , step s 170029 is skipped , and thus , processing returns to step s 170024 without updating the subscribers . it is noted that if a center / flc list was requested at step s 170024 , step s 170030 is executed to send the list of available centers and flcs via the tcp / ip sockets , before executing step s 170026 . similarly , if it is a new greta user , at step s 170026 , step s 170031 is executed to send all data for the center / flc requested via the tcp / ip sockets before executing step s 170027 . a sample osspnd screen is shown at page 6 - 195 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the specify ticket activity routine is illustrated in fig3 . when this activity routine is selected , a specify ticket window pops up that permits the user to select a ticket . in particular , the system obtains the user &# 39 ; s input . the user has four options : select the “ ok ” button , select the “ exit ” button , press the “ return ” key , or select a previous ticket . if the “ return ” ( also referred to as “ enter ”) key was entered while in the ticket field , a determination is made as to whether the user is logged into the selected region . when this determination is affirmative , a request is made for either a wfa / c maintenance pool worklist ( ossavl ) window or a wfa / c trouble report / activity ( osstr ) window . if the ossavl window is brought up , the user selects the line containing the desired ticket . the selected ticket is then placed in the specified ticket window and processing returns to get additional user inputs ( steps s 180002 to s 180018 ). on the other hand , if the osstr window is brought up ( i . e ., no for step s 180010 ) ( or the “ ok ” button was selected by the user ), the presently displayed ticket is made active for all ticket actions , and then the specify ticket window closes ( steps s 180002 to s 180010 , s 180020 and s 180022 . it is noted that if the user decides to select the “ exit ” button processing jumps to step s 180022 , to close this window . the specify circuit window activity flowchart is illustrated in fig3 . in this window , the current specified circuit is displayed . the user can then input partial cid data , clo data , order number , or cac data . the user then has several options : find a circuit id ( step s 190004 ), clear the user input ( s 190006 ), test the specified circuit ( s 190008 ), load react 2001 ( s 190010 ), get circuit information ( s 190012 ), or exit ( s 190014 ). if the user elected to find a circuit id , and the user is logged into the region , a wfa process is initiated to find the circuit id . when the circuit id is found , an appropriate message is produced , and processing loops back to display the current specified circuit ( steps s 190004 to s 190008 ). the flowchart for executing the pickup ticket is shown in fig3 . as shown in the drawing , when this activity routine is selected , the user selects a desired region , and the wfa / c trouble report / activity ( osstr ) screen is activated using the obtained ticket ( steps s 20000 to s 20005 ). however , if the user is not logged into the region ( step s 20006 ), or it was not possible to successfully execute the wfa / c pickup using the selected region ( step s 20007 ), an appropriate error message is produced and this process ends ( step s 20008 ). the program for performing the wfa / c trouble report / activity ( osstr ) activity window is shown in fig3 - 39 . a center technician ( user ) works on trouble reports from this window ( screen ). that is , this window allows the user to , for example , initiate handoffs , test requests , and make referrals to other centers . in operation , when a ticket has been specified , the osstr activity window is initiated using the specified ticket , and the osstr window is displayed . from the osstr window , the user ( technician ) selects a process from among the following : refresh the osstr screen , send the ticket number to the osslog process window , send the ticket to the owddoc process window , send the ticket to the osstre process window , grab the ticket , drop the ticket , add a remark ( see fig4 ), dispatch the ticket ( see fig4 ), activate a status process ( see fig4 ), closeout the process ( see fig4 ), send the ticket to a printer , initiate a test process , activate a semi - automatic test process ( see fig4 ), display circuit information , display a command menu , or exit . it is noted that if the user grabs the ticket ( step s 210018 ), the osstr screen is refreshed . further , if the user ( technician ) selects the display commands option , the user is presented with three choices : cancel the ticket ( step s 210050 ), get the next ticket on the list ( step s 210052 ), or go to the top of the day ticket ( e . g ., first ticket of the day ) ( step s 210054 ). the semi - automatic test activity routine ( step s 210032 in fig3 ) is shown in fig4 . in this routine , the semi - automatic window is brought up , providing the user with several options , as follows : submit a ticket , clear the form , pop up a list window of semi - automatic information , or exit this window . if the user submits a ticket and he / she is logged in , the ticket and clo ( circuit - layout order number ) is submitted , a confirmation message is produced , and this window closes ( steps s 2100343 to s 2100346 ) the add remark activity routine ( step s 210022 in fig3 ), is shown in greater detail in fig4 . according to this routine , a window pops up that allows a user to append a remark to the log . thereafter , this window is closed ( steps s 2100221 to s 2100224 . the dispatch activity routine ( step s 210024 in fig3 ) is selected when the user wishes to update the osstr with dispatch information . this routine is illustrated in greater detail in fig4 . the status activity routine ( step s 210026 in fig3 ) is shown in greater detail in fig4 . according to this routine , the user is able to call up the wfa / c trouble report / activity ( osstr ) window and update it with status information . the close but activity routine ( step s 210028 in fig3 ) is shown in greater detail in fig4 . this routine is executed to update the wfa / c trouble report / activity ( osstr ) window with close out information before exiting this routine . the wfa / c screens by ticket activity window is illustrated in fig3 . when this window is selected , the user can select from the following : history measurement data ( osshmd ), service order image ( ossimg ), line record display ( osslr ), wfa / c multipoint circuit list ( ossml ), multipoint index ( vjmpi ), wfa / c trouble report entry ( osstre ), wfa / c trouble report electronic bonding ( osstreb ), wfa / c trouble report / activity ( osstr ), word access screen ( owddoc ), wfa / c work log ( osslog ), customer credit allowance ( osscca ), circuit history ( osschi ), circuit notes ( osscn ), customer service charge ( osscsc ); and facility find ( ossff ). several of these options were previously discussed with respect to the wfa / c screens by circuit window ( see fig3 ), and thus , only the options that were not previously discussed will be discussed below . the wfaic authorization ( ossauth ) window , step s 2402 , ( the flowchart of which is illustrated in fig5 ) allows the user to automatically collect and display data associated - with inter - exchange carrier ( iec ) customer authorization requests . this window also collects and displays approval or denial of authorization requests for electronic bonding ( eb ) trouble reports . a sample ossauth screen is shown at page 6 - 52 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the nsdb multipoint circuit index format ( vjmpi ) activity routine ( step s 2404 ), illustrated in fig5 , is a view - only screen that displays ( and prints ) multipoint index circuit data ( also referred to as an index page ). this screen displays critical information about complex circuit arrangements . a sample screen ( window ) is shown at page 4 - 11 of the aforementioned “ work and force administration / control ( wfa / c ) user manual ”. the wfa / c trouble report electronic bonding ( osstreb ) activity window , the flowchart of which is illustrated in fig5 , provides for the collection and storage of additional iec - provided data , such as , for example , information transmitted to wfa / c via a gateway by an iec or other customer . electronic bonding allows a user to take trouble reports from iecs directly via terminal emulation over an electronic gateway . an iec technician can enter iec trouble report information in an osstre - type format . the tr information is passed from the iec gateway to the bcc via a gateway , and from the bcc gateway to wfa / c . when the information ( data ) reaches the wfa / c system , the trouble report information is displayed in the osstre and osstreb formats , and stored in the trouble databases . the flowchart of the wfa / c work log ( osslog ) activity routine is illustrated in fig4 . this window ( screen ) is a display - only screen that shows a detailed account of activities on an order or trouble report . in the disclosed embodiment , this window shows activities in a date / time sequence , with the most recent activity being at the top of the display . the flowchart for the customer credit allowance ( osscca ) activity window and the customer service charge ( osscsc ) activity window is shown in fig4 . the osscca window allows the user to initiate a customer rebate when a trouble duration is greater than a required rebate interval . the osscsc window allows the user to enter customer billing information and to describe work performed by technicians . this data is used by an accounting office for billing purposes . based upon the above discussion with respect to fig4 - 63 , greta executes procedures on the wfa host . the procedures are executed in accordance with known functionalities of the wfa host . to execute a wfa procedure , greta provides an appropriate user interface to populate data to be formatted and transferred ( if necessary ) to the wfa host to run the procedure . once the wfa host has completed the procedure , data returned to greta is formatted and displayed ( if necessary ) on the appropriate interface . when greta calls hilda to perform tests on isdn switches , hilda interfaces with network monitoring and analysis system ( nma ). nma is a product of bellcore , murray hill , n . j . the isdn switch testing procedures ( shown in fig6 ) are executed in accordance with known scripts executed on the nma host . hilda provides a system wherein multiple tests may be performed on the nma host simultaneously . to execute a nma testing procedure , greta , via hilda , provides an appropriate user interface to populate data to be formatted and transferred ( if necessary ) to the n host to run the testing procedure . once the nma host has completed the testing procedure , data returned to greta , via hilda , is formatted and displayed ( if necessary ) on the appropriate interface . when greta calls the react 2001 host to perform remote testing of digital and analog services ( e . g ., private lines ), greta provides an appropriate user interface to populate data to be formatted and transferred ( if necessary ) to the react 2001 host to run the remote testing procedure . once the react 2001 host has completed the remote testing procedure , data returned to greta is formatted and displayed ( if necessary ) on the appropriate interface . other procedures shown in fig4 - 63 execute functions and routines ( e . g ., dynamically linked library functions ) provided by an aix ( or equivalent ) operating system and software running on the rs6000 platform . for example , windowing software , such as x - windowing software ( e . g ., x - motif ), may be provided to create the greta and hilda user interfaces . accordingly , procedures to resize , reposition , and change window colors may be provided by such windowing software . further , procedures to access attached devices ( e . g ., printers ) may be provided by the aix operating system . still further , client software such as wordprocessors and browsers , etc . may be implemented by known client software programs ( e . g , microsoft word and mosaic or other html compatible browsers ). other features and processes may be provided by applications bundled with the operating system ( e . g ., unix mail , unix telnet , unix ftp , and unix man pages ). also , other high level programming languages , such as hllapi , which are compatible with unix based operating systems may be used . additionally , security and access to the system may be limited in accordance with unix security and access features ( e . g ., unix rlogin , and unix yppasswrd ). while the invention has been described with reference to a preferred embodiment , it is understood that the words which have been used herein are words of description and illustration , rather than words of limitations . changes may be made , without departing from the scope and spirit of the invention in its aspects . although the invention has been described herein with reference to particular hardware , software , means , materials and embodiments , the invention is not intended to be limited to the particulars disclosed herein ; rather , the invention extends to all functionally equivalent structures , methods and uses . for example , hardware platforms other than the ibm rs6000 and 3270 may be used . in addition , other software applications may be used to implement the user interface of the present invention than the exemplary applications provided above . further , other communications protocols may be utilized to transport data from one system to another . in addition , the present invention is not limited to interfacing with hilda , wfa and react 2001 hosts , as the present invention may communication with other hosts utilizing the interface techniques of the present invention to format and transfer data . still further , the system of the present invention may notify administrative personnel of errors via other processes than paging , for example , the system may notify administrative personnel via e - mail and voicemail .