IBM z/OS Management Facility (z/OSMF)

 View Only

 Software Management API Deployment

Oscar Curero Sastre's profile image
Oscar Curero Sastre posted 06/16/26 06:43 AM

I’m trying to deploy a Software Instance using the REST API, but it’s not clear whether this is currently possible.

  • There is an endpoint called /zosmf/swmgmt/dep, but it only supports local deployments and SWIs (not PSWIs). How should I send an SWI to a remote z/OSMF instance?
  • There is another endpoint, /zosmf/swmgmt/swi/<system-nickname>/<swi-name>/export, which exports an SWI as a Portable Software Instance (PSWI). However, since the deployment endpoint only accepts an SWI (not a PSWI), I’m unsure how a PSWI through the API is meant to be used.
  • Additionally, it’s confusing that there is an “export” endpoint but no corresponding “import” endpoint.

Thanks in advance,

Kurt Quackenbush's profile image
Kurt Quackenbush

Unfortunately the existing Deploy API was developed for a very specific use case; deploy a z/OS software instance (SWI) locally without modifying data set names and create a new master catalog.  We know there are many more use cases we need to support; deploy portable software instances (PSWIs) as well as SWIs, deploy remotely (across sysplexes) as well as locally (within the same sysplex), support full configuration updates, etc.  In fact we are actively working on expanding the Deployment API to add these capabilities as I write this.  If you have a specific use case in mind, feel free to share it with me so I can be sure we'll have it covered.

Regarding "export" and no corresponding "import"... the Export action in the UI, and the Export API, create a portable software instance (PSWI).  The PSWI Add action in the UI supports obtaining a PSWI from a vendor and defining it to your local z/OSMF server.  The Add PSWI API supports defining the PSWI to your z/OSMF server.  The next step after adding the PSWI would be to Deploy it, so really the Add and Deploy together are perhaps the equivalent of an "import".

Oscar Curero Sastre's profile image
Oscar Curero Sastre

Thanks, Kurt. I guess we are all in the same boat 🙂

Our goal is to automate software update and deployment as much as possible. Right now, we use a homemade tool to manage software update & deployment. In fact, it’s somewhat similar to what z/OSMF provides, but with an ugly ISPF interface instead of a nice web interface. The main difference is that everything still has to be done manually. That’s one of the reasons why we’re looking into z/OSMF, especially because of its REST API.

We support four environments: a Sandbox Sysplex (only available to sysprogs), a Development Sysplex (our main driving and development sysplex), a QA Sysplex (similar to Production), and a Production Sysplex. All in all, we have over 40 LPARs, with a similar number of IMS/DB2/MQ subsystem instances.
I think our use case is quite simple: we need to maintain all software instances across all systems and be able to update them in a rolling fashion. We basically need the same things you can do now through the z/OSMF desktop but using the REST API.

We can discuss things in more detail off-list.