Category: Axys


With my long-standing history as a seasoned and impartial technology consultant catering to the wide-ranging needs of Advent users, it should come as no surprise that companies that have moved away from Advent call me to assist them if they have Advent specific needs after their agreements with Advent have lapsed.  In those specific cases, I suspect my independence from Advent is one of the most appealing features of my service, but many Advent users that have ongoing agreements with Advent also retain me to provide a level of service that Advent seems unwilling or unable to provide.

One of the things I get regular calls about is getting Axys running again.  These calls occur either when firms upgrade their servers or when firms that have moved on to competing Portfolio Management Systems dust off their old Axys files with hopes of tapping into Axys again.  My experience consulting to financial services firms using Advent Software for thirty-plus years facilitates my ability to resolve issues like these easily. 

Many of those calls I get start with the caller telling me, “We reinstalled Axys on the server and it isn’t working.”  And inevitably, this tells me more about the underlying issue than the caller ever could.  You certainly can reinstall Axys, but you probably don’t need to because Axys on the server is just a bunch of files that you access from another PC.  The most important thing to keep Axys working properly aside from the proper installation being done (at some point in the past) is making sure that users have all necessary rights to the shared folders.

This article is focused on explaining what the requirements are to empower you or your firm to resurrect Axys.  As usual, I’ll be providing a level of information in this piece that may be more than you need to solve any immediate problem with the hope that info is useful to you in the future.

Axys Versions

There are two fundamental versions of Axys: the multi-user version and single-user version.  To add a little confusion, the multi-user version is frequently referred to as the network version, but both fundamental versions are regularly installed on networks.  So, the network version is a bit of a misnomer.  Among these two fundamental versions, there is also the version of the software, which is at this point typically version 3.8, 3.8.5, 3.8.6 or 3.8.7.  In addition to these, there are also Monocurrency, Multicurrency and Variable Rate versions, to name a few.  Suffice to say, there are a lot of different versions.

Axys Licensing Model

The concurrent licensing model that Axys implements applies to both single-user and multi-user versions.  In both instances, the number of real Axys users typically exceeds the total licensed users, but having a multi-user version allows more than one user to use Axys simultaneously and adds certain multi-user features, such as user-specific settings and separate blotters, et cetera.

Understanding How Axys is Installed

Initially, the single-user version is simpler to install because the primary program (Axys) and supporting programs (Dataport, Data Exchange, Report Writer, et al.) hypothetically only need to be installed once.  That would be true if there literally was only one user using the software on one PC.  In actuality, the single-user version of Axys and supporting programs get installed multiple times in a network environment. They need to be installed once for every user, albeit to the same destination for each user (e.g., F:\Axys3).

During the Axys install process, certain required files are copied to the user’s PC and/or profile and Axys creates registry keys in HKEY_CURRENT_USER\SOFTWARE\Advent.  The most critical Axys registry keys are stored in HKEY_CURRENT_USER\SOFTWARE\Advent\Axys\3.  Although there are several important Axys files, the firmwide.inf is perhaps the most crucial file.  In a single-user installation, this text file, which can be found in the root folder of Axys (e.g., F:\Axys3), details certain settings in use and where all of the other Axys files can be found.

The multi-user version must also be installed multiple times for users, but the initial Axys install varies.  You install it once to the network/primary destination folder (e.g., F:\Axys3) and then install it again for the rest of the users (e.g., F:\Axys3\users\kevin where a firmwide.inf file will be created).  Similar to the single-user version, the supporting programs such as Dataport, Data Exchange and Report Writer would also need to be installed if the user needs those, or if you are trying to make sure all of the users have access to all of the supporting apps. The same registry keys are used for the multi-user install as the single-user version, but the multi-user (a.k.a. network) version adds an additional critical file: the netwide.inf file.

Netwide.inf versus Firmwide.inf

These two files are closely related.  The netwide.inf file should only be found in the root Axys folder of a network install, but firmwide.inf files exist in both single-user and multi-user environments.  The multi-user version is designed to use the settings in the netwide.inf as the system default and have any settings in the firmwide.inf supersede the settings in the netwide.inf.  As a rule, you should never see a firmwide.inf in the root Axys folder of a network install.  You should also almost never see a netwide.inf file in the root of a single-user Axys installation.


