My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
CRDSS_Task1_05-28_SoftwarePortabilityIssues
CWCB
>
Decision Support Systems
>
DayForward
>
CRDSS_Task1_05-28_SoftwarePortabilityIssues
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
9/25/2011 10:18:52 AM
Creation date
5/30/2008 3:38:01 PM
Metadata
Fields
Template:
Decision Support Systems
Title
CRDSS Task 1.05-28 - Study of System Integration Issues Software - Portability Issues
Description
This memorandum discusses the issues related to software portability.
Decision Support - Doc Type
Task Memorandum
Date
5/10/1994
DSS Category
DMI Utilities
DSS
Colorado River
Basin
Colorado Mainstem
Contract/PO #
C153658, C153727, C153752
Grant Type
Non-Reimbursable
Bill Number
SB92-87, HB93-1273, SB94-029, HB95-1155, SB96-153, HB97-008
Prepared By
Riverside Technology inc.
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
5
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
value at the beginning of each record. Others store the value at the end of each record. Moving such <br />files from one system to another requires "decoding" the storage format, and this information is <br />generally not well-documented. <br />The final disadvantage with binary files is that they cannot be easily edited. Consequently, if a <br />binary data file is corrupted, it cannot be edited to fix the data unless some type of special editing <br />utility is developed. ASCII files can be edited because they contain readable characters. <br />RTi recommends that binary files be used only for temporary files. However, any output that could <br />potentially be moved to different machines or that could potentially be edited by humans should be <br />ASCII format files. Some existing models that will be part of CRDSS may use binary files for <br />output such that the files cannot be easily moved and read on different machines. In such cases, a <br />study of the costs and effects of changing the file format to ASCII will be considered. It may be <br />appropriate not to change the file format. <br />3.0 CONCLUSIONS AND RECOMMENDATIONS <br />Based on the above discussion (and discussion in referenced task memoranda), the following <br />conclusions and recommendations are made: <br />Source code can be made portable by adhering to ANSI programming standards, including <br />? <br />C, FORTRAN, and draft C++ guidelines. Source code can also be compiled on different <br />platforms to verify that the code is robust. Code dependent on specific system features can <br />be managed using programming features (such as C preprocessor statements) and by using <br />make imake <br />programs such as and . <br />Graphics on UNIX workstations can be made portable by adhering to standard X Window <br />? <br />System and Motif programming guidelines. Graphics routines can be written for different <br />platforms by using a platform-independent GUI builder or GUI library (this method has not <br />been formally adopted for the CRDSS). Hard-copy graphics will use standard output <br />formats (e.g., PostScript and HPGL). <br />Data files can be made portable by avoiding system-dependent file system features (e.g., <br />? <br />use file names that will work on UNIX workstations and PCs) and language-dependent file <br />formats (e.g., use ASCII files rather than FORTRAN binary files). <br />5 <br />A275 05.10.94 1.05-28 Malers <br />
The URL can be used to link to this page
Your browser does not support the video tag.