DSXchange

Jobs that were compiling yesterday morning cannot compile. I hit compile in designer, window says job compiled successfully, but director still says not compiled. When i try to run the job i get notfication that job is not compiled, its not just one job, its with all the Jobs. Mind you this code was from 8.0 and migrated to 8.7 and did compile before.

When i create new Job it gets compiled with no issues.

I have tried following with no luck:

1) deleted Job reimported from 8.0 without execuables to DS 8.7
2) copy the Job and try compiling
3) have forced compiled
4) checked the RT_* files and they are part of same group (dstage) as I am, and have access.
5) compiler xlc_r is there and is working because when i create new Jobs it gets compiled, all existing ones cannot.
6) DS Admin command line when I do LIST DS_JOBS <job name> i do get Job number etc.
7) Created another project, imported same Job and still won't compile.
8: Recompiled previously compiled Jobs (which were compiled on 8.0)resulted in changing their status to "Not compiled" but a test Job created on 8.7 and compiled before was recompiled with no issues.
9) ran DS.CHECKER on project

What could be the problem? and what should I try. I want to nail down the problem instead of recreating the new project.

Thank you for your help

Looks like its time to talk to IBM support

I did face import/compile issue when we migrated from 7.5 to 8.1 and when raised an incident with IBM support they took a look and gave a patch which had set things right

@zulfi123786: Did you ask IBM what is included in this patch? any reference or details? was this patch to fix UV information about the project.

zaino22 wrote:Jobs that were compiling yesterday morning cannot compile.

What has changed?

Were using LDAP security then switched to WAS security with sharing registry option Checked off, and user's own credential are used instead of dsadm.
To prove if code is working created another project and imported this useless project without exe and recompiled and working fine.
This doesn't tell me what was wrong with it so we can avoid it in the future.

That Brings me to another topic - using App IDs to run jobs - but I don't want to veer anyone off the topic.

The three possibilities are LDAP, operating system or IIS internal user registry - there's no such thing as WAS security. I'm assuming you now have the third of these.

Have you properly set your DataStage Engine Credentials (in the Domain Management menu on the Administration tab of Web Console for InfoSphere Information Server)? Does the mapped user have execution permission to the compiler and its libraries? Are its command and shared library search lists correct?

Sorry didn't know WAS security doesn't exist. Then I guess we are using Operating System security but not LDAP for sure. I was told, we are not using LDAP because LDAP doesnt allow generic ids (like appadm, dsadm) to login into applications (I have a feeling it is incorrect but I dont have a documentation to find out how to setup LDAP so that "appadm" and "dsadm" can login.)

Here is how settings are: Web Console > Admin > Domain Management > Engine Credentials
Name= Server123, User Registry= Shared

on right hand side:
1) Open Configuration: box is checked=Share User Registry between InfoSphere Information Server and its engine;
Column "Default Credentials" has user name "dsadm" password blanked out.

2) Open My Credentials: my "Unix user ID" is greyed out and note says " The credential mapping is not activated for this engine. Your InfoSphere Information Server credentials will be used. "

3) Open User Credentials: Suite Users= "dsadm",
InfoSphere Information Server Engine Operating System Users="isadm";
Suite Users="isadm", InfoSphere Information Server Engine Operating System Users=dsadm.
Both values are unchecked and Assign User Credentials column on the right is greyed out with no values.

Any suggestions?

I wish everyone a very Mery Christmas and a very happy Happy New Year.

LDAP is merely a protocol for invoking something else, such as Tivoli or Active Directory. It's in those other environments where one sets up all the user IDs, even "service accounts" as they're usually called.

On the Global Security page of the Integrated Console for WAS, what is the "Realm" setting?

Thanks Ray for responding on Xmas eve. I feel grinch
I will take a look at the setting on Thursday and let you know.

Thanks again for reply and Merry Xmas.

Hi Ray, here is some of the info:
"Use realm-qualified user names" box is unchecked. Administrative and application security is checked and java 2 is not.

"LTPA" radio button is selected for authentication.

User Account Repository: Local operating System.

Updates:
apparently, dont know what resolved the issue but its resolved. We removed the connection information, recreated all the connections, imported metadata in IA, and boom its working.
IBM doesnt know the answer what was the reason this issue occurred.

Thought I should post this in case someone is looking for answres.

We experienced this same issue today. In our case we had to restore our project from XMETA. Our developers found the same looping compiler issue on some of our jobs.

We finally found that all the jobs that were stuck in the loop were using parameter sets. We deleted a set and replaced it with a fresh set and boom it worked

Can't really explain why the parameter set is the cause.

Thanks for the your input.
I agree it'd nice to find out what caused the error. Our Project which had this error was also using Parameter set but that we never deleted, and reimported.

To this day what resolved our issue is a mystery.