Re: Really dumb IPL question

[J R]

> Have you ever actually tried to use QEDIT and STOP/MODIFY on a TSO
> session? 

Yes!  

> It has indeed worked the same way for 4 decades, but that
> doesn't mean your application program can accept commands using it.

It worked just fine for me back in the '70s.  


 
> Date: Tue, 5 Oct 2010 14:42:16 -0400
> From: t...@harminc.net
> Subject: Re: Really dumb IPL question
> To: IBM-MAIN@bama.ua.edu
> 
> On 4 October 2010 09:08, Shmuel Metz (Seymour J.)
>  wrote:
> 
> > Tell them to read the documentation for QEDIT, because it has worked
> > equally well for, e.g., batch jobs, TSO sessions, for 4 decades.
> 
> Have you ever actually tried to use QEDIT and STOP/MODIFY on a TSO
> session? It has indeed worked the same way for 4 decades, but that
> doesn't mean your application program can accept commands using it.
> 
> Tony H.
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In , on
10/05/2010
   at 02:42 PM, Tony Harminc  said:

>Have you ever actually tried to use QEDIT and STOP/MODIFY on a TSO
>session?

Il va sans dire.

>It has indeed worked the same way for 4 decades, but that doesn't
>mean your application program can accept commands using it.

Are you a betting man?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Tony Harminc]

On 4 October 2010 09:08, Shmuel Metz (Seymour J.)
 wrote:

> Tell them to read the documentation for QEDIT, because it has worked
> equally well for, e.g., batch jobs, TSO sessions, for 4 decades.

Have you ever actually tried to use QEDIT and STOP/MODIFY on a TSO
session? It has indeed worked the same way for 4 decades, but that
doesn't mean your application program can accept commands using it.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Thanks. I have incorporated this information into the draft manual (along
with saying what the prerequisites are and so forth and "choose what works
for you."

Thanks everyone for your help.

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, October 05, 2010 3:33 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

In <00f901cb6322$4df01a50$e9d04e...@org>, on 10/03/2010
   at 10:42 AM, Charles Mills  said:

>Thanks. Your advice goes to the core of what I was asking. Can you
>please suggest the other five options, in what you might guess might
>be their order of desirability?

Order of desirability would be installation dependent, but a few
possibilities off the top of my head are

   COMMNDxx
   JES initialization
   Automation
   TCP/IP
   Startup of automatic subsystem, e.g., CA90S.
   Job submitted by other automatic task
   Commands submitted by automatic system Rexx procedure
   MPF
   Unix startup scripts
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Bill Fairchild]

In , on 09/28/2010
   at 10:26 PM, "Robert A. Rosenberg"  said:

>It sounds like those Ops/Automation 
>types are brain dead and do not understand what they are doing.

It sounds as if you don't know the same Ops/Automation developers that I know.

Bill Fairchild
Rocket Software
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In , on 10/04/2010
   at 07:06 AM, Tom Marchant  said:

>It does unless you have an ESTAE exit and take appropriate action.

CANCEL precludes an orderly shutdown *EVEN IF* you have an ESTAE.
There are significant restrictions on what you can do for recovery
after a CANCEL.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In <00f901cb6322$4df01a50$e9d04e...@org>, on 10/03/2010
   at 10:42 AM, Charles Mills  said:

>Thanks. Your advice goes to the core of what I was asking. Can you
>please suggest the other five options, in what you might guess might
>be their order of desirability?

Order of desirability would be installation dependent, but a few
possibilities off the top of my head are

   COMMNDxx
   JES initialization
   Automation
   TCP/IP
   Startup of automatic subsystem, e.g., CA90S.
   Job submitted by other automatic task
   Commands submitted by automatic system Rexx procedure
   MPF
   Unix startup scripts
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Rick Fochtman]

--


Judging from some of the posts here I think that those of you in the
user sysprog community think we software vendors stay up at night
trying to think of ways to annoy you. 
   



It doesn't matter whether it's incompetence, malice or orders from
above. If my boss asks me to evaluate a products, I'll tell him all of
the problems I spot regardless of the reasons for them.

 


The problem is that many of us came up through a development career
path, not a sysprog career path.
   



Part of development is requirements analysis. You need to talk to your
customers and potential customers.

 


While I'm on a rant here you in the sysprog community should keep in
mind that you are not the entire audience for our products.
   



And you need to keep in mind that in some shops we get asked before
procuring, and in some shops we get listened to when we suggest
dropping a product at renewal time.

If my boss tells me that we have budgetary problems and need to find
some software to drop, the first ones that I will suggest are the ones
that are causing problems.

So by all means put in additional information, but not at the expense
of the information that we need, and not in a misleading fashion.
 


---
Charles, we don't paint all vendors with the same brush. There are a few 
vendors that are very obscure, misleading and annoying. There are a few 
that are remarkable for their openness. Most fall somewhere in the 
middle Some of this range is caused by the programming "style" of the 
vendor, some through incompetence, malice or orders from above. And some 
from paranoia about software theft. And some is caused by a sincere 
desire to meet customer needs with the least pain. It all depends on 
people and we're all different, no matter what the development path 
might have been.


Most sysprogs, in most shops, have a fairly good "feel" for what the 
shop needs and try to be responsive, whether it's a custom-built 
subroutine to fetch obscure data from the system, a customized exit, or 
provide a service that isn't available in the particular HLL in use. 
Selection of OEM software is part of that function, so we have to 
evaluate the assets and liabilities of a number of products, and that 
might also include start-up and shutdown requirements, whether it's at 
system start-up and shutdown time or ISPF session start-up and shutdown. 
Timing and order dependancies have to be made clear, and all too many 
vendors don't provide that information, leading to a certain amount of 
annoyance.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In <005d01cb5f72$0646ba00$12d42e...@org>, on 09/28/2010
   at 06:02 PM, Charles Mills  said:

>Judging from some of the posts here I think that those of you in the
>user sysprog community think we software vendors stay up at night
>trying to think of ways to annoy you. 

It doesn't matter whether it's incompetence, malice or orders from
above. If my boss asks me to evaluate a products, I'll tell him all of
the problems I spot regardless of the reasons for them.

>The problem is that many of us came up through a development career
>path, not a sysprog career path.

Part of development is requirements analysis. You need to talk to your
customers and potential customers.

>While I'm on a rant here you in the sysprog community should keep in
>mind that you are not the entire audience for our products.

And you need to keep in mind that in some shops we get asked before
procuring, and in some shops we get listened to when we suggest
dropping a product at renewal time.

If my boss tells me that we have budgetary problems and need to find
some software to drop, the first ones that I will suggest are the ones
that are causing problems.

So by all means put in additional information, but not at the expense
of the information that we need, and not in a misleading fashion.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In
,
on 09/29/2010
   at 05:15 PM, Peter Nuttall  said:

>I guess, in their defence they never intended/suggested for the IP 
>listeners to work as Started Tasks, 

Tell them to read the documentation for QEDIT, because it has worked
equally well for, e.g., batch jobs, TSO sessions, for 4 decades.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In , on 09/28/2010
   at 10:26 PM, "Robert A. Rosenberg"  said:

>Shutting down a Started Task can be done in the way other STCs are 
>controlled.

Not if it is programmed ineptly.

>You can issue a WTOR which allows the request to shut 
>down to be sent

Please don't; that approach is so 1960's.

>or you can just use the Modify (F) or STOP (P) command.

That's controlled by the author, not by the automation package.

>It sounds like those Ops/Automation 
>types are brain dead and do not understand what they are doing.

It sounds like you need to read Peter's message again; the offending
code is not in the automation software and not under the control of
those using it. AUTOOPS can issue STOP commands until the cows come
home, but it can't force the application to act on the STOP CIB.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Tom Marchant]

On Sun, 3 Oct 2010 10:35:03 -0500, Shmuel Metz (Seymour J.) wrote:

>CANCEL precludes an orderly shutdown.

It does unless you have an ESTAE exit and take appropriate action.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Ted MacNEIL]

>Also, any system auto-operations product start-up script

That's why (imo) it's better to just list requirements.

Also, if you start listing methods, what happens if you haven't tested the 
product, or the product changes?

Tend to your own knitting, and let the customer wear it.

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Binyamin Dissen
> Sent: Sunday, October 03, 2010 1:46 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Really dumb IPL question
> 
> On Sun, 3 Oct 2010 10:42:09 -0700 Charles Mills 
> wrote:
> 
> :>> The list should probably include at least half a dozen options,
> :>> including COMMNDxx
> :>
> :>Thanks. Your advice goes to the core of what I was asking. Can you
> please
> :>suggest the other five options, in what you might guess might be
> their order
> :>of desirability?
> 
> Here are a few:
> 
> Manual start
> 
> /etc/rc
> 
> $VS in Jes init deck.
> 
> MPFLST


Also, any system auto-operations product start-up script

If a CA customer, there's CAS9 and if -CA-ENF, it does this also.

If the site does TSSO, likewise

If your system needs and initializes a subsystem, it could be done
there.

TCPIP AUTOLOG



