
Accessibility & Compliance for Government
SAS works extensively with government agencies. We provide software that both meets accessibility standards and complies with all relevant regulations for software and data submissions. We also continuously strive to make it easier for government agencies to acquire SAS solutions.
Federal Government Electronic Information Technology Accessibility Standards
Section 508 of the US Rehabilitation Act of 1973, as amended, mandates that when the federal government purchases most electronic information and technology (EIT), including software applications, it must ensure that the EIT provides federal government employees with disabilities with access to and use of information or data that is comparable to the access provided to federal government employees without disabilities. Moreover, under the act, the federal government is also obligated to provide members of the public with disabilities with access to information and data that is comparable to the access provided to the public without disabilities.
SAS understands the importance of Section 508 requirements to our customers. The regulations adopted by the federal government to implement Section 508 generally require US government agencies to purchase software solutions that are most compliant with Section 508 requirements. In addition, other customers, including state governments and international bodies, increasingly require compliance with accessibility standards when making procurement decisions. Beyond the legislative compliance, SAS recognizes that universal design and accessibility are good business strategies.
SAS is committed to providing accessible software products and documentation through the ongoing evolution of its product lines. Recognizing that accessible software also provides ease-of-use, we incorporate universal design into our planning process. As we develop our products, we test them with assistive technologies and with operating system accessibility extensions to assess their compliance with applicable Section 508 accessibility criteria established by the federal government. The extent of compliance with the Section 508 accessibility criteria currently varies by product. Upon request by an eligible customer, SAS will provide information detailing the extent to which specific SAS products of interest to the customer support the applicable Section 508 accessibility criteria.
As accessibility requirements, standards and methodologies evolve, our customers can be assured that they will continue to have access to the most current product evolution made available by SAS in our efforts to meet current and future accessibility requirements for disabled users.
At SAS, our mission is to empower organizations around the world with superior software, solutions and services that give them The Power to Know®. Consistent with that mission, SAS is committed to extending The Power to Know to all of our customers.
Learn about accessible SAS Graphs
Learn More About EIT Accessibility Standards
- Contact SAS with compliance questions about specific products.
- Voluntary Product Accessibility Templates (VPAT) are available on request. Please contact your SAS sales representative, or send your request to accessibility@sas.com.
- For questions on accessible graphs, see http://support.sas.com
- Visit the Federal Section 508 website.
- Worldwide Web Consortium (W3C) Web Accessibility Initiative (WAI) – For web accessibility guidelines cited in many state and international procurement requirements, visit the Worldwide Web Consortium's (W3C) Web Accessibility Initiative (WAI) website.
Product Compliance with the Federal Desktop Core Configuration (FDCC) and the US Government Configuration Baseline (USGCB)
Effective Sept. 15, 2010, the US Government Configuration Baseline (USGCB) joined the Federal Desktop Core Configuration (FDCC) as the security configuration baseline for information technology products deployed across the federal agencies.
Evolving from the FDCC, the USGCB is designed to replace the FDCC and expands the baseline configuration guidelines to Windows 7, Windows 7 Firewall and Internet Explorer 8. Use of the FDCC checklists for Windows XP, Windows Vista, Windows XP Firewall, Windows Vista Firewall and Internet Explorer 7 remains in effect until the USGCB checklists are produced for those platforms.
The USGCB is designed to provide a single, standard, enterprisewide, managed environment for PC desktops and laptops running Windows 7.
As a vendor of desktop software products to the US federal government, SAS has evaluated SAS' applicable* desktop software products on the SAS® 9.1.3 SP4, SAS 9.2, SAS 9.3 and SAS 9.4 platforms for use with the Microsoft® Windows operating system ("Desktop Software") for conformance to the FDCC/USGCB security configurations developed and issued by the National Institute of Standards and Technology (NIST) for Windows 7 and Windows XP VHDs. NIST issues these configuration guidelines in response to US Office of Management and Budget Memorandum M-07-18 dated June 1, 2007, on the subject of Ensuring New Acquisitions Include Common Security Configurations.
Based on testing with a Security Content Automation Protocol (SCAP)-validated product, SAS verified that our Desktop Software operates in substantial conformance with SAS' current user documentation for such Desktop Software on desktop machines running Windows 7 and Windows XP operating systems (each a "Standardized FDCC/USGCB Desktop"), and runs on the Standardized FDCC/USGCB Desktop substantially in accordance with the FDCC/USGCB guidelines, provided that the Standardized FDCC/USGCB Desktop has been properly configured to implement the FDCC/USGCB guidelines. Our product-by-product testing continues to verify:
Customers' normal end users will not require elevated system administration privileges to run Desktop Software on a Standardized FDCC Desktop, where normal end users are indicated in SAS' current user documentation for such Desktop Software.
Standard installation, operation, maintenance, update and/or patching of such Desktop Software in accordance with SAS' current user documentation for such Desktop Software will not materially alter the Standard FDCC Desktop settings from the FDCC guidelines.
SAS has incorporated FDCC/USGCB validation testing into our due diligence process for products marketed to the US federal government. As NIST releases updated versions of the VHDs, SAS will incorporate the latest security checks into our validation testing.
For additional information, please contact fdcc.sas@sas.com.
*See Attachment A hereto for a list of SAS desktop software products that were not evaluated under FDCC guidelines.
NOTICE: This information is provided by SAS Institute Inc. for information purposes only and may be changed by SAS at any time without notice. SAS makes no representations of warranties concerning this information. SAS' only warranty or other obligations to Customer with respect to a SAS product shall be as set forth in any applicable licensing documents. SAS and all other SAS Institute Inc. product and service names are registered trademarks or registered trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are registered trademarks or trademarks of their respective companies.
27AUG2013
Attachment A
SAS opted not to test the following desktop software products either because the product is legacy software not offered on/for the SAS 9.2, SAS 9.3 or SAS 9.4 platforms, the product transparently provides functionality available to the desktop user, or the product is not used on federal desktops.
- SAS® AppDev Studio™
- SAS® Data Surveyor for Oracle Applications
- SAS® Data Surveyor for PeopleSoft
- Design Time Controls
- SAS® Drug Development
- Enterprise Reporter® software (Businessview)
- SAS/ACCESS® Interface to BAAN
- SAS/ACCESS® Interface to Teradata
- SAS/ACCESS® Interface to ODBC
- SAS/ACCESS® Interface to Oracle Rdb
- SAS/ACCESS® Interface to SAP BW
- SAS/ACCESS® Interface to SYSTEM 2000
- SAS/ACCESS® Interface to ADABAS
- SAS/ACCESS® Interface to DATACOM/DB
- SAS/ACCESS® Interface to DB2
- SAS/ACCESS® Interface to CA IDMS™
- SAS/ACCESS® Interface to IMS-DL/I
- SAS/ACCESS® Interface to INFORMIX
- SAS/ACCESS® Interface to Oracle
- SAS/ACCESS® Interface to PC Files
- SAS/ACCESS® Interface to R3
- SAS/ACCESS® Interface to SYBASE
- SAS/ACCESS® Interface to OLE DB
- SAS/CALC®
- SAS® Web OLAP Viewer for .NET (on SAS 9.1.3 SP4, not available on SAS 9.2/SAS 9.3)
- SAS® Simulation Studio
- Locale Setup Manager
- SAS® Migration Utility
- SAS® In-Database for Teradata
- SAS Online Doc® for the Web
- SAS Online Doc® for Windows
- SAS® Risk Reporting Repository
27AUG2013
IPv6 Statement of Position
IPv6 Support – US Government Regulation requiring for Internet Protocol Version 6 (IPv6)
May 05, 2009, Abstract: All major US federal government agencies' infrastructure (network backbones) have migrated to using IPv6, and all agency networks are able to interface with this infrastructure effective June 2008. The US Government Chief Information Officers require that all new IT procurements be IPv6-compliant. An IPv6-compliant product or system must be able to receive, process and transmit or forward (as appropriate) IPv6 packets, and should interoperate with other systems and protocols on both IPv4 and IPv6 modes of operation.
Key Business Issues:
The continuous growth of the global Internet requires that the architecture evolve to accommodate new technologies that support increasing numbers of users, Internet hosts, services and applications. Internet Protocol Version 6 (IPv6) IPv6 (http://www.ipv6forum.com/, http://www.ipv6tf.org/, http://www.gogo6.com/), or IP Next Generation (IPNG), is the successor to the existing Internet addressing protocol, IPv4, and enables the continuing expansion of Internet technologies. In addition to expansion of the Internet address range, IPv6 includes designed security and privacy enhancements, dynamic auto-configuration semantics and quality of service enhancements for optimized throughput services. There are a number of implementation, migration and coexistence issues that will affect hardware and software vendors' deployment of IPv6.
Position:
- Factors that may inhibit IPv6 conversion:
- Significant infrastructure costs to migrate hardware and software to IPv6.
- Limited selection of IPv6-capable security and management products.
- Network Address Translation (NAT) and VPN semantics mitigate some IPv4 limitations and restrictions.
- Secure Sockets (SSL) is prevalent throughout Internet services, which negates some of the advantages of IPSec in IPv6.
- Stricter control of IPv4 addresses and classless inter-domain routing will conserve IP address ranges.
- Conversion strategies are well-defined and can be adopted at a measured rate.
- Factors that may accelerate IPv6 conversion:
- Recent projections estimate the exhaustion of IP addresses in the 2011-2012 time frame.
- The major hardware and software vendors support IPv6 semantics in network devices and operating systems.
- The US Department of Defense (DoD) mandate that resulted in IPv6 being in place and that all IT product acquisitions be IPv6 enabled.
- Effective January 2009, the Defense Information Systems Agency (DISA) added IPv6 testing to its regular IT product evaluation process required by the DoD.
- As of June 2008, all the major federal agencies' network backbones were IPv6-enabled.
- Much of the current US Federal IPv4 infrastructure is IPv6 capable, with approximately one-third of the deployed desktop systems IPv6 capable.
- The US government is encouraging all federal agencies to move forward with IPv6 integration as part of their enterprise architecture planning.
- Europe, Japan and other Asian countries have IPv6 roadmaps in place.
- Features of this new protocol include:
- Expanded address ranges.
- Efficiencies in routing.
- Integrated IPSec semantics.
- Improved quality of service.
- IPv6 adoption by operating system vendors that SAS supports include Microsoft, HP, IBM and Sun. Infrastructure vendors, such as Cisco, have also announced support for this technology.
Bottom Line:
Many governments have already moved to, or are mandating, IPv6 compliance within the next 12 to 18 months. Additionally, Internet hardware vendors and operating system vendors are now actively supporting IPv6. SAS implemented support for IPv6 beginning with SAS 9.2.
FDA and SAS Technology
The Food and Drug Administration (FDA) expects clinical and nonclinical data submitted as part of an NDA or BLA to be in SAS v5 transport format, described in the FDA's "Study Data Specification."
To request more information, please contact Joseph.Boland@sas.com.
The links below provide information on using the SAS XPORT transport format to submit data sets to the FDA. Specifications for the XPORT format are provided in TS-140 so that it is not necessary to use SAS software to translate data sets to/from this format.
Check out the FDA's Electronic Records; Electronic Signatures compliance documents
FDA Standards for Electronic Submissions
The Electronic Records; Electronic Signature Rule (21 CFR Part 11), or "the Esig rule," is the US law that gives the FDA the authority to identify types of submissions that the agency will accept in electronic form. The Esig rule also states that persons should consult the agency for details on how to proceed with electronic submissions. Such details include method of transmission, media, file formats and technical protocols. The FDA issues guidance documents to reduce the need to consult for details.
In January 1999, the FDA's Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER) issued a joint guidance on general considerations for electronic submissions, entitled Providing Regulatory Submissions in Electronic Format – General Considerations. The guidance describes the use of the SAS System XPORT format for electronic data sets.
The FDA plans to issue a series of guidance documents that will focus on specific submission types. The first of this series was issued in January 1999, when CDER issued a guidance on NDAs, entitled Providing Regulatory Submissions in Electronic Format – NDAs.
Q&A
Q: There are two SAS transport file formats. Which one is the FDA prepared to use?
A: FDA can accept data in the SAS XPORT Transport Format that is processed by the XPORT engine in Version 6 of SAS software and later, and by PROC XCOPY in Version 5.
Q: What are the two SAS transport formats?
A: The XPORT Transport Format selected by the FDA, and the CPORT Transport Format. Both XPORT and CPORT are established mechanisms for data exchange that are well tested and well documented. They are not new or at-risk technology. The XPORT Transport Format is supported on all platforms and releases of the SAS System (it is machine and release independent) from Version 5 on. The CPORT Transport Format was invented in Version 6 and is supported from Version 6 on.
Q: Why did the FDA choose the XPORT Transport Format over CPORT Transport Format?
A: XPORT is an open format, while CPORT is a proprietary format.
Q: What do you mean, the XPORT format is "open"?
A: Specifications for the XPORT transport format are in the public domain. Data can be translated to and from the XPORT transport format to other commonly used formats without the use of programs from SAS Institute or any specific vendor.
Q: Where are specifications for the XPORT transport format published?
A: At support.sas.com, under Technical Support, Technical Document TS-140.
Q: Why does the FDA want an open format?
A: By US law, the FDA must remain "vendor neutral." The FDA cannot endorse or require use of any specific vendor's product.
Q: What is the XPORT transport format, generally?
A: It is a text file, with record length = 80 columns. It looks and feels so much like a text file that it is a good idea to avoid using ".txt" as a file name extension so that the operating system won't treat it as a text file.
Q: Are there any naming conventions for transport files?
A: Beginning with Version 6, the process of installing SAS on a PC automatically registers two filename extensions to MS Windows. This means PCs on which SAS software has been installed will recognize a file named *.stx as a SAS System Xport Transport File and a file named *.stc as a SAS System Cport Transport File.
Q: Does ".xpt" work for an XPORT filename extension?
A: This is a popular extension that works fine with the SAS System and is supported by JMP, the SAS System Viewer, and soon will be supported by the UODBC driver.
Q: How does the XPORT transport format store numeric data?
A: The canonical transport format for floating point numbers in XPORT format is the IBM mainframe machine double precision format.
Q: Isn't the IBM mainframe format antiquated? Why would FDA want to use an old format?
A: The numeric representation of data in a data interchange format is the "lowest common denominator" for transferring data across different hardware and operating systems. For many years, people have been using the "lowest common denominator" provided by the XPORT transport format because it provides a reliable method for data interchange.
Q: Do variable lengths remain stable in the XPORT transport format?
A: Variables that are two bytes long get converted to three bytes on operating systems that have a minimum variable length of three bytes (OpenVMS and some others). While this will not present a problem with browsing the files, it could cause a SAS program error if program logic is based on two bytes. This will be a problem only if a sponsor submits SAS programs with the data – which is likely. We would like to suggest that three bytes be used as a minimum variable length. This assures portability across operating systems.
Q: CPORT has been updated in Version 7 to take advantage of the new V7 data set features. Will FDA adopt the CPORT transport format as a new standard for data archival in order to take advantage of the new features?
A: No, because the CPORT format will not be a public format. There are security issues with password protected data sets. It is not clear how to maintain the security that passwords provide and still document the format of the file.
Q: Does Version 7 SAS software maintain compatibility with the XPORT transport format?
A: Yes, SAS software maintains compatibility with the XPORT transport format in Version 7.
Q: SAS users may want to use Version 7 features like long variable names. As computer systems evolve, new standards for numeric representation will continue to emerge. Will the FDA update their standard for data archival as technology advances?
A: If the FDA would like to create an updated transport format SAS Institute will be willing to work with the FDA to develop a new standard. Updating the transport format could allow for new functionality such as long variable names. The new standard could involve a different format for numeric representation (or "lowest common denominator") such as IEEE numeric representation.
Q: Does the XPORT transport format have any year 2000 problems?
A: There are no year 2000 problems so far as the data itself. The header record contains only two spaces for the year, and that can be a cosmetic problem.
The layout of the header record for a transport library dates back to version 5. The version 5 format has 2 date fields in it (date time created and date time modified). The date time modified is ignored by the system (since you cannot update a transport library). The date time created is displaced by utilities (like PROC CONTENTS).
Since no transport file could have been created before 1980, Version 7 will assume that any 2 digit year between 80 and 99 has a century of 19 and any date between 00 and 79 will have a century of 20. This assures that version 7 will always display the correct century for the date time created on a transport file.
Version 6 does have a cosmetic year 2000 problem reading transport files. In version 6, the value of the yearcutoff option will determine how the version 6 system displays the date time created from a transport file. This bug will not prevent the V6 system from processing the file. It could mean, however, that reports (like PROC CONTENTS) could show that the file was created in the wrong century.
This file format does not have a year 2000 problem until the year 2080.
Q: Does the XPORT transport format retain variable labels?
A: Yes.
Q: Does the XPORT transport format retain variable formats?
A: Formats of individual variables are retained in the XPORT transport format.
Q: What about custom formats that are not provided with SAS software?
A: Assigning a format to a variable associates text or numbers with variable values. As an example, the variable GENDER could have two possible values, 1 or 2. A format named GENDRFMT can be associated with GENDER so that the text "Male" appears on the computer screen or on paper when GENDER = 1 and "Female" appears when GENDER=2. Custom formats like GENDRFMT can be created and stored in a format catalog.
It is important to be able to archive custom variable formats along with the data. It is possible to do this with the XPORT transport format. The format catalog must be saved as a SAS data set, and the resulting data set can be saved in XPORT transport format along with corresponding data sets. When data sets are extracted from transport format, the data set containing the custom formats can be saved as a format catalog. Thus, variable formats can be archived and retrieved along with the corresponding data.
Q: Is it difficult to detect the end of file when reading a data set stored in XPORT transport format?
A: Under certain circumstances it is difficult to detect the end of file when reading a data set in XPORT transport format. Below is an explanation and a suggested fix that will alleviate the problem.
The problem occurs when the record length of a file is less than 80 characters. The transport format writes 80 byte records. The last observation may not fill up an 80 byte record. When this happens the SAS System will pad the 80 byte record with blanks. When reading a transport file, the SAS System treats trailing blanks as insignificant. If the records are shorter than 80 bytes and if the last record written contains nothing but blank characters then the file comes up one record short.
The key to avoiding this potential problem is to undertake preventative measures described below.
One preventative measure could be to make sure that the circumstances do not exist. Avoid creating a data set where:
- The observation length (the sum of the variable sizes) is less than 80 and
- The variables are all character and
- The last record has all blank values.
Another preventative measure could be to save original data in transport format, extract new data from the transport file, then run PROC COMPARE to compare the original data to the new data. Output from PROC COMPARE can validate that the new data extracted from the transport file is identical to the original data.
Q: Are there rounding problems when using the XPORT transport format to move data across hardware platforms or operating systems?
A: Numeric representation is an issue in any computer application because of hardware limitations. Any particular hardware configuration can only represent a finite amount of numbers. The real number system is infinite and there is no way to represent each one of the real numbers in a unique way with currently available hardware.
It is obvious that extremely large and extremely small numbers cannot be represented with a finite amount of numbers. It is less obvious why representing fractions can be a problem. To illustrate the problem with fractions, consider the following example. The fraction 2/3 cannot be represented in our base 10 number system as a decimal fraction with a finite amount of numbers. We write 2/3 as 0.666..., where "..." represents an infinite series of sixes after the decimal. To represent 2/3 as a decimal fraction with a finite amount of numbers, rounding or truncation must occur. That is the nature of a problem that occurs in representing fractions on computers.
The SAS System and most computers use floating-point representation to store numeric values. All platforms on which the SAS System runs use 8 bytes for floating-point numbers.
Floating-point representation is an implementation of what is generally known as scientific notation, in which values are represented as numbers between 0 and 1 times a power of 10. Using scientific notation, the basic parts of a floating-point number can be identified as the mantissa or fraction portion, the base, and the exponent.
Different computers can have different specifications for floating-point representation. Table 1 summarizes various representations of floating-point numbers that are stored in 8 bytes. The canonical transport format for floating point numbers in SAS transport format is the IBM mainframe machine double precision format.
Table 1. Summary of Floating-Point Numbers Stored in 8 Bytes
Representation | Base | Exponent Bits | Maximum Mantissa Bits |
IBM mainframe16756 | 16 | 7 | 56 |
VAX/VMS | 2 | 8 | 56 |
AOS/VS | 16 | 7 | 56 |
PRIMOS | 2 | 16 | 47 |
IEEE | 2 | 11 | 52 |
Differences in specifications for floating-point representation may cause a loss of precision or magnitude/range when data are moved from one platform to another. The more bits that are reserved for the mantissa, the more precise the number, and the more bits that are reserved for the exponent, the more magnitude the number can have.
As an example of differences in precision, the IBM representation reserves more bits for the mantissa than the IEEE, and this provides the IBM format more precision than the IEEE format.
Differences in floating-point representation on different platforms may be an issue, but should not be a problem when the differences are known and accounted for in software applications. The XPORT transport format is published, and the file specifications are readily available on SAS Institute's external web. Knowing the format for floating point numbers in SAS transport format makes it possible to allow for and minimize the effect of differences in floating-point representations.
SAS Macros that Convert a Directory of Transport Files
This is a set of SAS macros that converts a directory of transport files to a directory of SAS data sets and format catalogs (and vice versa). To see how to invoke the macros, look at the test following the last macro. The macros make the assumption that transport files created from data sets have the extension .xpt, and transport files created from format catalogs have the extension .xpf.
/*----------------------------------------------------------------*/ /* This macro will convert an existing format catalog into a */ /* CNTLOUT= data set in transport format. The parameters are: */ /* */ /* %expfmts(fmtlib,outfile); */ /* */ /* where */ /* */ /* fmtlib Name of format catalog. If only one */ /* level is given, it is assumed that this */ /* is a libref and the catalog name is */ /* FORMATS. */ /* outfile Filename that will contain the transport */ /* file. */ /* */ /* Note that the macro will first create a temporary CNTLOUT= */ /* data set, then examine it for variables that are not necessary */ /* for the final transport file. This is done to reduce the size */ /* of the transport file. */ /*----------------------------------------------------------------*/ %macro expfmts(fmtlib,outfile); *-----first create the CNTLOUT= data set from the catalog------------*; proc format library=&fmtlib cntlout=work.temp; run; *-----determine variables not needed for the final transport file----*; data _null_; set temp end=eof; nend+(end^=start); * START/END must be different ; nfuzz+(fuzz^=1e-12 and fuzz^=.); * FUZZ must be non-default ; if type='P' then do; * For PICTURE formats: ; nprefix+(prefix^=' '); * nonblank prefix ; nmult+(mult^=.); * multiplier specified ; nfill+(fill^=' '); * nonblank fill ; nnoedit+(noedit=1); * NOEDIT specified ; end; nsexcl+(sexcl='Y'); * start exclusion specified ; neexcl+(eexcl='Y'); * end exclusion specified ; nhlo+(hlo^=' '); * high/low/other etc. specd ; if eof; length todrop $200; *-----build a DROP= option for all pertinent variables----------*; if ^nend then todrop=trim(todrop)||' '||'END'; if ^nfuzz then todrop=trim(todrop)||' '||'FUZZ'; if ^nprefix then todrop=trim(todrop)||' '||'PREFIX'; if ^nmult then todrop=trim(todrop)||' '||'MULT'; if ^nfill then todrop=trim(todrop)||' '||'FILL'; if ^nnoedit then todrop=trim(todrop)||' '||'NOEDIT'; if ^nsexcl then todrop=trim(todrop)||' '||'SEXCL'; if ^neexcl then todrop=trim(todrop)||' '||'EEXCL'; if ^nhlo then todrop=trim(todrop)||' '||'HLO'; if todrop^=' ' then todrop='DROP='||todrop; *-----emit the requested DROP= option---------------------------*; call symput('dropopt',trim(todrop)); run; *-----provide a LIBNAME statement for the specified file-------------*; libname yyy xport "&outfile."; *-----create the transport file, dropping appropriate variables------*; data yyy.formats; set temp(&dropopt.); run; *-----clear the libref now that the file is written------------------*; libname yyy clear; *-----ensure the temporary data set is deleted-----------------------*; proc datasets dd=work; delete temp; quit; %mend; /*----------------------------------------------------------------*/ /* This macro will convert an existing SAS data set into a */ /* transport file. The parameters are: */ /* */ /* %expdset(dataset,outfile); */ /* */ /* where */ /* */ /* dataset Name of SAS data set (one- or two-level) */ /* outfile Filename that will contain the transport */ /* file. */ /*----------------------------------------------------------------*/ %macro expdset(dataset,outfile); libname yyy xport "&outfile."; data _null_; i=index("&dataset.",'.')+1; memname=scan(substr("&dataset.",i),1,' .'); call execute('data yyy.'||memname||"; set &dataset.; run;"); run; libname yyy clear; %mend; /*----------------------------------------------------------------*/ /* This macro will convert a transport CNTLOUT data set into */ /* a native format catalog. The parameters are: */ /* */ /* %impfmts(xpffile); */ /* */ /* where */ /* */ /* xpffile Name of transport CNTLOUT data set */ /* */ /* The macro will create the formats in LIBRARY.FORMATS. It */ /* assumes that the libref LIBRARY has already been defined. */ /*----------------------------------------------------------------*/ %macro impfmts(xpffile); libname xxx xport "&xpffile."; proc format library=library.formats cntlin=xxx.formats; run; libname xxx clear; %mend; /*----------------------------------------------------------------*/ /* This macro will convert a transport data set into a native SAS */ /* data set. The parameters are: */ /* */ /* %impdset(xptfile); */ /* */ /* where */ /* */ /* xptfile Name of transport data set */ /* */ /* The macro will create the native SAS data set in the directory */ /* defined by the libref LIBRARY, which it assumes has already */ /* been defined. */ /*----------------------------------------------------------------*/ %macro impdset(xptfile); libname xxx xport "&xptfile."; proc copy in=xxx out=library; run; libname xxx clear; run; %mend; /*----------------------------------------------------------------*/ /* This macro will create a SAS data set consisting of a variable */ /* called FILENAME. There will be one observation for each file */ /* in the specified directory with the specified extension. The */ /* parameters are: */ /* */ /* %getnames(dataset,directry,extensn); */ /* */ /* where */ /* */ /* dataset Name of SAS data set to create */ /* directry Directory to find files */ /* extensn Specified extension to look for */ /* */ /*----------------------------------------------------------------*/ %macro getnames(dataset,directry,extensn); filename xxx pipe "&dircmd. &directry.&delim.*.&extensn."; data &dataset.; infile xxx length=l; length filename $200; input @; input @1 filename $varying200. l; if index(filename,"&delim.")=0 then filename="&directry.&delim."||filename; keep filename; run; filename xxx clear; %mend; /*----------------------------------------------------------------*/ /* This macro will determine the proper directory command and */ /* delimiter. For UNIX, the command is ls -1, and the delimiter */ /* is a forward slash. For PC, the command is dir/b, and the */ /* delimiter is a backslash. */ /*----------------------------------------------------------------*/ %macro dirdelim; %global dircmd delim; data _null_; *-----determine if we are on UNIX-----*; unix = "&sysscp" in ('RS6000 ', /* AIX */ 'SUN 4 ', /* Solaris I and II */ 'HP 800 ', /* HP-UX */ 'DEVHOST ', /* SAS Institute Internal */ 'ALXOSF ', /* Digital UNIX */ '386 ABI ', /* Intel ABI */ 'MIPS ABI' /* MIPS ABI */ ); *-----determine if we are on a PC-----*; PCX = "&sysscp" in ('OS2','WIN','WIN_NTSV'); *-----if on UNIX, use ls -1 and forward slash delimiter-----*; if unix then do; dircmd='ls -1'; delim='/'; end; *-----if on PC, use DIR/B and backslash delimiter-----*; else if pcx then do; dircmd='DIR/B'; delim='\'; end; *-----otherwise not supported-----*; else do; abort abend 999; end; *-----save macro variables for command and delimiter-----*; call symput('dircmd',trim(dircmd)); call symput('delim',delim); run; %mend; /*----------------------------------------------------------------*/ /* This macro will create native SAS data sets in the specified */ /* directory, using transport files from another directory. The */ /* transport files include those with .xpf extensions and .xpt */ /* extensions. .xpf files are transport versions of CNTLOUT= data */ /* sets from PROC FORMAT. These will be read into PROC FORMAT via */ /* the CNTLIN= option. The .xpt files are regular transport data */ /* sets that may refer to formats in the .xpf files. Therefore, we*/ /* use the LIBRARY libref and use LIBRARY.FORMATS as the format */ /* catalog to ensure that the catalog is searched. (The FMTSEARCH=*/ /* option, by default, references LIBRARY.FORMATS as a catalog to */ /* search in). The parameters are: */ /* */ /* %fromexp(indir,outdir); */ /* */ /* where */ /* */ /* indir directory containing transport files */ /* outdir directory to contain SAS data sets */ /*----------------------------------------------------------------*/ %macro fromexp(indir,outdir); %dirdelim; *-----establish LIBRARY libref for output directory-----*; libname library "&outdir."; *-----obtain the names of the transport files for data sets-----*; %getnames(xptfiles,&indir,xpt); *-----obtain the names of the transport files for formats-----*; %getnames(formats,&indir,xpf); *-----invoke the %impfmts macro for each format transport file-----*; data _null_; set formats; call execute('%impfmts('||trim(filename)||');'); run; *-----invoke the %impdset macro for each data set transport file---*; data _null_; set xptfiles; call execute('%impdset('||trim(filename)||');'); run; *-----clear LIBRARY libref now that we are done-----*; libname library clear; %mend; /*----------------------------------------------------------------*/ /* This macro will create transport files in the specified */ /* directory, using native SAS data sets from another directory. */ /* Regular SAS data sets will be converted to transport files */ /* with the .xpt extension, and format catalogs will be converted */ /* to transport data set representations of their corresponding */ /* CNTLOUT= data sets, using the .xpf extension. */ /* */ /* %fromexp(indir,outdir); */ /* */ /* where */ /* */ /* indir directory containing SAS data sets */ /* and format catalogs */ /* outdir directory to contain transport files */ /*----------------------------------------------------------------*/ %macro toexp(indir,outdir); *-----use dictionary.members to get all member names---------------*; libname library "&indir."; proc sql; create table names as select memname, memtype from dictionary.members where libname = 'LIBRARY'; quit; %dirdelim; *-----generate %expfmts or %expdset calls for proper members-------*; data _null_; set names; if memtype='CATALOG' then do; macro='%expfmts'; ext='xpf'; end; else do; macro='%expdset'; ext='xpt'; end; call execute(macro||'(LIBRARY.'||trim(memname)||','|| "&outdir.&delim."||trim(memname)||'.'||ext||');'); run; *-----delete WORK.NAMES now that we are done-----------------------*; proc datasets dd=work; delete names; quit; *-----clear the libref now that we are done------------------------*; libname library clear; %mend; *==================END OF MACRO SET================================*; *--------------UNIX test of macros---------------------------------*; options macrogen mlogic mprint; *-----create fresh directories for testing-------------------------*; x 'rm -Rf /tmp/fdatest 1> /dev/null 2> /dev/null'; x 'mkdir /tmp/fdatest 1> /dev/null 2> /dev/null'; x 'rm -Rf /tmp/fdatestx 1> /dev/null 2> /dev/null'; x 'mkdir /tmp/fdatestx 1> /dev/null 2> /dev/null'; *-----create format library and test data sets---------------------*; libname library '/tmp/fdatest'; proc format library=library.formats; value abc 1='yes' 2='no'; value $grade 'A'='great' 'B'='almost great' 'C'='average'; run; data library.temp1; x=1; y='A'; format x abc. y $grade.; run; data library.temp2; x=2; y='B'; format x abc. y $grade.; run; libname library clear; *-----create transport files from the directory--------------------*; %toexp(/tmp/fdatest,/tmp/fdatestx); run; *-----reset original SAS data set directory-----------------------*; x 'rm -Rf /tmp/fdatest 1> /dev/null 2> /dev/null'; x 'mkdir /tmp/fdatest 1> /dev/null 2> /dev/null'; *-----recreate original SAS data sets and format catalog-----------*; %fromexp(/tmp/fdatestx,/tmp/fdatest); *-----verify that all is restored properly-------------------------*; libname library '/tmp/fdatest'; proc contents data=library._all_; run; data _null_; set library.temp1; put _all_; run; data _null_; set library.temp2; put _all_; run; libname library clear; |
The Record Layout of a Data Set in SAS Transport (Xport) Format
This information is available on the support site as a PDF.
SAS System Viewer Included in FDA Guidance Recommendations
In the FDA's general guidance for electronic submissions, the SAS System Viewer is listed as one of the tools used by the agency to view SAS XPORT transport files and SAS data sets directly. The Viewer allows a user to view files without invoking the SAS System or having any other SAS System software installed.