BNUMBER:  B-271035; B-271035.2
DATE:  June 10, 1996
TITLE:  Sprint Communications Corporation, L.P.

**********************************************************************

DOCUMENT FOR PUBLIC RELEASE
A protected decision was issued on the date below and was subject to a 
GAO Protective Order.  This version has been redacted or approved by 
the parties involved for public release.
Matter of:Sprint Communications Corporation, L.P.

File:     B-271035; B-271035.2

Date:June 10, 1996

Anthony L. Cogswell, Esq., and Ronald L. Fouse, Esq., for the 
protester.
Rand L. Allen, Esq., and David A. Vogel, Esq., Wiley, Rein & Fielding, 
for [REDACTED], an intervenor.
George M. Kingsley, Esq., Madeline Shay, Esq., and Joseph Cox, Esq., 
for the agency.
C. Douglas McArthur, Esq., and Christine S. Melody, Esq., Office of 
the General Counsel, GAO, participated in the preparation of the 
decision.

DIGEST

1.  Protest challenging agency's refusal to grant request for change 
to benchmark script (to allow protester to defer until after award 
demonstration of its ability to switch data display from full screen 
to teletype format without leaving the application) is denied since 
waiver of the type protester requests would be inconsistent with the 
purpose of the benchmark--to require offerors to demonstrate, before 
award, their capability to meet mandatory solicitation requirements.

2.  Protest that requirement for offeror to demonstrate dual mode 
emulation during benchmark is unduly restrictive of competition 
because agency has no valid requirement for dual mode emulation is 
untimely where the requirement was stated in the solicitation but 
protest was not filed until well after time set for receipt of initial 
proposals.

3.  Protest that agency improperly waived for one offeror a mandatory 
solicitation requirement--for use of a commercial operating system--is 
denied where record shows that the offeror's proposed operating system 
is available commercially.

DECISION

Sprint Communications Company, L.P. protests the agency's actions 
under request for proposals (RFP) No. DACW31-94-R-0145, issued by the 
U.S. Army Corps of Engineers for information processing services.  
Sprint contends that the Army improperly and unreasonably rejected its 
request for modification of a benchmark test.  Sprint also alleges 
that the agency improperly waived a mandatory solicitation requirement 
for another offeror, [REDACTED].

We deny the protests.

BACKGROUND

On November 1, 1994, the agency issued the RFP for software, hardware, 
and telecommunications to support the agency's Programming, 
Administration and Execution (PAX) system for a base year, with four 
1-year options.  Through various program management applications 
sponsored by the agency, the PAX system provides international 
teleprocessing support for the Army's military construction program, 
as well as service to a variety of military and civilian agencies.[1]

The solicitation provided for evaluation of proposals in three stages.  
Stage I, which is now complete, involved evaluation of proposals by a 
technical evaluation committee to determine whether they met the 
mandatory requirements of the statement of work (SOW).  Offerors whose 
proposals were found to comply with the SOW requirements then must 
perform a benchmark demonstration, stage II of the evaluation, the 
terms of which are at issue in this protest.  In stage III, offerors 
who pass the benchmark will submit price proposals.  Selection of a 
contractor, presuming that offerors meet mandatory criteria and pass 
the benchmark, will be based on price and technical factors, including 
soundness of approach, the results of a user survey, and the offeror's 
FTS2000 Network Design.

Paragraphs C.3 and M.2.1 of the RFP provide that an offeror must 
satisfy all requirements of the SOW to be technically acceptable.  
Paragraph 6.2.1 of the SOW requires the contractor to convert the four 
major PAX applications, which have been written in a modified version 
of the International Business Machines Corporation's (IBM) VM/ESA 
operating system known as VMTI/ESA.[2]  The Army made available to 
offerors, in a reading room, a document describing the incumbent's 
functional modifications to the operating system, including a feature 
known as dual mode emulation.[3]  This feature allows a user to switch 
back and forth between teletype (display of one line at a time) mode 
and full screen mode without leaving an application. 

Amendment No. 0001 to the RFP, dated November 4, 1994, advised 
offerors that the benchmark package would be made available on 
November 8; however, the agency had begun to suspect certain problems 
with the benchmark package.  Specifically, it appeared that [REDACTED] 
meeting the mandatory requirement for dual-mode emulation through 
"calls" to proprietary codes.  A "call" is software code resident in a 
program that allows (or causes) the program to branch outside to 
another program and execute code located in that program.  In 
pertinent part, it appeared that, in switching between the two modes 
of display, PAX applications were branching out to [REDACTED] 
proprietary code located in the mainframe supporting the PAX system.  
This created a problem in that other offerors would be unable to run 
the benchmark as initially issued--specifically, the demonstration of 
dual-mode capability--if the function required the system to have 
access to a proprietary code.[4]

