REXX Tips & Tricks:REXXUTIL functions

This section contains hints about the functions from the DLL REXXUTIL.

Using REXXUTIL

If you're using REXXUTIL very often and your PC has enough memory (8 MB or more), you should load REXXUTIL in the STARTUP.CMD.

Example for STARTUP.CMD:

/* Important: STARTUP.CMD must be a REXX program to load REXXUTIL!    */
 call RxFuncAdd "SysLoadFuncs", "REXXUTIL", "SysLoadFuncs"
 call SysLoadFuncs
 exit 0

Using REXXUTIL if booted from diskette

If you've booted OS/2 from diskette, you can use REXXUTIL in the following circumstances:

• The stub program to load the REXX support is BOS2REXX.EXE
• The OS/2 DLLs normally in the directory \OS2\DLL are accessible through the LIBPATH. Of course, these DLLs won't fit on a diskette. But they may be on a hard disk or a codeserver.
• And last you must load each function from REXXUTIL by hand with RxFuncAdd. You can't use SysLoadFuncs if booted from diskette!

You can't use the WPS related functions from REXXUTIL if booted from diskette, but mostly all other functions work fine. For example I've tested the following functions:

• SysCls
• SysCurPos
• SysCurState
• SysDriveInfo
• SysDriveMap
• SysGetKey
• SysMkDir
• SysOS2Ver
• SysRmDir
• SysTempFileName
• SysTextScreenSize

Note

See also the DLL CLTRUTIL included in the OS/2 WARP Server/OS/2 WARP Connect.

See also #New REXXUTIL functions in Object REXX.

Hints for REXXUTIL functions

The functions to work on the macro space