A Recurring Axys Installation Bug

With regard to installing Axys, there is a rather annoying issue that has been going on for several years.  It seems that the Axys install will not recognize certain network locations and/or mapped drives.  The fix requires the following registry settings:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]

“EnableLUA”=dword:00000001

“EnableLinkedConnections”=dword:00000001

Once those settings have been applied, the Axys install program will be able to find the mapped drives.  It seems to me that this is an issue Advent should have addressed a long, long time ago.

Understanding Those Axys Shortcuts and Corresponding Registry Entries

The working folder of the Axys shortcut needs to point to the appropriate folder for the firmwide.inf file.  That means that an Axys shortcut for a single-user version of Axys should have a “Start in” folder like F:\Axys3, whereas the multi-user version would have “Start in” folder like F:\Axys3\users\kevin.  Assuming the same install folder was used, the target for these shortcuts would be the same: F:\Axys3\Axys32.exe.  Likewise, the registry entries associated with Axys should match these settings.  When I am looking at a system, I can usually determine if Axys has been installed properly by looking for consistency between the shortcuts and the following registry entries: ExePath, NetPath and UserPath.

In summary, your Axys install is dependent on a few things: the files themselves, access to the location where they are stored and proper mapping to the location of those files in the registry, firmwide.inf and netwide.inf if applicable.  Hopefully, you can get things back online on your own, but if you need assistance with your Advent installation, reach out to me and I’ll do my best to assist you.


Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Schwab is no longer providing price file downloads that some Axys users have relied on for decades.

When I set out to write this, I had some trouble deciding on the title.  At first, I considered “Schwab Hamstrings Pricing for Advent Users”, but that’s inflammatory and not entirely accurate, so I couldn’t do that.

I could just as easily have titled this blog “Stubborn Axys Users Refuse to Embrace Benefits of ACD Interface” or “Axys Users Slow to Hire Consultants to Address Schwab Point-to-Point Interface Changes”, but in truth Schwab is discontinuing their support for Axys in the data they provide directly to their customers via the Schwab download, so I had to go with “Schwab Discontinuing Support of Axys Point-to-Point Interface – Again?”  Besides, picking one of those other titles would have made me write a blog with a different message.  In advance, I’d like to clarify that this issue only impacts the Schwab point-to-point interface and has no effect on those that receive their Charles Schwab data from Advent’s ACD interface. 

I need to apologize to those who have read my blog regularly in the past.  First, I am sorry I haven’t posted anything in a while.  Additionally, I must apologize that this blog may not seem particularly newsworthy for some.  You may even be thinking, Didn’t this happen eons ago.  The answer is yes and no.

About twenty years ago, there was some drama about the point-to-point interface that Charles Schwab provided to its customers and Advent, being Advent, may have been perceived as attempting to screw Charles Schwab and its customers to make more money.  Schwab, being Schwab, sued Advent – to paraphrase the judge told Advent, “You can’t do that.”

According to what I can dig up now, the firms quit wasting each other’s time and money nearly seven months after that preliminary injunction, coming to a compromise that allowed Schwab to continue to provide their point-to-point data for a period of time.  In my recollection of the events, it seemed much more drawn out.  Fast forward twenty years, and now everyone that is still relying on this particular set of data directly from Schwab’s download is back to square one.

Back in 2002, the underlying issue was that Advent didn’t want Schwab to continue providing the data without going through ACD and Schwab wanted to continue providing the data to satisfy their existing customers, who had grown dependent on getting that data via the point-to-point interface.  From the perspective of those Axys customers, it is easy to understand their position then and now…  it is pretty much free, and it works.  Why would we want to change that?

Somehow, for more years than I would have thought possible these holdouts that either saw no reason to fix something that wasn’t broken or were too cheap to move to ACD continued to do what they had been doing for decades.  I never thought this would have gone on as long as it did.  Alas, as they say, all good things must come to an end.  That is apparently what is happening now.

