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.
What FIXFORM Format would be used to read in a field, that was Zoned on the MainFrame, that was a converted to a number with a leading sign (where the + is blank)?
That depends what you mean by "was converted to a number."
What platform is on now? What does it look like in a text editor? And how about in hex?
If you view it in a text editor and the number is readable (1234 looks like 1234, -1234 looks like -1234), then it's alpha (A). If this is the case, and the number is 9 characters long, then fixform it as A9. If the USAGE is I9 or P9 in the MFD of the DB you're loading it into, then FOCUS will convert it internally to the proper format in the load.
If you view it in a text editor and it's garbage characters, then we'd need to figure out how it's actually stored right now.
If you view it in hex, and the number 1234 appears as
F1 F2 F3 F4 (mainframe EBCDIC) or
31 32 33 34 (PC ASCII)
then it's also a good bet that it's alpha.
Let us know what platform and what the data looks like both in hex and in a text editor and I can give you a better idea how to define it.
-CB
Posts: 55 | Location: New York | Registered: March 07, 2003
Thanks Chris, we are going from EBCDIC on MVS to ASCII on NT. We converted the MVS Zoned fields to alpha with a character space in front of the number for the sign. So, on NT 1234 is Alpha as you surmised. Our original was FIXFORM Z8.2, so with what you are saying we should probably change the FIXFORM to A8 (we were trying F8.2 to no avail) and then the USAGE which i believe is P8.2 will take care of itself. Correct?
Correct. A8 would be the actual format of that field. And conversion of A8 to P8.2 will work fine in the load. FOCUS will store it in the db as a P4 ACTUAL internally.
So if your MFD has the field defined as P8.2, you should have no problems using A8 as the input format for the fixform.
Posts: 55 | Location: New York | Registered: March 07, 2003
When the FIXFORM Format is A8 and the USAGE in the MFD is P8.2 the Load disregards the implied decimal, and the value is loaded as a whole number. How can we get the load to honor the decimal? Data -> b0200000 - where b is blank comes in as -> 200000 not as -> 2000.00
Well, you can 'cheat' . Since you're going to a 'P' format, and your data has an implied decimal point, use 'Z' format on the fixform. With 'Z' format, you can specify where the implied decimal point is. For example, if my data is '01234, and my FIXFORM declares the field as 'field/Z5.2', it'll be read in as 12.34.
Of course, this assumes there are no leading signs on your value.
Just out of curiosity, how did you get the leading sign, but lose the decimal point?
Art
Posts: 25 | Location: 2 Penn Plaza 28 fl | Registered: March 27, 2003