...Once you get into utb with tam browse function on, feel free to come back for clarification on all the stuff you see. It can be a little overwhelming at first.
You might want to check out a doc on the knowledge garden called Change Management: Managing OneWorld Development (you'll have to do a search for it). Although, it's not an instruction manual for this, it does have extensive information on the relationships between various spec files. Check out the chart on page 8 for a quick overview of the spec files.
owguru (at least I'm trying
You're probably out of luck on this one. While there are functions in the jde system code that access the tam files, they are not really meant for "public consumption". They are certainly not documented, or as jde calls it, "published". And it would most likely take you longer to figure out how to use them than to jump through the hoops inside oneworld to do whatever you need to do. Furthermore, if you did accomplish this, you would most likely have to do it all over again after an upgrade as jde enjoys reworking all the hidden stuff on a regular basis...it keeps all those developers employed!
If you would like to share your specific goal, I would be happy to make a few suggestions if I can
owguru (at least I'm trying
Will you be so kind and help me into retrieving the document you're previously describing? I tried the search; it's a complete noway_to_get_it_Adrian since they'd change it. Do you have the ott#?
Thank you and Congratulations again,
Would you allow me to say owgura/journeywoman, please?
As usual, OWGURU is right. I agree her and advise you to consider her arguments.
On the other hand, which TAM do you want to write and why.
I have already done it for language translation purpose as we use Hungarian language. OneWorld has Hungarian version first time in XE but won't under B7321, B7331 and B7332.
Here is our story briefly.
When we started with the first B7321 OW implementation there was a really appreciatable need that the users wanted to see a Hungarian application instead of an English one because not a common in Hungary that all employee speaks English.
Our guys and girls struggled a lot to translate forms and reports with the very "advanced" vocabulary override application and exporting it onto excel sheet from our inhouse system and implementing it somehow at our partners system. It was a horror. This was the time when I started with OneWorld.
I investigated the Object Librarian, how to Check In, Check Out and Erase Checkout and the Vocabulary Override application how to retrieve domestic texts and language overrides and how to update them.
I copied the IVO application and made a "little" enhancement on it, e.g. showing the original and the translation text together, preventing the user to override the original texts with our translations and vica versa, etc.
I created an other application which managed the translation extraction on one system, transportation and implementation on an other system, based on a form list and with a minimal need of user activity. As you know, Vocabulary Overrides needed Check Out and Check In under B7321.
I was very proud that I was able to make it just starting with OW and we could spare a lot of human work and possible error.
On the summary of 1999 I just spent my holidays at lake Balaton when I receved a phone call from my boss asking me that could we transport our translations from our B7321 to a new B7331 because we will starting with it at a new partner and we have a close deadline. I asked my young colleauge who just started with OW to compare the Interactive Vocabulary Overrides application on the two systems. He reported me that they are totally row by row identical. I calmed down.
I returned to the office after my holiday and what a horror. The override handling dramatically changed in B7331 e.g. it doesn't need Check Out/In anymore. The old application (P9820 if I remember well) also exist under B7331 but without functionality and OW used a brand new P9220 application. Unfortunately, my young colleauge had compared the P9820 application.
We workd days and nights to figure out how to transport our language overrides from B7321 to B7331. Finally we made some "one time use" application strongly modifying the copy of P9220 and writing some BSFN, creating an English_Hungarian dictionary where translations were weighted on Form, Appl and System Code level making able to find the best text to text translations when the same English text has more translations. It was a nightmare but we resolved it and the qualty of the translation was pretty good.
After this running started my second round.
I made our new and more advanced translation tools, this time taking more help to the translators and keeping the consistence of the translations of the very standard (PHYPER) and the standard text (e.g. Form, Report, etc.). I made some automatical translation process for the very standard and standard terms, etc. This time not for APPLs but for UBEs and DDs.
I made my brand new and more advanced Extraction/Transportation/Implementation application for the translations.
These developments contain several APPL, UBE, BSVW, DSTR, BSFN and TBLE.
During this time I worked almost all days on the weekdays too.
Finally I advice, make some consideration before you start.
Writing to TAM: While I do not argue with OWGuru, there are some cases when
you simply MUST write to spec files or forget the whole idea. I'll briefly
describe when we had to do it, and what we did:
As some of you may know , JDEdwards writes all it's printable reports to
PDF. What most of you probably don't know is that Adobe DOES NOT support
Cyrillic characters in PDF, unless font is embedded. Acrobat Reader can be
fooled into using Cyrillic font, but it uses standard font spacing, which is
very different from Russian (the language I'm actually talking about). This
makes reports, which are printed using standard Arial font, very hard to
read. There are two possible solutions: either change report font to a
monospace font, or insert correct spacing info into PDF by a post-processor.
By the time we worked on solution, we have not considered the second option
(I never told I know how PDF is structured). Font override application is
only working for double-byte language.
At first we selected a list of reports we considered critical and had 2
consultants (junior, but precious still) go into each report and each
version of each report and change font. It took 3 days for less then 100
reports. And then we decided we need to do something. We've spent some time
examining related Central Objects tables, looking at them both in BLOB
fields and with UTB, experimented a little, and finally came up with a
program, which processes a pathcode for B7332 in less then half an hour. All
of programming took less then two days, and most of the time was spent
fixing different VB and VBA issues, and having the programmer accustomed to
Oracle and OneWorld. I can't describe the joy I felt when I say the program
working. Even the fact that we have to rerun it every now and then, because
Arial is leaking thru, did not spoil the joy.
A couple of tips for those, who have to do it: Don't be afraid, just be
careful and take your time. Use TAMMenus=Show and examine the BLOB contents
from two sides. In header files, at least some TAM structures are described
(for those who don't know, as I did not - BLOB is just storing a C
structure). Do some experimenting with simple reports/applications you
create specifically for this purpose, so you can easily test it. Do it first
in DEV or CRP.
And another tip, for those just curious: there are other interesting things
both in OneWorld and in outside world, explore those and don't mess with
Hope you'll find it usefull,
PS: If you ask me, if we had the problem completely solved - the answer
would be, NO. But it got better and we can live until SP 15, where they
promise to fix everything
PPS: I'm sorry, I'm not a programmer, but those of you, who need specifics,
can mail me off-list and I'll forward your mail to our developer.