Schwab is in the process of stopping production of the files that feed Dataport for this subset of Axys users.  Last month, they stopped producing the price (CSMMDDYY.pri) files; they are also planning to stop producing other key files, such as transactions, sometime in 2023.  The sudden inability to create a price file no doubt caused some difficulties for those still dependent on them.  As a result, a couple firms reached out to me.

After a brief discussion with the first firm, I agreed to automate the creation of the missing price file.  According to my customers, both Advent and Schwab were unwilling to assist them with the issue.  Advent’s not planning to make changes to their interface to take in the new Schwab files, and Schwab’s not planning to help clients transform the files into something that can be ingested directly into Dataport.

It sounded way too easy for someone with my experience, and I thought it would only take a “few” minutes.  Somewhat embarrassingly, I spent a few hours creating the automation necessary to do the translation.  However, in a subsequent implementation for another customer, I was able to have a meet-and-greet call with them and a follow-up call to implement and test the solution in their environment very quickly.  All of it was accomplished in a couple hours, and on the very same day the prospective customer contacted me, leading me to believe that future implementation may be performed in a matter of minutes.

Those dealing with what is currently limited to a pricing issue have a handful of choices, none of which are fun to deal with when you need yesterday’s prices now:

  1. The most obvious choice: consider implementing the Schwab Interface via ACD.  It might be worth it.  I am not kidding.  I have plenty of clients that use ACD.
  2. Use a third-party pricing service like IDC/ICE or Telemet.
  3. Key the prices in manually.  I am not recommending this, but it is certainly an option.
  4. Utilize automation to recreate the missing price file (CSMMDDYY.pri) from the security file (CRSYYYYMMDD.SEC) now provided by Schwab.  This isn’t very difficult, and that is what I have done for those who have asked me to resolve the issue for them.

Addressing the pricing issue alone is a stop-gap solution at best.  The larger issue down the road is translating the transaction files, which will need to be done in 2023.  At my clients’ request, I have agreed to look into doing this for them as well, and I will most likely do it.  With my experience building Axys interfaces and doing the requisite transaction mapping et cetera it probably won’t be that big a deal, but it will certainly be more complicated and time-consuming than the Price File Translator was to create.

As always, if this issue is something your firm needs assistance with, please feel free to contact me directly.


Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.

For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

grayscale photo of computer laptop near white notebook and ceramic mug on table

In previous articles, I have written about the ability to take an Advent Report Writer report and make changes to it in the underlying REPLANG code. Though the program is actually called Report Writer Pro, I won’t be referring to it by that name since the “Pro” part seems a bit much.

In this article, I will take you through the basics of this process and also share some code I wrote recently to deal with a troublesome Report Writer exception. Please note, there are many modifications that can easily be done within the Report Writer interface, but this article is not about that.

You should have a good reason for attempting to modify Report Writer reports outside of the app.  For me, two fundamental issues drive this decision.  The modification either cannot be handled due to limitations of Report Writer or it is simply much more expedient to hack and slash REPLANG than it is to work within the confines of the Report Writer environment.

Okay.  Let’s assume that like me you think you have a good reason to do this. There are a few things you should know before you modify a report created by Report Writer outside of Report Writer. First of all, any report created in the Report Writer has a RPW extension, but the underlying format is REPLANG.  In most cases, any report with a REP extension was not created by Report Writer – except of course for reports like the ones we are talking about creating.

Second, your report containing code not created by Report Writer can no longer be modified by Report Writer in the future, so make a backup of the RPW file before any changes, and save the file you modify as a REP file.  That way if you need to make a change to the report later – that Report Writer would be better suited to make – you can.  In that scenario, once you have updated the report you can reapply your manual updates to the newer RPW file and then save it as REP report again.

The reason that your new REP report cannot be modified in Report Writer is not only due to the fact that the extension isn’t an RPW, but more specifically that a checksum created by Report Writer when it was last modified by the software will no longer match.  The logic behind why this is done is understandable.  Report Writer only works with certain predefined templates and does some really impressive things, but it is not designed to interpret code changes that were not created by Report Writer.

