DSXchange

How does a before routine process parameters passed in the command line? I can get it to read default values but not what is passed via the command line?

What is your command line?

I was accessing the parameter before the READV statement. I had the following lines of code, which was merely returning the default values of DataStage parameters.

ParamValues = STAGECOM.JOB.CONFIG<JOB.PARAM.VALUES>
env_flag = ParamValues<1,ParamPos>




In the following code block, the READV statement populates dynamic array ParamValues with parameters from the JOB.PARAM.VALUES record in datastage. env_flag is the parameter I was trying to get from the command line. Once I moved the env_flag assignment after the READV block I was able to get the command line parameter.

Readv ParamValues From DSRTCOM.RTSTATUS.FVAR, StatusId, JOB.PARAM.VALUES On Error
Release DSRTCOM.RTSTATUS.FVAR, JobName On Error Null
ErrorCode = 1
Call DSLogFatal('File read error for ':StatusId:' on ':StatusFileName:'. Status =':Status(),RoutineName)
Return
End Else
Release DSRTCOM.RTSTATUS.FVAR, JobName On Error Null
ErrorCode = 2
Call DSLogFatal('Failed to read ':StatusId:' record from ':StatusFileName,RoutineName)
Return
End

env_flag = ParamValues<1,ParamPos>

Call DSLogInfo("Env_flag is ":env_flag,RoutineName)

You really shouldn't be reading those values from the internal structures. The call to DSGetParamInfo() will return the same values - and will also work at the next release while I am fairly certain that your code as it stands will cease to work.

The reason I asked about the command line is that DS jobs don't really have one - they are invoked with a list of parametername-value combinations from a sequence or something similar when invoked from a command line call of "dsjob". You were looking to get the runtime values for the parameters from teh "command line", right?

Be aware that any DS/BASIC code you see that uses variables/common blocks defined in any $INSERT/$INCLUDE statements apart from the documented JOBCONTROL.H is neither supported nor guaranteed to work. There are some cases where functionality is not available through the API where use of the internal structures can be condoned, but this isn't one of those exceptions.

It's ashame that may not work in the next release. I have another block of code that lets me set parameters for the job in the before routine:

Writev ParamValues On DSRTCOM.RTSTATUS.FVAR, StatusId, JOB.PARAM.VALUES On Error
Release DSRTCOM.RTSTATUS.FVAR, JobName On Error Null
ErrorCode = 5
Call DSLogFatal('File write error for ':StatusId:' on ':StatusFileName:'. Status = ':Status(),RoutineName)
Return
End Else
Release DSRTCOM.RTSTATUS.FVAR, JobName On Error Null
ErrorCode = 6
Call DSLogFatal('Unable to write ':StatusId:' record on ':StatusFileName:'. Status =':Status(),RoutineName)
Return
End

I have already seen in both my own test results and explained in these posts that DSSetParams does not work in before routines. Will the above code also not work in the next release (which sets job parameters) also?

Arnd should have been more definite. Using these internal, undocumented structures will not work in a future release, because the next release delivers metadata via a service (the Metadata Delivery Service), not out of accessible structures. Nor are the metadata stored in a UniVerse-like database any more, so that you can not even expect to be able to access RT_STATUSxxx etc.

What would be most recommended if special constants and variables will not be available in future releases? I am currently using a before routine to get database connection information for a given table. The routine then sets the connection parameters for a DB2 stage. Can I use a job sequence with a routine activity that does the same thing? It would get connection parameters for a given parameter, set the parameters for a job and then run it.

What is the best (and safe) way of doing it?

devnull - what we are saying is that the undocumented stuff will cease to function. Any documented features such as before-subroutines will continue to work.

My question remains unanswered. Perhaps I am not posing it clearly enough. The code I posted earlier is in a before-routine that retrieves database connection information and sets corresponding parameters in the current job. I am using undocumented datastage variables and constructs to set those parameters. DSSetParam, a documented job control function will not work in a before/routine. and earlier posts have said that this cannot and should not be done. What am I supposed to do if I want to use a routine to set parameters for a particular job prior to running it? Do I use a job sequence with a routine activity? What are my options?

This is not the original question, but to answer it: setting parameters should be done in the sequence that calls the job, as you've already correctly surmised.
It used to be possible to change a job's parameter values in the job control, but this functionality was removed and the code you are using circumvents this restriction.

You can interrogate the job's parameter values using calls to DSGetParamInfo() using DSJ.ME as the job handle and DSJ.PARAMVALUE as the InfoType argument. Read the online help for DSGetParamInfo() to learn what else you can discover about parameters.

As Arnd noted, to set a parameter in the current job is not possible via DSSetParam() - a running job can not (legally) have its parameter values changed.

Therefore you must use a job sequence. You can derive the parameter values by any legal means such as, but not limited to, a Routine activity. You set the parameter values for the job run under control directly in the Job activity. You can add parameter references from the job sequence itself, or activity variables from upstream activities, or user variables.