ansible-collections / ibm_zos_core

Red Hat Ansible Certified Content for IBM Z
77 stars 44 forks source link

[Bug] [zos_copy] Character "£" not supported in dataset name #416

Open fernandofloresg opened 2 years ago

fernandofloresg commented 2 years ago
SUMMARY

A UK user reported than using "£" in a dataset name as a src to zos_copy fails with error :

fatal: [winmvsb0]: FAILED! => {"changed": false, "msg": "Parameter verification failed", "rc": null, "stderr": "Invalid argument \"CBSA.A.JENKINS.JCL.INSTALL(DFH£SIP1)\" for type \"data_set\" or \"path\".", "stderr_lines": ["Invalid argument \"CBSA.A.JENKINS.JCL.INSTALL(DFH£SIP1)\" for type \"data_set\" or \"path\"."], "stdout": null, "stdout_lines": null}

This is because in the arg parser we do not support this but only the special characters "$", "@" "#" and "-". Problem here is that UK codeset for "$" is the same as the "£".

This raises the question, is this only happening with the pound ?

COMPONENT NAME

zos_copy

ANSIBLE VERSION
Ansible version output:
SPECIFY ANSIBLE COLLECTION VERSION
SPECIFY THE Z OPEN AUTOMATION UTILITIES VERSION
ENVIRONMENT
STEPS TO REPRODUCE
Reproduction playbook/yaml

- name: Copy a local file to a sequential data set
  zos_copy:
    src: CBSA.A.JENKINS.JCL.INSTALL(DFH£SIP1)
    dest: SAMPLE.SEQ.DATA.SET
EXPECTED RESULTS

Dataset is successfully copied.

ACTUAL RESULTS
Playbook output:

fatal: [winmvsb0]: FAILED! => {"changed": false, "msg": "Parameter verification failed", "rc": null, "stderr": "Invalid argument \"CBSA.A.JENKINS.JCL.INSTALL(DFH£SIP1)\" for type \"data_set\" or \"path\".", "stderr_lines": ["Invalid argument \"CBSA.A.JENKINS.JCL.INSTALL(DFH£SIP1)\" for type \"data_set\" or \"path\"."], "stdout": null, "stdout_lines": null}
CONFIGURATION

Ansible.cfg

'ansible-config dump --only-changed' output:

Inventory

Inventory content:

Vars

'group_vars' or 'host_vars' content:
SCREENSHOTS
ddimatos commented 1 year ago

Possibly related ZOAU tracker xxxx-8976

ddimatos commented 1 year ago

I think this will need some additional thought and story points.

As our better arg parser encounters something like a £ what do we do? Do we just pass it through without an evaluation, that would negate our fail fast design to catch user error early and handle it.

Assuming we want to keep our design, we will need to do some inspection.

Here is an idea in pseudo logic: 0) Choose a locale we standardize on , lets call this STDCP (cp1047) 1) From the better argparser check the managed node locale and compare it to STDCP 2) If the system local does not match STDCP then: 3) encode the input to be 1047 and let it run through our regular expressions , eg £ would become $ and pass, then decode again and pass it to ZOAU.

hx='\xc3'.decode('cp238')
val=bytes(hx).decode('cp238')
richp405 commented 1 year ago

We have validated a code change that will properly escape the characters, but need to wait for the matching component in zoau to handle this change. Ticket filed is Jira/Narare/10103. During discussion of the "symbols' issues (642/724), a similar issue related to the £ (here) was already being worked on.

ddimatos commented 1 year ago

This relies on ZOAU 1.3 , IBM z/OS core collection will support 1.3 in Q1 2024