> 
> :>-Original Message-
> :>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf
> :>Of Shmuel Metz (Seymour J.)
> :>Sent: Sunday, October 03, 2010 7:52 AM
> :>To: IBM-MAIN@bama.ua.edu
> :>Subject: Re: Really dumb IPL question
> 
> :>In <013801cb5dc8$703d9ec0$50b8dc...@org>, on 09/26/2010
> :>   at 03:16 PM, Charles Mills  said:
> 
> :>>I'm writing documentation for a product that a customer would
> :>>normally run automatically as an STC at every IPL. What do I say in
> :>>the manual about where to place the START command?
> 
> :>"The foo address space must be started after bar. Because different
> :>installations are set up differently, there is no single best way to
> :>cause an automatic START. Some of the ways that may be available
> are:"
> 
> :>The list should probably include at least half a dozen options,
> :>including COMMNDxx. You should also discuss shutdown[1] and restart.
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Binyamin Dissen]

On Sun, 3 Oct 2010 10:42:09 -0700 Charles Mills  wrote:

:>> The list should probably include at least half a dozen options,
:>> including COMMNDxx
:>
:>Thanks. Your advice goes to the core of what I was asking. Can you please
:>suggest the other five options, in what you might guess might be their order
:>of desirability?

Here are a few:

Manual start

/etc/rc

$VS in Jes init deck.

MPFLST

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
:>Of Shmuel Metz (Seymour J.)
:>Sent: Sunday, October 03, 2010 7:52 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: Really dumb IPL question

:>In <013801cb5dc8$703d9ec0$50b8dc...@org>, on 09/26/2010
:>   at 03:16 PM, Charles Mills  said:

:>>I'm writing documentation for a product that a customer would
:>>normally run automatically as an STC at every IPL. What do I say in
:>>the manual about where to place the START command? 

:>"The foo address space must be started after bar. Because different
:>installations are set up differently, there is no single best way to
:>cause an automatic START. Some of the ways that may be available are:"

:>The list should probably include at least half a dozen options,
:>including COMMNDxx. You should also discuss shutdown[1] and restart.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

> The list should probably include at least half a dozen options,
> including COMMNDxx

Thanks. Your advice goes to the core of what I was asking. Can you please
suggest the other five options, in what you might guess might be their order
of desirability?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Shmuel Metz (Seymour J.)
Sent: Sunday, October 03, 2010 7:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

In <013801cb5dc8$703d9ec0$50b8dc...@org>, on 09/26/2010
   at 03:16 PM, Charles Mills  said:

>I'm writing documentation for a product that a customer would
>normally run automatically as an STC at every IPL. What do I say in
>the manual about where to place the START command? 

"The foo address space must be started after bar. Because different
installations are set up differently, there is no single best way to
cause an automatic START. Some of the ways that may be available are:"

The list should probably include at least half a dozen options,
including COMMNDxx. You should also discuss shutdown[1] and restart.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In <013801cb5dc8$703d9ec0$50b8dc...@org>, on 09/26/2010
   at 03:16 PM, Charles Mills  said:

>I'm writing documentation for a product that a customer would
>normally run automatically as an STC at every IPL. What do I say in
>the manual about where to place the START command? 

"The foo address space must be started after bar. Because different
installations are set up differently, there is no single best way to
cause an automatic START. Some of the ways that may be available are:"

The list should probably include at least half a dozen options,
including COMMNDxx. You should also discuss shutdown[1] and restart.

"If foo terminates abnormally, do baz before issuing a START foo
command to restart it."

[1] Whatever other mechanism you support, you should accept and
respond to a STOP command.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In , on 09/27/2010
   at 02:42 PM, "Robert A. Rosenberg"  said:

>That sounds useful but unless my memory is inaccurate an STC must be 
>a single step

There was a time when the PPT was not honored if the proc wasn't
single step, but most started tasks these days don't require PPT
entries, so even if the restriction is still there it's probably not
an issue.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In
<397724969-1285617146-cardhu_decombobulator_blackberry.rim.net-16760008...@bda497.bisx.prod.on.blackberry>,
on 09/27/2010
   at 07:53 PM, Ted MacNEIL  said:

>PS: it's a started task (or Started Task). STC stands for Started
>Task Control -- the sub-system.

Hypocrite.

>Calling it an STC is inaccurate,

No; the job type is STC. 

>and akin to calling a job a JCL, or an EXEC a REXX.

No; it's akin to calling a session a TSU.

 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Shmuel Metz (Seymour J.)]

In , on 09/30/2010
   at 04:13 PM, "Robert A. Rosenberg"  said:

>The assumption of my comment was the program was written to use STOP
> or MODIFY to signal the task to terminate.

That was a bizarre assumption to make, given the text of
.

> was to the effect that it was against the Ops/Automation types
> rules/procedures to use CANCEL 

Yes, so far, and you called that rule brain dead.

>(or STOP/MODIFY

Au contraire, it was the fact that the code *didn't* support
STOP/MODIFY that Ops/Automatione was complaining about.

>which use the same QEDIT interface)

STOP and MODIFY use the same interface, but it is not the same as used
by CANCEL.

>Note that I may be wrong about 
>the ability to intercept the CANCEL and suppress it

You are.

>since you are going to do an orderly shutdown by treating as a 
>STOP.

You can't treat CANCEL as STOP unless you have a time machine. CANCEL
precludes an orderly shutdown.

>The quote was:
>>Setting this up as a started task and then explaining to 
>>Ops/Automation that the only way to stop it was to Cancel the 
>>Started task was not fun (against their operational procedures) 

And there's nothing there to the effect that it was against the rules
to use STOP/MODIFY, only that it was against the rules to use CANCEL.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Edward Jaffe]

 On 10/1/2010 5:03 AM, Chase, John wrote:

Meanwhile, NetView still hangs a WTOR on the console :-(


Actually, that's an optional behavior in Netview. Of course, the default--chosen 
for maximum upward compatibility--is exactly what you don't want.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chris Mason]

John

You may be right about NetView Access - which has only the most tenuous 
connection with the "pukka" NetView by the way - as close as Raleigh, NC, 
and Rome, Italy - just check the "Help Us Help You!" sections in appropriate 
manuals.

However, I hope you checked the manuals for the latest release of the 
product over whether there is only a REPLY (WTOR) interface or also a 
MODIFY/STOP (EXTRACT/QEDIT) interface for operators before casting this 
aspersion.

Chris Mason

On Fri, 1 Oct 2010 07:50:42 -0500, Chase, John  
wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Vernooij, CP - SPLXM
>>
>> "Chase, John" wrote in message
> ...
>Also Netview Access:
>
>*06 EMS0990A ACCESS  READY FOR COMMANDS.
>
>   -jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chris Mason]

John

> Meanwhile, NetView still hangs a WTOR on the console.

I went back as far as I could in the NetView bookshelves[1] in order to 
confirm what I seemed to remember from the days when I used to run a 
NetView on all my systems that there was no outstanding "reply" messing up 
the console. I found the following from NetView V2R3 (1994):

NetView® Administration Reference Version 2 Release 3, SC31-6128-01



2.1.54 MVSPARM

MVSPARM [MSGIFAC={SYSTEM|USESSI|CMDONLY}]
[,DEFAUTH={MASTER|ALL|SYS|I/O|CONS|INFO|
   CONS&I/O|CONS&SYS|I/O&SYS}]
[,CMDWTOR={YES|NO}]
[,MIGRATE={YES|NO}]

...

CMDWTOR={YES|NO}
Specifies whether the DSI802A WTOR is issued. CMDWTOR is valid only if you 
have the NetView program for MVS/ESA installed on an MVS/ESA system.

YES Issues message DSI802A. This is the default in DSIDMN.
NO Suppresses message DSI802A.



As I used to try to drum into my students: "Defaults always work but they 
don't tend to offer the best performance."

I suggest your installation catches up with at least 15 years of NetView 
development and examines its defaults!

And please refer to your documents before obliging me to spend up to half an 
hour checking mine!

Just to offer a useful response to this slur on NetView capability[2], this is 
some more information I dug up:

NetView® Operation Version 2 Release 3, SC31-6127-01



1.9.2.1 MVS

For MVS, you can issue CLOSE as a NetView subsystem command if you have 
not first stopped the NetView subsystem.  From the system operator's 
console, you can use the REPLY command to enter the CLOSE command.

Because the NetView subsystem is processing messages from all other active 
tasks in the MVS system (your automation logic may be necessary for handling 
some or all of these messages), you should temporarily inactivate some or all 
of your applications before canceling the subsystem.

To stop the NetView program, enter:

%CLOSE

where % is the NetView descriptor character. The MVS console must be 
associated with a NetView autotask if you use only %CLOSE to stop the 
NetView program.

If message DSI802A is outstanding, you can reply to the message and then 
issue the CLOSE command. For example, enter:

REPLY nn,CLOSE

where nn is the reply number. The NetView program stops automatically when 
all operators and incoming cross-domain operators have logged off.[3]



You shouldn't assume that, just because nobody has bothered to keep your 
installation's NetView in best shape for the last 15 or so years, that might 
apply to all others nor that NetView, a seat of automation, doesn't follow the 
best practice it tends to require of other products.

Chris Mason

[1] http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/CNMYBK04

[2] If previous "usual suspect" Patrick O'Keefe were still participating, he 
would have jumped on you so hard that you would now be deeper than the 
poor Chilean miners!

[3] I believe this sentence should be in a separate paragraph so that it 
applies 
to both techniques for issuing the CLOSE command. Perhaps it is corrected in 
a later edition - perhaps not.

