Kevin McNamara
(303) 642-7943
[email protected]
Technical Biography
January 2004
Table of Contents
Section
1.
2.
3.
4.
5.
6.
7.
8.
Page
Introduction............................................................................................................................. 1
Smallworld Magik .................................................................................................................. 1
2.1.
Magik Applications Developed...................................................................................... 1
2.1.1.
GE Network Solutions – DM AVA Application................................................... 1
2.1.2.
Level3 - Data Validator ......................................................................................... 1
2.1.3.
Level3 - Work Order Monitor ............................................................................... 2
2.1.4.
Level3 – MIT Vitria Interface ............................................................................... 3
2.1.5.
Level3 – Data Copy Engine .................................................................................. 3
2.1.6.
Duke Energy – Multi-purpose Tracing Engine ..................................................... 3
2.1.7.
Duke Energy – Data QA/Bulk Update via Tracing ............................................... 4
2.1.8.
Duke Energy – Cornerstone Customization .......................................................... 4
2.1.9.
Niagara Mohawk – Gas Leak Survey.................................................................... 4
2.1.10.
Niagara Mohawk – Leak Archive Report ............................................................. 5
2.1.11.
Niagara Mohawk – ACES – Joint Pole Proposal .................................................. 5
2.2.
Magik Scripts/Tools Developed..................................................................................... 5
2.2.1.
Level3 – Print Common Ancestry ......................................................................... 5
2.2.2.
Level3 – Inside Plant Data Query Methods .......................................................... 6
2.2.3.
Level3 – Text Sorted Collection ........................................................................... 6
2.2.4.
Level3 – Load List Generator ............................................................................... 6
2.2.5.
Level3 – Big Rope and Big Hash .......................................................................... 7
2.2.6.
Niagara Mohawk – Association Table Mixins ...................................................... 7
UNIX Shell and PERL Scripting ............................................................................................ 7
3.1.
BellSouth – Pre-Order Gateway .................................................................................... 7
3.1.1.
Volume Test Automation ...................................................................................... 8
3.1.2.
Volume Test Analysis ........................................................................................... 8
3.1.3.
Data Log Analysis ................................................................................................. 9
3.1.4.
Configuration Manager ......................................................................................... 9
3.1.5.
Automated Filename Change ................................................................................ 9
3.2.
Bell Atlantic/Verizon – DSLAM Discrepancy Analysis ............................................... 9
Oracle & PL/SQL ................................................................................................................. 10
4.1.
BellSouth – POG.......................................................................................................... 10
4.1.1.
PSIMS Oracle Data Loader ................................................................................. 10
4.1.2.
DDL Schema Update........................................................................................... 11
4.2.
Level3 – Model.it and NextGen Analysis .................................................................... 11
C/C++ ................................................................................................................................... 11
5.1.
BellSouth – POG.......................................................................................................... 11
5.2.
US West – Log GUI for Protocol Converter Interface................................................. 12
Visual Basic .......................................................................................................................... 12
6.1.
Bell Atlantic/Verizon – DSLAM Discrepancy Analysis ............................................. 12
6.2.
Level3 – Excel Automation within Magik ................................................................... 12
XML/HTML ......................................................................................................................... 13
7.1.
Telcordia – XML/FCIF Translation ............................................................................. 13
7.2.
Niagara Mohawk – NMGAS GIS Web Pages ............................................................. 13
ESRI ArcInfo/ArcView ........................................................................................................ 13
8.1.
University of Wyoming – Master’s Thesis .................................................................. 13
ii
1. Introduction
This document describes information systems software I have developed over the course
of my career. These software development descriptions are organized by programming
language.
2. Smallworld Magik
2.1. Magik Applications Developed
2.1.1.
GE Network Solutions – DM AVA Application
This provides an interface between Design Manager and AVA programs. AVA is an
accounting standard used in cost estimations across utility corporations in Germany.
AVA accounting models in XML format are imported into Smallworld, where
administrators can customize these models for use within their company. Engineers
working in Design Manager associate these custom models to work done in their jobs.
Accounting information for each job is then exported in XML format to AVA programs
outside of Smallworld, where cost estimations are calculated.
I assisted in the internal design and development for several features of the DM AVA
application. A few of these features are described below:
Menu Item Visibility: One major challenge was development of a unified system to
control menu item visibility. The application GUI contains dozens of menu items, each
of which is visible based on the type of data the user has selected. I developed a
framework that allows definition of all menu item visibility from a single point within the
Magik code using a well-defined API.
Hierarchical Search: The AVA data is hierarchical in nature, and therefore is displayed
in trees within the GUI. I developed algorithms and corresponding GUI functionality
allowing users to quickly “drill down” though these trees to find data of interest.
Three-Tiered Architecture: The DM AVA Application was initially developed as a
rapid prototype. I re-engineered the internal design employing a three-tiered architecture
such that data, engine, and GUI code are clearly separated. Going forward, this
decoupling will provide flexibility in customizations. For example, the existing Magik
GUI could be replaced with a Visual Basic GUI without a change in internal
functionality.
2.1.2.
Level3 - Data Validator
The Data Validator provides automated analysis, update, and tracking of records in the
Smallworld VMDS (Version Managed Datastore). Development of this application
began with creation of Magik scripts to assist in the data validation/integrity efforts for
1
Smallworld Model.it inside plant data. These scripts fell into two categories: data query
and data update. Data query scripts output errors and discrepancies in the Model.it data,
while data update scripts provide automated repair of this data. A large number of these
scripts were rapidly created, and a higher level of organization was needed to track their
findings and updates. I developed the Data Validator application to address this need.
An instance of the data_validator class is sent the ‘run()’ message with the name of a
script as an argument. Information on the records flagged and/or updated via the script is
then logged to Data Validator tables in a separate Smallworld datastore.
I integrated Data Validator functionality into the Model.it Work Order Application.
When a user shares changes on a work order (i.e. posts), a Data Validator is instantiated
and specified scripts are run, with the results being saved to the dB. Furthermore, if data
errors are found and cannot be updated automatically, the user is informed of the specific
problem, and the work order is not posted. Errors in work orders occur due to both user
error and data corruption from the Model.it application itself. Some examples of
validations to flag and repair these data errors are:




Find Dislocated Children: Flag any child (‘n’ side of 1:n relationship) inside
plant records whose area geometries are not fully inside their parents’ area
geometries.
Repair Lost Geometries: Geometries for inside plant records sometimes get
into the wrong world, causing them to be invisible in their proper world. This
script finds such geometries and attempts to put them back in the correct world
based on their relational joins. In other words, provided that the foreign key to
traverse from the ‘n’ to the ‘1’ in a 1:n relationship is intact, and the ‘parent or
owner’ record is in the proper world, the ‘child’ record can be returned to that
world.
Repair Orphans:
This is a sort of inverse validation from ‘Repair Lost
Geometries’. If the foreign key on the ‘n’ side of a 1:n relationship is unset, this
record is termed an orphan. Provided that the area geometries of both lost parent
and orphaned child records are set and located properly in the same world, spatial
queries are used to reunite parent with child record via the foreign key value on
the child.
Various Text Validations: These ensured that particular text field values on
records contained valid data based on what type of telecommunications
equipment these records represented.
2.1.3.
Level3 - Work Order Monitor
The need for Work Order Monitor arose due to the large number of conflicts Level3 users
were receiving when posting their work orders for Model.it inside plant equipment. I
developed this application to proactively prevent this conflict occurrence. With Work
Order Monitor in use, if a work order user inserts, updates or deletes equipment within a
Bay, that entire Bay is locked from alteration in other work orders. If users of other work
orders attempt to modify equipment in that Bay, they receive a message that the Bay is
already in an open work order. Also, users have the option to highlight all Bays that are
in open work orders. The back end is a simplified copy of the Work Order Association
2
table, named Work Order Monitor, in a separate non-version managed datastore.
Model.it provides such a datastore for storing template data for inside plant equipment,
and I added Work Order Monitor table to this datastore. This table holds all locked Bays
until the pertaining work orders are closed.
2.1.4.
Level3 – MIT Vitria Interface
MIT Vitria Interface provides a gateway for sending Model.it inside plant relational data
to downstream applications. This application was needed as Level3 chose Smallworld
Model.it to be the source of record for all network inventory data. From a connection to
Oracle within the Smallworld image, data is first sent to an Oracle dB with the same
inside plant relational data model as Model.it. When this process is completed, a trigger
is evoked in the Oracle dB to notify a Java application in Vitria Middleware that the
Model.it data is complete and available for use by downstream applications.
In MIT Vitria Interface’s basic form, all inside plant data is sent (Bulk Load). However,
functionality is also available to send a subset of this data. This subset can be records in
a work order, all inside plant records within a particular internals world, or records
selected via a predicate search. The Bulk Load functionality allows an initial send of all
records when a Model.it database first becomes available to downstream applications. I
modified the Model.it Work Order application to send all rwos (real world objects) in a
work order through the MIT Vitria Interface whenever the work order is posted. When a
new central office becomes available, all inside plant records in that central office’s
internals world can be sent downstream. If somehow, data “falls through the cracks”, and
downstream applications get out of sync with Model.it, the data of concern can be
selected via predicate in Model.it and sent downstream. Together, these functions ensure
that downstream applications are kept in sync with the latest inventory upgrades in
Model.it.
2.1.5.
Level3 – Data Copy Engine
This allows automated copy of Smallworld geometric and relational data from one dB to
another dB in a separate image. The intermediate data storage vehicle is a set of ASCII
text files. A “dump” instance of Data Copy Engine is run from one image to create the
ASCII text files. The information in these text files is then used to populate the other dB
via a Data Copy Engine “load” instance.
Level3 found this functionality very useful during the initial entry of data into Model.it.
This data entry was done on several laptops, each of which stored a Smallworld dB for a
UTM zone where Level3 owned infrastructure and equipment. Prior to creation of the
Data Copy Engine, data was manually entered into each laptop separately from Excel
spreadsheets. This process resulted in extensive repetition of manual data entry,
especially since the inside plant data for each central office was nearly identical. Data
Copy Engine allowed the replacement of manual data entry with an automated process.
2.1.6.
Duke Energy – Multi-purpose Tracing Engine
I developed a tracing engine and corresponding GUI class that utilizes core Smallworld
Network Follower technology. This application provides users with the ability to specify
3
manifold, trace direction (upstream, downstream, both directions, user specified via
trailpoints), network analysis type (trace out or shortest path), and configurations (stop
predicates and weighting types) based on Duke Energy’s specific application needs.
Additionally, the most frequently used parameter combinations can be hard-coded to
provide users with “canned” traces. The Duke Energy tracing GUI can be customized to
include access to these canned traces.
2.1.7.
Duke Energy – Data QA/Bulk Update via Tracing
A number of GeoData developers contributed to this application. This engine provides
automated QA and update of Electric, GAS, and Landbase GIS data. I assisted in
integration of this application with the Duke Energy Tracing Engine to provide
automated analysis and update of electric circuits.
2.1.8.
Duke Energy – Cornerstone Customization
GeoData developed Cornerstone as a foundation for utilities’ Smallworld
implementation. I worked with a team to customize Cornerstone. I assisted in enhancing
the classes and inheritance structure corresponding to the Cornerstone data model to meet
Duke Energy’s specifications. I created a general relationship class for inheritance by
rwos related through a field mapping join. Some examples of such rwo relations are
paths to conductors and structures to equipment.
2.1.9.
Niagara Mohawk – Gas Leak Survey
The Gas Leak Survey application provides facilities for the planning, tracking, reporting,
and mapping of Niagara Mohawk’s surveys for gas main and service line leaks. I was a
member of a team that gathered requirements for this application through extensive
meetings with the end-users to ascertain business needs. These end-users were
operations supervisors (OS). As a result of these efforts, a Smallworld data model and
corresponding Magik application were delivered to meet Niagara Mohawk’s gas leak
surveying requirements. I was the lead developer of this data model and application.
Fundamental to the Gas Leak Survey application is the concept of survey areas and
workdays. A survey area contains a portion of the gas network to be surveyed for leaks
within a given timeframe. A workday consists of all gas mains and service lines
surveyed by a particular worker or crew on a given day. The connection between survey
areas and workdays is modeled in the Smallworld dB as a many-to-many (m:n)
relationship: a worker can complete more than one survey area in a given workday, but
some survey areas take multiple workdays to complete. Thus, survey of the gas network
is administered on two levels: by survey area and by workday. The link between gas
network infrastructure and these administrative levels is enabled through association
tables similar to that used in Work Order applications.
The Gas Leak Survey GUI consists of editors, custom tools, reports, and a Survey Viewer
to geographically view survey work. Through use of Survey editors an operations
supervisor associates gas infrastructure to the survey area. This can be done via selection
of gas objects, definition of an area via a trail boundary, or through selection of a preexisting area object in the GIS (such as a town) to delineate the survey area boundary.
4
Miles of gas line associated with each survey are automatically calculated. The OS can
print a report of all gas lines in each survey for distribution to surveyors before going out
in the field. The OS then uses the Workday editor to track work done towards
completing these surveys. The Survey Viewer provides the OS a variety of GIS views
useful to the planning and tracking of surveys. These views are enabled by custom draw
methods on the gas line objects. For example, due dates for gas lines are calculated based
on their type, location, and date last surveyed. The Survey Viewer then provides a colorcoded map of date until due for survey (by month or year) for all gas lines in the current
GIS view.
2.1.10.
Niagara Mohawk – Leak Archive Report
I was lead developer of the Leak Archive Report. This report allows users to see a
history of changes to Leak records in the Smallworld dB, thus providing a tool to validate
that leaks on the gas network are documented and repaired in a timely fashion.
The Leak Archive Report derives its information from a text join field (named Leak
Archive Text) on the Leak table. This field provides a very large buffer for storing
information on all changes to Leak records. The Leak Archive Text field is populated via
an update trigger on the Leak table. Each time a Leak record is updated, the previous
values of any changed fields are added to the Leak Archive Text field. This information
can be seen as nested key-element pairs. The outer key consists of the Leak record
update date and user, while the inner data consists of field name keys and field value
elements. When a user requests a Leak Archive Report for the current record in the Leak
editor, the information in this text join field is parsed for display in the report.
2.1.11.
Niagara Mohawk – ACES – Joint Pole Proposal
Joint Pole Proposal (JPP) is a component of Niagara Mohawk’s ACES (Automated
Construction and Estimation System), designed to integrate Smallworld GIS work orders
with Niagara Mohawk’s accounting practices. I was a member of the development team
for the JPP component of ACES. JPP provides billing information for work done on
utility poles owned jointly by Niagara Mohawk and one or more other companies. I
created a prototype JPP data model using Smallworld’s CASE tool, and corresponding
billing logic and editor functionality using Magik. A fellow Magik developer used the
information generated by JPP to create custom billing reports stating cost to each owner
for work done. This work involved extensive review of Niagara Mohawk’s billing
agreements with joint owners of equipment, and close communication with electric utility
SMEs (subject matter experts) within Niagara Mohawk.
2.2. Magik Scripts/Tools Developed
2.2.1.
Level3 – Print Common Ancestry
I created this script to assist developers in understanding related objects with complex
common inheritance trees. The need for such a tool arose since Model.it contains several
objects with complex inheritance. This script accepts the names of Magik object classes
as parameters. The output is in the same format as the Smallworld core print_ancestry()
method, except that only those ancestral classes common between all input classes are
5
displayed. This functionality is useful if, for example, you are trying to decide where to
put a new method so that it is available on a specified set of object classes. In this
situation, the input for print_common_ancestry() would be this set of object classes, and
output will be those super classes where the new method can be put such that it is
available on all objects of the input classes.
2.2.2.
Level3 – Inside Plant Data Query Methods
The inside plant data model in Model.it is a hierarchy of 1:n relationships. From top
down, this hierarchy is: Hub, Building, Floor, Room, Bay, Shelf, Slot, Card, Port. The
data model is highly normalized. In other words, there is no field on Port, for example, to
directly access the owning building. Instead, one would have to issue the code
‘port.card.slot.shelf.bay.room.floor.building’. Queries in the other direction (say, to find
all ports in a building) are even more code intensive. I wrote methods on these objects so
that any equipment record can access its related equipment with a single method call. For
example, the code above is simplified to ‘port.q!building’, and ‘building.q!ports’ will
return a set of all ports within a building. This encapsulation of relational complexity
enables subsequent Model.it Magik development to be much faster, producing simpler
code that is easier to read.
2.2.3.
Level3 – Text Sorted Collection
I created this object as a subclass of Smallworld’s core sorted_collection class.
Text_sorted_collection allows sorting of text elements in a more humanly recognizable
order than is possible with standard sorting. In other words, the string “Port 10” will
come before “Port 3” in standard sorts. In text_sorted_collection, this is reversed. The
need for this tool arose due to Level3’s requirement to see hundreds of port descriptions
of this type sorted in a humanly intuitive order. In addition, Level3’s port descriptions
included fractions such as “Port ¾”. I borrowed some basic XML/HTML concepts in
creating text_sorted_collection, in that I treated each string to be sorted as data separated
by markup. The markup were things such as spaces, forward slashes, and commas. The
remaining data is processed based on the nearby markup. This allows logic, for example,
that orders “Port ¾” before “Port 2”, which comes before “Port 10”. The one drawback
of Text Sorted Collection is that it takes a while to sort due to heavy processing overhead.
While Magik is an excellent language for OO Application development and rapid
prototyping, it can be slow in algorithm processing. Therefore, I would like to rewrite
this class in PERL or C++, where it could perhaps be called from within Magik via an
ACP (alien co-processor) if the need ever arose to replicate this functionality.
2.2.4.
Level3 – Load List Generator
I wrote this procedure to automate the creation of load list files in a Magik build tree. In
its basic form, you send in the root path of your build tree directory as an argument.
Load List Generator then recursively creates new load list files based on all Magik files
and subdirectories found at each level. Optionally, you can pass in additional arguments
to specify a load order if necessary. Load List generator provides the obvious benefit of
providing an automated process to replace tedious manual load list maintenance. In
addition, I believe it enforces good file organization within your build tree. If you do not
want a file or subdirectory to get into your build, it probably should not be in your build
6
tree. However, it is crucial to remember that this procedure does overwrite existing load
lists. Also, additional work is needed to integrate Load List generator functionality with
source code management.
2.2.5.
Level3 – Big Rope and Big Hash
I worked with another developer to create these classes. They are designed to handle the
size limitations of the core Smallworld rope and hash_table classes, which could hold a
maximum of roughly 20,000 elements. Internally, the big_rope and big_hash classes
function as ropes of ropes, and ropes of hash tables, respectively. Each of the inner data
structures holds a maximum of roughly 10,000 elements (well within the size
limitations). This behavior is encapsulated on the class methods, so that is it is hidden
from users of the classes. Externally, these classes function very nearly the same as
conventional Magik ropes and hash tables, except they can be used to store many more
data elements.
2.2.6.
Niagara Mohawk – Association Table Mixins
I created these mixin classes to provide reuseable code based on a recurring design
pattern. In this pattern, rwo records are related to some sort of administrative records
through an association table. Some examples of these administrative records are Work
Orders, Valve Zones, and Surveys/Workdays (see description in Section 2.1.8 – Gas Leak
Survey). Rather than rewrite code with the same functionality for each of these, I created
generic mixin classes that the objects and editors could inherit from, and thereby share
common methods. These association table mixins are as follows:




At_admin_obj_mixin: e.g. Work Order, Valve Zone, Survey. This provides
methods for getting information on associated rwos from _self (i.e. the current
object inside its method). Also, methods are provided for getting information on
what objects can be associated with _self. A shared constant must be subclassed
to get this latter functionality.
At_rwo_obj_mixin: e.g. Pole, Valve, Gas Main. This provides methods to
obtain information on associated administrative objects from _self.
At_admin_ed_mixin: This provides methods to goto and highlight rwos
associated with the current record in the editor. Also, methods are provided to
enable the selection of rwos (via geometry selection or trail boundary placement
in the GIS) for association with the current record in the editor.
At_rwo_ed_mixin: This provides methods to view all administrative
associations for the current record in the editor.
3. UNIX Shell and PERL Scripting
3.1. BellSouth – Pre-Order Gateway
I worked extensively with UNIX Korn shell and PERL during my year of Pre-Order
Gateway (POG) software support. A large team at Telcordia developed POG to provide
CLECs (competitive local exchange carriers) a single convenient interface to query
multiple BellSouth mainframe databases. These mainframe databases contain
7
information necessary for providing customers telephone and related services. POG
transactions adhere to EDI (electronic data interchange) standards. Input contracts are in
EDI 850 format, returning an EDI 855 contract as output. Both input and output
contracts are in fixed field (as opposed to delimited) format. My work with UNIX Korn
shell for POG involved scripting, as well as extensive command line work on a daily
basis. This work ensured POG was ready for third party testing, an important milestone
towards BellSouth's entrance into the long distance market.
3.1.1.
Volume Test Automation
POG is not designed to include a direct user interface for production use. Instead, POG is
designed to interface with separate front-end software that provides automation to enable
volume contract processing. Some examples of front-end automation include
instantiation of multiple POG server instances and validation of unique Ids for each
transaction. Since POG itself lacks this automation capability, is not possible to conduct
volume testing directly from POG.
I created a system of UNIX scripts to allow volume testing directly from POG. Using
these scripts, it is possible to instantiate a specified number of POG servers and specify
the set of contracts to run. With multiple servers, these contracts can either be run in
series or in parallel. I manipulated input contracts such that the unique key for each
contract was automatically updated before processing (a task normally allocated to frontapplications). This provides functionality to run a contract several times to test POG
processing limits. These scripts enabled replication of volume testing while removing
front-end applications and related network communication issues from the test scenario.
This proved very helpful in determining the source of defects.
3.1.2.
Volume Test Analysis
Utilizing the volume test automation described above, I was able to locate the source of a
serious performance defect that was delaying third party testing acceptance work. This
defect was manifested during heavy volume testing initiated from TAG
(Telecommunications Access Gateway). TAG communicated with POG across a
network utilizing Orbix (CORBA compliant middleware). Errors occurred during high
volume testing against POG servers on a high-end machine with extensive RAM. Using
the POG volume test automation scripts I developed, I was able to replicate this test
directly from POG. In this scenario, the test ran successfully, demonstrating that the
defect was not originating from POG.
Since the defect was not in POG, this indicated that the defect was due to network issues,
Orbix, or TAG. To help pinpoint the defect source, I developed UNIX Korn shell scripts
to output processing times and result information for each contract. I then sent this data
to MS Excel to calculate and graph comparative statistics between POG servers on
machines with varying amounts of RAM. I demonstrated a direct correlation between
RAM and the number of contracts processed per minute when volume testing was ran
directly from POG. I then installed POG clients on different machines from the POG
servers to determine how the network variable effected performance. In doing this, I was
able to replicate the original error from the original two machines (TAG client and POG
8
server) that the defect was reported on. I analyzed the network and determined that the
connection between these two machines was an order of magnitude slower than between
most of BellSouth’s other machines. This demonstrated that that the volume test errors
occurred due to network issues between these two machines, thus pinpointing the source
of the defect.
3.1.3.
Data Log Analysis
As part of the effort to support POG and TAG third party testing, I wrote UNIX Korn
shell scripts to trace contracts from TAG to POG. These scripts utilized sed and grep
functionality extensively. Essentially, there were several log files that contained
pertinent data distributed across the network. I used sed and grep to filter out the data of
interest from each log file, and then I synthesized this data into information on contract
flow through POG, Orbix, and TAG.
3.1.4.
Configuration Manager
I revised a script that provided configuration and startup assistance for the POG
environment. Essentially, this script ensured that pertinent related software was running
(e.g. Oracle RDBMS, Orbix). If this software was not running, the scripts would output
information on the problem. Otherwise, it would initialize the POG software. This script
no longer functioned due to significant changes in the POG architecture and environment,
and I provided upgrades to make it functional with the current POG release.
3.1.5.
Automated Filename Change
I created a PERL script to assist in unit and acceptance test of POG software releases.
For this testing, several EDI 850 input files are used for each contract type to be tested.
There is a standard naming convention for these files. However, this convention often
changed between POG releases. To automate these name changes (and thereby avoid
manually renaming dozens of contract files), this PERL script accepted as arguments a
search string and a rename string. The script updates the names of all files in scope that
have the search string in their name, with the search string being replaced by the rename
string.
3.2. Bell Atlantic/Verizon – DSLAM Discrepancy Analysis
I worked with an analysis team to create a system of interconnected UNIX Korn shell and
PERL scripts to assist Verizon in detecting discrepancies between their mainframe
SWITCH database, NCON, and real-time query of their DSLAM equipment. Essentially,
this work consisted of comparing DSLAM ports within several central offices across
Verizon’s service area. These comparison scripts enabled detection of several thousand
discrepancies between the these data sources. This discrepancy data was an important
source of information in Verizon's data migration effort from SWITCH to NCON. Also,
this discrepancy data identified records in the NCON dB that were not in sync with the
DSLAM equipment.
There were three main steps in locating these data discrepancies as described in the three
paragraphs below.
9
While the NCON and the DSLAM data were of the same form, SWITCH data was in a
different data model. It was therefore necessary to map the SWITCH data to the NCON
and DSLAM data using lookup tables. This mapping was needed before data comparison
could be done. I wrote PERL scripts to provide metrics on data joined between SWITCH
and NCON through the mappings we identified. These metrics were sent to Excel
spreadsheets for analysis and display (see Section 5.1).
Once the proper mapping between SWITCH and NCON was determined, I assisted in
development of scripts to compare information from the SWITCH, NCON, and DSLAM
data sources. This comparison produces a set of discrepancy reports organized by
geography: one report for the port discrepancies in each central office.
When SWITCH data was fully migrated to NCON, the task of resolving discrepancies
between NCON and the DSLAM equipment remained. I developed scripts to create
reports displaying these discrepancies. These scripts call heavily upon the text
processing, data structuring and reporting functionality within PERL. In addition to the
basic reports describing discrepancies (i.e. Ports in NCON but not on connected on
DSLAM equipment, and ports connected on DSLAM equipment but not in NCON), I
reported on the distribution of these discrepancies. For example, one report lists the
CLLI (common language location identifier) code of each central office where
discrepancies occur, while another report displays discrepancy distribution graphically.
4. Oracle & PL/SQL
I used SQL on a daily basis in my work at Telcordia and Level3 to query and update
Oracle dBs, primarily to support testing and development efforts. Through this work, I
have gained expertise in structuring SQL queries to obtain specific information in a
desired format from relational databases. In addition, I have experience with ‘wrapping’
SQL in PL/SQL and UNIX shell code as described below.
4.1. BellSouth – POG
4.1.1.
PSIMS Oracle Data Loader
I revised a system of UNIX Kornshell/AWK scripts used for text file data loading into
POG’s Oracle dB. The actual data loading to Oracle is accomplished through embedded
SQL in the UNIX code. AWK is used to parse the raw text files to build SQL statements
to load the data. I modified these scripts to enable successful loading of very large text
files. This modification was necessary because the amount of PSIMS (Product and
Services Inventory Management System) mainframe data available had increased
significantly. I carried out this modification though serial loading of all text data by state.
Prior to my modification, all data for BellSouth’s entire operating region was parsed and
then loaded at once. This exceeded system performance limitations when large data sets
were loaded. By parsing and then loading this data one state at a time, the PSIMS Oracle
Data Loader scripts run successfully and do not exceed system limitations.
10
Also, I investigated the possibility of using of Oracle SQLLOAD functionality to replace
the embedded SQL statements in PSIMS Oracle Data Loader. This has the potential of
greatly decreasing load times compared with loading one record at a time using insert
statements. Although this functionality was not implemented in production, I gained a
good working knowledge of SQLLOAD functionality through researching this
possibility.
4.1.2.
DDL Schema Update
I maintained DDL to build POG Oracle database schemas for each release. Numerous
versions of this DDL were needed since the schema changed between releases. For
debugging purposes, it was sometimes useful to test a contract against numerous schemas
in the same release. This keeps the code constant, while testing how changes in the data
model effect bug occurrence. I created scripts to automatically update portions of the
schema definition that have changed with each release. When used in a test environment,
these scripts assist in determining if a defect is caused by data model changes.
4.2. Level3 – Model.it and NextGen Analysis
At Level3, I used PL/SQL extensively in my work on the interface between Smallworld
Model.it GIS and NextGen, the Level3 custom provisioning system. As outlined in
Section 2.1.3, I played a key role in the integration of these two systems by developing a
translator to send the Smallworld data into an Oracle dB (where it was then massaged and
sent to NextGen via Java and Vitria Middleware). This effort did face a challenge,
though, as both Model.it and NextGen had gigabytes of separate production data before
our Middleware went online. Therefore, there were considerable data discrepancies
between the two systems. I wrote PL/SQL code to compare these databases and assist in
resolution of the data discrepancies.
5. C/C++
5.1. BellSouth – POG
I worked as a development team member on three releases of POG for BellSouth
providing enhancements and debugging for the core POG C/C++ source code.
An example of an enhancement provided is the update of specified contract transactions
to return additional customer information data for the CLECs. POG receives extensive
return data from the mainframe databases in response to the EDI 850 contracts it sends to
these mainframes. The POG requirements define the portions of this mainframe data to
be sent back to the CLEC as an EDI 855 return contract. As these requirements change,
the code functionality must be updated accordingly.
An example of debugging I provided is the tracking of contract data at several stages in
the processing to determine the source of bad data in EDI 855 output contracts. When an
output contract does not contain the expected data, the transaction must be traced from
input contract, to mainframe query, to return data, and finally to build and return of
output contract. Character buffers at each point in this process must be queried to ensure
11
they contain proper data. I provided debugging code to output this data from within
methods and then rebuilt the affected POG executables for testing. Through several
iterations of this work I became very familiar with information flow through the POG
C/C++ code structures.
5.2. US West – Log GUI for Protocol Converter Interface
I served as a developer for the initial requirements stages of Protocol Converter Interface
(PCI), an application to support broadband provisioning of video and data service for US
West/Qwest. I created a prototype GUI using Visual C++ to view error log information.
The sample log data viewable with this GUI is based on sample log data descriptions
from PCI requirements documents. These documents describe the log data that should be
output when errors occur. The log data include information on transaction identifiers,
user, error occurrence time, type, code, severity, and description.
The error log GUI prototype I created consisted of three major components: an error log
generator, an error log data manager, and the error log GUI itself. Since this prototype
was developed well before any actual error log files existed, the error log generator
creates random error logs of varying size based on specifications in the PCI requirements
documents. This provides pertinent sample data for the application to work with. The
error log data manager provides a data structure to hold the error log information. When
the error log GUI is activated, the error log data manager is queried to obtain data for
display. The error log GUI provides the ability to filter errors based on user, date ranges,
and/or error types. This provides users with a Windows interface to rapidly to obtain
specific error information from within a large text log file.
6. Visual Basic
6.1. Bell Atlantic/Verizon – DSLAM Discrepancy Analysis
I assisted in creation of Visual Basic code to process text mapping files for DSLAM ports
in SWITCH and NCON databases. These text files were ouput from PERL scripts I
created to provide metrics to assist in mapping SWITCH to the NCON data model (see
Section 3.2). Visual Basic was used to automate the creation of Excel spreadsheets that
display SWITCH and NCON port data related through specified mapping algorithms we
had developed.
6.2. Level3 – Excel Automation within Magik
I used VB automation within Magik to export Model.it inside plant data to Excel
spreadsheets. Members of the team supporting NextGen (Level3’s provisioning
application) used these spreadsheets for comparison of the Model.it and NextGen data.
12
7. XML/HTML
7.1. Telcordia – XML/FCIF Translation
I was involved in the preliminary requirements stage of several projects utilizing various
middleware packages (Vitria, webMethods, etc..) to translate data in Telcordia’s FCIF
(flexible computer interchange format) to and from XML. Through this work I became
very familiar with FCIF, and gained a good working knowledge of XML.
7.2. Niagara Mohawk – NMGAS GIS Web Pages
I used HTML to build web pages on Niagara Mohawk’s intranet describing their
Smallworld NMGAS GIS.
8. ESRI ArcInfo/ArcView
8.1. University of Wyoming – Master’s Thesis
I gained a serious interest in software/database development when working on a thesis in
graduate school. Using GPS and surveying equipment to map headwater drainage basins,
I quickly amassed a great deal of data. I stored this data in ESRI ArcInfo and ArcView
GIS, and in series of connected Excel spreadsheets. I realized the great value of having
an automated system to turn data into meaningful information. In addition, I developed
excellent investigation and communication skills while working on this project.
Although my thesis was in Physical Geography, it incorporated aspects of Civil
Engineering, Geology, Hydrology, Fluvial Geomorphology, Biology, and Range
Management. I therefore needed to communicate with a wide variety of people in
various fields to design my data collection, modeling, and analysis techniques. This
instilled in me an understanding that excellent information system design requires both
human communication and technical expertise.
The main focus of my thesis was a comparison of stream network form and extent on
either side of a vegetation boundary (between forest and grassland). I used Trimble GPS
to map out the stream network in my study region, and then uploaded this data to
ArcInfo, where I created a stream network line coverage. I also created stream network
coverages using map-based stream delineation methods. This enabled a comparison of
stream networks delineated by map and field-based methods. In addition, I created a
vegetation polygon coverage for the study area. I conducted an overlay and INTERSECT
of the stream and vegetation coverages to create updated stream coverages with arcs
broken upon vegetation boundaries. Next, I exported these coverages to ArcView for
analysis. I conducted comparative analysis of drainage density (total length of streams
per watershed area) between the vegetation zones, and for map vs. field delineation
techniques. Also, I analyzed the stream network for a number of topological indices with
ArcView. This GIS analysis facilitated comparison of my results with data from related
field studies and theoretical models of stream networks.
13