The PROC “GTMSKVD” is the only one that uses an intermediate work file (on disk),
and it does so during a custom process to split the input file into logical segments prior to masking, then to recombine the masked segments at EOJ.
The Dev team would not suggest using this.
For all other file masking PROCs, there is nothing to stop either or both the input and/or output files from being on tape,
however those PROCs – and therefore the default runtime environment – assumes disk as media.
This means therefore that the runtime JCL will require a full DD override statement for both the input (source) and the output (masked) files.
Also, the initial output file definition statement(s) will need suppression.
If the input tape is NOT cataloged, then you will also need to identify it.
The additional parameters will depend on your own environment and I have stated general values below.
//DEL1A.OUTDS DD DUMMY <- Only if using GTMSKVS, otherwise omit
//DEF1.DD03 DD DUMMY
//STEP03.PARMCD DD *
---- as is ----
//STEP04.PARMCD DD *
---- as is ----
//STEP05.FILEI DD DSN=JENMI04.TDM.TAPEIN,
//* LABEL=(2,BLP), <- if not cataloged
//* VOL=SER=123456, <- “ “
//* UNIT=TAPE, <- “ “
//STEP05.FILEO DD DSN=JENMI04.TDM.TAPEMASK,
Concerning processing speed, Support nor the Dev team can provide an answer.
The comparative I/O speed of tapes versus disk will always be slower, even with virtual tapes, however, the ratio will be determined entirely by your own environment.
That said, there is nothing specific with regard to the masking process that will be affected by the medium type.
With regard to article 133776, that publication is still relevant and has not changed in any way that affects this question.
Its thrust is the use of COPYBOOKs and the Windows tool File Definition Manager — formerly known as the parser — to break down COBOL or PL/I record descriptions into Advanced File Layouts, required subsequently by the file masking program.
It does not cover the processing of tapes, or any other specific media.