John, Thank you for your review/option , my friend much appreciated. We are using a CI , Continous Integration process and I am trying design the z/OS to z/OS portion ...
Also John, what the usage of UNIX on z/OS , i.e.; SCP to SCP ...? Scott On Saturday, September 10, 2016, John McKown <john.archie.mck...@gmail.com> wrote: > On Sat, Sep 10, 2016 at 12:15 PM, Scott Ford <idfzos...@gmail.com > <javascript:;>> wrote: > > > ---------- Forwarded message ---------- > > From: Scott Ford <idfzos...@gmail.com <javascript:;>> > > Date: Sat, Sep 10, 2016 at 1:12 PM > > Subject: System Automation Question > > To: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu > <javascript:;>> > > > > > > All: > > > > We have multiple z/OS images running in AWS ( Amazon ) and I have a > > question. We have a set of CI (Continuous Integration) z/OS machines > > and a set of QA z/OS machines. We develop on our sandbox and then have to > > move the loadlibs to the other mentioned systems. The catch is that > > we have to be able to shutdown two STCs that we work with, because the > > libraries need to be refreshed. I was thinking about doing this: > > > > 1. FTP a JOB with a program that can issue 'F ( modify ) commands to the > > STCs', > > 2. When Item #1 is done, send the new loadlibs > > 3. Receive the new loadlibs on th destination machine > > 4. FTP a JOB to Start the STC. > > > > Am i being realistic in this scenario ? or is there an easier way ? > > > > Scott > > > > > Sounds pretty decent to me. I might do it slightly differently. > > 1) FTP the new loadlib to z/OS with a new name (say SOME.PDS.LOADLIB.NEW) > 2) FTP a z/OS job which does two things: > 2a) Issues a F MODIFY,stcname,STOP (or whatever) > 2b) submits a new job. > 3) The job submitted by the the FTP'd job does: > Job 3 step 1 - IDCAMS to delete SOME.PDS.LOADLIB.OLD, > rename SOME.PDS.LOADLIB to > SOME.PDS.LOADLIB.OLD > rename SOME.PDS.LOADLIB.NEW to > SOME.PDS.LOADLIB > Job 3 step 2 - IEFBR14 allocation SOME.PDS.LOADLIB with DISP=OLD to > stop job from running until STC shuts down (enq conflict) > job 3 step 3 - issue S STC to restart the STC - however it is you issue > z/OS commands within a z/OS jobstream > But not with a /*$VS,'S STC' in the job's JCL since > that runs too soon > > This avoids your step #2 of "wait for the STC to terminate" because the job > mentioned in my step 3 won't really start until the STC is down. I think > this would be easier to accomplish since you can't really "wait until STC > is down" in some manner without some outside (non z/OS standard) software. > > > > -- > Unix: Some say the learning curve is steep, but you only have to climb it > once. -- Karl Lehenbauer > Unicode: http://xkcd.com/1726/ > > Maranatha! <>< > John McKown > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu <javascript:;> with the message: > INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
