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.
I've seen this before. My memory is a little fuzzy on this but I seem to recall that on WinNT 7.68 it displayed the rejected records in TRMOUT. What was even more annoying is that &FOCERRNUM was 0 unless the error occurred on the last row.
I think you'll have to use divide and conquer to find the rogue data.
My original post simplified the actual situation. I have 31 concatenated files as input so, to find the needle in the haystack I thought I would allocate one file at a time and run the job 31 times. Well, they all ran without format errors!
Then I started with two concatenated files, ran the job, added another, ran the job, and so on. I finally figured out a combination of two files gives me three format errors - but there are about two million rows...
I'm thinking of giving up.
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
I had something similar happen recently, we have a WebFocus program that builds a file that is used in AIX FOCUS. A tab was entered into one of the data fields. Passed through the WebFocus program without any problems, but when it hit the AIX FOCUS it rejected because all of the fields after were in the wrong position.
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
EX -LINES 6 EDAPUT MASTER,TST_DATA,CV,FILE
FIELD=KEY ,ALIAS= ,A10 ,A10 ,$
FIELD=VALUE ,ALIAS= ,P10.2,A10 ,$
FIELD=TEST_TYPE,ALIAS= ,A30 ,A30 ,$
EX -LINES 7 EDAPUT FOCTEMP,TST_DATA,CV,FILE
TEST 1 100.01VALID
TEST 2 999999.99VALID
TEST 3 MISTAKE 1Text instead of numeric
TEST 4 0.99VALID
TEST 5 12345,20Comma in numeric
TEST 6 -8888.77VALID
FILEDEF TST_DATA DISK tst_data.ftm (LRECL 50 RECFM V
TABLE FILE TST_DATA
ON TABLE HOLD AS TST_HOLD FORMAT ALPHA
! type tst_hold.ftm
And it seems to indicate that the records are not held.
To determine the records with the format errors, I would create a second master that is alpha only, (you only need the keys) and compare the two results.
If the format errors are not on the keys then it should pinpoint the offending records.
I may be totally off the mark here, but ... Could it be that by using 31 concatenated files and adding the records, you end up overflowing one of the summed fields (PLAN in this case), producing *** in the output file? If that might be the case, then increasing the format (not the actual) of the field PLAN on the input side might solve the problem.
- Using AS 8.2.01 on Windows 10 - IE11.
in Focus since 1988
Posts: 1961 | Location: Netherlands | Registered: September 25, 2007