While agency personnel confirmed [REDACTED] use of a proprietary code 
to perform the dual mode emulation, the Army also was issuing several 
amendments to the solicitation, which required extensions of the due 
date for initial proposals.  On March 6, 1995, the agency provided 
offerors with a revised benchmark package that eliminated the calls to 
[REDACTED] proprietary code.  In response to several questions 
submitted by offerors, the agency specifically advised competitors 
that [REDACTED] modified the operating system to meet some of the 
mandatory requirements, and that, since the government did not own 
rights to these modifications, other offerors would have to create 
their own proprietary software to meet certain requirements.  The 
VMTI/ESA Features Supplement described dual mode emulation and 
identified it as a key function requiring some modification to the 
operating system, although the supplement provided no details on 
[REDACTED] proprietary code used to accomplish the function.

The Army subsequently extended the time for submission of initial 
proposals to April 12, 1995, and the time for submission of any 
requests for changes to the benchmark to April 28.  The agency 
received proposals from the protester and [REDACTED].  None of the 
offerors, except [REDACTED], submitted requests for benchmark changes.  
[REDACTED]

On May 17, and again on August 11, the agency provided offerors with 
further opportunities to request changes to the benchmark.  On August 
14, Sprint submitted a letter requesting changes to the benchmark, 
none of them relevant to the issues in this protest.  Further, in 
correspondence dated September 1, Sprint advised the agency that, 
[REDACTED].

On October 11, the agency conducted a conference with representatives 
of Sprint by telephone.  The agency hoped to schedule the benchmarks 
immediately upon completing the technical evaluation, and was 
unwilling to allow further delay.  For this reason, the agency advised 
Sprint that its September 1 letter [REDACTED].  The agency took the 
opportunity to raise additional concerns--specifically, [REDACTED] 
which had arisen as a problem with other proposals.  Sprint then 
raised the question of [REDACTED].  The agency advised Sprint, as it 
had stated in response to prior inquiries, [REDACTED].[5]

The agency extended the deadline for requesting benchmark changes to 
November 3.  In the interim, one offeror withdrew because of problems 
associated with rewriting the code to allow dual mode emulation.  In a 
letter dated October 30, the agency specifically asked Sprint whether 
it understood its responsibility for developing the code necessary to 
perform the dual mode emulation during the benchmark.  Sprint 
responded the next day that it understood and was prepared to satisfy 
the requirement for demonstrating both modes, teletype and full 
screen, without logging off.

By letter of November 3, the agency accepted all but one of Sprint's 
requests for benchmark changes.[6]  Although the deadline for 
submission of change requests had again passed, Sprint continued to 
submit, and the agency to consider, other requests for changes to the 
benchmark script.  [REDACTED]

On November 17, Sprint acknowledged the need to develop software to 
interface with the PAX applications and operating system.  The 
protester asked the agency to delay the benchmark test until February 
1995, in order to allow Sprint to complete the development effort.  
The agency was unwilling to commit itself to such a delay, although it 
continued to accept and consider Sprint's requests for changes to the 
benchmark script.

The specific issues arising from this protest came to a head with 
Sprint's December 18 request for four additional script changes.  
Sprint requested that the requirement for a dot prompt during full 
screen emulation be eliminated.[7]  (The dot prompt is indicative of 
teletype mode.)  Sprint also asked to perform all benchmark edit 
sessions utilizing full screen mode.  The thrust of these changes 
would be to allow Sprint to run the entire benchmark in full screen 
mode, waiving the requirement for dual mode emulation during the 
benchmark.  Sprint also asked that it be allowed to ignore an error 
message--"INVALID DEVICE TYPE"--during the benchmark but failed to 
provide any information on the context in which the error message 
appeared.[8]

By letter dated January 2, 1996, the agency denied Sprint's December 
18 request.  The requests for omission of the dot prompt and for 
performance of edit sessions in full screen mode were denied because 
they were inconsistent with the requirement to demonstrate dual mode 
emulation.  Sprint's other request was denied because, absent 
additional information, the agency could not tell how frequently or 
under what circumstances the error messages might appear.  On January 
16, Sprint filed a protest with the agency over the rejection of its 
requests for changes to the script.  The agency denied this protest on 
January 24, and this protest to our Office followed.

DISCUSSION

Sprint contends that, while it ultimately can meet the solicitation 
requirement for dual mode emulation, the Army's insistence that it 
demonstrate dual mode capability during the benchmark is unreasonable.

The record shows that while full screen mode has obvious advantages, 
teletype mode is faster over a modem and generally more economical 
than full screen mode.  Separate pricing of the two modes had resulted 
in appreciable savings during the past contracts, and the agency 
wanted the continued capability for operators to switch to teletype 
mode when feasible to take advantage of its generally lower price.  
The requirement has been in the solicitation since its issuance, and 
indeed appeared in a draft solicitation distributed for comment before 
that.  As discussed above, the record demonstrates that Sprint never 
objected to the requirement prior to its December 1995 request for a 
change to the benchmark, and on several occasions acknowledged the 
requirement and assured the Army of its ability to provide the dual 
mode feature.

