CAC Customer Newsletter

Sequence Number 0035

Oct 17, 1997

Stratus Computer, Inc
55 Fairbanks Blvd
Marlboro MA 01752

The information in this document is subject to change without notice.

Stratus Computer, Inc. makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. This document contains proprietary information that is protected by copyright. All rights are reserved.

Stratus, the Stratus logo, FTX, Continuum, SINAP, XA, StrataLINK, and StrataNET are registered trademarks and RADIO, RADIO Cluster, the RADIO logo, SCEnic, Selectable Availability, Continuous Processing, RSN, XA/R, SQL/2000, Isis, the Isis logo, Isis Distributed, Isis Distributed Systems, Active Replication, HealthLine, are trademarks of Stratus Computer, Inc.

ON/2, ON/X, and Shared Systems are registered trademarks and S2, Electronic Windows, and Network Express are trademarks of S2 Systems, Inc.

TCAM is a trademark of TCAM Systems, Inc.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.

Hewlett-Packard, HP, and HP-UX are trademarks of Hewlett-Packard Company.

Microsoft, the Microsoft Solutions Provider logo, Windows NT, and Windows NT Server are registered trademarks and BackOffice is a trademark of Microsoft Corporation.

All other trademarks and registered trademarks are the property of their respective holders.

COPYRIGHT (c) 1997 Stratus Computer, Inc. All Rights Reserved.



The CAC Newsletter is a publication of the Stratus Customer Assistance Center. Its purpose is to distribute information to the users of Stratus software and hardware. This newsletter answers commonly asked questions, gives interesting tips and techniques, and tracks software and documentation availability. The overall intent of this newsletter is to provide answers before the questions are asked and to clarify often misunderstood areas.

At times, the CAC Newsletter might refer to subroutines, commands, and options of the system that do not appear in released Stratus documentation. These are support tools and interfaces that are provided primarily for use by Stratus personnel and are subject to change or removal without notice. Appearance in this newsletter of such an item does not imply any committent for future support by Stratus.

Comments and/or suggestions for future articles should be sent to the Stratus Customer Assistance Center via Remote Service Network mail addressed to: CAC Newsletter Editor.

Online copies of past issues of the CAC Newsletter can be found in the directory (master_disk)>system>doc of most systems.

This edition of the CAC Newsletter was edited and prepared by the VOS Product Support Group of Americas Customer Services.

This edition of the CAC Newsletter is in memory of Wesley J. Lowder, manager of the communications department in Americas Customer Service 1992 - 1997. Wes passed away on May 7, 1997 after a brief illness.

1 Battery Life

If you have ever had the misfortune of suffering through a "brown out" or powerfailure at your site, you already know how important a successful powerfail ridethrough is to your application. But, are you aware that the life of the battery in Bulk Power Supplies and even some Calendar Clock cards can be limited?

Battery life for batteries will vary from site to site depending on the power loading and on the number of deep discharge powerfails the battery has delivered.

For example, with the BA-000011 battery assembly used in the AA-E222XX Bulk Power Drawers (for XA/2000 and XA/R-Series modules), there are no guarantees that after 5 years the battery can survive the 6 second high current discharge required during powerfail ridethrough.

The increase in internal impedance of the battery is the greatest factor in determining battery life. While in this state, the battery will charge properly and give no indication of wear. This is also what makes it difficult to predict battery life and to measure its capacity.

The current condition of a battery within most Field Replaceable Units (FRUs) cannot be readily determined. For the Power Supply Units the battery condition can be checked by performing powerfail testing. However this may not be an option for all customers. There are also some outward indications of a faulty battery:

o Battery is in charging mode for more than 30 hours.

o Battery Good light not "ON" after 24 hours.

o Sys_Error logs during powerfail indicate half of the CPU cardcage boards failed during ridethrough. This would be the case if one Bulk had a bad battery.

o Bulk Power Drawer does not start up after it has been in storage. The unit probably has a depleted battery and was allowed to fully discharge.

The tables below with FRUs and their expected battery life is a good indication for battery replacement. Most FRUs currently in the field have a battery date label. For any FRU without this label, the age of the battery will have to be determined by the date the FRU was installed.

     FRU Part No. Model Description                                     
     ============ ===============================================
     AS-E20200-SX 40-Slot (Non-TUV) XA400/440, XA600, XA2000 
     AS-E21200    40-Slot XA2000 Model 100, 110-160, 200, 210-260      
     **The next 2 parts can both be found in 8/12/28-Slot Cabs.
     AA-E22200    8/12/28-Slot XA/R 5, R10, R15, R20, R25, R35, 
     AA-E22230            R45, R55, R300, R305, R310, R320, R330
     AA-E22250    40-Slot (with Tone) XA/2000    
     AA-E30001    10-Slot XA2000 Model 50, 70, 75, 80  
     AA-E30031    10-Slot XA/R 20                       
     AA-E31120    IOP Expansion Cabinet Power Control Module         
     AA-E50200    6-Slot, XA2000 Model 30 (Nimbus)      
     AA-K10300    IOA, RSN Console\Clock Card           
     AA-K10301    IOA, RSN Console\Clock Card           
     AA-C10500    C100/C200 RSN/Calendar Card  
     AA-000005    20-Slot, FT200                        
     AA-P22300    Continuum 600/1200 Battery String (4)     
     AA-B65000    D650/651 Disk Battery

FRU Part No. Description Batt Life ============ ===================================== ========= AS-E20200-SX POWER SUPPLY, 40Slot, (NON-TUV) 3 YEARS AS-E21200 POWER SUPPLY, 40Slot 3 YEARS AA-E22200 POWER SUPPLY,2500 WATT,8/12/28/40 SLOT 5 YEARS AA-E22230 POWER SUPPLY,2500 WATT,8/12/28/40 SLOT 5 YEARS AA-E22250 POWER SUPPLY, 40Slot, (with Tone) 5 YEARS AA-E30001 DC BULK POWER SUPPLY, 10 SLOT 3 YEARS AA-E30031 DC BULK POWER SUPPLY, 10/12 SLOT 3 YEARS AA-E31120 IOP-EXP, POWER CONTROL MODULE 3 YEARS AA-E50200 6SLOT, POWER SYSTEM & CONTROL 3 YEARS AA-K10300 IOA, RSN CONSOLE\CLOCK 4 YEARS AA-K10301 IOA, RSN CONSOLE\CLOCK 4 YEARS AA-C10500 COMM,PCB,C100/C200 RSN/CALENDAR CARD 13 YEARS AA-000005 20 SLOT BATTERY UNIT 3 YEARS AA-P22300 POWER, 4 BATTERY STRING, 600/1200 7 YEARS AA-B65000 BATTERY, D650/651 DISK BATTERY 3 YEARS

