FTP PF with variable length records

[Guest.Visitor]

Hi all, Currently we send a file with SNDNETF and use FORMAT(*V) which means the file is sent using variable-length records with trailing blanks removed from each record. How can I do the equivalent using FTP "Put"? The target system (MVS) does not want trailing blanks sent in each record. The current setup for FTP is to send the file as BINARY to handle the packed decimal fields. Thanks. Chris

[Guest.Visitor]

On Tuesday, June 01, 1999, 08:56 AM, Chris Ringer wrote: Currently we send a file with SNDNETF and use FORMAT(*V) which means the file is sent using variable-length records with trailing blanks removed from each record. How can I do the equivalent using FTP "Put"? The target system (MVS) does not want trailing blanks sent in each record. The current setup for FTP is to send the file as BINARY to handle the packed decimal fields. Thanks. I can not test it... but what about EBCdic, STRUCture F, and SITE TRIM 1 to effect that.?.? Since both are EBCDIC systems, this will work given common language environments. This works for me on a GET from a VM/CMS from V4R2M0 AS/400. HTH. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

[Guest.Visitor]

On Tuesday, June 01, 1999, 09:42 AM, Chuck Pence wrote: I can not test it... but what about EBCdic, STRUCture F, and SITE TRIM 1 to effect that.?.? Since both are EBCDIC systems, this will work given common language environments. This works for me on a GET from a VM/CMS from V4R2M0 AS/400. HTH. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.

---

Chuck, I issued 'SITE TRIM 1' from the AS/400 to the MVS system and 'TRIM' was not a recognized parm for MVS. I can tell you that when I perform the transfer as EBCDIC, trailing blanks are automatically trimmed BUT whenever a record has a hex '15' in it, that record gets split into 2 records on the MVS side. Here is an example in hex:

 "FROM" file record ....5...10...15...20...25...30...35...40...45...50  ...55...60...65 IOHM~ßßßß ßß 8 ßß CDCD15010014F4444444444444444444444444444444444444  444444444444402 968 41F15F0F080000000000000000000000000000000000000000  000000000000 "TO" file records ....5...10...15...20...25...30...35...40...45...50  ...55...60...65 IOHMßß CDCD1504444444444444444444444444444444444444444444  444444444444444 968 41F10000000000000000000000000000000000000000000000  000000000000 ßßß 8 ßßßVISLOG 0014F444444444444444444444444444444444444444444444  44444020ECEDDC4 F0F 08000000000000000000000000000000000000000000000000  0000F5923670 

As you can see, the split occurs at the hex '15' in position 8 of the "from" record and the hex '15' is not in either of the split "to" records. I tried a BINARY transfer but this always puts trailing blanks in the sent records regardless of any 'TRIM' or 'LOCSITE TRIM' setting. I also tried STRUCT R without success. I may have to convert the packed decimal fields to signed but that will effect programs on the MVS side. Is there anyway to use a translation table to not convert a hex '15'?? Thanks Chris

[Guest.Visitor]

On Tuesday, June 01, 1999, 01:06 PM, Chris Ringer wrote: I issued 'SITE TRIM 1' from the AS/400 to the MVS system and 'TRIM' was not a recognized parm for MVS. I can tell you that when I perform the transfer as EBCDIC, trailing blanks are automatically trimmed BUT whenever a record has a hex '15' in it, that record gets split into 2 records on the MVS side. Here is an example in hex:

 "FROM" file record ....5...10...15...20...25...30...35...40...45...50  ...55...60...65 IOHM~ßßßßßß 8 ßß CDCD15010014F4444444444444444444444444444444444444  444444444444402 96841F15F0F080000000000000000000000000000000000000  000000000000000 "TO" file records ....5...10...15...20...25...30...35...40...45...50  ...55...60...65  IOHMßß CDCD1504444444444444444444444444444444444444444444  444444444444444 96841F10000000000000000000000000000000000000000000  000000000000000  ßßß 8 ßßßVISLOG 0014F444444444444444444444444444444444444444444444  44444020ECEDDC4 F0F08000000000000000000000000000000000000000000000  0000000F5923670 

As you can see, the split occurs at the hex '15' in position 8 of the "from" record and the hex '15' is not in either of the split "to" records. I tried a BINARY transfer but this always puts trailing blanks in the sent records regardless of any 'TRIM' or 'LOCSITE TRIM' setting. I also tried STRUCT R without success. I may have to convert the packed decimal fields to signed but that will effect programs on the MVS side. Is there anyway to use a translation table to not convert a hex '15'?? Thanks OK... so seems there would be a limit per EOL marks. I'm not sure about effecting special xlate to effect no EOL. I'll have to remember that one; in fact I believe I may have seen this in the past, but my frustration in trying to get what I want finally made me admit that the real problem was using the wrong tool for the job. FTP is not meant to transport described data... just a stream of bytes. You should stick to binary... and if the data truly is described , then a more appropriate tool for the task may be required. In the PC and mixed-system environments this usually meant/means EXPORT and IMPORT functions for your data. In more recent times this means database to database, for which some "open" interfaces allow better solutions; allowing simply SELECT of the data from one system, and saving the result set to the current system . In QMF I believe there is DRDA with CONNECT TO and SAVE DATA AS after a SELECT * FROM. Of course without smart underlying database and communications, this may not even solve the variable length data situation; even if the column is defined as VARLEN data. There are many other specific file-transfer functions which may effect similar transport w/out full "database" support . Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.