On Fri, 1 Oct 2010 07:03:41 -0500, Chase, John  
wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List On Behalf Of Chris Mason
>>
>> Robert
>>
>> > ... or you can just use the Modify (F) or STOP (P) command.
>>
>> That "just" is suspicious. The program needs to support the
>MODIFY/STOP
>> interface and not all programs do. It took IMS "for ever" to provide
>this
>> alternative to the WTOR interface and I vaguely remember it took CICS
>quite
>> a while before you could "talk" to it with MODIFY commands.
>
>Meanwhile, NetView still hangs a WTOR on the console  :-(
>
>   -jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Tom Marchant]

On Thu, 30 Sep 2010 16:13:11 -0400, Robert A. Rosenberg wrote:

>At 10:04 -0500 on 09/29/2010, Tom Marchant wrote about Re: Really
>dumb IPL question:
>
>>On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg wrote:
>>
>>>Shutting down a Started Task can be done in the way other STCs are
>>>controlled. ...   you can just use the Modify (F) or STOP (P)
>>>command 
>>
>>MODIFY and STOP only work if the code is written to recognize them.
>>
>
>The assumption of my comment was the program was written to use STOP
>or MODIFY to signal the task to terminate. 

I'm not sure that is a good assumption

>The quote that I was
>responding to (which was omitted from your reply) was to the effect
>that it was against the Ops/Automation types rules/procedures to use
>CANCEL (or STOP/MODIFY which use the same QEDIT interface) to signal
>the terminate order.

I think you've read too much into Peter Nuttall's post that you quoted.  
He did not say that it was against the operational procedures to use 
STOP or MODIFY.  He said that it was against the procedures to use 
CANCEL.  I read that as meaning that the program was not coded to 
recognize STOP or MODIFY.

And, BTW, lest someone get the wrong impression from what you 
wrote above, STOP and MODIFY use the same "QEDIT interface", 
CANCEL does not.

>
>The quote was:
>
>>Setting this up as a started task and then explaining to
>>Ops/Automation that the only way to stop it was to Cancel the
>>Started task was not fun (against their operational procedures) 

And perhaps the relevant phrase in Peter Nuttall's post is 
"the only way to stop it was to Cancel the Started task"

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Vernooij, CP - SPLXM]

"Chase, John"  wrote in message
news:...
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Vernooij, CP -
SPLXM
> > 
> > "Chase, John" wrote in message
> >
>
news: > m>...
> > > > -Original Message-
> > > > From: IBM Mainframe Discussion List On Behalf Of Chris Mason
> > > >
> > > > Robert
> > > >
> > > > > ... or you can just use the Modify (F) or STOP (P) command.
> > > >
> > > > That "just" is suspicious. The program needs to support the
> > > MODIFY/STOP
> > > > interface and not all programs do. It took IMS "for ever" to
> provide
> > > this
> > > > alternative to the WTOR interface and I vaguely remember it took
> > CICS
> > > quite
> > > > a while before you could "talk" to it with MODIFY commands.
> > >
> > > Meanwhile, NetView still hangs a WTOR on the console  :-(
> > >
> > >-jc-
> > >
> > 
> > Is it? Not on our console.
> 
> *03 DSI802A NETV3REPLY WITH VALID NCCF SYSTEM OPERATOR COMMAND
> 
> Also Netview Access:
> 
> *06 EMS0990A ACCESS  READY FOR COMMANDS.
> 
>-jc-

I searched our DSIPARM and found:

TASK.DSIWTOMT.INIT=No  // Do you want the DSI802A WTOR?   

Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Vernooij, CP - SPLXM
> 
> "Chase, John" wrote in message
>
news: m>...
> > > -Original Message-
> > > From: IBM Mainframe Discussion List On Behalf Of Chris Mason
> > >
> > > Robert
> > >
> > > > ... or you can just use the Modify (F) or STOP (P) command.
> > >
> > > That "just" is suspicious. The program needs to support the
> > MODIFY/STOP
> > > interface and not all programs do. It took IMS "for ever" to
provide
> > this
> > > alternative to the WTOR interface and I vaguely remember it took
> CICS
> > quite
> > > a while before you could "talk" to it with MODIFY commands.
> >
> > Meanwhile, NetView still hangs a WTOR on the console  :-(
> >
> >-jc-
> >
> 
> Is it? Not on our console.

*03 DSI802A NETV3REPLY WITH VALID NCCF SYSTEM OPERATOR COMMAND

Also Netview Access:

*06 EMS0990A ACCESS  READY FOR COMMANDS.

   -jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Vernooij, CP - SPLXM]

"Chase, John"  wrote in message
news:...
> > -Original Message-
> > From: IBM Mainframe Discussion List On Behalf Of Chris Mason
> > 
> > Robert
> > 
> > > ... or you can just use the Modify (F) or STOP (P) command.
> > 
> > That "just" is suspicious. The program needs to support the
> MODIFY/STOP
> > interface and not all programs do. It took IMS "for ever" to provide
> this
> > alternative to the WTOR interface and I vaguely remember it took
CICS
> quite
> > a while before you could "talk" to it with MODIFY commands.
> 
> Meanwhile, NetView still hangs a WTOR on the console  :-(
> 
>-jc-
> 

Is it? Not on our console. 

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Chris Mason
> 
> Robert
> 
> > ... or you can just use the Modify (F) or STOP (P) command.
> 
> That "just" is suspicious. The program needs to support the
MODIFY/STOP
> interface and not all programs do. It took IMS "for ever" to provide
this
> alternative to the WTOR interface and I vaguely remember it took CICS
quite
> a while before you could "talk" to it with MODIFY commands.

Meanwhile, NetView still hangs a WTOR on the console  :-(

   -jc-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chris Mason]

Bruce

> ...there is a very simple MVS command that ALL products should be able to 
accept (intercept) .. that is STOP (P).

The rub[1] is in the "should". Indeed, it is just about the simplest MVS 
command it is possible to devise. However there is still a need to support it 
within the program itself and, while not difficult, it is *not* trivial - 
although I 
guess both of those are relative.

Incidentally, I checked the MVS System Commands manual to be sure of my 
ground and my memory of my QEDITEX program which I used to explore this 
matter of the MODIFY and STOP commands long ago. Indeed, I remembered 
correctly that, there is no opportunity to add parameters to a STOP command 
while there is for a MODIFY command - of course. Thus, should you want to 
have different flavours of "stop", you may actually be *obliged* to use the 
MODIFY command for that purpose - sorry!

Chris Mason

[1] Hamlet's sense.

On Thu, 30 Sep 2010 03:59:53 -0500, Bruce Hewson 
 wrote:

>PLEASE PLEASE - do not suggest MODIFY or WTOR to request shutdown of
>your taskthere is a very simple MVS command that ALL products should be
>able to accept (intercept) .. that is STOP (P).
>
>Use MODIFY to change your task environmentnot to shutdown your task.
>
>Use STOP to request shutdown..
>Then if that dont work ... use CANCEL
>Then if that dont work ... use FORCE. but be propared to IPL the whole
>system.
>
>In this day or age there is simply NO excuse not to support the STOP
>command.
>
>extra: Separation of security access rules for STOP and CANCEL away from
>MODIFY is highly advised. The functionality of these commands is distinctly
>different.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 14:14 -0500 on 09/30/2010, Chris Mason wrote about Re: Really dumb 
IPL question:



Robert


 ... or you can just use the Modify (F) or STOP (P) command.


That "just" is suspicious. The program needs to support the MODIFY/STOP
interface and not all programs do.


Since I mentioned it as an alternative to using a WTOR, I was 
implying that the program has this support. I might have been lax in 
not qualifying that comment via "... by having support for ...".


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 10:04 -0500 on 09/29/2010, Tom Marchant wrote about Re: Really 
dumb IPL question:



On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg wrote:


Shutting down a Started Task can be done in the way other STCs are
controlled. ...   you can just use the Modify (F) or STOP (P)
command . If MODIFY is good enough for TCP, TSO, etc, it should be

 >good enough for your RYO STC. It sounds like those Ops/Automation
 >types are brain dead and do not understand what they are doing.

MODIFY and STOP only work if the code is written to recognize them.
Some products are not coded to work with a STOP command.  If not,
it is not the automation that is brain dead.



The assumption of my comment was the program was written to use STOP 
or MODIFY to signal the task to terminate. The quote that I was 
responding to (which was omitted from your reply) was to the effect 
that it was against the Ops/Automation types rules/procedures to use 
CANCEL (or STOP/MODIFY which use the same QEDIT interface) to signal 
the terminate order. We are not taking about pulling the rug out from 
under the task via FORCE here by sending a request for an orderly 
shutdown using standard interfaces. Note that I may be wrong about 
the ability to intercept the CANCEL and suppress it since you are 
going to do an orderly shutdown by treating as a STOP.


The quote was:

Setting this up as a started task and then explaining to 
Ops/Automation that the only way to stop it was to Cancel the 
Started task was not fun (against their operational procedures) 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chris Mason]

Robert

> ... or you can just use the Modify (F) or STOP (P) command.

That "just" is suspicious. The program needs to support the MODIFY/STOP 
interface and not all programs do. It took IMS "for ever" to provide this 
alternative to the WTOR interface and I vaguely remember it took CICS quite 
a while before you could "talk" to it with MODIFY commands.

Obviously a program has to have logic to respond to MODIFY commands and, 
perhaps less obviously, to a STOP command. 

Only CANCEL is/can be independent of the program.

The starting point for research into MODIFY/STOP support is the following:

z/OS MVS Programming: Authorized Assembler Services Guide, SA22-7608-15, 
2.3 Communicating with a program 

(EXTRACT, QEDIT)

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/2.3

I used to use MODIFY support extensively in my mickey-mouse programs using 
the VTAM API. It's not at all difficult.

Chris Mason

On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg 
 wrote:

>At 16:03 +0200 on 09/28/2010, Peter Nuttall wrote about Re: Really
>dumb IPL question:
>
>>Setting this up as a
>>started task and then explaining to Ops/Automation that the only way to
>>stop it was to Cancel the Started task was not fun (against their
>>operational procedures) 
>
>Shutting down a Started Task can be done in the way other STCs are
>controlled. You can issue a WTOR which allows the request to shut
>down to be sent or you can just use the Modify (F) or STOP (P)
>command . If MODIFY is good enough for TCP, TSO, etc, it should be
>good enough for your RYO STC. It sounds like those Ops/Automation
>types are brain dead and do not understand what they are doing.
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Bruce Hewson]

