DataStage Backup and Recovery from Server

[ag_ram]

kduke,

Thanks for your comments.

I have been using Universe since 1986 and I would never do any of this

Here and now my first question would be 'Could you provide me any valid reason for the question that why didn't you involve yourself in these UniVerse commandsin your more than 20 years of experience?'. And with a best knowlegde of what these uncommon commands do exist to mean in UniVerse since product's birth, if you possibly feel that these commands wont mean to be useful at any situations where we work hard enough to find a worthful solution and strongly believe that most of people as of now do not have any bit of interest on this, let the UniVerse architect know your perception and take these commands away from uniVerse in the next releases.

Perhaps, i may state this for a need of connoting that inquiring into unusual and untouched objects would make feel that that newness will no longer as it is ever. There is nothing wrong in exploring those commands at first and investigating how and where they come to mean what they are born for and deriving a best of possibles which need those commands.

Export/Import is by far the best way to recover a job

True.

The Exporting/Importing DataStage components as dsx file is the best way to back up/recover a Job. But, in this thread, i say that this is a possible way to recover a Job from Server side backup file.

Your advice seems to be misleading on purpose.

Would you mind if you let us(me) come to know where misleading takes its chance here? If you dont like to follow this way of backing up and restoring DataStage components for a stronger reason behind(it is not my method, though), please dont disturb the listener's as they are quiet busy discussing with me everything of it.

If you keep giving bad advice then we need to ban you or do something drastic.

First of all, this is not such bad advice as you think but a possible solution when we have no clue to proceed back up/restore actions at server side. What has been my duty here is to explicate the usage of uncommon commands which do what we need at server side. Dont do any actions(banningo or doing something drastic) to anyone but instead you can make him/her feel the badness of the ideas which he/she comes up with, in a matured way, if he/she really comes up with bad solution.(this is what an expert does all the time)

I would like to ask you one question- could you ask ray.wurlod that why he prefers this method of backing up/restoring DS components[said in this thread]

You argue with Ray, Arnd and others, our most devoted posters.

There are no arguments but a smooth discussion in a fine tune so long with the experts, of course, the devoted posters in DataStage. By the way, they here seemed to be asking questions on using these commands and as far as i know i just do my part as answering their queries with a visible background experimention. When a new unsaid method is likely to be declared out here from me, they(ray.wurlod, ArndW) do their duty as what an expert would do at the end as checking possibilities in all corners. one thing that we need not be afraid to announce an uncommon-but-truth method to the public or to the experts, even they would like to welcome it, if they are satified in all the way.

I wish you would just quit or leave this site.

Please never drop words like this to at least anyone else as words do possess high emotions inside and more powerful than anything in this world. If you wellknow of how bad this advice is and where the term 'misleading' is born, please share your pointers and views on it with me and make me feel ashamed, if it is anyway as such.

Most of the posters here are or try to be professional.

We have been discussing all our views in a professional manner more than how it has been yesterday.

If you face any diificulties in using this method, please share with us.

[ag_ram]

ArndW,

The question you just bring in, could be the first question from you in this thread as doubting that how this solution would be a comfortable method of doing back up and restore process to a lay man who does not care about the DataStage internals at any point of time.

The underlying statement(maybe, a requirtment) would be that the user who tends to delve himself in this method, must keep a good knowledge of DataStage internal files as what it is and what it contains inside, in terms of the real DataStage components beside.

What if we take this question to the persons who always have a habit of doing backup from server side, as we said in thread?[In the corners of site there must be at least a few people holding this idea for a long time.].

Possibly we expect a reasonal statement from one of the users - ray.wurlod. He may convince you by simply stating that this solution needs a fair understanding of DataStage internal files with regard to basic UniVerse concepts, though he seems to test all heads of possibities here.

That warning(this will probably cease to work with some future version) does seem to be good to make us take precautionary steps for the next versions. And one thing that as long as it is with us and we are with that, we can possibly have this solution in mind until we have a shift.

[ArndW]

ag_ram - you have managed to post 5 paragraphs without actually adding anything to the thread or even coming close to touching upon the thread topic.

I do find it amusing to see that you recommend that I delve into the internals of DataStage and even funnier to see how you lecture me on the use of uvbackup and uvrestore. That is a rather interesting comment from one who has recently starting delving into the dark heart of DS to make - considering that the last tiem I taught the UniVerse internals class was about 10 years ago. Then again, I am getting somewhat long in the tooth; I still think of coffee when I hear the term "java" but can remember the relationship between a Fibonacci series and DataStage server string.

I suppose that instead of being polite and asking you a question (to which I know the answer) so that you can think about what you are saying and giving you an opportunity to withdraw, I really should be more straightforward in my responses to you in the future.

...That warning(this will probably cease to work with some future version) does seem to be good to make us take precautionary steps for the next versions. And one thing that as long as it is with us and we are with that, we can possibly have this solution in mind until we have a shift.

I cringe when I think that you consider this use of undocumented product functionality acceptable. Given the rate of changes in the product, both major and "dot" releases, the life cycle of any backup scheme based on using these internal structures is going to be less than year. I, for one, would never dream of producing (and charging for) product with this short a lifespan. And no customers that I have ever worked for would have accepted this, unless there were some very pressing business reason behind that decision.