The new REXXUTIL.DLL provided with Object-Oriented REXX contains some functions to work with the macro space (see #New REXXUTIL functions in Object REXX). These functions return the following error codes:

• okay, no error
• Not enough memory
• Macro not found
• Extension required
• Macro already exist
• File error
• Signature error
• Sourcefile not found
• Invalid position

Some further hints for these functions:

SysAddRexxMacro can only load one macro from a REXX cmd file at a time. You can't load a tokenized REXX program into the macro space using this function. SysAddRexxMacro overwrites an existing macro. The file with the REXX macro must have an extension - SysAddRexxMacro doesn't find files without an extension.

SysLoadRexxMacroSpace can only load an image that was previously saved with SysSaveRexxMacroSpace. SysLoadRexxMacroSpace works only if the macro space is empty (thus you can't concenate two or more images in the macro space but AFAIK the number of macros in the image is not limited).

There's no function to get a list of all existing macros in the macrospace.

(see also LoadMac.cmd)

The function SysCLS()

The function SysCLS clears the screen using the default colors. To clear the screen with non-default colors (set with ANSI ESC sequences) you must use the OS/2 command CLS.

Source: John Seitz

The function SysCopyObject()

In theory you can use the function SysCopyObject to copy a file with a long name from an HPFS formatted drive to a FAT formatted drive. In real life it works sometimes and sometimes not. This seems to be a bug.

SysCopyObject does not overwrite an existing file.

(see also Copy a file from HPFS to FAT and vice versa for a workaround)

The function SysCreateObject()

SysCreateObject does not support the object settings database DATABASE.DAT in the directory \OS2\INSTALL.

You cannot use the SysCreateObject parameter title to change the title of an existing object. You must use the setup string keyword TITLE to do this.

SysCreateObject does not replace an existing object when a caret is used in the object title to represent a new line character. Example.:

/* Create an object and update it                                     */

  call RxFuncAdd "SysLoadFuncs", "REXXUTIL", "SysLoadFuncs"
  call SysLoadFuncs

  do 2
    call SysCreateObject "WPProgram" ,,
                         "Title^with Caret" ,,
                         "<WP_DESKTOP>" ,,
                         "EXENAME=C:\OS2\CMD.EXE;PROGTYPE=WINDOWABLEVIO;" ,,
                         "U"
  end /* do 2 */

This code should create an object on the desktop in the first round and update that object (with the same settings) in the second round. But instead of that, it creates two objects on the desktop. To avoid this, either don't use a caret in the title of an object or. better yet, always create objects with an object ID.

(Source: APAR PJ17176)

Be aware that using the function SysCreateObject with the last parameter set to Replace will destroy the object and all shadows of the object before recreating it (without recreating the shadows)!

The function SysDestroyObject

Use the REXXUTIL function SysDestroyObject to delete a complete directory tree including the sub directories (Source: Michael Platschek).

Please note that this is not possible if there are read-only files in one of the directories. To get around this limitation you can use the function SysFileTree (see also Delete a directory(-tree)):

/* sample code to delete a directory tree                             */

                    /* dirToDelete contains the name of the directory */
                    /* to delete                                      */
  dirToDelete = 'D:\TEST'

                    /* load the functions from the DLL REXXUTIL       */
  call rxFuncAdd 'SysLoadFuncs', 'REXXUTIL', 'SysLoadFuncs'
  call SysLoadFuncs

                    /* clear the read-only, the hidden and the system */
                    /* flag from all files                            */
  call SysFileTree dirToDelete || '\*.*', dummyStem, 'BS', '*****', '-*---'

                    /* delete the directory tree                      */
  call SysDestroyObject dirToDelete

The function SysFileSearch()

"When SysFileSearch is called with a file that has lines greater than 255 characters the strings returned contain the line truncated to 255 characters." (Source: APAR PJ19726 fixed in WARP 3 Fixpack #15)

The function SysFileTree()

The date returned by the functions SysFileTree and STREAM is always the date the file was last modified.

See REXX and Y2K for information about SysFileTree and Y2K.

The function SysIni()

Using the function SysIni to write data to a non-existing ini file creates a file with that name.

The function SYSINI returns ERROR: if called about 12900 (+/- 100) times in a loop to retrieve/set a value from/in one or more INI files. After the error occurs, you can't use the function SYSINI in that session anymore. To get around this, you have to close the session and open another.

(see also RxIni)

The function SysOS2Ver()

The result of the REXXUTIL function SysOS2Ver under OS/2 Version 3 WARP is 2.30.

The result of the REXXUTIL function SysOS2Ver under OS/2 WARP 4 is 2.40.

The function SysPutEA()

Use an empty string as the third parameter of SysPutEA to delete an Extended Attribute.

Use the OS/2 program EAUTIL to delete all Extended attributes of a file or directory.

The function SysQueryEAList

Ordinarily, it is not possible to get a list of all existing Extended Attributes in Classic REXX. But there is a function called SysQueryEAList in the REXXUTIL.DLL from Object-Oriented REXX that will list all EAs attached to a specified file or directory. This DLL can also be used in Classic REXX (see #New REXXUTIL functions in Object REXX).

The function SysQueryClassList()

The function SysQueryClassList does not work after resetting the WPS (with RESETWPS.EXE from WPTOOLS, for example).

A possible workaround for this problem is to open a new OS/2 session and issue the SysQueryClassList from within this session. This workaround may not be effective in every situation.

This bug seems to be fixed in WARP 4.

Source: Christian Langanke

The function SysSearchPath()

If a filename is passed to the function SysSearchPath without an extension, but WITH a trailing dot, the function will return the filename WITHOUT the trailing dot (provided, of course, that the file exists); e.g.:

newName = SysSearchpath( 'PATH', 'test.' )

returns 'C:\test' if that file exists (and C:\ is in the PATH variable).

The function SysSleep

Note that there is no guarantee that the function SysSleep sleeps exactly the time given to it as parameter. The real sleep time depends on the system load of the running OS/2 system. Therefore you should use a routine like for example Wait until a specific time if you're using SysSleep to wait for a specific time.

New REXXUTIL functions in WARP

There are 5 new functions in OS/2 WARP Version 3 to work on WPS objects:

• SysMoveObject
• SysCopyObject
• SysSaveObject
• SysOpenObject
• SysCreateShadow

All functions are mentioned in the documentation. But because the documentation for these functions is really a pit, I include the documentation from the REXX Reference Summary Handbook by Dick Goran (captured from a message in a public CompuServe Forum):

The following new functions have been added to REXXUTIL in WARP Version 3.0:

SysCopyObject( object_name, object_destination )

Returns 1 if object_name was successfully copied to object_destination; otherwise, returns 0. If the object already exists in the destination location, it is not copied and a 0 is returned.

Both object_name and object_destination can be a WPS object ID (the unique string preceded with a '<' and terminated with a '>') assigned to the object when it was created (e.g. <WP_DESKTOP>) or a fully qualified file name. The predefined object IDs are shown in Section 4.1 beginning on page 89.

Note 01: The copied object will not have an OBJECTID whether the original object had one assigned or not.

Note 02: Some of the object's other properties are not copied along with the object. Specifically, ASSOCTYPE= belonging to the original object does not appear on the copy. This is consistent with what occurs when using drag & drop to copy

SysCreateShadow( object_name, object_destination )

Returns 1 if a shadow of object_name was successfully created at the specified location, object_destination; otherwise, returns 0.

Both object_name and object_destination can be a WPS object ID (the unique string preceded with a '<' and terminated with a '>') assigned to the object when it was created (e.g. <WP_DESKTOP>) or a fully qualified file name. The predefined object IDs are shown in Section 4.1 beginning on page 89.

SysMoveObject( object_name, object_destination )

Returns 1 if object_name was successfully moved to object_destination; otherwise, returns 0. If the object already exists in the destination location, it is not moved and a 0 is returned.

Both object_name and object_destination can be a WPS object ID (the unique string preceded with a '<' and terminated with a '>') assigned to the object when it was created (e.g. <WP_DESKTOP>) or a fully qualified file name. The predefined object IDs are shown in Section 4.1 beginning on page 89.

SysOpenObject( object_name, view, flag )

Returns 1 if the WPS object object_name was successfully opened on the Desktop; otherwise, returns 0.

Object_name can be a WPS object ID (the unique string preceded with a '<' and terminated with a '>') assigned to the object when it was created (e.g. <WP_DESKTOP>) or a fully qualified file name. The predefined object IDs are shown in Section 4.1 beginning on page 89.

View specifies the view to be opened and can contain either a numeric value or the equivalent string. The function will pass all numeric values to the underlying wpOpen() or wpViewObject() function without testing the value for validity.

0 - DEFAULT

1 - ICON

2 - SETTINGS

3 - HELP

4 - RUNNING

5 - PROMPTDLG

101 - Tree view (added RXT&T v2.00 /bs)

102 - details view (added RXT&T v2.00 /bs)

121 - PALETTE

Flag can contain a 1 indicating that an existing view of an object can be opened on top of the Desktop (resurfaced) by calling the wpViewObject method or a 0 indicating that the view specified in view is to be opened using the wpOpen method. The following comment originated in the description of the wpOpen method:

"In general, wpViewObject should be used instead of the wpOpen method. This is because wpViewObject takes into consideration the setting in the Object Open Behavior field on the Window page of the Settings notebook for the object. If a view of the object is already open, wpViewObject will depending on the setting of the Object Open Behavior field, either display the existing window for the object or create a new object."

"In contrast, wpOpen always opens a new view of the object. Under certain circumstances this might be called for, but, under most circumstances, wpViewObject should be called instead."

SysSaveObject( object_name, timing_flag )

Returns 1 if the WPS object object_name was successfully saved; otherwise, returns 0.

File system objects (WPFileSystem) are saved in the file system's extended attributes and abstract objects are saved in the OS2.INI (user) file. Transient objects (WPTransient) cannot be saved.

Object_name can be a WPS object ID (the unique string preceded with a '<' and terminated with a '>') assigned to the object when it was created (e.g. <WP_DESKTOP>) or a fully qualified file name. The predefined object IDs are shown in Section 4.1.

Timing_flag can be 0 (Boolean false - object is to be saved synchronously) or 1 (Boolean true - object is to saved asynchronously).

Note

No, you can't use the new REXXUTIL.DLL in OS/2 version prior to WARP.

New REXXUTIL functions in Object REXX

The new Object-Oriented REXX contains an enhanced REXXUTIL.DLL. This DLL exports a lot of new functions in addition to the normal REXXUTIL.DLL (see below).

You don't need to install Object-Oriented REXX to use its enhanced REXXUTIL.DLL. The DLL also runs under Classic REXX in OS/2 WARP 3 and OS/2 WARP Version 4. (Note that the default REXX interpreter in OS/2 WARP 4 is still Classic REXX!)

Use one of the following methods to use the new REXXUTIL.DLL in Classic REXX when Classic REXX is your default (i.e., currently installed) REXX.

Using the new REXXUTIL.DLL as default REXXUTIL.DLL

To use the new REXXUTIL.DLL as the default REXXUTIL.DLL with Classic REXX, rename the original REXXUTIL.DLL to something like REXXUTIL.BAK. Then copy the file REXXUTIL.DLL (and REXXCRT.DLL in OS/2 WARP 3) from Object-Oriented REXX to the OS/2 DLL directory \OS2\DLL and reboot. Note that in OS/2 WARP Version 4 the new REXXUTIL.DLL is named OREXUTIL.DLL when Classic REXX is the default REXX interpreter. (When Object-Oriented REXX is installed as the default REXX, OREXUTIL.DLL is automatically renamed to REXXUTIL.DLL and the corresponding DLL for Classic REXX becomes CREXUTIL.DLL)

That's it.

Using only the new functions from the new REXXUTIL.DLL

To use only the new functions from the new REXXUTIL.DLL, copy the REXXUTIL.DLL from Object-Oriented REXX into a new directory, for example C:\OREXX.

In OS/2 WARP 3 you must also copy the DLL REXXCRT.DLL from Object-Oriented REXX into the OS/2 DLL directory; in OS/2 WARP Version 4 this DLL already exists in the OS/2 DLL directory.

To use a function from the new REXXUTIL.DLL, simply load it using RxFuncAdd. You must use the RxFuncAdd statement for every function from the new REXXUTIL.DLL you need - you cannot use SysLoadFuncs! It's also important in this case that you use the fully qualified name for the DLL in the RxFuncAdd statement!

Example:

/* To show how we can have the REXXUTIL DLL for Classic REXX loaded   */
/* as the default and -- at the same time -- use the new functions of */
/* the Object REXX DLL, in this example we'll first load REXXUTIL     */
/* from Classic REXX. (This first step is not required every time you */
/* call a function from Object REXX's REXXUTIL.)                      */

/* load the REXXUTIL DLL from Classic REXX                            */
  call RxFuncAdd "SysLoadFuncs", "REXXUTIL", "SysLoadFuncs"
  call SysLoadFunc

/* load the functions SysBootDrive and SysProcessType from the new    */
/* REXXUTIL DLL                                                       */
/* (assuming the new REXXUTIL.DLL is in the directory C:\OREXX)       */

  call RxFuncAdd "SysBootDrive",   "c:\orexx\rexxutil", "SysBootDrive"
  call RxFuncAdd "SysProcessType", "c:\orexx\rexxutil", "SysProcessType"

Following is a list of the new functions in the REXXUTIL.DLL from Object-Oriented REXX (Please note that the following links will only work if Object REXX is the default REXX interpreter on your system!):

SysAddRexxMacro

add a routine to the REXX macro space

SysClearMacroSpace

clear the REXX macro space

SysDropRexxMacro

remove a routine from the REXX macro space

SysLoadRexxMacroSpace

load a function into the REXX macro space

SysQueryRexxMacro

query the existence of a macro space function

SysReorderRexxMacro

change the order in the REXX macro space

SysSaveRexxMacroSpace

save the REXX macro space

SysCreateEventSem

create or open an OS/2 event semaphore

SysOpenEventSem

open an OS/2 event semaphore

SysPostEventSem

post an OS/2 event semaphore

SysResetEventSem

reset an OS/2 event semaphore

SysWaitEventSem

wait on an OS/2 event semaphore

SysCloseEventSem

close an OS/2 event semaphore

SysBootDrive

get the OS/2 boot drive

SysFileSystemType

get the name of the file system for a drive

SysQueryEAList

retrieve a complete list of EA names

SysElapsedTime

use the OS/2 high-frequency timer service

SysCreateMutexSem

create or open an OS/2 mutex semaphore

SysOpenMutexSem

open an OS/2 mutex semaphore

SysCloseMutexSem

close an OS/2 mutex semaphore

SysReleaseMutexSem

release an OS/2 mutex semaphore

SysRequestMutexSem

request an OS/2 mutex semaphore

SysGetCollate

get the country-specific collating table

SysMapCase

perform national language uppercase mapping of a string

SysNationalLanguageCompare

compare two strings using a country-specific collating table

SysProcessType

get the type of the process in which the REXX program is running

SysSetPriority

change the priority of the current process

SysQueryProcessCodePage

query the current code page for the process

SysAddFileHandle

get and set the number of file handles

SysSetFileHandle

set the number of file handles available to the current process

SysSetProcessCodePage

change the current code page for the process

SysShutdownSystem

shut down the OS/2 system

SysWildCard

produce an OS/2 edited file name using a source name and a wild card pattern

The updated version of Object REXX from 11 Nov 1997 (see Object REXX for OS/2) contains some additional new REXXUTIL functions. (Please note that the following links will only work if the Object REXX from 11 Nov 1997 is the default REXX interpreter on your system!) These additional functions are:

SysQueryExtLibPath

query the value of BEGINLIBPATH/ENDLIBPATH

SysSetExtLibPath

set the value of BEGINLIBPATH/ENDLIBPATH

SysQuerySwitchList

query the task list

SysSwitchSession

switch to a specific session

Also new in this version of REXXUTIL is the ability to use the Sysini function in non-PM environments. To do this, the new DLL SHPIINST.DLL must be in the LIBPATH.

---

The updated version of Object REXX from 18 May 1999 (see Object REXX for OS/2) contains some additional new REXXUTIL functions. (Please note that the following links will not work even if the Object REXX from 18 May 1999 is the default REXX interpreter on your system because the functions are not documented in the INF file! see #Documentation for the new REXXUTIL functions) These additional functions are:

SysDumpVariables

Dump the contents of all variables

SysGetFileDateTime

Get the date of a file or directory

SysSetFileDateTime

Set the date of a file or directory

SysStemCopy

Copy a stem

SysStemDelete

Delete one or more entries in a stem with numbered index

SysStemInsert

Insert an entry in a stem with numbered index

SysStemSort

Sort a stem

SysUtilVersion

Retrieve the REXXUTIL version

SysVersion

Retrieve the OS version in string format

---

Warning

According to some messages on CompuServe the REXXUTIL.DLL from the beta versions of Object-Oriented REXX are not fully compatible with the normal REXXUTIL.DLL!

But now that the Special Edition of Object-Oriented REXX is available at the Net for free you shouldn't use the Beta anyway.

Documentation for the new REXXUTIL functions

This section contains the documentation for the new functions in the REXXUTIL.DLL from Object-Oriented REXX from 18 May 1999 (The documentation is missing in the file REXX.INF).

SysDumpVariables

Syntax

result = SysDumpVariables([filename])

Params

filename - name of the file where variables are appended to (dump is written to STDOUT if omitted)

Function

This function dumps all variables in the current scope either to the specified file (new data will be appended) or to STDOUT if the filename parameter is omitted. The format of the data is (one variable per line):

Name=MYVAR, Value="This is the content of MYVAR"

Examples

Call SysDumpVariables "MyVars.Lst" /* append vars to file */
Call SysDumpVariables              /* list vars on STDOUT */

Return

 0 - dump completed OK
-1 - failure during dump

SysSetFileDateTime

Syntax

result = SysSetFileDateTime(filename [,newdate] [,newtime])

Params

filename - name of the file to update
newdate  - new date to set in format YYYY-MM-DD
           OS/2: (YYYY > 1980)
           Win: (YYYY > 1800)
           AIX/Linux: (YYYY > 1900)
newtime  - new time to set in format HH:MM:SS (24 hr format)

Function

This function can be used to modify the "Last Modified" Date of the specified file. If no new date or new time is specified then the file date and time will be set to the current time (TOUCH). If only one of date or time is omitted then this parameter will be left unchanged.

For OS/2 and Windows NT the filename may also specify a directory name. This does not work with Windows 95/98 or AIX/Linux however.

The file you want to change must not be opened by another process or at least it must allow shared writes in order to update the timestamp.

Examples

Call SysSetFileDateTime "MyFile.Log"  /* touch file */
Call SysSetFileDateTime "MyFile.Log", "1998-12-17"
Call SysSetFileDateTime "MyFile.Log",, "16:37:21"
Call SysSetFileDateTime "MyFile.Log", "1998-12-17", "16:37:21"

Call SysSetFileDateTime "C:\MyDir"    /* touch dir on OS/2, NT */

Return

 0 - file date/time was updated correctly
-1 - failure attribute update

SysGetFileDateTime

Syntax

result = SysGetFileDateTime(filename [,timesel])

Params

filename - name of the file to query
timesel  - What filetime to query: CREATE/ACCESS/WRITE

Function

The function call returns the selected file date time attribute of the specified file if this is supported by the operating and file system (e.g. FAT does not provide Create/Access). The selector for the time to be returned can be abbreviated with its first character.

For OS/2 and Windows NT the filename may also specify a directory name. This does not work with Windows 95/98 or AIX/Linux however.

The file you want to query must not be opened by another process or at least it must allow shared reads in order to query the timestamp.

Examples

Say "File creation time:" SysGetFileDateTime("MyFile.Log", "C")
Say "File last access time:" SysGetFileDateTime("MyFile.Log", "A")
Say "File last update time:" SysGetFileDateTime("MyFile.Log", "W")

Say "Directory creation time:" SysGetFileDateTime("C:\MyDir", "C")

Return

-1 - file date/time query failed
other - date and time as YYYY-MM-DD HH:MM:SS

SysStemCopy

Syntax

result = SysStemCopy(fromstem, tostem, [from], [to], [count] [,insert])

Params

fromstem - name of source stem
tostem - - name of target stem
from  - first index in source stem to copy
to - position where items are copied/inserted in target stem
count - number of items to copy/insert
insert - 'I' to indicate insert instead of 'O' overwrite

Function

Copy elements from the source stem to the target stem. Elements in the source stem are copied starting at the from index (default 1) into the target stem beginning at the to index (default 1). The number of items to copy to the target stem can be specified with count (default is to copy all items in the source stem). You can optionally specify that the items should be inserted into the target stem at the position and the existing items will be shifted to the back accordingly.

This function operates only on stem arrays that specify the number of elements in stem.0 and all elements must be numbered from 1 to n with no omitted index.

Examples

Source.0 = 3
Source.1 = "Hello"
Source.2 = "from"
Source.3 = "REXX"
Call SysStemCopy "Source.", "Target."

Call SysStemCopy "Source.", "Target.", 1, 5, 2, "I"

Return

 0 - stem copy was successful
-1 - stem copy failed

SysStemDelete

Syntax

result = SysStemDelete(stem, startitem [,itemcount])

Params

stem - name of stem where item will be deleted
startitem - index of item to delete
itemcount - number of items to delete if more than 1

Function

Deletes the specified item at index startitem in the stem. If more than one item is to be deleted then the count of items can be specified as the third parameter. After deleting the requested items the stem will be compacted, that means items following the deleted items will be shifted up into the vacant positions.

This function operates only on stem arrays that specify the number of elements in stem.0 and all elements must be numbered from 1 to n with no omitted index.

Examples

Call SysStemDelete "MyStem.", 5

Call SysStemDelete "MyStem.", 5, 4

Return

 0 - delete was successful
-1 - delete failed

SysStemInsert

Syntax

result = SysStemInsert(stem, position, value)

Params

stem - name of stem where item will be inserted
position - index where new item will be inserted
value - new item value

Function

A new item will be inserted at the specified position in the stem. All existing items in the stem from the specified position will be shifted up by one to make room for the new item.

This function operates only on stem arrays that specify the number of elements in stem.0 and all elements must be numbered from 1 to n with no omitted index.

Example

Call SysStemInsert "MyStem.", 5, "New value for item 5"

Return

 0 - insert was successful
-1 - insert failed

SysStemSort

Syntax

result = SysStemSort(stem, order, type, start, end, firstcol, lastcol)

Params

stem - name of stem to sort

order - 'A' or 'D' for sort order (default: ascending)

type - 'C', 'I' for comparision type (case/ignore, default: case)

start - first index to sort (default: 1)

end - last index to sort (default: last item)

firstcol - first column to use as sort key (default: 1)

lastcol - last column to use as sort key (default: last column)

Function

This call sorts all or the specified items in the stem. Sort order can be specified as ascending or descending, comparison type can respect or ignore the case of the strings being compared.

The sorting can further be narrowed by specifying the first and last item to be sorted or by specifying the columns used as the sorting key. The sort uses a quicksort algorithm, so the order of equal elements according to the sort key is undetermined.

This function operates only on stem arrays that specify the number of elements in stem.0 and all elements must be numbered from 1 to n with no omitted index.

Examples

/* sort all elements descending, use cols 5 to 10 as key */
Call SysStemSort "MyStem.", "D",,,,5, 10

/* sort all elements ascending, ignore the case */
Call SysStemSort "MyStem.", "A", "I"

/* sort elements 10 to 20 ascending, use cols 1 to 10 as key */
Call SysStemSort "MyStem.",,,10, 20, 1, 10

Return

 0 - sort was successful
-1 - sort failed

SysVersion

Syntax

result = SysVersion()

Params

None

Function

This function returns a string to identify the operating system and its version. The returned string contains an identifier for the operating system as the first word and then the version in the second word.

Examples

Say SysVersion()       /* show OS and version */

Return

Operating system and version

Possible output for operating systems supported by Object REXX:

Say SysVersion()   ->  "WindowsNT 4.00"
Say SysVersion()   ->  "OS/2 2.40"
Say SysVersion()   ->  "AIX 4.2"
Say SysVersion()   ->  "Linux 2.0.34"

Note

This function can be used to replace the operating system specific functions SysOS2Ver(), SysWinVer(), and SysLinVer().

SysUtilVersion

Syntax

result = SysUtilVersion()

Params

None

Function

This function returns a version number that identifies the current level of the REXX Utilities package. This can be used to verify that certain functions are available.

Examples

Since this function was not part of the original packaging a sample logic to check for a certain level of REXXUTIL could look like this:

If RxFuncQuery("SysUtilVersion") = 1 |,
                SysUtilVersion() < "2.00" Then
                Say "Your REXXUTIL.DLL is not at the current level"

If a specific function should be used that was added at a later REXXUTIL level a similar check can be performed by querying that function:

If RxFuncQuery("SysSetFileDateTime") = 1 Then
                Say "Your REXXUTIL.DLL is not at the current level"

Return

REXXUTIL version number in the format (n.mm)