PLEASE PLEASE - do not suggest MODIFY or WTOR to request shutdown of 
your taskthere is a very simple MVS command that ALL products should be 
able to accept (intercept) .. that is STOP (P).

Use MODIFY to change your task environmentnot to shutdown your task.

Use STOP to request shutdown..
Then if that dont work ... use CANCEL
Then if that dont work ... use FORCE. but be propared to IPL the whole 
system.

In this day or age there is simply NO excuse not to support the STOP 
command.

extra: Separation of security access rules for STOP and CANCEL away from 
MODIFY is highly advised. The functionality of these commands is distinctly 
different.


On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg 
 wrote:

>At 16:03 +0200 on 09/28/2010, Peter Nuttall wrote about Re: Really
>dumb IPL question:
>
>>Setting this up as a
>>started task and then explaining to Ops/Automation that the only way to
>>stop it was to Cancel the Started task was not fun (against their
>>operational procedures) 
>
>Shutting down a Started Task can be done in the way other STCs are
>controlled. You can issue a WTOR which allows the request to shut
>down to be sent or you can just use the Modify (F) or STOP (P)
>command . If MODIFY is good enough for TCP, TSO, etc, it should be
>good enough for your RYO STC. It sounds like those Ops/Automation
>types are brain dead and do not understand what they are doing.
>


Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Chris Mason]

significance is to be timed or not to be timed and, as long as the 
affected job step has TIME=1440 - or some more modern equivalent - added 
to the EXEC statement, the effect identical to having specified SYST is 
achieved.

I never messed about with "goal mode" and "WLM" but it's clear that a little 
bit 
of definition activity is all that is needed to achieve the same effect as 
having 
specified SYST there also.

My reason for getting rid of the single step requirement was to be able to add 
job steps to ensure that trace and dump data sets were newly available for 
the following VTAM or NetView or TCP/IP for MVS as it then was started 
tasks. I probably applied the same technique as a matter of course to any 
other started task I needed to run and never suffered any "unintended 
consequences".

Chris Mason

[1] In fact I discovered - as you may have noticed - to discover the e-mail of 
posters even when one site which copies the list posts obscures a poster's e-
mail address. There is another site, Google Groups in fact, which also obscures 
poster's e-mail address - but the other side of the "@"!

[2] Before posting, I checked how much of a limitation not using NODSI might 
be and saw that very few PPT entries seem to need it.


On Mon, 27 Sep 2010 14:43:49 -0500, McKown, John 
 wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg
>> Sent: Monday, September 27, 2010 1:43 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: Really dumb IPL question
>>
>> At 00:55 -0500 on 09/27/2010, Brian Westerman wrote about Re: Really
>> dumb IPL question:
>>
>> >It's more work to tell them multiple places that it can go,
>> but it leaves it
>> >up to the site to decide what works best for them.  We even
>> have a small
>> >derivative of one of our products (SyzCMD/z) that can be run
>> as a step
>> >before any job that checks for dependencies and waits for
>> things to be the
>> >way the site (or we) need them to be before things go
>> forward, like (but not
>> >limited to) TCP is up (or not), VTAM is up (or not), some
>> other task is
>> >running (or not running), etc
>>
>> That sounds useful but unless my memory is inaccurate an STC must be
>> a single step so that utility is not useful unless it has the option
>> of being able to issue an XCTL to the real program once the system
>> status has been verified.
>
>Ah, yes and no.
>
>Basically, any proc in the right proclib can be started with a START 
command. It can be single or multi-step. Most seems to be single step. Some 
TCPIP subfunction STCs have two step. The first sets up some sort of 
messaging facility and the second does the work.
>
>However, if the STC is to have its program controlled by the PPT (SCHEDnn 
member of PARMLIB) to set specific attributes (such as NODSI, and SYST as 
best as I can tell) then the procedure must be single step. If it is multistep, 
the PPT attributes are ignored with a message: IEF188I PROBLEM PROGRAM 
ATTRIBUTES ASSIGNED
>
>--
>John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Peter Nuttall]

Indeed ... This was the case in the example I gave  I raised a problem 
with the Development team and . 

No idea what happened eventually, because I moved on  C'est la vie ... 


I guess, in their defence they never intended/suggested for the IP 
listeners to work as Started Tasks, 
that was for our 'ease of use'  Nevertheless, the code should have 
been present.
 
 



"Tom Marchant"  
Sent by: "IBM Mainframe Discussion List" 
29/09/2010 05:04 PM
Please respond to
"IBM Mainframe Discussion List" 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: Really dumb IPL question









MODIFY and STOP only work if the code is written to recognize them.
Some products are not coded to work with a STOP command.  If not, 
it is not the automation that is brain dead.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



This e-mail message, including any attachments transmitted with it, is 
CONFIDENTIAL and may contain legally privileged information. This message is 
intended solely for the use of the individual or entity to whom it is 
addressed. If you have received this message in error, please notify us 
immediately and delete it from your system. Please visit our website to read 
the full disclaimer: http://www.euroclear.com/site/public/disclaimer

Re: Really dumb IPL question

[Tom Marchant]

On Tue, 28 Sep 2010 22:26:29 -0400, Robert A. Rosenberg wrote:

>Shutting down a Started Task can be done in the way other STCs are
>controlled. ...   you can just use the Modify (F) or STOP (P)
>command . If MODIFY is good enough for TCP, TSO, etc, it should be
>good enough for your RYO STC. It sounds like those Ops/Automation
>types are brain dead and do not understand what they are doing.

MODIFY and STOP only work if the code is written to recognize them.
Some products are not coded to work with a STOP command.  If not, 
it is not the automation that is brain dead.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

I've always been told that WTORs are a terrible way to "wait for a command"
for the reason you describe. That's what MODIFY is for.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Vernooij, CP - SPLXM
Sent: Wednesday, September 29, 2010 12:05 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

"Robert A. Rosenberg"  wrote in message
news:...
> At 16:03 +0200 on 09/28/2010, Peter Nuttall wrote about Re: Really 
> dumb IPL question:
> 
> >Setting this up as a
> >started task and then explaining to Ops/Automation that the only way
to
> >stop it was to Cancel the Started task was not fun (against their
> >operational procedures) 
> 
> Shutting down a Started Task can be done in the way other STCs are 
> controlled. You can issue a WTOR which allows the request to shut 
> down to be sent or you can just use the Modify (F) or STOP (P) 
> command . If MODIFY is good enough for TCP, TSO, etc, it should be 
> good enough for your RYO STC. It sounds like those Ops/Automation 
> types are brain dead and do not understand what they are doing.
> 

I would strongly discourage WTORs for this. If you have a number of
those tasks on a number of systems in your sysplex, the WTORs will fill
an entire screen, just wasting space until you going to reply to it 2
months from now.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Vernooij, CP - SPLXM]

"Robert A. Rosenberg"  wrote in message
news:...
> At 16:03 +0200 on 09/28/2010, Peter Nuttall wrote about Re: Really 
> dumb IPL question:
> 
> >Setting this up as a
> >started task and then explaining to Ops/Automation that the only way
to
> >stop it was to Cancel the Started task was not fun (against their
> >operational procedures) 
> 
> Shutting down a Started Task can be done in the way other STCs are 
> controlled. You can issue a WTOR which allows the request to shut 
> down to be sent or you can just use the Modify (F) or STOP (P) 
> command . If MODIFY is good enough for TCP, TSO, etc, it should be 
> good enough for your RYO STC. It sounds like those Ops/Automation 
> types are brain dead and do not understand what they are doing.
> 

I would strongly discourage WTORs for this. If you have a number of
those tasks on a number of systems in your sysplex, the WTORs will fill
an entire screen, just wasting space until you going to reply to it 2
months from now.

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 16:03 +0200 on 09/28/2010, Peter Nuttall wrote about Re: Really 
dumb IPL question:



Setting this up as a
started task and then explaining to Ops/Automation that the only way to
stop it was to Cancel the Started task was not fun (against their
operational procedures) 


Shutting down a Started Task can be done in the way other STCs are 
controlled. You can issue a WTOR which allows the request to shut 
down to be sent or you can just use the Modify (F) or STOP (P) 
command . If MODIFY is good enough for TCP, TSO, etc, it should be 
good enough for your RYO STC. It sounds like those Ops/Automation 
types are brain dead and do not understand what they are doing.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 18:02 -0700 on 09/28/2010, Charles Mills wrote about Re: Really 
dumb IPL question:


