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.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I am curious as to how one uses an A99V field in reports. From what I've seen, the first two characters of a variable length field contains the length of the data in the field, then the actual data value, so for example, an A10V field might have a value of "05ITALY". How would you display this in a report? Would you always have to edit out the first two characters? How is this practical? Why would the default behaviour of WebFOCUS 7.6 change from previous versions to generate metadata for VARCHAR fields as A99V, when it seems to me that most people would want to use most of those VARCHAR fields as normal, fixed length fields in reports.This message has been edited. Last edited by: Kerry,
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
If it is defined as an A99V, when you print/sum the field it will display only the value of the field and not the length. However, if you are editing or substringing the field you have to allow for the extra characters and a SQL passthru may handle the field differently. I'm with you, I don't know why anyone would want it in WebFocus. ADD ENGINE DB2 SET VARCHAR OFF to the server profile and recreate your synonyms.
Pat WF 7.6.8, AIX, AS400, NT AS400 FOCUS, AIX FOCUS, Oracle, DB2, JDE, Lotus Notes
Posts: 755 | Location: TX | Registered: September 25, 2007
It's the first 6 characters that show the length of the field. In the source master file the field is identified as A99V, in a holdfile it is also A99V for usage, but A99W for actual (don't know why the W). Tabling off a hold file will account for the length bytes, you won't see them in the report.
GamP
- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007
Variable length fields are the correct modern way of doing strings.
Unfortunately wf does not lend itself well to implementing this without a total rewrite of its tried and tested architecture. Hence we also stick with the ENGINE XXX SET VARCHAR OFF.
Dont completely write them off they have their uses such as returning variable length strings from user functions.
Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2 Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo
Posts: 888 | Location: Airstrip One | Registered: October 06, 2006
The FOCUS architectire requires that records (instances of a given segment) have uniform length. As a result, varchar (AnV) fields must be padded out to their maximal length, obviating the potential savings in storage. (Procrustes rules!)
OTOH, the internal architecture of XFOCUS does provide for storing variable-length records, which allows varchar fields potentially to be stored in truncated form. (But that potential savings ain't necessarily implemented)
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005
I had an issue with -READ off a HOLD file containing A99V fields and dismissed them as a bad idea. I should have realized that a TABLE, DEFINE, COMPUTE would read/output the fields normally.
Francis
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server