How can I be sure IÆm doing my job?

How can I be sure IÆm doing my job?
An Original Composition by Gene of GHTROUT.com

YouÆve got a Meridian 1 and everyone looks at you when the phones act up. You might not be sure how you inherited this job, but hey - the thing runs well and you figure you are doing as much or more than the last person. If there is a problem, the system calls the vendor and they fix it remotely. If the telco lines go down, youÆd hear about that in like 3 seconds!

Programming the system is mainly a time you can relax in a chair. ItÆs come down to just adding and changing groups of sets with a periodic big move. Every so often you get a very complicated request and it involves changing more than just sets.

You do all of those things exceptionally well. But how can you be sure you are doing your job?

Can you be sure the phone restrictions are ôreallyö correct? Do you know if ôeveryö mailbox is subject to the restriction permission lists? Did the person before you leave the programming is pristine condition?

Are the bills being reviewed by someone else? Do they know that the operator assisted calls to area code 779 could be corrected in a few seconds by your adding it to BARS?

All right û enough of that. Let me tell you some personal experiences...things IÆve uncovered at new jobs during my discovery and audit phase during the first weeks and months of every job IÆve had. Here we go:

ò The lobby phones were restricted from local calls. However they could dial International calls.
ò There are three long distance T1s, but 40 NPAs are pointed to the local trunks.
ò An upgrade to add TNs to the system has been proposed, yet there are 50 TNs programmed without any cross-connect wire. These were disconnected but never ôOUTedö.
ò The six M2250 Operator Consoles has never shown Calling Party Name Display and nobody ever though to ask why not. It was never turned on in the Customer Data Block.
ò Everyone heard about the new long distance rates, but nobody noticed the bill was still at the old rates û for three years.
ò They told employees that the phone system was one of the more feature rich and advanced systems available. They were correct, but a year later, half of the phones did not have the great features turned on in the Class of Service.
ò ôThere are TIE lines to our distribution centerö. There were, but the coordinated dialing plan that was added later only had local trunks in the routing list.
ò ôWe use a virtual dialing plan between all branches. ItÆs part of our long distance serviceö. The dialing plan was fine, but nobody thought about the long distance rates that applied when branch offices less than a mile apart used it to call each other.

OK, so what is the point of all these items? Consider these:

ò None of these problems existed when the system was first installed.
ò The contracted Technicians caused some of the problems. The telecom person caused some as well.
ò Can we blame someone else when it took over a year or more to realize things were messed up?

That is the point! the title of this article comes together...öHow can I be sure IÆm doing my jobö

Every system has errors û some errors might be years old. LetÆs say you have 100 users missing a feature or sometimes the phone ôdoes odd stuffö. Of those 100 people, 50 or 60 think about the problem for a millisecond and then go about working. 10 or 20 might think ôthis phone system sucksö. Of those 10 or 20, five of them may seriously think about reporting itàthose 5 people smart enough to figure you would be interested also think you are a genius and know about the problem already.

Now letÆs take it a step further. What about the problems that have no functional effect. No user would know. Unless you go deep inside the system, you might never noticeà.that is, until the ôbilling auditorö shows up. These auditors are often hired because a senior officer or VP gets the call from them. They produce names of respected companies and rattle off how much they saved. You might be the last person to find out that someone else is verifying lines or long distance patterns. Will you get in trouble? No, but the people upstairs will be reassured you are ôjust the phone personö and a brick wall will appear between you and the pay raise you hoped for. If you had only taken the time to verify that BARS was perfectà.if you only took the time to compare the Telco records with your cross~connect.

Oh dear. I am sorry but it gets worse. The auditor finds outgoing calls on what you generally reserved for incoming. Or maybe he finds an international call every few days at 10:00PM. Ya, someone knows how to dial out from Meridian Mail. Whoaàyou are lucky it was an employee and not a ôPhone Call Dealerö in New York, selling your access to hundreds of people each week.

Enough already. ôWhere are we going and whatÆs with the hand basket?ö you might be asking. Hopefully IÆve made the point that your system has problems waiting to be found. Rather that leave you hanging with ôyou better find themö, I put together a list of tasks you can use as a starting point.

Daily or every few days:

ò Review two consecutive days worth of Midnight Routines - you'll see both CPUs - be able to tell what is important and what is insignificant.
ò Rotate backups considering the number of changes that are made - daily when a lot of changes are made or weekly if not.
ò On a two drive system, a weekly rotation is fine in my book.
ò Premise visit for environment, smell (I mean sending burning transistors or something that reminds you of the TV that fried).

Weekly or every few weeks:

ò Review five consecutive days worth of Midnight Routines - you'll see the advanced LD137 tests - be able to tell what is important and what is insignificant.
ò Check Trunk operation - During the day use LD60 and watch things operate - also do the same test after hours to see if an unusual number of trunks are busy when they should not be. This is often trunks locked to each other. Use the LDIC command (List Days Incoming - days since last incoming call) to see if some trunks never take calls. On analog trunks, go to an Attendant console and use the Barge In feature to select every trunk one by one (instructions sent at your request)

Monthly or so:

ò Physical cleaning of filters if needed. Moving dust around increases the likelihood it will find its way into more places that if you just left it.
ò Simple security audit:
ò Count number of sets (use LD81) with the items I have on my audit page (heading is "GATHERING DATA FROM LD81")
ò Print DISA and look for changes
ò Print passwords to see if any have been added/changed
ò Do a search in voice mail looking for restriction permission errors (that can get very detailed).
ò Run a LD90 NET printout and make sure all entries are still where they should be. Run a LD86 printout and make sure the selection order and FRLs are correct. I do this monthly and every few months I find something that someone "forgot to undo".
ò You can refer to my M1 Security Audit at GHTROUT.com for some more detail.

6 months or when you feel like it:

ò Use the "netty" program from Dave Higham (start at GHTROUT.com for a link) and search for inconsistent station programming. Thinks like NCOS wrong, TGAR not set, CLS oddities, etc. You can also capture a TNB and do ôfindö on text strings. Or, use LD81 to list many things (not TGAR though). Did you ever make a table of mailbox numbers and compare them to PBX extensions?
ò Gather a few days worth of Inventory Station Reports (LD117) and see how many TNs come up without a phone being detected. (This is just more detailed that the LD30 NWS and LD45 BSD outputs that show disabled sets). Keep this list and run the same report in a month. If the same TNs are on each report, maybe they can be outed. If you need TNs, this is handy, otherwise who cares if nobody is complaining.
ò In old MerMail systems, you were smart to look for aging mailboxes - but newer systems can be set to delete unheard messages, keeping some control over disk space.

I think this is a good start. To some readers, many of these tasks are in uncharted waters. If I were only allowed to do two things, they would be these:
ò Start a formalized rotation of backup tapes/diskettes.
ò Dig through Meridian Mail/Call Pilot learning every possible screen that relates to security. Checking or create user Class of Service models with really well thought out Restriction Permission tables û then move every user into a Class of Service. To find users that are not in a Class of Service, use the ôFind Usersö command looking for CLS 0 (zero)