Identifying Places and Things

By Richard K. Goran

Where am I / what am I?
With many OS/2 users moving to Warp 4, the need may exist in your REXX programs of determining a number of system-related variables. The most obvious of these is what version of OS/2 your program was launched from. The simplest way to differentiate the OS/2 version is using the SysOS2Ver function in the REXXUTIL Application Program Interface (API). The values returned by SysOS2Ver are shown in Table 1. As the table shows, both classic REXX and Object REXX on Warp version 4 return the same value. Therefore, the PARSE VERSION instruction must be used to further identify the operating environment. Classic REXX will return a value of 4.00 as the second word whereas Object REXX will return a value of 6.00. I suggest that the date returned by the PARSE VERSION instruction not be relied upon as I have seen this change in the classic REXX world with various maintenance releases. The long-awaited boot drive function was put into the Object REXX version of REXXUTIL as SysBootDrive; however, that is of little consolation to classic REXX programmers. The ability to determine the boot drive does exist in other APIs. REXXLIB (commercial) has always had the DOSBOOTDRIVE function. RXU (free) written by Dave Boll includes the RxQuerySysInfo function (described separately below) which has a slightly obscure way of identifying the boot drive. This is not Boll's doing as he is simply providing a pass-through to the DosQuerySysinfo system function. The boot drive is returned as an ordinal number which can be converted into its corresponding drive letter (1-26 = A-Z).

Warp 4 and Warp 3 Connect contain an undocumented API, RLANUTIL, that contains the GetBootDrive functions which returns the boot drive letter in upper case followed by a colon. The function most be individual register using the RxFuncAdd function. E.g. call RxFuncAdd 'GetBootDrive', 'RLANUTIL', 'GetBootDrive' boot_drive = GetBootDrive

Other techniques to determine the boot drive can be used without relying on external APIs. Some that I have seen used are naive because they are predicated on flawed rationale. For example, the IBM Warp 3 Bonus Pack install.cmd assumed that the boot drive was indicated by the drive letter and colon that immediately preceded the first occurrent of \OS2 in the PATH environment variable. This worked well on systems that didn't have custom directories that began with the characters \OS2 and that were placed ahead of the system's \os2 directory. It certainly won't work on any OS/2 systems I build where I have added a directory, \os2addon, that I intentionally want to appear in the search path before the default system directories. For a long time I recommended that the environment variable RUNWORKPLACE, which normally points to ?:\os2\pmshell.exe, be used to determine the location of the boot drive; however, a program named FILEBAR apparently changes this value. Therefore, when I want to determine the boot drive without using an external API, I use the following: parse upper value VALUE( 'PATH',, 'OS2ENVIRONMENT' ) with, '\OS2\SYSTEM' -2 boot_drive +2 This does have a dependency on the \os2\system directory remaining on the boot drive, but I doubt that will change in the near future.

Classic vs. Object REXX
The PARSE VERSION instruction is used to determine whether you are running under classic REXX, Object REXX, or any alternate version of REXX like Personal REXX from Quercus Systems. The values returned for each version are summarized in Table 2. The value returned by SAA REXX on PCDOS 7.0 is included though I don't know that many people will care.

File name vs. File extension
With access to other file systems via the Internet, some attention is warranted in the discussion of parsing, or separating, a file name from its optional file extension. According to OS/2 Warp 4 Unleashed, "Under the 8.3 naming convention, the extension is the 1-3 characters following the period. Under HPFS, if the file system name contains one or more periods, the characters to the right of the rightmost period comprise the file extension." [#Fragment 1 Fragment 1] shows a technique for extracting the file name and optional extension from a full file system name which is valid for all file systems. The code fragment uses a file system name that is found on a Warp 4 system that has the optional Java installed.

Fragment 1 - Parsing file name and extension

DosQuerySysInfo
The DosQuerySysInfo function is an API that is available to C programs to extract a wealth of system information about the system the program is running on. Some of this information is available via REXXLIB; however, all of the information is directly available with the RxQuerySysInfo function in rxu.dll. Table 3 lists the information that can be extracted from the object system. RXU is accompanied with rxu.inf which describes how to use the RxQuerySysInfo function and how the data is returned.

Closing
It has been my pleasure to write for OS/2 Magazine for the past three years. I'm sorry to say that this is my final column. Our WWW site and FTP server will remain active. I will continue to post utilities as well as other REXX-related information there for all to access anonymously. My REXX and OS/2 advocacy will continue as will my REXX training and consulting. The new edition of our REXX Reference Summary Handbook, with all of the Warp Version 4 updates, is available and full details can be found on our Web site.

Resources
OS/2 Warp 4 Unleashed - (SAMS - ISBN 0-672-30910-6)
 * 1-800-695-8642
 * David Moskowitz, David Kerr, et. all

Personal REXX Quercus Systems
 * 1-408-372-7399

REXXLIB - commercial with fully enabled demo version
 * Quercus Systems
 * 1-408-372-7399

RXU - free for download