NOTE: The AA-K11800 and AA-E59300 contain a hybrid capacitor/battery, which does NOT decay over time and therefore do NOT require pro-active replacement.

FRU Battery Date Label Location ============ ============================================== AS-E20200-SX None AS-E21200 Front (since rev 55) AA-E22200 Front AA-E22230 Front AA-E22250 Front AA-E30001 Top (unit needs to be removed) AA-E30031 Top (unit needs to be removed) AA-E31120 Front (since rev 3) AA-E50200 None AA-K10300 Board Edge near connectors (since rev 28) AA-K10301 Board Edge near connectors AA-C10500 None AA-000005 None AA-P22300 Side (unit needs to be removed) AA-B65000 Front

The tables above, along with your records, are intended to be used as a guideline to determine if you should start making plans for battery replacement. Please note that batteries are cabinet dependent. Your local Field Engineer or the CAC can best determine the condition of the batteries on your Stratus system.

[Remco van der Braak/Kevin Dorer]

2 Year 2000

Running VOS Applications Successfully through the Year 2000

There is a lot in the news lately about the problems expected in computer systems and applications when all four digits of the year flip over at midnight on December 31, 1999. The so-called year 2000 problem even has its own code name, "Y2K". A recent AltaVista(tm) ( search on "Y2K" turned up some 300 web pages. This article explains how VOS and VOS-based applications may be affected when they encounter dates beyond 1999. It discusses the following topics:

o What Is the Year 2000 Problem?

o How Is Stratus Engineering Addressing the Problem for VOS?

o What Might You Need to Do?

o What Are the Answers to Some Frequently Asked Questions?

2.1 What Is the Year 2000 Problem?

The year 2000 problem has two components: two-digit years and leap years.

2.1.1 Two-Digit Years

The core of this subproblem lies in the following combination of facts.

o Because computer memory and disk storage have traditionally been expensive and data transfer rates can limit performance, programmers have sought to minimize usage of memory and disk storage and maximize performance wherever possible by encoding data compactly.

o All of the development of computer systems and applications has occurred in this century, where the first two digits of the year have been a constant "19".

o Consequently, programmers have saved space by encoding years using only the variable's last two digits; for example, "96" for "1996".

o Data encoded in this way are used in comparisons that affect processing of the data, including sorting. These comparisons produce unexpected results when the years being compared are on opposite sides of the boundary between "1999" and "2000". For example, while "95" is less than "98", "98" is not less than "02".

o Also, for data spanning more than a century, it is unclear whether, for example, "05" means "1905" or "2005".

Many programmers never considered that their applications might still be running, or need to deal with dates, beyond 1999. As a result, these applications may not work correctly when dealing with such dates. Note that this problem does not occur only at midnight on December 31, 1999. It occurs as soon as an application needs to process data with dates beyond that time.

2.1.2 Leap Years

The leap-year subproblem results from the failure of programmers to invoke all three rules for determining whether a given year is a leap year. A year is a leap year if it is:

1. divisible by 4 (1996 is a leap year) 2. but not divisible by 100 (1900 was not a leap year) 3. except when it is also divisible by 400 (2000 will be a leap year).

The third of these rules has not been followed universally by programmers, so there is some risk of losing a day in the year 2000.

2.1.3 Additional Information

The web site Y2K (, maintained by the United States Department of Defense Electronic Systems Center and the MITRE Corporation, is a source of further information on the year 2000 problem. It discusses many aspects of the problem and provides links to related sites.

2.2 How Is Stratus Engineering Addressing the Problem for VOS?

Stratus Engineering is working in the following areas to ensure that VOS applications run successfully through the year 2000:

o Examining VOS Software Products. The VOS Products Group (VPG) is using special tools to examine the modules that make up VOS software products for potential year 2000 problems.

o Testing VOS Software Products. VPG's system test group is simulating year 2000 operation to uncover any potential problems, as well as verifying that its own testing tools do not have year 2000 issues.

o Certifying VOS Releases for Operation through the Year 2000. In 1997, Stratus Engineering will certify that the following VOS releases have been evaluated for year 2000 problems and that all such problems have been fixed.

- Release 14.0.0 - Release 13.5.0 - Release 12.4.0

Subsequent releases will also be tested and certified.

o Adding New Date-Time Built-In Functions to PL/I and COBOL. VPG is adding new ANSI-standard built-in functions to the PL/I and COBOL compilers to provide a wider range of distinct date-times.

o Informing Customers. This article is provided to alert customers to potential problems in VOS releases or their own applications and inform them of assistance available from Stratus Engineering to avoid these problems.

2.3 What Might You Need to Do?

Applications that you have purchased from other sources or developed in house may be subject to year 2000 problems. Stratus recommends the following actions.

o Contact the vendors of any non-Stratus software you are using to ascertain that it is certified to operate properly with dates after 1999.

o Use procedures similar to those followed by Stratus engineers to examine applications you have developed in house for potential problems, and modify them as needed.

o Search application source files and command macros for strings that may indicate date-time usage (for example, "date", "year", and "yy"). Make sure dates are used properly.

2.4 Examining VOS Software Products

The leap-year component of the year 2000 problem does not affect VOS software products. All date-time subroutines are written to account for leap years correctly according to the rules.

The remainder of the year 2000 problem arises when comparing dates containing two-digit years. The VOS calls that deal with dates and times are of two primary types:

o calls to subroutines that return binary representations of dates and times.

o calls to subroutines or language built-in functions that return character-string representations of dates and times or convert binary representations into character-string representations.

The former are not a source of year 2000 problems. The binary representations they use are based on an arbitrary starting date-time, and can represent dates from 1980 through 2048. (Database data types can represent even wider date ranges). Problems can occur when the string representations returned by the latter group of subroutines and built-in functions, or subsets of those strings, are used in comparisons or to generate sort keys.

Based on this information, the VOS Products Group (VPG) has developed a software tool, locate_datestr_calls, which examines object modules for external references to subroutines and language built-ins in the latter group. VPG engineers are using this tool to systematically examine all of the object libraries used to build VOS and VOS products. When locate_datestr_calls reports references to the subroutines or built-ins that return string representations of dates in an object module, this indicates only the potential for a problem. The engineer must then examine the source code for that module to ascertain that no two-digit years are being used. The engineer records any problems for subsequent resolution.

Here are some guidelines and forms used in VPG's evaluation procedures, as well as a list of the software products being evaluated:

o Software Evaluation Guidelines. Guidance on some specific things to look out for.

o Module Evaluation Form. The form used by VPG engineers to record the results of examining object modules with locate_datestr_calls and any subsequent reading of the source code. The file commands is an example that shows how to use this form.

o Module Evaluation Notes. The form used by VPG engineers to record detailed information backing up the module evaluation form.

o VOS Software Products. The list of VOS software products being evaluated for year 2000 problems by VPG engineers.

2.4.1 Software Evaluation Guidelines

When examining your source code for possible year 2000 problems, look for instances of the following VOS date-time string subroutines (which can be detected in the corresponding object modules with the locate_datestr_calls command):

o s$cv_to_long_string_date_time

Always returns a string including a four-digit year. This is problematic only if the string is parsed or somehow permuted to a two-digit year.

o s$cv_to_strings_date_time

May return a two- or four-digit year depending on the options passed to the call. Context and string usage must be examined.

o s$std_date_time_and_zone s$cv_to_std_date_time_and_zone

May return a two- or four-digit year depending on the process's date format definition. Variations of date format (YMD, MDY, etc.) also depend on the format definition. Date, time, and zone return values are separate strings. String usage must be examined.

o s$std_date_time s$cv_to_std_date_time

May return a two- or four-digit year depending on the process's date format definition. Variations of date format (YMD, MDY, etc.) also depend on the format definition. Attempts to parse the date or time field may be problematic if they assume the values to be in a known position inside the string (see s$string_date_time). String usage must be examined.

o s$string_date_time s$cv_to_string_date_time

Always return a two-digit year. The format of the string returned is always "YY-MM-DD HH:MM:SS ZONE". Many programs parse this string to obtain date or time strings using a known position (for example, substr (str, 1, 8) or substr (str, 10, 8)). String usage must be examined.

In addition, you should look for the following:

o date

PL/I built-in function. Always returns "YYMMDD". String usage must be examined.

o (date) (date_time)

Command functions found in command macros.

2.4.2 Module Evaluation Form

Product (vos, lang, oracle, etc):

Files examined (or library if all files examined):

Files not yet examined:

Do unresolved year 2000 issues exist (list in supporting document):

Reviewer History (date/action):


Product (vos, lang, oracle, etc): vos

Files examined (or library if all files examined): commands>* (except those listed below)

Files not yet examined:

>ldd>b>commands>obj>bind.obj s$cv_to_string_date_time

>ldd>b>commands>obj.860>bind.obj s$cv_to_string_date_time

>ldd>b>commands>obj.7100>bind.obj s$cv_to_string_date_time


>ldd>b>commands>src>verify_end_of_file.pl1 s$cv_to_string_date_time

>ldd>b>commands>src>version_manager.c s$string_date_time

>ldd>b>commands>global>src>inr_log_mgr.pl1 s$cv_to_string_date_time

Do unresolved year 2000 issues exist (list in supporting document): No

Reviewer History (date/action): John Smith - 08/13/1996 - Initial generation of list Mary Jones - 08/19/1996 - Reviewed files owned by the I/O group. No conflicts found. Bill Brown - 08/20/1996 - Review of kernel files.

2.4.3 Module Evaluation Notes

Files using date strings benignly (and reason codes):

Files using date strings that will fail in 2000 (and why):

Files using date strings problematically (but will work in 2000):

Files using date strings requiring further review:

Testing suggestions/areas of interest (anything you're not quite sure of):

Reviewer History (date/action):

Reason codes for benign date string usage: 1 - Routine called always produces 4-digit year 2 - Date string used for display or text purpose only. 3 - Date strings compared only for equality. 4 - Parses s$*string_date* primitives 10 - Other (explain)

Reason codes for problematic date string usage: 11 - 2-digit year date strings compared for other than equality. 20 - Other (explain)


Files using date strings benignly (and reason codes): save (2) - Mary Jones verify_save (2) - Mary Jones view_release_tape_log (2) - Mary Jones check_jiffy_times.pl1 (4) compare_dirs.pl1 (2) copy_dump.pl1 (2) display_calendar_clock.pl1 (2) display_disk_label.pl1 (2) display_file.pl1 (2) dump_accounting_file.pl1 (2) emacs.pl1 (2) emacs_macro_control.pl1 (2) emacs_modification_history.pl1 (2) emacs_sos_mail.pl1 (2) init_date_time.pl1 (2) list_batch_requests.pl1 (2) list_broadcast_requests.pl1 (2) list_users.pl1 (2) load_control.pl1 (2, 3) log_registered_users.pl1 (2) login_admin.pl1 (2) move_device_reservation.pl1 (2) overseer.pl1 (2) overseer_log_msg.pl1 (3, 4) process_broadcast_queue.pl1 (2, 3, 4) recreate_index.pl1 (2) set_jiffy_times (2, 4) vc_s$_io.pl1 (2) vc_s$_other.pl1 (2, 10 (test facility for s$ date calls)) global>s_boot_partition_util.pl1 (2) global>s_compare_files.pl1 (2)

Files using date strings that will fail in 2000 (and why):

Files using date strings problematically (but will work in 2000):

Files using date strings requiring further review:

Testing suggestions/areas of interest (anything you're not quite sure of):

Reviewer History (date/action): Mary Jones - 08/19/1996 - Reviewed files owned by the I/O group. Bill Brown - 08/20/1996 - Review of kernel files.

Reason codes for benign date string usage: 1 - Routine called always produces 4-digit year 2 - Date string used for display or text purpose only. 3 - Date strings compared only for equality. 4 - Parses s$*string_date* primitives 10 - Other (explain)

Reason codes for problematic date string usage: 11 - 2-digit year date strings compared for other than equality. 20 - Other (explain)

2.4.4 VOS Software Products Being Evaluated and Certified

Stratus Engineering is evaluating and certifying all VOS software products and related software for year 2000 operation. The following table lists the VOS software products being certified.

     PRODUCT                                      ID

VOS (operating system) S0000V VOS (kernel) S0000V VOS (M&D subsystem) S0000V VOS (disk subsystem) S0000V VOS (tape subsystem) S0000V VOS (RSN) S0000V VOS (FIO) S0000V VOS (TP facility) S0000V StrataNET S0002V RJE 2780/3780/HASP S0003V 3270 Terminal Support S0004V 3270 Emulation Support S0005V X.25 Network Facility S0009V Financial Ticker Protocol Support S0010V X.29 Network Facility S0011V Synchronous Data Link Control (SDLC) S0012V LAPB Protocol Support S0032V PC/Connect - Host S0064V PC/Connect - 2 S0066V Stratus NFS S0135V UCOMM Environment S0137V Dow Jones News Retrieval S0138V OSI Server S0139V CPS (City Protocol Support) S0141V SNA Network Interface Support S0150V Primary SNA S0151V Secondary SNA S0152V Adv Program-to-Program Comm (APPC) S0153V Comm and System Management (CASM) S0154V Distributed System Services S0155V SNA Token Ring Link Manager S0157V SNA QLLC Link Manager S0158V SNA Routing Facility S0159V Local 3272 Emulation S0166V Local 4993 S0167V Local TPF S0168V Token Ring Netbios S0170V Programmable Ethernet S0173V Tokyo Stock Exchange Support S0178V Osaka Stock Exchange Support S0179V Async Window Term S0182V 48K Baud Tokyo Stock Exchange Support S0197V OS TCP/IP Protocol Support S0235V OS TCP/IP Application Support S0236V OS TCP/IP Utilities: TELNET & FTP S0237V STCP Utilities: TELNET & FTP (TBD) STCP (TBD) Multiplexed Host Interface (DataKit) S0238V DNS/2000-International Support S0242V MPIF S0249V X.25 over T1 S0261V Open StrataLINK S0293V Network Express Development S0300V STD_ASYNC S0312V Bisync (3270) Host-NX-SLH S0313V Bisync (3270) Trib-NX-SLH S0314V Bisync (2780/3780) NX-SLH S0316V Bisync (pt-to-Pt) NX-SLH S0317V X.25 NX-SLH S0320V STD_TCP/IP (Kernel Resident) S0324V Bisync (3270) Host U-NX-CLH S0330V Bisync (3270) Trib U-NX-CLH S0331V SNA LU_0 Primary NX-CLH S0334V SNA LU_0 Secondary NX-CLH S0335V SNA LU_1 (3770) Primary NX-CLH S0336V SNA LU_1 (3770) Secondary NX-CLH S0337V SNA LU_2 (3270) Secondary NX-CLH S0338V SNA LU_7 (5250) Secondary NX-CLH S0339V ALU_X.25 S0343V SNA LU_0 Second U-NX-CLH S0344V SNA LU_2 3270 Second U-NX-CLH S0345V BSC/RJE (2780/3780) U-CLH S0347V ALU_SNA/SDLC LU-0 Primary S0348V ALU_SNA/SDLC LU-1 (3770) Primary S0349V SNA LU_0 Primary NX-AXS S0350V SNA LU_0 Secondary NX-AXS S0351V SNA LU_2 (3270) Secondary S0352V SNA LU_7 (5250) Secondary NX-AXS S0353V BISYNC 3270 Host U-NX-AXS S0356V BISYNC 3270 Trib U-NX-AXS S0357V X.25 U-NX-AXS S0361V SNA LU_1 (3770) Primary NX-AXS S0362V SNA LU_1 (3770) Secondary NX-AXS S0363V SNA LU_0 Secondary U-AXS S0364V SNA LU_2 Secondary U-AXS S0365V SDLC U-NX-AXS S0366V BSC/RJE (2780/3780) PT-PT U-AXS S0367V APU_SNA/SDLC LU_0 Primary S0368V APU_SNA/SDLC LU_2 3270 Primary S0370V APU_SNA/SDLC LU_3 Primary S0371V APS_SNA/TRKG LU_0 Primary S0372V APS_SNA/TRKG LU_0 Secondary S0373V APs_SNA/TRKG LU_2 3270 Secondary S0374V APU_ASYNC S0376V APS_SNA/TRKG LU_1 3770 Secondary S0378V APS_SNA/TRKG LU_1 3770 Primary S0379V ALU_SNA/SDLC LU_3 Secondary S0381V APS_SNA/SDLC LU_1 3770 Secondary S0384V ALU_SNA/SDLC LU_3 Secondary S0385V ALU_SNA/SDLC LU_2 3270 Primary S0386V ALU_SNA/SDLC LU_3 Primary S0387V ALS_SNA/TRKG LU_0 Primary S0388V ALS_SNA/TRKG LU_0 Secondary S0389V ALS_SNA/TRKG LU_2 3270 Secondary S0390V ALU_ASYNC S0393V ALS_SNA/TRKG LU_1 3770 Secondary S0395V ALS_SNA/TRKG LU_1 3770 Primary S0396V ALU_BISYNC Pt-to-Pt S0397V ORACLE7 RDBMS S0470V ORACLE7 Distributed Option S0471V ORACLE7 SQL*Plus S0478V ORACLE7 Parallel Query Option S0488V ORACLE7 Advanced Replication Option S0492V ORACLE7 Precompilers S0494V ORACLE7 Forms and Report Writer S0495V SYBASE Data Workbench S0131V Cobol Precompiler for SYBASE S0145 PL/I Precompiler for SYBASE S0146V C Precompiler for SYBASE S0147V SYBASE APT Workbench S0231V SYBASE APT Execute S0232V SYBASE MP SQL Server S0250V SYBASE DB-Library S0251V COBOL Compiler and Library S0020V COBOL Runtime Library S0021V PL/I Compiler and Library S0024V PL/I Runtime Library S0025V FORTRAN77 Compiler and Library S0026V FORTRAN77 Runtime Library S0027V Pascal Compiler and Library S0028V Pascal Runtime Library S0029V VOS C Compiler and Library S0030V VOS C Runtime Library S0031V i860 Assembler S0243V 68K Assembler (for IOAs) S0039V Cobol Cross Compiler S0280V Cobol Cross Runtime S0281V VOS PL/I Cross Compiler S0284V VOS PL/I Cross Runtime S0285V VOS FORTRAN Cross Compiler S0286V VOS FORTRAN Cross Runtime S0287V VOS PASCAL Cross Compiler S0288V VOS PASCAL Cross Runtime S0289V C Cross Compiler S0290V C Cross Runtime S0291V Standard C Cross Compiler S0455V Transaction Processing Facility (TPF) S0006V DES Subroutines S0090V Office/2000 S0112V Forms Management System (FMS) S0008V Full Screen Editor S0040V Text Editor S0041V Spell Check/Dictionary S0043V Debugging Support S0080V Performance Measurement Reporting System S0176V JYACC Applications Manager (JAM) S0184V JYACC Applications Manager Runtime S0185V JAM DBi for ORACLE S0188V JAM DBi Runtime for ORACLE S0189V JAM NLS S0198V JAM NLS Runtime S0199V Multibase Applications Reporting System S0241V BASIC Compiler S0022V BASIC Runtime S0023 BASIC Cross Compiler S0282 BASIC Cross Runtime S0283 VOS system test tools (N/A) VOS development tools (N/A)

2.5 Testing VOS Software Products

The VOS Products Group (VPG) system test engineers are addressing the year 2000 problem in three ways:

o examining their own test tools to verify that they do not have problems

o making sure that their test suites contain tests to uncover year 2000 problems

o testing VOS products under simulated year 2000 conditions.

2.5.1 Examining Test Tools

VPG test engineers are examining their test-tool object modules using locate_datestr_calls, the same tool VPG development engineers are using to evaluate VOS product modules. In addition, they are manually checking the command macros used to set up tests to ensure that they do not have date-string problems.

2.5.2 Evaluating Test Suites

The test engineers are also incorporating new tests into their suites to address problems uncovered by VPG developers as they examine VOS software products. These tests will ensure that future VOS releases are free of year 2000 problems.

2.5.3 Simulating Year 2000 Conditions

VPG test engineers are developing test plans to run VOS software products under simulated year 2000 conditions. Tests will include running:

o on all supported processor types (MC68000, i860, PA-7100)

o with the date-time set to December 31, 1999 23:45:00 and rerunning with the date set to February 27, 28, and 29, 2000

o fault-insertion tests, such as manual board removal and insertion, and system interruption

o time-sensitive data and functions, such as user administration and transaction log rollover

o Open StrataLINK and setting jiffy times across modules.

2.6 PL/I datetime Function

The datetime built-in function conforms to ANSI Standard X3.74-1987 for the PL/I programming language. It accepts no arguments and returns a string of 14 characters representing the current date-time in the following form.


The components of the string are interpreted as shown in the following table.


YYYY year 0001:9999 MM month 01:12 DD day 01:31 hh hour 00:23 mm minute 00:59 ss second 00:59

For example, if the current date-time is 10:15 a.m. on August 29, 1996, the function returns the following string.


The existing built-in functions date and time will remain unchanged and will continue to be supported.

2.7 The COBOL current-date Function

The current-date built-in function conforms to ANSI Standard X3.23a-1989 for the Intrinsic Function Module for COBOL. It accepts no arguments and returns a 21-character alphanumeric value that represents the date, time, and local time differential factor. The character positions returned from left to right are as shown in the following table.

     POSITIONS      MEANING                            VALUE

1-4 year 0001:9999 5-6 month 01:12 7-8 day 01:31 9-10 hour 00:23 11-12 minutes 00:59 13-14 seconds 00:59 15-16 hundredths of a second 00:99 17 sign of difference between -(local time Greenwich Mean Time (GMT) and lags GMT) or local time +(local time equals or leads GMT) 18-19 hours that local time differs 00:12 from GMT 20-21 minutes that local time differs 00:59 from GMT

For example, if the current date-time is 10:15 a.m. EDT on August 29, 1996, the function returns the following string.


The current functions date and time will remain unchanged and will continue to be supported.

2.8 Database Data Types

Data stored in ORACLE& or SYBASE& databases using appropriate data types are not subject to year 2000 problems.

o The ORACLE date data type can represent dates from January 1, 4712 BC through December 31, 4712 AD.

o The SYBASE datetime data type can store values from January 1, 1753 through December 31, 9999, while the smalldatetime data type can store values from January 1, 1900 through June 6, 2079.

2.9 locate_datestr_calls


The locate_datestr_calls command examines object modules and reports any external calls to VOS subroutines or language built-in functions that return string representations of dates and times.


locate_datestr_calls program.obj



The name of the program object module to be examined. Star names are acceptable.


The locate_datestr_calls command examines object modules and reports external calls to any of the following:

     PL/I date built-in function 

Note: Failure of locate_datestr_calls to find any calls to date-time subroutines or built-in functions in a module does not guarantee that the module is free of year 2000 problems. Programs may also use two-digit years obtained from data files or other input, so source files need to be examined if there is any possibility that this is the case.


In the following example, locate_datestr_calls is used to examine all files in an object library. For each module that contains an external reference to a date-time subroutine or language built-in function, the command lists the module name and the subroutines called.

locate_datestr_calls >ldd>f>maint>obj>*

%s1#d02>ldd>f>maint>obj>display_bad_block_page.obj s$cv_to_std_date_time

%s1#d02>ldd>f>maint>obj>interpret_hardware_log.obj s$string_date_time s$cv_to_std_date_time

%s1#d02>ldd>f>maint>obj>mfio_activity.obj s$cv_to_std_date_time

%s1#d02>ldd>f>maint>obj>mfio_error_rtns.obj s$cv_to_std_date_time

%s1#d02>ldd>f>maint>obj>monitor_file_io.obj s$cv_to_std_date_time

ready 15:04:21

2.10 Downloading locate_datestr_calls

You can download a copy of locate_datestr_calls for your module. Download the version of locate_datestr_calls appropriate for the architecture of your module (Continuum, XA/R, or XA). Use anonymous FTP or a Web browsing program to download the file in "binary" mode. Copy the file to VOS. It will be a VOS stream file, which cannot be executed by VOS. To convert it to a VOS fixed-4096 file, use the VOS cvt_stream_to_fixed command. If you do not have a copy of cvt_stream_to_fixed on your module, you can ask your local Stratus CAC to send you a copy.

Here are the paths for the locate_datestr_calls binary and source code files on the Stratus FTP Server:

[Paul Green]

3 New Terms in Calls

The CAC for Americas Customer Services has started using a Call Flow Model to document and track the handling of issues. As a customer, you might see some new terminology in the text of your calls: strange words, such as SOAP and HEIFER, or references to a problem being identified in F3. This article explains these new terms.

The new methods of the Defect Relief Model (DRM) enhance the service provided by the CAC, allowing call takers to quickly identify problems or bugs and thus provide quicker relief. A side benefit is that the text of calls is more structured, making it easier to determine the current status of an issue.

There are three phases to the Defect Relief Model: Failure Analysis, Fault Analysis, and Defect Analysis.

o Failure   analysis  entails  three  components:  failure  detection,
  failure reporting,  and  failure  identification.  Failure  analysis
  requires  the  identification  of  symptoms  through  subjective and
  objective data.

o Fault Analysis has two components: fault definition and fault isolation. Fault Analysis defines the root cause of a fault whether it be a hardware component or a specific line of code in software.

o Defect Analysis has two components: defect repair and defect fix. Defect repair provides a tested repair for a problem. Defect fix integrates the defect repair with future releases and guards against regression.

The current stage of analysis that a call is in may be marked as F# in call text: Failure Detection is F1, Failure Reporting is F2, Failure Identification is F3, Fault Definition is F4, Fault Isolation is F5, Defect Repair is F6, and Defect Fix is F7. These stages all have detailed definitions with entrance and exit criteria described briefly here:

Failure Detection (F1) is the detection of an error such as a fault light, a message in an application or system error log, etc.

Failure Reporting (F2) is when a customer or system (RSN) reports incident to Stratus. Site, system and failure data is recorded at this time.

Failure Identification (F3) is the collection of objective data based on F2 information. F3 requires more analytical skill to focus on a specific product. This phase introduces the SOAP methodology which is part of both Failure Identification (F3) and Fault Definition (F4). SOAP is defined as:

     SUBJECTIVE: - Subjective symptoms.
     OBJECTIVE:  - Objective data.
     ASSESSMENT: - Diagnosis (new/existing bug?).
     PLAN:       - Steps to take.

The SOAP fields can be broken down further into unique sub-steps and should appear in almost every call.

Fault Definition (F4) defines the underlying fault. If the fault is found to be an existing fault, a solution can be provided and the issue resolved at this stage. F4 introduces the HEIFER methodology. HEIFER is defined as:

     HYPOTHESIS:      - Tentative assumption.
     EVIDENCE:        - Data required for hypothesis.
     INVESTIGATION:   - Does evidence prove or disprove hypothesis?
     FINDINGS:        - Document conclusions.
     EVALUATION:      - Document opinions.
     RECOMMENDATIONS: - Summary of information for PLAN.

Fault Isolation (F5) is the determination of the root cause as a line of code in software, hardware component, etc.

Defect Repair (F6) fixes the defect in source code and produces a patch or bug fix version of a release.

Defect Fix (F7) fixes the defect, tests for regresions and installs the fix into a release that has not yet been shipped to customers.

One last benefit will be the SCR. SCR is a summary of the issue and should be included at the end of a call. The SCR is defined as:


The SCR fields can take any form but should provide a useful summarization of the call and should be included in most calls.

The Defect Relief Model enhances resolution of customer issues and is part of a continuing CAC goal to improve customer satisfaction. One target of the model is to reduce the time required to identify a large percentage of reported problems and provide quick resolution. We hope that this model and future process improvements will allow the CAC to provide even faster responses to customers.

[Kevin Dorer]

4 Stratus on the Net

In addition to the CAC Newsletter, there are several ways to get useful information, tips, and tools from Stratus and other users. There is the Stratus anonymous FTP server, the USENET newsgroup comp.sys.stratus, the Info-Stratus mailing list, StrataSearch and PatchManager for HP-UX.

4.1 Stratus FTP Server

Stratus maintains an anonymous FTP server that contains both a VOS and a FTX area. You can reach these servers on the World Wide Web using the following Universal Resource Locator (URL):

or through FTP using the host name:

You can login with the user name: anonymous and the password your_name@your_host (e.g.,

In the VOS area you will find Year 2000 information, a VOS FAQ, VOS Documentation, Software Release Bulletins (SRBs), archived Stratagy presentations, a significant set of VOS tools with documentation, Customer Service tools, plus much more. In order to download some files you must have the ability to initiate "binary" file transfers. All files ending in ".gz" are binary files. They will not transfer properly in the default ASCII file transfer mode. Most FTP clients have a "binary" transfer mode.

There are a number of tools with help files on the server that will further assist you in downloading other files:

o used to bundle a group of files to be transferred

o used to unbundle files that were bundled using

o (version available for all processor types) encapsulates VOS sequential, relative, or, fixed files for transfer over non-VOS mediums without effecting VOS file characteristics.

o (version available for all processor types) decodes files encapsulated by

o (version available for all processor types) compresses files before file transfer or decompresses (gunzip) after file transfer.

Usually, files are transferred from the server as VOS stream files. Files with the ".pm" suffix will need to be converted to fix-4096 file format. The VOS command cvt_stream_to_fixed converts ".pm", program modules, from stream format to fix-4096. cvt_stream_to_fixed can be found in >system>command_library as of VOS Release 11.5. If you are on a release prior to VOS 11.5, call the CAC and request the command be sent to your site.

There is also a CAC Tools area on the FTP server:

Tools should only be downloaded from here at the direction of someone from the CAC. Tools in the CAC area may contain special code for debugging a specific problem for a specific customer. Use of these files is "at your own risk" unless you are directed to do so by support personnel.

4.2 comp.sys.stratus

The USENET newsgroup comp.sys.stratus has been around since 1992. You can benefit by following discussion threads or post your own questions and comments. The newsgroup is available on news servers worlwide. For example, one useful server is Deja News at:

Deja News allows users to search newsgroups through a variety of filters such as keywords or by specifying the group, author, subject, etc.

4.3 Info-Stratus

The Info-Stratus mailing list offers the same information as comp.sys.stratus but "spamming" and commercial mailings are curbed. you can subscribe to the mailing list by sending mail to:


And in the body of the message:

    SUBSCRIBE Info-Stratus

Note: The Info-Stratus mailing list server will be changing in October, instructions on how to subscribe will be available at that time.

4.4 StrataSearch

StrataSearch, which was demonstrated at the 1996 STRATAGY, allows access to a subset Stratus' Quality Tracking System database (QTS) through the World Wide Web. StrataSearch allows customers to search for problem reports for VOS and FTX in a number of ways:

o product categories o major release (e.g., VOS 13.0)/ specific release (e.g., FTX o QTS category (e.g., vos, dsk) o text match

Direct Stratus customers with a current support contract may access StrataSearch by providing a site_id and Remote Service Network (RSN) password. The RSN password is not the same as the password used by the CAC login. The System Administrator must contact the CAC and supply the RSN password. In addition, the System Administrator must update the site's RSN database by using either maint_request update for VOS, or, rsnadmin for FTX. The RSN password has an immediate effect on all RSN communication and so must be updated at the HUB (CAC) and site simultaneously. Access to StrataSearch may take up to 24 hours after updating the RSN password.

The StrataSearch URL is:

You can also reach StrataSearch through the Stratus server at:

4.5 PatchManager

PatchManager allows customers to retrieve HP-UX patches and patch information via the World Wide Web. The PatchManager URL is:

As with StrataSearch, you must be a direct Stratus customer with a current support contract and must provide a site_id and RSN password.

[Kevin Dorer]

5 CAC Visit

The Americas Customer Assistance Centers (CAC) have initiated a program that facilitates customers visiting the CAC for a technical and business information exchange.

We will work with you to customize an Agenda for a day (or even a half day) at the CAC.

You will have the opportunity to learn about the CAC and how we work, and we will learn more about your operation. You will have the opportunity to participate in a technical roundtable and meet your support engineers and service managers.

We would like you to tell us about your business, Stratus application, and environment. We want to know how Stratus fits into the picture. We want to know how downtime impacts you. We have found that knowing about our customer's applications, networks, third party products, etc., enables us to provide better assistance.

We would also like to show you how we work and how the Stratus CAC differs from most other technical support organizations.


o The CAC will understand your environment and procedures

o You will understand how the CAC is organized to assist you

o Shared knowledge

o Better teamwork

If you are interested in a visit please contact Stratus Education by phone at (800) 634-2122 or (508) 481-9431, or by e-mail To:

or on the World Wide Web using the URL:

They will gather preliminary information so that a CAC representative may contact you to schedule your CAC Visit.

[Kathy Dorer]

6 Machine-Independent Locks vs. StrataBUS Locks

On Continuum-series modules, if you utilize StrataBUS locking in your application, there is one very compelling reason why you should consider upgrading your application to machine-independent locking. Performance. The StrataBUS Locking mechanism is emulated on Continuum modules through a fault handler that can generate a thousand or more instructions to be executed for a lock call. The performance penalty for using StrataBUS locking emulation is about the same as that for an alignment fault. Stratus estimates that upgrading from StrataBUS lock emulation to the machine-independent locking mechanism can make locking code in an application run as much as 100 times faster.

VOS Release 13.0 supports machine-independent locking on Continuum only. As of VOS Release 13.1, machine-independent locking subroutines are also supported on XA2000 and XA/R modules. If you upgrade to one of these new releases and recompile you application code without making modifications for machine-independent locking, your code will use StrataBUS locking emulation by default.

Your application must create a shared region of virtual memory by using s$connect_vm_region with access_mode value 10. Remember, the region must be aligned on a 4096-byte page boundary (a non-transaction, fixed file, record length 4096 and open for vm access). Prior to VOS Release 13.0, access_mode 3 was used on XA2000 (68k) and XA/R (i860) platforms for accessing lock words, access_mode 10 replaces access_mode 3. The access_mode 10 description is as follows:

Code Access Mode I/O Type Locking Mode

10 Machine-independent vm-lock access. update implicit The calling process operates on locks in the pages of this region using the virtual-memory lock subroutines, such as s$lock_vm_lock. The copy_on_write switch must be false.

Calls to s$get_vm_lock_word should no longer be used to lock a lock word, the error e$invalid_access_mode (1071) will be returned. Replace calls to s$get_vm_lock_word with either s$try_vm_lock or s$lock_vm_lock. Code that unlocks a lock word should be replaced with s$unlock_vm_lock. Stratus discourages the use of s$get_vm_lock_word or spin-lock subroutines with interlocked-read and write access because on a Continuum-series module:

o When the region of shared memory containing the lock word is connected to using s$connect_vm_region's interlocked-read and write access mode (access code 3), the operating system simulates the interlocks that were used on pre-Continuum modules. Interlocked-read and write access is very slow because the operating system must simulate the old interlock behavior.

o When the region of shared memory containing the lock word is connected to using s$connect_vm_regions's machine-independent vm-lock access mode (access_mode 10), s$get_vm_lock_word returns an error.

On XA2000 or XA/R modules, s$get_vm_lock_word behaves as it did prior to VOS Release 13.0 whether the region is connected to using interlocked-read and write access (access_mode 3) or machine-independent vm-lock access (access_mode 10). Machine-independent locking and the new locking subroutines will produce good performance on all VOS modules.

The following new subroutines are used to perform locking related tasks and are briefly described here:

o The s$init_vm_lock subroutine initializes the state of a lock in shared virtual memory to the unlocked state. Use this subroutine to initialize each lock to the unlocked state before manipulating the lock with s$lock_vm_lock, s$try_vm_lock, or s$unlock_vm_lock.

o The s$lock_vm_lock subroutine acquires ownership of a lock located in shared virtual memory, looping until the lock is acquired.

o The s$query_vm_lock subroutine determines whether a lock in shared virtual memory is locked or unlocked. This subroutine does not affect the status of the lock (locked or unlocked).

o The s$try_vm_lock subroutine tries to acquire a lock located in shared virtual memory and returns, rather than loops, if it cannot acquire the lock immediately.

o The s$unlock_vm_lock subroutine unlocks a lock in shared virtual memory.

o The s$vm_lock_size subroutine returns the number of bytes of lock memory that are used for a single lock on the current processor.

One important note, vm-lock size varies depending on the module type (XA2000, XA/R, Continuum). You need to call s$vm_lock_size to check the lock size before calling s$init_vm_lock. On XA2000 and XA/R modules the size returned by s$vm_lock_size is 2. On Continuum, the size returned by s$vm_lock_size is 32.

You can find more information on virtual-memory locks and machine-independent locking in the following documentation:

o VOS Subroutines Manual - s$connect_vm_region, s$get_vm_lock_word, and s$init_vm_lock_word.

o Migrating VOS Applications to Continuum Systems (R407).

[Kevin Dorer]

7 Recovering From A System Interruption

A system interruption can be caused by an extended powerfailure, a user error (inadvertent power-off or level-7), a software inconsistency detected by the kernel, or hardware failure. In general, no matter what the cause of the interruption, there are a number of items you should be aware of to help you and the CAC return your system to normal operation.

The intent of this article is to highlight some of the steps a customer should be taking if they suffer a system interruption. If you do suffer a system interruption you should do is call the CAC immediately. However, there are some things you can do now to be prepared for that unlikely event, review the documentation and steps mentioned here.

Read the chapter "Recovering from a Crash" in the Stratus manual VOS System Administration: Starting Up and Shutting Down a Module or System (R282).

You can request a copy of SED-1909: Diagnosing and Recovering from VOS Hangs from the CAC. Although this is a Stratus Engineering Document (SED), the intended audience is the CAC and Stratus customers. It is the official Engineering position statement on what to do after a crash or hang.

Once the module reboots but BEFORE starting production applications, check the syserr_log.(date) for Emergency Shutdown (ESD) and salvager error messages. If you are on VOS Release 11.1 or greater, ESD will try to complete all outstanding I/O, write out the file partition bit maps on all disks, and updating the labels on all mounted disks. If ESD completes properly, the need to salvage disks on reboot should be eliminated. If you see salvager messages where changes are being made to directories containing critical files, you need to examine the files and their attributes to see if corrections need to be made.

Of course, the data and indexes of files that are TP-protected should be undamaged, provided the TPOverseer starts successfully when the module reboots. Any committed transactions that were not completely written to disk prior to the interruption will be re-applied after the module reboots and the TPOverseer process starts.

For files that are not TP-protected, the data may have been modified at the time of the interruption and therefore inconsistent on disk. You will need to use the tool to verify that the end-of-file pointer in a directory entry points to a correct location within the file. The pathname for the tool is:

>system>command_library> will work on sequential, relative and fixed file formats. verify_end_of_file is documented in VOS System Administration: Starting Up and Shutting Down a Module or System (R282).

On indexed files where the end-of-file pointer has been repositioned by verify_end_of_file, you may need to recreate the indexes as index keys may not point to the intended records. The pathname is:


recreate_index automates index recreation by determining the characteristics for each index of a file. recreate_index can be used only on embedded_key indexes. recreate_index is documented in VOS System Administration: Starting Up and Shutting Down a Module or System (R282). In some cases, it may be faster to delete or repair the damaged keys. The tool test_index invokes a subsystem that will allow you to examine the structure of an index and may help you determine whether or not you need to recreate an index. However, it does not check or verify the consistency of index keys pointing to the correct record. The pathname is:


test_index is documented in VOS System Administration: Starting Up and Shutting Down a Module or System (R282).

Even with these tools, it is possible for a file to be damaged beyond repair. Every site should have a regular backup process to ensure that current backup tapes are available.

Along with ESD, dumps are an important part of the recovery process. The more complete the dump, the more data the CAC has to determine the cause of the interruption and helping you avoid another interruption in the future. There are several factors that can affect the completeness of a dump:

o System is powered off during Primitive Control Program (PCP) dump.

o Power to bootload memory boards is interrupted.

o Dump partition is too small, contents of physical memory, paging partition, board states, etc., cannot be written to disk.

o Bootload memory is not duplex.

Physical memory dumping, also referred to as memory dumping, became available in VOS Release 11.0. Physical memory dumping creates a dump file from the contents of the partnered memory board that had unsuccessfully attempted to create its own dump when the system interruption occurred. The bootload memory must be duplex and power to the partnered memory board cannot be interrupted. This dump can be merged with the PCP dump. Memory dumps cannot copy paging partition pages, board states, IOP/IOA or BIO memory (all these have been reset by the reboot process).

Frequently, the dump partition is too small for the amount of memory and number of processes running on a system. Processes that have a large number of stack pages or a significant number of tasks, require more dump pages. Currently, the maximum size for the dump partition is 16320 pages. The CAC can help you determine the optimal dump partition size for your system.

Note that VOS Release 12.3.0 introduced compressed dumps. Typically, compressed dumps take about half the disk space required for uncompressed dumps.

If you have questions about recovering from a system interruption, please contact your CAC.

[Kevin Dorer]


8.1 Check Your SRB

With every major release of VOS Stratus produces a VOS Software Release Bulletin (SRB). The SRB is available as a manual, R119 or can be found in text form in (master_disk)>system>doc as the file rXX.X_srb.memo, where XX is the major VOS release. In the SRB there is a section that describes Software Enhancements, New Hardware Support, Unsupported Software Products and other Products no longer Supported, End of Life (EOL) or End of Service (EOS) notices, and other changes and considerations. Other chapters describe changes that affect Operation and Administration, Communications, Commands, Languages, File system.

Additionally, an addendum_srb.memo file is usually produced for an update release. The file rXX.X_addendum_srb.memo located in (master_disk)>system>doc usually describes enhancements for the release, where rXX.X is the release number.

[Kevin Dorer]

8.2 Software Compatability And Your Application

There are two guidelines you should keep in mind when you do release planning for your production and development systems:

o Stratus guarantees forward compatibility for VOS on the same hardware architecture.

o Stratus guarantees backward compatibility for one release on VOS.

Stratus guarantees forward compatibility for VOS on the same hardware architecture. In practice, most customers recompile and rebind their code at each major release. They do this to be sure that it will still build cleanly, and to use any new compiler optimizations. However, this is not required by Stratus.

Stratus guarantees backward compatibility for one release on VOS, as long as no new release-specific features are used. In other words, as long as you do not invoke some functionality that is only present in release N, the compilers, binder, and language runtime routines will produce executable code that is good for release N-1. For example, code that is created on VOS 13 can be run on VOS 12 and up.

Customers are encouraged to keep their production and development systems no more than one release apart. In fact, if they are connected via StrataNet or StrataLink, Stratus requires that the releases be no more than one major digit apart (VOS 11 to 12, VOS 12 to 13, etc.). If you are running your development module at VOS 13, and your production module at VOS 11, you are two releases apart. Therefore, Stratus would not guarantee that code created on VOS 13 will run properly on VOS 11. It might work, it might not.

The precise details about software compatibility issues are documented in the Software Release Bulletin (SRB) that is supplied with each release. Please read the SRB carefully before performing any upgrade.

If you plan to upgrade your development system before you upgrade your production system, please call your local account team or the CAC to discuss your specific requirements.

[Paul Green/Kevin Dorer]

8.3 PL/1 - Calling s$parse_command Twice in a Single Program

If you need to make a second call to s$parse_command in a program you have to do the required prototyping; however, PL/1 has scoping that will allow you to do what you want; simply put the different declarations AND the calls to s$parse_command in different internal subroutines. You can also use BEGIN/END blocks to establish a temporary scope.

A word of caution about using s$parse_command more than once in your program when you use it to get arguments from the command line. The problem is that each call to s$parse_command parses the original command line. You should be using the end_descriptor qualifer 'noarg' instead of using a data type like unclaimed. Here are some examples with subroutines:

main: procedure;

dcl code bin(15); dcl abort_switch bit(1) aligned; dcl pathname char(256) var;

dcl s$write entry (char(*) var in);

call subr1; call subr2; if ^abort_switch then call s$write(pathname); return;

subr1: procedure; /* s$parse_command with no arguments */ dcl s$parse_command entry (char(*) var in, bin(15), char(*) var);

call s$parse_command('subr1', code,'end'); return;

end subr1;

subr2: procedure; /* s$parse_command with two arguments Note use of the 'noarg' value for the end parameter - prevents processing of command line arguments when s$parse_command is called this time. See the PL/1 subroutines manual for more information */

dcl s$parse_command entry (char(*) var in, bin(15), char(*) var in, char(*) var, char(*) var in, bit(1) aligned, char(*) var);

call s$parse_command('subr2', code, 'pathname', pathname, 'switch(-abort),=0', abort_switch, 'end,noarg,form'); return;

end subr2;

end main;

Here's the same example using BEGIN/END

main: procedure;

dcl code bin(15); dcl abort_switch bit(1) aligned; dcl pathname char(256) var;

dcl s$write entry (char(*) var in );

begin; /* s$parse_command with no arguments */ dcl s$parse_command entry (char(*) var in, bin(15), char(*) var);

call s$parse_command('subr1', code,'end'); end;


dcl s$parse_command entry (char(*) var in, bin(15), char(*) var in, char(*) var, char(*) var in, bit(1) aligned, char(*) var);

call s$parse_command('subr2', code, 'pathname', pathname, 'switch(-abort),=0', abort_switch, 'end,noarg,form'); end;

if ^abort_switch then call s$write(pathname);


end main;

[Dan Danz]

Converted to HTML by DOC processor, VOS version 5.4.1