Copy a VB dataset to U



JES, JES2, JCL utilities, IDCAMS, Compile & Run JCLs, PROCs etc...

Copy a VB dataset to U

Postby 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:
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:
//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:
.. 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:
ABC 123
ABC 456789


Copied to a U file as:
....ABC 123....ABC 456789


Thank you for your help,
RalphEagle
 
Posts: 22
Joined: Mon Apr 23, 2018 2:51 pm
Has thanked: 16 times
Been thanked: 0 time

Re: Copy a VB dataset to U

Postby 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.
Javas come and go, but JCL stays forever.
User avatar
sergeyken
 
Posts: 192
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 3 times
Been thanked: 18 times

Re: Copy a VB dataset to U

Postby 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.

These users thanked the author willy jensen for the post:
RalphEagle (Thu Jul 22, 2021 7:15 pm)
willy jensen
 
Posts: 347
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 48 times

Re: Copy a VB dataset to U

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

I just tried it, it does seem to work.
willy jensen
 
Posts: 347
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 48 times

Re: Copy a VB dataset to U

Postby 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.

//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 -

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

**************************** 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.

These users thanked the author steve-myers for the post:
RalphEagle (Thu Jul 22, 2021 10:07 pm)
steve-myers
Global moderator
 
Posts: 2094
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 236 times

Re: Copy a VB dataset to U

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

I just did
//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.

These users thanked the author willy jensen for the post:
RalphEagle (Thu Jul 22, 2021 10:07 pm)
willy jensen
 
Posts: 347
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 48 times

Re: Copy a VB dataset to U

Postby 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!!
RalphEagle
 
Posts: 22
Joined: Mon Apr 23, 2018 2:51 pm
Has thanked: 16 times
Been thanked: 0 time

Re: Copy a VB dataset to U

Postby 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?
Javas come and go, but JCL stays forever.
User avatar
sergeyken
 
Posts: 192
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 3 times
Been thanked: 18 times

Re: Copy a VB dataset to U

Postby 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.
willy jensen
 
Posts: 347
Joined: Thu Mar 10, 2016 5:03 pm
Has thanked: 0 time
Been thanked: 48 times

Re: Copy a VB dataset to U

Postby 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?
Javas come and go, but JCL stays forever.
User avatar
sergeyken
 
Posts: 192
Joined: Wed Jul 24, 2019 10:12 pm
Has thanked: 3 times
Been thanked: 18 times

Next

Return to JCL

 


  • Related topics
    Replies
    Views
    Last post