IBM Mainframe Forum

by **RalphEagle** » Wed Jul 21, 2021 3:33 pm

Hi,

I am trying to copy a VB dataset to another defined with RECFM=U (because I would like to keep the RDW so they are not stripped in FTP transfers, but that's besides the point).

So I have my VB dataset displaying as such:

Select all

 ATW  2019000029                    0001
etc

My VB has a record length of 3048 and a block size of 6233.

I am using IEBGENER to make the copy:

Select all

//STEP005  EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DISP=SHR,DSN=WORK.JOHN
//SYSUT2   DD DSN=WORK.JOHN.RESULT,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(10,10),RLSE),
//            DCB=(RECFM=U,LRECL=32756)
//SYSIN    DD DUMMY
//

I am using deliberately a LRECL of 32756 because as I understood, U datasets should simply be raw binary data, with BDW and RDW as the start of each line and block. So the idea is to maximise the length on which the data is copied in raw format.

But the resulting dataset is very strange:

Select all

.. V...U.bATW.c2019:.0a29.:.0h1etc

We can see the first bytes which seem to be BDW and RDW but the rest seems different; the 0s between 2019 and 29 in the number above are replaced by strange characters, and the same seemed to happen for the spaces. Also, the record length seems to have been kept at 3044 on display.

Is there anything wrong with the way I did?

My idea was to have a VB file such as:

Select all

ABC 123
ABC 456789

Copied to a U file as:

Select all

....ABC 123....ABC 456789

Thank you for your help,

by **sergeyken** » Wed Jul 21, 2021 6:35 pm

1) with RECFM=U, all RDW etc, if any, are considered as part of normal data, nothing else.

2) non-printable characters might be displayed in character format differently while various viewing tools are used; in order to verify the real values use hexadecimal viewing tool mode.

3) generally, IEBGENER utility is not supposed to handle RECFM=U properly. Any (rarely used) dataset with RECFM=U I’ve ever seen in my life always required a specific program to handle them. The idea of RECFM=U itself was: “there is no common universal standard program to handle this dataset; you need to create your own program to handle it in your specific manner”.

Mainly, access methods BSAM or BDAM are required (at low I/O level) to handle these datasets. It can be fully controlled only when using Assembler, or languages like C/C++. Other languages may be used only with restrictions, and with good understanding of internal implementation of I/O operations in their environment.

by **willy jensen** » Wed Jul 21, 2021 10:16 pm

Not sure it will work, but try adding RECFM=U to the input DD statement too.

by **willy jensen** » Wed Jul 21, 2021 10:22 pm

I just tried it, it does seem to work.

by **steve-myers** » Wed Jul 21, 2021 11:15 pm

Yes: you must also specify DCB=(RECFM=U,BLKSIZE=6233) for the DD statement with DD name SYSUT1. IEBGENER will copy each data block; BDW, and every RDW to the output data set.

As proof of concept I wrote this JCL.

Select all

//PREP    EXEC PGM=IEFBR14
//VB2U     DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..VB2U.DATA
//B       EXEC PGM=IEBGENER
//SYSPRINT DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=&SYSUID..DSSTAT.ASMLIST,
//             DCB=RECFM=U
//SYSUT2   DD  DISP=(,CATLG),UNIT=SYSDA,SPACE=(TRK,(10,10),RLSE),
//             DSN=*.PREP.VB2U
//SYSIN    DD  DUMMY
//C       EXEC PGM=IKJEFT01
//STEPLIB  DD  DISP=(SHR,PASS),DSN=&SYSUID..LOAD
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  *
LISTD (DSSTAT.ASMLIST VB2U.DATA)
RDUMP DSSTAT.ASMLIST NODCB FOR(1)
RDUMP VB2U.DATA NODCB FOR(1) MOD

The data set was just a handy data set with RECFM=VB. I did not specify the BLKSIZE parameter in the SYSUT1 DD statement because IEBGENER wil use the BLKSIZE in the data set label. It also copied the LRECL parameter from SMYERS.DSSTAT.ASMLIST The RDUMP command is a handy private TSO command to dump records; its NODCB option just forces RECFM=U, BLKSIZE=32760. FOR(1) limits the output to 1 input record.

