Weird Behaviour of dsjob -lparams
Moderators: chulett, rschirm, roy
Weird Behaviour of dsjob -lparams
Hi,
I am trying to list the job parameters and use it in a shell script. The -lparams worked perfectly. But after testing it for several jobs and sequences, we found some strange behaviour.
The dsjob -lparams was executed for a sequence as before. But it returned a different set of parameters. We compiled the sequence and executed the command, then it worked fine.
Later, the -lparams worked in a similar way for another function. And then we had to compile the sequence again.
NOTE:
1. The job sequences had already been compiled earlier. But still the -lparams command showed the wrong set of parameters.
2. We have set the restartability option to 'true' for the sequences and hence, it need not be recompiled even if it fails.
3. Also, the jobs will be called from Autosys and hence it will not be possible to open and compile each job everytime.
Can someone tell me what I missed out in using the dsjob -lparams command? Is there any prerequisite to using this command?
Thanks
I am trying to list the job parameters and use it in a shell script. The -lparams worked perfectly. But after testing it for several jobs and sequences, we found some strange behaviour.
The dsjob -lparams was executed for a sequence as before. But it returned a different set of parameters. We compiled the sequence and executed the command, then it worked fine.
Later, the -lparams worked in a similar way for another function. And then we had to compile the sequence again.
NOTE:
1. The job sequences had already been compiled earlier. But still the -lparams command showed the wrong set of parameters.
2. We have set the restartability option to 'true' for the sequences and hence, it need not be recompiled even if it fails.
3. Also, the jobs will be called from Autosys and hence it will not be possible to open and compile each job everytime.
Can someone tell me what I missed out in using the dsjob -lparams command? Is there any prerequisite to using this command?
Thanks
Joel Satire
![Confused :?](./images/smilies/icon_confused.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Charter Member
- Posts: 560
- Joined: Wed Jul 13, 2005 5:36 am
- Location: Ohio
Re: Weird Behaviour of dsjob -lparams
Can you tell us how you used the dsjob -lparms command. As Chulett asked, what was the difference in your output?joesat wrote: Can someone tell me what I missed out in using the dsjob -lparams command? Is there any prerequisite to using this command?
I executed the command in the usual manner, ie.
dsjob -lparams projname job1
But the result of this command yields a set of parameters which are not used in the job 'job1'. Rather it yields a set of parameters from some other job 'job2'.
And yes Chulett, the job 'job1' was in an 'Aborted/Restartable' state. Since the job is being run from Autosys, it will not be possible to compile it everytime it gets aborted. Is there any other way out of it?
Thanks.
dsjob -lparams projname job1
But the result of this command yields a set of parameters which are not used in the job 'job1'. Rather it yields a set of parameters from some other job 'job2'.
And yes Chulett, the job 'job1' was in an 'Aborted/Restartable' state. Since the job is being run from Autosys, it will not be possible to compile it everytime it gets aborted. Is there any other way out of it?
Thanks.
Joel Satire
This makes absolutely zero sense. Status of the job makes no difference in the operation of this function and I don't see how it can decide to pull parameter names from a job other than the one you requested.joesat wrote:I executed the command in the usual manner, ie.
dsjob -lparams projname job1
But the result of this command yields a set of parameters which are not used in the job 'job1'. Rather it yields a set of parameters from some other job 'job2'.
![Confused :?](./images/smilies/icon_confused.gif)
What 'status' does it show? After listing all parameter names, if everything went ok it should also show as the last line returned: "Status code = 0". What does yours say?
Regardless, if you are certain of the behaviour you think you are seeing, then you need to open a case with your official Support provider and see if they can figure out what is going on.
You don't Compile aborted jobs, you simply need to Reset them. Hopefully, you have a 'wrapper' script that you use in conjunction with dsjob and AutoSys and don't have the job run directly. That way, your wrapper can run a standard series of checks before the job is actually launched - does it in fact exist? Is it in a runnable state? Does it need to be reset? Some answers would generate errors, the latter would simply issue the RUN RESET request before the job is run.joesat also wrote:And yes Chulett, the job 'job1' was in an 'Aborted/Restartable' state. Since the job is being run from Autosys, it will not be possible to compile it everytime it gets aborted. Is there any other way out of it?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
I agree with you, Craig. The -lparams command SHOULD work irrespective of whether the job is aborted/restartable or otherwise. And yes, the Status is shown as '0'. Let me brief you on the nature of my 'wrapper script'.
1. The script will take two parameters: proj name and job name.
2. The dsjob -lparams will be executed to find out the parameters required for a job. The parameters will be written to a temporary file.
3. The parameters in the temp file will be 'grep'ped against another file 'the exhaustive parameter & its value' file. Here we will identify the values we need to pass to the parameters required by the job.
4. As each value is identified, we will build the parameter string, i.e, -param param1=value1 -param param2=value2 etc.
5. This parameter string will then be appended to the dsjob -run command and the job will be executed.
I hope I have been clear in explaining. Now since, the -lparams is not working correctly, the whole script seems to be a failure.
Apart from running the shell script, i also tried using the -lparams command in a stand alone fashion and yet it seems to act the way it does.
The requirement for me is that only the project name and the job name have to be given as input to the shell script. And I believe that the approach taken by me is probably the right one.
Please let me know how to correct the issue (other than contacting the support group
) or if there is any other way to restructure the wrapper script?
Thanks.
1. The script will take two parameters: proj name and job name.
2. The dsjob -lparams will be executed to find out the parameters required for a job. The parameters will be written to a temporary file.
3. The parameters in the temp file will be 'grep'ped against another file 'the exhaustive parameter & its value' file. Here we will identify the values we need to pass to the parameters required by the job.
4. As each value is identified, we will build the parameter string, i.e, -param param1=value1 -param param2=value2 etc.
5. This parameter string will then be appended to the dsjob -run command and the job will be executed.
I hope I have been clear in explaining. Now since, the -lparams is not working correctly, the whole script seems to be a failure.
Apart from running the shell script, i also tried using the -lparams command in a stand alone fashion and yet it seems to act the way it does.
The requirement for me is that only the project name and the job name have to be given as input to the shell script. And I believe that the approach taken by me is probably the right one.
Please let me know how to correct the issue (other than contacting the support group
![Wink :wink:](./images/smilies/icon_wink.gif)
Thanks.
Joel Satire
Actually, I said it does work irrespective of job status.
Meaning what, exactly? That just running it from the command line it works fine or it exhibits the same (wrong) behaviour? If the former, then I'd say your issue lies with your specific implementation in the script and not the function itself. If the latter, then we're back to contacting Support.
And seriously, if you are saying that the function somehow returns invalid parameters for you, then you need to contact Support to find out what in the heck is going on. No-one here can explain why an internal function that seemingly works fine for everyone else isn't working properly for you or in your installation, you'd need to go back to The Creator for that. Did you throw Mr Winkie in with your 'other than contacting support' comment because you are not under any kind of support contract?
![Wink :wink:](./images/smilies/icon_wink.gif)
joesat wrote:Apart from running the shell script, i also tried using the -lparams command in a stand alone fashion and yet it seems to act the way it does.
![Confused :?](./images/smilies/icon_confused.gif)
Your approach sounds fine. Without seeing your actual script, I don't really see how anyone could comment on the structure or if there was a need to 'restructure' it.joesat also wrote:The requirement for me is that only the project name and the job name have to be given as input to the shell script. And I believe that the approach taken by me is probably the right one.
Please let me know how to correct the issue (other than contacting the support group) or if there is any other way to restructure the wrapper script?
And seriously, if you are saying that the function somehow returns invalid parameters for you, then you need to contact Support to find out what in the heck is going on. No-one here can explain why an internal function that seemingly works fine for everyone else isn't working properly for you or in your installation, you'd need to go back to The Creator for that. Did you throw Mr Winkie in with your 'other than contacting support' comment because you are not under any kind of support contract?
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
It works the same wrong way from the command line too...the 'winkie' was because I will have to raise this issue to my client and that would have to be done only in the rarest of rare cases...
I will try to find out if there's any alternative support available within my current framewrok (without going to my client)
I will try to find out if there's any alternative support available within my current framewrok (without going to my client)
Joel Satire