Joining 2 datasets with SYNCSORT, is it possible to wildcard some values of F1 in any way?
I want to search for the word BEER, but in F2, the values might be BEER or BEER-BLONDE, or etc..
Here is the code I have now. If F2 contains BEER-BLONDE, the record is not paired because the value is not BEER (with 16 spaces after), but I still need to set the code to 0000100002.
//STEP01 EXEC PGM=SORT,PARM='DYNALLOC=(SYSDA,255)'
//SORTMSGS DD SYSOUT=*
//SORTJNF1 DD *
0000100001WINE
0000100002BEER
0000100003OTHER
/*
//SORTJNF2 DD DSN=ZZ.MAINDATA,
// DISP=SHR,DCB=BUFNO=255
//SORTOUT DD DSN=ZZ.OUTPUT,
// DISP=(NEW,CATLG,DELETE),
// UNIT=(SYSDA,59),
// SPACE=(CYL,(500,100),RLSE)
//SYSIN DD *
JOINKEYS FILE=F1,FIELDS=(11,20,A)
JOINKEYS FILE=F2,FIELDS=(40,20,A)
JOIN UNPAIRED,F2
REFORMAT FIELDS=(F2:1,10,F1:1,10,F2:21,20)
OPTION COPY
//DFSPARM DD *
MSGDDN=SORTMSGS
I don't/can't list all possibilities (example below) as they will change too frequently, it can be set to anything.
//SORTJNF1 DD *
0000100001WINE
0000100002BEER
0000100002BEER-BLONDE
0000100002BEER-BROWN
0000100002BEER-WHITE
0000100002BEER-DARK
0000100003OTHER
/*
Is there something I can do with SORT or ICETOOL to address that problem?
Thanks
Instead of using a JOIN to change a value based on another value (on the same row), I later learn that one can simply use IFTHEN with SYNCSORT
//SYSIN DD *
OPTION COPY
INREC IFTHEN=(WHEN=(40,11,CH,EQ,C'BEER-BLONDE'),OVERLAY=(11:C'0000100002')),
IFTHEN=(WHEN=(40,10,CH,EQ,C'BEER-BROWN'),OVERLAY=(11:C'0000100002')),
IFTHEN=(WHEN=(40,10,CH,EQ,C'BEER-WHITE'),OVERLAY=(11:C'0000100002')),
IFTHEN=(WHEN=(40,9,CH,EQ,C'BEER-DARK'),OVERLAY=(11:C'0000100002')),
IFTHEN=(WHEN=(40,4,CH,EQ,C'BEER'),OVERLAY=(11:C'0000100002')),
IFTHEN=(WHEN=(40,4,CH,EQ,C'WINE'),OVERLAY=(11:C'0000100001')),
IFTHEN=(WHEN=(40,5,CH,EQ,C'OTHER'),OVERLAY=(11:C'0000100003'))
Related
I have a VSAM which has
• 4-byte binary unsigned integer representing a 6-digit decimal branch sortcode (e.g. 420101)
• 4-byte binary unsigned integer representing an 8-digit account number (e.g. 12345678)
• 4-byte signed integer holding the account's current balance
• 32-byte EBCDIC character account owner name (e.g. “PAT JONES”), blank padded on the right
and I want to generate a report as below
I was trying to do this
INCLUDE COND=(1,7,CH,EQ,C'some sortcode')
SORT FIELDS=(1,7,CH,A)
SUM FIELDS=(9,2,BI)
But there's plenty of sortcode. I am thinking of sort all the inputs and then sum every record that has the same sortcode together right underneath these sortcode rows. Is there any way in JCL I can do that? Thanks.
Try this:
//SORTSTEP EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SORTIN DD DSN=YourInputDataset,DISP=SHR
//SORTOUT DD DSN=YourOutputDataset,
// DISP=(NEW,CATLG,DELETE)
//SYSIN DD *
SORT FIELDS=(1,4,BI,A)
INREC BUILD=(1,4,BI,TO=ZD,LENGTH=6,5,4,9,4,13,32)
OUTFIL REMOVECC,
SECTIONS=(1,6,
HEADER3=(1:C'LIST OF BANK BY BRANCH',/,X,/,
1:C'SORTCODE: ',1,6,/,X,/,
1:C'ACCOUNT',10:C'BALANCE',20:C'OWNER NAME',/,
1:C'-------',10:C'-------',20:C'----------'),
TRAILER3=(X,/,
1:C'BRANCH TOTAL: ',16:TOT=(11,4,BI,EDIT=(SIIIITTT),SIGNS=(,-)))),
TRAILER1=(X,/,1:C'GRAND TOTAL: ',TOT=(11,4,BI,
EDIT=(SIIIITTT),SIGNS=(,-))),
OUTREC=(1:7,4,BI,TO=ZD,LENGTH=8,10:11,4,BI,EDIT=(SIIIITTT),
SIGNS=(,-),20:15,32)
/*
You can find about more about SECTIONS, HEADER3 and TRAILER3 at this link: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.iceg200/ice2cg_Sections.htm
I would like to know what the difference between these two lines of code :-
//STEP1.SYSIN DD *
and
//STEP1.SYSIN and STEP1.SYSIN DD &SYSUID..COBOL(CBL0001),DISP=SHR
and if there are any differences.
//STEP1.SYSIN DD *
Will pass the data in the lines following the statement as instream-data to the SYSIN DD e.g.
//SYSIN DD *
fred
bert
harry
Would result in the three lines being read when SYSIN is opened and read for input.
//STEP1.SYSIN DD DSN=&SYSUID..COBOL(CBL0001),DISP=SHR
Will allocate the PDS/PDSE member CBL0001 of the dataset user.COBOL (where user will be the userid (i.e. &SYSUID. resolves to the submitter's userid) of the user who submitted the job) to DD name SYSIN.
//STEP1.SYSIN
As used by both, is saying to override or add the SYSIN DD statement for the procedure step name STEP1 (the procedure itself would be defined in the preceding JCL).
The difference will be that the data read by SYSIN will be different (i.e. from a different source, it could be the same underlying data), the first will be the data that follows the JCL statement, the second will be the data held in member CBL001 (both would likely be a COBOL program).
With instream-data, the data will end if /* is coded or if a DD statement is coded or if nothing else follows(as shown above) e.g.
//STEP1.SYSIN DD *
fred
bert
harry
/*
...... more JCL here
or
//STEP1.SYSIN DD *
fred
bert
harry
//STEP1.OTHER DD .........
Instead of * DATA can be used e.g. (same result as above i.e. three lines)
//STEP1.SYSIN DD DATA
fred
bert
harry
/*
In both cases * or DATA you can specify the delimiter using DLM e.g.
//STEP1.SYSIN DD *,DLM="%%"
fred
bert
//harry
%%
( in which case the third line will be //harry)
I'm using DFSORT's ICETOOL DISPLAY operator to generate a list of accounts. I'm using a 'BREAK' on the branches to separate the accounts by sortcode and then sum the balance for the account. Everything works fine, but I get an additional entry(account) after summing the balance using BTOTAL. I've added my code below and the result so you better understand my question.
code
//SUR0007 JOB (5678),'ACCOUNTS'
//RUNIT EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//TOOLIN DD *
DISPLAY FROM(INPUT2) LIST(REPORT) -
TITLE('LIST OF BANK ACCOUNTS BY BRANCH') -
HEADER('ACCOUNT') ON(2,8,BI,E'99999999') -
HEADER('BALANCE') ON(3,6,BI,E'99999999') -
HEADER('OWNER') ON(13,30,CH) -
BTITLE('SORTCODE:') BREAK(1,4,BI,E'999999') -
BTOTAL('BRANCH TOTAL:') -
TOTAL('GRAND TOTAL:')
/*
//INPUT2 DD DSN=USER.CICS.Z022.BANK.ACCOUNTS,DISP=SHR
//REPORT DD SYSOUT=*
result
SORTCODE:000012
ACCOUNT BALANCE
-------- --------
91317760 97999587
BRANCH TOTAL :
91317760 97999587
Expected result
SORTCODE:000012
ACCOUNT BALANCE
-------- --------
91317760 97999587
BRANCH TOTAL : 97999587
DFSORT's ICETOOL DISPLAY operator has many options, which means there is extensive documentation for it.
You should consult the DFSORT Getting Started manual for introductory-level use, and DFSORT Application Programming Guide for more high-level use.
Within BCOUNT, all numeric fields will appear with totals. Your account is numeric (binary), but if you can't make it non-numeric you can use NOST (you can pretend that means NO Sub-Totals) as part of the formatting for any field that you do not want to be summed automatically.
To get your BTOTAL text to appear on the same line as the totals, use STATLEFT in the report description.
Here's an example of the use of both from the Application Programming Guide:
DISPLAY FROM(ACCTS) LIST(FANCY) -
TITLE('Accounts Report for First Quarter') -
DATE(MD4/) BLANK -
HEADER('Amount') ON(12,6,ZD,C1,N08) -
HEADER(Id') ON(NUM,N02) -
HEADER('Acct#') ON(31,3,PD,NOST,LZ) -
HEADER('Date') ON(1,4,ZD,E'99/99',NOST) -
INDENT(2) BETWEEN(5) -
STATLEFT -
TOTAL('Total for Q1') -
AVERAGE('Average for Q1')
There is coding for a plain version of the same report:
DISPLAY FROM(ACCTS) LIST(PLAIN) -
TITLE('Accounts Report for First Quarter') -
DATE(MD4/) BLANK -
HEADER('Amount') ON(12,6,ZD) -
HEADER(Id') ON(NUM) -
HEADER('Acct#') ON(31,3,PD) -
HEADER('Date') ON(1,4,ZD) -
TOTAL('Total for Q1') -
AVERAGE('Average for Q1')
The output, with explanation from the example, is:
This example shows some options you can use to improve the appearance
of a DISPLAY report. The first DISPLAY operator produces a "plain"
report, and the second DISPLAY operator uses the options shown in bold
to produce a "fancy" report.
The PLAIN output starts on a new page and looks as follows:
Accounts Report for First Quarter 05/04/2001
Amount Id Acct# Date
--------------- --------------- ------------------- --------------------
93271 1 15932 106
137622 2 187 128
83147 3 15932 212
183261 4 2158 217
76389 5 187 305
920013 6 15932 319
Total for Q1
1493703 50328 1287
Average for Q1
248950 8388 214
The FANCY output starts on a new page and looks as follows:
Accounts Report for First Quarter 05/04/2001
Amount Id Acct# Date
-------- --- ------ -----
932.71 1 15932 01/06
1,376.22 2 00187 01/28
831.47 3 15932 02/12
1,832.61 4 02158 02/17
763.89 5 00187 03/05
9,200.13 6 15932 03/19
Total for Q1 14,937.03
Average for Q1 2,489.50
Here is an explanation of the extra options used for the "fancy"
report:
First ON field: In the PLAIN report, BLANK causes ICETOOL to print
the 6-byte ZD values as unedited digits with leading zeros suppressed.
But for this example, we know the digits really represent dollars and
cents. So in the FANCY report, we use the C1 formatting item (one of
thirty-three available masks) to print the values with a comma (,) as
the thousands separator and a period (.) as the decimal point.
In the PLAIN report, TOTAL causes ICETOOL to allow 15 digits for the
values because it does not know how many digits are needed. But
for this example, we know the total amount will not exceed 8 digits.
So in the FANCY report, we use the N08 formatting item to set the
number of digits to 8. This decreases the column width for the field.
Second ON field: In the PLAIN report, NUM causes ICETOOL to allow 15
digits for the record number because it does not know how many
digits are needed. But for this example, we know the number of records
will not exceed 99. So in the FANCY report, we use the N02 formatting
item to set the number of digits to 2. This decreases the column width
for the record number.
Third ON field: In the PLAIN report, TOTAL and AVERAGE cause ICETOOL to
print the total and average for this 3-byte PD field. But
for this example, we know we do not want statistics for the field
because it is an account number. So in the FANCY report, we use the
NOST formatting item to suppress the statistics for this field.
In the PLAIN report, the default mask of A0 causes ICETOOL to suppress
leading zeros for this 3-byte PD field. But for this example,
we know that we want to show leading zeros for the field because it is
an account number. So in the FANCY report, we use the LZ formatting
item to print leading zeros for this field.
Fourth ON field: In the PLAIN report, BLANK causes ICETOOL to print the
4-byte ZD values as unedited digits with leading zeros
suppressed. But for this example, we know the digits represent a date
(month and day). So in the FANCY report, we use the E'99/99'
formatting item to print the values with leading zeros and a slash (⁄)
between the month and day.
In the PLAIN report, TOTAL and AVERAGE cause ICETOOL to print the total
and average for this 4-byte ZD field. But for this example, we
know we do not want the total or average for this field because it is
a date. So in the FANCY report, we use the NOST formatting item to
suppress the statistics for this field.
Note: In some applications, we might want the minimum and maximum for a
date displayed with E'pattern', so we would not specify NOST for
the date field.
INDENT: In the PLAIN report, ICETOOL starts the report in column 2
(after the control character), by default. But for this example, we
want to indent the report a bit. So in the FANCY report, we use the
INDENT(2) operand to indent the report by 2 blanks so it starts in
column 4.
BETWEEN: In the PLAIN report, ICETOOL uses 3 blanks between the columns
of data, by default. But for this example, we want more space
between the columns. So in the FANCY report, we use the BETWEEN(5)
operand to insert 5 blanks between the columns.
STATLEFT: In the PLAIN report, ICETOOL prints the strings for TOTAL
and AVERAGE under the first column of data, by default, and uses
two lines for each statistic to avoid having the string overlay the
value. But for this example, we would like to have the TOTAL and
AVERAGE strings stand out in the report and also have each string on
the same line as its value. So in the FANCY report, we use the
STATLEFT operand to print the TOTAL and AVERAGE strings to the left of
the first column of data.
Here's the link, which also includes a "plain" version of the report to contrast with the fancy one: http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/ice2ca_Example_1110.htm
I located the link by search-engineing for icetool display statleft nost.
I need to get the count for anything having value other than '1' or '2' in position 688.
IS it possible by Easytrieve or SORT in JCL ?
I have done it like this
-[ Character on 653 position should not be spaces AND ( CHeck 688 NE 1 .'AND' 688 NE '2']
INCLUDE COND=
((653,5,CH,NE,C' ',AND,((688,2,CH,NE,C '1 ',AND,688,2,CH,NE,C '2 ')))
can we do it in more efficient or other way ?
You can simplify human understanding by using OMIT instead of INCLUDE, to get rid of your negative conditions.
OPTION COPY,VLSCMP
OMIT COND=(653,5,CH,EQ,C' ',
OR,
688,2,CH,EQ,C '1 ',
OR,
688,2,CH,EQ,C '2 ')
It would be possible to use field-type SS to contract the tests on position 688, but I'd be wary of that if your data is suspect (only use SS when you are sure of what values there may be).
It could be simplified, to my mind, by using SORT symbols to avoid the repetition, and errors that can go with that.
Since you have short records which may get in the way (cause a failure of the step) I have included OPTION VLSCMP. This will pad all fields on INCLUDE/OMIT which are not contained within a record (because the record is short) with binary zeros. Thus, all records with space at 653,5 will be dropped, all records which are not C'1 ' or C'2 ' at 688,2 will be dropped. All short records will be included, as the criteria for dropping will not be met (fields will be binary zeros for the comparison on INCLUDE/OMIT). A short record which does contain space at 653,5 will be omitted. If this is not what you want, that can be dealt with by extending the conditions.
If you need a formatted count that can easily be done, but if you are just investigating, it could easily be the case that the default counts in the sysout give you what you want.
Yes it is possible to count the number of records matching a criteria in either sort or easytrieve
Easytrieve - very easy have a look at the manual - https://www.google.com.au/?gfe_rd=cr&ei=hUBnU-XbCOfC8gep74GIBg#q=easytrieve+manual
Most sort utilities have some sort of reporting funvtions that could be used, for DFSort there is the count (http://pic.dhe.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.icea100/ice1ca40124.htm) option in IceTool.
Even with out the reporting functions it can be done using in a 2 step process
Select the required records and reformat and include a binary field (with the value 1 using the outrec see http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.icea100%2Fice1ca50263.htm
Sort sum the file from the first step
The sort is roughly:
//STEP1 EXEC PGM=SORT
//SYSOUT DD SYSOUT=H
//SORTIN DD DSN=INP1,DISP=SHR,UNIT=3380,VOL=SER=SCR001
//SORTOUT DD DSN=&&OUTPUT,DISP=(,PASS),UNIT=3390,
// SPACE=(CYL,(5,1)),DCB=(LRECL=22)
//SYSIN DD *
OPTION COPY
OMIT COND=(653,5,CH,EQ,C' ',
OR,
688,2,CH,EQ,C '1 ',
OR,
688,2,CH,EQ,C '2 ')
OUTREC BUILD=(1,4,X'0000000001')
//*
//STEP1 EXEC PGM=SORT
//SYSOUT DD SYSOUT=H
//SORTIN DD DSN=&&OUTPUT,DISP=SHR,UNIT=3380,VOL=SER=SCR001
//SORTOUT DD SYSOUT=*
//SYSIN DD *
SORT FIELDS=(5,1,BI)
SUM FIELDS=(6,4,BI)
OUTREC BUILD=(6,4,BI,TO=ZD,LENGTH=9)
There will be areas you can improve
When I am sorting a Variable length file, the job is abending with SB37 repeatedly. Even when I increased the SPACE parameter values, still the job is abending.
Can anyone please help me in knowing what could be the reason for this..?
Below is the JCL I have been trying.
//STEP01 EXEC PGM=SORT
//SORTIN DD DSN=<Input DSN>,DISP=SHR [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
// DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SYSIN DD *
SORT FIELDS=(1,15,CH,A)
SUM FIELDS=NONE
/*
//SYSOUT DD SYSOUT=*
Try the below, the SB37 could be because the sort work DDs don't get enought space when allocated dynamically.
/STEP01 EXEC PGM=SORT
//SORTIN DD DSN=<Input DSN>,DISP=SHR [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
// DCB=(RECFM=V,LRECL=32756,DSORG=PS)
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,(500,10))
//SORTWK04 DD UNIT=SYSDA,SPACE=(CYL,(500,10))
//SYSIN DD *
SORT FIELDS=(1,15,CH,A)
SUM FIELDS=NONE
/*
//SYSOUT DD SYSOUT=*
Since you intend to get rid of trailing blanks and only deal with a maximum data-length of 246, you should do it all in the SORT.
//STEP01 EXEC PGM=SORT
//SORTIN DD DSN=<Input DSN>,DISP=SHR
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(1200,120),RLSE)
//SYSIN DD *
INREC BUILD=(1,4,5,246)
SORT FIELDS=(5,246,CH,A)
SUM FIELDS=NONE
OUTFIL VLTRIM=C' '
//SYSOUT DD SYSOUT=*
Note that I have removed the DCB information from SORTOUT. SORT will take care of that, and you confuse and increase maintenance by including it on SORTOUT (or any DD from OUTFIL) in a SORT step.
In the INREC, a new record is made from the input, which is 250 bytes long (four bytes of RDW and 246 bytes of data). The RDW and data are mentioned separately, so that it is clear to the next person along that you know what you are doing (and perhaps you really want 250 bytes of data anyway?).
In this way, all the data you do not want does not go into the SORT itself, massively reducing your workspace requirements, reducing CPU time, and elapsed time.
Unless your data has an actual key (in position 5 for a length of 11) you are potentially treating non-duplicate data as duplicate. In case you don't have a key, the SORT now sorts on the the data. There is no longer even a remote need to sort on the RDW, as all the RDWs will contain the record-length of 250 (in binary) in the first two bytes due to the BUILD on INREC.
The SUM FIELDS=NONE will now de-duplicate on the 246 bytes of data.
In OUTFIL, VLTRIM=C' ' is used to remove any trailing spaces that happen to be left.
Being concerned that you are unsure of your actual record-lengths, I'd run something like this:
INREC BUILD=(1,4,1,2)
SORT FIELDS=(5,2,BI,A)
OUTREC OVERLAY=(5:5,2,BI,EDIT=(IIIIT),10:18X)
OUTFIL NODETAIL,
REMOVECC,
HEADER2=('RECLENS PRESENT ON FILE'),
SECTIONS=(5,5,
TRAILER3=(5,5)),
TRAILER1=('MIN/MAX ',
MIN=(5,5,ZD,EDIT=(IIIIT)),
' ',
MAX=(5,5,ZD,EDIT=(IIIIT)))
This will produce a simple file, showing you all your record-lengths, and showing the minimum/maximum on the last page.
INREC is used to make records containing the (binary) record-length only. These are then SORTed. OUTREC expands the binary record-length to five printable digits with leading zeros suppressed. OUTFIL reporting features are used: detail lines are suppressed, no print control codes are included, a header is printed at the top of each "page", a control-break is established on the formatted record-length, and the record-length is printed when the break occurs. At the end, the minimum and maximum values are printed.
If you create the input for this with a SORT step consisting of this:
OPTION COPY
OUTFIL VLTRIM=C' '
Then you will get a report of the record-lengths of your file once the trailing blanks are ignored, and can be confident (for that example of data) that what you know of the specification matches the data.
It has been awhile since I've worked on a mainframe, but if memory serves a B37 can occur for two basic reasons:
1) Disk space for an initial allocation is not available
2) Disk space for a secondary allocation is not available
Your JCL statement:
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
// DCB=(RECFM=V,LRECL=32756,DSORG=PS)
Is asking for 1200 initial cylinders. This seems like a lot of space, try something like:
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(12,240),RLSE),
// DCB=(RECFM=V,LRECL=32756,DSORG=PS)
This should get you a primary allocation and then 240 cylinders for each of the secondary allocations, if necessary.
Also, look up the exact description of SB37, it should describe when the problem is due to NO space for primary allocation versus no space for a secondary allocation.
Here is the JCL , I modified. And it is working.
Even, here also the record length (LRECL) of input dataset is 32756.
//STEP01 EXEC PGM=SORT
//SORTIN DD DSN=<Input DSN>,DISP=SHR [the i/p DSN created with SPACE=(CYL,(1200,120),RLSE) ]
//SORTOUT DD DSN=<output DSN>,DISP=(,CATLG,DELETE),
// UNIT=DISK,SPACE=(CYL,(1200,120),RLSE),
// DCB=(RECFM=V,LRECL=500,DSORG=PS)
//SYSIN DD *
SORT FIELDS=(1,15,CH,A)
SUM FIELDS=NONE
/*
//SYSOUT DD SYSOUT=*