While I've been paying more attention to Martin Packer's and my podcast Mainframe, Performance, Topics lately, maybe this is a nice time to talk about something you may want to read and not listen to.
After returning from IBM System Z Technical University in London, and meeting new z/OS folks, I noticed that several people were confused about what a z/OSMF "autostarted" server actually was. You've heard me talk a lot about the biggest migration action in z/OS V2.3, which is that the z/OSMF angel and server will start automatically upon IPL of z/OS. I've also talked a lot about how to position, prepare, and handle that. (Incidentally, a large majority of people at the conference are choosing to start z/OSMF via automation and not by letting the z/OS IPL start it.) Here's the confusing point: a z/OSMF "autostarted" server can be one that is actually started with automation!
Yes. Confusing as it might be, you can have an "autostarted" z/OSMF server that was started with automation, or even manually. Let me explain. The term "autostart" got a little overloaded in z/OS V2.3. It actually is a string of characters that is used in two places for z/OSMF:
- As part of a statement in IZUPRMxx parmlib member, to say whether z/OS should start the z/OSMF angel and server at IPL with AUTOSTART(LOCAL) to do that, or AUTOSTART(CONNECT) to not do that.
- As a parameter on the PROC for IZUSVR1, to say the start up behavior of that z/OSMF server: SERVER='AUTOSTART' or SERVER='STANDALONE'.
Notice the overload in orange above. Looking at our current documentation, I can see how this was little confusing, but we know that and are hoping to clear that up.
Well, usually as with lots of things in z/OSMF, we recommend using the default. For the proc parm, that is absolutely true. For starting the z/OSMF server with your proc (probably called IZUSVR1) either with automation or by the IPL, definitely keep the parm of SERVER='AUTOSTART'.
Now for that IZUPRMxx parmlib statement of AUTOSTART of LOCAL or CONNECT? Do what you wish. As I've mentioned, many customers I've talked to are opting to make it CONNECT, because they will have already gotten z/OSMF set up before they get to z/OS V2.3 and they want to continue with that behavior. Or they need a little more time to finish setting up z/OSMF before IPLing z/OS V2.3. (Also, their automation handles quite nicely shutting down z/OSMF which they want to pair up with automation starting it too.)
Does using IZUPRMxx with CONNECT (and automation) *and* the proc with SERVER='AUTOSTART' give you an "autostarted" server? You bet it does.
Why is having an "autostarted" server good?
Well, for one thing, it allows you to use a cool function called JES2 Email Delivery Service (// NOTIFY EMAILfirstname.lastname@example.org) for job completion notification. When setting up JES2 EDS, you'll see it says you need "z/OSMF server that is configured to participate in an AUTOSTART group. Stand-alone z/OSMF servers do not advertise their presence to JES2.".
This is exactly saying the proc must have a parm of SERVER='AUTOSTART', and you must be in an AUTOSTART_GROUP for this function. Having SERVER='STANDALONE' for your IZUSVR1 parm will not work here.
Stand(alone) and deliver?
I can't resist trying to incorporate one of my favorite songs from the 80's here, but to sum this up, don't use SERVER='STANDALONE' to have an "autostarted" server. Using CONNECT is fine (as long as you start it with something else to give you a z/OSMF server), but STANDALONE won't deliver the email.
Carry on, you dandy highway men.