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.
We use a home-grown utility to convert a tab-delimited data file (originally from Excel) to both a .mas and a flat .ftm file.
Using a focexec from green-screen Focus for Unix, this .mas/.ftm deliver correct results. The same focexec, using DevStudio, while referencing the data in same directory where the .mas/.ftm files were originally created, works great.
However, if we use DevStudio to copy the .mas and .ftm files to a different folder, DevStudio pads the data record to 80 (81, really) characters. The focexec no longer works great. The .mas file no longer describes the record correctly.
Has anyone encountered this?
I have not tested what happens if the original record is longer than 80 characters. Nor have I reported this to IBI.
I'm still in a state of astonishment that DevStudio would mess with a data file in this way.
Suzy
Posts: 124 | Location: Lebanon, New Hampshire | Registered: April 24, 2003
same thing happens to me, when i make an .ftm as a temporary hold file and then copy it out of the agent along with its master. the master won't read it, in a separate operation . nuts, huh? If i filedef it out of the agent in the first place, and then copy the master out, its ok, i can re-read it in a separate operation. i don't use devstu, i use mre domain builder, but its the same thing.
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003
The problem is with the DATASERVER which has to also work on MVS mainframe for the movement of MASTER and FOCEXEC FILES where the record length is set to 80 characters. It's not designed to move data files as such, and if your ftm file is less than 80 characters it will be padded, If it is greater than 80 characters it will be truncated.
If you want to move a data file you should not use the dataserver in either dev studio or MRE.
In dev studio you can do it via Web Applications tree but there is no option for that in MRE.
A work around (if you must use the dataserver) when your original file is less than 80 characters is to add the LRECL when you filedef it such as FILEDEF FRED DISK C:\IBI\APPS\BASEAPP\FRED.FTM (LRECL 58 WebFocus will then read it correctly.
Really you should use the operating system to move data files around.
In dev studio this can be done if you have 'Show desktop on explorer tree' checked in your dev studio option panel. Again no equivalent in MRE.
In both MRE and Dev studio you could create a 2 line fex to do the copy for you
The Procrustean approach (stretch to or truncate at 80) is outdated, even with respect to Focexec and Master members on MVS: They are no longer required to be F 80.
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005
So you are suggesting that users will always need to be working at the OS level with one set of "names" (file paths) and at the DevStudio level with another set of "names" (app paths). Since these 2 kinds of "names" can never be identical, surely confusion (user unfriendliness) will arise.
And you are also suggesting that the GUI, which is supposed to make life a little easier for the user, will make incorrect decisions, even when it obviously knows the OS of the data server (it does copy the file, after all).
Sure hope this gets fixed soon.
Posts: 124 | Location: Lebanon, New Hampshire | Registered: April 24, 2003
It's not a copy opperation. It's a program controlled transfer.
To be honest it requires a hottrack to be raised with IBI support. It should no longer do the 80 Character transformation. The reason? Legacy system support perhaps.
In Dev Studio you have the option to change the extensions assigned to a folder so that different file types are available and to create new virtual folders.
Doing this allows it to work because then it actually is a copy operation. However again this is not possible via MRE
Thanks for your insight. I may understand why it may have been done, but I'm surprised that the side effects weren't considered. A sharp-eyed member of our team noticed that the results of the focexec run were WRONG.
I've opened a case with IBI.
Suzy
Posts: 124 | Location: Lebanon, New Hampshire | Registered: April 24, 2003
jg, when copying the .ftm files out of the agent to a disk space, the mas won't read the ftm. only if the ftm has been filedeffed and the mas copied will it work. i'm in 525/win2k.
Posts: 3811 | Location: Manhattan | Registered: October 28, 2003
How about using APP HOLD instead of HOLD, FILEDEF and COPY ?
APP HOLD <app-foldername>
writes all HOLD files and their MFDs to the specified app-folder. You can set this just before the request producing the HOLD file and reset the default behaviour just after that request by issuing
APP HOLD
This only works for your problem of saving HOLD files and their MFDs for subsequent tasks.
Posts: 54 | Location: Switzerland | Registered: May 13, 2003