Lastly, if you haven’t waded into REPLANG code created by Report Writer it will take some getting used to.  By nature of the fact that RPW files are created to be extensible the REPLANG code is more abstract. In other words, the code generated by Report Writer appears far less direct with regard to its purpose than code that an individual might write for a singular and well-defined purpose.  If you are not familiar with REPLANG coding, I wouldn’t recommend trying to modify REPLANG reports created by Report Writer.

Some examples of the types of things I find myself doing when I modify Report Writer reports from REPLANG directly follow:

  1. I need to do a calculation that I find difficult or impossible within the Report Writer interface.  If you have any experience using Report Writer to create user-defined formulas, this really isn’t that hard to imagine.
  2. Adding a piece of data that isn’t readily available from the Report Writer.
  3. For expediency sake, I know how to do something in REPLANG in a minute, but doing it in Report Writer might take an unreasonably long time.

Dealing with Report Writer Exceptions

Recently, while working on some reporting extracts for a client, I attempted to take what appeared to be a relatively simple Report Writer report and change the format to a CSV file.  Doing so is a basic function of the product and only requires a few mouse clicks.  It is something I tend to do on a regular basis and it usually works well.  However, this time Report Writer went haywire.

Instead of taking the twenty-two thousand line report and making another similar sized report as I expected, it created a ridiculously long report (hundreds of thousands of lines of code) that Report Writer could not test or run.  Even a twenty-two thousand line report sounds big and it is.  By comparison, the longest standard report(persave.rep), which updates performance files,  is under four thousand lines. Most of the standard reports are significantly less than a thousand lines of code.

It is not the first time I have seen this problem, but this time I decided to do something more proactive to deal with this issue in the future.   The report that I was attempting to change is fairly simple.  There are no summary records.  So, the output is just a table of detail records and that helps to simplify the coding requirements of what I want to do.  To deal with this issue in the past, I have simply renamed the RPW to a REP file and modified 10 to 20 lines specific to placing the output on the screen and reformatted them to be CSV friendly.

There are alternative ways to do this. You could create the Excel file output manually by exporting the report output to Excel once the report has been generated and saving it, or by writing a script to generate an Excel file, but in this particular instance I preferred to create a more flexible CSV report.  We could also do a standard search and replace function within a text editor, but having seen this issue more than a few times I wanted to create a utility I could use going forward.

So I quickly wrote the code in the section below to change the original report, which was sending output to the report view screen, to send all the output directly to a file.  I find it very easy to code things like this using Visual Basic (VB) or Visual Basic for Applications (VBA). Since most users also have access to VBA via Microsoft Office, it is a programming option you can find and use on almost any PC. As such, I frequently use VBA when I am doing spontaneous and simple coding tasks or projects that don’t require a more complex development environment. I am not a huge fan of verbose comments, but I thought they might be useful here.

VB
Sub MAIN()

' This routine takes a REPORT WRITER report which sends output to the
' screen and creates a report that sends output to a file. The routine
' was created to address an exception where the normal function to make
' a change in a RPW file created an obscenely large Report Writer file
' that couldn't be tested or run.

' written in VBA by Kevin Shea (aka AdventGuru) & published 06/26/2019

' Disclaimer: This routine works fine for the specific instance it was
' created for, but could need additional modifications for different
' circumstances.

'Initialize variables
Dim InputFileHandler As Integer
Dim OutputFileHandler As Integer
Dim Filename$
Dim Record$
Dim IgnoreRecords As Boolean
Dim ReportLocation$
Dim OutputFolder$

ReportLocation$ = "f:\axys3\rep\"
OutputFolder$ = "f:\axys3\exp\"

' Axys users will probably need to change the two locations above to
' match their actual folder locations of Axys.

' APX users, depending on the APX server name, the preceding statements
' might need to change to ReportLocation$="\\apxappserver\APX$\rep\"
' and OutputFolder$ = \\apxappserver\APX$\exp\"

InputFileHandler = FreeFile 'fetch an unused file handler
IgnoreRecords = False
Filename$ = InputBox("Report file name?")

Open ReportLocation$ + Filename$ For Input As #InputFileHandler

OutputFileHandler = FreeFile 'fetch an unused file handler

