Mainframe-PC data conversion not understood 
Author Message
 Mainframe-PC data conversion not understood

I have just started to use PLI for W95
I wish to use an MVS program which I have recompiled on the PC and I
wish to use data downloaded to PC from MVS mainframe. THe data is a VB
file containing a mixture of FB15 FB31 and CHAR data

I downloaded the data using BINARY and CRLF
The data is downloaded preserving the ebcdic but with 0D0A delimiting
the records. I use PLI to read the records on the PC but I have the
following problem and cannot really see where to go

The data structure I am using is declared with the NONNATIVE attribute
I cannot easily predict where character data will be in these records at
this time. It is a dump of a database and the record layouts are in the
database control blocks.

If the file is declared as
DD:DBDUMP=C:\DATABASE\DBDUMP.BIN
then the fixed binary fields are OK but the character fields are garbage
as no conversion is taking place from ebcdic to ascii

If the file is declared as
DD:DBDUMP=C:\DATABASE\DBDUMP.BIN,CHARSET(EBCDIC)
then the char fields are good but the ebcdic to ascii conversion done a
record read time has converted some values (say x'3F') to the ascii
equivalent (in this case x'1A'). It seems that all input bytes are
changed according to translation tables on record read. Any binary data
that contains a hex code that might possibly be character is converted
thus corrupting the binary data on the file.

How can I move data down from mainframe to PC and process it with
(minimal) changes to program so that I can display the character data
correctly and still process the binary data?

Does anyone have any suggestions, please????
Anyone reading from  Team PLI ???
John Wood                                                Birmingham
Lortim Consultants                                       UK



Mon, 08 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood

If you read it in as binary with the FIXED BIN declared as NONNATIVE so that
they're ok, when you determine where the character data is, you can
then convert it to ascii yourself by using the pliascii built-in subroutine.


Quote:

>I downloaded the data using BINARY and CRLF
>The data is downloaded preserving the ebcdic but with 0D0A delimiting
>the records. I use PLI to read the records on the PC but I have the
>following problem and cannot really see where to go

>The data structure I am using is declared with the NONNATIVE attribute
>I cannot easily predict where character data will be in these records at
>this time. It is a dump of a database and the record layouts are in the
>database control blocks.

>If the file is declared as
>DD:DBDUMP=C:\DATABASE\DBDUMP.BIN
>then the fixed binary fields are OK but the character fields are garbage
>as no conversion is taking place from ebcdic to ascii



Mon, 08 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood


Hello John,

Quote:
>I downloaded the data using BINARY and CRLF
>The data is downloaded preserving the ebcdic but with 0D0A delimiting
>the records. I use PLI to read the records on the PC but I have the
>following problem and cannot really see where to go

this is the right way to transfer the data if there is any binary
information you wish to process on an ASCCI machine.

Quote:
>If the file is declared as
>DD:DBDUMP=C:\DATABASE\DBDUMP.BIN
>then the fixed binary fields are OK but the character fields are garbage
>as no conversion is taking place from ebcdic to ascii

>If the file is declared as
>DD:DBDUMP=C:\DATABASE\DBDUMP.BIN,CHARSET(EBCDIC)
>then the char fields are good but the ebcdic to ascii conversion done a
>record read time has converted some values (say x'3F') to the ascii
>equivalent (in this case x'1A'). It seems that all input bytes are
>changed according to translation tables on record read. Any binary data
>that contains a hex code that might possibly be character is converted
>thus corrupting the binary data on the file.

in the first case input is not changed so you see the ASCII values. In
the second case all data is converted from ASCII to EBCDIC.
It is not possible to change some bytes to ASCII and some to EBCDIC,
all or none. :-)

Quote:
>How can I move data down from mainframe to PC and process it with
>(minimal) changes to program so that I can display the character data
>correctly and still process the binary data?

Transfer the data from mainframe, using binary transfer mode.
Write a program who converts the character part of your data from
EBCDIC to ASCII and you can use your program. In C the conversion
program is easy to build.

If you have further question, contact me.

regards

Rainer Schmack

Alcatel Telecom

----------------------------------------------------------------------
"I think there is a world market for maybe five computers."
     --Thomas Watson, chairman of IBM, 1943
----------------------------------------------------------------------



Mon, 08 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood

On Thursday, 97/05/22, John Wood wrote to All about "Mainframe-PC data
convers" as follows:

JW> I have just started to use PLI for W95
JW> I wish to use an MVS program which I have recompiled on the PC and
JW> I wish to use data downloaded to PC from MVS mainframe. THe data is
JW> a VB file containing a mixture of FB15 FB31 and CHAR data
JW>
JW> I downloaded the data using BINARY and CRLF

