[Module] Investigate new module - Easy service data transfer to IBM using PDUU

[ledina]

Is there an existing issue for this?

• [X] There are no existing issues.

New module description

CICS customers often use PDUU to transfer large chunks of data sets to IBM to use for problem determination in cases of issues. This would be a great enhancement to the collection as it ensures the data is transferred correctly and it is hassle free for our customers.

User story

As an Ansible user, I am able to easily transfer large data sets to IBM for problem determination without worrying about how to split the data, compression or the transfer

[ddimatos]

@ledina thank you for the module request, we will review it and place our thoughts and notes in this issue.

[ddimatos]

The utility PDUU differentiation over other compression options such as ADRDSSU dump and restore is that this utility is designed as a service aid but can be also used in data transport because not only does it compress data, it breaks into chunks and concurrently delivers it to the destination reducing transport times.

The utility options can be found here, there are a bit over 40 keywords.

This request appears to be a niche ask, so we would want to explore this further with UX to gauge the interest so that if this is to be accepted into the backlog it is appropriately prioritized.

In reviewing this, here are my initial thoughts and concerns.

• Is this a niche module?
• Is this better suited as an playbook example using module zos_mvs_raw and contributing the playbook?
• The JCL samples are not that complicated and align well to zos_mvs_raw but the JCL samples don't really take into account the 40+ keywords
• The PDUU z/OS utility is going to be initiating either an HTTPS or FTP connection to the target, its sort of leverages Ansible without direct integration, meaning , the connections Ansible makes are not reused and in some ways not very Ansible friendly by spawning its own connection which means users who specify configure connection attributes for Ansible will not propagate into this utilities connection.
• How is FTP viewed in today's security centric world, we can force disablement via our controlled keyword usage so that is not a concern but if we do disable it, is it something users would have wanted which put us possible in a disposition with Ansible, RH and IBM?
• If we expose many (not all keywords) the investment seems quite large in terms of functional testing over other modules we develop, which brings me back to my ROI comment above. For example, there are many keywords that can be used to connect to the target system, some of which are using a key ring, keycert, proxy, ciphers, attls, etc, all these will require more system administration and setup for our systems thus equal or greater time to maintain and test the module over time which concerns me for the ongoing cost to maintain what appears to be a niche module.

While it may appear I am not in support of the module, that is not my position, I don't see this an overly complicated module to develop, choosing the keywords and mapping those to a modern interface will be a bit tricky but the concerns I have are more about how valuable this is to the community in relation to ongoing costs to keep this module operational introducing new technical debt we will need to continue to carry.

Example JCL I pulled from docs:

///MYJOB     EXEC PGM=AMAPDUPL
//SYSUDUMP DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//DEBUG    DD  SYSOUT=*
//SYSUT1   DD  DISP=SHR,DSN=HLQ.DSN.DOC
//CEEOPTS  DD  * 
      HEAP(32768,32768,ANYWHERE,FREE,8192,4096),
      ENVAR(GGSK_V3_CIPHER_SPECS=9D3D9C3C,
            GSK_PROTOCOL_TLSV1_2=ON)
//SYSIN    DD  DISP=SHR,DSN=TSOUSER.FTPINFO(ECUREP)
//         DD  *
TARGET_SYS=www.secure.ecurep.ibm.com
TARGET_DSN=wessamp.bigfile
CC_FTP=03
WORK_SIZE=100
DIRECTORY=mvs
CASE=TS012345678
USE_HTTPS=Y
HTTPS_KEYRING=TSOUSER/pduu

My recommendation is that before any further work be done such as a module spec be designed, that an audience be engaged for a usability study to gauge the interest.