Hi
I'm working with DataStage7.5.1 for Enterprise Edition for MVS.
Can any one send me how a parameter file looks in MainFrame and its usage within DataStage Jobs, Ascential Best Practices.
Appreciated..
parameter file
Moderators: chulett, rschirm, roy
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Can you be more specific? There is no mention of a parameter file in the Mainframe Job Developer's Guide - in my experience you simply use the same Parameters grid in the job properties window as you do with other job types. In particular refer to pages A-15 and A-16 of that manual.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
parameter file for MF jobs
[quote="ray.wurlod"]Can you be more specific? There is no mention of a parameter file in the [i]Mainframe Job Developer's Guide[/i] - in my experience you simply use the same Parameters grid in the job properties window as you do with other job types. In particular refer to pages A-15 and A-16 of that manual.[/quote]
Yes, there is a mention about parameter file in Mainframe Job Developer's
Guide, parameter grid for Mainframe job is different from that of server job, example this grid doesnot allow to initialize the parameter, where as in server job, it allows.
Yes, there is a mention about parameter file in Mainframe Job Developer's
Guide, parameter grid for Mainframe job is different from that of server job, example this grid doesnot allow to initialize the parameter, where as in server job, it allows.
[quote="Mike"]Job parameters in a mainframe job are very different than in a server job.
What use do you have in mind for your application?
A mainframe job reads its parameters from a single record in a simple flat file during initialization.
Mike[/quote]
The usage of the application is as follows:
After successfully testing the DS-JOB, the job will be rolled over to QA, QA would like to change the extract criteria over a period of time. I thought providing a parameter file to user makes more sense, they can edit the values of the parameters in the file,as and when then want, rather than messing up the DS-JOB.
Keeping the above usage in mind,I prefer to go for a flatfile in Mainframe.
I'm not sure the layout of the parameter file, like project name, category name, job name, blah..blah..in which order and how these attributes need to be organized in a parameter file for MF job. Any help from this side will be appreciated.
Thanks
What use do you have in mind for your application?
A mainframe job reads its parameters from a single record in a simple flat file during initialization.
Mike[/quote]
The usage of the application is as follows:
After successfully testing the DS-JOB, the job will be rolled over to QA, QA would like to change the extract criteria over a period of time. I thought providing a parameter file to user makes more sense, they can edit the values of the parameters in the file,as and when then want, rather than messing up the DS-JOB.
Keeping the above usage in mind,I prefer to go for a flatfile in Mainframe.
I'm not sure the layout of the parameter file, like project name, category name, job name, blah..blah..in which order and how these attributes need to be organized in a parameter file for MF job. Any help from this side will be appreciated.
Thanks
Data Mover
papan,
Your intended usage for a mainframe job parameter is one that is suitable.
Everything you need to specify is on the Job Properties page. You can use a single common dataset to provide the same set of parameters to every job in your application, or you can use a different dataset for each job.
I like to use a consistent DD name across all jobs (e.g. JOBPARM).
If you use a different dataset for each job, then try to make the job name part of the dataset name (e.g. LEVEL1.LEVEL2.JOBNAME.JOBPARM).
If you use a common parameter file for every job then use something such as LEVEL1.LEVEL2.COMMON.JOBPARM.
You'll probably have to flex on naming to conform with your mainframe standards.
You can specify as many parameters as you need in the parameter grid. Keep in mind that if you are going to have your business analysts maintain the parameter values through something like TSO Edit, don't use Decimal or Integer SQL types. You don't want to force them to turn HEX ON and enter binary or packed decimal values. If your business analysts can use something like FILEAID to maintain parameter values then integer and decimal should be ok.
DataStage does not automatically create your parameter file for you. You will need to allocate the dataset and populate it ahead of time.
Mike
Your intended usage for a mainframe job parameter is one that is suitable.
Everything you need to specify is on the Job Properties page. You can use a single common dataset to provide the same set of parameters to every job in your application, or you can use a different dataset for each job.
I like to use a consistent DD name across all jobs (e.g. JOBPARM).
If you use a different dataset for each job, then try to make the job name part of the dataset name (e.g. LEVEL1.LEVEL2.JOBNAME.JOBPARM).
If you use a common parameter file for every job then use something such as LEVEL1.LEVEL2.COMMON.JOBPARM.
You'll probably have to flex on naming to conform with your mainframe standards.
You can specify as many parameters as you need in the parameter grid. Keep in mind that if you are going to have your business analysts maintain the parameter values through something like TSO Edit, don't use Decimal or Integer SQL types. You don't want to force them to turn HEX ON and enter binary or packed decimal values. If your business analysts can use something like FILEAID to maintain parameter values then integer and decimal should be ok.
DataStage does not automatically create your parameter file for you. You will need to allocate the dataset and populate it ahead of time.
Mike