UNIX permission while uploading file in server

[sftp]

How can i provide the UNIX permission exclusively on the mainframe file while using Co:Z SFTP to the server?
The server require the permission chmod=755 (RWX)...i am uploading the files in the remote server...how can i provide through JCL ?

Please provide some examples...

[dovetail]

I'm sorry, but I don't understand your question:

- which system is starting the connection (running the sftp client) ?
- where is the source and target file?
- on z/OS, is the file a z/OS Unix file, or a dataset?
- you are asking about setting the permissions of the target file, correct?

[sftp]

Let me clarify your qns's:
1. z/OS mainframe is starting the connection with server (UNIX) via Co:Z sftp client. Our Z/OS supports both IBM ported tools sftp and Co:Z sftp client.
2. Source file is the Z/OS file and target file is UNIX text (ASCII) file. Able to convert and transfer (put) the file into server location.
3. Its Z/OS dataset, used servercp="ISO8859-1" and lzopts mode=text in the jcl to convert into UNIX file
4. Able to provide chmod permission on the target file. All are working now.

File is transferred into the server but got the RC=1 -->> "CoZBatch­I½: returning rc=exitcode=1". is it a error or warning ? provide solution for this.
Can i able to use Co:z to do the sftp from Z/OS to Windows server. how can i set the permission on the target file in the windows server ?

[dovetail]

The return code from COZBATCH (1), is the exit code from the shell script. The exit code from the shell script is the exit code from the last command. If the last command is cozsftp, then there was some error processing a subcommand. if you add a line "set -x" to the beginning of your shell script, then post the output and it will help us to see where the exitCode=1 is coming from.

Yes, you can sftp to a Windows server. You will need to install a sftp server on Windows - there are commercial versions or there is a version of OpenSSH that runs under the Windows cygwin (Unix emulation) environment. You can issue a sftp "chmod" command from the Co:Z SFTP client, but it is up to your Windows sftp server to interpret what that means. For OpenSSH under cygwin, it sets the emulated permission bits. I'm not sure why you are concerned about permission bits under Windows.

[sftp]

Appreciated for providing the quick response. The exit code issue was resolved by removing the wrong subcommand in shell script. The permission for Windows server is not required. We will put as it is. Can i be able to transmit multiple flat files (datasets not PDS) in a single put command through the script instead of multiple put commands ? If yes, need some examples. Also, wanted to know more about "gdgnt" setting for file transmission ? How does it work ?

[dovetail]

Unfortunately, it isn't possible to use a Co:Z SFTP client "put" command to wild-card z/OS datasets to send.

GDGNT is a BPXWDYN dynamic allocation keyword, it is documented here:
http://publib.boulder.ibm.com/infocente ... %2Frda.htm

Here is the underlying SVC99 documentation:

S99GDGNT When the bit is on, the system is to use a LOCATE to determine the relative generation number based on the most recent catalog information. The relative generation number will reflect GDG data sets created or deleted by other jobs in a multitasking environment.
When the bit is off, the system is to determine the relative generation number based on the catalog information that was available the first time the GDG was referenced during the job or TSO/E session. The relative generation number will reflect only those GDG data sets created or deleted by this job. See z/OS MVS JCL User's Guide for more information about GDG data sets, and Table 64 for an example using S99GDGNT.

The default in Co:Z SFTP is "noGDGNT", to turn this on in the client, do this:

Code: Select all

lzopts gdgnt

[sftp]

Earlier, we used to send the mainframe sequential file (QSAM) through FTP in txt format. Now, I am facing some data format issues after the transmission from z/os to Windows by using Co:Z sftp.

Sample File:

01XYZ01/01/2010 (header record)
01 022222222222 ABC XXXXXXXX BBBBBBBBBB 00000000 SFTPSFTPSFTP (record1)
02 022222222222 ABC XXXXXXXX BBBBBBBBBB 00000000 SFTPSFTPSFTP (record2)
02ABC01/01/2010 (Trailer record)

After transmission of the above file to windows, the file format is mentioned below:

01XYZ01/01/2010 (header record)
01 022222222222 ABC XXXXXXXX BBBBBBBBBB
00000000 SFTPSFTPSFTP (record1)
02 022222222222 DEF XXXXXXXX CCCCCCCCCC
00000000 SFTPSFTPSFTP (record2)
02ABC01/01/2010 (Trailer record)

The individual records are not stored in 1 line. It skipped into 2nd line and doing it for all the records. We want to put the records in 1 line as it is in zOS.

Script used:

lzopts mode=text,linerule=crlf,sysout,servercp=ISO8859-1

Default options:
clientcp=IBM-1047 conddisp=catlg estsize jeslrecl=80
jesrecfm=f jesstatus=* linerule=crlf loglevel=I
mode=text overflow=wrap replace servercp=ISO8859-1
smf sysout
Rest all are NO*

linerule cr, nl didnt work properly either, somehow it worked with crlf and crnl but records are skipped into next line.
Please provide the exact format to be executed while doing SFTP. Is there any measures to be taken for file transmission to UNIX ?

[dovetail]

Is it possible that the records in the dataset contain embedded newline characters? Try "hex on" in ISPF to display these.

[sftp]

No.it doesnt.

[dovetail]

I'm not sure why this would be an issue; this is a very common use case.

Try send a small test dataset, while enabling a trace:

// EXEC PGM=COZBATCH
//STDIN DD *
...
cozsftp ... <EOB
lzopts loglevel=RecordStreamer=F
lzopts mode=text,linerule=crlf
put //HLQ.DATASET /remote/filename
EOB
//

This should produce trace records like this:

RecordStreamer[F]: -> streamRecord(recordCount=1 recLen=69 bufLen=32768)
RecordStreamer[F]: <- streamRecord(71)
RecordStreamer[F]: -> streamRecord(recordCount=2 recLen=26 bufLen=32697)
RecordStreamer[F]: <- streamRecord(28)
RecordStreamer[F]: -> streamRecord(recordCount=3 recLen=30 bufLen=32669)
RecordStreamer[F]: <- streamRecord(32)

For each call to the RecordStreamer routine, the input recLen is the length of the record (after trimming blanks, if that is enabled). The output record length is the length of the output record. So for the above example, you can see that two bytes were added to each record (CRLF).

If this trace data matches your expectations, then I would suggest that you bring up the Windows file in a hex editor. For a very small dataset, please post the hex for the dataset (from z/OS ISPF) along with the hex for the Windows file and we will look at it, along with your trace data.

[sftp]

Thanks for the information. Here is the streamer

RecordStreamerÝF¨: -> streamRecord(recordCount=1 recLen=1250 bufLen=32768)
RecordStreamerÝF¨: <- streamRecord(1252)
RecordStreamerÝF¨: -> streamRecord(recordCount=2 recLen=1250 bufLen=31516)
RecordStreamerÝF¨: <- streamRecord(1252)
RecordStreamerÝF¨: -> streamRecord(recordCount=3 recLen=1250 bufLen=30264)
RecordStreamerÝF¨: <- streamRecord(1252)
RecordStreamerÝF¨: -> streamRecord(recordCount=4 recLen=1250 bufLen=29012)

File record length is 1250. In FTP, the file transmits as it is, but in SFTP, the record skips into the next line.

[dovetail]

As requested, please post a hex view of the first couple of records on Windows.

http://www.techsupportalert.com/best-fr ... editor.htm