//* Licensed Materials - Property of IBM
//* 5655-P97 Copyright IBM Corp. 2007
//* Status = HCF7740
//*
//* It is recommended to use IBM JZOS Batch Toolkit for z/OS to invoke
//* the OpenPGP support.
//* The JZOS invocation samples provided by Encryption Facility V1.2
//* consist of three different files:
//* 1. Procedure in PROCLIB
//* 2. Shell script to configure environment variables
//* 3. Batch job that calls the sample procedure in PROCLIB
//*
//* This is a sample procedure used by the sample batch job
//* to launch the Encryption Facility V1.2 OpenPGP support.


EF-OPGP is not working well when data is in ASCII ISO8859-15 or WINDOWS-1252 and output should be EBCDIC IBM-1143 (FINSWE+€uro). 
Shipping data to/from LUW and z/OS must be enhanched.

We usually know what is the logical record length, and is it FB or VB, or should we add BLANC to EOL.

We can't use UTF-8 in many situations.

Data is credit card details and money. Usually in ISO8859-1, ISO8859-15, WINDOWS-1252, UTF-8,...

We should work on z/OS-MVS datasets only.

Not use z/OS-UNIX files to manipulate the data after DECRYPT or before when ENCRYPT is done. 
Actually only z/OS-MVS datasets whatever data manipulations is done.

The EF-OPGP tools should have at least following functions:

1. ZIP/UNZIP inbuilt in EF-OPGP (not rely on PKZIP or JAVA jar-zip/unzip). Should work on z/OS-MVS datasets and z/OS-UNIX files.
2. Option to handle CodePage/encoding like 
	- ASCII: UTF-8, ISO8859-15, WINDOWS-1252,...
	- EBCDIC: IBM-1143 (FINSWE), IBM-1142 (DENNOR), IBM-1149 (ICELAND), IBM-1141 (AUSGER),...
	- text or binary options
3. EOL (EndOfLine): 
	- z/OS-MVS NEL, z/OS-UNIX LF
	- LUW: LINUX/UNIX LF, WINDOWS/DOS CRLF, MAC-OS...
4. Add BLANK to end of record if old legacy COBOL application work on RECFM=FB and not RECFM=VB. 
5. Wrap or NoWrap of records.
6. Strip off CR, that is CRLF ==> LF when ASCII/EBCDIC and even when BINARY is used (ASCII/ASCII).
7. z/OS JZOS (JAVA) use too much CPU and MEMORY and I/O. The EF-OPGP should be written in C/C++ or Assembler. 
   The overhead is unacceptable for small and medium sized files.

Old legacy COBOL applications read XML without using XML-PARSER inbuilt functions, and can be sensitive to record layout. 
Files previously transfered with FTP and WRAP option as text or binary.

New SYSIN parameter syntax in JCL-STEP. EF-OPGP encryp/decrypt options are OK, but should be in z/OS-MVS dataset as alternativ to current:

Example for decrypt, encrypt:

//SYSIN DD *
DECRYPT IN=DD:IN,OUT=DD:OUT ; 
        # IN=/u/myuser/encrypted.data,
	# OUT=//DATA.set,RECFM=FB,LRECL=6160,BLKSIZE=6160 ;
	“DO UNZIP” ; 
	“DO ICONV FR=ISO8859-15 TO=IBM-1143” ; 
	EOL=(IN=CRLF,OUT=NEL) ; FILWITH=BLANC ;
        # legacy application hardcoded RECFM=FB,LRECL=6160,BLKSIZE=6160,...
        # the XML should wrap if >6160
	WRAP ; END
//*
//IN  DD DISP=SHR,DSN=ENCRYPTED.DATA
//OUT DD DISP=(,CATLG),DSN=FB.DATA.SET,RECFM=FB,LRECL=6160,BLKSIZE=6160
//* OUT DD DISP=(,CATLG),DSN=VB.DATA.SET,RECFM=VB,LRECL=32756,BLKSIZE=32760
//* OUT DD DISP=(,CATLG),DSN=FB.DATA.SET,RECFM=FB,LRECL=512,BLKSIZE=0


//SYSIN DD *
ENCRYPT IN=DD:IN,OUT=DD:OUT ; 
        # OUT=/u/myuser/encrypted.data,
	# IN=//DATA.set ;
	“DO ZIP” ; 
	“DO ICONV FR=IBM-1143 TO=ISO8859-15” ; 
	EOL=(IN=NEL,OUT=LF) ; FILWITH=NONE ;
	WRAP # or NoWRAP# ; END
//*
//IN  DD DISP=SHR,DSN=FB.DATA.SET
//OUT DD DISP=(,CATLG),DSN=ENCRYPTED.DATA,RECFM=VB,LRECL=32756,BLKSIZE=0

The encrypted (and zipped) file is normally FTP-binary to the receiver.