DSXchange

All,

I have been here for long time. Although i am unable to get clear picture about the usage of UV Database, usage of UVstage, relationship between current repostiry (DB2) and UV, relationship between DB2 repository database and XMETA database. It is always confusing If i read any post regarding this topic, it is confusing more. I just wanted to put full stop for this confusion. I hope i can get some good treatment here for my confusion sick Just kidding

In our company we are using DB2 as the repositry. But if i use UV stage to execute select * from DS_JOBS, it is running fine..really confusing
is UV database still used in 8.1 version? what is XMETA database?

let me put it in this way...
---------------------------------------------------------------------------------
I am creating a new parallel job in 8.1 version? we are using DB2 as the repository? if it is stored in DB2 repository, do i see the job in UV database thorugh UV stage ?

If yes, why and how?
If no, how to view the job information like (SELECT * FROM DS_JOBS)?

what is the role of xmeta here?
---------------------------------------------------------------------------------

---------------------------------------------------------------------------------
I am creating a new parallel job in 7.5 version? we are using DB2 as the repository? if it is stored in DB2 repository, do i see the job in UV database thorugh UV stage ?

If yes, why and how?
if no, how to view the job information like (SELECT * FROM DS_JOBS)?

what is the role of xmeta here?
---------------------------------------------------------------------------------

I have seen the below query in our site.

SELECT NAME FROM DS_JOBS WHERE JOBNO IN (SELECT OBJIDNO FROM DS_JOBOBJECTS WHERE EVAL "@RECORD" LIKE '%.sh%');

EVAL "@RECORD"

what it will do? how to learn from A-Z about writing queries against DS_JOBS table ? atleast A-F (6 letters )

what else keywords like @RECORDS can be used in DS_JOBS queries?

any inputs please ?

Don't "push", particularly on weekends!

karthi_gana wrote:we are using DB2 as the repository?

My inputs:
1. You should not ask strangers if you are using DB2 as the repository.
2. You have asked far too many questions for one topic. Too confusing.

Look thru the forum. Many/most of these questions have been answered, in various contexts. Some of it is historical, and some is purely functional (for example, I use UV Stages to do very creative pivoting, and there are lots of customers who have applications written on UV --- and yes, it could also be used for access to the legacy repository, but that's just a nice side effect).

Xmeta is the main rdbms for ALL of Information Server ...not just DataStage....Business Glossary, Metadata Workbench, FastTrack, etc...and holding all kinds of Metadata from those offerings. Run time componentry requires that some of the UV structures remain.

Ernie

@RECORD is a Universe concept. Several of us were Universe programmers before DataStage. DS_JOBS and DS_JOBOBJECTS are tables in Universe. DataStage uses a version of the Universe database to store job designs. The original version of DataStage was written completely in Universe.

Only a few fields are stored in DS_JOBS.

LIST DICT DS_JOBS

Will show the fields or columns in this table. There are also hidden columns. The LIST DICT command is like describe in Oracle.

Most of the columns in DS_JOBOBJECTS are hidden. We have figured out where some are stored because we had to at some point. In the beginning on versions earlier than version 3, a new version of DataStage would break all our jobs. So we would write programs in Universe to upgrade the jobs to the latest version. This meant moving columns around in DS_JOBOBJECTS. So we learned where they stored job and stage properties.

Most Universe tables are hashed files. They are many versions of hashed files. All Universe records are one long string. Each field or column is separated by a field mark. It is called @FM in BASIC. So using @RECORD in and EVAL says retrieve the whole record. Ray then uses LIKE to search all fields in every record. Very clever solution.

qt_ky wrote:

karthi_gana wrote:we are using DB2 as the repository?

My inputs:
1. You should not ask strangers if you are using DB2 as the repository.
2. You have asked far too many questions for one topic. Too confusing.

oh...

it is full stop only.

I use UV Stages to do very creative pivoting

Really! How? I am curious to know.

Thanks duke. i am sure it will take some time for me to gain some good knowledge on UV side may be based on experience

But i will try my best to learn as much as possible about UV with your people help.

Moving to some of my questions...

---------------------------------------------------------------------------------
I am creating a new parallel job in 8.1 version? we are using DB2 as the repository. if it is stored in DB2 repository, do i see the job in UV database thorugh UV stage ?

and yes, it could also be used for access to the legacy repository, but that's just a nice side effect).

If yes, why and how? (because of that side effect ???)

If no, how to view the job information like (SELECT * FROM DS_JOBS)?

what is the role of xmeta here?
---------------------------------------------------------------------------------

---------------------------------------------------------------------------------
I am creating a new parallel job in 7.5 version? we are using DB2 as the repository. if it is stored in DB2 repository, do i see the job in UV database thorugh UV stage ?

and yes, it could also be used for access to the legacy repository, but that's just a nice side effect).

If yes, why and how? (because of that side effect ???)

if no, how to view the job information like (SELECT * FROM DS_JOBS)?

what is the role of xmeta here?
---------------------------------------------------------------------------------


Any inputs?

Why not concentrate on becoming the best DataStage developer that you can? There's no need for detailed technical knowledge about how the engines, the services and the metadata repository work - finer minds than ours have spent vast amounts of time making these work as invisibly as possible.

A side note. Forget about XMETA while you're on version 7.5. It simply does not exist.

And documenting queries that will work in version 7.5 is a waste of your time - everything changes radically when you move to version 8.0 or later.

We are using 8.1 version only. The new development works are done in 8.1 version. The existing jobs are running in 7.5. We just provide support for those jobs.