2. Define Composite String: DIM var$:IOL=iolref

3. Initialize String: DIM var$(len[,char$])[,...]

4. Define Structured String DIM var$::structure$

Where:

The maximum number of elements in an array (regardless of the number of dimensions) is 10000032767 for 32-bit ProvideX (Version 4.10). That is, you can use either DIM A$[1:32767] or DIM A$[32766] (zero based). (The limit in 16-Bit PVX Windows and PVX DOS remains 8192 elements.).

To delete an array use the CLEAR directive as in CLEAR A$[ALL]

DIM array_name[$](subscript_1[,subscript_2[,subscript_3]])

Use the DIM directive to define an array with one, two or three dimensions. Specify the dimensions using the values in the DIM statement. The dimensions of the array are defined as

[ minimum :] maximum.

If you omit the minimum dimension, then ProvideX uses the default minimum, 0 (zero).

Examples:

DIM X$[10]	Creates 11 element array with elements X$[0] thru X$[10]
DIM X$[0:10]	Same as above
DIM X$[1:6]	Creates 6 element array with elements X$[1] thru X$[6]

When you refer to items in arrays, the lowest subscript is the minimum value specified, the highest is the maximum value specified. You can redefine existing arrays using the DIM statement. The values of all elements in the array are automatically initialized to zero or null by the DIM statement.

The following example defines a three-dimensional array with three elements (0 through 2) in each dimension for a total of 27 elements:

DIM A(2,2,2)

The following example defines dimension one with 10 elements (1 through 10). Dimensions 2 and 3 are 0:0:

DIM CATS[1:10] !

DIM var$:IOL=iolref

Use this format of the DIM directive to define a composite string variable consisting of the fields specified in an IOList. The variable returns a string made up of the fields you specified in the IOList. If you modify the variable (e.g., by adding a field) ProvideX will modify the fields in the IOList. Field names in the IOList are prefixed by the name of the variable and a dot (.); e.g.,

0010 DIM CST$:IOL=1000
1000 IOLIST NAME$,ADDR$,CITY$,ZIP

yields the string CST$ consisting of CST.NAME$, CST.ADDR$, CST.CITY$, and CST.ZIP. Each field is separated by the SEP or delimiter in the default record format.

You can use a CLEAR directive to reset a variable that is defined as a string template; e.g., CLEAR CST$. For more information refer to Composite Strings vs BBx Templates, IOLIST Specify Variable List, and CLEAR Reset Variables.

The following example defines PRD$as a 36 character string consisting of PRD.DESC$ for 30 characters and PRD.COST for 6 digits with a scale of 2 (2 implied decimal digits):

0010 DIM PRD$:IOL=2000
2000 IOLIST DESC$:[CHR(30)],COST:[NUM(6,2)]

DIM var$(len[,char$])[,...]

Use the DIM directive to define a string variable of a specific length. You can also use the DIM statement to define the value of the string variable. ProvideX uses the first character of the value you set in the char$ string as the fill character for the string being defined. The fill character is repeated for the length of the string, as follows: DIM A$(5,"*") is the same as DIM A$(5,"*-") ... both yield A$="*****"

If a value is not given (or is null) then the string is initialized to spaces.

Combine this string initialization with the definition of string arrays (above) to pre-initialize all the elements of a string array. For example, the DIM statement DIM ACC_IDS$[10](6,"0")defines an array of 11 strings, each pre-initialized with 6 zeroes.

Structured string handling is a +PxPlus Exclusive

• You can pass a variable that is part of a composite string (e.g., CST.NAME$) to a subprogram and have a value returned in it. In a string template, however, CST.NAME$ would be considered a substring which could not be altered by a subprogram.
• There is no performance impact when referencing individual variables in a composite string. There can be a performance impact when referencing logical variables in a template, especially when the template has variable length fields. On the other hand, when you reference the complete composite string, the string will be reconstructed each time. The string template always exists in memory, with no reconstruction required.
• Unlike string templates, composite strings can be reconstructed on the fly; e.g.,
  
  0010 IOLIST NAME$,ADDR$,CITY$,AMT
  0020 IOLIST NAME$,ADDR$,CITY$,ZIP$,AMT
  0030 CST.ZIP$=""
  0040 DIM CST$:IOL=0010
  0050 READ RECORD (1)CST$
  0060 DIM CST$:IOL=0020
  0070 WRITE RECORD (1)CST$
  
  The logic above automatically inserts CST.ZIP$into the composite string while preserving the other data elements. Note that composite string variables are not implicitly cleared when the composite string is defined, whereas templates are.
• Since composite strings reference real variables, fields in composite strings have data types associated with them. That is, in a composite string, ProvideX considers CST.AMT, CST.AMT$, and CST.AMT%to be three different fields, whereas in a string template these would all refer to the same field.
• ProvideX does not currently support subscripting with composite strings.