//STEP001 EXEC PGM=SORT
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=XXX.T.KR0A9N99.XXXIFRDK.PARM,
// DISP=SHR
//SORTOUT DD DSN=XXX.T.KR0A9N99.XXXIFRDK.PAR1,
// DISP=SHR
//SYSIN DD DSN=XXX.T.KR0A9N99.TWT.PARM(XXX#DATE)
// DISP=SHR
Inside this file XXX.T.KR0A9N99.XXXIFRDK.PARM
----+----1----+----2----+----3----+----4----+----5----+----6----+
***************************** Top of Data ***********************
open xxxF01Q#SDTPRD.fbabank.com
CD SDT_WINDSS/Download/
LSITE trailing_blanks=yes
SPUT //'xxx.T.KR0A9N99.xxxDHOLA.CSVF.SR0096(0)' HOLD.20190524.CSV
QUIT
inside parm XXX.T.KR0A9N99.TWT.PARM(XXX#DATE)
OPTION COPY
INREC IFTHEN=(WHEN=(1,4,CH,EQ,C'SPUT'),OVERLAY=(54:&DATE1))
the job went successful but not updated the current date for this file HOLD.20190524.CSV.. could you please help me to get correct date?
This may be a SYSIN RECFM issue. It sounds as if your SORTOUT file equals your SORTIN file. If so, that means the condition is never true. One explanation could be that, because of the RECFM, the argument SPUT might not be in position 1 the way it appears to be in the ispf screen shot. For example, if the RECFM of the SYSIN file happens to be FBA then, although the value appears to be in column 1, it would really be in column 2. If the input file is VBA or VB then the value would be offset by either 2 or 4.
It would be interesting to know the RECFM of the SORTIN file.
Related
I have a input PS file like
aaa1111zzzz
bbb2222bbbb
ccc3333bbbb
ddd3333cccc
eee7777yyyy
I want to know the line number in this input PS file where the word '3333' is present.. output should be something like
3
4
in this scenario
I am looking for a JCL that can do this, I have searched in net, but no luck.
You seem to mis-understand what JCL is.
JCL is not executable, it does not look at data, it does not manipulate data.
JCL is like a memo from you to the operating system requesting the OS to run some programs.
When the JCL is read the OS reads it and sets up whatever it requires to do the tasks defined in the JCL and then DISCARDS the JCL i.e. writes it to the output spool.
The OS then runs the program(s) in accordance with the information it has extracted.
Now, for your task, cschneid has pointed you to one solution. You will have to manipulate the report from superc to get it as you posted.
Or, you can use your sort product as follows:
When reading the records in you ask sort to assign a sequence number to each record. When writing the records out you ask sort to only refer to the records with the value you are looking for and only write out the sequence number for those records.
With respect to NicC's answer, I've tried using SORT to attain the expected result.
//SORT EXEC PGM=SYNCSORT
//SORTIN DD *
aaa1111zzzz
bbb2222bbbb
ccc3333bbbb
ddd3333cccc
eee7777yyyy
//SORTOUT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
INREC FIELDS=(1:SEQNUM,3,ZD,4:1,11)
SORT FIELDS=COPY
OUTFIL FNAMES=SORTOUT,INCLUDE=(7,4,ZD,EQ,3333),OUTREC=(1:1,3)
/*
It's a different approach than most people take, but don't forget you can actually use z/OS UNIX Services utilities for tasks like this. In your example, "grep -nr pattern file" would find all the lines matching "pattern" and show you the line numbers.
Of course, the trick is getting the "file" part right when your data is in a conventional dataset...sometimes, easiest is something like this:
cat "//'my.dataset.name'" | grep -nr pattern
To run this in JCL, you'd put the above command as input into BPXBATCH using JCL like this:
//jobname JOB ...
// EXEC PGM=BPXBATCH
//STDERR DD PATH='/tmp/mystd.err',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU
//STDOUT DD PATH='/tmp/mystd.out',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),PATHMODE=SIRWXU
//STDPARM DD *
SH cat "//'my.dataset.name'" | grep -nr pattern
If you want the STDOUT/STDERR somewhere else (say, SYSOUT), just change the STDERR/STDOUT DD statements.
Using UNIX Services this way is a very cool thing if you're already familiar with UNIX/Linux shell commands...read the details here: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxa400/toc.htm
I have the below job which runs on a zlinux server and it creates a trigger in a destination zOS system.
//WPLP0500 JOB (GBCRM,GBAWPL),'PLIW ESI TRIGGER',
// CLASS=A,REGION=32M,MSGCLASS=E
//STEP EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
But it is giving the below errors
STMT NO. MESSAGE
1 IEFC620I UNIDENTIFIABLE CHARACTER ON THE JOB STATEMENT
2 IEFC605I UNIDENTIFIED OPERATION FIELD
3 IEFC620I UNIDENTIFIABLE CHARACTER ON THE EXEC STATEMENT
Can anyone please guide me on this.
Now that your error messages are formatted, you can see that for 1 and three it is complaining about something "invisible".
Invisible things in JCL are non-printable characters. If you are able to look at that job output in hex, you will see exactly what the unprintable characters are.
For 2, it doesn't show you the character, but the problem is the same (likely).
My bet is that they are "ASCII-spaces", hex-code 20. Making the bet because otherwise you'd have seen them on the z/Linux system.
You haven't listed the content of file two of the spool for your JOB, from which it may be possible to tell more, but your problem is "non-display" characters on your JCL cards. Probably ASCII-spaces. Perhaps not.
It would appear that you have omitted // on all lines (if the space before the jobname (WPLP0500) is coded would also cause issues). try :-
//WPLP0500 JOB (GBCRM,GBAWPL),'TRIGGER',
// CLASS=A,REGION=32M,MSGCLASS=E
//STEP EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
Note that the last line is superfluous as program IEFBR14 does not produce any output. In fact the program effectively just returns i.e. it Branches to the value held in Register 14, which, at program start, contains the return address.
I'm trying to send an email using BATCHTMP using the contents of a dataset.
But what happens is it just displays the first row even incomplete.
Here is my step that executes IEBGENER.
Please note that the multiple inputs have different LRECL but it seems to accept LRECL 80 for the output dataset fine.
//STEP202 EXEC BATCHTMP,COND=(0,NE,STEP020)
//SYSPRINT DD SYSOUT=*
//SYSABOUT DD SYSOUT=D
//SYSUDUMP DD SYSOUT=D
//SYSOUT DD SYSOUT=*
//*
//MAILINPT DD DSN=SUMFILE,
// DISP=SHR
//*
//SYSTSIN DD *
OUTLOOK2 MAHEMAIL#MAHEMAIL.com -
MAINFRAMEDAYCOUNT GAMING SIR
//*
Try viewing your dataset and use HEX ON on the command line.
using IEBGENER and SORT sometimes causes a HEX value of 00 inside your dataset. This is unacceptable by outlook but is ok in MAINFRAME. It reads it as a terminating value or EOF/EOL. This is why you can view the dataset but the outlook cannot read it as a whole.
You can try and sort the file again before sending by removing the HEX '00' values and replace it with HEX '40' (a space).
I have n number of files that have a particular count.
I now want to add all those count values into another file.
it will be something like
//SORTIN DD file1
// DD file2
.
DD filen
//SORTOUT DD output file
need a way to do the same using only JCL.
Regarding your "using only JCL" requirement, please read this.
If your files are GDGs then in your SORTIN just specify the GDG base name without specifying a generation number. The system will automatically concatenate your files for you.
I'm trying to replace a small amount of text on a specific line of a large log file (totaling ~40 mil lines):
sed -i '20000000s/.\{5\}$/zzzzz/' log_file
The purpose of this is to "mark" a line with an expected unique string, for later testing.
The above command works fine, but in-place editing of sed (and perl) creates a temp file, which is costly.
Is there a way to replace a fixed number of characters (i.e. 5 chars with 5 other chars) in a file without having to create a temp file, or a very large buffer, which would wind up becoming a temp file itself.
You could use dd to replace some bytes in place:
dd if=/dev/zero of=path/to/file bs=1 count=10 conv=notrunc skip=1000
would write 10 zeros (0x00) after the 1000s byte. You can put whatever you want to replace inside a file and write the path to it in the if parameter. Then you had to insert the size of the replacement file into the count parameter, so the whole file gets read.
the conv=notrunc parameter tells dd to leave the end of the file untruncated.
This should work well for any 1-byte file encoding.
ex is a scriptable file editor, so it will work in-place:
ex log_file << 'END_OF_COMMANDS'
20000000s/.\{5\}$/zzzzz/
w
q
END_OF_COMMANDS