The Titan User's Guide is published and maintained by the Center for
Information Technology, for those who use the Titan mainframe (z/OS) system of
the NIHDataCenter.
This manual describes the services, registration, standards, security-related
issues (see Section 4), where to go for additional information, and contacts
for customer support. Refer to the manual Titan Batch Processing for
information on batch processing and job control language (JCL) for the Titan
system. See Section 5.4 for information on ordering documentation.
Visit
the CIT Titan system on the Web by going to:
and
clicking on NIHDataCenter
under the Quick Links list on the right.
Any questions about the content or meaning
of information in the Titan User's Guide
should be directed to the NIH Help Desk. The location and telephone number for
the NIH Help Desk and other
important groups can be found in Section 1.3.1.
Other enterprise application hosting
systems—EOS, a Unix-based system for general applications; and Windows Server
Services—are only briefly described in this
document. Please contact the NIH Help Desk
for further information about the Unix and Windows platforms.
Between updates to this manual, users are informed of changes
through CIT's online resources including:
·Interface, a Web-based periodical. To
subscribe to Interface Online via Listserv or to order the printed
version, go to http://datacenter.cit.nih.gov/interface.
These
resources announce changes in CIT policies and standards of service, as well as
all significant modifications to hardware and software on various platforms at
the data center. This version of the Titan
User's Guide is updated through Interface
Number 239, Fall 2007 and the Titan News
online newsletter of November 14, 2007. New and prospective customers may
obtain the latest issue of Interface from the NIH
Help Desk (See Section 5.2.1.) For CIT publication services, visit:
CIT
provides a variety of data processing
services on a cost-recovery basis to the NIH and other government agencies, and
also conducts research and development related to
the application of computer methodology to biomedical research.
Among
its activities, the CIT:
·engages in collaborative research and provides
collaborative support to NIH investigators in the area of computational
bioscience
·provides efficient, cost-effective information
systems and networking services
·provides state-of-the-art scientific and
administrative computing facilities
·identifies new computing technologies with
innovative applications to biomedical research
·creates, purchases, and distributes software
applications
·provides NIH staff with computing information,
expertise, and training
·provides data processing and high-performance
computing facilities, integrated telecommunications data networks, and services
to the U.S. Department of Health and Human Service (HHS) and other federal
agencies
·serves as a data center to HHS and other federal
agencies
·develops, administers, and manages NIH systems
and provides consulting services to NIH Institutes and Centers (ICs), in
support of administrative and business applications.
This section
briefly describes some of the components of the Center for Information
Technology.
1.1.1Office of the Deputy Chief Information Officer
(ODCIO)
The Deputy Chief Information
Officer advises the Chief Information Officer (CIO) on the direction and
management of significant NIH IT program and policy activities under relevant federal
statutes, regulations and policies. The ODCIO also develops, implements,
manages, and oversees NIH IT activities related to IT legislation, regulations,
and NIH and other federal policies:
·ODCIO
directs NIH's IT capital planning processes with regard to major IT investments
and provides leadership to NIH ICs to enhance and strengthen their IT program
management so they comply with legislative and policy requirements.
·This office
serves as principal NIH liaison to HHS, its OPDIVs, and other federal agencies
on IT matters.
·ODCIO
identifies critical IT issues and analyzes, plans, leads, and manages the implementation
of special HHS or federal initiatives as they relate to the management of NIH's
IT resources.
·The office
collaborates with NIH managers responsible for IT-related functions, in
particular, IT security. ODCIO staffs and supports NIH's Incident Response Team
(IRT). The IRT serves as the focal point for IT security incidents by
identifying and characterizing incidents, and providing immediate diagnostic
and corrective action when appropriate.
The Division of Computer System Services
(DCSS) plans, implements, operates, and supports centrally owned or
administered computing resources for NIH enterprise use. The division promotes
awareness and efficient and effective use of these computing resources by
customer personnel through training, presentations, consultations, and
documentation.
DCSS
operates enterprise-wide e-mail and messaging services for NIH; the
multi-platform NIH Data Center for application and Web hosting, including
co-location and disaster recovery services; and the Helix systems for NIH
scientists. We work closely with our customers to meet the hosting requirements
most suitable for their applications.
DCSS
investigates new and emerging computing requirements of customer programs. It
conducts research to identify, evaluate, and adapt new computer architectures
and technologies to meet customers’ needs and to enhance current service
offerings.
Customers
can access scientific and administrative data and applications, as well as
develop new applications to meet the needs of an office, an agency, a lab, or a
worldwide community of collaborators using the computing environment and
platform most suitable for their applications.
Designated as a HHS consolidated data
center, the NIHDataCenter
offers full-service enterprise application hosting on the data center's
mainframe z/OS (Titan), Unix (EOS), and Windows servers as well as co-location
services for customer-owned servers. Both
full-service application hosting and co-location services offer:
·yearly SAS 70 Type II audits—validate the
data center’s physical security, operating practices, and procedures
·physical security—includes
card key and biometric access, video monitoring, and guards on duty 24 x 7
·redundant,
high-bandwidth connectivity
·reliable
infrastructure—climate control, UPS (uninterruptible power source)
·operations staff
on-site, 24 x 7
The
NIHDataCenter
can host enterprise applications for NIH and other government agencies.
In general, the NIHDataCenter operates on a fee-for-service
basis; that is, charges to customers are based on the resources they use. See
Section 3.1 for the current rates for the Titan system.
The
data center supports high-speed network connections. NIHnet, supported by CIT,
is the NIH backbone network that interconnects the Institutes and Centers
(ICs), local area networks (LANs), and the NIHDataCenter with the Internet, Internet2, HHS
operating divisions, and other government agencies. For additional information
on NIHnet, see Section 6.1.
Co-Location
Services
Many organizations already own their own
servers for hosting applications but find that they are simply running out of
floor space or they lack the resources (e.g., security, redundant power, and
high-bandwidth connectivity) to house their servers properly. To address this
problem, CIT offers on-campus and off-campus co-location—housing customers' equipment
in a secure, climate-controlled environment, where customers have 24 x 7
access.
The
data center supports co-location services for servers owned and managed by our customers.
As with other services, use of the NIH co-location facilities is charged on a
cost recovery basis. Fees for this service are based on the amount of space and
power required by the customer.
·The two on-campus co-location sites are in
building 12—in secure, separate parts of the CIT data center.
·The off-campus co-location site is in a secure
commercial location connected by extremely high bandwidth—away from the NIH
campus (in Northern Virginia), yet under the auspices of CIT. The off-campus
co-location still ensures the full confidentiality, availability, and integrity
of NIH information.
and select
Co-Location services under Quick Links, on the right.
Full-Service
Hosting
Full-service application hosting on our
secure, well-managed, central servers running z/OS (Titan), Unix (EOS), or
Windows provides:
·firewall and intrusion detection services,
penetration testing, security assessments
·maintenance and backups for your files
·a disaster recovery program available for
your critical applications
·comprehensive change management
·redundant hardware and software in critical
areas
·24 x 7 system monitoring and problem resolution
·multiple platforms
·all server maintenance
·access to data on other systems
·dedicated application coordinators to help our
customers
To
assist users with the full extent of services, CIT provides consulting,
training, and documentation. This manual is intended to provide users with a
general description of what the Titan system offers and how to use it
effectively.
Besides
Titan, other components of the enterprise systems include:
EOS (Unix)
EOS—a Unix-based environment at the NIHDataCenter—currently hosts a
variety of production and development applications. EOS provides a stable,
robust hosting solution for enterprise-wide Unix applications. It features both
high-end and mid-tier servers, as well as shared and stand-alone servers for
Oracle databases. CIT works with users to customize hardware and software configurations
to meet their requirements. For more information, refer to the EOS User's
Guide, available from the CIT publication service (see Section 5.4).
Operating
systems:
·HP-UX
·Sun Solaris
·Tru64 Unix
Database:
·Oracle on shared or dedicated Unix servers
Connectivity:
·FISMA-compliant highly available, secure
connectivity, such as:
·SSH
·Connect:Direct
Middle
Tier Application Servers:
·Oracle Application Server
·Netscape Enterprise Server
·Apache Server
Windows Server Services
The NIHDataCenter hosts Windows-based
applications on HP Enterprise class servers and SANs (storage area networks) that
are carefully managed and monitored on a 7x24 basis. The Windows servers
provide a computing environment suitable for critical enterprise-wide
applications.
We
support the major components of the Windows Server Suite─including
Terminal Server, SQL Server 2005, and IIS─in our enterprise-wide
environment. The NIHDataCenter
provides these services in both a shared and dedicated server environment. In
addition, we support ColdFusion in both a shared and dedicated Web environment.
Microsoft’s Content Management Server provides application
hosting in a shared Web environment, saving your organization money by
leveraging an economy of scale model. The
Division of Enterprise
and Custom Applications is partnering with the Division of Computer System
Services to provide the application and template development for the NIH
Content Management Server service.
The
Windows environment supports SharePoint, a Web service for information sharing
and document collaboration using Microsoft Windows SharePoint Services (WSS).
The NIHDataCenter also offers a Virtual
Server service in the Windows environment that resides on a pool of servers
running under VMWare ESX software. Server virtualization allows multiple
operating system instances to pull resources from a pool of physical servers.
The customer receives an economical service similar to having a dedicated
server, even though multiple “virtual systems” are running on the same server.
Other Services:
·Central Email Service (CES) providing e-mail and messaging services
for the NIH community, including Active Directory (AD) services
·a disaster recovery program for disaster
recovery facilities and services for “critical” applications that run on the
Titan and EOS systems (see Section 4.4)
·search engine services for NIH Web sites,
using Google
The NIH Helix
Systems manage high-performance computing systems for the NIH intramural
scientific community. The front-end SGI Origin 2400 system (with the network
name helix) is used for many scientific applications as well as general purpose
tasks, such as reading mail, transferring files, and Web browsing.
Additional systems offer special computational
capabilities that enable compute-intensive scientific applications to run
faster or more efficiently. An SGI Origin 3400 (nimbus.nih.gov) augments helix
by running specific scientific applications or user programs that require long
execution times. The SGI systems run the IRIX operating system. The NIH Biowulf
Cluster (biowulf.nih.gov) is a 4500+ processor Linux cluster, built by members of
the Helix Systems staff, that runs the Redhat Linux operating system.
In addition
to the standard Unix tools for software development, text formatting, and
network communications, software packages for the Helix System include:
A large collection of
nucleic and protein sequence databases are maintained in several formats on the
Helix Systems, including Genbank, GenPept, NCBI’s nt and nr, Refseq, Swissprot/Trembl,
and genome data. A comprehensive list with details and update status is
available at:
·Scientific
applications: EMBOSS Lite (formerly GCG-Lite), Molecules To Go, UCSC
Genome Browser mirror, ExPlain, Transfac, TransPath, TrxFacMiner, structural
biology tools, and other Web interfaces to scientific tools
The
Division of Computational Bioscience (DCB) of CIT is a research and development
organization that provides scientific and technical expertise in computational
science and engineering to support the NIH Intramural Research Program (IRP).
Working with all of the Institutes and the Clinical Center, DCB applies the
concepts and technologies of computer science, engineering, physical science
and mathematics to biomedical applications including the areas of image
processing, biomedical informatics, genetic databases, structural biology,
scientific visualization, medical imaging, telemedicine, signal processing,
biomedical instrumentation, and biomathematics. DCB develops computational
methods and tools for solving biomedical laboratory and clinical research
problems and manages centralized scientific computational and communication
systems. DCB also provides an environment to mentor computational scientists
and engineers for careers in biomedical research.
The Division of Enterprise and Custom Applications (DECA)
supports the NIH through development and management of NIH business
applications. DECA offers experienced analysts, developers, and project
managers who are committed to providing top-notch service backed by technical
excellence, innovation, and our proven software development process. We provide
centralized, modern application development services to the NIH, HHS and other
federal agencies and manage a large number of IC specific software projects
that benefit tens of thousands of users annually.
The
Division provides advisory and integration services to take advantage of
best-of-breed COTS & GOTS solutions and to ensure compliance with NIH's
Integrated Enterprise IT Architecture.
The Division of Network
Systems and Telecommunications directs the engineering, design, implementation,
and support of network infrastructure and services for the NIH wide area
network (NIHnet) to facilitate the use of scientific, administrative, and other
business applications. The Division manages and directs NIH telecommunications
systems and develops technical requirements for the NIH ICs and implements
telecommunications programs to meet the needs of the NIH community.
DNST researches, develops, and tests
next-generation networking/telecommunications technologies and develops and
supports applications using new network technologies, such as telemedicine and
video conferencing. It provides consulting, guidance, and support to the ICs,
helping them to meet their network requirements. To improve the information
infrastructure on networking/telecommunications activities, DNST serves as
liaison to the NIH ICs and other HHS components.
DNST provides cost effective and reliable video and wireless
services for the NIH and HHS; provides a robust cost efficient and scalable
cabling plant to support multimedia services at the NIH; and facilitates the
implementation of Federal Telecommunication System services. DNST assists NIH
customers in implementing video conferencing and video streaming solutions. The
Division provides two-way radio services that meet the requirements of the NIH
public safety and facilities maintenance communities; and facilitates the
implementation of Federal Telecommunication System services.
The Division manages the cable
plant facilities and the physical environment of the communications
infrastructure. It collaborates with application developers to design
general-purpose software tools that provide end user interfaces to the cable
database system; and provides direct end user support for cable database
questions and concerns.
DNST serves as the focal point for
telecommunications service orders, and develops and disseminates recommended
standards, policies, and procedures for the nationwide implementation and
management of NIH networking and telecommunications systems. DNST also
develops, implements, and supports remote access services to NIHnet, technical
support for wireless services, and a 24-hour telephone/network support service.
The
Division of Customer Support provides centralized, integrated computer support
services to the NIH computing community. DCS advocates customer needs to CIT
management and staff, and represents CIT services and policies to customers. It
plays an active and participatory role in supporting desktop computing to the
end user in the areas of software and hardware, including Internet, telecommunications,
and access technologies. DCS manages the NIH Help
Desk, which provides support for the wide range of IT
services used at the NIH and central account establishment and management. DCS
provides support tools for the NIH IT community, including a service request
tracking system, knowledgebase, and automated call distribution. DCS manages
the iSDP program, which establishes volume discounts and enterprise licenses
for commodity software and hardware for the entire Department of Health and
Human Services. DCS also coordinates and oversees CIT's Training Program for
the benefit of the NIH computing community.
The NIHDataCenter
and its associated offices are in buildings 12, 12A, and 12B on the NIH campus
at 9000 Rockville Pike, Bethesda,
Maryland20892.
The second primary location for the Center for
Information Technology is located at 10401
Fernwood Road, Bethesda, Maryland20817,
a few miles northwest of the main NIH campus.
The main entrance to the NIH Campus is the NIHGatewayCenter at Metro located
at Rockville Pike and South Drive.
This entrance is open 24 x 7 for vehicles and pedestrians.
NOTE:
Due to security measures, access to the campus is limited. In addition, parking
is extremely limited. Visitors are encouraged to use public transportation. Admittance
requires a NIH ID or security screening for non-NIH personnel. For the most
current access information, refer to:
For
questions about campus access, please contact the ORS Information Line at
orsinfo@mail.nih.gov or 301594-6677, TTY - 301-435-1908.
Figure
1‑2. Map of Washington
Area
Figure 1‑3.
Map of NIHBuilding 12 Complex
Figure 1‑4. Map of FernwoodBuilding
Access
Note: Overflow from the visitor parking
lot is directed to the covered parking garage accessible from Rockledge Drive.
Directions to the NIHDataCenter
By subway:
·Take the Metrorail Red Line to MedicalCenter stop.
·Continue walking forward down South Drive after getting off the
escalator.
·Cross the intersection of Center Drive (stop sign). The NIHDataCenter (building 12A) is
on the left behind building 50.
See
map for Metrorail.
By car:
Interstate
495 Westbound
·Take exit 33B Connecticut Avenue (Chevy
Chase).
·Turn left onto Connecticut Avenue.
·At first traffic light, Jones Bridge Road, turn right.
·Turn right on Rockville Pike and drive .2 of a
mile on Rockville Pike. Turn left into the main entrance of the National
Institutes of Health on South
Drive. Go approximately .2 of a mile just past Center Drive
·The NIHDataCenter
(building 12A) is on the left, behind building 50.
Interstate
495 Eastbound
·Take exit 34B Wisconsin Avenue/Bethesda.
·Drive approximately two miles south on Rockville
Pike.
·At the traffic light at South Drive, turn right into the main
entrance of the National Institutes of Health.
·Go approximately .2 of a mile just past Center Drive
·The NIHDataCenter
(building 12A) is on the left, behind building 50.
Interstate
270 (from Gaithersburg)
·Take I-270 to Rte. 495 Washington (East).
·Exit Rte. 495 at Rte. 355 (Wisconsin Avenue).
·Drive approximately two miles south on Rockville
Pike.
·At the traffic light at South Drive, turn right into the main
entrance on the National Institutes of Health.
·Go approximately .2 of a mile just past Center Drive
·The NIHDataCenter
(building 12A) is on the left, behind building 50.
Wisconsin Avenue
(from D.C.)
·Proceed north from the District (past the north
end of Bethesda Business District) to South
Drive. This is the main entrance to the National
Institutes of Health.
·Turn left and go approximately .2 of a mile just
past Center Drive
·The NIHDataCenter
(building 12A) is on the left, behind building 50.
NIH visitor parkingis
extremely limited. We strongly encourage the use of carpools and public
transportation. The NIH Police strictly enforces all parking regulations.
By bus:
·Metrobuses and Montgomery County RideOn buses make stops at the
Medical Center Metro stop. Call Metro information for time schedules and routes
(202) 637-7000.
·The NIH Shuttle service provides regularly
scheduled transportation around the main campus and between the campus and
other area NIH locations.
This section contains a
telephone directory to key services. Keep the following information in mind:
·Users without a direct network connection can
access Titan and the Helix Systems through remote access technologies. See
Section 6.1.3.
·Long
distance users, whose data phones are not on the FTS2001 system, can access the
interactive services through 800/866 numbers.
·Ten-digit dialing is required for all NIH/HHS
phone numbers in the Rockville/Bethesda area. This also affects dialup access to the NIHDataCenter's systems via Parachute.
The NIH Enterprise Directory
(NED) is a centrally-coordinated, electronic directory, developed by CIT, to
maintain accurate, current information for all NIH workers and people using NIH
services or facilities. NED is also used by administrative personnel for
authorizing NIH services such as ID badges, NIH Library privileges, listing in
the NIH Telephone and Services Directory, parking permits, Active Directory
accounts, and Exchange mailboxes.
The public information on a person
in the NED includes—telephone, pager, and fax numbers; e-mail address;
building, room; mail stop, postal address, delivery address, and Web address.
The NED also stores a person’s title, IC, organizational unit, and
organizational status (Civil Service or Public Health Service employee, fellow,
contractor, guest, volunteer, summer employee, or tenant). Individuals are
identified in the NED via their NIH ID—the 10-digit number at the bottom of
their ID badge. As more and more NIH systems use the NIH ID for identification,
it is important that all records in the NED be accurate and current.
The information in the NED and all
changes made through the NED are propagated to Web Sponsor (see Section 2.3).
Updating Entries
If you are associated with NIH,
you can update most of your own customer information using the NED.
Assistance
If you need assistance
concerning the NED or the NIH Login (NIH user name and password), please
contact the NIH Help Desk. See Section 5.2.1.
The CIT Customer Locator provides account and directory information for
anyone with a Titan userid, through the Web. Users can learn the names of the
account sponsor and alternate sponsors for a Titan account. This facility
displays directory information by user name or by the Titan userid. Users can
set or change their output box numbers using Customer Locator. For information
on output boxes, see Section 5.6.1. Customer Locator also has links to the NIH
Enterprise Directory (NED) and the HHS Employee Directory.
If you are associated with NIH, you can find out if your NIH ID is
registered through the Customer Locator. Enter your Titan userid in the box
next to Customer Userid, and click Display at the beginning of that line. The
customer information displayed should include your NIH ID (toward the bottom).
Access
You can use the
Customer Locator through your Titan login or your NIH Login (user name and
password).
The Department of Health and
Human Services organizational directory is available on the Web. You can search
the directory by employee name or look for information for a particular office.
Employees can correct their directory information using an online form. Go to:
Although the mainframe
component of the NIH Data Center operates on a seven-day 24-hour basis, the
availability of individual services varies. The operating hours for all the
enterprise systems (Titan, EOS, and Windows Server Services) can be found on
the Web by going to:
and scroll down to click on the
link for the Maintenance Calendar.
Special arrangements for service
beyond the announced schedule may be possible if needed; contact the head of the
Data Center Operations Branch through the NIH Help Desk. See Section 5.2.1.
Unattended
Service on Titan
Unattended serviceallows the use of some Titan services during
periods of time (such as holidays) when these services would otherwise be
unavailable. For the details on unattended service and information about
specific holidays when unattended service will be in effect, go to:
Unattended service currently
consists of ISPF, TSO, DB2, Model 204, and WYLBUR availability. Users can do
most of their regular tasks using those software applications during the
unattended service period. All batch processing services that do not require
foreign tape access are available. During unattended service:
·No jobs are printed on the central printers.
·No foreign tapes are mounted (NIH tapes can be
mounted).
·Normal OUTPUT HOLD time limits
are enforced for jobs not awaiting printing.
All users of the CIT
enterprise systems are expected to abide by all laws and regulations regarding
the proper use of government information technology resources. Users are
expected to comply with the following when using the CIT systems:
·The
enterprise systems are to be used for official government business only. Users
must not use the systems for personal gain, outside business activities,
political activity, fund raising, charitable activity not sponsored by a
government agency, or for playing games (even in learning situations).
·Users must not use CIT systems to produce,
store, display, or transmit material that is offensive to others including
sexually explicit or suggestive materials.
·Users must not use the CIT systems to produce,
store, display, or transmit material that constitutes harassment of other
individuals on any basis including race, ethnicity, or sexual orientation.
·Users must not use the CIT systems as a staging
area for gaining unauthorized access to any other information systems or for,
in any way, damaging, altering, or disrupting the operations of the other
systems.
·Users must not use the CIT systems and services
for capturing or otherwise obtaining passwords, encryption keys, or any other
access control mechanism that could permit unauthorized access to any computer
system.
·Access to information on the CIT systems is the
sole responsibility of the “owner”―the account sponsor or registered
user―of the information. Users must not access that information without
the explicit permission of the owner, regardless of the degree of access
control applied. The only exception is users may freely access information that
is stored under a facility for general availability such as the Web or public
libraries.
·Users are expected to use the services and
facilities provided by the CIT systems in accordance with the standards set
forth in the appropriate guides. If a facility is not described in any guide,
contact the NIH Help Desk for assistance before attempting to use it.
·Users must not use electronic communications
such as electronic mail to harass others, send obscene messages, forward chain
letters or hoaxes, or send mass mailings indiscriminately.
Users who violate these rules of
behavior are subject to disciplinary action in accordance with the NIH
Information Technology General Rules of Behavior.
Authorities:
·Public Law 93-579, U.S. Code 532(a), the Privacy
Act (1974)
·Public Law 99-474, 18 U.S. Code 1030, the
Computer Fraud and Abuse Act (1986)
·Standards of Ethical Conduct for Employees of
the Executive Branch, 5 C.F.R. Part 2635
·HHS Standards of Conduct, 45 C.F.R. Part 73,
Subpart M
·NIH Information Technology General Rules of
Behavior at:
Software distributed
by the NIH Data Center, CIT, is obtained under a variety of legally binding
license agreements that restrict the use, duplication, and transfer of the
software and associated documentation. Unauthorized use, duplication, and/or
distribution of this software can result in penalties for both the individual
responsible and the National Institutes of Health, including civil damages up
to $50,000 for each occurrence and criminal penalties including fines and
imprisonment.
Each software package and
associated documentation distributed by the data center is authorized for
limited use in conjunction with the services provided by the NIH Data Center.
This software and documentation may not be duplicated or transferred to any
other individual or facility. Each user who requests and receives software
distributed by the NIH Data Center is responsible for insuring its proper
use. In the event of improper use, unauthorized copying, or redistribution of
the software and/or associated documentation, the NIH Data Center will
contact the responsible user and account sponsor for corrective action. If
questions arise about software distributed by the NIH Data Center, please
contact the NIH Help Desk. See Section 5.2.1.
When an organization is
preparing or administering a contract for an application to be used at the NIH Data
Center, the staff should pay particular attention to the following sections of
the Titan User's Guide:
1
ORIENTATION
2
REGISTRATION
AND DEREGISTRATION
4
SECURITY
AND DISASTER RECOVERY
5.1
SOFTWARE
SUPPORT
5.2.5
Assistance
for Implementing Non-NIH Software
7.1.1.2
Software
Features Not Permitted at NIH
9
BATCH JOB
SERVICES
In addition, the contracting
office and account sponsor should be familiar with the Titan User's Guide.
The Titan User's Guide defines the NIH Data Center's current software
standards; however, these change with the passage of time, in response to the
needs of our users and developments in computer technology. Because of this, it
is a good idea to discuss the proposed software with the Application Services
Branch (ASB) before the contract is finalized. The staff will be able to
provide guidance, including information concerning hardware and software changes
which may occur in the relatively near future. ASB is also familiar with many
alternatives that may be used in place of standard IBM facilities and other
software whose use is not permitted at NIH. Contact our staff through the NIH
Help Desk. See Section 5.2.1.
It is important that all of our users have full
access to CIT services and facilities. The Americans with Disabilities Act of
1992 was passed to ensure that persons with disabilities have equal
opportunities and guarantees of civil rights. “Reasonable” accommodation,
access to facilities and alternate forms of media and communication are
inherent in the implementation of the Act. CIT is in compliance with Section
508 of the Rehabilitation Act, amended in 1998, concerning the accessibility of
electronic and information technology (including Web pages) for persons with
disabilities. For information about Section 508, go to:
The NIH Data Center and the
associated offices of CIT, such as the NIH Help Desk and the CIT Computer
Training Program, are located in wheelchair-accessible buildings. Individuals
who are hearing or speech-impaired can contact any person or office within the
Center for Information Technology via a
TDD/ TTY (Telecommunications Device for the Deaf) located in the office
of the Computer Training Program. The TDD is answered during the office's
regular hours. See Section 1.4.
CIT is currently running a
pilot project with several participating ICs to test the NexTalk system (NTS).
This service allows people with hearing disabilities, who have computer access,
to communicate "live" with someone, without having to use a TTY-type
device. There is no audio component to the client and all textual functions of
the client are certified to be Section 508 compliant. For more information, go
to:
All users, including individuals
with disabilities, are welcome to attend any course in the CIT Computer
Training Program for which they meet the technical and administrative
prerequisites. There are elevators at both CIT training sites─buildings 12A
and Fernwood. At each site, the classrooms and restrooms are on the same floor and
are wheelchair accessible. Because elevators cannot be used in case of fire, students
who may need assistance negotiating the stairs should inform the Training
Program before the first day of class.
If any special services (such as
recorded notes) will be needed, individuals should contact the Training Program
at least 2 weeks in advance to make the necessary arrangements.
Users with special needs
who would like to make suggestions concerning the accessibility of the NIH Data
Center and its related CIT services should contact the NIH Help Desk or submit
a CIT Service Request (see Section 5.2.2).
For more information on IT
accessibility resources and other accessibility resources, go to:
This section describes how to
register users for the services offered by the Titan system and how to
deregister users. Contact the NIH Help Desk if you have questions concerning
registration and deregistration. See Section 1.3.1 for the phone number.
When an organization uses
Titan services, CIT assigns certain responsibilities relating to registration,
deregistration, billing, and security to persons within the customer
organization. CIT refers to these account officials as:
·account sponsors (see Section 2.2.1)
·deregistration officials (see Section 2.4.1)
·billing coordinators (see Section 3.2.1)
·security coordinators (see Section 4.5)
Characteristics of account
officials:
·All account officials should be familiar with
the Web Sponsor facility for displaying and changing account and customer
information. (See Section 2.3.)
·For each Titan account official role (except
deregistration officials), there is one primary and any number of alternates.
·Officials do not have to have a valid userid for
the account(s) for which they are an account official.
·A person within an organization can hold several
positions. For example, the account sponsor can also be the security
coordinator, the billing coordinator, and the deregistration official.
·All Titan account sponsors and deregistration
officials must be government employees.
The IC (institute/center)
Executive Officer or responsible agency official assigns a deregistration
official for an account. The deregistration official, in turn, can change the
primary account sponsor. In addition to the deregistration official, the
primary account sponsor can assign and remove alternate account sponsors, and
reassign the primary account sponsor. Any account sponsor can assign, reassign,
or remove security coordinators and billing coordinators.
The
Account Sponsor Interest Group (ASIG) provides an informal forum for discussion
of issues important to account sponsors, deregistration officials, and other
account officials (e.g., billing coordinators, security coordinators). For more
information, subscribe to the ASIG-L Listserv list. Go to:
You must be a registered user
to take advantage of the services provided by Titan. Registration certifies
that the user has an operating program requirement and funds with which to
reimburse CIT for services received.
New
users are welcome at the NIH Data Center. If you are interested in becoming a
user but have questions, the NIH Help Desk consultants will be glad to refer
you to an appropriate staff member.
If There Is an Existing Account
If an account already exists for
your organization, the account sponsor for the organization can simply add new
users to that account through Web Sponsor. (See Section 2.3.) The account sponsor authorizes
the use of resources and services at CIT and can add users to the account.
If This Is a New Account
To initiate a new account, a
person with authority to obligate funds must complete a CIT Account Request form
for the organization. If the sponsoring organization is outside of NIH, an
Interagency Agreement must also be submitted. See Section 2.2.4 for more information about the forms. For
registration information for CIT systems and services, as well as downloadable
forms, go to:
The forms must be faxed or sent to
CIT. After receiving the appropriate forms, CIT will establish an account code
for the user organization. Account codes are unique codes used to identify the
recipient of services. Once the account is set up, the account sponsor can
register additional users for the organization through Web Sponsor. Visit:
After completing the registration
process, the account sponsor receives a unique userid and a temporary password
to give to the new user. The user should immediately change the password to
ensure further security.
Resetting Passwords
Account sponsors, security
coordinators, and deregistration officials can reset the passwords for users
under their account through Web Sponsor (see Section 2.3).
Users can change their own passwords
through Web RACF (see Section 4.6.4). If the users are associated with NIH, they can
reset their Titan passwords using the Password Reset facility, which is
accessed through their NIH Login (user name and password). Go to:
When account sponsors register new
users, they also assign output box numbers for the userid. If the account
sponsor does not assign an output box number, the default is NOBX. Users can
set or change their output box numbers using Customer Locator. For information
on output boxes, see Section 5.6.1.
Registration Data
Account sponsors must maintain
close surveillance of user registration data for their organizations. Current
information (e.g., telephone number, address) on each user must be available to
fulfill security requirements and to permit CIT to contact users directly.
Account sponsors monitor the account through Web Sponsor. For more information
on Web Sponsor, see Section 2.3. For additional information, contact the NIH Help
Desk. See Section 5.2.1.
Each user organization must
appoint an account sponsor as the primary point of contact between the users
and the NIH Data Center. The name of the account sponsor must be specified in
the CIT Account Request form.
How to identify your account
sponsor
To find the name of an account
sponsor for a specific account, use the Customer Locator (see Section 1.3.2.2).
·Select your Institute or Center from the Account
Sponsors and Alternates list.
·Click the Display button. This will display all
the Account Sponsors for your Institute or Center. You may be able to identify
the appropriate person from the list.
Otherwise, talk to your supervisor or
co-worker, or call the NIH Help Desk for assistance.
Responsibilities of Account Sponsors
Account sponsors and their designated
alternates play a vital role in the success of the computer applications that
are run at the NIH Data Center. Because of this, each sponsor should designate
at least one alternate to accept responsibility in the sponsor's absence.
Sponsors and alternates must be government employees. They have full
responsibility for their computer accounts. Account sponsors must ensure that
all computer applications directly relate to the official government business
defined in the request for use of the NIH Data Center, and that all work
adheres to the Center's published standards and procedures. They can reset
passwords and have all of the other security authorities of the security
coordinator (see Section 4.5). Account sponsors can refer to the manual Procedures
for Deregistration Officials and Account Sponsors, available throughthe CIT publication ordering service
(see Section 5.4).
The account sponsor and the
alternate should have some understanding of NIH Data Center operations.
Sponsors are urged to take advantage of the wide variety of services described
in this manual. There are extensive training opportunities offered by the CIT
Computer Training Program (described in Section 5.3). CIT provides documentation via the CIT
publication service (see Section 5.4).
Account sponsors use Web Sponsor to perform account
and userid changes interactively. For more information on Web Sponsor and the
functions that account sponsors can perform, see Section 2.3.
The specific responsibilities include
the following:
·oversee the appropriate use of an account
·add/remove users for an account
·reassign userids within the account
·authorize/remove/transfer customers for CIT
services (e.g., Helix, remote access, etc.)
·close accounts
·change the account title or CAN (Common
Accounting Number)
·change customer information
·employ the security authorities of the security
coordinator (see Section 4.5). This includes resetting passwords,
revoking/resuming RACF access, and changing the password expiration date.
·access billing data
·add, change, or remove:
·alternate account sponsors
·primary and alternate security coordinators and
billing coordinators
·perform data functions (when removing userids
from account)
·deregister users from DB2
·register and remove users from Model 204
·add, change, or remove alternative sponsors,
billing coordinators, security coordinators
·delete user data sets (DASD, tape)
·primary
sponsors only:
·designate a new primary sponsor
CIT wants to know of any problems
encountered by account sponsors and would like to hear about their concerns.
Submit a CIT Service Request to communicate user problems, and to apply for
refunds. See Section 5.2.2 for further information. Occasionally CIT will have
to contact an account sponsor in order to update information or to discuss a
problem concerning the use of an account.
The NIH Help Desk (see Section
5.2.1) serves as the central point of contact for all CIT
accounts and welcomes inquiries from sponsors concerning administrative
procedures.
Accounts identify the customer
organizational unit responsible for reimbursing CIT for the charges that will
be incurred. All accounts on Titan are defined as RACF groups and the userids
and RACFids assigned to an account are members of that RACF group. (See Section
4.6 for information on RACF.)
Userids are required for
accessing system services such as batch jobs, interactive and database systems,
and RACF. A userid identifies a particular registered user of a system. The userid
does the following:
·validates an individual signing on to the system
(like the TSOid)
·acts as the high-level qualifier for user-owned
data sets
·identifies whether a user is permitted access to
data (like the RACFid)
·must be associated with an output box number
(NONE is a valid value for a box); see Section 5.6.1 for more information.
·should not be shared. All users must have
their own userid.
If a user causes systems problems
and cannot be located by CIT staff, the userid will be deactivated until the
staff can contact the user.
Characteristics of Titan Userids
·Titan userids may be from 2 to 8 characters
long, with the first character an alphabetic letter or a $.
·TSOids are limited to 7 characters in length. Userids
of 8 characters cannot log on to TSO.
·In order to avoid problems, users who expect to
develop applications that use UNIX System Services should not have userids that
include a $. In particular, data set names incorporating a $ are treated differently
under UNIX Systems Services.
·Each userid is associated with one, and only
one, account.
·User-owned data sets must begin with either the userid―with
the form userid.name (e.g., johndoe.dataname)―or with the account
(e.g., aaaa.dataname or aaa.dataname). For information on data
set naming conventions, see Section 10.
Figure 2‑2.
Format for Titan Identifications
Titan Identification
Format
userid
From 2 to 8 alphanumeric characters
account
3 or 4 alphanumeric characters
(e.g., aaa or aaaa)
In some cases, it may be
necessary to have userids associated with passwords that do not expire. The
most common examples are for batch jobs that are submitted automatically with
embedded passwords, or for Web or database access from a middle tier
application that connects via a predetermined userid and password. An account
sponsor can add a new customer (userid) through Web Sponsor and specify, “Never
expire” for the password. However, that userid will not be allowed to sign on
to the interactive TSO facility. Userids with non-expiring passwords should be
used only when absolutely necessary.
These userids have the following
characteristics:
·Batch, Web, and database access is permitted.
·They can be used to create data sets.
·Their associated passwords do not automatically
expire after 180 days.
If a user requires remote access to the
NIHnet through Parachute or VPN and does not have a Titan userid, a special
userid will be created when the account sponsor requests remote access service
through Web Sponsor.
These userids have
the following characteristics:
·They contain 8 charactersbeginning with
the letter "R" followed by 7 numbers derived from the user's NIH ID.
·The "R" userids are linked to the
user's NIH Login user name.
·They do not have associated passwords.
·Their only function is to be part of the authorization
process for users who require remote access accounts.
·They
cannot be used to log on to any system, submit batch jobs, or access Web
sites that require a Titan userid (e.g., a SILK Web site)
Scroll down and
click on Forms. Next, select the appropriate form. There is an account request
form for NIH customers (see Section 2.2.4.1) and a separate account request form (interagency
agreement) for non-NIH customers (see Section 2.2.4.2). This site also includes links to other CIT services
such as EOS, Windows Server Services, Helix System, Parachute, and the Central
Email Service.
Anyone within NIH who wishes to open a CIT
account that includes Titan access must fax or mail the NIH customer form to
CIT. Although anyone can request an account, the authorizing official who signs
the form must have the appropriate authority within the Institute or Center
(IC). The requestor should be able to answer questions that CIT may have about
the information on the form. To authorize additional users on an account,
account sponsors must use Web Sponsor (see Section 2.3).
Government organizations outside the National
Institutes of Health may obtain CIT services, including access to Titan,
through an interagency agreement. Organizations should fax or mail the non-NIH customer
form to CIT. Although anyone can request an account, the authorizing official
who signs the form must have the appropriate authority within the government
agency. The requestor should be able to answer questions that CIT may have
about the information on the form. To authorize additional users on an account,
account sponsors must use Web Sponsor (see Section 2.3).
Near the end of the fiscal year, CIT sends out a CIT
Annual Renewal of Interagency Agreement form to each non-NIH organization using
its services. This form must be completed and then faxed or mailed to CIT.
The Executive Officer (for NIH customers) or
responsible agency official (for non-NIH users from HHS and other federal
government agencies) must complete and sign the Deregistration Official
Authorization for CIT Accounts form to assign or change the deregistration
official or alternate deregistration official for CIT accounts. This form must
be faxed or mailed to CIT.
Account sponsors, security
coordinators, billing coordinators, and deregistration officials can use a
Web-based facility―Web Sponsor―to display information and perform
many account and security-related functions for the accounts and userids under
their control.
NOTE: When adding a new customer the account sponsor requests a
userid, specifies the default level of data set access, and selects the
password expiration period.
·Transfer Userid
·Remove Userid
NOTE: A userid cannot be removed until all the resources associated
with that userid are deleted. When a sponsor chooses this option, Web Sponsor helps
the account sponsor perform functions that include deleting cataloged data
sets, removing RACF profiles, scratching migrated data sets, deleting DB2
objects, and removing the Web-based Job Scheduler entries. After all the resources
are removed, the account sponsor can delete the userid.
·Change Customer Information
NOTE: This includesupdating
names, addresses, output box numbers, and telephone numbers for users on their
accounts. Users who are affiliated with NIH, should make these changes via the
NIH Enterprise Directory (NED) interface (http://ned.nih.gov).
See Section 1.3.2.1. Be aware that changes made directly through Web
Sponsor will not be propagated to
the NED, but changes made through the NED are propagated to Web Sponsor.
Account sponsors can use
Web Sponsor to associate a user’s Titan userid(s) with the user’s NIH (NED) ID.
That way all changes to the NED will carry over to Web Sponsor.
·Request Additional Userid
·Reassign Userid to Existing User
·Reassign Userid to New User
·Request Model 204 ID
·Remove Model 204 ID
Display
·Customer Information
·Dsnames
·DB2 Objects
·Customer Log (Web Sponsor displays the number of data sets,
number of tapes, and the Model 204 ID, if there is one, for each userid valid
for the account, or for the specified userid.)
·Resource Matrix (Web Sponsor displays the type
of resources owned by the userid for the specified account as of 02:00 am the
previous morning. These resources include data sets, tapes, Parachute/VPN
authorization, Helix accounts, and Model 204 IDs.)
Security
·Change Titan Password
NOTE: Users with an NIH ID badge number can reset their Titan
passwords directly, rather than going through their sponsors. The requestor is
validated for the specified userid based on their NIH Login user name, domain,
and NIH Login password. Go to the Password Reset facility at:
NOTE: This includes resetting passwords that were restricted under
the former South System to access only certain CIT services. To allow these
userids to access TSO, select the Change Password Expiration link and choose “Expire
after 180 days.”
·Restore Userid
·Revoke Userid
Helix
·Request Password Change
NOTE: Users with an NIH ID badge number can request a reset of
their Helix, passwords directly, based on their NIH Login user name, domain,
and NIH Login password. Go to the Password Reset facility at:
NOTE: Auser must have an NIH Login user name
associated with a Titan userid before a sponsor can request a Parachute or VPN
account for that user. For information on the NIH Login and the NED, see
Section 1.3.2.1.
·Parachute Requests
·VPN Requests
ACCOUNTS
·Close Account
·New Account Form (for downloading)
·Change Account Title (and CAN)
·Change Primary Sponsor
·Add Account Official
·Remove Account Official
Display
·Account Log
·Account Official Information
·Customer Information
·Model 204 Information
·Titan Password Activity Dates
·Remote
Access
·Resource
Matrix
·Helix
NIH nVision Data Warehouse
·CIT Billing Reports
·nVision Data Warehouse Registration
MISCELLANEOUS
·Add Web Sponsor to your NIH Portal Page
·Web Sponsor Documentation
·Submit Comment
Most actions through Web Sponsor
are effective immediately.
RACF security protects all Titan
system data from unauthorized access. The first time the Web Sponsor page is
accessed from a Web browser, a security “pop-up” window prompts for a userid
and password. Only account sponsors with valid userids and passwords will be
allowed to display and change data for their accounts. Account officials who have
multiple Titan userids for a single account should designate one userid for use
with Web Sponsor.
Web Sponsor Access Via NIH Login
Account officials associated
with NIH can access Web Sponsor via the NIH Login. They are prompted for their
NIH Login user name and password rather than their Titan userid and password. The
NIH Login will then find the associated Titan userid. If an account official
has more than one userid that is valid as an account official, a drop-down menu
will offer a choice of userids to use. Go to:
Authentication via NIH Login will
fail if your NIH ID has not been added to your Web Sponsor customer record. To
remedy this, log in to Web Sponsor, click on Change Customer Information under “Customers.”
On the next page, specify your userid or name. Complete your customer record
and click “Submit Request.” Once your customer record has been updated, you can
access Web Sponsor via the NIH Login.
Web Sponsor Via the NIH Portal
Account officials who have personalized a my.nih.gov Web page can
access Web Sponsor through the NIH Portal. To add the "Launch Web
Sponsor" portlet to a NIH Portal page (my.nih.gov), do one of the
following:
·From the Web Sponsor home page, select “Add Web
Sponsor to your NIH Portal Page”
The NIH Data Center has
procedures in place for preventing unauthorized users (e.g., employees who
leave their IC or government agency) from accessing CIT computer systems.
Denying access to employees and contractors who have left the IC is a good
management practice: it prevents unauthorized access to IC data, and the
resulting potential resource cleanup can save IC funds by avoiding unnecessary
computer charges.
Deregistration officials are
responsible for ensuring that users who are no longer authorized to incur
charges have their access/authorities removed from NIH systems. These account
officials have the ultimate responsibility for ensuring that access to CIT
computing services, including financial systems (e.g., databases on the
mainframe system), is denied when an employee resigns or is transferred to another
IC or government agency.
Deregistration officials work with
account sponsors on the deregistration process. “Clean-up work,” (e.g., getting
rid of data sets, removing databases, releasing tapes, etc.) is done solely by
the sponsors (see Section 2.4.2). Note: The
deregistration official can be the same person as the account sponsor.
The following policies apply to deregistration
officials and alternates:
·They are appointed by the NIH IC (Institute, Center)
Executive Officer or by the responsible agency official (for non-NIH accounts).
·Since deregistration officials are responsible
for some issues regarding funds, security, and privacy with respect to the NIH Data
Center, they must always be government employees.
·There must be an alternate deregistration
official who can carry out these functions if the primary is not available.
·Only one primary and alternate deregistration
official are permitted for each account, and each must be a registered user of the
NIH Data Center.
The deregistration official has the
following responsibilities:
·initials paperwork for new accounts, indicating
receipt, thereby ensuring that each account has a deregistration official
·uses Web Sponsor to carry out many functions (see Section 2.3)
·oversees the deregistration of
users from their account(s)
·resets RACF passwords when users leave the IC or
agency
·primary deregistration official only:
·adds, changes, or removes account sponsors,
including selecting a new primary account sponsor
(NOTE: when a new account is opened, the
name of the account sponsor must be specified on the CIT Account Request form)
Deregistration officials use Web
Sponsor to carry out many of their functions. See Section 2.3.
For more information, refer to the manual Procedures for Deregistration Officials and
Account Sponsors, available from the CIT publication ordering service (see
Section 5.4).
Account sponsors use Web Sponsor to help close an
account or to remove a user from an account. If users leave and their NIH IDs
have been included in the Web Sponsor database, Web Sponsor sends e-mail to the
account sponsors and deregistration officials for those accounts. Based on
these e-mails, account officials can then determine when a userid must be
removed or transferred to another user. (See Section 2.3.1, under “Change Customer Information.”)
Closing an account or removing a
user from an account can only take place after meeting all of the requirements
listed below:
·The account sponsor ensures that all computing
resource usage has ceased.
·The userid no longer owns data sets or tapes.
·Data sets and tapes that contain important or
useful data are transferred to another userid.
·All unneeded data sets are scratched and
unneeded tapes released.
The specific steps required to
reassign/release data and resources are listed below. Many of these steps can
be accomplished through Web Sponsor (see Section 2.3), as indicated.
·Reassign data sets by renaming them using
another valid userid. This places the data sets under the control of another
user.
·An alternative is to reassign the userid to an
existing user (Web Sponsor). When using these two methods (reassigning the data
sets or reassigning the userids), the account sponsor should ensure that the
resources used by the reassigned userids are closely monitored.
·Account sponsors should be sure to reset the
passwords (Web Sponsor) for userids that will be reassigned and not deleted.
·Reassign ownership of tapes. To do this you must
copy the entire tape. Change the data set name of at least the first data set
on the tape so that it begins with the userid of the new owner.
·Cancel subscriptions to Internet Listserv lists.
·Remove the userid when the cleanup is complete
(Web Sponsor).
A userid cannot be
removed until all the resources associated with that userid are deleted. When a
sponsor chooses this option, Web Sponsor helps the account sponsor perform
functions such as:
·deleting cataloged data sets
·removing RACF profiles
·scratching migrated data sets
·deleting DB2 objects
·removing the Web-based Job Scheduler entries
After all the resources
are removed, the account sponsor can delete the userid.
·If an account must be closed, first remove each userid
in the account. Once the cleanup is complete, use Web Sponsor to close the
account.
Contact the NIH Help Desk if there are any questions concerning the
reassignment of userids or the deregistration procedure.
A schedule of rates governing
the various kinds of services offered by CIT has been established under the NIH
Service and Supply Fund (Revolving Fund). The schedule of rates for the various
services offered by Titan is available in Section 3.1. For billing purposes, every request for service
identifies the user by the Titan userid described in Section 2.2.3. This code must be used on all requests for services.
CIT billing practices are described in Section 3.2. For refund information, see Section 3.2.2.
Section 3.1 contains the rates as of the publishing date for this
manual. Occasionally CIT must make adjustments to the rate structure during the
year.
For the most current rates for
Titan and additional NIH Data Center services, go to:
*
Model 204 CPU and I/O charges are
computed at either the batch or interactive rate, as appropriate. IMS CPU
charges are computed at the interactive rate.
**A shift discount of 50% applies to both batch and interactive
processing (per CPU second). Prime shift is 7:00 A.M. to 5:00 P.M., Monday
through Friday. Discount period is all other times.
DB2
Processing
Up to 1.70 CPU seconds (per
CPU second)
$
1.81
1.71 to 4.26 CPU seconds (per CPU second)
$
1.33
4.27 to 34.10 CPU seconds (per CPU second)
$
.61
Over 34.10 CPU seconds (per CPU second)
$
.30
SILK/Shadow
Direct Processing
Up to 1.70 CPU seconds (per CPU second)
$
2.85
1.71 to 4.26 CPU seconds (per CPU second)
$
2.61
4.27 to 34.10 CPU seconds (per CPU second)
$
1.21
Over 34.10 CPU seconds (per CPU second)
$
.61
IMSProcessing(per ENTER keystroke)
$
.05
Disk
Storage (per megabyte, per
day)
$
.0103
Backup (per megabyte, per day)
$
.0003
Dedicated disk (per month)
$
2,112.00
Tape
Tape mount
$
.52
Library storage (per tape, per day)
$
.0361
Tape handling for exporting tapes
$
12.00
Tape shipping for exporting tapes
$
10.00
Printing
Standard (per image)
$
.0618
Labels (per 1,000 lines)
$
1.1845
MISCELLANEOUS
SERVICES
Central Printing (LAN Initiated)
Per image
$
.0618
Disaster Recovery (Per Application,
Per Month)
$
708.00
SILK
Web (Per Customized Server, Per Month)
Basic (up to 10 MB
storage, 500 MB data transfer)
Server
charge
$
61.80
Password
protection
$
10.30
Secure sockets layer (SSL)
$
20.60
Intermediate (up to 25
MB storage, 1000 MB data transfer)
Server
charge
$
103.00
Password
protection
$
15.45
Secure
sockets layer (SSL)
$
36.05
Advanced (up to 50 MB storage, 2000 MB data
transfer)
Server
charge
$
206.00
Password
protection
$
20.60
Secure sockets layer (SSL)
$
51.50
SILK
Web (Public and Secure Servers, Per Month)
Unlimited
number of Web pages (“@WWW” data sets) stored under a userid plus normal data
set charges
Discount
service offers a 50% discount to interactive and batch CPU processing between
the hours of 5:00 P.M. and 7:00 A.M. Monday through Friday and all day on
weekends. Federal holidays are treated the same as weekdays. There is no
discount for tape mounting or central printing. To request batch processing
during the discount period, add the following control statement:
/*DISCOUNT
after
the JOB statement. Even if a job does not include a /*DISCOUNT
statement, any job that begins execution during the discount period will
receive the discount rate.
For
more information on job control language, refer to the Titan Batch
Processing manual. See Section 5.4 for ordering information.
Billing
information is available through Web Sponsor and the nVision Data Warehouse Community
of the NIH Portal.
Web Sponsor
Account sponsors and
billing coordinators can use the CIT Billing Reports link in Web Sponsor (click
on Accounts) to view CIT charges for their account and for the individual users
under their account. See Section 2.3.2 for information on how to access Web Sponsor.
nVision Data Warehouse
Community
Account sponsors, billing coordinators, and Data Warehouse
Budget & Finance registered users can use the CIT Billing Queries &
Reports facility, available through the nVision Community. Go to the NIH Portal
(http://my.nih.gov), and select the nVision community.
On the left side of the page, click on
Launch Reports.
On the left side of the resulting page,
click on the plus signs to open these folders in order:
·Public Folders
·Business Areas
·Budget & Finance
Within the Budget & Finance folder,
click on the Applications folder.
CIT Billing appears as one of the
options within the Applications folder. Click on it to open up the CIT
Billing Sign In screen.
Batch Job Charges
Users
who submit batch jobs can look at their output for the estimated cost for each
job step. A sample of job output is included in the manual Titan Batch Processing.
Each organization using Titan must have a
billing coordinator, (usually a financial officer) assigned by the account
sponsor. The billing coordinator deals with the financial aspects of an
account. This official may be a contractor.
There
must be one primary billing coordinator and any number of alternates. The
billing coordinator:
·receives invoices (primary billing coordinator
only) for appropriate accounts
·accesses billing data through the methods described in Section 3.2
If you think that you have been overcharged
for Titan services, you can apply for a refund and CIT will investigate your
charges. CIT will give refunds for jobs that fail due to the following reasons:
·hardware failure
·failure due to NIH Data Center-supported
software
·operational errors
There are no refunds for:
·jobs aborting due to user's application program
failure
·I/O errors caused by defective foreign tapes
·errors occurring or jobs aborting as a result of
the user violating instructions or restrictions as stated in the Titan User's Guide and Titan Batch Processing
This also includes
errors occurring or jobs aborting as a result of exceeding job limits or
failing to follow vendor reference manuals and warnings.
Obtaining Refunds
To request a refund for a run
that has aborted due to an error/problem with NIH Data Center services, the
user should:
·Contact the NIH Help Desk by phone or submit a
CIT Service Request (see Section 5.2.2).
·Submit all supporting documentation (i.e.,
source listing, dumps, and terminal listings) to the NIH Help Desk.
·Preserve unchanged, all the evidence related to
the problem.
CIT will review the request and
contact the user (by telephone or e-mail) to report whether the request for a
refund has been approved or denied. If a refund is not justified, the staff
member will provide the user with an explanation.
If a refund is approved, the
appropriate amount will be credited to the user's account and will appear as a
credit on their monthly statement. Because of the processing overhead, refunds
for services amounting to less than $10.00 will not be credited, however you
can accumulate requests for refunds related to batch charges until they total
$10.00 or more.
CIT
wishes to help users make efficient and effective use of its facilities. This
section includes suggestions to control information processing costs. See
Section 3.2
for information on billing.
Batch Processing
In addition to the hints
below, the documentation for individual programming languages and procedures
often contains additional cost-saving recommendations. To reduce the costs of
batch processing try the following:
·Run batch jobs overnight or during weekends to
obtain dramatic savings. Refer to Section 3.1.
·Reduce the number of tape mounts required by some
jobs.
·If a tape will be used more than once in a step
or in multiple steps, proper JCL can minimize the number of times the tape must
be mounted, and therefore, the corresponding tape mount charges. Use the JCL
subparameter RETAIN in the VOLUME parameter and the PASS subparameter of the
DISP parameter to ensure, where possible, that a tape remains mounted during
and between steps.
·Execute a fully or partially resolved load
module for programs that are run repeatedly rather than compiling the program each
time. For COBOL, FORTRAN, and PL/I, compiler optimization options can provide
additional savings.
·Reblock your files to reduce I/O costs. Small
blocksizes increase I/O counts.
Interactive Sessions
As with batch processing, an
effective way to save money is to use the system during the discount period.
Storage
·Cut costs by storing data economically. Data
sets that are no longer of value should be scratched.
·Condense partitioned data sets (PDSs) using the
RELEASE option with the space allocation.
·Use the NOBACKUP management class for data sets
that do not require data center backup.
·Examine tape usage to determine if some data
should be stored on disk. The convenience, automatic backup, and low disk
charges often make disk an attractive alternative to tape.
The NIH Data Center provides a secure computing
environment, suitable for hosting critical applications and data categorized at
the low or moderate security level (per FIPS Publication 199, Standards for
Security Categorization of Federal Information and Information System) for NIH
and other government agencies.
Appendix III to OMB Circular A-130
states: “The Appendix requires the establishment of security controls in all
general support systems, under the presumption that all contain some sensitive
information, and focuses extra security controls on a limited number of
particularly high-risk or major applications.” CIT, as a provider of general
support systems, manages and configures all host systems in conformance with
the following laws, regulations, and policies to provide the appropriate
protection controls for hosting customer data and applications that are
determined to be rated moderate-risk or major applications:
·Public Law 93-579, U.S. Code 532(a), the Privacy
Act (1974), requires the U.S. Government to safeguard personal data processed
by federal agency computer systems. It also requires the government to provide
ways for individuals to find out what personal information is being recorded
and to correct inaccurate information.
·OMB Circular A-130, Management of Federal
Information Resources (1985), establishes requirements for effective and
efficient management of federal information resources. Appendix III, Security
of Federal Automated Information Resources, establishes the requirements for
agency security programs to safeguard the sensitive information they process.
·Public Law 100-235, the Computer Security Act
(1987) requires every U.S. government agency that processes sensitive
information to have a customized computer security plan for the system’s
management and use. It also requires that all U.S. government employees,
contractors, and others who directly affect federal programs undergo ongoing
periodic training in computer security.
·Federal Information Security
Management Act of 2002 (FISMA), enacted as part of PL 107-347, the E-Government
Act of 2002; codifies the security requirements contained in Appendix III of
OMB Circular A-130. In addition, it requires agency Inspector Generals to
conduct independent audits of agency information security programs, through
testing security controls on a subset of agency systems, and to report the
results to the OMB, which in turn reports the findings to Congress.
·Department of Health and Human Services policies
and guidelines
·NIH data security policies and guidelines
published on the NIH intranet
Significant security controls
for Titan
Security controls for Titan
include:
·restrictions on physical access to the facility
housing the CIT enterprise systems (physical security). See Section 4.1.
·policies and procedures for ensuring that only
authorized individuals are granted access to Titan (user registration). See
Section 2.2 for details.
·policies and procedures for authenticating users
before granting access to Titan (passwords). See Section 4.6.1.
·procedures for ensuring tapes and printed output
are appropriately protected (input and output controls). See Section 4.2.
·procedures for ensuring security violations are
handled and resolved in a timely manner (security violation monitoring). See
Section 4.3.
·a program for ensuring the continuation of
operations following an event that causes an extended disruption of enterprise
systems operations (disaster recovery). See Section 4.4.
·technical controls for protecting data
sets—Resource Access Control Facility (RACF). See Section 4.6.
·annual
SAS 70 audits of enterprise systems processing data and applications to ensure
that the security controls remain effective to protect those data and
applications. (Titan has SAS 70 Type II validation.)
·periodic risk assessments, penetration testing
·formal security plans
·policies and procedures for users with remote
access to NIHnet (e.g., Parachute and VPN). Go to:
·change control procedures covering hardware and
software upgrades and patches
·environmental controls and monitoring to ensure
a stable Data Center climate. See Section 4.1.
While CIT is responsible for
maintaining a secure operating environment on the enterprise systems,
individual users are responsible for ensuring that their own data and
applications are protected. CIT provides the necessary procedures and tools
that enable users to fulfill their security responsibilities.
Access to the entire NIH Bethesda campus,
including the building 12 complex, is tightly
controlled. Employees must present a Department of Health and Human Services
(HHS) photo ID badge (for example, an NIH-issued ID badge). Visitors must
obtain temporary visitors' badges at the NIH Gateway Center (at Metro) or the West
Gateway Visitor Center. For current security procedures in effect at the
NIH campus, go to:
A
security guard is stationed at the main entrance to the Data Center, 24 hours a
day, seven days a week. Badge readers control all other external entrances and
surveillance cameras monitor building access from multiple locations.
Machine
Room Access
The CIT enterprise systems are all housed in the NIH
building 12 complex machine room. Physical
controls that restrict access to the machine room include:
·Badge readers and
iris recognition systems are installed on all entrances to the machine room.
·Badge reader
access privileges are only granted to individuals who require frequent and
regular access to the computers in the machine room.
·Procedures are in
place to annually certify the holders of machine room badge reader access
privileges.
·Individuals, such
as equipment repair persons, who must have unescorted access to the machine room,
obtain temporary badges that allow access for a limited time.
·Everyone else
must display an “Escort Required” badge and be accompanied by a person
authorized for unescorted access to the machine room.
Environmental Controls and Fire
Containment
The temperature and humidity in the machine room are
strictly monitored and controlled for a non-stressed hardware environment.
The machine room is equipped with smoke detectors and an
adequate number of fire extinguishers to contain small fires. The NIH
building 12 complex has sufficient fire
protection due to the rapid response by the NIH fire department.
UPS
System
The machine room equipment is protected from surges or
drops in power supply and power interruptions by an uninterruptible power
supply (UPS) system. The UPS system is designed to provide all electrical
services to the machine room area. When
an interruption occurs, power is supplied by a battery backup system that
provides over 20 minutes of operating capability. After being on batteries for
30 seconds, the diesel generators start up and provide more than 24 hours of
operation per tank of fuel.
The
UPS system has more than 50% excess capacity. Moreover, the batteries,
monitoring and control equipment, and diesel generators are all configured in
three redundant sections. Failure of any one section will result in no more
than a one-third loss of capability, leaving more than adequate capacity to
support all ongoing services until power is restored.
4.2INPUT/OUTPUT CONTROLS
Tapes
CIT processes two categories of tapes:
·NIH-owned – These
tapes are available for assignment to users for storing data and remain under
the control of the tape inventory system.
·“foreign” (or “special”) –These
tapes are owned and supplied by users and are not under the control of the tape
inventory system. Foreign tapes are submitted to the Output Distribution
Services counter in Building 12A. For additional information on foreign tapes,
see Section 10.2.4.
RACF security protects the
data stored on all NIH-owned tapes. Data on foreign tapes is not protected by
RACF controls.
NIH-owned tapes may not be
removed from the data center. Users may copy the information from a NIH tape to
either a tape that they supply or to a tape from a pool of tapes available for
purchase from NIH.
Printed Output
Printed output is placed in
the locked boxes outside the machine room. Only users who know the correct box
access code can access the boxes. See Section 5.6.1 for further details on the locked boxes.
Users have the option of printing “PRIVATE”
on the header and trailer pages of the printed output containing sensitive
information.
CIT monitors the security
status of Titan and takes immediate action if there is an apparent breach of
security. Userids related to any security violation are automatically revoked.
The NIH Data Center security
investigators send e-mail to the security coordinator/account sponsor or
alternate for the account in question. The e-mail details the specific
circumstances of the violation. The security coordinator is responsible for
investigating and resolving the apparent violation. When satisfied that no
improper use of the account occurred, the security coordinator or account
sponsor can reactivate the userid through Web Sponsor. No further communication
with the NIH investigators is required unless the investigation indicated a
security breach did, in fact, occur.
The NIH security investigators are
available to assist with any aspect of the investigation. They may be reached
by calling the NIH Help Desk.
If users discover apparent
breaches of security, such as discovering that an unknown person may have used
their userid, they should immediately notify their security coordinator or
account sponsor. For general security questions contact the DCSS Security
Coordinator.
With today's near total
dependence on automated information systems to support critical organizational
functions, interruption of those services could have severe consequences.
Without adequate planning, an organization will have a difficult time
recovering from an event that causes a long-term interruption to information
system services.
CIT has a disaster recovery
program to provide a foundation for users' disaster recovery planning. The CIT
disaster recovery program covers Titan and EOS. CIT
charges for participation in the disaster recovery program (see Section 3.1). Charges for those applications that require additional
hardware at the hot site or other heightened levels of support will be
individually determined.
Account sponsors must enroll their
applications in the disaster recovery program for their applications to be
covered during a prolonged interruption to services. Contact the Disaster
Recovery (DR) Coordinator to participate or to answer any questions regarding
the program. See Section 1.3.1 for the telephone listing.
Features of the disaster recovery
program include:
·Every week, CIT
creates full volume backups of all Titan volumes, all database volumes, all
private volumes, and all public volumes used for permanent data storage. These
weekly dumps are written simultaneously to two separate automated tape libraries
(ATLs); one located in the NIH Data Center and the second, located over 30
miles from the NIH campus. Both backups are cycled through six sets of tapes so
that six successive weeks worth of backups are always maintained.
·Incremental backups of all changed data sets are
taken daily for public and systems disk storage. Up to five unique backup
versions per data set name are maintained. The incremental backups are written
simultaneously to the two ATLs. In a disaster situation, all usable tapes will
be sent to the hot site.
·CIT has a contract with a commercial vendor to
provide sufficient computer services to support the participating applications
at a fully operational data center, a hot site, if and when a disaster
causes an extended interruption to computer services.
·CIT schedules and
conducts twice-yearly tests of the disaster recovery plan. Testing occurs over
a two-day period with the first day dedicated to testing system recovery
procedures and the second day set aside for customers to test their recovery
procedures.
·Participants in
the program receive on-going customer support for disaster recovery planning
and hot-site preparation.
In
the event of a disaster that requires CIT to move operations to the hot site,
CIT will restore the applications and data for the participating applications.
There is no guarantee that other applications will be serviced following a
disaster.
For more information on the CIT
disaster recovery program, including a link to the documentation, visit:
Each user organization must have a security (RACF) coordinator. There
must be one primary security coordinator and any number of alternates. This
function belongs to the account sponsor until the sponsor designates a security
coordinator. (See Section 2.1.) The security coordinator may be a contractor. The
security coordinator carries out the following functions:
·serves as
the point of contact for CIT security matters
·implements
the account organization's password change policy
·performs
RACF functions for users of an account
·sets Titan passwords
·revokes and resumes RACF access
·changes Titan password expiration
·sets authorities for RACF account group
·creates and maintains generic profiles
·requests password changes for Helix accounts
The security coordinator carries out many of
these functions through Web Sponsor and Web RACF.
Titan provides comprehensive data security
through the Resource Access Control Facility (RACF). RACF is a security system
that protects a data set by limiting who can access the data set and how it can
be used (e.g., read, update). All data sets created at the NIH Data Center are
automatically protected by RACF through the use of generic profiles.
RACF also controls logon and batch submission. The IBM OS Password
Protection facility cannot be used at the NIH Data Center.
Each organization must assign a security
coordinator. The security coordinator is responsible for the implementation
standards of RACF within the agency. Users who need password assistance,
require access to resources that are not currently available to them, or have
other similar RACF problems should contact their security coordinator. NIH Help
Desk consultants cannot help the user in these situations. For additional
information about security coordinators, see Section 4.5.
RACF documentation is available through the CIT publication service
(under the IBM Utilities category). See Section 5.4.
Each user is assigned a password when registered.
This password allows access to Titan services. After you receive your initial
password, be sure to reset it using Web RACF (see Section 4.6.4), Password Reset (see Section 4.6.1.1), or TSO (see Section 4.6.5). See Section 4.6.1.2 for general guidelines for choosing a password.
The
password has the following characteristics:
·It must be 7 or 8 characters.
·The password must include at least one
alphabetic character, at least one numeric character, and at least one special
character.
·The special characters used in the password are
limited to these: #, @, or $.
·It cannot be the same as the Titan userid.
·RACF passwords expire every 6 months (180 days).
·When a RACF password expires, you may not reset
it to any of your 10 previous passwords.
·Titan does
not distinguish between upper and lower case, therefore changing the case of an
alphabetic character does not change the password.
·Users can change their passwords through Web
RACF (see Section 4.6.4), TSO (see Section 4.6.5) or Password Reset (if they have an NIH ID badge
number; see Section 4.6.1.1).
Users associated with NIH also have an NIH Login password. Although the
requirements for a RACF password and the NIH Login password are similar, CIT
strongly recommends that you do not make both passwords the same. This
minimizes the chance that a compromised NIH Login password could be used to
access Titan. Links to information related to the NIH Login passwords may be
found at:
Users who forget their Titan (RACF) passwords
will not be able to log on. Due to the design of RACF, it is impossible to
determine the password for a userid; instead the password must be reset.
Using Web Sponsor
Account
sponsors and security coordinators can reset forgotten passwords for users in
their organization through Web Sponsor. Note:
when the account sponsor or security coordinator resets the RACF password, that
password is temporary and will expire automatically when the user tries to log
on. The user must then reset the password through Web RACF. If you require
further assistance concerning forgotten passwords, contact the NIH Help Desk. See
Section 5.2.1. For general information
about choosing passwords, see Section 4.
Using Password Reset
Users with an NIH Login user name and password, can reset their Titan
passwords using the Password Reset Web page. Go to:
If you are associated with NIH and you forget your NIH Login password,
contact the NIH Help Desk. As an alternative to calling the NIH Help Desk, you
can register for the CIT self-service password management tool, iForgotMyPW,
which allows you to reset your NIH password or unlock your account yourself. You
must pre-register for this service. Go to:
Passwords
are the keys that allow access to the enterprise systems. Therefore, it is
important to ensure that strong passwords (not easily guessed) are used and
that passwords are protected from exposure to unauthorized individuals. See
Section 4.6.1 for the specific requirements for RACF (Titan)
passwords.
Users
can help to ensure that passwords are not easily guessed by following these
simple guidelines:
·Construct a mnemonic password; i.e., think of a
phrase and use the first letter of each word to create the password.
·Devise passwords that include combinations of
letters, numbers, and special characters, preferably embedding the numbers and
special characters within the password, not at the beginning or end.
·Do not choose passwords that are the same as the
login names (userids).
·Do not choose passwords with personal
associations (e.g., names of relatives or pets, phone numbers, license plate
numbers).
·Do not use repeated or obvious sequences (e.g.,
the same alphabetic character repeated 6 times, alphabetic run, keyboard
sequence).
Users
can help protect their passwords by following these procedures:
·Do not write down the password and leave it near
your workstation.
·Do not divulge your password to any other
individual. As a rule, CIT staff never request user passwords. Exceptions occur
when the staff member may need to log on as the individual when all other
avenues of problem resolution have been exhausted. If a staff member initiates
a contact and requests a password, ask for the individual's name and call back
through the NIH Help Desk before fulfilling the request. Be sure to change your
password after the problem has been resolved.
·Use emulator software that supports either
masking or suppressing the printing of the password as it is entered.
·Change your password more frequently than the
required 180 days. Passwords can be changed using the Change RACF Password
option of Web RACF at:
or through the Password Reset facility (see Section 4.6.1.1 ).
For specific information regarding RACF passwords, see Section 4.6.1.
Users
should be careful when entering their passwords. Repeated errors in attempting
to supply a password are logged as a security violation. Excessive failed
attempts will cause the userid to be revoked (i.e., be unusable) until the
security coordinator makes a formal response to the violation notification.
Users should be familiar with the following RACF
terms in order to use the RACF facilities effectively:
RACFid
the
Titan userid
PASSWORD
a protection for the
RACFid. The password is a series of seven or eight characters, specified by
the user. It must include at least one alphabetic character, at least one
numeric character, and at least one special character (from the set #, @ or
$). Passwords expire automatically after being in use for 6 months; they can
be changed through the Change RACF Password function of Web RACF. See Section
4.6.1 for all the rules concerning RACF passwords.
RACF GROUP
or RACF Account Group - is
the same as the user's account. Each RACFid must be registered to one (and
only one) account. A RACF Group may have multiple RACFids registered to it.
USER-DEFINED GROUP
also
called @group - a collection of RACFids that can be treated as a single
entity for the purpose of data set protection. Each user-defined group has
three components: a two-to-eight character name (of the form @name), an
owner, and member RACFids. RACF groups offer a convenient way to control
access to one or more data sets. When you protect a data set, you specify an
access list of users who will be able to read or update the data set. If the
access list includes RACF groups, you can maintain a single RACF group
containing the RACFids of persons who are able to access your data sets.
OWNER
the RACFid with the
authority to perform RACF functions that no other RACFid can perform. There
is an owner for each RACFid, RACF group, user-defined group, and RACF data
set profile.
·The owner of a user-defined group is
established when the group is established. The owner is the group member
RACFid with authority to add and remove members and delete the group.
·The owner of a data set is established through
the RACF Profiles area of Web RACF, and is the RACFid of a user who can
authorize other users (both individuals and user-defined groups) to access
the data set.
The owner is the
only person allowed to change ownership. The owner of a data set can be
changed in the RACF Profiles area (Change owner of RACF profile) of Web RACF.
The owner of a user-defined group can be changed in the RACF Groups area
(Change owner of a group) of Web RACF.
UNIVERSAL ACCESS (UACC)
established
in the RACF Profiles area of the Web RACF facility. It is used to establish
initial protection for the data set. The Universal Access specifies the
default access to the data set for users who have not been specifically
authorized to access the data set.
The choices are:
NONE
allow
no access
READ
allow
only read access
UPDATE
allow read and write access
ALTER
allow read, write, scratch, and rename access
To change the UACC, select the Change Universal Access
function in Web RACF.
ACCESS LIST
the
list of RACFids and user-defined groups that have been authorized to access
the data set, and the level of access (NONE, READ, UPDATE, or ALTER) for
each. The access list is saved in a system database and is not part of the
actual data set. The access list is created and changed through the RACF
Profiles area of Web RACF. To display the access list, use the RACF Profiles
(Display (RACF profile for a data set)) area of Web RACF. In addition to the
authorities listed in the access list, any batch job or interactive session
with a RACFid that is the same as the userid in the high level prefix of a
data set will have ALTER access to the data set.
GENERIC PROFILE
a profile that uses special characters (%,
*, **) to create a “mask” that is compared against the actual name of a given
data set and, if matched, defines the protection for that data set. The use
of generic profiles is highly recommended. See Section 4.6.3.
DISCRETE PROFILE
RACF protection for only one data set. The
name of the discrete profile matches the name of the data set protected. See
Section 4.6.3.
SPECIAL CHARACTERS
(Only one ** special
character is allowed per profile).
the
set of characters (%, *, **) that are used in the profile name to create a
“mask.” If no special characters are used, the generic profile only applies
to one data set, much like a discrete profile.
%
special
character matches one character. There may be one or more in a profile. For
example, $III.DATA%%%.TEST would protect the data set $III.DATAMIN.TEST.
*
special
character matches zero or more characters until the end of the qualifier. It
only applies to one qualifier, that is, the generic profile $III.AB.CD* would
protect data sets $III.AB.CD or $III.AB.CDEF, but would not protect data set
$III.AB.CD.EF.
used
as a qualifier at the end of a profile to match one qualifier until the end
of the data set name. For example, the generic profile $III.AB.CD.* would
protect data set $III.AB.CD.EFG, but would not protect data set
$III.AB.CD.EF.GH.
**
special
character matches zero or more qualifiers. For example, $III.AB.CD.** would
protect $III.AB.CD or $III.AB.CD.EFG, but would not protect the data set
$III.ABC.DEF. Note that the ** must appear immediately after a period (.),
for example, $III.ABC.DE** would be an invalid profile.
All disk and tape data on
Titan must have a RACF profile. To establish the level of protection needed,
use the RACF Profiles area (Protect a data set) in Web RACF. When a new userid is created, the account
sponsor specifies a default level of access (UACC) for all data sets created
with that userid as the high level qualifier.
There are two methods for
protecting data sets with RACF—generic profiles and discrete profiles.
Generic
Profiles
Generic profiles allow users
to create a single profile that protects multiple data sets, and to create a
profile for a data set that remains in effect even when the data set is
scratched and reallocated. Using Web RACF, go to the RACF Profiles area
(Protect a data set) to create a generic profile.
By using the special characters %,
*, ** in the profile name, you can create a data set “mask” that is compared
against the actual name of the data set. If the data set name matches the mask,
it receives the protection defined by the RACF profile. If none of the special
characters are used in the generic profile, only the data set whose name
exactly matches the profile is protected. These characters may be used alone or
in combination to produce highly flexible generic profile names.
For example, the generic profile
AAAAIII.**
protects all data sets stored
under userid AAAAIII.
The profile
$III.QRST*.**
protects all data sets stored
under userid $III whose names begin QRST.
RACF provides the following benefits
for data set protection:
·With RACF generic definitions you can be very
selective as to which data sets are protected based on their names, and you can
have different generic definitions for different sets of names.
·Your associates will be given access
transparently (if they are authorized to it).
Discrete Profiles
A discrete profile can only
protect a single data set. If you are currently using discrete RACF profiles,
you will probably find it more convenient to use generic profiles for the
following reasons:
·If a data set with a discrete profile is
scratched or deleted, the RACF protection also disappears.
·If the data set is later recreated, the discrete
profile will not be automatically recreated. Instead, the data set will be
protected by an existing generic profile.
·Web RACF does not
permit users to set up discrete profiles. To set up a discrete profile, you
must use TSO commands.
Converting to generic profiles is
simplified by the fact that if both generic and discrete profiles protect a
data set, the discrete profile takes precedence. Therefore, you can create the
necessary generic profiles and then DELETE the discrete profiles afterwards. As
the discrete profiles are removed, the generic profiles will provide the
protection.
The following tables were
extracted from an IBM RACF manual and provide a summary of generic profile
naming conventions.
Figure 4‑1. Generic Data Set Profile Names Created with Enhanced
Generic Naming Active—Asterisk and Double Asterisk at the End
Profile Name
AB.CD*
AB.CD.*
AB.CD.**
Resources protected by the
profile
AB.CD
AB.CDEF
AB.CD.EF
AB.CD.XY
AB.CD
AB.CD.EF
AB.CD.EF.GH
AB.CD.XY
Resources not protected by the
profile
AB.CD.EF
AB.CD.EF.GH
AB.CD.XY
ABC.DEF
AB.CD
AB.CDEF
AB.CD.EF.GH
ABC.DEF
AB.CDEF
AB.CDE.FG
ABC.DEF
Profile Name
AB.CD*.**
AB.CD.*.**
Resources protected by the profile
AB.CD
AB.CD.EF
AB.CDEF
AB.CDEF.GH
AB.CD.EF.GH
AB.CD.XY
AB.CD.EF
AB.CD.EF.GH
AB.CD.XY
Resources not protected by the
profile
ABC.DEF
ABC.DEF
AB.CDEF
AB.CDEF.GH
AB.CD
ABC.XY.XY.EF
Source: z/OS V1R4.0 Security ServerRACF
Command Language Reference,(SA22-7687-03)
Note: Although
multiple generic profiles might match a data set name, only the most specific
actually protects the data set. For example, AB.CD*, AB.CD.**, and AB.**. CD all
match the data set AB.CD, but AB.CD** protects the data set.
Figure 4‑2. Generic Data Set Profile Names
Created with Enhanced Generic Naming Active—Asterisk, Double Asterisk, or
Percent Sign in the Middle
Profile Name
ABC.%EF
AB.*.CD
AB.**.CD
Resources protected by the
profile
ABC.DEF
ABC.XEF
AB.CD.CD
AB.CD
AB.X.CD
AB.X.Y.CD
Resources not protected by the
profile
ABC.DEFGHI
ABC.DEF.GHI
ABC.DDEF
AB.CD
AB.CD.EF
AB.CDEF
ABC.DEF
ABC.XY.CD
ABC.XY.XY.CD
AB.CD.EF
AB.CDEF
ABC.X.CD.EF
ABC.DEF
ABX.YCD
Source: z/OS V1R4.0 Security ServerRACF
Command Language Reference,(SA22-7687-03)
Titan users can submit information
through the Web, and Web RACF formats all RACF commands. The commands go to the
mainframe system for processing and the user receives a response indicating
successful completion or an appropriate RACF message.
Users must have a valid Titan userid
and password in order to submit any RACF request. The userid entered must be
authorized to perform any RACF function requested. Generally, this means that
only the owner (creator) of a data set profile can change RACF access to that
data set.
Among its functions, Web RACF
allows users to:
·change the user's RACF password
·permit individual, universal, and group access
to mainframe data sets
·set up generic profiles for data set protection
·change the Universal Access (UACC) for a profile
·change the owner of the profile
·view the RACF profile of a mainframe data set
·create or delete RACF groups
·add or remove users from a RACF group
·change the owner of a RACF group
·display attributes of a RACF group
·control which users can submit, read
(fetch)/purge batch jobs
Web RACF allows security
coordinators to:
·perform RACF functions for users of an account
·set a user’s password
·revoke and resume a user’s RACF access
Typical
Tasks
The following table describes
how to perform some typical tasks using Web RACF.
Figure 4‑3. RACF Typical Tasks
Task
Web RACF
Area
Change the password.
Change
RACF Password
Establish
protection for a data set. (NOTE: protecting
a data set establishes a UACC and gives the user whose RACFid is in the high
level prefix of the data set ALTER authority.)
RACF Profiles –
Actions (Protect a data set)*
Give
other users specific access to a protected data set.
RACF Profiles – Actions (Add user to access list to data
set)*
Change
the access of a specific user.
RACF Profiles –
Actions (Add user to access list to data set)*
Remove
the access given to a user.
RACF Profiles –
Actions (Remove user from access list)*
Change
the UACC of a protected data set.
RACF
Profiles – Actions (Change UACC)*
Create
a user-defined RACF group.
RACF
Groups – Actions (Create a RACF group)
Add users to a user-defined
RACF group.
RACF Groups – Actions (Add
users to a group)
Remove
users from a user-defined RACF group.
RACF
Groups – Actions (Remove users from a group)
Delete
a user-defined RACF group.
RACF
Groups – Actions (Delete a RACF group)
See
the group names in which a RACFid is a member.
RACF
Groups – Display (Groups containing user)
See
which RACFids have been given specific access to a protected data set. (NOTE: The output from this function
will also show the UACC of the data set.)
RACF
Profiles – Display (RACF profile for a data set)
As an
alternative to using Web RACF, you can execute RACF commands directly through
TSO or in a batch job. If you need assistance with issuing RACF commands under
TSO, contact the NIH Help Desk or refer to the RACF documentation available from
the CIT publication service. See Section 5.4.
Entering RACF Commands
A cataloged procedure, BATCHTSO, is available for
entering RACF commands in a batch job. The formats for the RACF commands are
the same in TSO and batch. The TSO convention governing the use of single
quotes around data set names applies (i.e., a data set name enclosed in single
quotes will be processed as entered, but a data set name not enclosed in single
quotes will have the TSO userid added as a prefix automatically before
processing). If the latter method is used, a PROFILE statement must precede the
RACF command.
The following example illustrates the use of
BATCHTSO:
·Use Web RACF (see Section 4.6.4). This is the preferred method.
·Use the Web-based Password Reset facility to
change your RACF password if you are associated with NIH and have an NIH Login user
name and password. Go to:
Allowing
Individuals or Groups to Use a Protected Data set
The PERMIT command grants a specific level of
access to other users of a data set. For example:
PERMIT
dsname ID(xxx) ACCESS(level of access)
Where: “xxx” may be the userid or RACF group. Multiple userids or RACF
groups may be specified in the ID field with separating blanks or commas. Level
of access entries and meanings are described under “Level of Access,” earlier
in this section.
Allowing Universal Access to a Protected Data set
The
ALTDSD command with the UACC operand grants all users a specific level of access for a data set. The format is:
Tape data set security
on Titan is handled by RACF permissions on a data set rather than volume basis.
Data set protection depends on the RACF profiles in place and applies to any
data set, regardless of whether it is on tape or disk.
NOTE: If you wish to use the naming
convention of aaa.iii.dataname, the security coordinator must create RACF
profiles of the form AAA.III.** and must permit the $III userid ALTER access to
that profile. Optionally, the security coordinator can set the owner for the
AAA.III.** RACF profile as $III. This allows the $III user to use RACF commands
to permit other users access to data sets on tape. Unless these RACF
permissions are given, the generic profiles currently in use for disk data sets
will be used and some tape jobs may fail.
When a data set is scratched,
the data set's entry is removed from the Volume Table of Contents (VTOC). The
disk space occupied by the data set is released for reuse, but the data itself
remains on the disk. The operating system does not automatically erase or
"over-write" scratched data sets. The data is possibly vulnerable to
disclosure to unauthorized individuals.
Users who must ensure that sensitive data
cannot possibly be recovered from scratched data sets should take the
additional step of erasing the data (prior to scratch) using the ADSERASE
procedure, described in the Titan Batch
Processing manual. ADSERASE can also be used to erase data from tapes.
The RACF ERASE capability
(for RACF protected data sets) and the ERASE option for any AMS command (for
VSAM data sets) cannot be used at the NIH Data Center because they cause severe
performance problems.
Many types of assistance are
available to users to help them make efficient and effective use of the Titan
system. The NIH Help Desk- provides a single point of contact for phone calls
and Web-based requests for technical assistance. The NIH Help Desk supplies
assistance to users with support from the staff of the NIH Data Center and
other parts of CIT. See Section 1.3.1 for useful phone numbers. See Section 1.1
to learn about other CIT services provided by the individual organizational
components of CIT.
The comprehensive consulting
services offered to customers by CIT include problem resolution and assistance
with Titan services described in this manual. CIT can assist users on
connectivity strategies and services, including interactive login and file
transfer services that are part of NIHnet, and remote access technologies.
Consultants are also available when a system problem occurs that prevents a
user's work from continuing—a situation which requires a quick response for a
solution/circumvention.
Major Sources of Help
·Call the NIH Help Desk. See
Section 5.2.1.
·Submit
a CIT Service Request to report problems, make suggestions, apply for refunds,
and request consulting assistance. Enter your request via the Web at:
The NIH Help Desk offers
consulting and assistance on a variety of software and services. The NIH Help
Desk will try to answer questions on any product used by CIT customers. Titan
software and services, specifically documented in this guide, receive a high
level of consulting. Support comes in the form of responses to CIT Service
Requests, technical documentation, maintenance, advance announcement of all
changes, and full conversion support (if the product is upgraded or
discontinued).
Figure
5‑1 lists software facilities available to Titan
customers for application development.
The
NIH Help Desk is located at 10401 Fernwood Road, Suite 300, Bethesda, Maryland,
20817. Refer to Section 1.4 for the hours of operation. Consulting assistance is
available on all software supported by the NIH Data Center, as well as
questions concerning LANs, networking, and NIHnet (e.g., e-mail, connectivity
with the enterprise systems, and network connectivity strategies).
The NIH Help Desk consultants can
answer most questions, but will refer more complex problems to subject matter
specialists. The expertise and experience of the senior staff members are
available to any registered user who calls the NIH Help Desk.
Regardless of the software you are
using, if you think that an action you are taking during an interactive session
or while running a batch job is causing the system to crash, you must contact
the NIH Help Desk immediately. If you cannot reach the NIH Help Desk, submit a
CIT Service Request online and suspend all action until you are notified. Do
not try to modify the command or job and resubmit it. (See Section 5.2.2 for information on submitting CIT Service Requests.)
Users who plan to acquire or
develop large systems at the NIH Data Center should contact CIT to set up a
meeting to discuss the proposed software in detail. This will help ensure that
the new system will adhere to the job standards and will not conflict with
published restrictions.
5.2.2CIT
Service Request
Users report problems,
request refunds, and communicate suggestions, comments, and needs to CIT
through a Web-based CIT Service Request. The information from these reports
help the staff formulate future policies, plan systems changes, and inform
users of common trouble areas. CIT Service Requests can deal with supported
software, hardware, network connections, or service for enterprise systems
(including Titan). The staff will not be able to respond to problems with
software or hardware (e.g., workstations) not supported directly by CIT.
Submitting a CIT Service Request
To submit a CIT Service
Request,go to the NIH Help Desk Web site at:
2.Enter your name in
the space indicated; select GO.
3.Click on your name
(there may be other users with the same name).
4.Verify your
information; click Continue.
5.A page will now
appear where you can input your request.
6.Notice that you can:
·Select an alternate Point of Contact (POC) for
your request.
·Type your request or copy and paste your error
message. Indicate if the request is related to CIT’s mainframe services. For
especially severe or critical problems, it is important to provide all
available problem-related information with the Service Request.
·Select your workstation platform, if relevant.
·Stipulate how an agent and/or technician should
contact you (email, phone, TTY).
Before submitting a CIT Service Request
describing a problem that severely impacts production (not test or development)
work and cannot wait, it is often useful to discuss the problem with the NIH
Help Desk consultants. See Section 5.2.1.
Whenever possible, CIT staff will try to
provide a temporary solution or bypass for the problem. Permanent fixes
typically take longer since they may require coordination with the software
developer or vendor.
CIT Service Requests can also be submitted
by calling the NIH Help Desk.
Providing Documentation for a CIT Service
Request
For any CIT Service
Request, whether submitted via e-mail or the Web, include a description of the
suggestion, problem, or complaint that clearly, but briefly, explains the area
of concern. The problem description should include all information (for
example, data set names, job numbers, etc.) needed to resolve the problem.
The amount of documentation needed depends
on the severity, complexity, and nature of the problem. For printing problems,
extensive listings may not be required. Often the output header and trailer
sheets and a few pages showing the problem are sufficient.
Tracking
and Updating a Service Request
CIT uses Remedy's
Action Request System (AR) to track Service Requests internally. This system
automatically creates a “ticket” that is associated with a user's problem. When
you submit a CIT Service Request, the system will notify you of the Remedy
“ticket” number for future reference.
You can search for a particular ticket by
selecting Ticket Search from the menu bar of the Help Desk Web page. To view
your ticket history or send an update to your ticket, select Service &
Training History from the menu bar.
Canceling a CIT Service Request
To cancel a CIT Service
Request (e.g., the problem has been solved or no longer requires an answer), do
one of the following:
·Submit another CIT Service Request to cancel the
previous one.
·Telephone the NIH Help Desk immediately (see
Section 5.2.1).
Requesting a Refund
To obtain a refund, a
user must submit a CIT Service Request, either by e-mail or through the Web.
See Section 3.2.2 for more information about refunds.
The NIH Help Desk provides advice and assistance to users with a
wide variety of telecommunications, networking, and connectivity problems.
Users who suspect that communications hardware maintained by CIT may be causing
their problems should contact the NIH Help Desk. CIT provides help with:
There are additional forms of
assistance available for relational database technologies (DB2, Oracle, and SQL
Server). Refer to the Computer Services telephone directory in Section 1.3.1.
For more information on relational database
systems supported on Titan, go to:
Users who are considering, or
are in the process of acquiring or developing, a software package should
contact CIT to arrange a meeting to discuss implementation. The purpose of this
meeting is twofold:
·To ensure that the proposed software will comply
with the NIH Data Center standards and will not have a detrimental effect on
other users. This compliance is mandatory in the open-shop environment at NIH.
·To help the NIH Data Center staff project the
resource requirements of the user community as a whole (e.g., additional
resources such as online disks, etc.).
If a large system is designed without prior
consultation with the appropriate CIT personnel, it may require extensive modification
before it is implemented, or it may not be able to run at all. Avoid the
necessity of “after the fact” changes―this can save substantial costs,
staff-hours, etc. Prior consultation often results in a more efficient,
bug-free, and more easily maintained system.
If possible, representatives of the vendor
should be present together with the user, so that they can gain an insight into
the NIH environment and, along with it, a more accurate estimate of the work it
will take to make the system compatible with NIH's standards. The staff will
help the vendor plan the changes and installation of the system. Such a meeting,
held early in negotiations with the vendor, is an important step in insuring a
smooth, economical, and hopefully rapid installation of the vendor's system.
Whenever possible, avoid the use of
device-dependent data or programs. Software packages using these features could
become unusable later if the NIH Data Center upgrades its hardware.
Some software vendors charge for the use of
their software based on the number of processor complexes on which the package
may run. They may require the purchaser to supply processor complex serial
numbers that are then checked by the software. The NIH Data Center's
configuration is relatively dynamic. Acquisition of a new processor complex,
and particularly changes or additions to processor complex serial numbers
cannot be announced in advance. Any contract to acquire software should include
some allowance for the possibility of additional or replacement processor
complexes.
Transferring disk data to the NIH
Data Center from other data centers via tape should be done using individual
data sets. Attempting to restore data from a backup tape will often be
unsuccessful because of hardware and software incompatibilities. See Section 6.4.6 for details.
For a list of the operating system software that
cannot be used at this installation, see Section 7.1.1.2.
5.2.6Additional Web-based Customer Support
In addition to allowing users to submit
online service requests, the NIH Help Desk Web site offers several online
services that users can access any time via:
·CIT Knowledge Base (KB) - the
database of technical support information and references to outside resources
created, maintained, and used by NIH Help Desk consultants. It includes
information on software products, instructions for changing passwords, e-mail
client configuration, Listserv lists, and many other topics. You can access the
KB from the NIH Help Desk Web site or by going to:
CIT can also provide NIH organizations with their own
closed knowledge domain. For further information, contact the NIH Help Desk.
·Frequently Asked Questions
(FAQs) – The NIH Help Desk maintains a repository of customer Frequently Asked
Questions about a variety of topics, including Titan, CIT accounts, changing
passwords, e-mail, and remote access, among many others.
·Hot
News – Hot News items represent IT service items of impact to the NIH
community. The current list of Hot News items is available on the main NIH Help
Desk Web site.
·Virus Alerts
·CIT Maintenance Calendar –
When maintenance on NIH’s IT infrastructure is scheduled, the dates and times
of the planned outages are listed here.
5.3TRAINING
The CIT Computer Training
Program offers a variety of classroom courses to assist users in making
effective use of computers at NIH. Many seminars address the uses of computers
in science. A variety of self-study courses are also available. Descriptions of
all classroom courses, seminars, and self-study courses provided by the CIT
Computer Training Program are available through the Web. Course information is
kept up-to-date; when a course fills early and a new session is scheduled, it
will be shown. There is no charge for courses in the CIT program.
The CIT Computer Training Program
staff can answer any questions about these courses, give assistance in selecting
the best course to fill specific needs, and even take your registration
information over the phone. See Section 1.3.1 for the phone number.
As a convenience to NIH personnel,
the CIT Computer Training Program Web site has links to other computer training
programs available at NIH and through HHS.
The CIT Computer Training
Program fully accommodates students with disabilities. Classes are located in
wheelchair-accessible buildings. People with disabilities are welcome to attend
any course or seminar offered by the CIT Computer Training Program for which
they have the appropriate professional background. Prospective students should
inform the training staff if special assistance would be needed. For more
information, see Section 1.7.
There are three terms each
year: fall, spring, and summer. Subjects include: personal computers, networks,
Internet resources including Web facilities, disaster recovery, the Titan
mainframe system, computer security, database topics, Unix, grants, statistical
packages, nVision information, and scientific seminars.
Whenever possible, special
seminars will be scheduled to meet the needs of organizational groups. For
information on scheduling a special seminar for your group, contact the staff
of the CIT Computer Training Program through the NIH Help Desk. See Section 5.2.1.
Location
CIT classes generally meet in the on-campus
classrooms, located in building 12A, or at the Fernwood Road location. Be sure
to check the schedule for the training location.
A variety of online training courses
are offered for students who want to study independently. Details can be found
at the CIT Computer Training Program Web site.
CIT provides manuals for CIT
supported systems and software through the Web. Anyone making active use of the
NIH Data Center is responsible for obtaining and consulting the publications
related to the services they use.
To order hard copy publications, view
publications online, print manuals on the high-speed central printers, or print
at your desktop printer, visit:
Each CIT or vendor document on the
CIT publication pages is available through one or more of options. To get
started, select a category from the list on the left side of the CIT
Publications page. If you’re not sure of the category for a publication, use
the Keyword Search feature on the right side of the Web page. For example, to
find an ISPF publication, type ISPF in the search window, and a list of all
ISPF manuals will be displayed. After the title appears, select from one of the
available formats.
·online viewing via the View/Print On Demand
Service via the Web in PDF
format via Acrobat reader (with the option of printing at your local
desktop printer). This is a free service, available to all users.
·central printing via the View/Print On Demand
Service. Many vendor manuals and CIT-written manuals can be printed
in-house―double-sided, three-hole punched, on high-speed laser printers. To
order copies of printed documentation, provide your Titan userid. Users must
verify (and correct, if necessary) their customer information before placing an
order online for a printed copy of documentation.
If you click the question mark next to the name of the manual, you will see the
date, number of pages, and estimated printing charge. The charge is waived for
the first printing of a new version of a manual. Users will incur charges when
they request the printing of more than one copy of a manual at the central
printers. There is a choice of delivery options:
·to your output box
·by mail
·online viewing via a Web browser for documents
in html format. This is a free service, available to all users.
·hardcopy (traditional method). Some manuals (specific vendor
manuals and older CIT manuals) are only available through the traditional
ordering system. You must supply a logon ID (e.g., the 10-digit badge number of
your NIH ID, your Titan userid, or your Helix ID). If you order documentation
by this method, CIT will mail you the manual.
There may be a charge for ordering statistical software.
Contact the NIH Help Desk for
assistance with ordering or printing documentation. See Section 5.2.1.
Ordering Limits
Almost all publications are
given to users without charge. The NIH Data Center absorbs the cost in its
overhead (which is in turn paid for from computer charges). To be cost
effective, some limits must be put on the documentation service. Each user
should order only the publications currently needed; if others are needed later,
they can be ordered at any time. An order for an unreasonable number of
publications (e.g., one of every publication stocked) cannot be filled and will
be delayed until the user can be contacted to determine which publications are
really necessary. Each request for a special order of documentation is reviewed
as it is received. Publications not listed in the online publications system
will be given to a user only if the document describes facilities offered at
the NIH Data Center to its user community.
User groups with many individuals
at a single location should consider establishing a library of publications to
be shared by the group. Each user may still obtain a personal copy of the
publications used most frequently.
People who are not registered users
may receive introductory publications. Requests from non-users for any other CIT
publications should be directed in writing to the Director, Division of
Computer System Services.
Stay Up-to-Date
You may subscribe to a publications
interest list and receive e-mail notification whenever a new manual is
available. Go to the NIH Listserv page at:
Browse the list of Listserv lists and select the CIT-DOC-RENEW list.
Note: updates for CIT publications
are distributed only upon request.
When a major publication is introduced or updated, an article
often appears in Titan News, the online
mail facility described in Section 1. You
can also check the Publications page that appears towards the back of Interface for a list of new and updated
CIT publications.
IBM BookManager, an
interactive facility on Titan, allows users to view IBM technical documentation
online.
Access
To use BookManager, access the
Titan system and connect to NIHTSO. Log on with your userid and password. After
the informational messages appear, hit Return. From the CIT/Titan Primary
Option Menu, select C for Additional Products, and then select B for Books
(BookManager).
For more information on
BookManager, see Section 7.11.
Two-way
communication between users and the NIH Data Center staff is valuable. Input
from users is a critical element in determining data center goals, policy, and
allocation of staff time. It greatly affects the quality and timeliness of the
end products provided to the user community. The NIH Help Desk provides
information on setting up accounts, training, software, e-mail and a full range
of technical issues. Suggestions on how to improve our service are always
welcome. The CIT Service Request, described in Section 5.2.2, is an important communication tool for users who
need help. Publications, such as Interface,
are effective vehicles for CIT-user communication. The communication tools
described in this section complement the general links described above.
An important means of communicating timely information with
mainframe users is Titan News. It is distributed through an e-mail list,
CIT-TITAN-NEWS@LIST.NIH.GOV. This service allows CIT to send out important
information, such as updates on outages, special events, equipment and software
upgrades, technical information and other issues, at short notice.
For
information about Listserv, or to join or leave a list, go to:
Occasionally, in a data center
environment, changes to a published procedure must be quickly implemented.
Titan has several methods for timely communications with its users:
Titan
Hot News
Titan Hot News provides TSO
and batch users with information concerning changes in operating schedules,
software enhancements, and published procedures.
To access Hot News from ISPF, enter
the command:
TSO HOTNEWS
CIT Hot News
CIT announces important messages concerning the status
of its systems through the Hot News feature of the NIH Help Desk Web page at:
A specific system, such as
TSO, may send messages to all users of that system. Since this message facility
is a feature of the individual system, only information of interest to the
users of a particular system is broadcast in this manner.
Batch
Listing Messages
Titan messages are displayed on Titan batch listings.
There are several
CIT-sponsored groups to help users exchange information in specific areas of
interest. Contact the NIH Help Desk for further information. These groups
include the following:
·Biomedical Research Mac Users Group (BRMUG) -
Macintosh user support
·Molecular Modeling Interest Group (MMIG)- seminars on various molecular modeling
topics to foster communication between NIH scientists concerning the methods
and applications of molecular modeling
·Knowledge Management Interest
Group (KMIG)
·The Account Sponsor Interest
Group (ASIG) – a Listserv forum for discussion of issues important to sponsors,
deregistration officials, and Titan account officials (e.g., billing
coordinators, security coordinators). For more information, see Section 2.1.
·Jobs submitted locally or interactively without a “ROUTE” or “DEST”
statement are printed at the Bethesda campus of the NIH Data Center.
·Computer
output is either placed in assigned combination lock boxes or in “special
handling” areas. Only users who have been given the combination by their
respective account sponsors have access to the lock boxes.
·For output
designated for Parklawn delivery points (“P” preceding the box number), users
must make their own delivery arrangements. See Section 5.6.1 for information on output boxes.
CIT provides locked output boxes at the
Bethesda NIH campus―located next to the Output Distribution Services
counter in building 12A. To access an output box you must enter the BAC (box
access code) at a keypad located by the bank of output boxes.
All Titan users have a default box number
value assigned; however they can set or change their output box numbers.
Box Numbers
To see your output box number, go to
Customer Locator at:
At the display of your assigned box number,
you may see one of the following values:
nnnn
This is the desired box number at the NIH
main campus.
Pnnn
This is the desired Parklawn box number.
NONE
An output box is not needed. This option
is designed for users who do not use
the central printers on Titan, such as people who only use VPS or Helix. Any
output that is printed at the central printers is thrown away, but incurs a
printing charge.
NOBX
No box number has been set. If the account
sponsor does not specify an output box number or NONE for a user at
registration, this is the default. If you try to run a job on Titan with a
box number of NOBX, the job will fail with a JCL error.
For
Jobs Run at a Remote Site
You can run a job at a remote site with a
box number of NOBX and print the output at a VPS printer. If you send the
output to a central printer on Titan, the output will print and be thrown
away. You will be charged for printing.
If you do not specify a box number in your
JCL, your assigned box number is used. If, however, you specify a box number in
your JCL (by using a former South System-style job card, a /*BOX statement, or
a /*JOBPARM ROOM=bbbb statement), it overrides the assigned box number.
If a box number is not provided in the
JCL and the default output box setting is NOBX, the job will be rejected.
Any output that prints on a central printer without a valid box number will be
disposed of, and the user will be charged for printing.
How to Change Your Box Number
To change your output box number, select Set
Box Number on the appropriate Customer Locator page. (See Section 1.3.2.2) Your account sponsor can tell you the box numbers
that are valid for your account and the entry code for the box you select. If
you set a new box number, be sure to click the SET button on the Box Number
Update page after you enter the new value.
If you have any questions on displaying or
setting your assigned box number, contact the NIH Help Desk. See Section 5.2.1.
If
output is too large to fit in a user's locked output box, the box will contain a
special key with an attached box number for a nearby oversized locked box. The
output can then be picked up at the oversized locked box. All large-volume
output, including output marked “Private,” will therefore be secured.
Boxes
for Mailed Output
Users at a remote location should obtain a
mailing box number (with an “M” prefix) so that output produced at the central
facility can be mailed to them. Users who choose this service must accept full
responsibility for delays, damage, or loss incurred in the mails and must limit
the volume of output to be mailed to that which will fit in one 12 by 16 inch U.S.
mail envelope (NIH Supply Number 7-7106). Box numbers are limited to 4
characters, including the M prefix.
Occasionally output is
misdirected because of a user error or mishandling by the NIH Data Center. This
can cause great frustration for the user who should have received it. If you
locate misdirected output, please inform Output Distribution Services, located
in building 12A of the NIH Bethesda campus, as soon as possible. See Section 1.3.1 for the telephone number.
6NIH Connectivity and Network Services
This section provides an overview of CIT’s
network connectivity services and the software products supported by CIT to
access Titan’s facilities.
The Center for Information Technology provides network
connectivity to Titan services. Network connections and reliability are
monitored 24 x 7. Contact the NIH Help Desk for all connectivity assistance,
including software recommendations.
Users can access Titan through TCP/IP
(Transmission Control Protocol/Internet Protocol) connections from their
desktop computers. TCP/IP supports high-speed file transfer, remote job
submission, and TN3270 connections. For additional information, refer to the
manual Network Access to Titan, available from the CIT publication
service (see Section 5.4).
Network connectivity is an essential tool for
the biomedical, clinical, and administrative communities at NIH, other
government agencies, and organizations worldwide. NIHnet is the NIH backbone
network that interconnects the Institutes and Centers (ICs), local area
networks (LANs), and the NIH Data Center with the Internet, Internet2, HHS
operating divisions (via HHSnet), and other government agencies. It controls
access between the ICs and between NIH and the outside world. Information
carried by NIHnet includes biomedical, clinical, and administrative data.
NIHnet
is a wide area network (WAN) comprising the physical infrastructure of cable,
optical fiber, routers and switches; network management control systems,
servers, and workstations. This infrastructure supports the NIHnet operation;
wireless access points; and security control systems, which include firewalls,
intrusion detection systems (IDS), content filtering systems, and virus
detectors.
The
topology of the NIHnet backbone uses redundant connections and equipment
locations to provide more resilience and resistance to outage. To ensure
sufficient capacity for data requirements, the NIHnet has several high-speed
primary connections to the Internet. A portion of NIHnet resides in the machine
room of building 12.
CIT also supports remote access technologies (e.g., dialup and
VPN) for users whose workstations are not directly connected to the NIHnet. See
Section 6.1.3.
A NIHnet connection provides reliable,
high-speed access to a wide variety of network services. The NIH Data Center
supports network services that allow Titan users, with a NIHnet connection from
their desktop computers, to:
The
variety of NIHnet-based services reflects the heterogeneous nature of the NIH
environment and of the Internet as well. Despite their variety, however, these
network services have one thing in common: NIHnet is the conduit by which they
are delivered to users at NIH.
6.1.2Useful Web Services
Many CIT and NIH Data Center facilities are
available through a Web-based interface. CIT Web facilities allow users to
download software, change passwords, read documentation (including Interface),
order manuals, look up an e-mail address, register for a training course,
submit a CIT Service Request, use RACF, change account information (for account
sponsors), and learn about-or take advantage of many other CIT services.
SILK (Secure Internet-LinKed) Web
technologies, supported by the NIH Data Center, allow users to access data
stored on Titan and use many CIT enterprise applications. For information on
SILK, see Section 7.6.1 or visit:
CIT supports remote access technologies to
allow users to access the NIHnet from home, another office, or while traveling.
Requests for remote access authorization must be made by the account sponsor
through Web Sponsor. See Section 2.3 for information on Web Sponsor.
6.1.3.1Parachute for Dialup Access
Parachute/Modem provides
dial-up access to NIH and Institute computing resources while working with a
home or mobile computer equipped with a modem. This method utilizes your
current phone line though it does not allow voice calls to be made over the
same line while connected to Parachute. The connection speed is 56Kbps.
To connect to Titan through Parachute access to
the NIHnet, you will also need a 3270 (full-screen) terminal emulation software
package, such as QWS3270 PLUS installed on your workstation. For information on
QWS3270 PLUS, which is supported by CIT, see Section 6.3.1.
How to
Apply for Parachute
To apply for Parachute
service a customer must:
·have a valid Titan user id. If you do not have a
Titan userid, one will be created specifically for remote access use when the
account sponsor requests Parachute service through Web Sponsor.
·have a valid business reason for needing this
service
·be registered in the NED (NIH Enterprise
Directory). See Section 1.3.2.1 for information on the NED. Under some circumstances,
CIT can register a person outside of NIH to the NED (as a guest) in order to
register for a remote access account.
·obtain an Active Directory Account (NIH Login
Username); the exact method varies by IC. Contact the NIH Help Desk (see
Section 5.2.1) for assistance.
Since this service permits
a desktop computer to effectively “be part of NIHnet,” security is a vital
concern.
·ask the account sponsor within your organization
to request Parachute service for you. The sponsor makes the request through Web
Sponsor (see Section 2.3).
Access
See below for the Parachute access telephone
numbers. Please use one of the first pair of numbers (depending on whether you
are dialing locally or long distance). If that number is busy, use one of the
second pair of numbers.
Figure 6‑1NIHnet Access through Parachute
Service
NIHnet Access
Assistance
NIHnet access through Parachute
301-402-6830
800-827-0124*
301-496-4357
(301-496-HELP)
866-319-4357 (toll free)
301-496-8294 (TTY)
301- 951-6874
866-753-3457*
All telephone numbers are accessible through FTS.
*These 800/866 numbers should be used only by persons who do not have
access to FTS2001.
For More Information
For more information about
Parachute and other remote access technologies, go to:
VPN (Virtual Private
Network) allows NIH employees to access the NIH network and computing resources
over a third-party Internet Service Provider (ISP) such as that from Verizon
DSL, AOL, or Comcast Cable. You will need to contact your third-party ISP to
verify that the ISP allows VPN over their network. Connection Speed: Not
applicable as this service uses your current Internet connection so it is
dependent on that connection's speed.
How to Apply for VPN
To apply for VPN service a
customer must:
·have a valid Titan userid. If you do not have a
Titan userid, one will be created specifically for remote access use when the
account sponsor requests VPN service through Web Sponsor.
·have a valid business reason for needing this
service
·be registered in the NED (NIH Enterprise
Directory). See Section 1.3.2.1 for information on the NED. Under some circumstances,
CIT can register a person outside of NIH to the NED (as a guest) in order to
register for a remote access account.
·obtain an Active Directory Account (NIH Login
Username); the exact method varies by IC. Contact the NIH Help Desk (see
Section 5.2.1) for assistance.
In TCP/IP-based networking, the name server
is the networked computer that translates Internet names, such as
tn3270.titan.nih.gov, into the Internet Protocol Address (Internet number or IP
number) necessary to make the connection. All connections to CIT TCP/IP-based
services should be done through the Internet host names (see Section 6.2), since the numerical IP addresses are subject to
change.
The
domain name servers at NIH handle the name-to-address conversion for TCP/IP
connections. For example, if a user on the network wants to open a file
transfer (FTP) session using FTP to Titan, the person would FTP to
FTP.TITAN.NIH.GOV. The name server then translates that address into the
Internet number for the actual FTP session.
NIH
users can register a host name, set up an alias, perform DNS lookups, assign
additional IP addresses, and perform other basic DNS changes themselves through
the Web. Go to:
Your
desktop support group will handle the network configuration for your desktop
workstation. Contact the NIH Help Desk if you need assistance (see Section 5.2.1).
The
Online Services Directory below provides the Internet host names for network
connections and the telephone numbers for remote dialup access through
Parachute.
The telnet facilities of TCP/IP allow users
to access Internet-connected computer sites interactively. In order to access
Titan’s interactive services (e.g., TSO and DB2) from a NIHnet-connected
workstation, users must install a TN3270 full-screen communications software
package on the workstation itself. All system and user-written applications
that run under TSO can be reached with TN3270 access. For interactive access,
connect to the Titan host name.
TN3270.TITAN.NIH.GOV
Application
Selection Menu
After you make the TN3270 connection to Titan, the Application
Selection menu appears. Use the Application Selection menu to access Titan's
interactive systems. Select NIHTSO to access most Titan services. See Section 7.2 for information about NIHTSO.
Users
with Internet connections running TCP/IP software on their workstations can
also access other computers that are connected to the Internet (such as the NIH
Helix Systems) provided, of course, that the user has the authority to use the
other system.
Windows
2000 and Windows XP include TCP/IP driver software. For information on
additional connectivity software for Windows, see Section 6.3.1. NIH Macintosh users should see Section 6.3.2.
CIT
provides several software products that enable Windows-based desktop computers
to access the Titan system.
QWS3270
PLUS for TN3270 Connections
The NIH Data Center has a site license for
QWS3270 PLUS, the commercial version of QWS3270. QWS3270 PLUS is a full-screen
application that allows a network-attached, desktop computer running Windows to
connect to an IBM mainframe in 3270 mode (TN3270). This software is designed to
take full advantage of the “point and click” capabilities of Windows XP.
QWS3270
PLUS is fully compatible with the Titan system. This 3270 client software for
network connections is available without charge. The software includes
instructions on how to set up additional 3270 sessions.
Titan
users can download QWS3270 PLUS from the Web by pointing their browsers to:
Contact
the NIH Help Desk if you need assistance. See Section 5.2.1.
QWS3270
Secure for TN3270 Connections
QWS3270 Secure is a 3270 (full-screen)
emulation application that allows a network-attached, desktop computer running
Windows to connect to SSL-enabled IBM mainframes over a secure TCP/IP
connection. This software will run on Windows XP and is available without
charge. QWS3270 Secure is fully compatible with Titan. Users can download
QWS3270 Secure from the Web by going to:
Because of the special secure port
considerations, be sure to print and read the installation and configuration
instructions before you install this product. QWS3270 Secure instructions also
contain separate configuration directions for IMS/ADB users to allow them to
connect directly to IMS. See Section 7.4.2 for more information. Contact the NIH Help Desk if
you need assistance.
Each
individual Macintosh on the network must have a unique IP (Internet) address (number)
to allow network access, regardless of the protocols employed. A user can
generally acquire the unique IP number by selecting Network Preferences in
their System Preferences in OS X. An invalid or non-unique IP number will cause
problems for the user and may cause problems for other workstations on the
network.
Contact the NIH Help
Desk for assistance with any Macintosh connectivity issues.
TN3270 or
TN3270X allows a Macintosh user, on a LAN connected to NIHnet, to access
full-screen services, such as TSO, DB2, and ISPF. This software is available
from the vendor (Brown University) at:
This section describes various methods of
transferring data between desktop computers and the mainframe and between NIH
and other data centers:
·FTP (see Section 6.4.1)
·Web-based secure file transfer (see Section 6.4.2)
·Connect:Direct (see Section 6.4.3)
·SSH (see Section 6.4.4)
·IND$FILE for 3270 File Transfer (see Section 6.4.5)
·exchanging tapes (see Section 6.4.6)
·SENDFILE/RCVFILE – legacy batch programs for
file exchange using NJE (see Section 6.6); should only be used for existing applications
If
a batch job is required for the data transfer (e.g., Connect:Direct and SSH),
also refer to Titan Batch Processing.
This manual is available from the CIT publication service. See Section 5.4.
6.4.1File
Transfer Using FTP
A user can transfer files between a
workstation connected to the Internet, or on a NIHnet-connected LAN running
TCP/IP software, and the Titan system. The FTP facilities of TCP/IP provide
high-speed file transfer between a user's workstation and the other Internet
site. For FTP access, connect to the host name of the FTP server on Titan:
FTP.TITAN.NIH.GOV
Refer
to Figure
6‑2 for information on establishing the network
connection to Titan.
Users
with a TCP/IP connection to the Internet can transfer files in either direction
(i.e., to the mainframe, or from the mainframe to their workstations). Unix workstations can also transfer files to
and from Titan using appropriate FTP software packages.
Submitting
Batch Jobs Using FTP
To transmit a batch job to Titan, use the FTP
command SITE FILETYPE=JES. For additional information, refer to the manual Network
Access to Titan, available from the CIT publication service. See Section 5.4.
SSL
FTP for Encrypted Data Transfer
SSL (Secure Socket Layer) FTP ensures that
all data and passwords transmitted over the network are encrypted. SSL is a
protocol defining a means of encrypting data across Internet connections. SSL
uses Public Key Technology to allow a client and server to agree on an
encryption method and to verify the server to the client.
For Windows SSL FTP
See
Section 6.4.1.1 for information on using WS_FTP Pro with SSL.
Mainframe-to-Mainframe SSL FTP
SSL FTP can be used to transfer data between
Titan and another IBM mainframe system. In this case, Titan could be either the
SSL FTP server or the SSL FTP client. Since configuration and certificate process
involved is fairly complex, contact the NIH Help Desk if you need to use this
facility. See Section 5.2.1.
For
More Information
Contact
the NIH Help Desk for more information on FTP and recommendations on client
products for TCP/IP-based file transfer.
CIT provides WS_FTP Pro to its users. WS_FTP
Pro, a software package based on the file transfer protocol (FTP), provides
fast transfer of files or collections of files between Internet-connected
computers using Windows XP.
Secure File Transfer
You can configure WS_FTP Pro to request a
Secure Sockets Layer (SSL) connection to Titan, thereby providing encryption
over the network. Titan users can download WS_FTP Pro software from the Web. Go
to:
and
select NIH Connectivity Tools. There you will find installation and
configuration instructions. For security reasons, we recommend that you don't
allow WS_FTP Pro to encrypt and store your password in its .ini file.
For
More Information
For more information on using WS_FTP Pro for transferring files
with Titan, refer to the manual Network
Access to Titan (see Section 5.4), use the online help provided by the software, or
contact the NIH Help Desk.
Macintosh
OS X (version10.2 or later) can take advantage of the built-in command line
Terminal application for FTP transfers to Titan. From the Macintosh
Applications folder, open the Utilities folder, and then open the Terminal
application.
In
addition, there are many shareware FTP programs for Mac OS X that will allow
you to transfer files between the Titan system and your Macintosh (e.g.,
Fetch). Fetch is a full-featured FTP client for the Macintosh. This software is
available from the vendor (Fetch Softworks) at:
Titan offers a Web-based secure file transfer facility that takes
advantage of SSL. The only software required on your desktop computer is a Web
browser. Go to:
Click
on Utilities (under Mainframe) and follow the link to Secure File Transfer. You
must provide a valid Titan userid and password. You have the option to upload a
file from your desktop computer to the mainframe, or download a file from Titan
to your local system.
For
more information about Web-based secure file transfer, refer to the online help
or the manual Network Access to Titan,
available from the CIT publication service. See Section 5.4.1.
Connect:Direct, a product that provides
host-to-host file transfer, is required by the Department of the Treasury for
online financial transactions with their systems. The function it provides is
similar to that of the SENDFILE and RCVFILE programs (described in the manual Titan Batch Processing) but it is
easier to use. Connect:Direct monitors the progress of the file transfer.
Connect:Direct
requires coordination with another site as well as modifications to certain
Connect:Direct configuration files. Connect:Direct must be installed at the
remote site as well as at NIH, and requires either a VTAM or TCP/IP connection
between the two sites. Connect:Direct is controlled by a process that is
similar to a JCL procedure. Once the process is written, the user needs only to
supply the values for various parameters. The two parameters used most are the
source data set name and the target data set name.
Registration
for Connect:Direct
To register to use Connect:Direct,
submit a CIT Service Request that includes the following information:
·the destination of the data to be transmitted
·the nature of the data to be transmitted
·the amount and frequency of the transmitted data
Each project must have a Data
Transmission Administrator (DTA) who is responsible for setting up and
maintaining the jobs and Connect:Direct processes needed to transmit the data.
All correspondence with CIT regarding a registered Connect:Direct project should
specify the name of the DTA.
If
users on other systems will be transferring files to Titan via Connect:Direct,
the DTA must obtain a restrictive Titan userid for each such user. This userid
will have the following special characteristics:
·Logon to NIH systems will not be permitted.
·The associated password will not expire.
Users from other systems must add
the following Connect:Direct parameter to the appropriate Connect:Direct
control statements:
SNODEID=(userid,password)
The DTA must arrange to have an
appropriate RACF profile set up for this restricted userid. The DTA should
contact the security coordinator for the account.
Connect:Direct
Secure+
The Connect:Direct Secure+ option provides strong mutual
authentication, data encryption, and data integrity checking for Internet
transactions. It uses Secure Socket Layer (SSL) technology to encrypt data as
it passes between Connect:Direct nodes.
For
More Information
For
additional information, refer to Titan
Batch Processing.
6.4.4SSH
(Secure Shell)
Titan provides the ability to directly
transfer data sets and automatically translate between ASCII and EBCDIC via the
SSH (secure shell) protocol. The SSH protocol is widely used on Unix systems to
carry out secure (encrypted) file transfers. SSH software is also available for
Windows and Macintosh machines.
SSH is available on
Titan as part of Titan’s Unix System Services (USS). Refer to Section 7.1.2 for information on USS.
Because a userid
must be specifically authorized to use USS, users who need this facility should
contact the NIH Help Desk. A userid containing a $ cannot be authorized to use
USS.
SSH
Transfers Initiated on Titan
SSH
transfers are carried out in batch jobs. For additional information, refer to
the Titan Batch Processing manual
(under “Transfer Utilities”). See Section 5.4 for information on CIT publications.
SSH Transfers
from a Remote Host
SSH file transfers
can also be initiated from a remote host by a user who does not generally
access the Titan system but needs to use Titan data sets.
For more information
on SSH file transfers from a remote host, contact the NIH Help Desk and ask to
speak with an SSH consultant. For a technical reference for SSH transfers from
a remote host, go to:
However, we suggest
that you contact an SSH consultant before using this site.
6.4.5IND$FILE for 3270 File Transfer
Many PC 3270 emulation
packages support file transfer between the host and the desktop computer if an
IBM program named IND$FILE is installed on the host. IND$FILE provides the
mainframe side of a file transfer capability from 3270-type terminals (or
workstations emulating them). IND$FILE has been successfully tested with such
packages as QWS3270 PLUS, the IBM PC 3270
Emulation Program, EXTRA by Attachmate, and IRMAremote for Hayes AutoSync by
DCA. For information on QWS3270 PLUS, see Section 6.3.1.
The use of IND$FILE for 3270 file transfer
requires specific software on the desktop computer. Because the use of IND$FILE
in most 3270 emulation packages is transparent to the user, it is not necessary
to know how to use it, only that it is available. Perform the file transfer
from the TSO ready prompt or from the command option of the CIT/Titan Primary
Option Panel.
Tape is the preferred
medium for transporting large data files from one installation to another
because RAMAC (logical 3390) disks cannot be transferred. Whether exporting or
importing data, be sure that the receiving installation has the type of drive
capable of processing the tape, especially cartridge tapes.
Tapes in the Virtual Storage Manager (VSM)
may not be removed from the data center. See Section 10.2 and Section 10.2.5.
The VPS printing service supports mainframe-to-network printing from the
mainframe to printers accessible via NIHnet or the Internet. Printed output from Titan can be produced on
printers attached to a PC, Mac, or local area network (LAN) connected to NIHnet
and running an LPD server. AppleTalk printers are supported in conjunction with
the PrintShare services provided by CIT (see below).
VPS converts mainframe print output into a TCP/IP
print request conforming to the Berkeley Line Print Daemon (LPR/LPD) standard.
This LPR print request is then sent from Titan to the appropriate networked LPD
server. Many users can share a printer, or one printer can be used exclusively
by a single user.
The LPD server must be configured locally and
registered with CIT prior to being used by VPS. Users are responsible for
setting up the local LPD server. An IBM PC-compatible environment requires Windows 2000/XP. Almost any Unix LPD server
can be used.
CIT will assist administrators in modifying
configurations for VPS printing from Titan. Firewalls must be properly
configured to permit VPS to deliver print requests from the Titan system to LAN
printers. (They must allow traffic through from the IP address 128.231.64.34 to
port 515.)
Inactive
Print Queues
Local printers (print queues) that have not been
used for 12 months will be flagged for removal from the table of queue names and
for reissue to another user. Contact the NIH Help Desk (see Section 5.2.1), if there are
any questions concerning this policy.
Additional
Information
For additional information and to register your
printer for VPS, go to:
PrintShare,
a NIHnet service developed and supported by CIT, allows networked PC, Mac,
Unix, and mainframe users to print to the nearest networked AppleTalk printer.
PrintShare can be used with VPS to send mainframe print jobs directly to a
networked AppleTalk printer. For further information, or to register an
AppleTalk printer for PrintShare, call the NIH Help Desk. See Section 5.2.1.
Network Job Entry (NJE) is a communications
protocol that allows the transfer of commands, messages, programs, files, and
jobs among different computing systems in a network. The NIH Data Center, in
cooperation with other data processing centers, provides a capability whereby a
batch job can execute at one data center and the output can be printed at
another through NJE. This facility is easy to use and does not require
significant JCL changes to implement. These jobs require a /*XMIT statement as
part of the job control language. For more information, refer to the manual Titan Batch Processing.
Pre-registration
for Printing Non-NIH NJE Jobs
Users who execute jobs outside of NIH and
then transmit them to Titan for printing must pre-register with the NIH Help
Desk (see Section 5.2.1). This information will allow CIT to charge the
appropriate account for printing and provide contact information in case of
problems.
Contact
the NIH Help Desk and provide the following information:
·the originating node name (i.e., where the job
will be coming from)
A wide range of major systems
and development facilities are available on Titan for its users. These include
interactive systems, database systems, client/server products, Web facilities,
and programming languages. See Figure
5‑1 for a list of supported software facilities.
An
operating system is a library of programs that controls resource allocation and
program execution. These programs can be tailored to meet the individual
requirements of a computer installation. The NIH Data Center offers application
hosting services on the mainframe (Titan), Unix (EOS), and Windows computing
platforms.
The systems software serving
the Titan facility is composed of the IBM z/OS operating system with job
control language (JCL) and the Job Entry Subsystem Version 2 (JES2) as the user
interface. For more information on job control language, refer to the Titan
Batch Processing manual. See Section 5.4 for information on ordering documentation.
z/OS supports the latest 64-bit
IBM mainframe—or zSeries—processors as well as older legacy processors. See
Section 11.1 for information on the current Titan configuration. The
operating system vastly expands the address space that can be available to each
task and uses the computer's memory more efficiently than non-virtual systems.
This is possible since only the active portions of programs are kept in real
memory. JES2 acts as the batch job scheduler and controller for the operating
system. z/OS allows the creation of multiple, data-only address spaces (called “data
spaces”) of up to 2 billion bytes of virtual storage. z/OS substantially
enhances the reliability, availability, and serviceability characteristics of
the operating system.
This complex operating system presents a unified
system interface to the user. Shared files and work queues make it possible to
balance the workloads of the various subsystems. High availability is realized
through high component reliability and design features that help provide fault
avoidance and tolerance as well as permitting concurrent maintenance and
repair.
The operating system is a standardized
environment that offers users flexibility in the establishment and utilization
of TSO sessions. Language environment (LE) is an architectural interface
designed to meet IEEE's portable operating system interface (POSIX) standards.
By meeting these POSIX standards for code and user interfaces, LE-conforming
programs can cross operating systems, platforms, and environments. The LE
interface provides application programs with a common run-time service and
run-time environment—that is, a set of resources and modules that support the
execution of an application program. LE establishes a common run-time
environment for all participating high-level languages (HLL).
The cross-system enqueue
software in use at the NIH Data Center is MIM (Multi-Image Manager) from
Computer Associates. It provides automatic data set integrity protection in a
multi-system environment, preventing accidental destruction of data from jobs
or interactive sessions modifying any data set with the same name at the same
time.
ThruPut
Manager interfaces with MIM to determine which data sets are needed and the
type of control (shared or exclusive) required for each data set. If a needed
data set is not available, the jobs are requeued and placed in a special TM
HOLD for jobs experiencing data set contention. ThruPut Manager monitors the
availability of data sets on behalf of the job to determine when the job should
be released from the TM HOLD queue. Once the data sets in question are
available, ThruPut Manager allows the TM HOLD job to be initiated. This
technique eliminates tying up system resources and degrading system throughput.
In addition, jobs will no longer be cancelled due to data set contention. For
more information on ThruPut Manager see the Titan Batch Processing manual.
System libraries and software
modules will not be updated or changed to accommodate user software. Also, user
software is not permitted to use any means (e.g., CALL, ATTACH, LINK) to invoke
compilers, system modules, or the Program Management Binder unless CIT documentation
specifically permits such access. These restrictions are necessary to preserve
the integrity and dependability of the operating system.
The following facilities
incorporated in the mainframe operating system cannot be used at the NIH Data Center
because they are not supported or their use may cause performance problems:
No list of exceptions can be complete. The TitanBatch Processing manual documents the software facilities to be used at
the NIH Data Center. Occasionally a user will discover a non-supported feature
in a supported product that works or appears to work, and will integrate it
into an application. Such a user runs the risk that the non-supported feature
will suddenly not work at all or worse yet, will appear to work but will
actually produce erroneous results.
Before using a facility not mentioned in our documentation,
submit a CIT Service Request (see Section 5.2.2) to make certain it is allowed. In many cases, an
alternative technique is supported.
Other Restrictions
·The creation of unmovable data sets on disk is
not permitted.
·It is forbidden to have software send
information about the application to the machine room operator's console.
·Under no circumstances should a user access
system data sets (e.g., system libraries, disk VTOCs) with any software other
than that supplied by the NIH Data Center and described in CIT documentation.
Formal action will be taken against anyone who attempts to circumvent
protection software and threatens the security of accounts or data.
·It is against CIT policy to
permit use of the system as a recreational facility; CIT will take immediate
action against anyone found using its resources to play computer games, even in
learning situations. For further details on restrictions against use of
computers for personal and recreational use, see Section 1.5.
·Because the printed output format of Titan utilities
is subject to change without notice, software should not be designed to depend
on such output. For information, refer to the manual Titan
Batch Processing.
·Certain job control language features cannot be
used at this data center. Refer to the Titan Batch Processing manual.
The UNIX System Services (USS) subsystem of Titan offers
significant enhancements in the open systems arena. USS includes the POSIX
programming environment. Because a userid must be specifically
authorized to use USS, users who need USS should contact the NIH Help Desk (see
Section 5.2.1). Keep in mind that the userid cannot contain the “$”
character.
In addition, the NIH Data Center offers an
open systems environment on EOS, a separate Unix-based hosting environment. EOS
hosts a variety of production and development applications. For additional
information on EOS see Section 1.1.2.1.
7.2TSO
TSO (Time Sharing Option)
provides interactive access to the facilities of the computer system. Users can
enter, retrieve, update, and store data; as well as create, test, and execute
programs with the results available at a workstation. The following sections
describe many of the subsystems and facilities that are installed to function
under TSO. For additional information about TSO, refer to the TSO documentation
available from CIT (see Section 5.4).
All data files to be accessed
interactively must be mainframe data sets with standard data set names (See
Section 10) and must be stored on disk. Tape data sets must be
transferred to disk prior to processing.
Titan TSO sessions issue a
warning message on the screen after every 30 CPU seconds of processing time to
alert you that your TSO session may be looping. If you receive a warning:
·It will not cause your session to be automatically
terminated. However, when you issue a TSO command or execute a program or
CLIST, do not leave your system unattended.
·Determine if the amount of CPU time used is
reasonable for the session. If the CPU time seems reasonable, ignore the
message and keep an eye on the session. If the CPU time seems excessive,
manually interrupt processing by pressing the key mapped to the ATTN, PA1, or
PA2 key, as appropriate.
TSO/E LOGON Panel
Access the Application
Selection menu (see Section 6.3) and type NIHTSO at the cursor. Tab over, enter your userid,
and hit ENTER. Next, you will see the following logon panel:
You
may request specific help information by entering a '?' in any entry field
Respond by entering your password.
Tips on This Panel
·To change your password—enter a password in the
NEW PASSWORD field at any time.
·To change the “Procedure” from the
default—change the procedure field by typing the existing one.
CIT/Titan
Primary Option Menu
Upon completion of the logon
screen you are immediately placed into the message screen, which contains
pertinent RACF information and any messages from the broadcast system.
Hit Enter to go to the CIT/Titan
Primary Option Menu panel (ISPF Primary Option Panel). To eliminate the
copyright panel in the lower left corner and see the full panel for this
screen, hit Enter. You can enter the desired option in the option field and
proceed into the selected panel. NOTE:
the option line is at the bottom of the panel.
·To return the Option ===> to the top of the
screen—change the default parameter in the Settings list. Place a zero in the
option field and the following screen will appear:
·To return the command line to the top of the
screen, remove the / in the “Command line at the bottom” option (the default).
Simply select the / and hit delete.
·The default setting places the cursor at the
action bar. To change the default and place the cursor at the option field,
remove the / from the “Tab to action bar choices” option.
·Hit F3 to exit the current panel.
·Having reset the options, your ISPF main menu
will look like the one that follows for all future sessions.
In the above panel display, F12 is
set to cancel your session.
Review the PF key settings
established by the software and reset them to meet your needs. Please note that
the PF key settings are not necessarily consistent from panel to panel,
therefore, it is a good idea to review the keys for panels you use with some
frequency. Users who have customized PF keys to their own personal features
will also have to reset them from the defaults established for Titan. The
command keys should be entered at each panel to verify the default settings.
TSO Superset Utilities
Titan provides the TSO user
with special utilities that can perform frequently required functions. The
commands include: COPY, MERGE, LIST, FORMAT, and LISTJES. SORT functions
interactively and prompts the user for input, output, and sort statements if
none are provided. The sort will make all allocations. LISTJES is an
alternative to the TSO OUTPUT command; it provides scrolling commands for
viewing the output.
Logging Off
When you log off of TSO, you
will return to the Application Selection screen (See Section 6.3).
At this point, just close the window—click the X in the top right corner.
Note—If you type LOGOFF or
hit PF3 from the Application Selection screen you will see the “NetView Access
Services” screen. You cannot do anything from this screen. To return to
the Application Selection screen, hit PF12.
Automatic Logoff
The automatic logoff interval
for TSO, following a period of inactivity, is 2 hours.
Web Access to TSO Commands
Some TSO commands can be
executed through the Web. Open your browser to:
You will be prompted for your
Titan userid and RACF password.
Select a command from the
drop-down menu, and then type in the name of the job or the data set name.
This Web-based service is provided
through SILK Web technologies. For information on other SILK Web services, see
Section 7.6.1.
Canceling a TSO Session
If you have a frozen TSO
session or a runaway CLIST, you can cancel your TSO session through the same
Web facility that allows you to execute TSO commands and cancel jobs. A TSO
session is really just a special type of job. First, you must identify the TSO
session; then you can cancel the session. Open your browser to:
·For the COMMAND option —select “status” from the
drop-down menu
·For the Job or Data Set Name option —type your
Titan userid in the open field.
·Press “Enter” to Display Your TSO Jobs
A job or list of jobs will appear.
For example:
JOB AAAAIII(TSU12443) ON OUTPUT QUEUE
JOB AAAAIII(TSU22801) ON OUTPUT QUEUE
JOB AAAAIII(TSU22843) EXECUTING
In this example, the third job on
the list is the current TSO session—that is, the one marked EXECUTING. Make
note of the job number, then click on the BACK button of your browser to return
to the previous page. The first two jobs on the list above are older sessions.
Cancel Your TSO Session
·COMMAND—select “cancel” from the drop-down menu
·Job or Data Set—type in your Titan userid. For
example:
AAAAIII(TSU22843)
NOTE:
If there are several TSO sessions in the list, you must include the job number
when you cancel your session. (Hint: just copy and paste the userid and job
number from the list of jobs).
If you need assistance, contact
the NIH Help Desk. See Section 5.2.1.
ISPF, a software system
available under TSO, extends the capabilities of TSO and provides increased
performance. ISPF also includes interfaces to
language processors, which can be invoked in the foreground, and extensive
application testing facilities. ISPF consists of two major components,
the Dialog Manager and the Program Development Facility.
Dialog Manager
The dialog manager (the application manager for ISPF) is used to
develop formatted screens tailored to the user application. It can create applications using graphical user
interfaces—including pop-up windows, action bars, and pull-down menus.
Program Development Facility (PDF), Also
Known as SPF
The program development facilities
can create or access a partitioned or sequential data set. In addition to
program source statements and JCL, the data sets may consist of input data or
text for any kind of processing or formatting program. The program development
component includes:
·a full-screen editor
·forward, backward, and lateral scrolling
·an interface to data utilities for library,
file, and data set maintenance
·foreground and background execution of language
processors
·a facility for submitting batch jobs to JES2 for
background processing
·an online tutorial
·split screen capabilities that permit the user
to alternate between two functions as though two terminals were in use
Several
additional products provide enhancements to ISPF:
·MVS/QuickRef - a “pop-up” quick reference tool (see
Section 7.2.3)
·MAX- a collection
of data and file manipulation programmer tools (see Section 7.2.2)
·User Display Facility (UDF) - a facility that allows
users to display information about batch jobs. For additional information, see
Section 7.2.4.
ISPF Logon and Logoff Procedures
To use ISPF, log on to TSO.
(See Section 6.3 for the system selection procedures.) The system will
automatically bring up the CIT/Titan Primary Option Menu. This is also the
primary option menu for ISPF. To exit ISPF and get to the TSO READY prompt,
type X at the command line.
ISPF Edit
ISPF provides a complete range
of full-screen editing facilities including:
·scrolling forward, backward, or sideways through
a data set and use of the cursor to add, change, or delete characters anywhere
on the display screen
·inserting, changing, or deleting lines anywhere
in the data set, duplicating lines, and copying or moving lines from one place
to another
·creating new data sets by entering new data or
copying data from other data sets
·performing frequently used operations by use of
Program Function (PF) Keys
ISPF Utilities
ISPF utilities are a group of
full-screen, interactive commands that provide a variety of functions commonly
required for effective processing. These commands are initiated and controlled
during an ISPF session through easy-to-use menu selection panels. The major
functions are:
·maintaining libraries, data sets, and catalogs
·moving and copying data
·resetting ISPF library statistics
·initiating hardcopy output
·displaying or printing VTOC entries for a disk
volume
·browsing through and printing held SYSOUT data
For More Information
To learn more about ISPF
facilities, try using the interactive tutorial. From the CIT/Titan Primary
Option menu, select Help from the Action Bar on the top of the panel, and then
choose Tutorial. CIT offers documentation on ISPF through the Web. See Section 5.4 for more information.
MAX is a collection of data
and file manipulation programmer tools for use under ISPF. MAX has the ability
to browse and edit VSAM data sets and sequential data sets online. It permits
formatted browsing and editing using COBOL copybooks. MAX also helps users
allocate or delete VSAM files. It eliminates ISPF's record length and file size
restrictions. Other features include enhanced data set name lists, and a “cut
and paste” option for records within one edit session or between edit sessions.
Access to MAX
Type MAX at the CIT/Titan Primary
Option Menu.
For More Information
For additional information on MAX,
consult the documentation offered by CIT. See Section 5.4 for ordering information.
MVS/QuickRef is a pop-up
reference tool running under ISPF that allows users to look up information
(e.g., on error messages, ABEND (Abnormal ENDing) codes, command structure) and
get answers quickly online. The term “pop-up” in this context refers to
MVS/QuickRef's ability to “pop up” over the current application and display
information rapidly, no matter which ISPF application or panel is active.
Access to MVS/QuickRef
·Type QW directly at the ISPF command line.
or
·Type C for Additional Products at the CIT/Titan
Primary Option Menu. At the Additional Products screen, type Q.
The User Display Facility
(UDF) allows users to display information about jobs processed by ThruPut
Manager. If ThruPut Manager is delaying the execution of your job, UDF will
allow you to display information such as hold reasons, job dependencies, and
needed data sets.
Access
Type TMUSER at the ISPF command
line.
For More Information
For additional information on UDF,
consult the Titan Batch Processing manual.
See Section 5.4 for information on the CIT publication service.
NIH WYLBUR is an interactive system,
available on full-screen terminals, for batch job entry and tracking, coding
and execution of command procedures, text editing, and document formatting,
with features that simplify many data processing tasks. It runs under TSO.
NIH WYLBUR provides interactive
access to disk data sets whose names begin with valid userid format. The commands
are common English words (usually verbs) that describe the work to be done. The
JES2 interface provides a remote job entry and remote job output (RJE/RJO)
facility for submitting batch jobs, monitoring their job status, and
manipulating by canceling, purging, or printing the job's input and output.
Access
NIH WYLBUR in Several Ways:
·Type TSO WYLBUR on any command line within the
CIT/Titan Primary Option Menu (ISPF).
·Type WYLBUR on the ISPF Command screen (option 6
on the CIT/Titan Primary Access Menu).
·Type WYLBUR at the TSO READY prompt.
Scrolling
the Screen in WYLBUR
In WYLBUR you can scroll back to
output that has disappeared off the screen by using the IBM Session Manager.
Without Session Manager, the Titan full-screen mode would prevent scrolling
back to previous output.
To use Session Manager:
·On the TSO/E LOGON screen, enter sessmgr
as the value for Procedure.
·On the CIT/Titan Primary Option Menu, enter x.
You must exit ISPF to
use Session Manager. It will not work under ISPF.
·On the TSO Session Output screen, enter wylbur.
You may begin using
WYLBUR.
To return to ISPF after you have
ended your WYLBUR session, enter SPFMAIN.
Follow these guidelines:
·Use F7 to
scroll backwards and F8 to scroll forwards.
·You must define a set break character to be able
to leave collect mode. For example:
set break BRK
You can then exit
collect mode by entering BRK as the first characters on any line.
·The modify and retry commands are tricky to use
because the cursors are not positioned properly.
·You may sometimes have to enter an extra
carriage return to see your output.
For more information about Session
Manager, refer to the TSO/E User's Guide. Go to the CIT publications Web
page (see Section 5.4) and select Time Sharing Option (TSO) under Titan.
CICS is a transaction server
that supports many concurrent users and allows access to a diverse group of
database files. It functions as a general-purpose database/data communications
system that supports a variety of terminal types and Web interfaces. CICS
serves as an interactive interface between the user and the operating system.
Features
·executes by itself in a single-tier architecture
or as either a client or a server in a multi-tier architecture
·interfaces with an external security manager to
provide security to the data files, the transactions, and all of the required
resources
·supports programs written in JAVA, ASSEMBLER, C,
COBOL, and PLI
·functions with commercial software designed to
use CICS as its communications interface
Applications that require CICS are
subject to prior approval by CIT. The user and CIT jointly develop the
protocols for accessing the user's application.
Access to CICS
From the Application Selection
screen on Titan (see Section 6.3), enter the CICS region that you wish to access (CICSPROD
or CICSTST1).
This section describes the database
systems supported by Titan. For more information on database facilities
supported at the NIH Data Center, connect to:
and select Database Services. See
Section 5.2.4 for information on database assistance.
7.4.1Model
204
Model 204 is a database
management system in which access structures, programs, and data are stored
together. Model 204 provides a high degree of flexibility that encourages the
use of application prototyping. This reduces the likelihood of structural
changes to an application after it has become operational.
Every Model 204 file is a separate
data set that consists of five tables. These tables contain directories of
field names and attributes, data, inverted lists, and other control
information.
Model 204 relationships are based
solely on the value of data. Relating two or more records requires the
existence of common data values within the records. Hierarchical and network
relationships can be supported by this “commonality of data” characteristic.
Model 204 has its own
easy-to-learn user language. It also provides interfaces to standard programming
languages. Model 204 runs in batch mode as well as interactively.
Access
To access Model 204 on Titan,
users must first have a valid Titan system userid and password. Account
sponsors can then register users on their account for Model 204 through Web
Sponsor (see Section 2.3).
Refer to Section 6.3 for general interactive access information.
Registered Model 204 users can access Model 204 from the Titan Application
Selection menu (see Section 6.3). The following example shows the commands that are
used to log on and log off Model 204:
To sign-on: LOGON
userid
To sign-off: LOGOFF
Users desiring to establish new
Model 204 files should contact the NIH Help Desk.
Security Features
RACF protects data from
unauthorized access. Model 204 has additional security features that include
individual logon accounts and passwords, as well as file passwords for
accessing secure files or groups of files.
Web Access
Model 204 can be accessed
through the Web using SILK (Secure Internet-LinKed) Web technology. Web users
can issue Model 204 commands, execute existing Model 204 programs and APSY
subsystems, and create ad hoc queries. Go to:
Model 204 commands that can be issued
from a Web browser include:
·LOGWHO (list all active Model 204 users)
·DISPLAY (PROCEDURES and FIELDS)
·VIEW (ERRORS, PARAMETERS, and UTABLE)
·DELETE PROCEDURE
APSY subsystems, such as BUMPME
(remove an active user from the online system), can also be used.
Users can invoke stored or ad hoc
Model 204 procedures that return one-line reports, full-screen formatted
reports, or print all information (PAI) unformatted reports. Output can be
printed on a local or NIHnet-connected printer, or viewed from the browser. For
more information on SILK, see Section 7.6.1.
IMS (Information Management
System) is a database/data communication (DB/DC) facility that supports
user-written batch processing and teleprocessing applications. Using the IMS
facilities in a combination of batch and teleprocessing modes permits the
efficient and orderly development of data management applications. IMS user
application programs may be written in Assembler Language, COBOL or PL/I.
IMS is a hierarchical database management system. It
is appropriate for very large databases that will be accessed by many users at
one time. A professional database administrator or programmer must set up the
database's structure and keep track of implementation. Requesting a report with
information formatted or selected in a new way requires extensive applications
programming and cannot be done on short notice.
The database management facility of IMS is also
referred to as Data Language/One or DL/I. The Batch Terminal Simulator (BTS II)
is designed to operate as a batch program and provides a comprehensive
development and debugging tool for IMS applications.
The NIH Administrative Database (ADB), which is used for several NIH
business functions, is maintained in IMS. ADB users must register with the
Administrator of the Administrative Database so that the proper account can be
billed for the IMS resources consumed and the appropriate IMS security can be
assigned.
Access
IMS can be accessed using QWS3270
PLUS or QWS 3270 Secure. QWS3270 Secure instructions contain separate
configuration directions for IMS/ADB users to allow them to connect directly to
IMS. If you use QWS3270 Secure, set the “Port” to 2324 for the direct
encrypted connection to IMS. If you use QWS3270 PLUS, set the “Port” to 2325.
For further information on QWS3270 PLUS or QWS 3270
Secure, see Section 6.3.1. Any problems in using IMS or interfacing with it
should be directed to the NIH Help Desk.
Use of IMS is restricted to
projects approved by the NIH Data Center. This restriction is necessary because
the data center's capacity to deliver the quantity and quality of support
required by IMS is limited. For more information, contact the NIH Help Desk.
For
More Information
IMS documentation is available
from the CIT publication service. See Section 5.4.
The NIH Data Center offers
relational database systems (including IBM DB2 on Titan, Microsoft SQL Server,
and Oracle) to its users in an environment where users can manage their own
databases and applications.
Titan provides the connectivity
software that allows Titan users to access Oracle databases residing on other
server environments. Titan sends a request to an Oracle database, where it is
processed. The Oracle database then sends the result back to the Titan user.
There are batch cataloged procedures (procs) on Titan to facilitate making the
requests to Oracle databases. CIT also offers hosting and management of Oracle
relational databases on the CIT EOS (Unix) systems (see Section 1.1.2.1).
The NIH Data Center supports a
number of programming languages, offering a wide range of capabilities.
For
More Information
For further information, refer
to the Titan Batch Processing manual and the documentation for the
individual programming languages available from the CIT publication service.
See Section 5.4 for information on the CIT publication service. Contact
the NIH Help Desk (see Section 5.2.1) if you need assistance.
COmmon Business Oriented
Language (COBOL) is used for non-scientific applications. The version of COBOL
on Titan is compatible with the American National Standards Institute (ANSI)
standard and contains a number of IBM extensions. COBOL is based on a
well-defined, restricted form of English.
Access
The COBOL compiler is available
interactively (foreground) from TSO/ISPF and in batch (background) mode. The
TSO/ISPF COBOL compiler is found in ISPF panel 4.2 for foreground and panel 5.2
for batch.
FORTRAN is one of the most
commonly used languages for scientific and engineering applications. The VS
FORTRAN compiler is available on Titan. The VS FORTRAN compiler meets the 1978
ANSI standard (also known as FORTRAN 77).
Access
The VS FORTRAN compiler (Version 2
Release 3.0) is available interactively from TSO/ISPF and in batch mode. The
TSO/ISPF VS FORTRAN compiler is found in ISPF panel 4.3 for foreground and
panel 5.3 for batch.
PL/I is a multi-purpose
language used in business and scientific applications. PL/I contains most of
the capabilities of FORTRAN and COBOL as well as some additional features.
Access
The Titan PL/1 compiler is available
interactively from TSO/ISPF and in batch mode. The TSO/ISPF PL/1 compiler is
found in ISPF panel 4.5 for foreground and panel 5.5 for batch.
The IBM Operating System High Level
Assembler is a symbolic programming language used to write programs for the IBM
mainframe system. The language provides a convenient means for representing the
machine instructions and related data necessary to program the IBM mainframe
system. Assembler Language is generally used for system programming where
machine-dependent operations are required that cannot be performed using one of
the higher-level languages such as COBOL or FORTRAN. The Assembler program
processes the language, provides auxiliary functions useful in the preparation
and documentation of a program, and includes facilities for processing the
Assembler macro language.
Access
The
Titan Assembler compiler is available interactively from TSO/ISPF and in batch
mode. The TSO/ISPF Assembler compiler is found in ISPF panel 4.1 for foreground
and panel 5.1 for batch.
REXX
(Restructured EXtended eXecutor), which runs under TSO, provides a fully
functional application development environment, including structured
programming techniques, logical and arithmetic operations, and communication
with the TSO end user. REXX features a choice of compiled or interpretive
execution, convenient built-in functions, free-format coding, debugging
capabilities, and very extensive parsing and character string manipulation.
The REXX Compiler and Library
allow users to translate frequently used routines into compiled REXX programs.
The REXX Library also contains common routines that are accessible to all
compiled REXX programs.
The REXX documentation is
available from the CIT publication service (under the TSO category). See
Section 5.4.
Access
The Titan REXX compiler is available
interactively from TSO/ISPF and in batch mode. The TSO/ISPF REXX compiler is
found in ISPF panel 4.14 for foreground and panel 5.14 for batch.
SILK (Secure Internet-Linked)
Web technologies were developed for users of the NIH Data Center. Users can
take advantage of SILK Web technologies to access any sequential data set or
PDS member from a Web Browser, download files, issue TSO commands, change RACF
passwords, locate a user or the account sponsor, and perform many other
functions.
The data may be any type of output supported
by Web browsers—including plain text, html, gif, jpeg, or other binary files.
All SILK reports are protected by RACF, the IBM mainframe security software.
The EOS
(Unix) platform provides SILK Web facilities for easily building applications
to obtain, examine, update, and store information using Web browsers. SILK
technologies permit applications to be implemented on the platform that is
most appropriate for their requirements.
There are many important Titan
services that are available via SILK Web pages. Web RACF allows users to
perform RACF functions (see Section 4.6.4). Web Sponsor is a tool for account officials to make
changes to accounts and display information (see Section 2.3).
Users can view documents on SILK
servers on their personal computers, then download or print them on local or NIHnet-connected
printers.
The following figure provides a
summary of many of the SILK-based services.
There are three SILK Web
server options available for Titan that allow users to display mainframe data:
·a public server (displays files to anyone with a
browser)
·a secure server (displays files to a limited
group of viewers)
·a customized server (set up and managed by the
user to display mainframe files or files uploaded from the owner's workstation)
Creating Links
You can use public, secure, and
customized servers to view Titan data sets from the Web by creating a link such
as:
http://titan.nih.gov/secure/dsname
http://titan.nih.gov/public/dsname
http://titan.nih.gov/silk/myserver/mypage
where:
“dsname”
is your data set name (see Section 7.6.2.3 for data set format and naming information)
“myserver”
is the name you give to your server
“mypage”
is the name you give to the Web page
The owner of a mainframe data set
controls access to the data set being displayed. Access can be “universal” or
restricted to individuals or groups by using mainframe RACF commands. SILK data
sets are mainframe data sets with full RACF protection—they can be made as secure
as any other mainframe data set.
For more information concerning
SILK Web technology on Titan, call the NIH Help Desk.
This server contains data
available to anyone with browser software and an Internet connection. Data sets
for public access should be defined in RACF with “UACC=READ.”
Type http://titan.nih.gov/public/
in your browser address window, followed by the name of the data set that you
want to view.
For example:
http://titan.nih.gov/public/userid.@WWW.MYDATA
For information on creating and
naming data sets for the public server, see Section 7.6.2.3.
Anyone viewing data sets using
the Titan SILK secure server must supply a valid Titan userid and RACF
password. The userid will be checked for RACF authority to read the data set.
It is the data set owner's responsibility to establish and maintain appropriate
RACF control of Web accessible mainframe data sets. The secure server uses RACF
to control access to stored data.
Type
http://titan.nih.gov/secure/ in your browser address window, followed by the
name of the data set that you want to view.
For example:
http://titan.nih.gov/secure/userid.@WWW.MYDATA
For information on creating data
sets for the secure server, see Section 7.6.2.3.
Creating
Data Sets for the Public and Secure Servers
In order to display the data
set via SILK:
·Create a data set on the Titan system following
the naming conventions described below.
·If you are using
WYLBUR, specify the HTML option of the WYLBUR SAVE command. The HTML option
allows youto save any text data in a
format compatible with the SILK Web server.
·Set the level of RACF control for the data set.
This determines the access limitations.
Naming
Data Sets for Public and Secure Servers
The naming conventions require the
following elements:
·a Titan userid
·“@www” as a qualifier. The “@www” naming
convention adds an additional layer of security because it prevents Web access
to other mainframe data sets.
·the correct suffix
Suffix
Meaning
HTM or HTML
HTML code
GIF, JPG, JPE or JPEG
GIF or JPEG graphics file
DSNCC
mainframe format with printer
control characters in column 1
·Then type either “public/” or “secure/” (without
quotes) depending on the level of RACF control set for the data set.
·Add the full data set name of the data set.
Refer to the examples in Section 7.6.2.1 and Section 7.6.2.2.
·Display, download, or print that data set.
The NIH Data Center takes care of
all server maintenance. All you need are a few simple lines of html code stored
on the mainframe.
Graphics Files (all servers)
If you want to display a graphics file (e.g., a GIF or
JPEG file); upload the file from your desktop computer, via FTP, using binary
format. Specify RECFM VB, LRECL 255, BLKSIZE 23476 on the mainframe. Make sure
the file conforms to the naming requirement described above. Specify an
extension of GIF for a GIF file, and JPEG, JPE, or JPG for JPEG files.
Customized SILK servers allow users to create and
manage their own full-function SILK Web server without having to purchase and
maintain hardware or software. The NIH Data Center takes care of all
server maintenance. The operating system for a
customized SILK server is transparent to the user. A customized SILK server can
be set up by anyone with a CIT Titan (mainframe) userid, a Web browser, and an
e-mail address. You can upload pages directly from your desktop computer using
SILK's file transfer facility. You can also access data sets stored on Titan
through a customized SILK server. For information on linking mainframe data
sets to pages on a customized SILK server, see below.
SILK
Web server owners can define and control access to their servers—providing the
basis for a corporate intranet facility. There are three access security
levels:
·“unrestricted” (for
anyone with a Web browser)
·“registered users”
(limited to CIT users)
·“designated users”
(The owner designates the specific CIT userids that will have access
privileges).
SILK
server owners can choose to apply an optional “group password” available to all
three levels of access. In addition, secure socket layer (SSL) protection
provides for data encryption across the network.
and
choose Create and Manage Customized Servers (under SILK Servers). At the
Customized Servers page, select Create Server and enter a name for the server.
When you set up a SILK Web server, you must comply with your agency's Web
server policies. If you are associated with NIH, you will have an opportunity
to read the NIH server policies. A server will not be created until after you
have indicated that you have read and understood your agency's policies.
Once
you have created the server, you can make changes to it, such as adding a
co-owner, changing the name or description of the server, changing the security
level, adding the server to a registry of SILK servers, etc. Go to the
Customized Servers page, look in the Manage Server area, and click on the name
of the server that you wish to change. To upload files to your customized SILK
server, go to the Customized Servers Page, scroll down, and select the File
Transfer Facility. You can also link mainframe data sets to your customized
SILK server. For detailed information, see below.
Customized
Servers with the SSL Encryption Option
SILK servers can take advantage of SSL (Secure Sockets
Layer) encryption. SSL encryption protects the data being transferred between
the Web server and the Web browser. The data that are transferred are
encrypted, and therefore not visible as they travel across the network. To
include the SSL feature for your customized SILK server, check the SSL box on
the Manage Server page. There is an additional charge for using the SSL option.
See Section 3.1 for charging information.
SILK Web's customized servers allow users to associate
mainframe data sets with Web pages (URLs) on a customized SILK server. Owners
of SILK customized servers can go to:
to
see a list of all their SILK customized servers. To associate a page on the
server with a data set stored on Titan, do the following:
·Click on a server
name.
·Choose the option
“Add a page using an existing Titan file.”
·Type the name for
the page on your SILK server and click the “Add” button.
·On the form that
is displayed, type the data set name to be associated with the Web page.
·Select the
appropriate document type for the Web page from the drop-down list box.
Document type
Description
“text/html”
for
data sets containing html tags
“text/plain”
for
data sets containing text only
“dataset/cc”
for
data sets containing text with a carriage control (cc) character in column 1
“suffix”
for
data sets that have a document type as the last qualifier in the data set.
With the “suffix option” the Web page name aaaaiii.mypage.html is interpreted
as “text/html” whereas aaaaiii.myimage.gif would be interpreted as “image/gif.”
·Select the “Create”
button.
Example:
If you
have a server called “Personnel,” you can create a Web page for that server
called “Leave.” Associate the data set aaaaiii.hr.leave (where aaaaiii is your
Titan userid) by following the instructions above. Each time a browser requests
http://silk.nih.gov/silk/personnel/leave, your customized server will display
the contents of the mainframe data set aaaaiii.hr.leave.
(The
initial part of Web addresses—http://silk.nih.gov/silk/personnel/—is not
included in the following examples.)
Additional
Information for Partitioned Data Sets
SILK
allows users to link a Web page to a member of a partitioned data set (PDS).
Example:
You can create a Web page called “policies/overtime” and associate it with
a member of the partitioned data set “aaaaiii.hr.policy(ot).”Note that the Web
page name can contain a “/” to indicate subdirectory.
Wildcards
in Web Addresses
SILK
permits Web page addresses containing wildcards. Wildcard pages use “*” to
indicate a value that will be determined by the URL requested. A portion of the
page name determines the mainframe data set name to be displayed. With wildcard
Web pages, you do not have to manually associate each Web page with a specific
data set.
Examples:
A Web
page called “Vacancies/*” can be associated with the mainframe data set “aaaaiii.vac.*”.
When someone types the full Web address into the browser window, the portion
corresponding to the “*” will be substituted into the “*” in the data set name.
If the incoming Web address is vacancies/tech/cs001, then the mainframe data set
“aaaaiii.vac.tech.cs001” is displayed. NOTE:
a “/” in the Web address is automatically converted to a “.” in the data
set name.
The Web page name called “Training/*” can be associated with a member of a
mainframe partitioned data set “aaaaiii.train.course(*).”Whenever the Web
address training/crs1234 is requested, the corresponding data set “aaaaiii.train.course(crs1234)”
would be displayed.
Data Set
Security
The
NIH Data Center strongly recommends the use of RACF profiles to protect the
mainframe data sets that you display on the Web from unwanted access. See
Section 4.6.3 for further information.
These utilities display mainframe data sets ending in .txt,
.dsncc, .gif, .jpg, and other (nonspecific) data set names. It also downloads
data sets that end in .exe .doc .xls or .zip.
View or
Download Mainframe Public Data Sets
Anyone with a browser and an
Internet connection can view or download a Titan data set.
The owner of the data set must first define the data set
in RACF with “UACC=READ.”
To view or download these data
sets, you need a Titan userid and password in addition to the browser and
Internet connection. The userid will be checked for RACF authority to read the
data set. It is the data set owner's responsibility to establish and maintain
appropriate RACF control of Web accessible mainframe data sets. RACF controls
access to the stored data.
Creating a Web interface for
your mainframe applications makes them accessible with the easy-to-use features
of a browser. The mainframe's RACF facility provides complete security for your
data, and only authorized accounts will be allowed to see your Web data. Using
SILK Web interfaces you can:
·store reports on the mainframe in Web-enabled
formats
·limit access to information to the appropriate
accounts
·initiate queries from the Web to run against
mainframe databases
The SAS System is an
integrated system of software products for performing tasks such as data entry,
data retrieval, data management, report writing, graphics, statistical and
mathematical analysis, business planning, business forecasting, business
decision support, operations research, project management, quality improvement,
and applications development. SAS builds and operates on SAS data sets, VSAM files,
sequential files DBMS tables (DB2, Oracle, and others), MS Excel, and MS
Access. In addition to the basic SAS system, there are many other products in
the SAS suite available on Titan. See Section 7.7 for the appropriate Web site.
TSO
CLISTs
SAS is also available
interactively under TSO through the following CLISTs:
%SAS
for initial entry into the system
%SAS GO
to reenter the system during the
same TSO session
%SUPPORT
gives the entry into SAS NOTES
and SAS SAMPLE libraries through a menu-driven facility
Access
To access SAS, select L (Local)
from the CIT/Titan Primary Option Menu, and then select the SAS option.
If you need assistance, contact
the NIH Help Desk. See Section 5.2.1.
BMDP is a library of statistical analysis
programs that were originally developed at the UCLA Health Sciences Computing
Facility. The programs are self-contained and use an English-based control
language. Emphasis is placed on determining the validity of underlying
statistical assumptions and on identifying implausible values. Many of the
analysis features cannot be found in other statistical analysis systems.
Use
the BMDP procedure in SAS programs to:
·call a BMDP program to analyze data in a SAS
data set
·convert a SAS data set to a BMDP “save” file
For
assistance, contact the NIH Help Desk. See Section 5.2.1.
SPSS provides capabilities for
extensive file handling and data management tasks, including advanced
statistical analysis procedures (e.g., discriminate analysis, nonlinear and
logistic regression analysis, and multivariate analysis of variance). SPSS runs on Titan in batch mode. CIT
also supports many SPSS products on Windows and Mac operating systems.
The Interactive Output
Facility (IOF) provides users with complete access and control over their
generated print spool output and input batch jobs. IOF lets users track the
progress of a job and view the output. There is a tutorial (Quick Trainer) and
a help screen at every panel when viewing the printed output, selected
portions, or components of a spooled job. In the basic TSO environment, IOF
will also run from the READY prompt.
Access
To use IOF, do one of the
following:
·Select IOF from the CIT/Titan Primary Option
Menu.
·Enter IOF at the TSO READY prompt.
·Type IOF at the TSO/ISPF command line.
For More Information
For additional information on IOF,
consult the Titan Batch Processing manual and other documentation offered
by CIT. See Section 5.4 for more information.
Users can send e-mail through the Titan
system using a Web (Easymail and Formsmail) or batch (Sendmail) interface.
Titan does not have a facility that allows users to receive e-mail.
NOTE:The electronic mail service supported by CIT
is the NIH Central Email Service (CES). The CES provides e-mail, scheduling,
and other messaging services to the NIH community. NIH users are encouraged to
take advantage of this service. There is no direct charge for CES to NIH ICs.
Contact the NIH Help Desk for further information, or go to:
Web page developers can add e-mail to their pages
using a hypertext link to Easymail. To invoke Easymail from a Web page, use the
following HTML coding:
Clicking the “Send e-mail” link displays the Easymail
form.
You can also have e-mail sent to a pre-specified
e-mail address by including “?to=“ in the HTML (hypertext markup language)
coding. For example, to send e-mail to the “webmaster@my.site.gov” address,
include the following code:
In this case, the Easymail form would be initialized
with “webmaster@my.site.gov” as the To: address. NOTE: the person
sending the mail must have a Titan userid to access Easymail.
Formsmail is a SILK Web facility that sends information collected using an
online Web form directly to a specific, predetermined e-mail address. With
Formsmail, a registered user can set up a form on any Web server (including
SILK Web customized servers) and receive the resulting information via e-mail.
For more information go to:
The SENDMAIL utility is a batch
procedure used for sending e-mail from Titan. Refer to the Titan Batch
Processing manual for a full description of this procedure.
VISION:Builder (previously known as MARK IV)
is a general-purpose file management and reporting system. The system can
process multiple coordinated input files, create multiple output files, update
or create a new master file, retrieve data by selection criteria, and produce
multiple user reports with summary statistics, all in a single pass of the
master file.
VISION:Builder
supports fixed and variable length sequential and virtual sequential (VSAM)
files. The system is easy to use due to system defaults and automatic
operations. VISION:Builder is adaptable to most commercial data processing
applications.
Access
VISION:Builder runs in batch mode using standard JCL or
interactively from TSO/ISPF. At the CIT/Titan Primary Option Menu, select C for
Additional Products, and then select VI for VISION:WorkBench Facility for
interactive execution. This product is not fully supported by CIT. Use it at
your own risk.
IRS is a general batch-oriented information
management system. It provides the user with a fast, efficient, easy-to-use
technique for extracting information from computer files, performing basic data
processing operations, and producing printer, tape, and disk output. IRS runs
in batch mode only. IRS is an older product that is not fully supported by CIT.
Use it at your own risk.
Titan supports IBM BookManager for viewing online documentation
such as user's guides, product specifications, maintenance manuals, procedures
manuals, vendor's publications, reports, articles, and bulletins.
Online
information has the familiar book appearance on the viewer's display screen,
and allows you to:
·open to a specific place in the book
·scroll forward and backward
·use the table of contents and index
·go directly to any chapter or topic
·group books on a bookshelf
·link to other books (hypertext)
Access
To
browse the BookManager Bookshelf List, which includes IBM manuals, go to the
CIT/Titan Primary Option Menu. Select C for Additional Products, and then
select B for Books.
CIT
only supports the READ function of BookManager. For additional information on
IBM BookManager, contact the NIH Help Desk.
This section introduces the facilities for
producing printed output from Titan. Printing services are available through
batch jobs, NIHnet connections to local printers, and the Web. See Section 11.1.1.3 for the specifications for the printers at the
central facility.
The
Titan Batch Processing manual
includes a comprehensive description of printing services for Titan through
batch jobs, including the following topics:
·job control language (JCL) statements used by
batch jobs to select output options
·forms for laser and impact printing
·labels
·user-supplied forms
·character sets
·hexadecimal tables for character sets
·carriage control
·form control buffers (FCBs)
·table reference characters (TRC)
·Hardcopy utility of ISPF
OUTPUT
HOLD
All jobs in OUTPUT HOLD on Titan are purged
(except for SYSOUT=I which is printed) after 7 calendar days―this
includes weekends. Jobs awaiting output for more than 14 calendar days will be
purged even if routed to a remote printer or another NJE node. Refer to the Titan
Batch Processing manual for information on SYSOUT classes. (See Section 5.4 for information on how to access CIT documentation).
For
More Information
For
further information on printing through batch job submission, consult the Titan
Batch Processing manual or contact the NIH Help Desk. See Section 5.2.1.
Users who run jobs at other NJE nodes and
then route the job to print on Titan must add the following statements after
their JOB statement:
/*JOBPARM ROOM=bbbb
/*NETACCT userid
where
“bbbb” is the box number for the output and “userid” is the Titan userid. To
specify a Parklawn output box, place the letter “P” before the box number.
Without the /*JOBPARM ROOM=bbbb statement, your output may not print, may go to
the wrong box, or may be discarded. If there is no /*NETACCT control
statement—or if the Titan userid on the NETACCT statement has not been
registered to use NETACCT—then the SYSOUT from the non-NIH node will be
rejected by Titan. The SYSOUT will be sent back to the sending node.
Refer
to Section 6.6 for more information on Network Job Entry.
All Titan output is printed at the NIH
Bethesda site. Output printed on the central printers must
have a box number associated with the job. See Section 5.6 for more information on output distribution services
including how to specify a box number for your job.
When
the machine room operators sort the output, it is placed in the box
corresponding to that number in building 12A at NIH. Note: users must make their own delivery arrangements for output
designated for Parklawn (“P” preceding the box number).
Users can print output from the Titan to
printers accessible via NIHnet or the Internet using the VPS printing service.
The output goes to printers attached to a
PC, Mac, workstation, or local area network (LAN) connected to NIHnet and
running an LPD server. AppleTalk printers are supported in conjunction with the
PrintShare services provided by CIT. See Section 6.5 for more information on VPS.
8.3Printing from the Web
Using SILK's Web
Listoff facility, you can print Titan data sets through the Web. Any non-VSAM
data set—except those in WYLBUR edit
format—can be listed offline. Since all data set access is controlled by RACF
(see Section 4.6), you can only print the data sets that your userid
has authority to read.
Enter your userid and password in the browser security
window. When the form appears, specify the data set name and the following
options for listing offline:
·box number
·title
·remote printer
number or name (VPS printer)
·number of copies
·hold (optional)
·form (optional)
·character set
(optional)
Once you submit the form, the screen will display the
number of the batch job that will actually create the listing. You will be able
to pick your listing at the specified output box (see Section 5.6.1) or a VPS printer.
The batch processing facility of the Titan system allows users to submit
a job or computer program to the mainframe system. The NIH Data Center provides
an extensive set of batch utility programs to aid the user in the areas of data
management and manipulation. Users can print job output or examine it at their
desktop workstations. Refer to Section 9.6 for information on managing batch jobs through the
Web.
For More Information
Refer to the manual Titan Batch Processing for complete information on running batch
jobs, methods of submission, job class summaries, job turnaround times, job
control language statements, and the procedures for using batch utility
programs and cataloged procedures. CIT also provides other documentation
related to batch processing. See Section 5.4 for information on viewing and ordering
documentation.
The z/OS Titan mainframe operating system introduces programs to the
computing system, initiates their execution, and provides all the resources and
services necessary for the programs to carry out their work. The operating
system is made up of a general library of programs that can be tailored to meet
many requirements. The installation can select the systems programs that it
needs, add its own programs to them, and update existing programs as needs
change.
For illustrative purposes, the programs and routines that compose the
operating system are classified as a control program and processing programs.
The control program:
·accepts and
schedules jobs in a continuous flow (job management)
·supervises
each unit of work to be done (task management) on a priority basis
·simplifies
retrieval of all data, regardless of the way it is organized and stored (data
management)
The processing programs define the work that the computing system is to
do and simplify program preparation. Processing programs consist of:
·language
translators (such as the FORTRAN compiler)
·service
programs (such as the Binder)
·problem
programs (such as users' programs)
For a description of the Titan operating system, see Section 7.1.
Job Control Language (JCL) is the means by which
the user communicates the resource requirements for a job to the operating
system and various components of the mainframe system. Through JCL, the user
instructs the computer on what to do with programs, data sets, and I/O devices.
ThruPut
Manager
Titan uses software called ThruPut Manager to
convert JCL from the former NIH mainframe systems to run on Titan. It
recognizes the format of an incoming JOB statement, converts the JCL, and
directs output to the appropriate printers. ThruPut Manager also controls the
flow of jobs on Titan. When a job needs tapes, it schedules the job
accordingly. For additional information on batch processing and job control
language for Titan, refer to the Titan Batch Processing manual.
Jobs
are assigned to execution classes based on the system resources requested.
There are two execution classes on Titan:
·L for Long – This is the default class. Class L
has a default CPU time of 999 seconds (16 minutes and 39 seconds) and a maximum
time of 999 minutes.
·X for eXpress – Class X has a default and
maximum CPU time of 100 seconds (1 minute and 40 seconds). In general, jobs
that execute in Class X receive a higher scheduling priority than jobs that
execute in Class L.
When a job has completed execution, it enters a queue to be printed or it
is placed in OUTPUT HOLD (from which the user can selectively examine the
output at a workstation). Use IOF (see Section 7.8), the Web-based Display or Purge Jobs facility
(see Section 9.6), or WYLBUR, to track the progress of a job, review
the output, or purge the job.
Output turnaround is from the time a job enters the print queue until the
output has been placed in the user's output box. For information on output
boxes, see Section 5.6.1. Time can
vary widely depending on the services chosen. For jobs printed at the central
facility with the standard printing requirements, the time for the job to be
printed, separated from other jobs, and routed to the appropriate output box in
building 12A will normally be two hours or less during normal working hours.
9.5OFF-HOURS JOB PROCESSING
To request overnight or weekend processing, include the proper ThruPut Manager statement on a Titan JOB
statement.
To
request overnight processing, add the following control statement:
//*+JBS BIND
OVERNITE
To
request weekend processing, add this control statement to the JCL stream:
You can submit batch
jobs through the Web on a one-time basis or on a regularly occurring schedule.
Titan also provides a Web facility for displaying or purging batch jobs. For
more information on the various methods of submitting batch jobs and managing
output, refer to the Titan Batch Processing manual.
Submitting a Single Job
There are two options for submitting a single
batch job through the Web:
·Execute the TSO SUBMIT
command through the Web at:
When the Web form appears, enter a mainframe data set name to be submitted
as a batch job and specify the appropriate options.
The data set must have the record format FB (fixed-length records,
blocked) with LRECL=80. NOTE: the
data set can not be in WYLBUR edit format. The userid specified in the browser
security window must have RACF authority of “read”or above for that data set.
When you submit the job, the job number is displayed. If the job is
rejected for some reason, that information will also be displayed. To find why
the job was rejected, either examine the printed output or fetch the job.
For further information on submitting batch jobs refer to the manual Titan
Batch Processing.
Scheduling
Recurring Work
Web-based Job Scheduler
The Titan Job Scheduler allows users to schedule recurring work
to run automatically. This Web-based facility gives you complete control over
setting up, displaying, and modifying your batch job entries. You can schedule
a job to be submitted once or on a continuing basis. Simply provide the name of
your JCL data set and when you want it run—that is, on a specific date, every
day, every weekday, once a week, once a month, or the first or last workday of
every month. After that, your job is run automatically on the date and time you
requested with no further action on your part.
Job
Scheduler lets you see what jobs you have scheduled and allows you to change
the JCL in your data sets at any time, without affecting the schedule. Each
time a job is submitted through Job Scheduler, an entry appears in a log. To
view the log, use the Display Submission Log button from the Job Scheduler Web
site.
Users who require more complex scheduling (e.g., multiple jobs
that interconnect in some way, or e-mail notification of job failure) may need NIH
Data Center staff to help schedule recurring
job streams with CA-7. CA-7 is a comprehensive automated production control
system that can address the broad range of activities traditionally considered
the responsibility of computer operation’s production control team. As an
online, real-time, interactive system, CA-7 automatically controls, schedules,
and initiates jobs according to time-driven and/or event-driven activities.
In addition to CA-7,
users can access a Web-based application, Unicenter Enterprise Job Manager
(UEJM), to simplify and automate the job scheduling, monitoring, and management
functions. To use CA-7 and/or UEJM please contact the NIH Help Desk to
request this option. See Section 5.2.1.
Displaying
or Purging Batch Jobs
Use the Web-based Display or Purge Jobs facility to locate your
batch jobs and fetch the output or to purge batch jobs. Go to:
The NIH Data Center offers both
disk and tape data storage. See Section 11.1 for the hardware specifications for storage devices.
The NIH Data Center does not provide for archival storageof data. Data to be archived should be copied
to tape and permanently removed from the NIH Data Center.
·Public disk storage, also known as DASD (direct
access storage devices), is shared by all users for:
·online storage of data sets (both long-term and
short-term storage)
·scratch space (for use during the processing of
a batch job)
Backups of Titan disk data are
sent off-site on a regular schedule. See Section 4.4 for information on disaster recovery.
·Magnetic tape facilities are also
available―both for data storage at the NIH Data Center and for data
exchange with other installations. The NIH Data Center has an automatic tape
inventory system that ensures the privacy and integrity of data on tapes.
Data Set Names
On Titan, data set names (disk
or tape) must begin with either:
·a userid (userid.dataname)
or
·a Titan account (account.dataname)
Data set names that begin with an
account (e.g., account.mydata) are ideal for production work. Because they do
not belong to an individual, they do not need to be renamed if the userid is
reassigned.
RACF Profiles
Data set access, whether it is
on tape or disk, depends on having the appropriate RACF profiles in place; see
Section 4.6
for information. Any user who handles or stores personal data as defined by the
Privacy Act of 1974 has legal responsibilities for maintaining its security and
integrity. For further information, see Section 4.
There are advantages to using
direct access facilities (disk) instead of tapes:
·Several jobs can read the same data set at the
same time. A tape can be used by only one job at a time.
·Jobs accessing the data will be less expensive
because there will not be a charge to mount a tape. See Section 3.1 for specific details on costs.
The NIH Data Center operates in an
all-cataloged disk storage environment. All data sets must be cataloged, and
all references to data sets should be made through the catalog.
It is important to remember the
following:
·All disk data sets must be cataloged.
·Neither UNIT nor VOLUME should be specified when
referencing existing, properly cataloged data sets. Specify DISP=SHR and the
data set name.
·If a data set cannot be cataloged (probably
because another data set with the same name is already cataloged), the job will
fail and the data set will not be created.
Space Management of Disk Data Sets
Titan uses IBM's SMS (System
Managed Storage) and HSM(Hierarchical Storage Manager) as the primary storage
management software for data set migration and backup. See Section 10.1.1.
Public disk volumes are under the control of the SMS/HSM
environment. SMS simplifies data set allocation, provides efficient and
flexible data set management, and facilitates the transition to new disk
architectures. HSM, a part of SMS, manages data sets on groups of storage
volumes and provides backup and recovery services.
SMS
For data stored on public volumes, SMS uses management classes
to determine the following:
·how long to keep inactive data
·which data sets to back up
·how long to keep the backups after the data sets
have been scratched
·when to stage a data set to secondary storage
When
a data set is allocated—either initially or when recalled from secondary
storage—SMS selects a volume with sufficient storage space and updates the
catalog appropriately.
HSM
HSM places disk data on the most efficient media, based on size
and usage history. HSM:
·keeps new and actively used data sets on a group
of “primary” disk volumes, referred to as level 0
·moves less frequently accessed data sets onto
HSM-owned “secondary” disk volumes (called level 1) and tapes (called level 2)
·tracks where each data set resides, moving (“migrating”)
data sets off primary volumes as space is needed, and automatically “recalling”
them as they are accessed
When
a public data set is created, it is placed on one of the primary disks. As
these disks start getting full, the least active data sets are moved to
secondary volumes. When an interactive user or a batch job references a data
set on secondary storage, HSM automatically brings the data set back to one of
the primary volumes. While the data sets are on these secondary volumes, the
catalog indicates that they are on a volume named MIGRAT. Under ISPF, the
volume shown for data sets that have been migrated to compressed disk will be
MIGRAT1; the volume shown for data sets that have been migrated to tape will be
MIGRAT2.
When
data is migrated to secondary storage and recalled, the data set is reallocated
on primary storage, as follows:
·For sequential data sets with a secondary space
allocation, HSM allocates only the amount of space actually occupied by the
data, releasing any unused space and resetting the number of extensions used.
·For all other data sets, HSM allocates the total
space previously allocated, whether occupied by data or not.
·Partitioned data sets are always condensed when
recalled—moving all members to the beginning, and all unused space to the end
of the data set.
There
is no way to guarantee that a data set will remain on any particular disk
volume or that two data sets (for example, a primary and backup) will always be
on different volumes.
For management classes that
provide backup services (DISK2YR, DISK7YR, and LONGTERM), HSM creates daily
incremental backups of online data. That is, each night a backup is made of any
data set that has changed since the previous day. A data set is considered
changed—even if the data set is not actually modified—whenever the data set is:
·renamed
·opened for output
·opened for input/output
HSM's incremental backup system:
·maintains up to five unique backup versions per
data set name
·allows users to restore any data set that is
lost or destroyed to its state as of the most recent backup
·keeps backups for six weeks after the data set
has been deleted (or renamed)
All changed data sets are backed up
with the following exceptions:
·data sets with no DSORG (empty) or partitioned (PO)
data sets with zero block size
·data sets that cannot be read (damaged PDS
directory, etc.)
·data sets that are allocated with a disposition
of OLD at the time HSM is trying to back them up
Use ISMF (under ISPF, select C
for Additional Products) to:
·display a list of incremental backups for a data
set
·restore a data set from the available backups
See the Titan Batch Processing manual for more information on using ISMF.
While these backups provide a great amount of protection for user data sets, it
is not absolute. Critical data sets should be periodically saved by the user on
tape and removed from the NIH Data Center premises. See Section 4.4
for information on disaster recovery.
Web Retrieve is a data set management tool for older (pre-HSM) migrated
data sets. It can only be used for data sets begining with the userid format
aaaaiii that were created or restored before April 18, 1994. Web Retrieve
allows users to display, retreive, rename, or delete data sets in the old
mirgration system. To manage your older data sets, go to:
Figure 10‑1 summarizes the unit names that correspond to the
Titan SMS management classes (not including those specific to databases).
Figure 10‑1. Characteristics of Management Classes
Titan Management Class/Unit Name
Backups
Length of Retention
TEMP
no
7 days
NOBACKUP
no
until deleted
DISK2YR
5
2 years after last use
DISK7YR
5
7 years after last use
LONGTERM
5
until deleted
These management classes determine
which data sets are backed up and how long the data is kept.
In your JCL, you must specify
either UNIT= or MGMTCLAS=. If you specify the unit name, it will be translated
into one of the appropriate Titan management classes (shown above) to designate
how the data will be stored.
Data Set Naming Conventions
Some data set naming conventions
will assume specific management classes. That is, data sets that end with the
following suffixes will assume the stated management class:
·Disk data sets whose names end with the final
qualifier OUTLIST or SYSOUT are forced to be UNIT=TEMP.
·Disk data sets whose names end with the final
qualifiers listed below are forced to be UNIT=LONGTERM (where * is a wildcard
representing zero or more characters):
ASM
LOAD*
CLIST
OBJ
CNTL
PGM*
COB*
PLI
EXEC
PL1
FOR*
RESLIB
JCL
SCRIPT
LIB
SOURCE
*LIB
SRC
LLIB
TEXT
For example, a data set named
userid.MYSTUFF.LOAD will be set to the LONGTERM management class. A data set
named userid.MYSTUFF.OUTLIST will be set to the TEMP management class.
Data Sets Created through TSO
The default management class for
data sets created through TSO is DISK2YR. This includes all data sets created
in WYLBUR. To change the default, use one of the following methods:
·On the command line at the logon screen, include
the TSO UNITNAME command.
·Include the TSO UNITNAME command in a CLIST that
is executed from the command line at the logon screen.
·Use the WYLBUR SET VOLUME command in your WYLBUR
session.
·Include SET VOLUME (e.g., SET VOLUME LONGTERM)
in your @WYLBUR.profile.
Additional Information
The system will delete any
rolled-off GDG (generation data group) unless the expiration date has not been
reached (if one was specified). For more information, refer to the Titan Batch Processing manual.
When allocating disk data sets, it is important
to determine the best block size for the data set and the right amount of space
needed to store the data. Miscalculating the amount of space needed (via
blocks, tracks, or cylinders) or specifying a block size that is too small or
too large wastes disk space and increases storage costs. Specifying a block
size that is too small can also increase the I/O charges for the job that reads
or writes the data set.
The best way to allocate space is to allow the
system to pick the optimum blocksize. Then, if the data set has to be moved to
a new disk device with different track/cylinder architecture, it will be
automatically reblocked to a new optimum block size.
When creating data sets through
batch processing, use the AVGREC parameter if you know the approximate number
of records you expect to put in a data set and the length of the records (or
average record length for variable length records). The AVGREC parameter allows
the operating system to automatically calculate both the optimum block size AND
the space required for most physical sequential (PS) and partitioned (PO) data
sets. Refer to the Titan Batch Processing
manual.
Most Titan customer tape data
resides in the Virtual Storage Manager (VSM)―a comprehensive tape storage
system consisting of tape silos, disk buffers, new tape technology, and tape
management software that improves performance and reduces human intervention in
storing, retrieving, and mounting tapes. All VSM tapes are numbered above
500000.
Major features of the Titan tape
storage system are as follows:
·The NIH tape library contains only 3490
cartridge tapes.
·3480 tapes can only be used as foreign tapes.
There are some 3480 and 3490 tapes available for purchase. To purchase a tape,
go to:
·See Section 10.2.4 for information on foreign tape processing.
·Tape data set names must begin with a valid userid
or RACF group (account).
·Titan tapes are owned and
charged to the userid that begins the first data set name on the tape.
NOTE: to change the ownership of a tape you must copy the entire
tape, changing the data set name of at least the 1st data set on the
tape, so that it begins with the userid of the new owner.
·Tape data sets must have an expiration
date/retention period.
·Tape data set security is controlled by RACF
permissions on a data set rather than volume basis. For additional information,
see Section 4.6.
·In order to access any data set on a tape, you
must also have access to the first data set on the tape. (CIT strongly
recommends that all data sets on a tape begin with the same userid.)
·CIT recommends (but does not require) that all
Titan tape data sets be cataloged.
For More Information
Additional information concerning the use of tapes is
available from the Titan Batch Processing manual.
Removal of Tapes
Tapes in the VSM can not be
removed from the NIH Data Center. Users can copy the data from VSM tapes to
their own foreign tape or purchase a 3480 or 3490 tape from CIT to be used as a
foreign tape (see Section 10.2.5).
Titan uses the CA-1 Tape
Management System (TMS) software to maintain accountability of the tapes in the
tape library. The system records the tape serial number and the data set name
and characteristics in an internal catalog when the cartridge tape is created.
For Information on Your Tapes
·ISPF Option L.5—Manage your tapes in Titan's tape database through ISPF Option
L.5. (From the CIT/Titan Primary Option Menu, select L for Local
utilities/applications, and then select 5—TAPE.) This tape inventory facility
provides immediate feedback about the status of your tapes and allows you to:
·review tape information by either volume serial
number or data set name
·change expiration dates (You can also use the TAPEEXP batch
procedure to change the expiration date of the first data set on a tape; see
below for more information.)
·expire (scratch) a tape data set by setting the
expiration date to the current date
·expire the entire tape by setting the expiration
date of the first data set on the tape to the current date
·NOTE: Tapes don’t actually become scratch until
the morning of the next working day following their expiration dates. To
scratch a tape immediately, use the TAPEEXP batch procedure described below.
·ISPF Option 3.4—You can view information
on cataloged tape data sets by using option 3.4 of ISPF. When viewing a data
set list, type TI next to the data set name to see the volume serial number,
the size and format of the data set, plus the creation and last used
information. This data is for display only—any updates must be done through the
tape inventory panels (Option L.5).
·TAPEEXP—The TAPEEXP batch procedure
changes the expiration date for the first data set on a tape. You must have
RACF UPDATE access for the first data set. When the expiration date is reached,
the tape is scratched. TAPEEEXP also allows you to scratch a tape immediately.
If the tape is part of a multi-volume data set, you can change only the
expiration date of the first tape. When the expiration date is reached, all
tapes in the set are scratched.
TAPEEXP executes the TMSUPDTE program from Computer Associates. For more
information, refer to the Titan Batch
Processing manual.
·TAPEINFO—The TAPEINFO batch procedure
prints the status information that TMS has about a tape. The information
printed includes the data set name, expiration date, creation date, creation
time, name of the job that created the tape, name of the program that created
the tape, date last used, record format, record length, and block size. The
information is gathered in real time and is therefore valid as of the time you
run the procedure. For more information, refer to the Titan Batch Processing manual.
·VOLLIST—The VOLLIST batch procedure
finds all tapes owned by a particular userid, all tape data sets owned by a
particular userid, or all tape data sets with a particular string in the data
set name, even though they may be owned by various userids. For more
information, refer to the Titan Batch
Processing manual.
Recreating
Tape Data Sets
When recreating a data set on
a specific tape volume, the user must observe the following rules:
·For a tape with multiple data sets, only the last data set can be recreated.
·Recreation is not allowed if the data set has an
expiration date of 99365.
·The same
data set name must be used. Only when the data set name on the DD statement
matches the data set name on the cartridge tape label will the expiration date
be ignored. TMS will then allow the file to be overwritten.
·DISP=OLD must be specified. (DISP=NEW is used
exclusively for requesting a scratch volume to create a new data set or adding
a new data set to an existing tape volume).
If
either of the last two conditions is not met in recreating a data set on a
specific volume, a “scratch” volume will be used. The only indication that this
has occurred is in the JES2 Job Log at the start of the job output.
TMS ABENDs result in a system
completion code of the form xEC,
where x can be a number or a letter.
Refer to Titan Batch Processing for more information on TMS completion
codes and messages.
One abnormal situation occurs if a
scratch tape is requested for output and TMS does not accept the mounted tape
as a scratch tape. TMS issues an “IECTMS3... volser IS NOT SCRTCH (errorcode)”
message with an accompanying error code and requests another tape. If the
situation resulted from improperly coded DD statements, the job will be
terminated.
10.2.3Tape
Security
Tape security on Titan is
controlled by RACF permissions on a data set rather than volume basis. Data set
protection depends on the RACF profiles in place and applies to any data set,
regardless of whether it is on tape or disk. Users may need to modify their
RACF profiles to provide the correct level of access to tape data. In order to
have access to data sets on a tape, the user must have the proper access to the
first data set on the tape. For RACF processing on the Web, go to:
Foreign (or non-NIH) tapes are
those that are supplied by users and are not under the control of the CA-1 Tape
Management System. Foreign tapes can be used to exchange data with other
installations. Any foreign tape that conforms to Titan's normal tape standards
may be used.
The TAPEMAP utility program
displays the format of the volume, header, and trailer labels of a
standard-labeled or unlabeled tape for one or more data sets on a foreign tape.
For more information on TAPEMAP, refer to the Titan Batch Processing
manual.
Check-in Check-out Process
There is a check-in and a
checkout process for tracking foreign tapes. Foreign tapes can be checked in
for up to a week, to be returned to output boxes the Monday following check-in.
All foreign tape processing is done at the NIH Data Center’s Bethesda campus. For
information on input/output distribution services, see Section 5.6.
This section describes the equipment at the central facility for Titan and
information concerning other hardware devices used to access the central
complex.
Titan, the mainframe
component of the NIH Data Center, is an integrated computing facility composed
of multiple logical processors interconnected by over 900 volumes of shared
direct access storage and common operating system software. The processors
support 64-bit addressing and real memory. The system has a complement of
peripheral devices that includes tape drives and electrographic printing
subsystems.
Most of the peripheral devices can
be shared among logical processors or switched to one or more of the logical
processors. Many devices are also accessed through multiple data channels
within a logical processor. These capabilities allow for the minimal disruption
of service in the event of a subsystem or component failure.
A summary of the major hardware
components for Titan follows; additional information may be obtained from the IBM ESA/390 Principles of Operation,
SA22-7201 and in the various component description manuals. Refer to the
hardware and software information at the back of each issue of Interface for the current serial numbers
of the logical processors.
The
central processors may have a great variety of external devicesattached, including tape drives, disk drives,
printers, and terminals. Data going between the processor complex and the
external device passes through a logical path called a channel. Channels are
the direct controllers of all input/output devices. They provide the capability
of reading or writing data at the same time that actual computing is taking
place by relieving the processor complex of the task of communicating directly
with the device.
