VB file MVS<-->UNIX 
Author Message
 VB file MVS<-->UNIX

I'm now in a project which transfer mainframe(Hitachi mvs(vos/3))
cobol system to unix(UP-UX11) hitachi cobol environment.
I have a difficulty about variable block(VB) file conversion.

 Unix cobol environment needs RDW(record descriptor words) to
handle variable block file.  But when the file is transfered
via FTP from mainframe to unix, RDW is dropped.
 So they need another transfer way which keep RDW during
transfer or convert a data before transfer to include RDW
within application data, and rebuild it after transfer. Same
problem exist about from unix to mainframe.

 Now I know the way to convert a data, and rebuild it. But that
way need a program for each different format file. So I want
common way to transfer VB data. Does anyone know more convenient
way?  And what is the typical way to transfer?



Mon, 08 Mar 2004 20:23:10 GMT  
 VB file MVS<-->UNIX

Quote:

> Unix cobol environment needs RDW(record descriptor words) to
>handle variable block file.  But when the file is transfered
>via FTP from mainframe to unix, RDW is dropped.
> So they need another transfer way which keep RDW during
>transfer or convert a data before transfer to include RDW
>within application data, and rebuild it after transfer. Same
>problem exist about from unix to mainframe.

Does the RDW get stripped when doing a BINARY transfer?
I would think that the best thing to do is flatten out the file to the same
length across the whole file and append the original RDW to
each record before the FTP process.   Then on the receiving side,
rebuild the Variable file from the Fixed file.   This is because
I have found that some PC-ish systems wrap the RDW around
each record to enable read backwards as well as read forwards.

The BINARY option is not such a good thing since you are working between an
EBCDIC and ASCII platform.   You would have to handle EBCDIC/ASCII
translations of your Display formatted fields and retain the original values
of the Packed/Binary/Hex fields.



Mon, 08 Mar 2004 23:52:07 GMT  
 VB file MVS<-->UNIX

Quote:

> Does the RDW get stripped when doing a BINARY transfer?

Yes, it's stripped.

Quote:
> I would think that the best thing to do is flatten out the file to the same
> length across the whole file and append the original RDW to
> each record before the FTP process.   Then on the receiving side,
> rebuild the Variable file from the Fixed file.  

That's just the way we are trying. Anyone know the utility
that work like this?

Quote:
> The BINARY option is not such a good thing since you are working between an
> EBCDIC and ASCII platform.   You would have to handle EBCDIC/ASCII
> translations of your Display formatted fields and retain the original values
> of the Packed/Binary/Hex fields.

But if transfered by ASCII mode, does FTP know the field is EBCDIC
or Packed or ...? Does FTP change all fields of data as it thinks
fields are all EBCDIC character?
So FTP must be with binary option, and change fields before or after
tranfer. Is this right?


Tue, 09 Mar 2004 13:01:55 GMT  
 VB file MVS<-->UNIX
With the Micro Focus "mainframe development targeted products", there are
several utilities that are provided - and that I think you will need to
"emulate" if you are in another environment.  Before listing them, there is
one question that I would ask you - Do you have any MVS programs that do
negative subscripting to get at the RDW itself?  If so, you need to have a
Unix compiler that will "emulate" this environment for you (Again Micro
Focus has such an option - I don't know about the other PC products).

Things that you will need:

1) Two programs that will add and delete RDW fields when
uploading/downloading (See MF VRECGEN)

2) A program that will do "intelligent" ASCII/EBCDIC conversion (change PIC
X fields, fix sign-nibbles if needed for numeric Packed/Display fields, NOT
change binary fields)  This routine will need to handle multiple record
descriptions under the same FD. (See Micro Focus WFL)

3) A program that will correctly handle mainframe VSAM (or indexed) files -
especially those with multiple alternate indices

  ***

This is not (and is NOT intended to be) an "ad" for Micro Focus solutions to
these problems.  (In truth and fact, MF provides these for Windows
products - not for Unix products).  It is intended to point you to the
direction that you could look for the specifications for ALL the various
tools you need for this type of "conversion".

A couple other alternatives:

A) For each file that you want to transfer, create a "quick and dirty"
program that reads the file as defined and creates a new file with
 - RDW as a separate field
 - all numeric data as USAGE DISPLAY with SIGN IS SEPARATE
 - then look at the CODE-SET STANDARD-1 or EBCDIC (if you have it) syntax
 ... then you just transfer that with normal ASCII/EBCDIC conversion and
"reconstitute" it on the other platform

B) Look at finding a tool that does "remote access" for data files, so you
can leave the files on one platform - but use them on multiple platforms.

  ***

P.S.  I just noticed that your email ID has "jp".  Do be aware that there
are ALSO issues related to DBCS or "national" character sets being different
on different platforms.  Shift-JIS, Unicode, ISO-10646, IBM DBCS, etc.   I
know of NO tool that "correctly" converts such data.

P.P.S.  Back to the original "RDW question" - if your COBOL compiler (on
both platforms) supports the
   RECORD VARYING IN SIZE
        syntax as well as
  RECORD CONTAINS

then switching to RECORD VARYING IN SIZE *may* make it unnecessary to worry
about the RDW at all.

--
Bill Klein
 wmklein <at> ix.netcom.com


Quote:

> > Does the RDW get stripped when doing a BINARY transfer?

> Yes, it's stripped.

> > I would think that the best thing to do is flatten out the file to the
same
> > length across the whole file and append the original RDW to
> > each record before the FTP process.   Then on the receiving side,
> > rebuild the Variable file from the Fixed file.