The output from the TSO step (step C in the JCL is -

Select all

READY
LISTD (DSSTAT.ASMLIST VB2U.DATA)
SMYERS.DSSTAT.ASMLIST
--RECFM-LRECL-BLKSIZE-DSORG
  VBM   137   27998   PS
--VOLUMES--
  CBTSTG
SMYERS.VB2U.DATA
--RECFM-LRECL-BLKSIZE-DSORG
  U     137   27998   PS
--VOLUMES--
  CBTSTG
READY
RDUMP DSSTAT.ASMLIST NODCB FOR(1)
RDMP001I RDUMP completed, output in SMYERS.RDUMP.OUTPUT
READY
RDUMP VB2U.DATA NODCB FOR(1) MOD
RDMP001I RDUMP completed, output in SMYERS.RDUMP.OUTPUT
READY
END

Part of the output in SMYERS.RDUMP.OUTPUT is

Select all

**************************** SMYERS.DSSTAT.ASMLIST *****************
                                                                    
RUN AT 07/21/21 13:15                                               
                                                                    
DCB - RECFM=U, LRECL=137, BLKSIZE=32,760                            
                                                                    
                                                                    
*** RECORD 1                                                        
                                                                    
0000     0  6D340000 00050000  8B007D00 00194040  *_.........'...  *
0010    16  40404040 40404040  40404040 40404040  *                *
            ONE OR MORE LINES SAME AS PREVIOUS LINE                 
0030    48  40404040 404040C8  89878840 D385A585  *       High Leve*
...
6D20 27936  40404040 40404040  40404040 F0F6F8F8  *            0688*
6D30 27952  F0F0F0F0                              *0000            *
                                                                    
                                                                    
                                                                    
******************************* SMYERS.VB2U.DATA *******************
                                                                    
RUN AT 07/21/21 13:15                                               
                                                                    
DCB - RECFM=U, LRECL=137, BLKSIZE=32,760                            
                                                                    
                                                                    
*** RECORD 1                                                        
                                                                    
0000     0  6D340000 00050000  8B007D00 00194040  *_.........'...  *
0010    16  40404040 40404040  40404040 40404040  *                *
            ONE OR MORE LINES SAME AS PREVIOUS LINE                 
0030    48  40404040 404040C8  89878840 D385A585  *       High Leve*
0040    64  9340C1A2 A2859482  93859940 D697A389  *l Assembler Opti*
0050    80  969540E2 A4949481  99A84040 40404040  *on Summary      *
0060    96  40404040 40404040  40404040 404DD7E3  *             (PT*
0070   112  C640E4C9 F7F6F0F2  F45D4040 40D78187  *F UI76024)   Pag*
...
6D10 27920  D7D7D340 40404040  40404040 40404040  *PPL             *
6D20 27936  40404040 40404040  40404040 F0F6F8F8  *            0688*
6D30 27952  F0F0F0F0                              *0000            *
******************************** Bottom of Data ********************

The 6D340000 is the BDW (Block Descriptor Word) Followed by the 00050000 RDW (Record Descriptor Word) for a 5 byte record, and so on.

by **willy jensen** » Thu Jul 22, 2021 1:26 am

I just did

Select all

//G1      EXEC PGM=IEBGENER   
//SYSPRINT DD SYSOUT=*        
//SYSIN    DD DUMMY           
//SYSUT1   DD DISP=SHR,DSN=input-dsn,RECFM=U  
//SYSUT2   DD DISP=(,CATLG),DSN=output-dsn,             
//        UNIT=SYSDA,BLKSIZE=0,SPACE=(TRK,(2,2)),RECFM=U    

and did an ISPF VIEW with hex.
The input dsn is recfm VB lrecl 256.

by **RalphEagle** » Thu Jul 22, 2021 10:31 pm

It does work indeed! I am not sure what happened with my first file, I suspect there were some 'ALLOC' TSO commands issued on it in a Rexx I don't control which might explain why the memory space for this DSN was corrupted.

I do end up having the file with BDW and RDW!

Thank you!!

by **sergeyken** » Fri Jul 23, 2021 3:06 am

Has anyone tested the behavior of IEBGENER when the total size of data in SYSUT1 exceeds the BLKSIZE value which has been set for SYSUT2?
How the transition between SYSUT2 records/blocks should be handled?

by **willy jensen** » Fri Jul 23, 2021 1:27 pm

yes, I tried to set lrecl=60 for both input and output, where the input records physical lrecl was gt 80, and it worked fine.

by **sergeyken** » Sat Jul 24, 2021 6:19 am

willy jensen wrote:yes, I tried to set lrecl=60 for both input and output, where the input records physical lrecl was gt 80, and it worked fine.

“Fine” - stands for what?

I wonder how the last V record is fit into the end of U physical block? Either the first part of record is placed at the very end of one block, and the tail of the same record moved to the beginning of the next block? Or the whole record is moved to the beginning of the next block when it does not fit the end of previous one?

IBM Mainframe Forum

Copy a VB dataset to U

Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U

Re: Copy a VB dataset to U