While I'm on a rant here you in the sysprog community should keep in 
mind that you are not the entire audience for our products. We don't 
typically sell to the guy or gal who maintains SYS1.PARMLIB. So in 
many cases what you think should be in documentation is not what 
needs to be in there for the guy or gal who will make the purchasing 
decision (see above, compensation). We'll put in there what you want 
to see, but please keep in mind that we may have to put other things 
in there too.


There is nothing wrong with having documentation that serves multiple 
audiences. OTOH, if the documentation does not provide the 
information to allow the program to be installed/activated then no 
matter how accurate/good/informative the sales part of the 
documentation is, you are supplying/selling a defective product.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Awesome! Yes! Thank you, thank you, thank you.

This is great. This should be required reading for every vendor. Mainly, this 
should be made available to every vendor.

Some of your points I knew and were planned for incorporation in my current 
project; some were not. I will consider all of them.

Judging from some of the posts here I think that those of you in the user 
sysprog community think we software vendors stay up at night trying to think of 
ways to annoy you. Nothing could be further from the truth. In many cases our 
compensation is tied (sometimes 100%!) to how well the product sells.

The problem is not willfulness or even laziness. The problem is that many of us 
came up through a development career path, not a sysprog career path. I wrote 
my first mainframe program in 1968 but I have never been a sysprog. I have 
never owned catalogs and parmlibs and SMS and RACF and gotten calls in the 
middle of the night because MVS crashed. I simply don't understand your 
problems unless, like Linda, you tell me what they are.

While I'm on a rant here you in the sysprog community should keep in mind that 
you are not the entire audience for our products. We don't typically sell to 
the guy or gal who maintains SYS1.PARMLIB. So in many cases what you think 
should be in documentation is not what needs to be in there for the guy or gal 
who will make the purchasing decision (see above, compensation). We'll put in 
there what you want to see, but please keep in mind that we may have to put 
other things in there too.

Thanks again,
Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Linda Mooney
Sent: Tuesday, September 28, 2010 5:04 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

Hi Charles, 

I very much appreciate that you asked the question.  I can't tell you how many 
hours (maybe hundreds!)  I have spent over the last 10 years with vendor 
support folks trying to get the information you are planning to give out on a 
silver platter.  Thank you.  

I realize that this goes beyond your initial question by a good bit.  Perhaps 
it will be useful - if not, I know that you know where the delete key is   ;-). 

For example - 

I have a product suite form a vendor.  I really like these products and the 
vendor has since fixed their docs.   Both A and B require TCP/IP services.  A 
could come up with or without TCP/IP.  It would connect with TCP/IP when TCP/IP 
was ready.  If TCP/IP went down, A would issue a complaint message every minute 
and then connect back up with TCP/IP when it came back up - all by itself.  
Product B, on the other hand, would try ONCE to connect with TCP/IP, post one 
small, one line scroll message and never try again  - and there was no command 
to make it try again.  The only option was to shut Product B down and restart 
it. 

I am in a small shop, 2 monplex lpars, and we are back leveled.  When I look at 
a product - which I haven't lately because our budget is so bad, I really like 
to  see the - 

• Minimum and maximum z/OS requirements for it to run, including USS 
• Minimum and maximum z/OS requirements for it to be supported - which may 
be different 
• What are the co-existance levels between products from the same vendor? 
• What are the below the line and above the line storage requirements? 
• Any other products required? 
• What are the RACF, SAF, or other security requirements? For the 
installer, admin, user?  It's terrific if these things are clearly spelled out. 
 It's a royal pain to have to find out by "tripping over it" testing. 
• Does it require/psuedo-require SMS?  Some products write output either to 
one SMS pool or one volume.  We use some SMS, but not a lot, just where we 
really need it. 
• Does it/can it/must it run in LPA/ and why? 
• Please don't tell me that it must run in SYS1.PROCLIB, or have parm 
entries in SYS1.PARMLIB.  That means I can't let the new sysprog install it.  
Newbies follow directions too closely sometimes.  Tell me something like - 
Place this parmlib member in the SYS1 parmlib library concatenation. etc - like 
the one who followed the docs to apply and then apply the usermods, then accept 
everything - and all of that before enven testing the product! 
• Any other products (from the same vendor) that work well in concert with 
this product 
• Any other products that this product does not play well with (same or 
different vendor) and does it mean that I have to choose between products or is 
there some way that I can run both? I had this one - 2 programmer support 
products - they could co-exist, but it wasn't documented how to do it.  Both 
product vendors knew about the issues, but didn't want to help until I told 
them that if the products wouldn't play nicely together that we would drop one, 
maybe both.  If there had

Re: Really dumb IPL question

[Linda Mooney]

will finish what it's doing and shutdown gracefully, or P 
product for it to save its status and shutdown immediately.  On the next start 
up, it will pick up right where it left off.  Or I can issue F stc,ABEND and 
down she goes - now.  Very handy.  Then there is this other product - to shut 
it down, log on as an admin, close out its log, run a job to copy out the 
closed log, then log out with a shutdown option which submits a batch job to 
finish the shutdown - royal pain that one. 
• If/when the product gets into trouble, what are the data gathering, 
internal trace, dump options?  Are there programs to run against the gathered 
data?  Some products have some great features along these lines. 
• Please include message modification and message routing options where you 
can.  For some of our products, I push most messages to syslog only, sometimes 
I move something that most folks would handle with their automation product to 
the console and highlight it.  One of our products would get into grief every 
once in a blue moon.  The greener operators didn't handle it well, as cost us 
an outage or two.  I modified the message, to include a follow procedure Z 
instruction - no more problems. 



Also, while many shops have automated ops, many others don't .  



Thanks, 



Linda Mooney 


- Original Message - 
From: "Charles Mills"  
To: IBM-MAIN@bama.ua.edu 
Sent: Tuesday, September 28, 2010 7:19:36 AM 
Subject: Re: Really dumb IPL question 

Thanks for your kind words. It's easy to feel beat-up here no matter what 
you say or do. 

Charles 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf 
Of Peter Nuttall 
Sent: Tuesday, September 28, 2010 7:03 AM 
To: IBM-MAIN@bama.ua.edu 
Subject: Re: Really dumb IPL question 

Hmm ... I worked for a software company as a consultant in a previous life 
... Client-server app builder ... They used an IP listener to manage the 
upload/download of the application software ... Setting this up as a 
started task and then explaining to Ops/Automation that the only way to 
stop it was to Cancel the Started task was not fun (against their 
operational procedures)  

However, Credit to Charles for putting these questions out there and 
attempting to get a common approach  
  
  



"Charles Mills"  
Sent by: "IBM Mainframe Discussion List"  
28/09/2010 03:51 PM 
Please respond to 
"IBM Mainframe Discussion List"  


To 
IBM-MAIN@bama.ua.edu 
cc 

Subject 
Re: Really dumb IPL question 








Thanks, Barbara. I admit I had given no thought (so far) to this issue. 
I'm 
going to start a new thread on this topic. 

Charles 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf 
Of Barbara Nitz 
Sent: Monday, September 27, 2010 9:47 PM 
To: IBM-MAIN@bama.ua.edu 
Subject: Re: Really dumb IPL question 

>Since you say it can handle waiting for TCPIP on it's own, what's the 
>diff? If I want it during limited function "system checkout time" I'd 
>use COMMNDxx. Otherwise the automation. 

To reiterate: The difference is shutdown. If TCPIP services are needed for 

successful shutdown, then the product MUST be shutdown before TCPIP 
services go away. Or there needs to be a lot more code to test that IP 
services are always available and to handle a graceful shutdown in the 
absence of TCPIP. 

Barbara Nitz 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 



This e-mail message, including any attachments transmitted with it, is 
CONFIDENTIAL and may contain legally privileged information. This message is 
intended solely for the use of the individual or entity to whom it is 
addressed. If you have received this message in error, please notify us 
immediately and delete it from your system. Please visit our website to read 
the full disclaimer: http://www.euroclear.com/site/public/disclaimer 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Thanks for your kind words. It's easy to feel beat-up here no matter what
you say or do.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Peter Nuttall
Sent: Tuesday, September 28, 2010 7:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

Hmm ... I worked for a software company as a consultant in a previous life 
... Client-server app builder ... They used an IP listener to manage the 
upload/download of the application software ... Setting this up as a 
started task and then explaining to Ops/Automation that the only way to 
stop it was to Cancel the Started task was not fun (against their 
operational procedures)  

However, Credit to Charles for putting these questions out there and 
attempting to get a common approach  
 
 



"Charles Mills"  
Sent by: "IBM Mainframe Discussion List" 
28/09/2010 03:51 PM
Please respond to
"IBM Mainframe Discussion List" 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: Really dumb IPL question








Thanks, Barbara. I admit I had given no thought (so far) to this issue. 
I'm
going to start a new thread on this topic.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf
Of Barbara Nitz
Sent: Monday, September 27, 2010 9:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

>Since you say it can handle waiting for TCPIP on it's own, what's the
>diff? If I want it during limited function "system checkout time" I'd
>use COMMNDxx. Otherwise the automation.

To reiterate: The difference is shutdown. If TCPIP services are needed for 

successful shutdown, then the product MUST be shutdown before TCPIP 
services go away. Or there needs to be a lot more code to test that IP 
services are always available and to handle a graceful shutdown in the 
absence of TCPIP.

Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



