First, the 696 step condition code is 99000 modulo 4096 (which is the standard way z/OS handles codes larger than 4095). So telling us what it is doesn't add anything to the information already available.

Second, the error code 12 looks to be FTP_INPUT_ERR -- error reading INPUT or STDIN. Is there any chance that the FTP commands were edited and line numbers are in columns 73 through 80? If so, you'll need to remove them as FTP does NOT recognize line numbers in its subcommands. In my experience, this is the most common cause of input problems with FTP subcommands.

Third, you didn't bother to tell us what the step condition code nor the FTP output is for the step with the DELETE FILENAME.txt -- if you cannot provide complete information, that makes it much harder for us to help you.

You have not shown us:
- the JCL you are using
- the output of the first step
- the output of the entire job where the DELETE has been replaced with whatever command(s) you say do work
- a print of the &TEMP1 data set

You also have not told us what kind of server you are connecting to -- z/OS, z/OS Unix System Services, Windows, or Unix/Linux machine. So you have not provided anywhere near complete information.

Quote:

using FTPWEB PROC if only STEP1 is succesful

In case you are not aware of it, FTPWEB is specific to your site -- it is NOT a generally used procedure; I've never heard of it before today despite many years of using FTP.

Looking at what you HAVE provided, there are indications that your &TEMP1 data set has a problem -- the EZA1460I prompt is usually followed by the first command in the input data set. It could be that &TEMP1 is associated with the wrong DD name, or there could be some other problem.

You have no evidence in what you have shown of the existence of an actual &TEMP1 data set, so at the moment printing its contents is useless.

You use two different DDs to read (on one) and update (on another) the same dataset. This is an incredibly bad idea, which you may be getting away with simply because the data set contains only a small number of records. Don't do that.

Note also that you are updating with DISP=SHR, which means that if you submit your JOB twice, both JOBs can execute at the same time, further increasing the chance of corruption.

Note also also, that if you SAS fails for any reason, you may well corrupt your input data set with your output data set. If you want to do "corrupt-in-place" processing (same data set for input and output, non PDS/PDSE) then you must do a backup before the step.

You haven't provided DCB info for the data set.

When you enter the alleged instructions by hand, do they work? Enter them by hand into a data set with the same characteristics and experiment (editor) to make them not work.

Furthermore, you STILL have not shown us any job output of a completely successful run as you claimed in your original post:

Quote:

I used to run similar job through PUT and GET commands. And they are successful.

Unless you can show us the successful job, executed in precisely the same manner as you did in the posted job, your claim to have a successful execution is, to say the least, suspect. And to echo Bill's comment, your original post talked about an &TEMP1 data set -- yet the posted JCL does not have this. Either you are not posting what you are using, or you are posting about things you are not doing in your JCL.

Since you cannot clearly and simply post what you are doing, what your results are, and how your results are different from what you want, why should this topic not be locked as a complete waste of time?

And to echo Bill's comment, your original post talked about an &TEMP1 data set -- yet the posted JCL does not have this.

Yes. I used &TEMP1 previously, then in order to check whether commands are populated correctly I replaced it with a dataaset USERID.WORKPACK.SS2

Quote:

Since you cannot clearly and simply post what you are doing, what your results are, and how your results are different from what you want, why should this topic not be locked as a complete waste of time?

You might have seen so many people posting questions, may be becuase of that you are replying like this...
But I have posted all the info which I have. And also what ever I have hidden only User ID, PWD which is confidential for everyone.

You might have seen so many people posting questions, may be becuase of that you are replying like this

Absolutely NOT. Such responses are generally invited by the OP by NOT posting what was asked repeatedly, or posting something which is misleading.
If you really are looking for help from a forum, start paying attention to the details of questions asked and review your responses if they contain sufficient information to help others willing to help you, instead of complaining.

You might have seen so many people posting questions, may be becuase of that you are replying like this

We are replying like this because you do not provide adequate information for us to help you. Between us, Bill and I have made over 15,000 posts to this forum (and many more to other forums) -- so we've got a great deal of experience in dealing with various questions. When we keep asking for the same things over and over, you need to look at what you are posting instead of blaming the messenger.

At least one of your problems is here. SAS data set WORK.FTPREC is being built with variables FTPIN, FTPOUT, FTPOPT, FTPMSK -- and only those variables. You input variable FTP_REC as a 100-byte character variable. Since it is not one of the KEEP variables, it is not kept and hence your FTPREC SAS data set has no data in it. Your DELETE statement will not have a file name associated with it. Your GET example moves FTP_REC to the 4 KEEP variables, one at a time, and hence the FTP GET will have a valid FTPIN value. The fact that you have such differences in your code is one reason why we've been asking you to post both the working and nonworking code for at least 2 days now.

Suneetha1612
You do not mention that you've compared the output, aka '//OUTPUT DD SYSOUT=*', from both the working and non working after putting debugging statements in. And the same for the INPUT commands. In my experience(far less than 7,500 replies), this will almost certainly show you exactly what is wrong with your input commands.

And, trust me, these people are here to help. They've helped me so much.