The above JCL it only prints the file name in the spool,but we need to get all the files available with LCDT.TEST.FINAL.G* in one of the output file. So how can we achieve this by writing all the availble files with LCDT.TEST.FINAL.G* in the output file.
Your list of datasets is in the spool because that's where you route them by coding...
//SYSPRINT DD SYSOUT=*
Route your SYSPRINT DD to a dataset instead of to the spool by coding...
//SYSPRINT DD DISP=(NEW,CATLG,DELETE),
// DSN=&SYSUID..LCDT.DATASET.LIST,
// SPACE=(TRK,(10,10),RLSE)
...and IDCAMS should provide the appropriate RECFM and LRECL.
Related
1 //ENCIP01 JOB ENCIPJCL
2 //STEP1 EXEC PGM=IDCAMS
3 //INPUT DD DSNAME=&SYSUID..RECORDS,DISP=SHR
5 //OUTDD DD DSN=&SYSUID..ZOWEPS,DISP=SHR
6 //SYSIN DD *
REPRO -
INFILE(INPUT) -
OUTFILE(OUTDD) -
COUNT(20)
/*
When I submitted above JCL. I received error "IEC130I AMSDUMP DD STATEMENT MISSING". But when i added //SYSPRINT DD SYSOUT=A, I didn't get the error. So, do AMSDUMP DD and SYSPRINT DD serve the same purpose?
No.
Sometimes, when IDCAMS encounters an error it attempts to produce a snap dump, which it writes to the AMSDUMP DD. You didn't supply the required SYSPRINT DD, which caused an error, which made IDCAMS want to write a snap dump but you also didn't supply an AMSDUMP DD, hence the message.
On your second run, you supplied a SYSPRINT DD, so IDCAMS did not need to write a snap dump, so it didn't need the AMSDUMP DD.
As title, I wonder how fsutil in windows can create a really large file so fast. Does it really allocate real cluster for that file or it just writes down file's metadata? Consider two commands below:
fsutil file createnew testFile <1Tb>
dd if=/dev/zero of=testFile bs=1024M count=1024
So I create a file with 1Tb size, the problem is with fsutil, the file is nearly created immediately, but with dd, it took over 1 hour to complete.
Therefore, I guess that fsutil only writes metadata to the file header, the real file cluster will expand whenever needed. Do I think right?
from Microsoft documentation
createnew
Creates a file of the specified name and size, with content that consists of zeroes.
from here, you can say that the file must be all zeros ([...]with content that consists of zeroes)
but, if this is truth
[...]the file is nearly created immediately[...]
I think that you are right: probably, fsutil creates the file with bytes marked as free at the time of execution, but doesn't write those bytes
When you use dd like this
dd if=/dev/zero of=testFile bs=1024M count=1024
you are actually writing, "byte by byte", zeros in each byte of the new file
You can do this:
fsutil file createnew testFile_fsutil <1Tb> #(on Windows)
dd if=/dev/zero of=testFile_dd bs=1024M count=1024 #(on Linux)
and then, you can see the contents of testFile_fsutil on any hexeditor, and looking for non-zero bytes, or, more precisely, from Linux you can do ( 1099511627776 bytes = 1 Tebibyte ):
cmp --bytes=1099511627776 testFile_fsutil testFile_dd
or
cmp --bytes=1099511627776 testFile_fsutil /dev/zero
or even using hashes:
dd if=/dev/zero bs=1024M count=1024 | sha1sum
return
fea475204f4ad1348f21fad930a7c721a2858971
so,
dd if=testFile_fsutil bs=1024M count=1024 | sha1sum
must return the same.
Note: to prove your point much more quickly, you can use a much smaller file for test.
I want to copy a mvs file to my PC.. I have tried with the below code.
//JOBNAME JOB NOTIFY=&SYSUID,CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1),
// REGION=0M
//STEP01 EXEC PGM=FTP
//OUTPUT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//INPUT DD *
MVS IP ADDRESS
USER.ID(MVS)
PASSWORD
PUT 'USERID.NEW1.TXT' C:\MYPATH\DATA.TXT
QUIT
/*
spool output shows
'Invalid data set name "c:\mypath\data.txt". Use MVS Dsname conventions.'
But it is working fine with MVS to MVS dataset but not with PC.
Can anyone suggest me what has to be done further.
If you do have an FTP server running on your PC, or a Windows server then it's simple to FTP using batch. Although the syntax you specified using a drive like C:\path\file is not supported. FTP commands and directory structures are similar Unix. When you configured the FTP server you would have specified a root directory (folder) that clients can access. You can't just access the entire Windows file system.
This JCL will work.
//FTPSTEP EXEC PGM=FTP,REGION=0M
//SYSPRINT DD SYSOUT=*
//INPUT DD *
*windows-ip-address*
*windows-username windows-password*
put 'USERID.NEW1.TXT' new1.txt
quit
I try to submit job, and all is good, when i hard coding. But I want to use params.
//REPORTS EXEC PGM=IKJEFT01,**PARM='SDSFINFO FTPSRV01 * hiqual'**
//SYSEXEC DD DSN=rexx.is.here,DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
I write my JCL as Procedure. Is it real to describe parameters in the procedure invoice ? Like this:
//stepxx exec myproc,hiqual=hiqual,owner=*...
There are two kinds of procedure, cataloged procedure and in-stream procedure.
A cataloged procedure is stored in a library member separate from the execution JCL. This separate library is located by the system searching through a list of such libraries defined to it in SYS1.PARMLIB. This list can be overridden with the JCLLIB statement in the execution JCL. Your shop likely has a standard location where cataloged procedures are stored.
In-stream procedures are located in the same library member as your execution JCL. The PROC statement must be between your jobcard and the EXEC statement that executes the named proc. The in-stream procedure must end with a PEND statement.
It is common to use symbolic parameters with procedures, making them more flexible.
You're headed in the right direction...
[jobcard is here]
//MYPROC PROC
//REPORTS EXEC PGM=IKJEFT01,PARM='SDSFINFO FTPSRV01 &OWNER &HIQUAL'
//SYSEXEC DD DSN=[rexx.is.here],DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
// PEND
//*
//MYSTEP EXEC PROC=MYPROC,HIQUAL=ABC,OWNER=XYZ
...where the stuff in square brackets must be supplied by you. This will result in MYPROC being executed as if you had hardcoded...
//REPORTS EXEC PGM=IKJEFT01,PARM='SDSFINFO FTPSRV01 XYZ ABC'
//SYSEXEC DD DSN=[rexx.is.here],DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
Sometimes procs are coded with default values for symbolic parameters...
//MYPROC PROC ENV='PROD'
//REPORTS EXEC PGM=IKJEFT01,PARM='SDSFINFO FTPSRV01 &OWNER &HIQUAL'
//SYSEXEC DD DSN=&ENV..REXX,DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
...and sometimes the default value is documentation...
//MYPROC PROC ENV='SPECIFY_PROD_OR_TEST_OR_QA'
//REPORTS EXEC PGM=IKJEFT01,PARM='SDSFINFO FTPSRV01 &OWNER &HIQUAL'
//SYSEXEC DD DSN=&ENV..REXX,DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
...forcing the execution JCL to provide a value or suffer a JCL error at run time.
Note that with the SET statement you can use symbolic parameters without needing a procedure, cataloged or in-stream. This...
[jobcard is here]
// SET HIQUAL=ABC
// SET OWNER=XYZ
//*
//REPORTS EXEC PGM=IKJEFT01,PARM='SDSFINFO FTPSRV01 &OWNER &HIQUAL'
//SYSEXEC DD DSN=[rexx.is.here],DISP=(SHR,PASS)
//SYSTSPRT DD SYSOUT=A,HOLD=YES
//SYSTSIN DD DUMMY
//*
...will give the same results as the first example, without using a proc.
There are usually shop standards to which you will be expected to adhere. Often mainframe shops have a dedicated group whose function is to run production job streams, scheduling hundreds or thousands of such job streams per day.
I'm writing a script that tests the read and write speeds of my HDD. I've been able to output the read speeds using the hdparm command. I'm using this line to test the write speeds:
dd if=/dev/zero of=/tmp/test.data bs=1k count=128k
This outputs to the window:
131072+0 records in
131072+0 records out
134217728 bytes (134 MB) copied, 1.18678 s, 113 MB/s
I tried using >> and > to output the results to the text file and these didn't work. Does anyone know how I can output my results to a text file?
They're output to stderr, so try using 2> instead of >
dd if=/dev/zero of=/tmp/test.data bs=1k count=128k 2> output.txt
dd's good for sequential writes, but also check into iozone and bonnie. Seeks within a track tend to be far faster than seeks from one track to another, so random I/O can be very different from sequential.