This e-mail message, including any attachments transmitted with it, is
CONFIDENTIAL and may contain legally privileged information. This message is
intended solely for the use of the individual or entity to whom it is
addressed. If you have received this message in error, please notify us
immediately and delete it from your system. Please visit our website to read
the full disclaimer: http://www.euroclear.com/site/public/disclaimer

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Peter Nuttall]

Hmm ... I worked for a software company as a consultant in a previous life 
... Client-server app builder ... They used an IP listener to manage the 
upload/download of the application software ... Setting this up as a 
started task and then explaining to Ops/Automation that the only way to 
stop it was to Cancel the Started task was not fun (against their 
operational procedures)  

However, Credit to Charles for putting these questions out there and 
attempting to get a common approach  
 
 



"Charles Mills"  
Sent by: "IBM Mainframe Discussion List" 
28/09/2010 03:51 PM
Please respond to
"IBM Mainframe Discussion List" 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: Really dumb IPL question








Thanks, Barbara. I admit I had given no thought (so far) to this issue. 
I'm
going to start a new thread on this topic.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On 
Behalf
Of Barbara Nitz
Sent: Monday, September 27, 2010 9:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

>Since you say it can handle waiting for TCPIP on it's own, what's the
>diff? If I want it during limited function "system checkout time" I'd
>use COMMNDxx. Otherwise the automation.

To reiterate: The difference is shutdown. If TCPIP services are needed for 

successful shutdown, then the product MUST be shutdown before TCPIP 
services go away. Or there needs to be a lot more code to test that IP 
services are always available and to handle a graceful shutdown in the 
absence of TCPIP.

Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



This e-mail message, including any attachments transmitted with it, is 
CONFIDENTIAL and may contain legally privileged information. This message is 
intended solely for the use of the individual or entity to whom it is 
addressed. If you have received this message in error, please notify us 
immediately and delete it from your system. Please visit our website to read 
the full disclaimer: http://www.euroclear.com/site/public/disclaimer

Re: Really dumb IPL question

[Charles Mills]

Thanks, Barbara. I admit I had given no thought (so far) to this issue. I'm
going to start a new thread on this topic.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Barbara Nitz
Sent: Monday, September 27, 2010 9:47 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

>Since you say it can handle waiting for TCPIP on it's own, what's the
>diff? If I want it during limited function "system checkout time" I'd
>use COMMNDxx. Otherwise the automation.

To reiterate: The difference is shutdown. If TCPIP services are needed for 
successful shutdown, then the product MUST be shutdown before TCPIP 
services go away. Or there needs to be a lot more code to test that IP 
services are always available and to handle a graceful shutdown in the 
absence of TCPIP.

Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Barbara Nitz]

>Since you say it can handle waiting for TCPIP on it's own, what's the
>diff? If I want it during limited function "system checkout time" I'd
>use COMMNDxx. Otherwise the automation.

To reiterate: The difference is shutdown. If TCPIP services are needed for 
successful shutdown, then the product MUST be shutdown before TCPIP 
services go away. Or there needs to be a lot more code to test that IP 
services are always available and to handle a graceful shutdown in the 
absence of TCPIP.

Barbara Nitz

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 00:55 -0500 on 09/27/2010, Brian Westerman wrote about Re: Really 
dumb IPL question:



It's more work to tell them multiple places that it can go, but it leaves it
up to the site to decide what works best for them.  We even have a small
derivative of one of our products (SyzCMD/z) that can be run as a step
before any job that checks for dependencies and waits for things to be the
way the site (or we) need them to be before things go forward, like (but not
limited to) TCP is up (or not), VTAM is up (or not), some other task is
running (or not running), etc


That sounds useful but unless my memory is inaccurate an STC must be 
a single step so that utility is not useful unless it has the option 
of being able to issue an XCTL to the real program once the system 
status has been verified.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Robert A. Rosenberg
> Sent: Monday, September 27, 2010 1:43 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Really dumb IPL question
> 
> At 00:55 -0500 on 09/27/2010, Brian Westerman wrote about Re: Really 
> dumb IPL question:
> 
> >It's more work to tell them multiple places that it can go, 
> but it leaves it
> >up to the site to decide what works best for them.  We even 
> have a small
> >derivative of one of our products (SyzCMD/z) that can be run 
> as a step
> >before any job that checks for dependencies and waits for 
> things to be the
> >way the site (or we) need them to be before things go 
> forward, like (but not
> >limited to) TCP is up (or not), VTAM is up (or not), some 
> other task is
> >running (or not running), etc
> 
> That sounds useful but unless my memory is inaccurate an STC must be 
> a single step so that utility is not useful unless it has the option 
> of being able to issue an XCTL to the real program once the system 
> status has been verified.

Ah, yes and no.

Basically, any proc in the right proclib can be started with a START command. 
It can be single or multi-step. Most seems to be single step. Some TCPIP 
subfunction STCs have two step. The first sets up some sort of messaging 
facility and the second does the work. 

However, if the STC is to have its program controlled by the PPT (SCHEDnn 
member of PARMLIB) to set specific attributes (such as NODSI, and SYST as best 
as I can tell) then the procedure must be single step. If it is multistep, the 
PPT attributes are ignored with a message: IEF188I PROBLEM PROGRAM ATTRIBUTES 
ASSIGNED

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-691-6183 cell
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Ted MacNEIL]

>That sounds useful but unless my memory is inaccurate an STC must be a single 
>step

I believe your memory is inaccurate.

TSO must be a single step, or you get an abend - S622, iirc.

But, we've had multi-step CICS Regions as started tasks.
Clean-up; CICS; recovery.

PS: it's a started task (or Started Task). STC stands for Started Task Control 
-- the sub-system.
Calling it an STC is inaccurate, and akin to calling a job a JCL, or an EXEC a 
REXX.
-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Mark Zelden]

On Mon, 27 Sep 2010 19:53:02 +, Ted MacNEIL  wrote:


>Calling it an STC is inaccurate, and akin to calling a job a JCL, or an
EXEC a REXX.
>-

Common usage, inaccurate or not.   People, manuals /  doc all use the 
terms STC and "started task" synonymously.   "Please define this STC
to RACF" etc.

This existed long before one of your pet peeves that people complain about
the usage of (USS) - and there is no ambiguity in this one.  

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Anne & Lynn Wheeler]

d...@lists.duda.com (David Andrews) writes:
> Perhaps TCPIP autolog would do the trick as well?  Does your product run
> all the time?

I had originally created the *autolog* command for automated
benchmarking ... near the end of the system boot/ipl process, it would
autolog a generic id (*autolog1*). For benchmarking, *autolog1* would
have script that autolog'ed the benchmarking ID ... which had a script
controlling which processes to *autolog* and which synthetic workload
each process should run. At the end of the benchmark, it would update
the script for the next benchmark, and do an auto shutdown/reboot
... which would invoke the next benchmark. This would be repeated as
long as needed. For instance, for the final validation for my resource
manager, over 2000 automated benchmarks were run, taking 3 months
elapsed time.

Some past posts mentioning automated benchmarking
http://www.garlic.com/~lynn/submain.html#bench

some old email mentioning migrating a whole lot of code from cp67 to
vm370 ... and features that were in my internal csc/vm release (product
for internal datacenters) starting out with release 2 of vm370.
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
http://www.garlic.com/~lynn/2006w.html#email750430

we had collected lots of workload and configuration profile information
from both internal and customer datacenters ... and built graph
depicting normal range of operations. The first 1000 benchmarks were
manually defined to evenly cover the wide variety of configurations and
workloads (along with numerous benchmarks way outside normal observed
operations). The final 1000 was an intelligent automated program that
included sophisticated analytical system model ... which would "look
for" interesting operating points (based on all benchmark data todate;
it would also predict what the resulting benchmark should be and compare
the actual results with the predicted; interesting that it was used to
help calibrate actual operation as well as the analytical system model).

some of the items (including *autolog*) were picked up and released in
the standard vm370 release 3 ... and other features were packgaged and
released in my resource manager. misc. past posts mentioning my resource
manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

for production operation, while cp67 got auto-reboot fairly early ... it
still required (operator) manual initiation of lots of the services
(like networking). autolog became the standard process for starting all
these standard processes (back then they were referred to as "service
virtual machines" ... the current nomenclature seems to be "virtual
appliance").

One of the issues for virtual machine based system use for 7x24 online
timesharing operation ... both dedicated corporate use as well as
commercial timesharing service bureaus (the '60s & '70s version of
"cloud computing") was cutting datacenter costs for offshift, usually
light useage. In the early days, machines were leased and monthly
datacenter charge was based on hrs taken from the cpu meter, which ran
when the cpu and/or any channel was active (and could continue to run
for 400ms after all activity had ceased). A very early trick in cp67 was
how to leave an active channel program (to accept incoming terminal
activity) ... and still allow the channel to go to sleep when no data was
actually being transferred. The later trick was increasing "dark room"
operation for lots of offshift (not only auto-boot, but also have all
the expected services to be back up and running). misc. past posts
mentioning early online commercial timesharing service bureaus:
http://www.garlic.com/~lynn/subtopic.html#timeshare

part of picking up lot of stuff I had been doing on 370 for release 3
... and then also releasing a lot of the rest of stuff as resource
manager ... was getting stuff back into the 370 product pipeline after
the failure of FS ... misc. past posts mentioning Future System effort
http://www.garlic.com/~lynn/submain.html#futuresys

i.e. FS was radically different from 370 and was going to completely
replace it; as a result lots of work had ceased on 370 related products
(I continued to work on 370 and made critical observations about reality
of what was going on in FS). Recently I ran into description of OS/VS2
SVS & MVS that were supposedly just on the "glide-path" to the FS
operating system ("OS/VS2 Release 3").

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Ted MacNEIL]

