unixutf-8asciimainframelftp

LFTP ASCII Error from unix to mainframe


I am trying to use lftp to ftp a file from unix(UTF-8) to mainframe (gdg). So the below command works fine for smaller files. Mainframe requires the file to be in ascii mode. When the file becomes larger, I think the ftp is broken up and the ascii option in lftp does not work properly. Looking for some solutions to this.

Command:

lftp -c "open -u user,password -p 21 server.example.ORG; site LRECL=10200; put -a /home/user/example_2018-02-01-09-46-05.txt -o \'C00000.000000.0000(+1)\';bye"

Error:

put: cannot seek on data source

Problem: Mainframe was running out of space.

Solution: Based on answer below. I reduced LRECL=750 to save space and the ascii mode was able to work again.


Solution

  • One difference between z/OS and most (all?) distributed OSs is the requirement to specify how much space your datasets will occupy. There is likely a default in place that your "smaller" datasets don't exceed and your "larger" datasets do.

    Try specifying the SITE commands to allocate more space.

    You might want to check with the mainframe storage administrator to see if there is a DATACLAS you should be specifying as a SITE command. A DATACLAS includes space allocation among other things.

    Absent a DATACLAS, normally one has a pretty good idea of the number of records present in a file and can calculate how many blocks or tracks or cylinders are required.

    Normally you can take advantage of System Determined Blocksize, where z/OS calculates the optimal blocksize for you. The largest block size you should use on modern DASD is 27998 bytes, which is the size of half a track. Your LRECL is 10200. 27998 / 10200 is 2.74 so 2 records will fit in a block, 4 on a track. There's a fair amount of wasted space there.

    If you have 1000 records in your file, you could specify...

    pri=250 sec=25 tracks

    ...as part of your SITE command. This would provide for your 1000 records in your primary allocation and potentially 15 secondary allocations for slop. You're not guaranteed to obtain a secondary allocation, so it's usually best to try to specify your primary allocation large enough for the entire dataset. For large files of 100,000 records, you could specify...

    pri=1700 sec=170 cylinders

    ...because there are 15 tracks to a cylinder. Where I come from that's a pretty big dataset.

    While JCL has a RLSE parameter for space allocation, which says to release (deallocate) the unused primary space, I see nothing in the SITE commands that performs the same function. Typically someone pays for allocated space, even if it's empty. Some shops have scheduled jobs that release unused but allocated space. All of which is to say that just throwing a bunch of space at your allocation and calling it a success because the FTP works might make you unpopular with whomever is paying the bill.

    All of this disk space allocation stuff dates back to when disk was unbelievably expensive by today's standards.