As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.
New TIBCO Community Coming Soon
In early summer, TIBCO plans to launch a new community—with a new user experience, enhanced search, and expanded capabilities for member engagement with answers and discussions! In advance of that, the current myibi community will be retired on April 30. We will continue to provide updates here on both the retirement of myibi and the new community launch.
What You Need to Know about Our New Community
We value the wealth of knowledge and engagement shared by community members and hope the new community will continue cultivating networking, knowledge sharing, and discussion.
During the transition period, from April 20th until the new community is launched this summer, myibi users should access the TIBCO WebFOCUS page to engage.
As far as I know, the concatenation for anything (strings, &vars, etc.) has always been the | or || symbol. The dot is used for many different things of which . &var.eval and &var.length ar a couple. It is also used for identifying field formats (-READ &VAR.A20.)and prompt strings (WHERE FIELD='&VAR.ENTER A VALUE.;) but I have never seen it used for concatentation.
Of course, sometimes I don't know very "far."
In FOCUS since 1991 WF Server: 7.7.04 on Linux and Z/OS, ReportCaster, Self-Service, MRE, Java, Flex Data: DB2/UDB, Adabas, SQL Server Output: HTML,PDF,EXL2K/07, PS, AHTML, Flex WF Client: 77 on Linux w/Tomcat
Posts: 2298 | Location: Salt Lake City, Utah | Registered: February 02, 2007
I misread Dave's post. &VAR.VARTWO does work but is used for concatenating the value of VARTWO to the &VAR variable name, not actual value concatenation of both variables. TWO dots .. will concate to values.
This seems to be the rulebook for the two delimiters, ".." and "|" recognized by dialog manager:
When dialog manager is composing a string (in any Focus statement, or in a -TYPE directive) ".." acts as a delimiter, if it immediately follows an amper variable reference. The delimiter gets eaten: The variable-name and its trailing delimiter are replaced by the variable's current value.
When dialog manager is evaluating an expression (as in a -SET or -IF directive), ".." does not function as a delimiter.
By contrast, "|" immediately following a &var reference always acts as a delimiter, in either context. For example,
is equivalent to
-SET &Z3=&Z1 || &Z2;
-SET &Z4=&Z1 | &Z2;
-- a vertical abutting &Z1 gets eaten, and the remaining one or two verticals represent soft or hard catenation. Since the vertical touching the &var disappears, it is not counted toward the catenation operator, so || in the first code yields soft catenation (rather then hard) and ||| yields hard (rather than a syntax error).
In either context, once you insert a space after the &var, the vertical reverts to its normal dialog manager significance (as an operator in expressions, and as a literal [no special significance to dialog manager] when forming a string.
Of course, when a line of Focus code preprocessed by d.m. finally gets read from focstack and processed as Focus code, the vertical may have significance as an operator; but that's a different stage of the game.
- Jack Gross WF through 8.1.05
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005