DSXchange

The format is still illegal in COBOL, unless the trailing "CC426687" starts in column 73 and you trimmed extra space!

Riku wrote:...The permission on project server and on at.exe and vmdsr_sched.exe is given.

But for which user? Check your Administrotor client "Schedule" tab for the project to see which user is being used for the "at" command.

I don't think that you can do this without a transform or other active stage. Have you tried to see what happens when you have a decimal 4,2 declaration but you have 3 digits after the decimal in the file?

If you could explain what you would like, perhaps someone could assist. The question is so broad and vague that no answer is possible on such a complex subject.

The question is similar to asking "What is the difference between Windows 3.0 and Windows NT?" and expecting a good answer.

Perhaps it is no longer actually running, but the status still might indicate that. Can you re-compile the job?

That message doesn't help at all. Can you try to reset the job and see if you have a log entry titled "from previous run..." and post the errors listed there?

That syntax is invalid. You might have reformatted it, so could you post the original inside "code" tags?

The jobs should all be upwardly compatible and, in theory, you should be able to recompile and immediately run them all. As noted in another thread, there don't seem to be as many migration sites as there are new customers at Version 8 so the breadth of experience is a bit narrow at the moment.

The same in my case, all of my V8 sites have been "greenfield" installations. I would guess that is most likely still the most common scenario as existing implementations at V7 will try to wait a bit longer before migrating up to V8.

Mohammed - please, try putting "PRINT" statements in your job to debug it, right before the offending "IF" statements so that you can see what values are being used.

I didn't now what the cause was, but I used the search facility and located this thread, perhaps that might help a bit further.

2ksaint - you have to specify in your job that the file you are reading is using UNICODE, not UTF-8. Specify this in the NLS tab on the sequential file stage.

No, you don't need to enable NLS. Could you explain your problem with the CHAR() function - I don't see it having a problem with the full ASCII set.

How can we answer if you don't post the warning you get?