In my job,
Step1 - I am generating FTP commands and writing into a file &TEMP1.
CD \PATH1\PATH2\
DIR
DELETE FILENAME.txt
DIR
QUIT
Step2 - I am executing the FTP commands in &TEMP1 using FTPWEB PROC if only STEP1 is succesful.
When I am running this Job it failed with an error 696.
----------------------------------------------------------------
STEP1 STEP2 - STEP WAS EXECUTED - COND CODE 0696
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
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.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
And i think I have provided the complete info
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.
---------------------------------------------------------------------------
//STEP2 EXEC SAS,COND=(0000,NE)
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSSNAP DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//DASA DD DSN=USERID.WORKPACK.SS1,DISP=SHR
//DASB DD DSN=USERID.WORKPACK.SS2,DISP=SHR
DATA FTPREC(KEEP=FTPIN FTPOUT FTPOPT FTPMSK);
INFILE DASA END=LASTOBS;
INPUT @1 FTP_REC $100.
;
DATA DASB(KEEP=FTPINP);
LENGTH FTPINP $70.;
SET FTPREC;
IN_PATH1 = 'CD \PATH1\PATH2\';
IN_PATH2 = 'DIR';
IN_PATH3 = 'DELETE' || FTPREC;
IN_PATH4 = 'DIR';
IN_PATH5 = 'QUIT';
IF _N_ = 1 THEN DO;
FTPINP = IN_PATH1;
OUTPUT;
END;
DO I = 2 TO 5;
IF I = 2 THEN FTPINP = IN_PATH2;
IF I = 3 THEN FTPINP = IN_PATH3;
IF I = 4 THEN FTPINP = IN_PATH4;
ELSE IF I = 5 THEN FTPINP = IN_PATH5;
OUTPUT;
END;
DATA _NULL_;
SET DASB;
FILE DASB;
PUT @1 FTPINP $70.
;
RUN;
//**************** PROGRAM NAME : FTPWEB ****************
//STEP2 EXEC FTPWEB,PARM='(EXIT'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYMMFAP DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//INPUT DD DSN=USEDID.CNTL(SIGNON),DISP=SHR
// DD DDNAME=SYSIN
//OUTPUT DD SYSOUT=*
//SYSIN DD DSN=USERID.WORKPACK.SS2,DISP=SHR
-------------------------------------------------------------------------------
Output of STEP1 is a dataset with FTP commands to be executed in next step.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
You have no explicit SYSIN DD for your SAS step.
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.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
It is possible that USERID.CNTL(SIGNON) is causing your problem; since you didn't list it, who knows? What is the LRECL of USERID.CNTL? What is the LRECL of USERID.WORKPACK.SS2?
Your SAS code is incredibly bad. Why not simplify it to
Code:
DATA DASB(KEEP=FTPINP);
SET FTPREC;
FILE DASB ;
PUT 'CD \PATH1\PATH2\';
PUT 'DIR';
PUT 'DELETE ' FTPREC $63.;
PUT 'DIR';
PUT 'QUIT';
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?
It is possible that USERID.CNTL(SIGNON) is causing your problem; since you didn't list it, who knows? What is the LRECL of USERID.CNTL? What is the LRECL of USERID.WORKPACK.SS2?
The LRECL of both dataasets are 80.
USERID.CNTL(SIGNON) - it is having ID/IP Address & PWD which we will use to connect to FTP Site.
Quote:
Your SAS code is incredibly bad.
I accept that there are better and efficeint ways to code any program, but this code has been already running in out PROD. And so we are modifying existing one.
Quote:
Furthermore, you STILL have not shown us any job output of a completely successful run as you claimed in your original post:
DATA FTPREC(KEEP=FTPIN FTPOUT FTPOPT FTPMSK);
INFILE DASA END=LASTOBS;
INPUT @1 FTP_REC $50.
;
RETAIN FTPIN FTPOUT FTPOPT FTPMSK;
LENGTH FTPIN $50.;
LENGTH FTPOUT $50.;
LENGTH FTPOPT $10.;
LENGTH FTPMSK $12.;
IF _N_ = 1 THEN DO;
FTPIN = FTP_REC;
END;
IF _N_ = 2 THEN DO;
FTPOUT = FTP_REC;
END;
IF _N_ = 3 THEN DO;
FTPOPT = FTP_REC;
END;
IF _N_ = 4 THEN DO;
FTPMSK = FTP_REC;
END;
IF LASTOBS;
RUN;
DATA DASB(KEEP=FTPINP);
LENGTH FTPINP $70.;
SET FTPREC;
IN_PATH1 = 'GET ' || FTPIN || ' +';
IN_PATH2 = ' //DD:OUTFILE (REPLACE';
IN_PATH3 = 'QUIT';
IF _N_ = 1 THEN DO;
FTPINP = IN_PATH1;
OUTPUT;
END;
DO I = 2 TO 3;
IF I = 2 THEN FTPINP = IN_PATH2;
ELSE IF I = 3 THEN FTPINP = IN_PATH3;
OUTPUT;
END;
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.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
Suneetha1612 wrote:
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.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
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.
