Attachment_3_NSLDS_Platform.pdf

PDF 91 KB Posted

Attached to
Phase 1 Solicitation: National Student Loan Data System Federal contract opportunity
Solicitation number
ED-FSA-14-R-0007
Issued by
Department of Education Office of Federal Student Aid

About this file

Solicitation Attachment 3 NSLDS Platform

View the file

Other files for this federal contract opportunity

Show all 15

On GovTribe

Work with this file on GovTribe

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Attachment 3: NSLDS Platform

NSLDS Production Environment NSLDS is physically hosted by the Virtual Data Center (VDC) in Plano, TX. The current contractor managing the VDC is Dell Services Federal Government.

At its highest level, NSLDS is composed of a database and two production websites which interact with the database. Student users can access NSLDS data via the Student Access website to view and update their records. School, lender, GA, and Federal Loan Servicer users can access NSLDS by logging onto the NSLDS FAP website. FSA and NSLDS contractor staff can access via web or via the mainframe directly in order to run queries. The choice depends on the task required. Users wishing to access the NSLDS data through the web may do so via the NSLDS Student and NSLDS Financial Aid Professionals websites, which are hosted on IHS midrange servers. These servers provide load balancing for incoming web hits and work with WAS application servers to post data to and retrieve data from the NSLDS mainframe via invocation of CICS transactions and JCL. It should be noted here that there is also a separate training website which interacts with the NSLDS database, mirroring the functionality of the FAP site. All three websites, NSLDS Student Access, NSLDS Financial Aid Professionals, and NSLDS Training reside on the Integrated Technical Architecture (ITA) environment.

At a more granular level, NSLDS employs a variety of hardware and software components in the overall system in order to facilitate end-user requirements, as well as serve the application and system database administration staffs. Software components include custom developed software, purchased software, development tools, DBA tools, performance monitoring tools, and end-user query tools. The table below describes each hardware or software product used by NSLDS and, where available, provides a brief explanation of its role in the system.

For Phase 1, the offeror shall respond in the Factors Matrix (Attachment 4) based on the platform and environment information in the following table:

Product Name

Installed Purpose

DB2 R10.1 Database system CICS TS v4.2 A significant portion of the software used in

NSLDS is custom-developed CICS transactions.

CICS provides an efficient and controlled environment to access DB2 data.

CA Cool Gen release 8 Code generation CASE tool QMF v10.1 Query Management Facility - allows users to run queries off of the mainframe using Structured Query Language (SQL).

CA-INSIGHT™ for DB2 v 15.0, SP0 Used to monitor both DB2 system and program performance

BMC Change Manager v10.01.00 Impact analysis for changes to logical or physical database structures

BMC Catalog Manager v10.01.00 BMC Catalog Manager provides easy access to catalog data through TSO/ISPF screens. It also assists with administrative tasks such as creating and deleting objects and generating utility job control language (JCL), and allows for navigation through screens and data supplied by the BMC DASD Manager product.

Websphere MQ v7.0.1.7 IBM Enterprise COBOL for z/OS v4.2.0 Code compiler

IBM z10 2098 - E10 - Q04 with 32 GB memory n/a IBM mainframe where the database sits

IHS Servers n/a WAS Application Servers n/a Z/OS v1.13 RSU1112 Operating system JDBC n/a JDBC is an application programming interface

(API) specification for connecting programs written in Java to the data in databases. The API lets you encode access request statements in SQL that are then passed to DB2. It returns the results through a similar interface. Many of NSLDS’ Web transactions invoke calls to the NSLDS DB2 database via JDBC.

BrightStor CA-1 Tape Management

R12.6 SP0

BrightStor CA-Vantage Storage Resource Manager

R12.6.00 PTF high date 07NOV2011 +

RO31422

CA JCLCheck Workload Automation

R11 SP01 AM02 +

PTFs (Including

RO34738)

JCL validation and error detection

CA Workload Automation EE R11.3 SP0 Job scheduling and automation CA Workload Automation Restart Option EE

R11.3 SP0 Job scheduling and automation

CA-Common Services (CCS) R14 SP0

CA-MAX/DATA UTIL & PDF R3.4 R10

CA-VIEW Output Archival and Viewing

R11.6 SP0

COBOL - Enterprise 5655-S71 V4R2

DIF 5.1.18

EMC Timefinder Suite Mainframe Enablers

7.3 Maint 7301

eTrust CA -Auditor (Examine) R12.1 SP0 + PTFs

RO20654 RO21330

RO22459 RO27050

RO28091 RO24566

RO24574 RO23433

RO28166 RO24631

RO25674 RO27786

RO30800 RO34554

RO35653 RO34780

RO34110

FATS/FATAR V4.9 L25 SPIN 2 Tape based data management/ FATS/FATAR are utility programs for z/OS magnetic tape, which provide the following key features: Secure data erasure, either a full or partial tape, Tape mapping, Tape error recovery, Tape media certification, Verification of legacy, historical and archive tapes, Tape labeling

FDR v5.4 L76 IBM FDR (Fast Dump Restore) provides high-performance full volume and dataset level backup, restore and copy between like and unlike disk architectures under z/OS and OS/390 or without the presence of an operating system as a stand alone utility for IBM SystemZ platforms.