That's probably not the best way to access the dataset.

JW> The data is downloaded preserving the ebcdic but with 0D0A
JW> delimiting the records. I use PLI to read the records on the PC but
JW> I have the following problem and cannot really see where to go
JW>
JW> The data structure I am using is declared with the NONNATIVE
JW> attribute I cannot easily predict where character data will be in
JW> these records at this time. It is a dump of a database and the
JW> record layouts are in the database control blocks.
JW>
JW> If the file is declared as
JW> DD:DBDUMP=C:\DATABASE\DBDUMP.BIN
JW> then the fixed binary fields are OK but the character fields are
JW> garbage as no conversion is taking place from ebcdic to ascii
JW>
JW> If the file is declared as
JW> DD:DBDUMP=C:\DATABASE\DBDUMP.BIN,CHARSET(EBCDIC)
JW> then the char fields are good but the ebcdic to ascii conversion
JW> done a record read time has converted some values (say x'3F') to the
JW> ascii equivalent (in this case x'1A'). It seems that all input bytes
JW> are changed according to translation tables on record read. Any
JW> binary data that contains a hex code that might possibly be
JW> character is converted thus corrupting the binary data on the file.
JW>
JW> How can I move data down from mainframe to PC and process it with
JW> (minimal) changes to program so that I can display the character
JW> data correctly and still process the binary data?

I would s{*filter*}the CR/LF, since this should be unnecessary. Besides
which, you might have '0D0A'X as a number in a binary field, which will
be mighty confusing.

Since your original dataset should have a 4-byte RDW on the front of
each logical record, allow it to be downloaded with them intact, but
slightly modified. The documentation mentions a sample program called
VRECGEN.PLI, which is a variant of an ADMVS tool and runs on the
mainframe. Run this to build your download file.

After downloading the resultant file in pure binary, this should then
allow you to use TYPE(LL) for the file. You can then use the PLIASCII
built-in function to translate the character fields from EBCDIC to
ASCII.

Regards

Dave
<Team PL/I>
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Thu, 18 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood


"Mainframe-PC data con" as follows:

R> Write a program who converts the character part of your data from
R> EBCDIC to ASCII and you can use your program. In C the conversion
R> program is easy to build.

In PL/I it's even easier: it's a built-in function!

Regards

Dave
<Team PL/I>

 * KWQ/2 1.2i * I despise WINDOWS!
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Thu, 18 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood



Quote:

> After downloading the resultant file in pure binary, this should then
> allow you to use TYPE(LL) for the file. You can then use the PLIASCII
> built-in function to translate the character fields from EBCDIC to
> ASCII.

If you compile your PL/1 prog with the DEFAULT(EBCDIC NONNATIVE) option,
then
you should not have to bother translating your data from EBCDIC at all and
also not need to declare bits of your structures as NONNATIVE.

In fact, if you already have a PL/1 program to read the data on the
mainframe, it may well work unaltered if you use the compiler options to
full advantage.



Fri, 19 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood

Thank you to all who contributed to a helpful discussion, including Team
PL/I. I am still not fully happy with what I should do

There was a suggestion NOT to use CRLF when downloading, but when I
leave this option off, having downloaded from mainframe to PC using a
3270 terminal emulator, I always get
IBM0843I Oncode=1042 A record in the dataset was not properly delimited
but using CRLF its OK and I do not seem to see the 0A0D delimiter

I compiled the sample VRECGEN.PLI on the mainframe and "unloaded" my VB
file to a new file which I then downloaded. The comments about CRLF
above apply.

How should I now access this file? The suggestion to use TYPE(LL) which
I presume goes on the SET DD:.........,TYPE(LL) assignment just seems to
give me protection exceptions.

I tried using READ FILE(DBDUMP) SET(mypointer) and the program hangs
until I press CTRL-BREAK. Should I be using record or stream I/O, or
should it not matter?

I have included my code below to read the first record. Please feel free
to improve on it

