| View previous topic :: View next topic |
| Author |
Message |
misi01
Advanced
Joined: 02 Dec 2002
Posts: 620
Topics: 173
Location: Stockholm, Sweden
|
 Posted: Tue Jan 29, 2019 2:13 am Post subject: Replace character using ICETOOL |
 |
|
This is my JCL
| Code: |
//CATENAT EXEC PGM=ICETOOL
//*
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//*
//IN01 DD DISP=SHR,DSN=SIMMIC.DIALTELT.DI.KBN030.HHHWK08.DIVIDER
//IN02 DD DISP=SHR,DSN=SIMMIC.DIALTELT.DI.KBN030.HHHWK08.AFTER
//IN03 DD DISP=SHR,DSN=SIMMIC.DIALTELT.DI.KBN030.HHHWK09.DIVIDER
//IN04 DD DISP=SHR,DSN=SIMMIC.DIALTELT.DI.KBN030.HHHWK09.AFTER
//*
//OUT DD DSN=SIMMIC.DIALTELT.DI.KBN030.RESULTS.AFTER,
// DISP=(MOD,CATLG,),
// DCB=(RECFM=FB,LRECL=1000)
//*
//TOOLIN DD *
COPY FROM(IN01) TO(OUT) USING(CTL1)
COPY FROM(IN02) TO(OUT) USING(CTL1)
COPY FROM(IN03) TO(OUT) USING(CTL1)
COPY FROM(IN04) TO(OUT) USING(CTL1)
/*
//CTL1CNTL DD *
OUTREC FINDREP=(IN=X'00',OUT=C' ')
/*
|
I define the output file as 1000 bytes since, with DCB's, it seems (and I assume) that ICETOOL takes the DCB's from the first file mentioned (RECFM=FB, LRECL=80) and uses it for the output results (fair enough).
What I thought I would see is all hex nulls converted to blanks, but that doesn't seem to be happening.
| Quote: |
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK08.AFTER'
191231 ..............................
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK09.AFTER'
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK10.AFTER'
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK11.AFTER'
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK12.AFTER'
2000432183BG BW 2000432183033330äTOK001IMF-KUND 190116 181213
2000432407BG 08 2000432407000000äTOK001IMF-KUND 190116 181206
2000431839BG BW 2000431839000000äTOK002IMF-KUND 190116 181205
2000432712BG AU 2000432712000000äTOK004Testkund 190116 (SMORT)
2000432860BG AU 2000432860000000äTOK004TestfÖretag1 190116 (SMORT)
2000432878BG AU 2000432878000000äTOK004TestfÖretag1 190116 (SMORT)
2000433355 AU 2000433355000000äTOK004Testperson 190116 IPS/AC
2000433314BG AU 2000433314000000äTOK004IMF-KUND 190116 181206
2000432886 AU 2000432886000000äTOK005IMF-KUND 190116 181130
2000431847 AU 2000431847000000äTOK005IMF-KUND 190116 181130
2000432704 AU 2000432704000000äTOK005Testperson 190116 (SMORT)
2000433330BG AU 2000433330000000äTOK005IMF-KUND 190116 181206
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK13.AFTER'
191231
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK14.AFTER'
>>>>>>> The file mentioned above is LRECL 40, the dots shown below are all hex nulls <<<<<<<
191231 ........................................
SYDIXNY NYSYDIX ........................................
FA FA ........................................
AN AN ........................................
PA PA ........................................
INTERNY NYINTER ........................................
|
What am I doing wrong?
_________________
Michael |
|
| Back to top |
|
 |
Nic Clouston
Advanced
Joined: 01 Feb 2007
Posts: 1075
Topics: 7
Location: At Home
|
| Posted: Tue Jan 29, 2019 5:57 am Post subject: |
|
|
i do not understand the quoted text. Why is it quoted? Should it not be plain text with the data enclosed by the code tags as per you JCL? Where do these data sets HHHWK10-14 come from? What about those DIVIDER data sets?
_________________
Utility and Program control cards are NOT, repeat NOT, JCL. |
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 620
Topics: 173
Location: Stockholm, Sweden
|
| Posted: Tue Jan 29, 2019 6:28 am Post subject: |
|
|
The quoted text is the content of the file created. As to whether that means it should be "defined" as CODE or QUOTEs is, according to me, a matter of taste.
The files coming in are created by a program. The Divider files are all of the type
| Quote: |
Following records belong to file 'SIMMIC.DIALTELT.DI.KBN030.HHHWK08.AFTER'
|
the idea being that if you have a catenated file with 1000's of records and there's a discrepancy in the results, by scrolling upwards, you can see which file it is that contains the discrepancy.
Did that make it clearer?
_________________
Michael |
|
| Back to top |
|
|
kolusu
Site Admin
Joined: 26 Nov 2002
Posts: 12368
Topics: 75
Location: San Jose
|
| Posted: Tue Jan 29, 2019 11:10 am Post subject: Re: Replace character using ICETOOL |
|
|
| misi01 wrote: |
I define the output file as 1000 bytes since, with DCB's, it seems (and I assume) that ICETOOL takes the DCB's from the first file mentioned (RECFM=FB, LRECL=80) and uses it for the output results (fair enough).
|
misi01,
DFSORT pads fixed-length records with binary zeros on the right when the SORTOUT LRECL is larger than the SORTIN LRECL.
This is explained here
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.icea100/ice2ca_Padding_and_truncation.htm
If you had OPTION PAD=RC16 in CTL1CNTL then you would have a more meaningful message in the form of ICE196A
| Code: |
ICE196A 0 SORTOUT LRECL OF 1000 IS DIFFERENT FROM SORTIN(NN) LRECL OF 80 - RC=16
|
| misi01 wrote: |
What I thought I would see is all hex nulls converted to blanks, but that doesn't seem to be happening.
What am I doing wrong? |
DFSORT when setting up the FINDREP looks at the input file LRECL and INREC statement to account as to where it has to find and replace the data. Since your input file is only 80 bytes, FINDREP stops processing at 80 bytes. The JCL override of the LRECL comes into picture when are writing out the record.
If your intention is to just space out records on the right of the max lrecl , then you can do it much more efficiently than using a FINDREP.
Simply change the CTL1CNTL to the following.
| Code: |
//CTL1CNTL DD *
INREC OVERLAY=(1000:X)
/* |
This will automatically pad your records with spaces up until 1000 bytes.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
www.linkedin.com/in/kolusu |
|
| Back to top |
|
|
Nic Clouston
Advanced
Joined: 01 Feb 2007
Posts: 1075
Topics: 7
Location: At Home
|
| Posted: Tue Jan 29, 2019 11:29 am Post subject: |
|
|
Quoting data does not retain spacing as the quoting font is not mono-spaced.
Quoted:
Coded:
_________________
Utility and Program control cards are NOT, repeat NOT, JCL. |
|
| Back to top |
|
|
misi01
Advanced
Joined: 02 Dec 2002
Posts: 620
Topics: 173
Location: Stockholm, Sweden
|
| Posted: Wed Jan 30, 2019 1:38 am Post subject: |
|
|
Thanks Kolusu - that did the trick.
Nic - whether I choose code or quote tags, the relevant point (to me) was all the dots indicating the low values in the output file.
_________________
Michael |
|
| Back to top |
|
|
Nic Clouston
Advanced
Joined: 01 Feb 2007
Posts: 1075
Topics: 7
Location: At Home
|
| Posted: Wed Jan 30, 2019 5:12 am Post subject: |
|
|
The relevnt point for anyone reading the topic is that the quoted stuff does not look like data because of the variable pitch font. If you think that the dots are all that are relevant then post only the dots. The dots have a context which is the data surrounding them. Code tags are for ANyTHING that should have a fixed pitch font i.e. everything that appears on the 3270 screen.
_________________
Utility and Program control cards are NOT, repeat NOT, JCL. |
|
| Back to top |
|
|
|
|
|
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