FDRERASE v5.4 L70 Fast DASD erase. Ensuring that test data is economically removed following a Disaster Recovery test is one of the most important steps in the test process. This service will erase all mission-critical and personal data as directed, thereby safeguarding it from unwanted use. This is especially important for compliance with HIPAA, GLBA, PIPEDA, etc.

IBM OMEGAMON XE on z/OS, ---for CICS on z/OS, ---for Messaging on z/OS, ---for DB2 on z/OS, '420' level + z/OS

1.13 toleration, '420' level + z/OS

1.13 toleration

V7.0.1, V5.1

In addition to monitoring the z/10 environment, OMEGAMON products provide CICS and DB2 monitoring. OMEGAMON for DB2 captures stats from the DB2 environment.

Quickref R7.5

Tapecopy R 2.7.4 Unicenter CA-OPS/MVS Event Management and Automation

R11.9 SP0

Additional Information:

A. Database The core of the NSLDS is the database itself. The database is hosted on an IBM z/OS mainframe with DB2, and is split into three partitions that support NSLDS operations: Production, Online Statistical Abstract, and an End User database. The Production database is the main data store containing all student and borrower accounts. The Statistical Abstract database is created by external process, and contains only a subset of data. It is refreshed on a quarterly basis. Lastly, the End User database contains ad hoc user queries that have been saved, and allows review of all data retrieved by user queries.

Direct interfaces to the DB2 database include the customer information control system (CICS) transaction processing system, DB2 commands, and batch SQL. Calls to the database from the NSLDS Web sites are made by either CICS transactions or Java Database Connectivity (JDBC) transactions.

The primary application software used on the mainframe is CA Gen, working with the DB2. The CA Gen Computer Assisted Software Engineering (CASE) tool is employed for program development, as well as creation/generation of the conceptual, logical, and physical definitions of the NSLDS database. Impact analysis for changes to logical or physical database structures is assessed via the CASE tool, and via the BMC Change Manager tool.

The complete and current description of the structure of all application databases, including the production database, is maintained by DB2 in the DB2 catalog. NSLDS contractor DBAs can access this information as needed, by either querying the catalog directly using SQL, or by using the BMC Catalog Manager tool to retrieve, format, and present the database structures from the DB2 catalog indirectly. The user community (that is, SQL query writers) obtains the same information about the database structure from the User Guide.

Changes to the structure of all application databases are accomplished through the use of data definition language (DDL). The application DBAs prepare the required DDL using the BMC Change Manager product whenever a change is proposed by a task order/modification or maintenance task. The task order/modification or maintenance team, making a change to the database, communicates the change to the user community (that is, SQL query writers) via the User Guide where the current structure of the production and STAB databases is described.

The complete and current description of the tablespace and index storage requirements for all application databases, including the production database, is maintained by DB2 in the DB2 catalog. The contractor DBAs access this information, as needed, by either querying the catalog directly using SQL, or by using the BMC Catalog Manager tool to retrieve, format, and present database object storage information from the DB2 catalog indirectly.

Database Security Management [redacted]

Performance Various DB2 physical design strategies are currently used to improve NSLDS database performance. These strategies include tablespace definitions, physical space allocations, and index definitions. Additionally, the DB2 Optimizer plays a critical role in determining access paths used when programs are executed against the database. NSLDS analyzes selected access paths with the CA Plan Analyzer tool. When feasible, additional database objects are defined to improve performance. In the Production environment, the CA-INSIGHT™ product is used to monitor both DB2 system and program performance. De-normalization and changes to DB2 table relationships have been executed in the past to improve performance.

B. NSLDS Websites As mentioned above, two websites (the NSLDS Student Access and Financial Aid Professionals websites) are part of the NSLDS production environment and interact with the production database. The following diagrams illustrate the high level architecture of the NSLDS Student Access Web interface and the Financial Aid Professionals interface.

1.Student Access Website Architecture (Note: The Loan Exit Counseling page no longer contains functional code with the movement of Loan Exit Counseling functionality to the COD studentloans.gov system. A link to studentloans.gov however currently resides on this page, referring students seeking loan exit counseling to the external site. )

NSLDS Student Access

Financial Aid Review

Loan Exit Counseling

Frequently Asked Questions

Browser Information/Setup Glossary of Terms ED Home

128-Bit Encryption

PIN Site

Aid Summary

Loan Detail Grant Detail Aid Overpayment Detail

Revised: December 2011

TEACH Exit Counseling

Borrower Access Authorization

Browser Setup Download Browser Strong Encryption Information

System Requirements

Grant Access Authorization

2. Financial Aid Professionals (and Training) Website Architecture For a complete description of the functionality contained on the FAP site functional areas listed in the diagram below, please see the associated business area sections of this Current State document.

AIMS

WELCOME AND

MAIN MENU

SECURITY AND

NAVIGATION

ORGANIZATION REPORTSENROLLMENTFINANCIAL AID TRANSFER

MONITORING

NSLDS STUDENT

ACCESS

SUPPORT

Revised: December 2011

NSLDS Production Environment
Additional Information:
A. Database
B. NSLDS Websites
1.Student Access Website Architecture
2. Financial Aid Professionals (and Training) Website Architecture

File details come from the government source that posted it. Updated .