Paragraph C.8.3 of the RFP identifies three purposes of the benchmark.  
As the agency notes, the benchmark generates cost information to 
establish the basis of pricing proposals and to allow the agency to 
monitor the selected vendor's performance and price procedures during 
performance.  That paragraph also states that the benchmark serves to 
demonstrate whether the vendor can accomplish mandatory requirements 
of the RFP.  Failure to perform tasks during the benchmark is cause 
for rejection of the proposal as technically unacceptable.  The RFP, 
to the extent it allows an offeror to seek changes to the benchmark, 
states that such changes are restricted to "job control instructions 
and any related machine-dependent changes to the software" if 
essential to make them perform on the vendor's system. 

Consistent with these provisions of the RFP, the agency asserts that 
the purpose of the benchmark is to test the potential offeror's 
configuration to ensure that it will support the PAX production 
environment.  The benchmark also serves, the agency states, as a 
pre-award demonstration of the offeror's anticipated technical 
competence in converting technical code during contract performance.  
In addition, the benchmark measures resource consumption for each 
offeror's proposed configuration, for use in evaluating the price 
proposal.  Changes to the benchmark are for the purpose of 
accommodating the offeror's configuration, the agency argues, not for 
the purpose of deferring the offeror's responsibility of demonstrating 
its ability to meet solicitation requirements until after award.

As discussed above, the subject of Sprint's requested waiver of the 
benchmark test--dual mode emulation capability--is a mandatory 
requirement of the RFP.  Clearly it would be inconsistent with the 
purpose of the benchmark test--to require offerors, before award, to 
demonstrate their capability to meet the RFP's requirements--to waive 
the requirement for demonstration of dual mode capability during the 
benchmark.  We therefore have no basis for finding the agency's 
refusal to grant Sprint's request to be unreasonable.

Sprint raises several other issues relating to the dual mode 
capability requirement, the essence of which is to challenge the 
agency's need for this function.  Specifically, Sprint argues that 
there is no reason to measure or compare its resource consumption 
during the benchmark because it might not price teletype and full 
screen modes separately; thus, the protester argues, the agency has no 
actual need for the dual mode emulation, given that offerors might be 
willing to provide full screen and teletype mode at the same price.  
Sprint also asserts that the agency can have little use for teletype 
mode; if some installations continue to use equipment incapable of 
displaying full screen, they could not take advantage of the 
capability of switching to full screen.  Finally, Sprint challenges 
the agency's statement that it has no right to the proprietary 
software [REDACTED] to perform the dual mode emulation function.  
Sprint contends that the agency should obtain the software [REDACTED] 
and provide it to Sprint and other offerors, to allow them to meet the 
requirement without having to develop their own code.  We conclude 
that these contentions constitute untimely challenges to the terms of 
the RFP. 

Our Bid Protest Regulations, 4 C.F.R.  sec.  21.2(a)(1) (1996), require 
protests based upon alleged improprieties in a solicitation to be 
filed prior to the time set for receipt of initial proposals.  Here, 
the agency points out that the requirement for dual mode emulation has 
been in the RFP since the Army issued it in November 1994.  In 
addition, amendment No. 0005, issued on March 3, 1995, specifically 
advised offerors that the agency did not have and would not provide 
the codes necessary to perform all the functions of the operating 
system [REDACTED].  Given that the RFP established the dual mode 
emulation requirement and advised that the agency would not provide 
the necessary codes, Sprint should have raised its objections to the 
requirement before the time set for receipt of initial proposals on 
April 12, 1995.  Since Sprint's agency-level protest was not filed 
until January 16, 1996, that protest and Sprint's subsequent protest 
to our Office are untimely.[9]

Regarding the request that the agency ignore the error message 
"INVALID DEVICE TYPE" during the benchmark, the agency points out that 
in the absence of any information from Sprint regarding the frequency 
and location of occurrence, it could not grant the request for waiver.  
In general, the presence of an error message presents an unacceptable 
risk, in the agency's opinion, since it could lead to confusion 
between intended and unintended error messages indicating actual 
malfunctions of the offeror's configuration or computer code.  If 
passed through to users, particularly less sophisticated ones, it 
would generate confusion and thus unnecessary processing and terminal 
input/output costs.  Sprint provides no clarification of the issue in 
its protest, and we have no basis to find that the agency unreasonably 
denied Sprint's request.

