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'm generating a SAVE file and comparing it to an existing file (this is a conversion project) and have discovered that in the OLD file each line is terminated with CRLF (carriage return, line feed), but the NEW file is terminated with only a CR.
Does anyone know how to force WF to generate the CRLF?
WF 7.6.6, FOCUS 7.6.4, IBM MVS/TSO, Windows 2003 Server, DB2, MSSQL
Posts: 65 | Location: Chicago, IL | Registered: July 26, 2007
I only need to do this to compare the two files and don't really care about the CRLF except it makes it difficult to identify the rows that are really different (not CRLF). It turns out the editor I'm using can convert the file to a DOS format and will change the CR to a CRLF for me.
Thanks for your help.
WF 7.6.6, FOCUS 7.6.4, IBM MVS/TSO, Windows 2003 Server, DB2, MSSQL
Posts: 65 | Location: Chicago, IL | Registered: July 26, 2007
Hm, I wonder what your procedure(s) looks like. If I create hold files (binary and/or alpha) and edit the results with a hex-editor then I see no CR/LF's at all in the binary holds (which figures, since they are being created with fixed record length), but the alpha hold does contain both the cr and lf characters in my environment (Windows XP). The alpha holds contain the 0D 0A combination at the end of every record. This is valid when run in 717 as well as in 761. Code I used:
APP HOLD SESSION
TABLE FILE CAR
SUM
DEALER_COST
RETAIL_COST
SALES
BY COUNTRY NOPRINT
BY SEATS
ON TABLE SAVE AS FILE1
END
And then change SAVE into HOLD FORMAT ALPHA or HOLD FORMAT BINARY or SAVB.
GamP
- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007
I'm doing a simple HOLD FORMAT ALPHA, and yes, I get the 0D 0A at the end of every row. My problem was when I tried to do a compare between the OLD (only OA) file and the NEW file (both 0D 0A) using UltraEdit, it would flag every row as different, which makes the compare useless. Now I'm using TextPad which can convert the file so that the compare works properly.
WF 7.6.6, FOCUS 7.6.4, IBM MVS/TSO, Windows 2003 Server, DB2, MSSQL
Posts: 65 | Location: Chicago, IL | Registered: July 26, 2007
c1, At this point, no. I would prefer a WF solution, too, but I may have to look for something outside WF. Right now I'm waiting to test one of the dozens of export files to see if it causes any problems at the other end.
If it does, I gotta make it happen.
CTRAN might do the trick. Create an A1 field and translate it to ASCII '0D' and print it as the last character in each row. I test it out and let you know what I get.
WF 7.6.6, FOCUS 7.6.4, IBM MVS/TSO, Windows 2003 Server, DB2, MSSQL
Posts: 65 | Location: Chicago, IL | Registered: July 26, 2007