Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Martin, Software Management generates an FTP job if it believes the target z/OSMF host system for the deployment is different than the source z/OSMF host system.  For example, if the target system is in a remote sysplex from the primary server.  If that is not the case for you then it sounds like the definitions for your systems in the z/OSMF Systems task are incorrect.  Check the System entries in the Systems task.  Do you have move than one z/OSMF server?  If not, then you should only have one System entry, and you should choose that one System as the target system for the deployment.

The point is, with the correct Systems task definitions and the correct choice for the deployment target system, Software Management will not generate an FTP job.

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Thanks Kurt,

In our case we actually have en entry for each system in the 8-way sysplex(DET1-8) , altho zOSMF only runs on DET4.  If I understand correctly, we should delete all the other items from our 'systems task'. I guess also to move foward we could just skip the FTP job and carry on with the job to unzip the datasets to disk ?

Kind regards,

Martin

Martin, Software Management generates an FTP job if it believes the target z/OSMF host system for the deployment is different than the source z/OSMF host system.  For example, if the target system is in a remote sysplex from the primary server.  If that is not the case for you then it sounds like the definitions for your systems in the z/OSMF Systems task are incorrect.  Check the System entries in the Systems task.  Do you have move than one z/OSMF server?  If not, then you should only have one System entry, and you should choose that one System as the target system for the deployment.

The point is, with the correct Systems task definitions and the correct choice for the deployment target system, Software Management will not generate an FTP job.

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Martin, if z/OSMF only runs on DET4, then you should choose DET4 as the target system for the deployment.

Please do NOT attempt to run the jobs as is, skipping the FTP job.  Please update the Objective step in the Deployment Checklist to select the correct target system, then continue through the remaining steps.  I believe the configuration step will remember your choices, although you will need to step through the wizard so Software Management can verify the information for the selected target system.  Then it will generate updated deployment jobs.

Thanks Kurt,

In our case we actually have en entry for each system in the 8-way sysplex(DET1-8) , altho zOSMF only runs on DET4.  If I understand correctly, we should delete all the other items from our 'systems task'. I guess also to move foward we could just skip the FTP job and carry on with the job to unzip the datasets to disk ?

Kind regards,

Martin

Martin, Software Management generates an FTP job if it believes the target z/OSMF host system for the deployment is different than the source z/OSMF host system.  For example, if the target system is in a remote sysplex from the primary server.  If that is not the case for you then it sounds like the definitions for your systems in the z/OSMF Systems task are incorrect.  Check the System entries in the Systems task.  Do you have move than one z/OSMF server?  If not, then you should only have one System entry, and you should choose that one System as the target system for the deployment.

The point is, with the correct Systems task definitions and the correct choice for the deployment target system, Software Management will not generate an FTP job.

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Hi Kurt - ah ok I was misunderstanding your reference to 'systems'. We have DET1-8 specified in the 'sysems' app in zOSMF - but we have DET4 (well its nickname DET4_002) specified in the 'objective' panel of the PSI. I wonder if the nickname is the issue - which seems to have been system-generated ? I have uploaded a couple of zOSMF screen shots for reference. 

Regards,

Martin  

Martin, if z/OSMF only runs on DET4, then you should choose DET4 as the target system for the deployment.

Please do NOT attempt to run the jobs as is, skipping the FTP job.  Please update the Objective step in the Deployment Checklist to select the correct target system, then continue through the remaining steps.  I believe the configuration step will remember your choices, although you will need to step through the wizard so Software Management can verify the information for the selected target system.  Then it will generate updated deployment jobs.

Thanks Kurt,

In our case we actually have en entry for each system in the 8-way sysplex(DET1-8) , altho zOSMF only runs on DET4.  If I understand correctly, we should delete all the other items from our 'systems task'. I guess also to move foward we could just skip the FTP job and carry on with the job to unzip the datasets to disk ?

Kind regards,

Martin

Martin, Software Management generates an FTP job if it believes the target z/OSMF host system for the deployment is different than the source z/OSMF host system.  For example, if the target system is in a remote sysplex from the primary server.  If that is not the case for you then it sounds like the definitions for your systems in the z/OSMF Systems task are incorrect.  Check the System entries in the Systems task.  Do you have move than one z/OSMF server?  If not, then you should only have one System entry, and you should choose that one System as the target system for the deployment.

The point is, with the correct Systems task definitions and the correct choice for the deployment target system, Software Management will not generate an FTP job.

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

You uploaded screen shots to where?  I don't see them.  Perhaps you can send to me directly.

In any case, verify the z/OSMF Host URL in the System entry for DET4_002 is what you expect.  Be sure to select the same System for the target of the deployment as the System where the Portable Software Instance (PSWI) resides.

Hi Kurt - ah ok I was misunderstanding your reference to 'systems'. We have DET1-8 specified in the 'sysems' app in zOSMF - but we have DET4 (well its nickname DET4_002) specified in the 'objective' panel of the PSI. I wonder if the nickname is the issue - which seems to have been system-generated ? I have uploaded a couple of zOSMF screen shots for reference. 