> That's just the way we are trying. Anyone know the utility
> that work like this?

> > The BINARY option is not such a good thing since you are working between
an
> > EBCDIC and ASCII platform.   You would have to handle EBCDIC/ASCII
> > translations of your Display formatted fields and retain the original
values
> > of the Packed/Binary/Hex fields.

> But if transfered by ASCII mode, does FTP know the field is EBCDIC
> or Packed or ...? Does FTP change all fields of data as it thinks
> fields are all EBCDIC character?
> So FTP must be with binary option, and change fields before or after
> tranfer. Is this right?



Tue, 09 Mar 2004 13:39:00 GMT  
 VB file MVS<-->UNIX

:>> Does the RDW get stripped when doing a BINARY transfer?

:>Yes, it's stripped.

:>> I would think that the best thing to do is flatten out the file to the same
:>> length across the whole file and append the original RDW to
:>> each record before the FTP process.   Then on the receiving side,
:>> rebuild the Variable file from the Fixed file.  

:>That's just the way we are trying. Anyone know the utility
:>that work like this?

You could probably code up some IEBGENER statements.

Or, perhaps, write a COBOL program to do it.

:>> The BINARY option is not such a good thing since you are working between an
:>> EBCDIC and ASCII platform.   You would have to handle EBCDIC/ASCII
:>> translations of your Display formatted fields and retain the original values
:>> of the Packed/Binary/Hex fields.

:>But if transfered by ASCII mode, does FTP know the field is EBCDIC
:>or Packed or ...? Does FTP change all fields of data as it thinks
:>fields are all EBCDIC character?

FTP does not know. It will change all, including packed and binary fields

:>So FTP must be with binary option, and change fields before or after
:>tranfer. Is this right?

The best approach would be to write a program that will convert a non-display
fields to display and ship the result. This should not be at all difficult if
you have the record descriptions.

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 09 Mar 2004 15:41:48 GMT  
 VB file MVS<-->UNIX


Quote:

> > The BINARY option is not such a good thing since you are working between
an
> > EBCDIC and ASCII platform.   You would have to handle EBCDIC/ASCII
> > translations of your Display formatted fields and retain the original
values
> > of the Packed/Binary/Hex fields.

> But if transfered by ASCII mode, does FTP know the field is EBCDIC
> or Packed or ...? Does FTP change all fields of data as it thinks
> fields are all EBCDIC character?
> So FTP must be with binary option, and change fields before or after
> tranfer. Is this right?

For a reasonably decent explanation of EBCDIC/ASCII and COBOL/IEEE datatypes
conversion issues, see my article at http://www.flexus.com/ebd2asc.html

You have about six different ways to do what you want to do, it's just that
once you pick a method, you'll have to follow it all the way through.

MCM



Tue, 09 Mar 2004 19:48:08 GMT  
 VB file MVS<-->UNIX

Quote:
> Before listing them, there is
> one question that I would ask you - Do you have any MVS programs that do
> negative subscripting to get at the RDW itself?  If so, you need to have a
> Unix compiler that will "emulate" this environment for you (Again Micro
> Focus has such an option - I don't know about the other PC products).

You mean a program which use the RDW within it?
I think I don't have that program.

Quote:
> A couple other alternatives:

> A) For each file that you want to transfer, create a "quick and dirty"
> program that reads the file as defined and creates a new file with
>  - RDW as a separate field
>  - all numeric data as USAGE DISPLAY with SIGN IS SEPARATE
>  - then look at the CODE-SET STANDARD-1 or EBCDIC (if you have it) syntax
>  ... then you just transfer that with normal ASCII/EBCDIC conversion and
> "reconstitute" it on the other platform

I didn't know above way. I refered manual, and understand the way.

Anyway, thank you for reply.



Tue, 09 Mar 2004 21:57:15 GMT  
 VB file MVS<-->UNIX

Quote:

> :>That's just the way we are trying. Anyone know the utility
> :>that work like this?

> You could probably code up some IEBGENER statements.

Can IEBGENER handle RDW and put it into the application data?

Quote:
> The best approach would be to write a program that will convert a non-display
> fields to display and ship the result. This should not be at all difficult if
> you have the record descriptions.

By that way should I make a program for each different format data?


Sun, 14 Mar 2004 19:05:55 GMT  
 VB file MVS<-->UNIX

:>> :>That's just the way we are trying. Anyone know the utility
:>> :>that work like this?

:>> You could probably code up some IEBGENER statements.

:>Can IEBGENER handle RDW and put it into the application data?

Don't think so, but it can make them fixed records.

:>> The best approach would be to write a program that will convert a non-display
:>> fields to display and ship the result. This should not be at all difficult if
:>> you have the record descriptions.

:>By that way should I make a program for each different format data?

Yes, as you would have to make a conversion routine for each data anyway.

--


http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 16 Mar 2004 01:31:45 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. ><><><><>Heeeeeeeeeeeeeeelp on INT 14!><><><><><>

2. <<<<<YOU MUST CHECK THIS OUT >>>>>>>>>> 2103

3. <><><> FLOODFILL <><><>

4. Unix->MVS file transfer; MF COBOL

5. >>>HELP, DECOMPILER<<<

6. <<<XXX Password>>>

7. >>>>>>>>>>>>>>>>>>>HEY!<<<<<<<<<<<<<<<<<<<<<<<

8. <<<XXX Password>>>

9. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

10. <<<XXX Password>>>

11. ??? <<<<<<<<<<<<<<<<<<<< RGB 4 MMX >>>>>>>>>>>>>>>>>>>>>>>?

 

 
Powered by phpBB® Forum Software