pli test3.pli (source attributes(full) options list
set dd:dbdump=c:\ibmpliw\data\dbunld.bin
ilink test3.obj
test3  /xxx

*PROCESS LANGLVL(SAA2 OS2) gostmt DEFAULT(nonnative) AG X;
 Test3: PROCEDURE( PARMS ) OPTIONS( MAIN ) REORDER;
    Dcl  dbdump FILE STREAM;
    display('version 1.2  parms(' || parms || ')');
    OPEN FILE(dbdump) INPUT;
    GET file(dbdump) EDIT(INAREA) (a(32));
    x=addr(pattern); y=addr(pattern); z=13; call pliascii(x,y,z);
    put skip edit('pattern(',hdr_sep.pattern,')') (3 a);
    x=addr(version); y=addr(version); z=1; call pliascii(x,y,z);
    put skip edit('version(',hdr_sep.version,')') (3 a);
    x=addr(ddn); y=addr(ddn); z=8; call pliascii(x,y,z);
    put skip edit('ddn(',hdr_sep.ddn,')') (3 a);
    put skip edit('blkcnt(',hdr_sep.nblk,')') (a,f(9),a);
    put skip edit('blksize(',hdr_sep.blksize,')') (a,f(5),a);
    CLOSE file(dbdump);
    return;
    DECLARE  PARMS CHAR(100) VARYING;
    DECLARE (x,y) pointer;
    DECLARE z fixed bin(31);
    DCL INAREA CHAR(32),
         1 HDR_SEP   based(ADDR(INAREA)) ,
           2 VBLL    fixed bin(15),
           2 PATTERN CHAR(13),
           2 VERSION CHAR(1),
           2 UNUSED  CHAR(2),
           2 DDN     CHAR(8),
           2 NBLK    FIXED BIN(31),
           2 BLKSIZE FIXED BIN(15);
    DECLARE (ADDR,LENGTH,NULL,SUBSTR,oncode,plidump) BUILTIN;
    DECLARE PLIASCII builtin;
 END;

Field VBLL in above structure was a field added to the mainframe file
using the program VRECGEN.PLI

The output from this program is currently correct, with text fields now
in ASCII and binary fields correctly interpreted
The first record is 30 bytes (plus 2 from VRECGEN)
Followed by NBLK records at BLKSIZE bytes each
This sequence is repeated until end of file

All help appreciated
John Wood                                                Birmingham
Lortim Consultants                                       UK



Sun, 21 Nov 1999 03:00:00 GMT  
 Mainframe-PC data conversion not understood

In a message dated 06-04-97, John Wood said to All about Mainframe-pc Data
Conversion

JW>There was a suggestion NOT to use CRLF when downloading, but when I
JW>leave this option off, having downloaded from mainframe to PC using a
JW>3270 terminal emulator, I always get
JW>IBM0843I Oncode=1042 A record in the dataset was not properly delimited
JW>but using CRLF its OK and I do not seem to see the 0A0D delimiter

This is because you haven't specified TYPE(LL). You'll never see the '0D0A'X
delimiter because it is swallowed by the run-time library when you use the
default TYPE(TEXT). Leaving the CR/LF pairs in the data is a bug waiting to
bite you, IMHO.

JW>I compiled the sample VRECGEN.PLI on the mainframe and "unloaded" my VB
JW>file to a new file which I then downloaded. The comments about CRLF
JW>above apply.

JW>How should I now access this file? The suggestion to use TYPE(LL) which
JW>I presume goes on the SET DD:.........,TYPE(LL) assignment just seems to
JW>give me protection exceptions.

The TYPE(LL) option can go on the SET DD: statement or in the TITLE() option
of the OPEN. I prefer the latter on largely aesthetic grounds.

If there had been anything syntactically wrong with your SET options, it
should have raised UNDEFINEDFILE() on the offending file. Were the
protection exceptions in your code or the RTL? Did they occur on OPEN or
READ statements?

JW>I tried using READ FILE(DBDUMP) SET(mypointer) and the program hangs
JW>until I press CTRL-BREAK. Should I be using record or stream I/O, or
JW>should it not matter?

With binary fields you'll be better off using RECORD transmission.

JW>I have included my code below to read the first record. Please feel free
JW>to improve on it

JW>pli test3.pli (source attributes(full) options list
JW>set dd:dbdump=c:\ibmpliw\data\dbunld.bin

set dd:dbdump=c:\ibmpliw\data\dbunld.bin,type(ll),recsize(32)

[You might care to do a bit of RTFM on the DD options on the workstation.
There is no format-1 DSCB under Win 95.]

JW>ilink test3.obj
JW>test3  /xxx

JW>*PROCESS LANGLVL(SAA2 OS2) gostmt DEFAULT(nonnative) AG X;
JW> Test3: PROCEDURE( PARMS ) OPTIONS( MAIN ) REORDER;

The REORDER option nows goes in the OPTIONS() list. [Although the old style
is tolerated by the compiler.]

JW>    Dcl  dbdump FILE STREAM;

DCL dbdump FILE RECORD;

JW>    display('version 1.2  parms(' || parms || ')');
JW>    OPEN FILE(dbdump) INPUT;
JW>    GET file(dbdump) EDIT(INAREA) (a(32));

READ FILE(dbdump) INTO(HDR_SEP);

JW>    x=addr(pattern); y=addr(pattern); z=13; call pliascii(x,y,z);
JW>    put skip edit('pattern(',hdr_sep.pattern,')') (3 a);
JW>    x=addr(version); y=addr(version); z=1; call pliascii(x,y,z);
JW>    put skip edit('version(',hdr_sep.version,')') (3 a);
JW>    x=addr(ddn); y=addr(ddn); z=8; call pliascii(x,y,z);
JW>    put skip edit('ddn(',hdr_sep.ddn,')') (3 a);
JW>    put skip edit('blkcnt(',hdr_sep.nblk,')') (a,f(9),a);
JW>    put skip edit('blksize(',hdr_sep.blksize,')') (a,f(5),a);

Lots of calls to the stream output transmitter! Only one is needed. We can
also optimize the pointers x and y, and the integer z out of existance. The
LENGTH() values should be determined at compile time and PUSHed or MOVed as
constants. [This built-in is ideal for Optlink linkage under OS/2, probably
Fastcall under Win32, so I would guess the MOV instruction would be used,
rather than PUSH.]

       CALL PLIASCII(ADDR(pattern),ADDR(pattern),LENGTH(pattern));
       CALL PLIASCII(ADDR(version),ADDR(version),LENGTH(version));
       CALL PLIASCII(ADDR(ddn),ADDR(ddn),LENGTH(ddn));

       PUT FILE(SYSPRINT) EDIT
       ('pattern(',pattern,')',
          'version(',version,')',
          'ddn(',ddn,')')
       (SKIP,3 A)
       ('blkcnt(',nblk,')')
       (SKIP,A,F(9),A)
       ('blksize(',blksize')')
       (SKIP,A,F(5),A);

The above will do all its printing for a record in a single starting and
terminating of the transmitter for SYSPRINT. [Assuming that the workstation
RTL uses file transmitter routines. Peter? Carolyn?]

Also, I like to declare SYSPRINT and name it explicitly in each PUT
statement. Furthermore, I like to open and close SYSPRINT explicitly, since
I can put overrides on the OPEN statement, such as PAGESIZE(), etc.

JW>    CLOSE file(dbdump);
JW>    return;
JW>    DECLARE  PARMS CHAR(100) VARYING;
JW>    DECLARE (x,y) pointer;
JW>    DECLARE z fixed bin(31);

This (z) will be NONNATIVE too! (I.e. slower access.) But since we optimized
it out of existance above, it matters not. The 2 previous declares can also
go west (or into the bit bucket, or down the gurgler, wherever).

JW>    DCL INAREA CHAR(32),

Not needed when you use RECORD transmission.

JW>         1 HDR_SEP   based(ADDR(INAREA)) ,

Why not make just this structure NONNATIVE and let the other stuff run
faster? Drop the DEFAULT(NONNATIVE) compilation option. This then becomes:

DCL  1  HDR_SEP         NONNATIVE,

JW>           2 VBLL    fixed bin(15),

No longer needed with TYPE(LL).

JW>           2 PATTERN CHAR(13),
JW>           2 VERSION CHAR(1),
JW>           2 UNUSED  CHAR(2),
JW>           2 DDN     CHAR(8),
JW>           2 NBLK    FIXED BIN(31),
JW>           2 BLKSIZE FIXED BIN(15);
JW>    DECLARE (ADDR,LENGTH,NULL,SUBSTR,oncode,plidump) BUILTIN;
JW>    DECLARE PLIASCII builtin;
JW> END;

You have no facility above for checking for "short" records, where a
spurious '0D0A'X has caused a record to be truncated. If you use RECORD
transmission, the RECORD(dbdump) condition will be raised if things are not
according to Hoyle. This will then show you if you have been bitten by using
the CR/LF option on the download.

Regards

Dave
<Team PL/I>
___
 * MR/2 2.25 #353 * Do vegetarians eat animal crackers?
--
Please remove the '$' in the from line before reply via email.
Anti-UCE filter in operation.



Wed, 24 Nov 1999 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. mainframe to pc assembler conversion

2. IBM mainframe to PC conversion problem ?

3. Data conversion on READ (why not?)

4. Request for help understanding IBM mainframe architecture.

5. Cobol - Data Exception (Conversion Data).

6. APP runs on one PC but not another PC

7. APP runs on one PC but not another PC

8. PC keys shuffled +/or not working in F-PC

9. tandem COBOL to IBM Mainframe MVS COBOL Conversion

10. File conversion from IBM Mainframe to Windows NT platform!!!Help Me

11. US-MN $60K-$70K Project Leader, MVS Mainframe/COBOL/Conversion

12. Mainframe to Unix Cobol conversion?

 

 
Powered by phpBB® Forum Software