Regards,

Martin  

Martin, if z/OSMF only runs on DET4, then you should choose DET4 as the target system for the deployment.

Please do NOT attempt to run the jobs as is, skipping the FTP job.  Please update the Objective step in the Deployment Checklist to select the correct target system, then continue through the remaining steps.  I believe the configuration step will remember your choices, although you will need to step through the wizard so Software Management can verify the information for the selected target system.  Then it will generate updated deployment jobs.

Thanks Kurt,

In our case we actually have en entry for each system in the 8-way sysplex(DET1-8) , altho zOSMF only runs on DET4.  If I understand correctly, we should delete all the other items from our 'systems task'. I guess also to move foward we could just skip the FTP job and carry on with the job to unzip the datasets to disk ?

Kind regards,

Martin

Martin, Software Management generates an FTP job if it believes the target z/OSMF host system for the deployment is different than the source z/OSMF host system.  For example, if the target system is in a remote sysplex from the primary server.  If that is not the case for you then it sounds like the definitions for your systems in the z/OSMF Systems task are incorrect.  Check the System entries in the Systems task.  Do you have move than one z/OSMF server?  If not, then you should only have one System entry, and you should choose that one System as the target system for the deployment.

The point is, with the correct Systems task definitions and the correct choice for the deployment target system, Software Management will not generate an FTP job.

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin

Hi Martin, I already did twice such installation, on my humble perception the concepts are equal do ServerPac dialog but now with z/OSMF, the only issue if I recall regarding this transfer, I need to select all files from my workstation to transfer to  a z/OS dir, because also if recall it was giving some issue when I select only one,  a xml or json file, the process suppose to knows what to transfer, as soon as I have select all, the follow steps of installation was very smoothly.

Joao Bertuzzi

Hi Marna,

Thanks for your response. Yes we have added a PSI and completed customisation for dataset, volume, SSA etc, and  have run the first couple of the deplyoment jobs to create the new master catalog and aliases.  Note that we are deploying on the SAME system where zOSMF is running.

The  problem we are having is with the deployment job:

IZUD05FA

FTP: Copy the portable software instance files from the source system to the target system using FTP.

The active element of this appears to be:

cd '/DEV/u/spx/smpnts/ZOS25'
lcd '/tmp/T3613443'
GET GIMPAF.XML (REPLACE
GET GIMPAF.XML (REPLACE
GET GIMPAF.XSL (REPLACE
GET IZUD00DF.json (REPLACE
GET S0227.CB.ST251869.FFST.V120ESA.SEPWCENU.pax.Z (REPLACE
......

Specifically, we are having authentication issues running the FTP job - which is probably site-specific. 

My question - if this is effectively a copy of the files from  /DEV/u/spx/smpnts/ZOS25 to /tmp/T3613443, could we not just use a unix 'cp' command to circumvent the need for FTP (for now) - and then continue with the following job which performs a GIMUNZIP of the file and creation of the system datasets?  From memory, during the last Serverpac install we completed for V 2.4, there was no requirement to use FTP (which I presume is used in z/OSMF for remote deployment ?). We tend to use Connect Direct rather than FTP for file transfer.

If I've missed anything, please let me know.

Kindest regards,

Martin

Hi Martin,

I'm a little confused.   Can I have a little more information? You said you've acquired the ServerPac into z/OSMF Software Management, and then you've configured the deployment for installation. I'm assuming that you'd done the Add of the Portable Software Instance from the GUI, and that occurred successfully.   Have you done the deployment yet, by running the jobs that were produced from the Deployment checklist?  Or are you in the process of running those jobs, and the deployment you are doing will be to a remote system?  

With the deployment of a portable software instance (ServerPac), z/OSMF Software Management does all the unzipping itself for you, so there is no need for you to use any other supplied job to unzip.  Was it when using a  z/OSMF Software Management-supplied job that you received this error, or was it via another job that you used to use with the CustomPac ServerPac?    (Remember the z/OSMF ServerPac is a different method to install than the CustomPac ServerPac, and you shouldn't try to use any of the jobs you might have run on the CustomPac ServerPac for the z/OSMF ServerPac.)   

We should be able to help you get past this, once we know when this is occurring...  

Thanks - Marna WALLE

Hi There,

We are in the process of using zOSMF Software Management to install zOS 2.5. We have successfully downloaded the order as a portable software instance and have configured a deployment for installation.

The problem we are having is using the FTP method of 'get'ting or extracting the files from the USS directory as pax files for later installation. Our issues revolve around site security; errors such as  '534 Server requires authentication before USER command' when trying to ftp the files from USS, even though the JCL is running in the same LPAR as the USS directory.  It's likely that our issue is site-specific; we are are probably missing some level of authentication here. But my question is slightly wider; has anyone found an alternative mechanism for doing the extract from USS directory to flat files ? Is there an alternative approach that's supported within zOSMF ? With previous (serverpac) installs we used the GIMUNZIP unpacking approach without issue.

Thanks,

Martin

Thanks,

Martin