Connect Direct : File sending from Mainframe to Unix

Question

When I am sending a Variable length file from Mainframe Connect direct to UNIX box, the file on UNIX have some extra bytes on the beginning of the Mainframe file, I tried using different SYSOPTS option but I am still getting those intial bytes. Any Idea ?

Ephesus

When posting this sort of question, you should definitely include some examples of the extra bytes. It could be very useful for us to determine the problem. – Subdelirium

Answer 1

You should look at getting the file copied to a Fixed-Length record (recfm=FB) file on the mainframe before doing the transfer. There are a number of mainframe utilities that can do this (i.e. sort).

If you transfer it as a VB file you should also leave it as an EBCDIC file (the BDW/RDW fields are binary fields and should not be translated to ASCII).

---

As others have said, it would be useful to have an example of the file.

---

Following on from NealB. A vb file on the mainframe is stored in this format

<BDW><RDW>Record Data 1
     <RDW>Record Data 2
      ....
     <RDW>Record Data n-1
<BDW><RDW>Record Data n
     <RDW>Record Data n+1
      ....
     <RDW>Record Data o-1
<BDW><RDW>Record Data o
     <RDW>Record Data o+1
      ....

Where

• BDW : Block descriptor word is 4 bytes; the first 2 bytes are the block length (big endian format); the last 2 bytes will be hex 0's for disk files (tapes files can use these 2 bytes).
• RDW : Record Descriptor word is 4 bytes; the first 2 bytes are the record length (big endian format); the last 2 bytes will be hex 0's.

So if Block length was 240 (and contained 3 80-byte records) then the file would be

---BDW--- ---RDW---
00F0 0000 0050 0000 80-bytes of data (record 1)
          0050 0000 80-bytes of data (record 2)
          0050 0000 80-bytes of data (record 3)

There may be a unix utility for handling mainframe VB files

---

There are are some vb options for Connect-Direct (NDM) (see http://pic.dhe.ibm.com/infocenter/sb2bi/v5r2/index.jsp?topic=%2Fcom.ibm.help.cd_interop_sysopts.doc%2FCDP_UNIXSysopts.html).

Looking at the documentation, you can not combine vb options with ascii translation; converting the file to Fixed-Length records (recfm=FB) on the mainframe may make a lot of sense.

---

Note: You could try looking at the file with the Record Editor and using the File-Wizard (button to the left of the layout name). The wizard should pickup that it is a Mainframe-VB file.

Note: While converting the file to a fixed-length record on the mainframe would be the best option, the java project JRecord can read Mainframe VB files if need be

Hibbard

Answer 2

Some extra bytes... how many is "some"?

If there are always 4 bytes, these may be the RDW (Record Descriptor Word) which carries the record length.

I don't know much about Connect Direct, but from a command line FTP session on the mainframe you can verify the RDW status using the LOCSTAT command as follows:

 Command:
LOCSTAT RDW
 RDW's from VB/VBS files are retained as part of data.
 Command:

If you see the above message you can drop the RDW's using the following command:

LOCSITE NORDW 

If you are pulling from the mainframe then you can find out whether RDW's are being stripped or not using FTP command:

 QUOTE STAT

You will then see several messages, one of which reports the RDW status:

 211-RDWs from variable format datasets are retained as part of the data.

Again, you can fix this with

QUOTE SITE NORDW

after which QUOTE STAT should give you:

211=RDWs from variable format datasets are discarded

Dustpan

Answer 3

Are the extra bytes 0xEF 0xBB 0xBF, 0xFF 0xFE or 0xFE 0xFF? That's the UTF Byte Order Marker.

If it's UTF-8, ignore it. Strip it, if you like. It's pointless.

If it's UTF-16, then you can use the bytes to determine endianness. If you know the endianness, it's safe to ignore or strip them.

If you control the application generating the files, change it from saving UTF. Just save the files as ASCII and the BOMs will go away.

Subdelirium