With the advent of ooRexx 4.0 a new, important need arises: determining
which addressing mode the running Rexx interpreter uses.

This is a vital information, if e.g. one writes installation scripts in
ooRexx installing native libraries that must match the bitness of the
running (installed) ooRexx interpreter. Therefore I would like to open
an RFE for supplying this information via Rexx, but before doing so, I
would like to ask for feedback.


A "natural" place to supply this fundamental information seems to be the
"PARSE VERSION" keyword statement, which exists for supplying Rexx
interpreter related version information.

Going back to the ANSI REXX J18 standard and studying its information
about the formatting of "PARSE VERSION" string this is what I have found
(version string related text put into bold):

    * "5.10.1 Config_Constants
      Set the values of the following state variables:
      – If there are any built-in functions which do not operate at
      NUMERIC DIGITS 9, then set
      variables #Bif_Digits. (with various tails which are the names of
      those built-in functions) to the
      values to be used.
      – Set variables #Limit_Digits, #Limit_EnvironmentName,
      #Limit_Literal, Limit_MessageInsert, #Limit_Name, #Limit_String,
      Limit_TraceData to the
      relevant limits. A configuration shall allow a
      #Limit_MessageInsert value of 50 to be specified.
      A configuration shall allow a #Limit_TraceData value of 250 to be
      - Set #Configuration to a string identifying the configuration.
      *- Set #Version to a string identifying the language processor. It
      shall have five words.
      Successive words shall be separated by a blank character. /The
      first four letters of the first
      word shall be 'REXX'./ The second word shall be the four
      characters '5.00'. The last three
      words shall be in the format which is the default for the DATE()
      built-in function."

    * "A.5.10.1 Config_Constants
      Existing practice is usually to implement the built-in functions
      using NUMERIC DIGITS 9 for the
      checks on the arguments. That may be inadequate for some purposes,
      such as the character
      position within a very large stream, so the configuration is
      allowed to indicate different values of
      NUMERIC DIGITS for different built-in functions.
      *It is intended that the right part of the first word of #Version
      should identify the language processor
      in use. It is intended that the date in the last three words
      should be the release date of the language
      The base document specifies that the first word of #Version should
      not contain a period, so as to
      simplify parsing #Version. Existing practice has not honored that
      rule, and the rule is not part of
      this standard."

Therefore I would like to suggest to extend the information encoded into
the first word of the #Version string, which currently is formed as:

    REXX-ooRexx_3.2.0(MT) 6.02 5 Dec 2007

If the first word gets extended with the address mode information in
such a way that it is easy to parse, then maybe one possible encoding
may be:

    REXX-ooRexx_4.0.0(MT*_32_bit*) 6.03 31 May 2009
    REXX-ooRexx_4.0.0(MT*_64_bit*) 6.03 31 May 2009
    REXX-ooRexx_4.5.0(MT*_128_bit*) 6.05 15 Dec 2015

    Such an encoding would allow for the following keyword statement to
    extract the address mode:

        parse version "(MT_" addressmode "_bit"

    However, it may be the case that there are programs which already
    use a pattern like "(" threadMode ")" to get the thread mode
    information, which as a result may break, if they just expect two
    alphabetical characters to be parsed. (IMHO quite unlikely, but
    still conceivable, hence looking for an alternative encoding that
    would not break any existing programs.)

An alternative encoding, which should not affect any existing programs,
parsing the version information might be:

    REXX-ooRexx_4.0.0(MT)*_32_bit* 6.03 31 May 2009
    REXX-ooRexx_4.0.0(MT)*_64_bit* 6.03 31 May 2009
    REXX-ooRexx_4.0.0(MT)*_128_bit* 6.05 15 Dec 2015

    Such an encoding would allow for the following keyword statement to
    extract the address mode:

        parse version ")_" addressmode "_bit"

Any thoughts? Would the encoding/suggestion be sensible ?


Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
Oorexx-devel mailing list

Reply via email to