Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

FTP From MFRM to Windows: Check for the input file ...
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> All Other Mainframe Topics
View previous topic :: :: View next topic  
Author Message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Wed Oct 15, 2008 10:49 pm    Post subject: FTP From MFRM to Windows: Check for the input file ...
Reply with quote

Hi,
I have to FTP a mainframe file to windows server. I have to prepare an FTP job which can also track the return code of FTP. I mean to track whether the FTP got successful or not. I raised this question in this forum few days ago in the following link - http://ibmmainframes.com/viewtopic.php?t=35022.
As suggested by Superk and Robert (I believe), I used the EXIT parameter to trap the FTP code. But now the problem is -
Suppose, you have misspelled a filename in mainframe and you have to FTP that very file to windows server. I wish to trap this error but my existing JCL fails to do so. For clarity, I am sending you the JCL I am using -
Code:
//STEP001 EXEC PGM=FTP,PARM='ip port (EXIT'   
//SYSPRINT  DD SYSOUT=*                               
//OUTPUT    DD SYSOUT=*                               
//FTPIN     DD DSN=File on tape,
//          DISP=SHR,                                 
//          UNIT=3490,VOLUME=(,RETAIN,,,SER=(444261)),
//          LABEL=(1951,SL),                           
//          RECFM=VBA,LRECL=240,BLKSIZE=32760         
//INPUT     DD *                                       
Domain\User-ID                                   
Password
DIR                                                   
CD FTP_DL                                             
PUT //DD:FTPIN MSGCLASS-20080531-2100.TXT             
QUIT                                                   
/*                                                     
/*                                                     


Here I have intentionally mis-spelled the name of the FTPIN file. If the FTPIN file is not present in the mainframe tape, I wish to raise an error.
How can I do that?
However refer the Output too -

Code:
EZA1460I Command:                                       
EZA1736I CD FTP_DL                                       
EZA1701I >>> CWD FTP_DL                                 
250 CWD command successful.                       
EZA1460I Command:                                 
EZA1736I PUT //DD:FTPIN MSGCLASS-20080531-2100.TXT
EZA1701I >>> SITE VARrecfm LRECL=240 RECFM=VBA BLKSIZE=32760                   
500 'SITE VARrecfm LRECL=240 RECFM=VBA BLKSIZE=32760': command not understood   
EZA1701I >>> PORT 10,138,102,10,238,101                                         
200 PORT command successful.                                                   
EZA1701I >>> STOR MSGCLASS-20080531-2100.TXT                                   
150 Opening ASCII mode data connection for MSGCLASS-20080531-2100.TXT.         
226 Transfer complete.                                                         
EZA1617I 37935 bytes transferred in 1.220 seconds.  Transfer rate 31.09 Kbytes/s
EZA1460I Command:                                                               
EZA1736I QUIT                                                                   
EZA1701I >>> QUIT                                                               
221  Leaving the MFrame Environment                                             
Back to top
View user's profile Send private message

Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Wed Oct 15, 2008 11:00 pm    Post subject:
Reply with quote

Quote:
EZA1617I 37935 bytes transferred in 1.220 seconds. Transfer rate 31.09 Kbytes/s
So what got transferred?

If the file name is wrong, you should get an error even when the file is on tape.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Wed Oct 15, 2008 11:08 pm    Post subject:
Reply with quote

Thanx Rober for your quick reply ...
The original file whose name I changed to do the test. I am not very much aware of the fact but is it possible that even if I miss-spelled the file name, the job will pick up the file present in that particular label mentioned in the job?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Wed Oct 15, 2008 11:45 pm    Post subject:
Reply with quote

Since the tape is labeled, the file name in JCL must match the file name on tape or the job won't run -- if the tape were unlabeled you wouldn't get that check. I don't remember the abend that is generated but the job definitely doesn't run.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Wed Oct 15, 2008 11:55 pm    Post subject:
Reply with quote

OK! The original name of the tape file was - SYS3.QPP1D.ARCH.D08154.T123242.F01 and I changed the second qualifier only to TESTD. So the new name (manipulated) becomes - SYS3.TESTD.ARCH.D08154.T123242.F01. And after FTP, I checked in the server and I found that the information that has been FTPed, belong to the original file. Am I missing something?
And I also checked in repository (A dump of CA tool, I believe; I don't know the name) and found that there is no file with the name SYS3.TESTD.ARCH.D08154.T123242.F01. Robert again, am I missing something? Why does it happen to me?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 12:12 am    Post subject:
Reply with quote

All I can say is that 37,935 bytes were transferred from somewhere ... check the JESMSGLG for the job and see if the file name shows up.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 1:16 am    Post subject:
Reply with quote

I checked the JESMSG and it is saying the following -
Code:
IEF285I   SYS6.QNEP1D.TCPIPOE.STANDARD.TCPXLBIN        KEPT             
IEF285I   VOL SER NOS= 1DOS01.                                         
IEF237I 5D0D ALLOCATED TO SYS00008                                     
IEF285I   SYS6.QNEP1D.TCPIPOE.STANDARD.TCPXLBIN        KEPT             
IEF285I   VOL SER NOS= 1DOS01.                                         
IEF142I XAYC4261 STEP001 - STEP WAS EXECUTED - COND CODE 0000           
IEF285I   PSCZAYC.XAYC4261.JOB12972.D0000102.?         SYSOUT           
IEF285I   PSCZAYC.XAYC4261.JOB12972.D0000103.?         SYSOUT           
IEF285I   SYS3.TESTD.ARCH.D08154.T123242.F01           KEPT             
IEF285I   VOL SER NOS= 444261.                                         
IEF285I   PSCZAYC.XAYC4261.JOB12972.D0000101.?         SYSIN           


But I tried to copy the file SYS3.TESTD.ARCH.D08154.T123242.F01 from tape to DASD, I received an error ...
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Oct 16, 2008 2:23 am    Post subject:
Reply with quote

Hello,

What i believe you are missing is that on tape only the last 17 bytes of the dsn were used to identify the dataset. . .

You changed something early in the dsn. Try your test again changing the last bit of the dsn instead.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 3:23 am    Post subject:
Reply with quote

Good catch, dick -- I used to use that a lot but haven't had to work much with tape dataset names lately!
Back to top
View user's profile Send private message
gcicchet

Senior Member


Joined: 28 Jul 2006
Posts: 1703
Location: Australia

PostPosted: Thu Oct 16, 2008 5:59 am    Post subject:
Reply with quote

Hi,

if the dataset is cataloged, then just specify the dataset name and disposition.

This should result in a JCL error if dataset is mispelled.


Gerry
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 6:14 pm    Post subject:
Reply with quote

Hey thanks Dick and Robert! But I have a question - How did you (Dick) find the fact that the last 17 bytes of the dsn were used to identify the dataset. How did you get to know this? This is just for my curiosity ...

By the way, I assumed a scenario that while FTPing a file from mainframe to windows server, suppose the connection got lost. What will happen then? Do I receive a non-zero return code? Hope u r getting what I wish to mean ...
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 6:30 pm    Post subject:
Reply with quote

In the DFSMS bookshelf, there's a manual called Using Magnetic Tape. In this manual is laid out the format of the various tape labels. Part of the description is:
Quote:
Contents: The rightmost 17 bytes of the data set name (includes GxxxxVyy if the data set is part of a generation data group). If the data set name is less than 17 bytes, it is left-justified and the remainder of this field is padded with blanks. If the name contains embedded blanks or other special characters, you must enclose the name in apostrophes on the DD statement that requests this data set. z/OS MVS JCL User's Guide lists the restrictions that apply to enclosing a data set name in apostrophes. The apostrophes do not appear in the data set identifier field.
When I was with a software vendor, we'd use this to our advantage -- our customers could put any needed high-level qualifier in front of our name to meet security requirements.

If the connection gets lost during the PUT, you'll probably get a 27426 FTP return code (27=PUT, 426="Connection closed; transfer ended abnormally", which translates into a 2850 JCL RC. You definitely got a non-zero return code (as long as (EXIT is in the PARM=).
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 6:40 pm    Post subject:
Reply with quote

Hey Robert, thanks a lot man! Hey dnt mind - I wish to get a confirmation/ suggestion from you.
As you mentioned earlier while FTPing a file if the connection is lost, we will receive a JCL RC. So we no need to take care of that issue seperately if I code the following -
Code:
//STEP001 EXEC PGM=FTP,PARM='ip port (EXIT'   

Right?

Hey pls let me know your concern! Waiting to hear from you ...
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 6:44 pm    Post subject:
Reply with quote

Correct -- the (EXIT causes the JCL return code to be set based on what the FTP commands do.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 6:48 pm    Post subject:
Reply with quote

Thanks a lot Robert ... icon_lol.gif icon_biggrin.gif
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Thu Oct 16, 2008 7:10 pm    Post subject: Reply to: FTP From MFRM to Windows: Check for the input file
Reply with quote

Hello,

Quote:
How did you (Dick) find the fact that the last 17 bytes of the dsn were used to identify the dataset. How did you get to know this?
Memory icon_smile.gif

I seem to recall discussions "way back" when the decision was made to use the last 17 rather than the first 17 (when the dsn was longer than 17 which was not often back then) so there would be better odds for uniqueness. With all of the "standards" that were implemented then, dataset name length grew and grew.

Robert,

Thanks for posting the quote from the doc - i was afraid i was going to have to go find it as a manual reference is far preferable to an old memory. . . icon_wink.gif

d
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 7:17 pm    Post subject:
Reply with quote

Glad to help dick ... it doesn't seem to be well-known but the 17-character tape name limit can be quite helpful at times.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 8:07 pm    Post subject:
Reply with quote

Hey I am back icon_wink.gif - Obviously again with a question (May sound to u little silly)! Guys suppose I receive a JCL RC = 1954, how can I calculate the FTP return code from this?
And guys do you know any site where different FTP return-codes are listed down?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Oct 16, 2008 8:27 pm    Post subject:
Reply with quote

I don't know that you can go from a JCL return code to an FTP code since multiple FTP codes could map to a single JCL return code. The FTP code is actually a two-byte FTP subcommand code followed by the 3-byte FTP reply code. In the Communications Server bookshelf, the IP User's Guide and Commands manual gives the FTP subcommand codes while the IP and SNA Codes manual contains the FTP reply codes. The FTP reply codes are pretty much dictated by the RFC document and are standard across platforms, although there can be some differences in wording for given reply codes.

As I said earlier, the FTP subcommand code and reply code are concatenated together to form a 5-digit number. This number is then converted into a JCL return code by dividing by 4096 and taking the remainder. If you have 1954 as a JCL return code, you don't know how many times 4096 was removed from the FTP code to get 1954. If I had to guess, I'd say 26530 was the FTP code -- PASS command had some error generated.
Back to top
View user's profile Send private message
jain.eti

New User


Joined: 23 Jan 2007
Posts: 25
Location: delhi

PostPosted: Thu Oct 16, 2008 8:37 pm    Post subject:
Reply with quote

Thanks a lot Robert icon_biggrin.gif
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> All Other Mainframe Topics All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Performing arithmetic on input field zh_lad DFSORT/ICETOOL 8 Tue Dec 06, 2016 8:04 pm
No new posts High CPU consumption Job using IAM fi... aswinir JCL & VSAM 8 Thu Dec 01, 2016 8:28 pm
No new posts Add PD field from 2nd file to PD in 1st Sushant Garje DFSORT/ICETOOL 6 Thu Dec 01, 2016 4:32 pm
No new posts File Aid to File Manager conversion murali3955 IBM Tools 4 Thu Nov 24, 2016 3:41 pm
No new posts What is the command to check MODE of ... rohanthengal CLIST & REXX 6 Fri Nov 18, 2016 1:48 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us