Regarding UV.Account
Moderators: chulett, rschirm, roy
Regarding UV.Account
Folks,
Inorder to access DS Repository Files thru Hashed files I think we need to configure UV.ACcount file on the server.
Is tht right?
If so, could you let me know how can I configure this file. When I try to open this its not in the readable format.
Help me out
Thanks in Advance
rajesh
Inorder to access DS Repository Files thru Hashed files I think we need to configure UV.ACcount file on the server.
Is tht right?
If so, could you let me know how can I configure this file. When I try to open this its not in the readable format.
Help me out
Thanks in Advance
rajesh
The UV.ACCOUNT hashed file contains information about the projects and other accounts in the DataStage instance. Changing any values in this file might result in a DataStage project or the whole system becoming absolutely unusable.
You don't need to do anything in the way of configuration in order to access local DS repository hashed file or tables. I'm sure you are aware that the content and structure of these tables is not only complex but also undocumented by IBM/Ascential; and the same warning applies as with the UV.ACCOUNT file - any changes you might make to these files might result in a broken project.
You don't need to do anything in the way of configuration in order to access local DS repository hashed file or tables. I'm sure you are aware that the content and structure of these tables is not only complex but also undocumented by IBM/Ascential; and the same warning applies as with the UV.ACCOUNT file - any changes you might make to these files might result in a broken project.
the uvodbc.config file is used to define the access to ODBC sources. The project hashed files can be accessed by using the ODBC connection localuv.
Explaining access to the repository files is something of a catch-22 for me in this context. If you need to ask how you can connect to them or access them then I am worried that you might inadvertantly change them and render your whole project useless. DataStage allows users access to modify these files because they know that the only changes are going to be made through the defined API of the DataStage clients; but by going straight into the files by another method circumvents that protection.
Explaining access to the repository files is something of a catch-22 for me in this context. If you need to ask how you can connect to them or access them then I am worried that you might inadvertantly change them and render your whole project useless. DataStage allows users access to modify these files because they know that the only changes are going to be made through the defined API of the DataStage clients; but by going straight into the files by another method circumvents that protection.
thank you Arnd for the information,
I am able access 'localuv' thru Universe but nor thru ODBC. But i find no
tables/ files when connected thru localuv. (Except <projectname>.example1 file)
As these hashed files are DS repository files, i hope these store metadata.
So my intension is to just retrieve this information from these files/tables
but not trying to change any of the hashed file content.
I am able access 'localuv' thru Universe but nor thru ODBC. But i find no
tables/ files when connected thru localuv. (Except <projectname>.example1 file)
As these hashed files are DS repository files, i hope these store metadata.
So my intension is to just retrieve this information from these files/tables
but not trying to change any of the hashed file content.
The Repository files are not listed or their columns described anywhere within the DataStage documentation. I recall seeing a post where Ray described some of the files... let me do a search ... aha, here it is
I hope you understand why I am being so reticent about this - it takes a while to understand the contents and some knowledge of UniVerse file structures, particularly multivalue columns and field, is necessary.
This reminds me of how I was treated by the person behind the counter when purchasing explosives. The store is not labelled at all on the outside and there is nothing on display except a large counter and a register/phone/credit card machine. The employee will not answer any questions; unless you tell him exactly what and how much of it you want and produce a license you won't get anything at all. The same things applies to the internal tables - if you don't know what to ask for it is best that you don't touch it.
If you look at the documentation tool and at the Microsoft Access .mdb file format it will show some of the repository metadata.
I hope you understand why I am being so reticent about this - it takes a while to understand the contents and some knowledge of UniVerse file structures, particularly multivalue columns and field, is necessary.
This reminds me of how I was treated by the person behind the counter when purchasing explosives. The store is not labelled at all on the outside and there is nothing on display except a large counter and a register/phone/credit card machine. The employee will not answer any questions; unless you tell him exactly what and how much of it you want and produce a license you won't get anything at all. The same things applies to the internal tables - if you don't know what to ask for it is best that you don't touch it.
If you look at the documentation tool and at the Microsoft Access .mdb file format it will show some of the repository metadata.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
You never really stated what your issue was. Be very, very careful with Repository objects; if you cripple them your support provider won't help and you may even void your warranty.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.