>Why are you so opposed to my mentioning some recommended approaches?

It's a matter what to do vs how to do it.

The recommendations tend to become instructions, and as SYSPROGs 'dumb down' 
inconsistent implementations abound.

Just tell me what is needed, first.
If you think your recommendations have merit, fine, but list them under 
possibilities, not in with prerequisites.

Been burned a few times by SYSPROGs, blindly following recommendations, eg:

For performance reasons, we recommend you put the programmes in LPA.

Boom! CICS wouldn't come up.

It should have said something like:

If performance is a consideration, and you have the capability, placing some, 
or all, programmes in the LPA is an option.

Yes, the example may be out-dated, and possibly not a concern, today.
But, **it happens.
And, this is the first example that pops to mind.


-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Perfect. Great suggestion. Thanks.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
David Andrews
Sent: Monday, September 27, 2010 7:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

On Mon, 2010-09-27 at 10:01 -0400, Charles Mills wrote:
> TCP/IP is a prerequisite but the product can wait for TCP/IP, so it makes
> sense to start it after starting TCP/IP but it does not matter if TCP/IP is
> not fully initialized.

Perhaps TCPIP autolog would do the trick as well?  Does your product run
all the time?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Gibney, Dave]

I agree with Ted and others. Tell me what it needs. For me, I'll either
put it in COMMNDxx or the CA-OPS start-up script.
Since you say it can handle waiting for TCPIP on it's own, what's the
diff? If I want it during limited function "system checkout time" I'd
use COMMNDxx. Otherwise the automation.

We don't do $VS anything. Other shops may. We would decline your
suggestion if it was $VS. 

If you were CA, I might tag it off of CAS9. Still, my choice.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Charles Mills
> Sent: Monday, September 27, 2010 7:37 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Really dumb IPL question
> 
> Ted, I've got a lot of successful third-party mainframe product
> management
> experience.
> 
> I'm sure every "shop" knows what they are doing but salespeople, sales
> support people, and tech support people don't talk to "shops," they
> talk to
> individuals at shops, and not every individual is comfortable with
> "just do
> it." This is not some weird notion of mine alone. Read Tony Harminc's
> post
> on the subject.
> 
> Yes, no matter what we say in a manual, a shop will do it the way they
> want
> to do it. I'm going to say what the prerequisites are and that they
are
> free
> to do it any way that works for them. Why are you so opposed to my
> mentioning some recommended approaches?
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf
> Of Ted MacNEIL
> Sent: Monday, September 27, 2010 7:12 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Really dumb IPL question
> 
> >So humor me, I'm not much of an operations person as you can tell,
> where
> would that be?
> >One alternative is "your console automation system" but what are the
> recommended vanilla IBM alternatives?
> 
> >- A $VS command in the JESx initialization data set.
> >- Where else?
> 
> None of those!
> 
> Just tell us the requirements and prerequisites.
> Each shop has different ways to deal with them.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[David Andrews]

On Mon, 2010-09-27 at 10:01 -0400, Charles Mills wrote:
> TCP/IP is a prerequisite but the product can wait for TCP/IP, so it makes
> sense to start it after starting TCP/IP but it does not matter if TCP/IP is
> not fully initialized.

Perhaps TCPIP autolog would do the trick as well?  Does your product run
all the time?

http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.halz001/autolog.htm

-- 
David Andrews
A. Duda and Sons, Inc.
david.andr...@duda.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Ted, I've got a lot of successful third-party mainframe product management
experience.

I'm sure every "shop" knows what they are doing but salespeople, sales
support people, and tech support people don't talk to "shops," they talk to
individuals at shops, and not every individual is comfortable with "just do
it." This is not some weird notion of mine alone. Read Tony Harminc's post
on the subject.

Yes, no matter what we say in a manual, a shop will do it the way they want
to do it. I'm going to say what the prerequisites are and that they are free
to do it any way that works for them. Why are you so opposed to my
mentioning some recommended approaches?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Ted MacNEIL
Sent: Monday, September 27, 2010 7:12 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

>So humor me, I'm not much of an operations person as you can tell, where
would that be?
>One alternative is "your console automation system" but what are the
recommended vanilla IBM alternatives?

>- A $VS command in the JESx initialization data set.
>- Where else?

None of those!

Just tell us the requirements and prerequisites.
Each shop has different ways to deal with them.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Ted MacNEIL]

>So humor me, I'm not much of an operations person as you can tell, where would 
>that be?
>One alternative is "your console automation system" but what are the 
>recommended vanilla IBM alternatives?

>- A $VS command in the JESx initialization data set.
>- Where else?

None of those!

Just tell us the requirements and prerequisites.
Each shop has different ways to deal with them.


-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

TCP/IP is a prerequisite but the product can wait for TCP/IP, so it makes
sense to start it after starting TCP/IP but it does not matter if TCP/IP is
not fully initialized.

> point out where they CAN put it to have it start up at the correct time

So humor me, I'm not much of an operations person as you can tell, where
would that be? One alternative is "your console automation system" but what
are the recommended vanilla IBM alternatives?

- A $VS command in the JESx initialization data set.
- Where else?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Brian Westerman
Sent: Sunday, September 26, 2010 10:55 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

We have the same sort of issue with our product documentation.  We have
found though that you really shouldn't tell they site where to put it. 
Instead, we point out where they CAN put it to have it start up at the
correct time.  

It's more work to tell them multiple places that it can go, but it leaves it
up to the site to decide what works best for them.  We even have a small
derivative of one of our products (SyzCMD/z) that can be run as a step
before any job that checks for dependencies and waits for things to be the
way the site (or we) need them to be before things go forward, like (but not
limited to) TCP is up (or not), VTAM is up (or not), some other task is
running (or not running), etc.  

In the end though I think it's best to let the site decide.

Brian  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Burrell, C. Todd (CDC/OCOO/ITSO) (CTR)]

I'd probably just recommend that they run the start command after either
TCPIP or TSO.  In our automation we have a number of tasks similar to
this one that we start after TCPIP (if it depends on TCPIP) or TSO.  

C. Todd Burrell 
PMP, MCSE 2003:Security
Security+, Network+
ITIL V3 Foundations
CSC Lead z/OS Systems Programmer 
ITSO 
(404) 723-2017 (Cell) 



-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Charles Mills
Sent: Sunday, September 26, 2010 6:16 PM
To: IBM-MAIN@bama.ua.edu
Subject: Really dumb IPL question

Hey, I'm a coder, not a sysprog.

I'm writing documentation for a product that a customer would normally
run
automatically as an STC at every IPL. What do I say in the manual about
where to place the START command? Where would this command go? It
probably
wants to be run fairly late in the IPL after most other subsystems are
up.

Place the command START FOO in _?

I'm looking at the documentation for COMMNDxx and IEACMD00 in Init &
Tuning.
COMMNDxx looks like it gets processed too early in the game and IEACMD00
is
documented as being for IBM-supplied commands only but there is no
cross-reference to where else to put a START command.

Thanks,

Charles Mills

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Brian Westerman]

We have the same sort of issue with our product documentation.  We have
found though that you really shouldn't tell they site where to put it. 
Instead, we point out where they CAN put it to have it start up at the
correct time.  

It's more work to tell them multiple places that it can go, but it leaves it
up to the site to decide what works best for them.  We even have a small
derivative of one of our products (SyzCMD/z) that can be run as a step
before any job that checks for dependencies and waits for things to be the
way the site (or we) need them to be before things go forward, like (but not
limited to) TCP is up (or not), VTAM is up (or not), some other task is
running (or not running), etc.  

In the end though I think it's best to let the site decide.

Brian  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Barbara Nitz]

>I agree... but in my experience we have as many or more customers who
>balk at "put the following command in xxx". Before we updated our doc
>some years ago, we got a number of complaints that we as a vendor
>obviously didn't understand how the Real World works, we must be
>developers working in a lab environment who have never run in a
>production shop, etc.

Exactly. I am one of those customers, especially if the context says that the 
address space is supposed/required to stay up all the time. Of course no 
address space *ever* takes a terminating abend. Then how do you (re)start? 
And how do you *timely* restart?

Document the startup dependencies and the startup commands (and the 
message id of your asid that says that the asid is now fully functional) and if 
you want to be real good, also indicate where to put stuff in the WLM 
hierarchy.  The latter is something that IBM, too, always neglects to mention.

>It gets worse if you want to have them run a UNIX program. If you tell
>them to run a started task with PGM=BPXBATCH, someone asks "can't I
>just run it from a shell prompt or using cron the way we run 'normal'
>stuff?". If you say something about a shell prompt, the complaint is
>that this is a production shop, we don't use shell prompts, etc.

And what you apparently all forget: Document the shutdown procedure
Again including dependencies. It does no good if an asid needs TCPIP but since 
that wasn't a startup requirement, TCPIP might be gone when this asid 
attempts to terminate, and it can't because the services it depends upon are 
already gone. So the said just hangs because it was too stupid in the first 
place to test for TCPIP availability.

