Problem 1: you did not post using BBcode
Problem 2: blanks within parameters of the job card will cause the job to fail without notice

Also, IEFBR14 doesn't need SYSPRINT since it doesn't do anything. And a block size of 800 is almost criminally negligent these days -- block sizes should be determined by the system, or set as close to half-track blocking as you can get (at least for disk).

flyingleo, there's nothing wrong with having the JOB statement be continued -- that's not the issue. And having SYSPRINT and SYSOUT in a step executing IEFBR14 does absolutely nothing -- it's not wrong, but it's not going to produce any output in any circumstances whatsoever.

HARI: the JCL error implies one of these possibilities: (1) the JOB statement has a syntax error (likely if you're not getting any output at all) -- you need to talk to someone at your site about the job accounting field to ensure it is properly coded, (2) the data set HMADHAV.NOV1.PS1 already exists and the converter / interpreter is failing the job for duplicate data set (every cataloged name must be unique), (3) you've got lower case data in your JCL, (4) you have non-printing characters instead of spaces somewhere in the JCL, (5) the lack of a UNIT and / or VOLSER is causing an allocation failure. There may be other causes but that's all I can think of that would cause the message.

Your best bet would be to run your JCL by someone in your site support group to determine if they see something wrong with it.

No -- message class is determined by each site and what is a good, valid class at one site may not even exist at another site. If they told you to use H, use H. I would try putting the UNIT parameter on the DD statement first; if that doesn't work, contact your site support group.

flyingleo, are you running at the same site as Hari? If not, your experience at your site is completely and totally irrelevant since MSGCLASS is a site standard, not an IBM standard. Furthermore, if Hari's site does not have SMS set up to default the UNIT, your experience at your site is again -- totally irrelevant. The SMS set up is site dependent. What works for you may cause JCL errors somewhere else.

Hari, since your last job ran okay, that implies the problem is with your DD01 DD statement -- so you probably need to get with someone at your site to determine the problem. If your TSO user id data set allocation is not SMS-controlled, for example, you would have to specify the UNIT (which is again a site standard and what works at one site will not work somewhere else).