After #7, the code is populating the remote userid field, which, if not cleared, leads to a "Conflict" error if a NETRC is in use. It's not obvious if this variable is being used for a default HLQ on a remote z/OS system. Research is needed to see why this field is being populated on the panel and how is it used when a NETRC is specified.

I entered **.LOAD for the From data set. Unfortunately it triggered a catalog search for every data set that matched, regardless of HLQ. I had to specify prefix.**.LOAD to narrow it down.

This may be a good time to ensure that From respects PREFIX for all uses.

Also check for % usage being ignored.

If the remote system SMS classes does not match the target system, it is necessary to specify MGMTCLAS NONE and STORCLAS NONE. However, even with those settings, DSS will not restore if the ACS routines reject the data set names. The workaround is to specify BYPASSACS(mask) to process all data sets (** for all).

A minor issue is that if a lower-case p is used in directory entries to indicate a PDSE for a new remote data set, it is not converted to upper case, and it is used in the generated DD SPACE keyword as-is.

The submitted FTP local job JCLs off due to the //NETRC DD pointing to a data set name of SYLDSNAME. This is caused because SYSDSNAME was caught in the variable refactor and was inadvertently changed to SYLDSNAME and the default Rexx variable value is substituted rather than the actual NETRC name.

Implement the following behavioral changes:

• If aliases are selected and base member is selected, use COPYGRP (any PDSE involved) or COPYGROUP (no PDSEs involved)
• If aliases are found for the selected member but not selected, prompt for copying of aliases
• If aliases are selected but base member is not selected, prompt for verification that the alias is to be copied without the base member
• Prompt for GENS= (GET & PUT)