Upon receiving the agency report filed in response to its initial 
protest, Sprint filed a second protest, asserting that the Army 
improperly waived mandatory requirements of the RFP [REDACTED].  
Specifically, the protester cites paragraph C.4.4 of the solicitation, 
which requires each offeror to warrant that its operating system is 
the most recent release commercially available for the last 6 months.  
Sprint contends that the agency should not have found [REDACTED] 
proposal technically acceptable because it is offering [REDACTED], a 
proprietary operating system that is not commercially available.

The arguments of the Army and the intervenor address the issue of 
whether [REDACTED] may be considered to have proposed [REDACTED] as 
the operating system, or whether the operating system is really VM/ESA 
with modification.[10]  Sprint argues extensively that [REDACTED] is 
an operating system separate and distinct from VM/ESA.  What Sprint 
does not do is address the assertions of the agency and [REDACTED] 
that even if one views [REDACTED] as an operating system in itself, 
[REDACTED] is licensed, as VM/ESA is, to a variety of commercial 
customers, and therefore meets the RFP requirement of being 
commercially available.  Thus, even if we accept Sprint's argument 
that the operating system is not VM/ESA but [REDACTED], the record 
supports the agency's conclusion that [REDACTED] is offering a 
commercially available operating system.  The agency therefore 
properly found that [REDACTED] proposal was technically acceptable and 
met the mandatory requirements of the RFP.

The protests are denied.

Comptroller General
of the United States
f:\projects\pl\271035r.wp5

1. The chief applications supported include the following:  the 
Accounting and Control System, which acts as the systems manager, 
directing users to the appropriate application and tracking costs of 
the overall PAX system; the Army Tracking System, used for facilities 
planning at major army installations; the Army Defense Energy 
Information System Data System, which collects energy consumption data 
for Army installations, as well as the Reserves and National Guard; 
the Construction Appropriations, Programming, Control and Execution 
system, which tracks individual construction projects throughout the 
Army; and the DD Form 1391 Processor System, which provides estimates 
and justifications for Army construction projects.

2. The record shows that since award of the initial contract in 1982, 
there have been periodic upgrades and improvements to the system.  The 
original contractor, TYMSHARE, Inc., was purchased by McDonnell 
Douglas Corporation, which later sold the unit [REDACTED].  It was 
McDonnell Douglas that, in 1988, installed the system on the mainframe 
using IBM's VM/ESA operating system and that created the proprietary 
software [REDACTED], to interface between the standard operating 
system and PAX users and installations.

3. Initially, the agency referred to this document as the Cumulative 
Functional Modification.  The Army later changed the title to the 
VMTI/ESA Features Supplement.

4. The benchmark created "calls" to the proprietary code, without 
providing the code itself.

5. Specifically, amendment No. 0005 to the solicitation, dated March 
3, contained a list of 230 questions asked by vendors and the agency 
responses.  In response to question No. 165, as noted above, the 
agency had advised offerors [REDACTED] that a generic description of 
the modifications was available in a reading room previously made 
available to offerors.  Question No. 168 specifically asked the agency 
to make available the code for modifications; the Army's response 
specifically stated that the government did not own the modifications 
and that offerors would have to develop their own code.

6. The agency rejected Sprint's log-on procedure, which is not 
relevant to this protest.

7. As the agency notes, the use of a dot, rather than some other 
prompt, is not significant.  It is the use of a prompt that is 
critical when running applications in teletype mode.  Without a prompt 
of some kind, PAX users could become confused as to the beginning and 
end of data, input or output routines, database modification routines 
or other procedures.

8. Sprint also requested permission to clear the display screen with a 
keystroke when the message "...MORE" was received.  The agency 
rejected this request because Sprint had provided no details.  
Although Sprint included this issue in its protest to the agency, it 
withdrew the request prior to the Army's decision on that protest.

9. To the extent that Sprint suggests that the requirement was not 
clear from the face of the RFP, the protest nevertheless is untimely.  
The record clearly demonstrates that the agency raised the dual mode 
emulation issue with Sprint on numerous occasions prior to the 
agency-level protest.  For example, the agency raised it during the 
October 11, 1995 teleconference, and Sprint specifically acknowledged 
and took no objection to the requirement in its letter of October 31.  
Thus, the record shows that even if the requirement were not clear 
from the face of the RFP, Sprint could and should have raised the 
issue well before the filing of its agency-level protest on January 
16, 1996.  See 4 C.F.R.  sec.  21.2(a)(2) (protests must be filed within 14 
days of when the basis of protest is or should have been known).

10. The agency also asserts that the protest is untimely.  Sprint 
asserts that until it viewed the agency report, it had no way of 
knowing that [REDACTED] or that the agency had found the proposal 
technically acceptable.  We note that Sprint's initial protest 
specifically argued that the requirement was unduly restrictive of 
competition because there was no commercial software capable of 
emulating [REDACTED] operating system.  Since, as noted below, Sprint 
does not deny that [REDACTED] itself is commercially available, we 
need not address the timeliness issue.