Open ReportLocation$ + Left$(Filename$, Len(Filename$) - 4) + ".out" For Output As #OutputFileHandler

Do While Not EOF(InputFileHandler)

  Line Input #InputFileHandler, Record$ 'read a record from the report

  If Left$(Record$, 4) = "head" Then IgnoreRecords = Not (IgnoreRecords)

  ' REPLANG marks the beginning of the header definition with the
  ' statement "head" and ends the header definition with the same
  ' statement. We don't want to write the header to our output file,
  ' so we are going to ignore all of the code between the two head
  ' lines of code.

  If IgnoreRecords = False Then

    If InStr(Record$, ".") > 0 Then

      ' The "." in REPLANG is the syntax usually associated with
      ' sending output to the screen most, but not all, "." lines
      ' end with "\n", which marks the end of the output line. By
      ' making the "." a requirement of this logic we will only
      ' process REPLANG statements that create output.

      For i = 1 To Len(Record$)

        'ignore any code lines that are less than two characters
        If i > 1 Then

          ' We may not need to be this specific, but I want to err
          ' on the side of caution. We will only process lines that
          ' start with a period. This prevents us from processing
          ' other lines that may have periods in the remarks or other
          ' areas of the REPLANG report.

          If Trim$(Left$(Record$, i - 1)) = "" And Mid$(Record$, i, 1) = "." Then

            'Somewhat self-explantory...
            Record$ = Replace(Record$, "~", ",")
            Record$ = Replace(Record$, "#,", ",#")
            Record$ = Replace(Record$, " ,", ",")
            Record$ = Replace(Record$, "?", "")

            Print #OutputFileHandler, Record$ 'write the record we modified

            Exit For
            'Exit logic early if we are done processing the record.

          End If

        End If

      Next i

    Else

      ' This bit of code inserts the code that writes all records
      ' that weren't modified, but contains some minor code insertion
      ' (outfile) make the output go to a file. The proper place to
      ' insert the outfile statement is before any accounts are
      ' processed, which is immediately before the load cli statement.
      ' Writing to a file requires that we close (fclose) the file
      ' or the result will not get written properly. The right place
      ' to insert the fclose statement is when all of the processing
      ' has been completed, which is immediately after the next cli
      ' statement.

      If Left$(record, 8) = "load cli" Then Print #OutputFileHandler, "outfile "+OutputFolder$+"outfile.csv n"
      Print #OutputFileHandler, Record$
      If record = "next cli" Then Print #OutputFileHandler, "fclose"
 
    End If

  End If

Loop

Close #OutputFileHandler
Close #InputFileHandler

End Sub
Expand

As to why Report Writer erroneously attempts and fails to create such a long report, it likely has something to do with user-defined calculations and parsing of strings. However, for the purpose of this article we are not trying to fix that issue. It may just be a limitation of the Report Writer.


Kevin Shea Impact 2010

About the Author: Kevin Shea is the Founder and Principal Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide. For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.

Bull_20140121-winter-SamiraBouaou-2329-676x450A relatively predictable bull market doesn’t pose significant challenges to investment managers short of making the best possible investments.  Assuming one has embraced a decent platform and mission-critical systems are in order, investment managers don’t need to think too hard about reporting or much else during a boom.  Investment management firms are money-making machines, and in a bull market, most tend to do that well.

When markets and returns are kind, client reporting doesn’t get much scrutiny.  This is a point exemplified by the fact that during these times some clients don’t even bother to open up their statements.  In more challenging times, client reporting gets a level of attention that has the potential to be bad for business.  And yes, I know – even during those times – there are still clients that don’t look at their statements.

Over the years, report designers like myself have created a number of dazzling client reports that can look … well … not so dazzling when returns approach zero, or worse, become negative.  In the design process, most of the time is spent looking at accounts that paint a pretty picture.  Those are the accounts that get used in sample reports, so it shouldn’t be surprising when investment managers see how ugly an account with poor performance can appear.

A survivor bias naturally minimizes any attention these accounts might receive, but in the meantime, those reporting on accounts with sub-zero performance need to make decisions like “Should we show the floor of the graph when the account is negative?” and other presentation details that most investors would rather not contemplate.

