Hi Terri, You are correct that within the z/OSMF interface, there is no way to edit a produced job for Deployment. It is intended that no editing is necessary, in that if you need to "tweak" the job, we should be providing that capability within the interface itself. The JCL produced should reflect what you want and also can be saved such that it can be reused for similar deployments, to avoid the same future tweaking.
Did you have any specifics on what you wanted to change in z/OSMF, but couldn't? Realize that the data set configuration, volumes, and cataloging capabilities are extremely flexible and should be able to do whatever you want. Even more so than the old ServerPac ISPF dialog. For instance, you can rename any data set you want, put it anywhere you want, and the old dialog had some restrictions on certain data sets. Might there be something in the data set, volume, and catalog capabilities we are missing? I'd like to solve the editing-JCL problem, with a solution for you that allows you to incorporate your intentions right within the GUI much earlier, save that intention, and make it so that you never have to "remember" it again should you do a similar deploy of the product. (I can see how tweaks to the old ServerPac JCL would not be saved in the configuration, and then you would have a need to keep doing those tweaks in the future for every install. That is not the intention here with z/OSMF.) I believe the "work data set prefix" you are referring to is the temporary file system for use as SMPWKDIR on "Define Job Settings". Would you like more information provided for that description to help understand what you are providing? Maybe something like a "Learn more..." to quickly show with more details that we are asking for the beginning qualifier(s) of data set name, that is a temporary zFS (completely handled within the jobs and accurately sized) that will be used as the SMPWKDIR? This should be an easy thing to do, if it would help. On that same checklist location for "Define Job Settings", the jobcard can be supplied, and also the place where you want all the generated jobs saved (like we had in SCPPBENU). Of course, you could run the jobs from that saved data set from ISPF, but again, the intention is that they are run through z/OSMF so the interface can keep track of what you've done and how far you've gone. You could re-submit the same job again, from z/OSMF, should you wish. Or even indicate that the job is complete as your ran it from ISPF and you want to continue on. If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance. This will allow you to model z/OS V2.5 from that prior z/OS release and not have to re-specify hundreds of data sets and volume placement. This is very very similar to the old ISPF ServerPac dialog "save and merge configuration". You will still have some unique data sets to deal with, but it will be a lot fewer than the entire z/OS ServerPac. Of course, I'd do that with CICS, Db2, and IMS also. -Marna WALLE z/OS System Install and Upgrade IBM Poughkeepsie ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