This is *especially* important in a UNIX environment, as there are 
installations 
(ours is one of them) that do a f bpxoinit,shutdown=forks as part of normal 
shutdown for IPL. That kicks the feet of anything unix out from under them 
pretty fast, but also (usually) makes it hard for them to terminate in the 
first 
place. Not to mention that *some* of them (like WAS) have a distinct need 
for shutdown in certain sequence, and if that isn't done, the filesystems can 
get corrupted at *IPL*.

I am harping on this, as I get to investigate the 'system xyz did not shut 
down' all the time, and it is usually because *someone* forgot to mention 
*some* requirement.

Bets regards, Barbara

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Tony Harminc]

On 26 September 2010 19:10, Charles Mills  wrote:

> In my experience some customers will balk if as vendors we just say "take
> the necessary steps to have the following happen." We get customers going
> "how do we do that?"

I agree... but in my experience we have as many or more customers who
balk at "put the following command in xxx". Before we updated our doc
some years ago, we got a number of complaints that we as a vendor
obviously didn't understand how the Real World works, we must be
developers working in a lab environment who have never run in a
production shop, etc.

> Rather than saying "put a start command wherever your shop puts start 
> commands" I would prefer
> to say "put a start command in __ or wherever your shop usually puts
> start commands that are to execute after blah and blah are up. You may use a
> console automation package to start FOO if your shop normally starts started
> tasks in this way."

Yup - that roughly what we say in our doc.

It gets worse if you want to have them run a UNIX program. If you tell
them to run a started task with PGM=BPXBATCH, someone asks "can't I
just run it from a shell prompt or using cron the way we run 'normal'
stuff?". If you say something about a shell prompt, the complaint is
that this is a production shop, we don't use shell prompts, etc.

All this is perfectly reasonable and understandable; shops vary a lot
in, as you say, who does what, who knows what, and what their
backgrounds are.

So we pretty much say that program x has to run with these privs under
environment y, and here are some examples that should help you decide
what best fits your organization's operational procedures.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Robert A. Rosenberg]

At 16:10 -0700 on 09/26/2010, Charles Mills wrote about Re: Really 
dumb IPL question:



Would a $VS command in the JESx init deck be a good place to put a start
command for something that probably wants to come up after JES2 and TCP/IP?
What's the formal name for the JESx init deck? Can a $VS command go in what
the JES2 manual calls the "initialization data set"?


The $VS command gets used after JES2 is fully activated. If you need 
TCP/IP to be running before your STC starts then $VS is not an option 
since there is no way to wait for TCP/IP to start and become active. 
Yes that is where you place the command, BTW.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Ted MacNEIL]

>I would prefer to say "put a start command in __ or wherever your shop 
>usually puts start commands that are to execute after blah and blah are up.

You are still missing the point!

>You may use a console automation package to start FOO if your shop normally 
>starts started tasks in this way.

You don't tell them how/why.

Tell them what parms are needed, what form of start, and what must be up.

Let them figure out whether it's, CMD, automation, or manul!

-
I'm a SuperHero with neither powers, nor motivation!
Kimota!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Charles Mills]

Lizette, thanks much.

I will definitely document the specific prerequisites.

> That way I can choose the mechanism

I hear you. Good point. I will definitely not imply "you HAVE to do it this
one particular way."

In my experience some customers will balk if as vendors we just say "take
the necessary steps to have the following happen." We get customers going
"how do we do that?" Don't forget that many large customers (= z/OS
customers LOL) are very fragmented in responsibility. The customer person
who is reading the documentation and evaluating the possibility of a
purchase may not be an expert in every aspect of MVS configuration. At the
very least the product "owner" in the customer shop needs to know who to
call and wants to sound like s/he knows what s/he is talking about when s/he
talks to those crusty old MVS sysprogs (just kidding!).  Rather than saying
"put a start command wherever your shop puts start commands" I would prefer
to say "put a start command in __ or wherever your shop usually puts
start commands that are to execute after blah and blah are up. You may use a
console automation package to start FOO if your shop normally starts started
tasks in this way."

Would a $VS command in the JESx init deck be a good place to put a start
command for something that probably wants to come up after JES2 and TCP/IP?
What's the formal name for the JESx init deck? Can a $VS command go in what
the JES2 manual calls the "initialization data set"?

Thanks again,

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Lizette Koehler
Sent: Sunday, September 26, 2010 3:27 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Really dumb IPL question

It will sometimes depend on Dependencies.

If it requires something like TCPIP to be up before the product FOO.  Then
it needs to be documented that way.

At my shop we use OPS/MVS so I can have things come up where needed in an
IPL.

I do not think you should limit your users to a specific process.

You just need to indicate where it needs to go (after TCPIP is up, After
JES2 is up, before Vtam is up) and let your customers determine how best to
do that.

Many shops today have automation tools, either OPS/MVS, Tivoli, etc...  So
if you restrict your document to say COMMNDxx, or IEACMDxx.  Then your
readers might not realize the tools they have in shop could manage the
startup.

Some shops even use JES parms ($VS in the INIT deck) to kick off tasks after
JES2 is initiated.

As a customer, I prefer a vendor to tell me what has to be up prior to
starting the Task.  That way I can choose the mechanism.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Binyamin Dissen]

On Sun, 26 Sep 2010 15:16:15 -0700 Charles Mills  wrote:

:>I'm writing documentation for a product that a customer would normally run
:>automatically as an STC at every IPL. What do I say in the manual about
:>where to place the START command? Where would this command go? It probably
:>wants to be run fairly late in the IPL after most other subsystems are up.

Which subsystems need be up? Are you sure that they start automatically?

:>Place the command START FOO in _?

:>I'm looking at the documentation for COMMNDxx and IEACMD00 in Init & Tuning.
:>COMMNDxx looks like it gets processed too early in the game and IEACMD00 is
:>documented as being for IBM-supplied commands only but there is no
:>cross-reference to where else to put a START command.

As your command will wait for JES anyway, it does not make that much of a
difference.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[John McKown]

On Sun, 2010-09-26 at 15:16 -0700, Charles Mills wrote:
> Hey, I'm a coder, not a sysprog.
> 
> I'm writing documentation for a product that a customer would normally run
> automatically as an STC at every IPL. What do I say in the manual about
> where to place the START command? Where would this command go? It probably
> wants to be run fairly late in the IPL after most other subsystems are up.
> 
> Place the command START FOO in _?
> 
> I'm looking at the documentation for COMMNDxx and IEACMD00 in Init & Tuning.
> COMMNDxx looks like it gets processed too early in the game and IEACMD00 is
> documented as being for IBM-supplied commands only but there is no
> cross-reference to where else to put a START command.
> 
> Thanks,
> 
> Charles Mills
> 

As Lizette indicated, it depends on dependencies. If your STC only
depends on JES2, then starting it in COMMNDnn works fine. If it depends
on something else being up first (like TCPIP or VTAM or ...), then
document that. In the case of dependencies, you can't really give exact
instructions because different shops have different methods. Even
documenting something simple (such as "You may start our product using
the 'START SPROD' command after you receive the IST020I message which
indicates VTAM is now fully functional.") is suspect because the message
for VTAM might change in some release. 

In our shop, we start a few things in COMMND00. The main thing is CA's
CAS9. CAS9 has an parameter to do other z/OS commands after it is up. We
use that to start CA-OPS/MVS. We use OPS/MVS to start JES2. We have an
OPS rule that is triggered from the appropriate JES2 message
(initialization complete) to do a number of other START commands. Such
as for VTAM. We then have a rule with looks for the VTAM Initialization
is complete message to start TCPIP. And we have OPS rules to look for
the TCPIP initialization complete messages to start even more stuff. I
have a very complicated diagram (made with a "mind mapping" software
tool on Linux) to document it in a fairly useful visual form.

-- 
John McKown
Maranatha! <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Really dumb IPL question

[Lizette Koehler]

> Hey, I'm a coder, not a sysprog.
> 
> I'm writing documentation for a product that a customer would normally
> run
> automatically as an STC at every IPL. What do I say in the manual about
> where to place the START command? Where would this command go? It
> probably
> wants to be run fairly late in the IPL after most other subsystems are
> up.
> 
> Place the command START FOO in _?
> 
> I'm looking at the documentation for COMMNDxx and IEACMD00 in Init &
> Tuning.
> COMMNDxx looks like it gets processed too early in the game and
> IEACMD00 is
> documented as being for IBM-supplied commands only but there is no
> cross-reference to where else to put a START command.
> 

Charles, 

It will sometimes depend on Dependencies.

If it requires something like TCPIP to be up before the product FOO.  Then
it needs to be documented that way.

At my shop we use OPS/MVS so I can have things come up where needed in an
IPL.

I do not think you should limit your users to a specific process.

You just need to indicate where it needs to go (after TCPIP is up, After
JES2 is up, before Vtam is up) and let your customers determine how best to
do that.

Many shops today have automation tools, either OPS/MVS, Tivoli, etc...  So
if you restrict your document to say COMMNDxx, or IEACMDxx.  Then your
readers might not realize the tools they have in shop could manage the
startup.

Some shops even use JES parms ($VS in the INIT deck) to kick off tasks after
JES2 is initiated.

As a customer, I prefer a vendor to tell me what has to be up prior to
starting the Task.  That way I can choose the mechanism.

Lizette

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html