[kduke]

This is not a discussion. A discussion is 2 people trying to learn from each other. This is one immature person trying to promote himself at the cost of others. Others who have invested lots of their valuable time and effort to help make all of us better DataStage developers. You are not helping anyone including yourself. I know how these commands work and I know the internals of a lot of these products including uniVerse. We were the 30th customer of VMark when we bought uniVerse. We started with the beta version of DataStage. I would still never restore a job with uvrestore unless there was no other way.

Explain to me in what way, shape or form does this topic benefit or help DataStage developers.

I learned the internals of DataStage because I had to. When they shipped version 1.1 they broke all of our 1.0 jobs. So I wrote BASIC programs to fix them. This saved us a lot of time in not having to redesign all our jobs. The same thing happened when they shipped the next few versions until about version 2.2. They actually upgraded our old jobs. I think I know how to fix a job at very low level. Been doing it for 10 years now. I have done similar things in uniVerse for many years now as well.

Your comments are saying my experience and Ray's and Arnd's and Craig's does not mean much. Many of these guys have more experience than I do. If Ray says something I listen. I have leanrned a lot from these guys. But your wisdom is far greater. It must be because you choose to ignore these guys. Please give us your background. Also give us your real name. Everyone knows our real names. We have nothing to hide.

Maturity is about doing the right thing. Integity is about doing the right thing because it is the right thing no matter what it costs you. I think I have defended what I consider is valulable and the people I consider to be pure of heart. These people have added value to my development skills. I admire them very much for their efforts. I admire them for being patient with you because I know how much they disagree with you. I know lots af talented developers and very few have gone out of their way as much as Ray and Arnd to help others. I trust their opinion because they have earned my trust.

[ag_ram]

ArndW,

I immensely request you not to delibrately take my first or further posts as a piece of advice to the man who knows how to smell the goodness of each cell in all the way as being with UniVerse more than twenty years. We(especilaly, I) contribute my whole respect to you for being an expert in using DataStage with profound understanding of uniVerse functionalities.


By the way, i may ask you to answer these questions with pleasure.

1. Would you like to share your bad experience or unexpected difficulties in using these commands at server side for an obvious need of taking backup at server side, which may apparantly cause you not to use these unknown commands further ever?

2. Could you provide any valid reasons for the present developers who know DataStage internals, always stay in the search of grabing an oppurtunity to take backup at server side using this method, not to go with this solution?

If you provide me any valid positive answers, let me also throw these commands away from here.

Possibly we expect a reasonal statement from one of the users - ray.wurlod . He may convince you by simply stating that this solution needs a fair understanding of DataStage internal files with regard to basic UniVerse concepts, though he seems to test all heads of possibities here.

If that user comes in this thread, he may possibly give the needed answer which we should listen to for now and ever.

[ag_ram]

kduke,

I initially searched a good answer for the questions i raised when replying to your initial post but unfortunately they seem to be not found. Your exposure in UniVerse and tactics in DataStage upgradation look good as expected as you are always, and there is a known statement that you were also one of the pillars who have the strong basic understanding of this product in all corners.

If you allow, i may be requested to say that a real expert listens each and every word from whoever drops in and analyses it with his/her intellectual ability in a detailed way of extracting the truth from it then welcome the speaker if it is the truth of all time otherwise correct the speaker in a convenient way. Though all, i respect all those experts(ray.wurlod, chulett, AndW and more people) as by looking at those words carefully and searching a deep meaning in them for every questions in this forum.

Please advise me not using these commands this further, if you are to provide valid answers for the same questions below.[though reminding myself that overquoting is not appreciated anyway]

1. Would you like to share your bad experience or unexpected difficulties in using these commands at server side for an obvious need of taking backup at server side, which may apparantly cause you not to use these unknown commands further ever?

2. Could you provide any valid reasons for the present developers who know DataStage internals, always stay in the search of grabing an oppurtunity to take backup at server side using this method, not to go with this solution?

Please give me valid postive answer, i am always in position to agree it.

[kduke]

In order to restore these hashed files you need to understand the internals of DataStage. One job is stored in many hashed files. It is not worth the effort to restore all these hashed files to get one job back. I can easily restore any job from an export. A lot less effort. The job can also be restored to different versions of DataStage. I can post it on my web site and let others download it and import it to their version of DataStage. I have tricked DataStage by editing a DSX file to restoring to an older version of DataStage. It will upgrade the job if restoring to a newer version of DataStage. How many reasons you want?

Here is a big one, IBM supports importing and exporting jobs. It does not support updating repository tables directly. I like IBM support. My company likes IBM supporting their business.

I know uniVerse commands as well as most of these people. Many years consulting on many different UNIX platforms before becoming a DataStage consultant. It is a lot of effort to restore jobs this way. Try restoring job your way to a new project. Very ugly solution. I taught uniVerse classes for VMark. Ray still teaches these classes. I am pretty sure Arnd has taught these classes. I have several products which update or read these hashed files directly by going around the APIs. I use many of the APIs as well. I have updated these files with VB, Delphi, Java, C and other languages. I still would not restore a job this way. I know the level of effort to do it both ways.