DSXchange

Hi,

I have a .pjb file which i received when i sent a DataStage job to my Version control tool using the source control option in IBM Information Server Manager.

Now, when I take this file from my version control tool and manualy import this .pjb file using the Import option in IBM Information server it gets imported correctly.

But when i try to import it through the command line using istool command it doesn't and gives me below error saying filename.pjb not recognized.

I am using the -ar option in istool and giving the .pjb file name here (generally we give isx file name here).

Below are my queries:
1. Can we import a .pjb file using istool command?
2. If Yes, Is there any other option to import a .pjb file instead of -ar? I tried searching but couldnt find.

Any inputs/pointers are welcome. Thank You !!

The exact error I am getting is as below:
Beginning import
Import failed: Error opening archive file /tmp/filename.pjb

1. Can you post the istool command you're using?

2. We can assume you've checked and that the file /tmp/filename.pjb actually exists?

Hi,

1. Below is the command i am trying to execute to import .pjb using istool:
./istool import -domain <Domain_Name>:<Port> -u <username> -p <password> -ar /tmp/filename.pjb -ds ' "<Server Name>/<Project_Name>" '

2. Yes, I have confirmed that the file exists in tmp folder.

Why do you think istool will import a .pjb file?

I can't say that I've ever thought to try it, so I can't say that it won't work.

I wouldn't consider a .pjb file to be an archive file like a .isx file.

A .pjb file is an XML document while a .isx file is a compressed archive file (which could contain .pjb files among its contents).

Mike

Actually we are planning to integrate IBM Information Server Manager with our Version Control tool wherein we can directly send an export of a particular job directly to the Version Control Tool i.e. without performing the manual export and not needing to check-in this export manually in the VC Tool.

Here the problem is, when we send the job from IBM Information Server to the Version control tool, it sends the job export in .pjb file.

Now we want to import this .pjb using the Command Line because we have a future plan to automate the deployment process as well.

This is why we are trying to import a .pjb file using istool command.

Right now we have two options:
1. Identify a way to import the .pjb file through command line
(OR)
2. Identify a way so that Info Server sends a file in .isx format to the version control tool instead of sending it in .pjb.

Thanks !

What version are you on?

If it is 8.5 or later, Information Server Manager already comes with version control tool integration as long as your version control tool has an Eclipse plugin.

With version control integration, it is a simple right-click mouse action to send an object to the version control tool ... no need for a manual export/import scenario.

Now, if your version control tool has no Eclipse plugin, I guess you could try to manufacture a .isx file to encapsulate the .pjb file that you have.

Start by using istool export to generate a .isx file that you can review. It includes a manifest file along with exported objects. I guess you could even just compress the .pjb file and see if istool import can consume it without a manifest file. If it requires a manifest file, you may be able to find a way to generate one that istool would be happy with.

Mike

Hi Mike,

We are on version 8.7 and as you said, we are doing that simple right-click mouse operation and sending the oject in the version control tool but the problem is it goes in .pjb format and not in .isx format in to the VC tool. This is our issue.

Now since its going in .pjb format in the versin control tool, we need to indentify some command to impot it back though command line for which i was exploring istool command.

The other option we are woking on is to check if the object can be sent in .isx format to the version control tool instead of .pjb.

Thanks !

So why the desire to import it back via the command line? Why not use Information Server Manager?

Mike

Because in future we are planning to automate our deployment process to move the code between various environments through scripts instead of Information Server Manager tool.

Thanks. That gives us a pretty good idea about what you're looking to accomplish now. I'd suggest looking at the istool commands for build package, send package, and deploy package. You'll be dealing with deployment packages (.pkg files) instead of individual components like a .pjb file.

Mike

The Problem here is that once a code is baselined and stored in the VC tool, further development on that code in Dev will still continue.

So we cannot directly move the code from Dev to QA and so on using istool package options. We have to import the baselined code from VC tool only.

Regarding option to take exports from Dev in a package and storing that package in VC tool is also not feasible as we need individual components in the VC tool.
This leave us with only below 2 options(incase we decide to use Server Manager for VC) :
1. Identify a way to import the .pjb file through command line
(OR)
2. Identify a way so that IBM Information Server Manager sends a file in .isx format to the version control tool instead of sending it in .pjb.

Thanks !!!

.pjb is the notification for parallel job. Ideally when you export anything out of Information Server Manager, it will export in .isx format; but the message window will display as listed below.

For parallel job.
<ServerName>/<Project Name>/Jobs/<Path>/Test_DB2.pjb

For Server Job:
<ServerName>/<Project Name>/Jobs/<Path>/Test_DB2.sjb

For Sequencer:
<ServerName>/<Project Name>/Jobs/<Path>/Test_DB2.qjb

What is the file extension of your job under /tmp folder? is it .pjb or .isx?

I am sorry to say but I don't see any relation between your post and the questions which I posted.

As far as your question is concerned, the answer is in the Subject Line itself. Wondering how you missed reading the subject line.

Amit_111 wrote:This leave us with only below 2 options(incase we decide to use Server Manager for VC) :
1. Identify a way to import the .pjb file through command line
(OR)
2. Identify a way so that IBM Information Server Manager sends a file in .isx format to the version control tool instead of sending it in .pjb.

Hi Amit,

It seems you've put yourself into a tight box with little room to maneuver...

#1) I don't think there is a tool to import a .pjb file from the command line. If you use istool, you would need a .isx or .pkg file. Even if it were possible to transform a .pjb into a .isx or .pkg, it would be non-trivial and unstable (the vendor can change the proprietary structures of the .isx and .pkg files any time they feel a need).

#2) You'd have to put an enhancement request with the vendor. Since they have already come up with a text representation of a job's metadata (.pjb file), I don't see why they would also want to put a compressed archive of the same thing (.isx file) into a VC repository.

If you step back out of the box and think about some ways to work with the tool instead of against the tool, here are a couple of my ideas to consider (I'd sure like to hear from others that have thought through some of the challenges):

A) Marry version control to deployment. Have your deployment manager build the deployment package and send objects to version control at the same time. This avoids the trap of using version control in place of a sound backup strategy (i.e. only create versions for deployments).

B) If you want to continue using version control independently from deployment, you could create a "Deploy From" DataStage project. Retrieve baselined objects from VC into this project, then do deployments from this project. Only the deployment manager would be given access to this project.

I didn't have time to go to IOD this year (or read Vincent's blog), but I wouldn't be surprised if version 9.1 had some new features supporting version control and deployments.

Version control of generated source code is a whole different paradigm from version control of hand-crafted code. I'm sure the vendor has lots of bright minds working on solutions for the best way to do that. Take advantage of whatever the vendor has to offer now and adapt as they roll out future enhancements.

Mike