No one I have worked with says, “We want our bad performance to look good.”  They just don’t want it to look any worse than it actually is.  Though some of the changes we make to reports are purely cosmetic, most of the report enhancements we implement are designed with one thing in mind: presenting performance fairly.

Some specific examples of modifications we have made include:

  1. creating a truly representative custom index for each account
  2. producing comparative index returns and risk
  3. isolating managed asset class and sector returns to produce select time period performance
  4. providing comprehensive performance summary reports that help the clients of investment firms put occasional anomalies in perspective

 

Flashback to Q1 2016 

Coming off a relatively flat 2015, traditional investors were likely dismayed to see double-digit negative returns just two weeks into 2016.  Since many of these same investors were drafting their investment commentaries explaining the past quarter, calendar year 2015, and the outlook for 2016 (ahem), these market conditions likely spurred some very focused thought about existing client reports and how they might look next quarter based on January’s performance to date.

2016-Q1

As a result of this come-to-Jesus moment, my phone was ringing more than usual.  In January of 2016, I fielded a number of calls from firms in a few different countries and across the US.  In almost every case, decision-makers were ready to pull the trigger.  They wanted new reports and they wanted them done quickly.

Investors planning on replacing their platform with a higher-cost alternative that ultimately might address the shortcomings of existing client reports may have reconsidered those decisions for the immediate future due to concerns over time to implement, predictability and increased costs.  I have made the point in the past and I’ll make it again here: it is typically much easier to replace your reports than your portfolio accounting system.

In simple terms, it generally takes hours, days or weeks to create new reports for Axys and APX users regardless of the content.  In contrast, the time required to change your portfolio accounting system in order to leverage pre-existing reports or make new reports on a different platform is more likely three to six months.  In some cases, investors that switch to another portfolio accounting system with new reports in mind find that they still don’t have those reports a year later.

These fundamental truths along with market conditions no doubt led investors that use Advent Software products to seek out and retain the expertise of replang and SSRS report designers like me to create and implement a variety of new performance reports designed to address concerns about their existing performance reports.

In my own experience, one prospect provided me with the specifications for their new performance summary report and requested that the report be done in a week.  In another instance, I was tasked with facilitating a reclassification of securities, regeneration of performance history, and creation of a new performance report based on the reclassification before the end of January.  In each of these engagements, working as a team with responsive and motivated clients, we were able to start and complete large-scale, high-impact projects in an accelerated time frame.

As a seasoned professional services consultant, I do my best to address the needs of my retainer clients – that keep me in business – first and any new prospects second, so these non-retainer clients were fortunate that I was able and willing to commit to projects that required fast tracking on short notice.  Though I regularly take on new projects, the most interesting thing about that quarter’s new business was the timeline imposed.

There was definitely a sense of urgency associated with these reporting projects that usually isn’t there, and though consultants like me appreciate new business opportunities, investment managers cannot usually expect those results if they haven’t forged a relationship with a consultant ahead of time.

With an established, highly-motivated expert on retainer, you can call that person on impulse, have a high-level conversation in minutes with someone that is familiar with your systems, get a responsive quote for additional work if necessary, and potentially have a new report or automation created before you might be able to effectively start a dialog or get an adequate response from an alternative source.

When the financial markets take a turn for the worse, one might assume that folks like myself who make a living off of providing software products, custom reporting solutions and consulting services aimed at automating and integrating investment management systems would suffer a downturn in business.

While that is ultimately true, should the market ever become so difficult that my customers become distressed or go out of business, it is not true of “corrections” that occur in the market.  These events force the hand of investors – making them scramble to take stock of reporting, trading and any other systems that their businesses rely on with an aim to enhance, automate and improve.

The best run investment firms are constantly striving to improve their mission-critical systems and willing to retain the talent that empowers them to make changes to those systems whenever it becomes necessary or advantageous.

Investors dodged a bullet in Q1 of 2016, but doing so in the future may require changes to your client reports. I am hopeful that 2019 will be another banner year for investors, but sooner or later something is bound to change.


About the Author: Kevin Shea is the Founder and Principal Kevin Shea Impact 2010Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide. For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.