DSXchange

If this message is while you are doing "view data" then it is not going to affect the runtime processing of the data. If you are getting this warning during execution of your job then it is a problem.

You don't need to recompile a routine in order to make it running from a job or a sequence. If you have issued a call to DSAttachJob() somewhere in your process then you can issue a command and it will reset an aborted job prior to running.

No, the stage variables are per process/stage only and are not accessible anywhere else.

The low value in char is 0x00, so you could try redefining your defaults in the input stage to use a space instead of char(0).

What are the data types that have the cobol LOW VALUEs? You will need to make a transform or derivation to handle them, as it seems they are outside of your database's legal range. Perhaps they are date or timestamp fields?

Are you using "inputColumn" or something like In.ColumnName without quotes in your job?

Kumar_j - it seems that your indices have been corrupted; this is why the client tools won't show a job while an import states that it exists already. You can use the DS.TOOLS menu and choose to reindex your project to fix this problem.

Could the value be written as a normal representation? If you are certain that the field contains COMP-3 then you must ensure that it is read as a binary field to make sure that no EBCDIC or other conversions are performed then use the SDK routine to convert. Can you read the char, write it to a seq...

Hello Gil,

DB/2 does not have a COMP-3 data type. What is the defined data type of the column you are reading?

Do you have permissions on the RT_CONFIG114 file on the server? Or in the project directory? This looks like it is the most likely problem cause. We can't tell you if you have enough space in the project directory to create new or extend old files, you will need to check that yourself.

"Can't" is awfully vague for a problem description. Do you get an error message when you do a view data on a mapped file? What happens when you try to write to that directory - perhaps the error message is a bit clearer then. In fact, what is the error message you are getting?

I have caused the same problem before; when using normal inserts against a partitioned table everything went well but I made the DBAs unhappy due to the backup pending state where they had to restore a whole tablespace. I hate posting a "me too" thread because I cannot recall exactly what the cause ...

You mean the @AM to @FM in the first quote

Does your userid have the UNIX permissions to change this file; this might be causing your problem. You can check from a shell or from TCL by doing a "ED RT_STATUS916 DUMMY"; if you only have read permission the editor will warn you that the file is read-only, then exit the EDitor using "Q".

If you go to TCL or the Administrator does a "COUNT RT_STATUS916" return a number or an error message?