**Version 1**

**July 2002**

*Prepared for*

![](media/image1.png){width="1.1388888888888888in"
height="0.5763888888888888in"}

*US Department of Transportation*

*Federal Highway Administration*

*400 Seventh Street, SW*

*Washington, DC 20590*

*Prepared by*

![](media/image2.wmf){width="0.42430555555555555in" height="0.55in"}

*The Johns Hopkins University*

*Applied Physics Laboratory*

*11100 Johns Hopkins Road*

##### Laurel, MD 20723-6099

######### Document Information

> Document Title: Release Notes for CVIEW Release 3.3
>
> Issued by: Alan Mick & C. D. Bethea
>
> Issue Date: July 2002

If there are any comments or questions about this document, please
address them to:

The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Road

Laurel, Maryland 20723-6099

Attention: Carolyn Bethea (Building 24-E240)

Phone: (240) 228-0151

FAX: (240) 228-6149

E-Mail: Carolyn.Bethea \@jhuapl.edu

CVIEW Web Page: <http://www.jhuapl.edu/cvisn/>

then click on "CVIEW" under the "CVISN Projects at APL" heading.

**Acknowledgments**

The authors would like to thank Robert Goldfarb and Mary Stuart, for
their assistance with this information.

**TABLE OF CONTENTS**

