Identifying Places and Things

From EDM2
Revision as of 23:25, 7 March 2018 by Ak120 (Talk | contribs)

Jump to: navigation, search

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.

Table 1 - SysOS2Ver() values
Version SysOS2Ver() returns
Prior to Warp 3 2.10
Warp 3 (Red, Blue, Connect) 2.30
Warp 4 (Classic & Object) 2.40

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.

Table 2 - PARSE Version values
REXXSAA 4.00 11 Nov 1994 (PCDOS 7.0)
REXXSAA 4.00 08 Jul 1992 (Pre Warp 3)
REXXSAA 4.00 10 Feb 1994 (Warp 3)
REXXSAA 4.00 24 Aug 1996 (Warp 4)
OBJREXX 6.00 12 Jul 1996 (Obj)
REXX/Personal 4.00 12 Oct 1994 Personal REXX

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

/* 9701FG01.CMD - Determine file extension */
file_system_name = 'C:\javaos2\docs\api\java.applet.Applet.html'
file_name_ext    = FILESPEC( 'N', file_system_name )
dot_ptr          = LASTPOS( '.', file_name_ext )
if dot_ptr > 0 then
   do
      parse value file_name_ext with,
         file_name =(dot_ptr) +1,
         file_extension
   end
else
   do
      file_name      = file_name_ext
      file_extension = 
   end

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.

Table 3 - Data available with RxQuerySysInfo()
1. Maximum length, in bytes, of a path name.
2. Maximum number of text sessions.
3. Maximum number of PM sessions.
4. Maximum number of DOS sessions.
5. Drive from which the system was started (1 means drive A, 2 means drive B, and so on).
6. Dynamic priority variation flag (0 means absolute priority, 1 means dynamic priority).
7. Maximum wait in seconds.
8. Minimum time slice in milliseconds.
9. Maximum time slice in milliseconds.
10. Memory page size in bytes. This value is 4096 for the 80386 processor.
11. Major version number.
12. Minor version number.
13. Revision letter.
14. Value of a 32-bit, free-running millisecond counter. This value is zero when the system is started.
15. Low-order 32 bits of the time in seconds since January 1, 1970 at 0:00:00.
16. High-order 32 bits of the time in seconds since January 1, 1970 at 0:00:00.
17. Total number of pages of physical memory in the system. One page is 4KB.
18. Total number of pages of resident memory in the system.
19. Maximum number of pages of memory that can be allocated by all processes in the system. This number is advisory and is not guaranteed, since system conditions change constantly.
20. Maximum number of bytes of memory that this process can allocate in its private arena. This number is advisory and is not guaranteed, since system conditions change constantly.
21. Maximum number of bytes of memory that a process can allocate in the shared arena. This number is advisory and is not guaranteed, since system conditions change constantly.
22. Timer interval in tenths of a millisecond.
23. Maximum length, in bytes, of one component in a path name.
24. Session ID of the current foreground full-screen session (full screen sessions only; PM session has sessid=1)
25. Process ID of current (i.e. one making this call) foreground process
26. Number of processors on machine

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