Weird Behaviour of dsjob -lparams

[joesat]

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

[chulett]

Can you explain what 'different set' or 'wrong set' of parameters means? What exactly was different or wrong about them? What was different about the Sequence when it gave these results - was it in an Aborted/Restartable status, for example?

[Krazykoolrohit]

Can someone tell me what I missed out in using the dsjob -lparams command? Is there any prerequisite to using this command?

Can you tell us how you used the dsjob -lparms command. As Chulett asked, what was the difference in your output?

[joesat]

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.

[joesat]

Chulett,
I checked with another job that had finished status... this one also shows a different list of parameters... really do not know what's wrong, 'cause all I am trying to do is execute the -lparams command

[joesat]

Chulett,
I checked with another job that had finished status... this one also shows a different list of parameters... really do not know what's wrong, 'cause all I am trying to do is execute the -lparams command

[chulett]

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'.

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.

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.

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?

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]

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.

[chulett]

Actually, I said it does work irrespective of job status.

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.

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.

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?

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.

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?

[joesat]

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)