The United States Department of Agriculture’s (USDA) Farm Service Agency (FSA) is looking to consolidate and centralize 2,384 distributed AS/400 systems across the country.

On December 29, the FSA issued a request for information (RFI), which isn’t a request for a proposal, meaning that the organization is still trying to figure out the best viable options for consolidation and centralization.

FSA’s State and County Service Centers each house an AS/400 model 170 that supports 1-to-6 counties across the United States. Each AS/400 averages four end users, which seems light until you realize the FSA’s distributed system supports close to 10,000 end users.

You might think the FSA is interested in consolidation to save money or achieve better operational efficiencies, but it turns out that the FSA is more worried about security.

“Recent audits have identified a lack of physical security at the Service Centers, which house these systems, as a risk,” the RFI states. “The Service Centers are generally leased office spaces located across the country. Improving the physical security in all of these offices is an expensive process and is not likely to be accomplished quickly. The building changes would have to be negotiated into the individual leases, and may not be possible until the current leases expire. Due to the cost and timeframe of improving physical security, the FSA is exploring the alternative of re-hosting the legacy applications in a small number of secure, central sites.”

In fact, one of the possible solutions the FSA is considering is physically moving each of the AS/400 170s into 1-to-6 central sites and providing remote access to each 170 from each State and County Service Center. Because the data stored on each AS/400 contains sensitive personal and financial details, you’ve got to wonder about the security effort it would take to move each of those 2,384 boxes at an acceptable level of risk.

Resolution of the security issue is complicated by legacy applications that run in the S/36 Virtual Machine environment, which IBM dropped support for. “Our reliance on the S/36 Virtual Machine forces us to remain on an unsupported version of the OS/400 operating system,” the RFI notes. In addition, S/36 applications use naming conventions that make it possible to support a small number of counties on a single AS/400, “but cannot be extended to support large-scale consolidation. The applications were developed under the assumption that they would be running in a small, local namespace.”

Looking to the future, the FSA has developed centralized Web-based applications, and once a full suite of Web-based applications is available, it will replace the legacy applications and the distributed environment — which the FSA could conceivably wait for, if not for the pesky physical security issues.

The RFI makes for interesting reading all on its own, so we’ve included most of it below — with only light edits for readability. We’re sure some readers have experienced similar challenges . . . and if you're a solution provider who's inclined to offer information, your deadline is January 16.

Reference-Number-RFI-07-0001

Background - Current Environment:

FSA's current distributed environment includes 2,384 State and County Service Centers, each equipped with an AS/400 Model 170 system. Local users access their offices AS/400 via PC workstations running 5250 terminal emulation. Output is printed on a combination of twinax-attached and network-attached printers. An average office has about four users, making a total user community of about 10,000. The primary use of these systems is to run S/36 applications developed and maintained by FSA from 1984 to the present. These applications run in the S/36 Virtual Machine environment (not to be confused with the S36 Environment, or S36E). The S/36 Virtual Machine environment provides binary compatibility for S/36 applications and data. IBM dropped support for the S/36 Virtual Machine after release V4R4 of the OS/400 operating system. Our reliance on the S/36 Virtual Machine forces us to remain on an unsupported version of the OS/400 operating system. The S/36 application portfolio consists of COBOL, RPG, and Assembler programs and subroutines; Screen and Menu members; OCL. These make use of unique S/36 capabilities and extensions such as the Local Data Area, and OCL substitution expressions. System facilities such as IDDU and Query/36 are also used. The data is stored in Indexed (including Alternative Indices), Sequential, and Direct files. Some files have multiple record types; and some numeric-defined fields may contain non-numeric data.

Each AS/400-S/36 environment hosts one to six counties. The S/36 namespace does not include a hierarchical file system. A naming convention is used to allow each of hosted counties to use the same file names. The first counties filenames begin with A., the second with B. and so on. This convention works fine for supporting a small number of counties on a single machine, but cannot be extended to support large-scale consolidation. The applications were developed under the assumption that they would be running in a small, local namespace. In 2000, FSA started deploying AS/400 systems and re-hosted the applications and data from S/36 systems. Once on the AS/400 platform, FSA started using DB2, TCPIP, Java, WebSphere, and MQ Series, as well as the S/36 emulation. MQ Software products Data Flow Studio (DFS) and QPasa are also used for file transmissions and MQ Series administration. The complete current environment consists of AS/400s running S/36 emulation, plus some AS/400-side code (CL, COBOL), DB2 databases, TCPIP communications, Java, Websphere, and MQ Series, DFS, and QPasa. In addition to the legacy applications, FSA has developed centralized Web-based applications. Once a full suite of Web-based applications is available, these will replace the legacy applications and the distributed environment. Some of the existing web-based applications must get data from, or replicate data to the legacy applications. This is done through a combination of AS/400 CL programs, Java programs, WebSphere applications, MQ Series, DFS, QPasa, and additions to legacy applications.

Planned Environment:

The data stored on the 2,384 AS/400 systems includes sensitive personal and financial data. Recent audits have identified a lack of physical security at the Service Centers, which house these systems, as a risk. The Service Centers are generally leased office spaces located across the country. Improving the physical security in all of these offices is an expensive process and is not likely to be accomplished quickly. The building changes would have to be negotiated into the individual leases, and may not be possible until the current leases expire. Due to the cost and timeframe of improving physical security, FSA is exploring the alternative of re-hosting the legacy applications in a small number of secure, central sites. FSA is researching several variations of the centralized hosting approach, but they all share many characteristics. The number of central sites being considered is in the range of 1 to 6.

For all centralized approaches, Service Center users will remotely access the centralized servers from their local workstations, via terminal emulation software or a Web client. Print output will be directed back to network printers in the appropriate Service Center. The centralized systems will interact with other hosts, including mainframe and Web farm. The centralized approaches under consideration are:

1. FSA would remove the existing AS/400 systems from the Service Centers and relocate all of the existing hardware to a small number (1-6) of centralized hosting facilities. For six centers, this is about 400 AS/400 systems per center.
2. FSA would re-host the legacy applications and data on a larger computing platform, which provides binary-level emulation of the current environment AS/400, S/36, MQ Series, WebSphere, etc. Assuming that one larger system can host the workload from many legacy AS/400s, and that users and data can be correctly routed and segregated, re-hosting on larger systems would mean fewer systems for the hosting facilities to operate. This consolidation may include providing a virtual partition for each existing system.
3. FSA would re-compile application software in order to migrate to another hardware platform, which could be scaled so that a single system would do the work of many legacy AS/400 systems. This is similar to approach #2, except with re-compilation and migration work.
4. FSA wishes to solicit any other relevant available options that could remove the physical security vulnerability while ensuring successful program delivery. Desirable characteristics include: Ability to run all existing applications and Query 36 without modification; support combined AS/400 S/36 environment (DDM, ILAN, STRM36PRC, RUN400, etc.); support AS/400 software, including WebSphere 3.5, MQ Series, DFS, QPasa; ability to implement without recompiling code (recompiling will add difficulty and complexity); minimal changes for the FSA software developers. FSA will continue to develop in the S/36 environment; ability to address scaling and namespace issues; ability to connect each remote user to the correct partition/namespace/data; correct printing of reports; user experience and performance similar to current environment; minimal downtime, at least comparable to current environment; ad hoc report capability; Query 36 is preferred.

Instructions to Prospective Offerors:

Responses to this RFI must be no more than 40 total single-sided pages with print no smaller than 12 point; however, text included in graphics, tables, and figures can be smaller than 12 point. The cover page, cover letter, table of contents, and exhibits are not included in the 40-page count. Responses should also include a Commercial price list or GSA schedule of license and maintenance fees along with Points of Contact (including name, e-mail address, phone number, and fax number from any customers currently using the product). The submission must be in sufficient detail and clarity to provide FSA with the information it needs to assess your company’s software capabilities. All information submitted in response to this request shall become the property of the Government and shall not be returned to the submitter. Responses must be submitted in Microsoft Word 2000 or later. Offerors responses to the RFI must be submitted to FSA by 1:00 p.m. CST on January 16, 2006. Your company should only contact the contracting office issuing this letter if there are questions about any aspect of this acquisition. Interested parties may not contact FSA technical personnel about this acquisition. One hard copy and a CD of all response files must be submitted to the following address:

USDA/FSA/KCAB, M/S 8388, Attn: Patty Cochran, 6501 Beacon Drive, Kansas City, Missouri 64133-4676. Patty Cochran may be contacted by e-mail at patty.cochran@kcc.usda.gov. RFI responses must conform to the format as described below and provide the following information: Cover Letter - the cover letter must include the following information: company name; company point of contact and telephone number; date submitted.

Section 1 - Software Capability - Offerors must briefly describe their software package for this initiative. Offerors must also describe their proposed software in terms of the desired characteristics above including any shortcomings that they cannot satisfy. If the software package is currently in use, the offeror should describe who is using the product and some statistics on volume of users and data.

Section 2 - Related Experience - Offerors must describe their related experience in the field of software development in the following categories: Government system implementation efforts for organizations with approximately 10,000 users, Large-scale complex projects involving hardware, application software, and production support services, Performance-based contracting efforts and current references, Project description, Functional environment, Number of customers served, Technical environment, Application server and operating system, Database server and operating system, Client workstation and operating system, Database management system. Capability Assessment Method - The government will use the information in your response to the RFI, as well as other information available to the government, to assess your company’s software capability. 52.215-3 Request for Information or Solicitation for Planning Purposes (Oct 1997) (a) The Government does not intend to award a contract on the basis of this solicitation or to otherwise pay for the information solicited except as an allowable cost under other contracts as provided in subsection 31.205-18, Bid and proposal costs, of the Federal Acquisition Regulation. (b) Although proposal and offeror are used in this Request for Information, your response will be treated as information only. It shall not be used as a proposal. (c)This solicitation is issued for information and planning purposes. A formatted copy of this RFI may be obtained by email request.

Here’s a direct link: http://www.fbo.gov/spg/USDA/FSA/KCAO/Reference%2DNumber%2DRFI%2D07%2D0001/SynopsisR.html"