1\. Introduction [3](#introduction)

2\. Version Identification [4](#version-identification)

3\. New Features and Functionality and Other Changes
[5](#new-features-and-functionality-and-other-changes)

3.1. Enhanced IRP Data Support for Vehicles
[5](#enhanced-irp-data-support-for-vehicles)

3.2. Enhanced IRP Data Support for Carriers
[5](#enhanced-irp-data-support-for-carriers)

3.3. PIQ and Carrier Queries from CVIEW to SAFER via RPC
[5](#piq-and-carrier-queries-from-cview-to-safer-via-rpc)

3.4. Inspection Report Subscriptions for Law Enforcement
[6](#inspection-report-subscriptions-for-law-enforcement)

3.5. ASPEN 32 Connectivity through CVIEW
[6](#aspen-32-connectivity-through-cview)

3.6. 997 / 824 EDI Acknowledgements [6](#edi-acknowledgements)

3.7. Configuration Parameters now in Registry
[7](#configuration-parameters-now-in-registry)

3.8. SendList Program [7](#sendlist-program)

4\. Caveats and Restrictions [7](#caveats-and-restrictions)

4.1. Last CVIEW Release [7](#last-cview-release)

4.2. Beta Release Testing [7](#beta-release-testing)

4.3. ASPEN Connectivity Through CVIEW
[8](#aspen-connectivity-through-cview)

4.4. Incorporating Intrastate Data in CVIEW
[8](#incorporating-intrastate-data-in-cview)

4.5. Turn Off 824's for Vehicles [8](#turn-off-824s-for-vehicles)

4.6. Oracle 7.3.4 Status and Issues [8](#oracle-7.3.4-status-and-issues)

4.7. The term "SAFER" may be Found in Source Code and Configuration Code
[9](#the-term-safer-may-be-found-in-source-code-and-configuration-code)

4.8. RPC Server [9](#rpc-server)

4.9. Vehicle Queries by VIN and License Plate
[9](#vehicle-queries-by-vin-and-license-plate)

4.10. CVIEW User ID's [9](#cview-user-ids)

5\. Known Problems, Defects & Workarounds
[10](#known-problems-defects-workarounds)

5.1. CVIEW Clients E-screen Subscriptions
[10](#cview-clients-e-screen-subscriptions)

6\. References [10](#references)

# Introduction

This document provides over-view information concerning the release of
CVIEW 3.3 and documents any changes or issues that were not able to be
documented elsewhere.

Previous versions of this document contained extensive information about
configuring the CVIEW service. This information is no longer provided in
this document. It is now published separately as *CVIEW Configuration
Definition Document* \[Reference 1\].

# 

# Version Identification

A version label of 3.3.30.0 identifies Executables and other binary
files associated with this release.

# New Features and Functionality and Other Changes

The following features are new to CVIEW 3.3:

## Enhanced IRP Data Support for Vehicles

In previous releases of the CVIEW system, the database stored the
license plate state and number, VIN and most related registration (cab
card) and vehicle information in a single table. This included a summary
of the inspection reports in which the vehicle had appeared. The
structure of the table allowed only one registration (cab card) to exist
for a vehicle. It also forced the VINs and license plate state / number,
found in inspections, to be stored in the same fields as the VIN and
license plate state / number from a registration. Thus updates based on
inspections created "false registrations" for the vehicle.

Additional flexibility has been added for storing vehicle registration
information in CVIEW 3.3. Vehicle information is now stored in more than
one table, and more than one license plate and cab card can exist for a
particular vehicle. In addition, the inspection report summary
information also has its own table, so storing a vehicle snapshot based
on an inspection report does not create a "false registration."

Backward compatibility with existing clients has been maintained by
sending the same EDI data for vehicles as was sent in previous releases.
However, due to CVIEW being able to store multiple registrations per
vehicle, multiple vehicle snapshots may be returned in response to a
query based on VIN or state / plate.

## Enhanced IRP Data Support for Carriers

In previous releases of the CVIEW system, the database stored carrier
IRP account information in the same table where MCMIS census data is
stored. This allowed only one IRP account to be stored for a particular
carrier. In CVIEW 3.3, this information is stored in its own table,
allowing more than one IRP account to exist for a particular carrier.

Backward compatibility with existing clients has been maintained by
sending the same EDI data for carriers as was sent in previous releases.
However, when a query is initiated based on Carrier ID, because multiple
IRP accounts per carrier are now stored in the database, multiple
carrier snapshots may be returned.

## PIQ and Carrier Queries from CVIEW to SAFER via RPC

When a CVIEW gets a past inspection query (PIQ) it will issue an RPC
query to the SAFER RPC service and return the results, if any, to the
client. If no matches are found the standard "data not on server"
message is returned to the client software, which then can be displayed
to the user.

When a CVIEW gets a carrier query it will check its local database and
return the result to the client. If no records in the local database
match, it will issue an RPC query to the SAFER RPC service and return
the results, if any to the client. If no matches are found the standard
"data not on server" message is returned to the client software, which
then can be displayed to the user.

To configure the CVIEW to utilize these capabilities see "RPC Server
Forwarding Address" in *CVIEW Configuration Definition Document*
\[Reference 1\].

This capability is used to implement ASPEN connectivity to SAFER through
CVIEW. See Section 3.5, ASPEN 32 Connectivity through CVIEW, for further
details.

## Inspection Report Subscriptions for Law Enforcement

If an inspection report comes into CVIEW's data mailbox from an ASPEN
client, because the CVIEW doesn't store inspection reports, the CVIEW
should be set up to forward it to the SAFER 60-day inspection report
repository. The inspection is not sent in EDI format. Instead, it is
sent in Application File Format (AFF). See the *SAFER Interface Control
Document* \[Reference 2\] for an overview of AFF.

This capability is used to implement ASPEN connectivity to SAFER through
CVIEW. See Section 3.5, ASPEN 32 Connectivity through CVIEW, for further
details.

## ASPEN 32 Connectivity through CVIEW

ASPEN 2.4 may be configured to use the CVIEW data mailboxes rather than
the SAFER data mailbox. By establishing the appropriate inspection
report subscriptions, and an RPC link to SAFER for PIQ and carrier
queries, the ASPEN 2.4 can function as if it were directly communicating
to SAFER.

Instructions for configuring the CVIEW / ASPEN 32 interface are provided
in the *CVIEW Configuration Definition Document* \[Reference 1\].

## 997 / 824 EDI Acknowledgements

The response to any syntactically correct subscription data and updates
from authoritative sources will always return at least a positive or
negative 824. When an update is sent, the application (SAFER or CVIEW)
will respond with one and only one of these interchanges / transactions:

-   A \"Negative\" 997 if the update interchange had syntactical errors
    and no processing could be done.

-   A \"Negative\" 824 with an error code / message for each problematic
    snapshot in the interchange and a count of the number of total and
    good snapshots processed. No other positive messages for those
    snapshots that were not problematic will be included. Thus if an
    update interchange containing 100 snapshots were to result in 10
    update errors, a single 824 with 10 error codes and messages and a
    count of 90 successful snapshots processed would be returned.

-   A \"Positive\" 824 reporting that all snapshots in the update
    interchange were updated properly, including a count of how many
    were processed. There will not be a separate report for each one,
    rather success in general will be reported.

A switch in the SAFER / CVIEW registry will allow 824's to be turned on
or off for carrier snapshots, vehicle snapshots or both. To configure
the CVIEW to utilize 824's see "Want 824" under "EDI Settings" in *CVIEW
Configuration Definition Document* \[Reference 1\]. When an 824 is
received by SAFER / CVIEW, it will log the information in the NT event
log. The **SMTP_MBX_NAME** value also establishes the mailbox where EDI
824 acknowledgements will be returned. The return address must consist
of the fully qualified input mailbox name including the domain.

## Configuration Parameters now in Registry

In previous versions of CVIEW, configuration parameters were contained
in two different Windows "INI" files. These files have been discontinued
and the configuration parameters are now in the Windows NT registry.
Details of the parameters, which used to be contained in the release
notes, are now documented in *CVIEW Configuration Definition
Document.*\[Reference 1\]

## SendList Program

> The Sendlist program is used to "mail" bundled Carrier Subscription
> snapshots to the various Clients. See "Executing Sendlist" in *CVIEW*
> *Utility Instructions*. \[Reference 3\]

# Caveats and Restrictions

The following caveats and restrictions apply to the CVIEW 3.3 release.

## Last CVIEW Release

> This release of the CVIEW service will be the last release provided by
> the FMCSA to the CVISN community. No new development work is
> anticipated for this version of the software. October 31, 2002 will be
> the last opportunity to receive bug fixes.

## Beta Release Testing

Previous releases of the CVIEW service were released to and installed in
several CVISN states prior to being released. The prototype state
installations were monitored closely and changes were made to the CVIEW
service before general distribution. This process is generally referred
to as beta testing. This release of CVIEW has not been put through this
process.

## ASPEN Connectivity Through CVIEW

This release provides the capability to utilize the ASPEN, ISS and PIQ
software distributed by FMCSA's Field System Team through the CVIEW,
rather than connecting it directly to SAFER. This capability is provided
for ASPEN version 2.4. Subsequent versions of ASPEN, ISS and PIQ may not
function in the same way, and therefore may not work with CVIEW 3.3.
Since this is the last release of CVIEW by FMCSA, any changes
necessitated by changes in ASPEN, ISS or PIQ would have to be arranged
for or made by the state.

## Incorporating Intrastate Data in CVIEW

A number of states desire to incorporate intrastate data into their
CVIEW database. Two types of data, carriers and vehicles, are of
interest.

To incorporate intrastate carriers into the CVIEW database, it is
necessary that intrastate carriers be issued USDOT numbers. When
intrastate carriers are issued USDOT numbers, the carrier information is
sent by MCMIS to CVIEW via SAFER as part of the normal update process.

To incorporate intrastate vehicle registrations into the CVIEW database,
it is necessary that the vehicle information be treated as if it were an
IRP registration (interstate cab card). Consequently, EDI updates must
include IRP base state and license plate number to CVIEW. By convention
an "IRP registration" with one and only one state of operation listed is
used to represent an intrastate vehicle. Such a registration is
interpreted as an intrastate vehicle.

## Turn Off 824's for Vehicles

The capability to send 824's reporting the status of update operations
can be turned on or off utilizing a configuration parameter. As
installed, CVIEW 3.3 is configured to utilize 824's for carriers only.
This is because vehicle updates are not combined into a single EDI
transaction, as are carrier updates, and thus a separate 824 would be
generated and sent for each individual vehicle.

## Oracle 7.3.4 Status and Issues

The version of the Oracle database server that must be used with CVIEW
3.3 is under special support status. It cannot be obtained through the
normal Oracle purchase procedures. To obtain it you should file a TAR
with Oracle support and ask for Oracle 7 Workgroup Server 7.3.4, PART
NO. A42666-6. Please check

<http://metalink.oracle.com/> -\>Product Lifecycle-\>Desupport Notices
for latestinformation

The distribution media provided by Oracle for this version of the
database contains a label with this warning: "This product is obsolete
and may have special support status.

The Oracle installer that is part of this release has a Y2K related
defect. An updated installer may be found at
[http://metalink.oracle.com](http://metalink.oracle.com/).

## The term "SAFER" may be Found in Source Code and Configuration Code

The SAFER and CVIEW systems share a large amount of source code.
Therefore the source code for CVIEW 3.3 often contains references to the
SAFER system.

## RPC Server

Under some circumstances, the CVIEW communicates with SAFER using the
Remote Procedure Call (RPC) protocol. With the release of CVIEW 3.3, the
SAFER 2.4 RPC service will be replaced by the SAFER 3.3 RPC service.
CVIEW 2.4 will no longer be able to communicate with SAFER via RPC.

## Vehicle Queries by VIN and License Plate

A query for a vehicle by VIN or License Plate / State requires that a
registration for the vehicle already exist. If a vehicle query is done
for a vehicle that does not have registration data in the database, no
information will be returned, even if inspection summary information
does exist. Instead, the standard "data not on server" message is
returned to the client software, which then can be displayed to the
user.

## CVIEW User ID's

When the SAFER system operator creates the CVIEW user ID and mailbox on
the SAFER Version 3 system, it is required to be "CVIEWxx" where "xx" is
the postal code for the operating state. The trading partner ID at the
CVIEW site must be equivalent.

For example, the Maryland CVIEW user ID and trading partner ID would be
called "CVIEWMD".

All CVIEW user IDs on SAFER, as well as the CVIEW trading partner
identifiers at the state, must be no more than 10 characters in length.
The 10 characters accommodate the user IDs created in previous
CVIEW/SAFER versions that included the suffix "SUB". \[Reference 4\].

In order to upload data to SAFER, a user ID called SAFER and an
analogous mailbox must be created at the CVIEW. Carrier and vehicle
subscriptions that the SAFER user will subscribe to must also be
created. The SAFER user must then be registered to these carrier and
vehicle subscriptions. All this is done via the OPCON program. The SAFER
system operator located at Volpe must be notified so that a testing
period can be established to make sure that the integrity and validity
of the data can be verified. At Volpe, the SAFER system operator must
create an entry in the registry utilizing the Service Configuration Tool
to facilitate the SAFER Service reading its SAFER mailbox at the CVIEW.

# Known Problems, Defects & Workarounds

## CVIEW Clients E-screen Subscriptions

Currently the carrier snapshot subscriptions on CVIEW that utilize the
full view event set do not trigger snapshots appropriate to E-screening
operations. Subscriptions utilize "event masks" to indicate to the
subscription processing code which fields should be examined for
changes. Neither the Carrier \"full\" event set nor the vehicle \"ROC\"
event set includes E-Screening events - that is they do not trigger
generation of E-screening snapshots when E-Screening data changes.
Therefore in addition to the Carrier Subscription (Full View) and
Vehicle Subscription (ROC View), two additional subscriptions should be
added in order to receive E-Screening data.

1.  Carrier Subscription with Carrier Snapshot Event set to E-screen
    view fields

2.  Vehicle Subscription with Vehicle Snapshot Event set to E-screen
    view fields

# References

1.  JHU/APL, *CVIEW Configuration Definition Document*. This document is
    available on the CVIEW 3.3 distribution CD.

2.  JHU/APL, *Safety and Fitness Electronic Records (SAFER) System
    Interface Control Document*, POR-99-7129 Baseline V1.0, dated June
    2001.

3.  JHU/APL, *CVIEW* *Utility Instructions*. This document is available
    on the CVIEW 3.3 distribution CD.

4.  JHU/APL, *OpCon Version 3.1 (Operator Console) Release Notes*. This
    document is available on the CVIEW 3.3 distribution CD.