date:20121205

Peter, thanks, this is pretty much what I am looking for.

Perhaps (thinking of the other responses) I was not sufficiently clear. I am
not trying to write an encapsulated function which is guaranteed to solve
this problem for any case. I have a particular program that may need to
behave differently if it was invoked by "X" as opposed to under all other
circumstances; or perhaps needs to behave differently if it was loaded by
"something else" as opposed to being the jobstep program.

Does JSCBPGMN = "me"? Does JSCBPGMN = "X"? The answers to those questions
are probably all I need.

Thanks much.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, December 05, 2012 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

JSCBPGMN is the "job step program name". If the question is is "am I a
program whose name matches the job step program name" then that field can be
used to answer. Note that I intentionally did not say "am I the program"
because that can be very very hard to determine, if there are multiple
programs with the same name that are available to be fetched.

Most (intended) started tasks do, for example, for system integrity reasons,
check "was I started as a started task" and if not they exit because they
are being invoked in an unexpected and unsupported (and potentially
malicious) environment . That can be determined using EXTRACT and COMCIBPT
and CIBVERB=X'04' .

If you were linked to or attached there is information via the RB chain and
RBCDE (not a programming interface) which (potentially) locates a CDE or
LPDE which will have a program name.

As mentioned, if you were load'd and call'd, there are no programming
interfaces that will tell you "who loaded". 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

On Dec 5, 2012, at 05:32, Martin, Larry D wrote:
> 
> I believe the reason for the "Start in order to Stop" process is required in 
> order to stop Unix Daemons that are running as a part of the process.  I 
> agree that the code to handle STOP and MODIFY commands is quite simple, but I 
> don't have any experience starting and stopping Daemons.
>  
The UNIX analogue is "kill" which sends any of several signals
to a process.  For example, SIGINT tells processes designed to
handle it to prompt or seek additional command information
elsewhere.  SIGTERM warns a process of imminent system shutdown;
I believe that in the spirit of POSIX, z/OS shutdown should send
SIGTERM to dubbed tasks; others reading this will feel strongly
otherwise.  SIGINT and SIGTERM are fatal if not handled.  SIGKILL
is unconditionally fatal (think FORCE, but not so destructive).
SIGHUP (HangUP) tells a process that its controlling terminal
has been disconnected.  Etc.  A couple signals are reserved for
user/ISV definition in any supplied application; often used for
debugging.

How does STOP work?  Is MODIFY similar?  Does either schedule
an RB to a task?  What happens if that task is not prepared to
deal with such an RB?  Which is older, STOP or MODIFY?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

IMO, the "proper" way to stop a UNIX daemon is to use the "kill" command. 
That's generally how it is done in Linux, at least. The daemon normally keeps 
its PID in a known location, such as /var/run/daemon.pid. The normal way to 
stop it is to have a root user (or setuid program) issue something like: kill 
-TERM $(cat /var/run/daemon.pid). The signal (-TERM) can often be used to send 
a generic message to the daemon. a -HUP is sometimes used to shut down, but 
other daemons use -HUP to say "read your startup configuration file again for 
changes and implement those changes". 


Note, that with z/OS UNIX, daemons can use the normal START, STOP, and MODIFY 
command interface (or even "hang a WTOR" ). It is just very unusual 
for them to do so because most are "ports" from UNIX systems which don't have 
those capabilities.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Martin, Larry D
> Sent: Wednesday, December 05, 2012 6:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> Tim,
> 
> I believe the reason for the "Start in order to Stop" process is
> required in order to stop Unix Daemons that are running as a part of
> the process.  I agree that the code to handle STOP and MODIFY commands
> is quite simple, but I don't have any experience starting and stopping
> Daemons.
> 
> ..Larry
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tim Hare
> Sent: Tuesday, December 04, 2012 4:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Historical question regarding the stop command
> 
> I'm sure this has been asked and answered somewhere in the dusty
> archives of this list, but I honestly couldn't figure out a way to
> formulate a search for it that would return mostly useful
> information
> 
> Does anyone know the historical/technical reason for some products, (at
> our shop CA-Datacom and possibly SAS SHARe) requiring you to START a
> task, to STOP their started task?   I know it's ridiculous of me but it
> drives me nuts to have to start something when I want to stop something
> else.
> 
> I've written code of my own which handles the STOP and MODIFY commands,
> so I know that it's not extremely difficult;  it's pretty well
> documented in the manuals too if I recall.   I wrote the code years
> ago, so it's not like the ability just became available, either.
> 
> So - anyone know why this particular technique is used?  Is there some
> technical reason for it?
> 
> Thanks for any and all information and/or entertainment your answers
> will provide...
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> This E-mail and any of its attachments may contain Prince George’s
> County Government or Prince George's County 7th Judicial Circuit Court
> proprietary information or Protected Health Information, which is
> privileged and confidential.  This E-mail is intended solely for the
> use of the individual or entity to which it is addressed.  If you are
> not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation
> to the contents of and attachments to this E-mail is strictly
> prohibited by federal law and may expose you to civil and/or criminal
> penalties. If you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

2012-12-05 Thread Peter Relson

All of PLPA is by definition refreshable. It implements exactly what 
refreshable means -- the storage might be "refreshed" (from its original 
state) at any point the system deems it appropriate to do so.

If a page backing a PLPA is stolen, it is not at that point written to aux 
storage; writing of all LPA to aux was done during IPL (or a previous IPL 
possibly). When that page is needed, it is gotten from that 
previously-captured aux storage.

This is the only part of the operating system that performs something akin 
to "refresh" for modules. You might view some control block refresh from a 
page-protected copy as refresh of data areas.
Beyond that, to z/OS, refresh has meaning only to DIAGxx processing where 
you can ask, for testing purposes, that refreshable modules be 
page-protected. You cannot write into a refreshable module and get lasting 
results (as it might be refreshed at any time), so this is intended to 
stop even key 0 from incorrectly writing into it. Yes, I know that an 
authorized program can accomplish writing into the module by undoing the 
page protection, or by using stores using real address.

So the question about refreshable modules is kind of moot. Or I am not 
understanding the intent. You can share modules by having them in common 
storage. RLDs are resolved at fetch time. End of story.

>Is there a service that will tell a priori the storage requirement of a
>load module, or must the programmer simply overrequest; LOAD, and
>free the excess?
BLDL or DESERV, to access the directory entry, as Binyamin wrote. Within 
there is the information about the length. You use that information to 
obtain the storage. You then do a LOAD with ADDR and DE. 

>Is there any prospect of above-the-bar LPA?  1.13 allows execution above-
>the-bar (with severe restrictions), and there should be no obstacle to
>keeping data above-the-bar beyond mere 64-bit savvy of the users.

There is always a "prospect", but there is no current "likelihood". The 
"obstacle" is the cost to resolve the "severe restrictions" you rightly 
mention. It doesn't do any good to put code above the bar that wants to 
run but cannot meet the "severe restrictions". It is already supported 
(z/OS 1.11) to do a LOAD with ADDR64 to an area above the bar for 
non-executable code if you have a data table module that you know can be 
above the bar (it better not have any 4-byte relocatable adcon's).

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CHPID TYPE OSE Port 1 of OSA Express3

2012-12-05 Thread Rebecca Martin

We have not resolved the problem yet - waiting for change control process.  We 
do now understand the problem.  The problem is because the OSA cards do not 
come with a default OAT that includes port 1.  To use PORT 1 for LCS you must 
use OSA/SF to complete the configuration.  There are 2 changes required: 1 - to 
the CONFIG we need to add a port name and use that same port name in the TCPIP 
LINK statements in our PROFILE, 2 - modify the OAT to include definitions for 
port 1. 

The hardware definitions I modifed on Monday, it appears, will work.  Adding 
the device with UA of FE and type OSAD was needed to use the OSA/SF facility.  
With the OSA/SF I was able to do a GET_CONFIG and GET_OAT for each of the 
CHPIDs.  The required changes are staged and ready to be loaded.  As soon as 
change control is approved and an approriate time for the change agreed upon, I 
think it will work.  

We previously had never needed to use OSA/SF and that is why our initial 
configuration didn't include a device with UA of FE and type OSAD.

Thank you all for your input.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Correlating workstation userid to TN3270 logon using client certificates

2012-12-05 Thread Tom Ambros

This is what I was thinking.   I believe I can require my admin users to 
use a particular port on the TN3270 server task and assign a unique set of 
LUs that way.  Non-admin users would not have access to that port.  If a 
user connects to the open port, they would wind up with an LU that would 
not be eligible for admin sign-on, so a non-admin user that somehow gets 
an admin's RACF userid and password would not get anywhere easily.  The 
sticky part is finding that LU for the RACF exit.   We'll see how that 
goes. 

Express Logon Feature is attractive, if I can't manage what I'm thinking, 
what I'd need to be able to do is require the function for admin users, so 
they'd have to pass a cert to log on and knowing the RACF password 
wouldn't get it done. 

Then there are all the operational issues, such as how to grant access 
when my brilliant schemes break. 

Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433





From:   Charles Mills 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/04/2012 17:27
Subject:Re: Correlating workstation userid to TN3270 logon using 
client certificates
Sent by:IBM Mainframe Discussion List 



I am not an expert on your exact question but I have done a lot with SSL
certificates and with SMF data from RACF and from TCP/IP. I think RACF is
pretty far removed from your TCP/IP sign-on, because TN3270 sits in the
middle. As far as RACF is concerned, your client didn't sign on, a virtual
terminal owned by TN3270 signed on.

You would have to capture it from TCP/IP somehow and hand it off to your
RACF exit.

Not an entire answer, but I hope this helps.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Ambros
Sent: Tuesday, December 04, 2012 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Correlating workstation userid to TN3270 logon using client
certificates

I apologize if this has been covered already, but I probably need to tell
somebody if this can be done before I read up and put the pieces together. 



If I have an SSL-capable emulator, is it possible to validate the client 
certificate and extract the userid (this part, at least, I know can be 
done) and somehow persistently store it so that  the RACF logon exits can 
locate it and verify that the userid entered at the application logon 
screen is the same userid that was presented in the client certificate? 

There are two factor authentication products that work at RACF logon but 
they have their drawbacks, we're musing about the possibility of fitting 
in with some of the distributed schemes for consistency's sake and closing 

the gap where one can get on a workstation with one set of credentials and 

then use another set that fell off the back of a truck to have a good old 
time in ways that may be distasteful to some.   The distributed schemes 
involve seemingly robust what I have and what I know type processes and if 

we can then implement something reasonably inobtrusive on zOS we'd be in 
better shape. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

To my remembrance, START, STOP, and MODIFY we all original commands in OS/360 
(I can be wrong, I don't go back that far). They do not do asynchronous 
functions like "kill" does. They basically post an ECB. It is up to the program 
to periodically query this ECB (see the QEDIT macro). That's why entering a 
STOP command doesn't always STOP a broken STC. You can even STOP a batch job 
step. If the program is proper set up, it will process the STOP request and 
terminate. I don't know about today's environment, but in the past, if you did 
this and the program didn't remove the STOP request from the queue but 
terminated instead, then the initiator would see the STOP and it would shut 
down. This was many years ago, so it may not do this anymore.

BTW, did you know that a TSO user's address space will honor a STOP command? 
But ISPF doesn't. So, in the old days, an operator could "P tsoid" and the 
user's TSO session would terminate when they next went to the READY prompt, 
usually at the end of a command. Since, to TSO, ISPF is basically a 
never-ending command, the P doesn't have much effect any more.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, December 05, 2012 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> On Dec 5, 2012, at 05:32, Martin, Larry D wrote:
> >
> > I believe the reason for the "Start in order to Stop" process is
> required in order to stop Unix Daemons that are running as a part of
> the process.  I agree that the code to handle STOP and MODIFY commands
> is quite simple, but I don't have any experience starting and stopping
> Daemons.
> >
> The UNIX analogue is "kill" which sends any of several signals to a
> process.  For example, SIGINT tells processes designed to handle it to
> prompt or seek additional command information elsewhere.  SIGTERM warns
> a process of imminent system shutdown; I believe that in the spirit of
> POSIX, z/OS shutdown should send SIGTERM to dubbed tasks; others
> reading this will feel strongly otherwise.  SIGINT and SIGTERM are
> fatal if not handled.  SIGKILL is unconditionally fatal (think FORCE,
> but not so destructive).
> SIGHUP (HangUP) tells a process that its controlling terminal has been
> disconnected.  Etc.  A couple signals are reserved for user/ISV
> definition in any supplied application; often used for debugging.
> 
> How does STOP work?  Is MODIFY similar?  Does either schedule an RB to
> a task?  What happens if that task is not prepared to deal with such an
> RB?  Which is older, STOP or MODIFY?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread Glenn Wilcock

No.  You should not attempt to start two distinct HSMs within the same LPAR.  
Multiple HSMs within the same LPAR are only supported when they share the same 
control data sets and the secondary hosts are started with the HOSTMODE=AUX 
parameter.  A good example of why you can't have distinct HSMs is Recall.  HSM 
intercepts Open requests for migrated data sets and recalls them.  You can't 
have two distinct HSMs fighting over a Recall.  That is just one issue of many 
(serialization on functions & data sets, other intercepts, etc)

Glenn Wilcock
DFSMShsm Architect

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

Peter Relson writes:


It is already supported (z/OS 1.11) to do a LOAD with ADDR64 to an
area above the bar for non-executable code if you have a data table
module that you know can be above the bar (it better not have any
4-byte relocatable adcon's).


A number of the tables that I routinely LOAD above the bar are
compound ones comprised of several atomic tables, not all of which are
always present.  The compound table's stub thus contains pointers to
these atomic tables, and some of these pointers are sometimes nul.

All of this now works for me after much less travail than I had expected.

I would rephrase Peter's formulation,

"(it better not have any 4-byte relocatable adcon's)",

slightly, changing it to

"it better be AMODE(64)".

His point is in a certain sense, or at least ought to be, obvious; but
that does not make it less important.  Students, mine anyway, often
fail to understand that AMODE is relevant for tables too.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

2012-12-05 Thread Bill Fairchild

There is also much discussion of this same topic in the IBM-MAIN archives, q. v.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, December 05, 2012 7:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Peter, thanks, this is pretty much what I am looking for.

Perhaps (thinking of the other responses) I was not sufficiently clear. I am 
not trying to write an encapsulated function which is guaranteed to solve this 
problem for any case. I have a particular program that may need to behave 
differently if it was invoked by "X" as opposed to under all other 
circumstances; or perhaps needs to behave differently if it was loaded by 
"something else" as opposed to being the jobstep program.

Does JSCBPGMN = "me"? Does JSCBPGMN = "X"? The answers to those questions are 
probably all I need.

Thanks much.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Wednesday, December 05, 2012 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

JSCBPGMN is the "job step program name". If the question is is "am I a program 
whose name matches the job step program name" then that field can be used to 
answer. Note that I intentionally did not say "am I the program"
because that can be very very hard to determine, if there are multiple programs 
with the same name that are available to be fetched.

Most (intended) started tasks do, for example, for system integrity reasons, 
check "was I started as a started task" and if not they exit because they are 
being invoked in an unexpected and unsupported (and potentially
malicious) environment . That can be determined using EXTRACT and COMCIBPT and 
CIBVERB=X'04' .

If you were linked to or attached there is information via the RB chain and 
RBCDE (not a programming interface) which (potentially) locates a CDE or LPDE 
which will have a program name.

As mentioned, if you were load'd and call'd, there are no programming 
interfaces that will tell you "who loaded". 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OT: Hum, MS raising prices?

2012-12-05 Thread zMan

On Tue, Dec 4, 2012 at 9:16 PM, Clark Morris wrote:

> On 4 Dec 2012 10:10:42 -0800, in bit.listserv.ibm-main you wrote:
> >I meant "legal code". My English is poor, especially in non-IT areas.
>
> In general, your written English seems as least as good as mine
> (unfortunately maybe better since my only language is United States
> English - no snide comments from the Commonwealth please).


Indeed. This wasn't a case of poor English -- it was a case of English
being poor. What he wrote was grammatical and clear, just ambiguous, due to
English lack of inflection!
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

On Wed, 5 Dec 2012 09:31:03 -0500, John Gilmore wrote:
>
>I would rephrase Peter's formulation,
>
>"(it better not have any 4-byte relocatable adcon's)",
>
>slightly, changing it to
>
>"it better be AMODE(64)".
>
>His point is in a certain sense, or at least ought to be, obvious; but
>that does not make it less important.  Students, mine anyway, often
>fail to understand that AMODE is relevant for tables too.
> 
Are you saying that of a 64-bit ADCON in a module loaded above the bar,
only the lower 32 bits will be properly relocated unless the CSECT is
declared AMODE(64)?  Ouch!  Is even a warning issued?

Do the declared AMODE and RMODE affect the format of RLD entries
output by the assembler?  How does this affect compatibility with
older products, evel HEWLKED?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

BCPII question

2012-12-05 Thread ralf . zantopp

Hi all,

I've developed a Assembler programs to change the system config via BCPII
Interface.

At the moment I'm able to query/change the weights, defined capacity,
IRD-Management, Group-Capacity and some other fields.

Now I try to activate OOCoD Records (perfom model conversation) but I can't
find the information how to set a specific model, e.g going from Model 719
to 720 and back. The HWISET macro does not support the function and the
HWICMD macro seems to support only the activation of the complete OOCoD
record.

Has somebody tried this and can give me a hint where to find the info? I'm
running on z/OS 1.13 and the callable service book I used is SA22-7613-10
date 04/2012.

Thanks in advance

Ralf

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

Paul,

I cannot answer your questions because I have never tried to put
something above the bar that was not AMODE(64).  Moreover, I do not
recommend atrempting to do so.  I will, however, conduct some
experiments over the coming weekend and post the results I get.

I do have a more general comment.

Bertrand Russell observed long ago that

No one can understand the word 'cheese' unless he has a non-linguistic
acquaintance with cheese.

What is going on above the bar is in some ways quite
different---cleaner, neater, simpler---than what we are used to.   Get
some first-hand experience with it.  That experience will inform and
change your comments.

I have been guilty of poking fun at some of the terminology used above
the bar, but that should not be misunderstood.  I would have named
some things differently, but I have nothing but praise for the quality
of the things themselves.  In particular, they cohere unexpectedly
well, making mostly reliable inferences about their behavior easy.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread Lizette Koehler

Glenn,

Is there any safe way to test HSM exits without having a TEST LPAR?  So if I 
only had an LPAR but needed to validate my code for an HSM Exit, any way to do 
that safely?  Or would it be safer to bring up a new sysres set with the exits? 
 Or a new LPAR for testing?

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf
> Of Glenn Wilcock
> 
> No.  You should not attempt to start two distinct HSMs within the same LPAR.  
> Multiple
> HSMs within the same LPAR are only supported when they share the same control 
> data
> sets and the secondary hosts are started with the HOSTMODE=AUX parameter.  A
> good example of why you can't have distinct HSMs is Recall.  HSM intercepts 
> Open
> requests for migrated data sets and recalls them.  You can't have two 
> distinct HSMs
> fighting over a Recall.  That is just one issue of many (serialization on 
> functions & data
> sets, other intercepts, etc)
> 
> Glenn Wilcock
> DFSMShsm Architect
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Correlating workstation userid to TN3270 logon using client certificates

2012-12-05 Thread Joel C. Ewing

Although I have only used RACF TERMINAL profiles for userid/password 
logon control, I believe they would equally apply to any logon, 
including one using client certificates.


If you can restrict your admin users to specific set of LU names with a 
unique naming convention, then you don't need an exit to restrict those 
users to logging on with that set of LU's, just use the RACF TERMINAL 
class and generic profiles in that class.  Let most users logon via 
arbitrary LU's via access to TERMUACC, and be sure you have generic 
profiles covering all their allowed LU's with READ UACC allowed.  
Connect the admin users to RACF group without TERMUACC, insure that the 
TERMINAL profile covering their special LU names does not have READ UACC 
and that READ access is only explicitly granted to RACF group(s) 
associated with admins or to specific admin userids.  Then admin userids 
will only be able to logon to a 3270 session when the request is 
associated with their specific set of LU's.The same profile class 
also restricts logons in the TCP/IP environment (e.g., FTP servers etc.) 
using a hex representation of the IP address as the terminal name.  Be 
sure you have enough generic profiles to cover everything of interest 
and allow existing default logon behavior before activating the TERMINAL 
class, or you may suddenly have all sorts of unexpected logon failures.


It is useful, if you want to restrict certain user logons to specific 
subset of physical sites, to have the IP Address assignments of those 
sites restricted  to known IP ranges or subnets.Then TCP/IP logons 
can use  generic TERMINAL profiles covering those IP ranges to control 
TCP/IP logons from userIDs that should either be restricted to or 
disallowed from those locations, and TN3270 can then be configured to 
map IP addresses in those ranges to uniquely-named LU's for that 
location  so that similar controls can be  imposed on 3270 logons in the 
VTAM environment that originate from those locations.


As with anything affecting logon ability, proceed with caution. If RACF 
changes prevent future logons from RACF SPECIAL users, then you may be SOL.

  Joel C. Ewing

On 12/05/2012 08:01 AM, Tom Ambros wrote:

This is what I was thinking.   I believe I can require my admin users to
use a particular port on the TN3270 server task and assign a unique set of
LUs that way.  Non-admin users would not have access to that port.  If a
user connects to the open port, they would wind up with an LU that would
not be eligible for admin sign-on, so a non-admin user that somehow gets
an admin's RACF userid and password would not get anywhere easily.  The
sticky part is finding that LU for the RACF exit.   We'll see how that
goes.

Express Logon Feature is attractive, if I can't manage what I'm thinking,
what I'd need to be able to do is require the function for admin users, so
they'd have to pass a cert to log on and knowing the RACF password
wouldn't get it done.

Then there are all the operational issues, such as how to grant access
when my brilliant schemes break.

Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433





From:   Charles Mills 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/04/2012 17:27
Subject:Re: Correlating workstation userid to TN3270 logon using
client certificates
Sent by:IBM Mainframe Discussion List 



I am not an expert on your exact question but I have done a lot with SSL
certificates and with SMF data from RACF and from TCP/IP. I think RACF is
pretty far removed from your TCP/IP sign-on, because TN3270 sits in the
middle. As far as RACF is concerned, your client didn't sign on, a virtual
terminal owned by TN3270 signed on.

You would have to capture it from TCP/IP somehow and hand it off to your
RACF exit.

Not an entire answer, but I hope this helps.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Ambros
Sent: Tuesday, December 04, 2012 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Correlating workstation userid to TN3270 logon using client
certificates

I apologize if this has been covered already, but I probably need to tell
somebody if this can be done before I read up and put the pieces together.



If I have an SSL-capable emulator, is it possible to validate the client
certificate and extract the userid (this part, at least, I know can be
done) and somehow persistently store it so that  the RACF logon exits can
locate it and verify that the userid entered at the application logon
screen is the same userid that was presented in the client certificate?

There are two factor authentication products that work at RACF logon but
they have their drawbacks, we're musing about the possibility of fitting
in with some of the distributed schemes for consistency's sake and closing

the gap where one can get on a workstation with one set of credentials and

then use another set that fell off the back of a truck to h

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread O'Brien, David W. (NIH/CIT) [C]

Lizette,

Is Setsys debug what you're looking for?

Setsys debug
Enable exits to test
Test function using exits
Disable exits
Setsys nodebug

Release Hardcopy
Examine activity logs for the effects of testing exits.

No need for a second HSM.

-Original Message-
From: Lizette Koehler [mailto:stars...@mindspring.com] 
Sent: Wednesday, December 05, 2012 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multiple HSM in one LPAR ?

Glenn,

Is there any safe way to test HSM exits without having a TEST LPAR?  So if I 
only had an LPAR but needed to validate my code for an HSM Exit, any way to do 
that safely?  Or would it be safer to bring up a new sysres set with the exits? 
 Or a new LPAR for testing?

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Glenn Wilcock
> 
> No.  You should not attempt to start two distinct HSMs within the same 
> LPAR.  Multiple HSMs within the same LPAR are only supported when they 
> share the same control data sets and the secondary hosts are started 
> with the HOSTMODE=AUX parameter.  A good example of why you can't have 
> distinct HSMs is Recall.  HSM intercepts Open requests for migrated 
> data sets and recalls them.  You can't have two distinct HSMs fighting 
> over a Recall.  That is just one issue of many (serialization on 
> functions & data sets, other intercepts, etc)
> 
> Glenn Wilcock
> DFSMShsm Architect
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Bill Fairchild is guilty of meiosis, the antonym of hyperbole.  There
is very much too much discussion of this topic in the archives.

It is of course possible to get answers to carefully circumscribed
special cases of this question of the sort Charles Mills is seeking.
There are no general/generic answers to it, and the prospects for one
are bleak.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread Lizette Koehler

That was what Miklos Szigetvari asked originally.  I was just trying to get an 
answer for him

Lizette

> 
> Lizette,
> 
> Is Setsys debug what you're looking for?
> 
> Setsys debug
> Enable exits to test
> Test function using exits
> Disable exits
> Setsys nodebug
> 
> Release Hardcopy
> Examine activity logs for the effects of testing exits.
> 
> No need for a second HSM.
> 
> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Wednesday, December 05, 2012 10:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Multiple HSM in one LPAR ?
> 
> Glenn,
> 
> Is there any safe way to test HSM exits without having a TEST LPAR?  So if I 
> only had
> an LPAR but needed to validate my code for an HSM Exit, any way to do that 
> safely?
> Or would it be safer to bring up a new sysres set with the exits?  Or a new 
> LPAR for
> testing?
> 
> Thanks
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Glenn Wilcock
> >
> > No.  You should not attempt to start two distinct HSMs within the same
> > LPAR.  Multiple HSMs within the same LPAR are only supported when they
> > share the same control data sets and the secondary hosts are started
> > with the HOSTMODE=AUX parameter.  A good example of why you can't have
> > distinct HSMs is Recall.  HSM intercepts Open requests for migrated
> > data sets and recalls them.  You can't have two distinct HSMs fighting
> > over a Recall.  That is just one issue of many (serialization on
> > functions & data sets, other intercepts, etc)
> >
> > Glenn Wilcock
> > DFSMShsm Architect
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

On Wed, 5 Dec 2012 10:16:46 -0500, John Gilmore wrote:
>
>I have been guilty of poking fun at some of the terminology used above
>the bar, but that should not be misunderstood.  I would have named
>some things differently, but I have nothing but praise for the quality
>of the things themselves.  In particular, they cohere unexpectedly
>well, making mostly reliable inferences about their behavior easy.
> 
It appears that the designers have learned well from experience.  I
enthusiastically await the day when the bar is erased and programmers
can code entirely RMODE(64), oblivious to any antiquated 31-bit
and 24-bit constraints.  (Yes; imagine 64-bit addressability to PARM.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

> How does STOP work?  

>From a programmer's point of view, it sets a flag and posts an ECB.

> Is MODIFY similar?  

Yes, both are quite similar in how they work. Modify is a flag plus the text
of the command. AFAIR Stop is just a flag, but I might well be wrong and I
am too lazy to look it up right now.

> Does either schedule an RB to a task?  

Don't think so, but not sure.

> What happens if that task is not prepared to deal with such an RB?  

z/OS "knows" whether a program has gone through the motions of telling z/OS
it was prepared to accept console commands. If not, z/OS rejects the
command. If the program tells z/OS it can process commands but fails to do
so, then the command "just sits there." z/OS knows how many "stacked"
un-processed commands a program can accept -- one, for any program I have
ever written -- and rejects new commands in excess of that.

> Which is older, STOP or MODIFY?

Well, both are in the 1968 manual I cited earlier in this thread. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Wednesday, December 05, 2012 5:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Historical question regarding the stop command

On Dec 5, 2012, at 05:32, Martin, Larry D wrote:
> 
> I believe the reason for the "Start in order to Stop" process is required
in order to stop Unix Daemons that are running as a part of the process.  I
agree that the code to handle STOP and MODIFY commands is quite simple, but
I don't have any experience starting and stopping Daemons.
>  
The UNIX analogue is "kill" which sends any of several signals to a process.
For example, SIGINT tells processes designed to handle it to prompt or seek
additional command information elsewhere.  SIGTERM warns a process of
imminent system shutdown; I believe that in the spirit of POSIX, z/OS
shutdown should send SIGTERM to dubbed tasks; others reading this will feel
strongly otherwise.  SIGINT and SIGTERM are fatal if not handled.  SIGKILL
is unconditionally fatal (think FORCE, but not so destructive).
SIGHUP (HangUP) tells a process that its controlling terminal has been
disconnected.  Etc.  A couple signals are reserved for user/ISV definition
in any supplied application; often used for debugging.

How does STOP work?  Is MODIFY similar?  Does either schedule an RB to a
task?  What happens if that task is not prepared to deal with such an RB?
Which is older, STOP or MODIFY?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread O'Brien, David W. (NIH/CIT) [C]

Hopefully he is still monitoring the thread.

-Original Message-
From: Lizette Koehler [mailto:stars...@mindspring.com] 
Sent: Wednesday, December 05, 2012 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Multiple HSM in one LPAR ?

That was what Miklos Szigetvari asked originally.  I was just trying to get an 
answer for him

Lizette

> 
> Lizette,
> 
> Is Setsys debug what you're looking for?
> 
> Setsys debug
> Enable exits to test
> Test function using exits
> Disable exits
> Setsys nodebug
> 
> Release Hardcopy
> Examine activity logs for the effects of testing exits.
> 
> No need for a second HSM.
> 
> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Wednesday, December 05, 2012 10:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Multiple HSM in one LPAR ?
> 
> Glenn,
> 
> Is there any safe way to test HSM exits without having a TEST LPAR?  
> So if I only had an LPAR but needed to validate my code for an HSM Exit, any 
> way to do that safely?
> Or would it be safer to bring up a new sysres set with the exits?  Or 
> a new LPAR for testing?
> 
> Thanks
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Glenn Wilcock
> >
> > No.  You should not attempt to start two distinct HSMs within the 
> > same LPAR.  Multiple HSMs within the same LPAR are only supported 
> > when they share the same control data sets and the secondary hosts 
> > are started with the HOSTMODE=AUX parameter.  A good example of why 
> > you can't have distinct HSMs is Recall.  HSM intercepts Open 
> > requests for migrated data sets and recalls them.  You can't have 
> > two distinct HSMs fighting over a Recall.  That is just one issue of 
> > many (serialization on functions & data sets, other intercepts, etc)
> >
> > Glenn Wilcock
> > DFSMShsm Architect
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Thanks, John.

It is so easy and facile to say "RTFM."

Yeah, sure, it's in the archives. So is everything else.

When I lived in NYC in the sixties, I had a friend who had this idea of
selling the police "a list of everyone in Manhattan who smoked dope." It was
the Manhattan phone book.

I have a program that will tell you anyone's RACF password. It's a random
password generator. If you click it enough times it will generate the
password you are looking for.

RTFM is an appropriate response in many cases, but it is vastly overused as
a smug put-down. If a friend asked you what time it was, would you tell him
there was a clock in a room down the hall, or would you look at your wrist
and tell him the damned time?

I suspected someone would know the answer to my fairly simple question of
the top of their heads, and I was right, Peter Relson did. If you don't have
an easy answer off the top of your head, or you're too busy to respond, you
are free to ignore a question. Put-downs are not necessary.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, December 05, 2012 7:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Bill Fairchild is guilty of meiosis, the antonym of hyperbole.  There is
very much too much discussion of this topic in the archives.

It is of course possible to get answers to carefully circumscribed special
cases of this question of the sort Charles Mills is seeking.
There are no general/generic answers to it, and the prospects for one are
bleak.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

On Wed, 5 Dec 2012 08:03:16 -0800, Charles Mills wrote:

>> How does STOP work?
>
>From a programmer's point of view, it sets a flag and posts an ECB.
>
>> Is MODIFY similar?
>
>Yes, both are quite similar in how they work. Modify is a flag plus the text
>of the command. AFAIR Stop is just a flag, but I might well be wrong and I
>am too lazy to look it up right now.
> 
Same ECB or different ECB?  Or does the flag indicate whether the operation
was STOP, MODIFY, or ... (What else?)

>z/OS "knows" whether a program has gone through the motions of telling z/OS
>it was prepared to accept console commands. ...
>
May I assume that "telling" includes providing z/OS with the address of the 
ECB(s)?

Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

> May I assume that "telling" includes providing z/OS with the address of the 
> ECB(s)?

Asking, actually, LOL.

*--*
* OBTAIN ADDRESS OF THE CIB *
* From z/OS V1R10.0 MVS Authorized Assembler Services Guide p. 2-4
*--*
*
*  Now see if have a CIB
 EXTRACT COMADDR,FIELDS=COMM,MF=(E,EXTRACTL)
 L R8,COMADDR  GET ADDRESS OF THE AREA
 USING COM,R8  USE R8 AS BASE ADDRESS OF COMM AREA
*
*  Pick up ECB address out of the COM
 L R0,COMECBPT
 STR0,ECBLISTC Store in ECB list
*
*  Use QEDIT to set MODIFY count to one
 QEDIT ORIGIN=COMCIBPT,CIBCTR=1

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 05, 2012 9:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Historical question regarding the stop command

On Wed, 5 Dec 2012 08:03:16 -0800, Charles Mills wrote:

>> How does STOP work?
>
>From a programmer's point of view, it sets a flag and posts an ECB.
>
>> Is MODIFY similar?
>
>Yes, both are quite similar in how they work. Modify is a flag plus the 
>text of the command. AFAIR Stop is just a flag, but I might well be 
>wrong and I am too lazy to look it up right now.
> 
Same ECB or different ECB?  Or does the flag indicate whether the operation was 
STOP, MODIFY, or ... (What else?)

>z/OS "knows" whether a program has gone through the motions of telling 
>z/OS it was prepared to accept console commands. ...
>
May I assume that "telling" includes providing z/OS with the address of the 
ECB(s)?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CHPID TYPE OSE Port 1 of OSA Express3

2012-12-05 Thread Chris Mason

Rebecca

> For the OSE cards, when TCP/IP is started, it uses the information in the 
> TCP/IP profile to load the port with IP address, etc, that the port needs to 
> connect to the network.

No. You or your "hardware vendor" - wouldn't that be IBM or has the world 
become more complicated with more people skimming the milk since I retreated 
from the grindstone? - are confusing QDIO and non-QDIO. Try this section from 
the zEnterprise 196, System z10, System z9 and eServer zSeries Open Systems 
Adapter-Express Customer's Guide and Reference:

1.1.8.1 ARP Takeover

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ioa2z180/1.1.8.1

-

Well, I'm glad you have got your OSA-Express3 feature working. When I last 
worked with OSE 12 years ago with OSA-2 features, setting up OSA/SF and then 
configuring with OSA/SF appeared to be mandatory - but maybe that's because I 
was concentrating on SNA use. Even since then when I have concentrated on OSD 
(QDIO) I have emphasised setting up OSA/SF in order to be able to "see" the OSA 
Address Table.

-

Incidentally, when you finally start using OSD rather than OSE, you should use 
the IBMTCP-L list for any topic related to z/OS Communications Server and 
neighbouring topics such as OSA features:

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L

Chris Mason

On Mon, 3 Dec 2012 09:54:39 -0600, Rebecca Martin  
wrote:

>FYI - Looks like our hardware vendor has found the answer (I'll know for sure 
>a bit later on):
>
>After spending a while researching and thinking about the OSA problem, here's 
>what I think it is.
>For the OSE cards, when TCP/IP is started, it uses the information in the 
>TCP/IP profile to load the port with IP address, etc, that the port needs to 
>connect to the network.   The default configuration that gets loaded onto the 
>OSE chpids during POR has entries for unitadd 00 and 01, which makes the port 
>0 connections work.  For port 1 the definitions are unitadd 10 and 11 for FC40 
>and FC10.  Those unitadds do not get set up right in the card's default 
>configuration.
>
>Here's the fix :
>In HCD, add a device definition for a device type OSAD at unitadd FE to each 
>of the OSE chpids, like the following:
>CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
>IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA 
>IODEVICE ADDRESS=FCFE,UNITADD=FE,CUNUMBR=FC00),UNIT=OSAD   <--
> 
>CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA  
>IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA 
>IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA
>IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=FC20),UNIT=OSAD
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Binyamin Dissen

On Wed, 5 Dec 2012 11:02:26 -0600 Paul Gilmartin  wrote:

:>On Wed, 5 Dec 2012 08:03:16 -0800, Charles Mills wrote:
:>
:>>> How does STOP work?

:>>From a programmer's point of view, it sets a flag and posts an ECB.

:>>> Is MODIFY similar?

:>>Yes, both are quite similar in how they work. Modify is a flag plus the text
:>>of the command. AFAIR Stop is just a flag, but I might well be wrong and I
:>>am too lazy to look it up right now.
 
:>Same ECB or different ECB?  Or does the flag indicate whether the operation
:>was STOP, MODIFY, or ... (What else?)

The ECB, when posted, indicates that at least one CIB is available for
processing. The CIB has the command code and the related data.

:>>z/OS "knows" whether a program has gone through the motions of telling z/OS
:>>it was prepared to accept console commands. ...

:>May I assume that "telling" includes providing z/OS with the address of the 
ECB(s)?

More precisely, the application tell zOS that it is willing to handle MODIFY
commands. STOP commands will always go thru. The ECB is provided by the
system. It is cleared when there are no CIBs to process. It is special in that
it is the only key0 ECB that user key programs can wait on.

--
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Chris Mason

Gilmartin

Stop bullying your erstwhile colleagues!

You can put everybody out of their misery, yourself especially, by doing on 
what Charles Mills is famous for pouring scorn - RT fine M:

2.3 Communicating with a program (EXTRACT, QEDIT)

http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/iea2a8c0/2.3

Mason

On Wed, 5 Dec 2012 11:02:26 -0600, Paul Gilmartin  wrote:

>On Wed, 5 Dec 2012 08:03:16 -0800, Charles Mills wrote:
>
>>> How does STOP work?
>>
>>From a programmer's point of view, it sets a flag and posts an ECB.
>>
>>> Is MODIFY similar?
>>
>>Yes, both are quite similar in how they work. Modify is a flag plus the text
>>of the command. AFAIR Stop is just a flag, but I might well be wrong and I
>>am too lazy to look it up right now.
>> 
>Same ECB or different ECB?  Or does the flag indicate whether the operation
>was STOP, MODIFY, or ... (What else?)
>
>>z/OS "knows" whether a program has gone through the motions of telling z/OS
>>it was prepared to accept console commands. ...
>>
>May I assume that "telling" includes providing z/OS with the address of the 
>ECB(s)?
>
>Thanks,
>gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Skip Robinson

The ability to terminate a TSO user with STOP is not used much, but I once 
worked with a shop that required, as part of their security/integrity 
environment, that a user never be allowed to reach 'TSO Ready'. The user 
was put into ISPF at logon and logged off upon exit from ISPF. Their focus 
was on preventing a user from busting out of ISPF to Ready, which at that 
time was a tough requirement. 

It turned out that 'P userid' issued at any time during the TSO session 
would eventually cause immediate logoff upon exit from ISPF regardless of 
how long the ISPF session lasted. Problem solved. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   "McKown, John" 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/05/2012 06:04 AM
Subject:Re: Historical question regarding the stop command
Sent by:IBM Mainframe Discussion List 

To my remembrance, START, STOP, and MODIFY we all original commands in 
OS/360 (I can be wrong, I don't go back that far). They do not do 
asynchronous functions like "kill" does. They basically post an ECB. It is 
up to the program to periodically query this ECB (see the QEDIT macro). 
That's why entering a STOP command doesn't always STOP a broken STC. You 
can even STOP a batch job step. If the program is proper set up, it will 
process the STOP request and terminate. I don't know about today's 
environment, but in the past, if you did this and the program didn't 
remove the STOP request from the queue but terminated instead, then the 
initiator would see the STOP and it would shut down. This was many years 
ago, so it may not do this anymore.

BTW, did you know that a TSO user's address space will honor a STOP 
command? But ISPF doesn't. So, in the old days, an operator could "P 
tsoid" and the user's TSO session would terminate when they next went to 
the READY prompt, usually at the end of a command. Since, to TSO, ISPF is 
basically a never-ending command, the P doesn't have much effect any more.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
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

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, December 05, 2012 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> On Dec 5, 2012, at 05:32, Martin, Larry D wrote:
> >
> > I believe the reason for the "Start in order to Stop" process is
> required in order to stop Unix Daemons that are running as a part of
> the process.  I agree that the code to handle STOP and MODIFY commands
> is quite simple, but I don't have any experience starting and stopping
> Daemons.
> >
> The UNIX analogue is "kill" which sends any of several signals to a
> process.  For example, SIGINT tells processes designed to handle it to
> prompt or seek additional command information elsewhere.  SIGTERM warns
> a process of imminent system shutdown; I believe that in the spirit of
> POSIX, z/OS shutdown should send SIGTERM to dubbed tasks; others
> reading this will feel strongly otherwise.  SIGINT and SIGTERM are
> fatal if not handled.  SIGKILL is unconditionally fatal (think FORCE,
> but not so destructive).
> SIGHUP (HangUP) tells a process that its controlling terminal has been
> disconnected.  Etc.  A couple signals are reserved for user/ISV
> definition in any supplied application; often used for debugging.
> 
> How does STOP work?  Is MODIFY similar?  Does either schedule an RB to
> a task?  What happens if that task is not prepared to deal with such an
> RB?  Which is older, STOP or MODIFY?
> 
> -- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Mike Schwab

How about creating a started task, say OPENCMD.  When started, it
determines what OpenMVS programs are running.  Then the operator could
issue /F OPENCMD,KILL *ALL for normal shut down all OpenMVS functions
prior to shutdown, or '/F OPENCMD,unixcmd function option' and the
function with options would be forwarded to the unixcmd.  When all was
shutdown, it would close.

On Wed, Dec 5, 2012 at 7:48 AM, McKown, John
 wrote:
> IMO, the "proper" way to stop a UNIX daemon is to use the "kill" command. 
> That's generally how it is done in Linux, at least. The daemon normally keeps 
> its PID in a known location, such as /var/run/daemon.pid. The normal way to 
> stop it is to have a root user (or setuid program) issue something like: kill 
> -TERM $(cat /var/run/daemon.pid). The signal (-TERM) can often be used to 
> send a generic message to the daemon. a -HUP is sometimes used to shut down, 
> but other daemons use -HUP to say "read your startup configuration file again 
> for changes and implement those changes".
>
>
> Note, that with z/OS UNIX, daemons can use the normal START, STOP, and MODIFY 
> command interface (or even "hang a WTOR" ). It is just very unusual 
> for them to do so because most are "ports" from UNIX systems which don't have 
> those capabilities.
>
> --
> John McKown
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, December 05, 2012 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> On Wed, 5 Dec 2012 08:03:16 -0800, Charles Mills wrote:
> 
> >> How does STOP work?
> >
> >From a programmer's point of view, it sets a flag and posts an ECB.
> >
> >> Is MODIFY similar?
> >
> >Yes, both are quite similar in how they work. Modify is a flag plus
> the
> >text of the command. AFAIR Stop is just a flag, but I might well be
> >wrong and I am too lazy to look it up right now.
> >
> Same ECB or different ECB?  Or does the flag indicate whether the
> operation was STOP, MODIFY, or ... (What else?)

Same physical ECB. There is a control block, the CIB, which describes the 
communication. It has a "verb" for STOP, MODIFY, and START. Each of these 
reside in a CIB. That's how a program can pick up information from the START 
command which initiated it (if there is one, that is). Using QEDIT, you tell 
z/OS how many CIBs can be queued to your address space. The default is 0. The 
QEDIT macro is also used to get the address of the next CIB, if any, and also 
to free it. A "one stop" macro. There is only a single ECB involved. It is 
reset when the number of CIBs is zero. The ECB itself is in system storage. 
There is special code in WAIT which allows key 8 code (application) to WAIT on 
the key 0 ECB.

> 
> >z/OS "knows" whether a program has gone through the motions of telling
> >z/OS it was prepared to accept console commands. ...
> >
> May I assume that "telling" includes providing z/OS with the address of
> the ECB(s)?

No, z/OS tells the code where the ECB exists.

> 
> Thanks,
> gil

Ref, with example assembler code:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/2.3

Implemented in IBM's z/OS C run time via the __console2 routine.
ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDCLB1B0/3.138

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

See F BPXOINIT for some of what you want to do. F BPXOINIT,TERM=pid[.tid]

ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2G1B2/4.21.9

D OMVS,A=ALL

will display all z/OS UNIX processes.


-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mike Schwab
> Sent: Wednesday, December 05, 2012 11:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> How about creating a started task, say OPENCMD.  When started, it
> determines what OpenMVS programs are running.  Then the operator could
> issue /F OPENCMD,KILL *ALL for normal shut down all OpenMVS functions
> prior to shutdown, or '/F OPENCMD,unixcmd function option' and the
> function with options would be forwarded to the unixcmd.  When all was
> shutdown, it would close.
> 
> On Wed, Dec 5, 2012 at 7:48 AM, McKown, John
>  wrote:
> > IMO, the "proper" way to stop a UNIX daemon is to use the "kill"
> command. That's generally how it is done in Linux, at least. The daemon
> normally keeps its PID in a known location, such as
> /var/run/daemon.pid. The normal way to stop it is to have a root user
> (or setuid program) issue something like: kill -TERM $(cat
> /var/run/daemon.pid). The signal (-TERM) can often be used to send a
> generic message to the daemon. a -HUP is sometimes used to shut down,
> but other daemons use -HUP to say "read your startup configuration file
> again for changes and implement those changes".
> >
> >
> > Note, that with z/OS UNIX, daemons can use the normal START, STOP,
> and MODIFY command interface (or even "hang a WTOR" ). It is
> just very unusual for them to do so because most are "ports" from UNIX
> systems which don't have those capabilities.
> >
> > --
> > John McKown
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Gerhard Postpischil


On 12/5/2012 1:00 PM, McKown, John wrote:

Same physical ECB. There is a control block, the CIB, which describes
the communication. It has a "verb" for STOP, MODIFY, and START. Each
of these reside in a CIB.


I've never had an occasion to process a CIB for a STOP command, as it's 
easier just to test the communications ECB. Start and Modify both post 
with x'40', while STOP posts with x'50'.


Gerhard Postpischil
Bradford, Vermont

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Tim Hare

According to IEZCIB, STOP is x'40', MODIFY is x'44' and START is x'04':

CIBVERB  DSC -  COMMAND VERB CODE  
CIBSTART EQU   X'04' -  COMMAND CODE FOR START 
CIBSTCOM EQU   X'08' -  COMMAND CODE FOR STC COMMUNICATION @G860P2G
CIBMODFY EQU   X'44' -  COMMAND CODE FOR MODIFY
CIBSTOP  EQU   X'40' -  COMMAND CODE FOR STOP  
CIBMOUNT EQU   X'0C' -  COMMAND CODE FOR MOUNT


I'm still left with my original question - especially now that we've determined 
that the STOP/P command existed when I was in high school...  my current 
thinking:

1. Whoever wrote the started task thought they needed to use some sort of 
subsystem request (for whatever reason) and therefore had to have a program to 
make such request
2.  The people who actually wrote this code are no longer with us, or no longer 
on IBM-MAIN at least, so we don't have them around to explain it  

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Tony Harminc

On 5 December 2012 12:02, Paul Gilmartin  wrote:

>>z/OS "knows" whether a program has gone through the motions of telling z/OS
>>it was prepared to accept console commands. ...
>>
> May I assume that "telling" includes providing z/OS with the address of the 
> ECB(s)?

It's been answered, but it's worth noting that it's "ECB", not
"ECB(s)". That is, there is effectively but one such ECB per address
space, so multiple tasks cannot have their own independent
notifications from stop or modify commands. There is neither syntax
nor infrastructure provided to direct a stop or modify to a unit of
work within an address space.UNIX on z/OS does provide the ability to
direct signals to processes, and perhaps even to threads, iirc.

In passing, there is another really annoying limitation imposed on
programs that use the IBM callable service BPX1CCS (aka __console()
or __console2() ), which are the only console services available to C
programmers unless you write your own assembler interface. These
services arrogate to themselves use of the entire name space on the
modify command that rightly belongs to the application program, and
dole out to the application only the limited subset that follows the
string "APPL=".

But I've ranted about this before...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

Well, I know for a fact that some vendors still don't use MODIFY commands for 
their products. They "hang" a WTOR. Why? I guess it's just easier. 

I spoke with my manager, who used to work for a vendor. He said that for one 
product he knew of, what became an independent STC was once a subset of a 
larger STC. If you wanted to shutdown that particular subset, it was easier to 
issue a START which ran a program which connected to the subfunction and said 
"shut down". Use of a MODIFY would have caused contention with the routines in 
the enclosing STC. Since then, the subset was moved into a separate STC, but 
originally "as is", thus continuing to use the second START. Since then, they 
have upgraded the separated code to use a STOP as well, but left in the old 
shutdown code in for existing users.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Tim Hare
> Sent: Wednesday, December 05, 2012 1:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> According to IEZCIB, STOP is x'40', MODIFY is x'44' and START is x'04':
> 
> CIBVERB  DSC -  COMMAND VERB CODE
> CIBSTART EQU   X'04' -  COMMAND CODE FOR START
> CIBSTCOM EQU   X'08' -  COMMAND CODE FOR STC COMMUNICATION @G860P2G
> CIBMODFY EQU   X'44' -  COMMAND CODE FOR MODIFY
> CIBSTOP  EQU   X'40' -  COMMAND CODE FOR STOP
> CIBMOUNT EQU   X'0C' -  COMMAND CODE FOR MOUNT
> 
> 
> I'm still left with my original question - especially now that we've
> determined that the STOP/P command existed when I was in high school...
> my current thinking:
> 
> 1. Whoever wrote the started task thought they needed to use some sort
> of subsystem request (for whatever reason) and therefore had to have a
> program to make such request
> 2.  The people who actually wrote this code are no longer with us, or
> no longer on IBM-MAIN at least, so we don't have them around to explain
> it
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

I had never heard of the ability to issue a STOP command for a TSO 
session, so I tried it with one of my TSO sessions (which was in READY 
mode), and nothing happened. It would appear that as of z/OS 1.13 this 
ability no longer exists.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-12-05 09:03, McKown, John wrote:

To my remembrance, START, STOP, and MODIFY we all original commands in OS/360 (I can be 
wrong, I don't go back that far). They do not do asynchronous functions like 
"kill" does. They basically post an ECB. It is up to the program to 
periodically query this ECB (see the QEDIT macro). That's why entering a STOP command 
doesn't always STOP a broken STC. You can even STOP a batch job step. If the program is 
proper set up, it will process the STOP request and terminate. I don't know about today's 
environment, but in the past, if you did this and the program didn't remove the STOP 
request from the queue but terminated instead, then the initiator would see the STOP and 
it would shut down. This was many years ago, so it may not do this anymore.

BTW, did you know that a TSO user's address space will honor a STOP command? But ISPF 
doesn't. So, in the old days, an operator could "P tsoid" and the user's TSO 
session would terminate when they next went to the READY prompt, usually at the end of a 
command. Since, to TSO, ISPF is basically a never-ending command, the P doesn't have much 
effect any more.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Okay, I'm getting this nailed down. To review, I am not writing a general
purpose function and can safely ignore all of the "weird" cases like "two
programs with the same name from different load libraries." We can assume
true z/OS batch (not STC or anything Unix-ey). Let's ignore any 64-bit
considerations. No AR mode.

I can live with an answer to the following either/or question: am I the
jobstep program, or did someone else load (in a generic sense of the word
load) me? I can't make the simplifying assumption that I know my own name
because customers may have renamed "me" (more likely than it usually would
be for reasons that are beyond the scope of this discussion). Either "me" or
the (other) jobstep program might be in the LPA. 

I don't see any examples for CSVQUERY. Am I missing something?

Anyway, here is my plan. Comments?

Issue CSVQUERY
INADDR=ptr_to_any_addr_in_my_pgm,SEARCH=JPALPA,SEARCHMINOR=NO,OUTEPNM=eight_
char_fld_in_writable_storage

(I know some of those parms are defaults; I'm just being extra clear.) Given
RC=0, that gets me "my" name. Do I need anything else on CXVQUERY other than
the usual MF= considerations? Am I safe ignoring PLISTVER and any other
parameters?

Compare the returned name to JSCBPGMN from my TCB. If they are equal, it is
the "I am the jobstep program" case; else it is the "somebody must have
loaded me" case.

Thanks,
Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Wednesday, December 05, 2012 4:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

JSCBPGMN is the "job step program name". If the question is is "am I a
program whose name matches the job step program name" then that field can be
used to answer. Note that I intentionally did not say "am I the program"
because that can be very very hard to determine, if there are 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

In <076601cdd26d$7bc24590$7346d0b0$@mcn.org>, on 12/04/2012
   at 02:19 PM, Charles Mills  said:

>1. What would be the best way for a program running z/OS batch to
>answer the question "Am I the jobstep program, the PGM= program, 
>or was I LOADed and CALLed or ATTACHed (let's ignore XCTL for now) 
>by another program?

The TCBJSTCB field of the current TCB points to the J/S TCB. The
Initiator attaches PGM=foo as a jobstep.

>2. In addition, if the answer to (1.) is "another program," where
>would I find its entry point name?

Use CSVQUERY to identify the current program. 

>In other words, "who loaded me?" 

Those are two unrelated questions. There is no API to determine who
did the LOAD for a loaded module.

Do you also want to know who did a CALL or LINK?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <20121205011050.5da6824...@panix5.panix.com>, on 12/04/2012
   at 08:10 PM, Rich Greenberg  said:

>Tim et al,  This is a pure WAG:

And quite wrong.

>The START command has been around a LOT longer than the STOP
>command,

No.

>taps A on the shoulder, 

The standard way to do that is to use a HALT (Z), MODIFY (F) or STOP
(P) command.

>It became the standard way to end a never-ending task.  Then someone
>invented STOP.

STOP was in OS/360 in the 1960's.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

In <50bea8f7.1060...@valley.net>, on 12/04/2012
   at 08:52 PM, Gerhard Postpischil  said:

>The PGM= entry is the jobstep program, unless you're processing a TSO
> command (but you specified batch...).

Even under TSO, PGM=IKJEFT01 is in a J/S task.

He'll need more detail to do SA and RB chasing.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <50bed27c.3090...@ozemail.com.au>, on 12/05/2012
   at 03:50 PM, Clem Clarke  said:

>I agree.  MFT had a P command too, as I recall.  You had to be 
>able to stop the readers and writers, even though TSO, 
>multitasking and all the good stuff hadn't been invented yet.

Multitasking was part of the original design, even if SSS and MSS
shipped first.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <50bf02da.9010...@edelweb.fr>, on 12/05/2012
   at 09:16 AM, Peter Sylvester  said:

>Several "started tasks" programs around do not need
>"authorized" features.

QEDIT does not require authorization. IBM documented it back in
OS/360, so it's hardly bleeding edge.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

The programming to respond to either a MODIFY command or a WTOR reply is
pretty simple. From my POV the level of complexity is similar. In either
case, to ensure that operator input is recognized and processed
promptly, it is advisable to create a separate TCB to handle the
operator input.

Regarding the use of a START command to cause another started task to
stop, the saying "if all you have is a hammer, everything looks like a
nail" comes to mind.

Think back to the complaints when Windows first came up with the "Start"
button..."What, I have to click Start to stop my computer?"

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-12-05 14:35, McKown, John wrote:

Well, I know for a fact that some vendors still don't use MODIFY commands for their
products. They "hang" a WTOR. Why? I guess it's just easier.

I spoke with my manager, who used to work for a vendor. He said that for one product he knew of,
what became an independent STC was once a subset of a larger STC. If you wanted to shutdown that
particular subset, it was easier to issue a START which ran a program which connected to the
subfunction and said "shut down". Use of a MODIFY would have caused contention with the
routines in the enclosing STC. Since then, the subset was moved into a separate STC, but originally
"as is", thus continuing to use the second START. Since then, they have upgraded the
separated code to use a STOP as well, but left in the old shutdown code in for existing users.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Just a thought on this. As you say, check that the TCB under which the code is 
executing is the JSTCB. Next, make sure that the RB back chain points back to 
the TCB. This means that it is the only RB on the chain and that you are not 
running via a LINK instruction. But you might be running on the first RB, but 
invoked via a BALR/BASR where the executable code was brought in with a LOAD 
and the EPA stored away. In that case, get the CDE pointer from the RB. The CDE 
contains the load point of the program and its length. Make sure the PSW is 
within this address range. If not, then you were not executed via a PGM= . 
Unfortunately, I cannot figure out an easy way to determine if you were invoked 
via an XCTL.

I guess the OP's question, as I might rephrase it would be: "How can I test to 
see if the currently executing code is being run under the first, and only, RB 
on the TCB's RB chain and that the TCB is the job step TCB?" Answering this 
would eliminate use of ATTACH, LINK, LOAD/BALR|BASR, SYNC. It only leaves XTCL.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
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


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Wednesday, December 05, 2012 9:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Who loaded me?
> 
> In <076601cdd26d$7bc24590$7346d0b0$@mcn.org>, on 12/04/2012
>at 02:19 PM, Charles Mills  said:
> 
> >1. What would be the best way for a program running z/OS batch to
> >answer the question "Am I the jobstep program, the PGM= program, or
> was
> >I LOADed and CALLed or ATTACHed (let's ignore XCTL for now) by another
> >program?
> 
> The TCBJSTCB field of the current TCB points to the J/S TCB. The
> Initiator attaches PGM=foo as a jobstep.
> 
> >2. In addition, if the answer to (1.) is "another program," where
> would
> >I find its entry point name?
> 
> Use CSVQUERY to identify the current program.
> 
> >In other words, "who loaded me?"
> 
> Those are two unrelated questions. There is no API to determine who did
> the LOAD for a loaded module.
> 
> Do you also want to know who did a CALL or LINK?
> 
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  Atid/2
> 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...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Peter Sylvester


On 12/05/2012 04:18 PM, Shmuel Metz (Seymour J.) wrote:

In <50bf02da.9010...@edelweb.fr>, on 12/05/2012
at 09:16 AM, Peter Sylvester  said:


Several "started tasks" programs around do not need
"authorized" features.

QEDIT does not require authorization. IBM documented it back in
OS/360, so it's hardly bleeding edge.


ooups. thanks for the reminder, some Alzheimer effect. :-)
I remember I wrote this little program to encapsulate
C program/daemon ported from unix as part of the
 UCLA/Mail400 project in october 1987.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Tony Harminc

On 5 December 2012 14:49, Gord Tomlin  wrote:

> I had never heard of the ability to issue a STOP command for a TSO session,
> so I tried it with one of my TSO sessions (which was in READY mode), and
> nothing happened. It would appear that as of z/OS 1.13 this ability no
> longer exists.

I noticed that it had been removed a few years ago, but I'm not sure
when it happened. It may well have been early in TSO/E. It is
certainly there in the TSO in MVS 3.8. There is check of the
STOP/MODIFY ECB in the main loop that issues the READY message.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

2012-12-05 Thread Jeremy Nicoll - ls mainframes

Charles Mills  wrote:

>Issue CSVQUERY
>INADDR=ptr_to_any_addr_in_my_pgm,SEARCH=JPALPA,SEARCHMINOR=NO,OUTEPNM=eight_
>char_fld_in_writable_storage
>
> (I know some of those parms are defaults; I'm just being extra clear.)
> Given RC=0, that gets me "my" name. Do I need anything else on CXVQUERY
> other than the usual MF= considerations? Am I safe ignoring PLISTVER and
> any other parameters?

Suppose someone's defined one or more aliases of the program concerned.  

Is there any combination of uses where the JCL could say EXEC PGM=PROGRAMx
but the CSVQUERY would return "PROGRAMy" - either when one or other of
PROGRAMx/y s the 'real' program, or when both PROGRAMx/y are aliases of
something else?

-- 
Jeremy C B Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <2318b017-dbf2-4116-8388-d8d607ac0...@aim.com>, on 12/05/2012
   at 06:36 AM, Paul Gilmartin  said:

>How does STOP work?  Is MODIFY similar?

Almost identical; both chain a new CIB to the CSCB and post an ECB.
The differences are:

 1. ECB CC
 2. CIB verb
 3. No text from STOP command

>Does either schedule an RB to a task? 

No.

>Which is older, STOP or MODIFY?

They are essentially contemporaneous; certainly both arrived in the
mid 1960's. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

2012-12-05 Thread Jim Mulder

> Beyond that, to z/OS, refresh has meaning only to DIAGxx processing 
where
> you can ask, for testing purposes, that refreshable modules be
> page-protected.

  A minor correction:

  The documented REFRPROT option in PROGxx or SETPROG
causes the full pages of REFR modules to be 
page-protected.  This is intended for testing or
production use.

  The undocumented CsvRentProtect trap name in
DIAGxx causes the full pages of RENT modules to be 
page-protected.  This is intended only for testing or
diagnostic purposes.

  The undocumented CsvRentSP252 trap name in 
DIAGxx causes RENT modules to be loaded into 
subpool 252 (key 0) storage, regardless of whether 
or not they come from APF-authorized libraries.
This is intended only for testing or diagnostic
purposes. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

In
,
on 12/05/2012
   at 09:00 AM, Peter Relson  said:

>All of PLPA is by definition refreshable.

It's certainly refreshable these days, but it wasn't way back in SVS.
OTOH, I always considered it to be bad form to write nonrefreshable
code that was reentrant or LPA resident, even when it was still
supported.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Mark Zelden

On Wed, 5 Dec 2012 14:49:06 -0500, Gord Tomlin 
 wrote:

>I had never heard of the ability to issue a STOP command for a TSO
>session, so I tried it with one of my TSO sessions (which was in READY
>mode), and nothing happened. It would appear that as of z/OS 1.13 this
>ability no longer exists.
>

As far as I know, the function is still there.   Did you attempt to 
exit to TSO READY?   What response did you get (if any) on
the console when you issued the stop command?

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Page datasets

2012-12-05 Thread Lopez, Sharon

We have 9 mod-9 page datasets that are over 50% in useMQ Broker using most 
of this storage.  Has anyone experienced anything like this?



E-mail correspondence to and from this address may be subject to the North 
Carolina Public Records Law and may be disclosed to third parties by an 
authorized state official.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

2012-12-05 Thread Bill Fairchild

It's in the archives multiple times.  About once a year this same question is 
asked, followed by a flurry of technical replies, and finally a small flurry of 
"it can't be done in the general case" replies.

Not everything is in the archives.  And a lot is in the archives that doesn't 
need to be there, because of topic drift and periodic asking of the same 
question.

I once had a colleague who asked me at least once a day what time it was.  I 
told him the time of day every time he asked me for about two weeks.  Then one 
day I grew tired of the process and asked him politely, but not smugly, why he 
didn't have his own watch.

My answer of looking in the archives was too brief, and thus it appeared smug.  
I should have added that this was a difficult topic, there are a lot of details 
to consider, the problem is insoluble in the general case, and it is asked of 
IBM-MAIN about once a year.  Reviewing the archives will also reveal the 
details that have been brought out in the past but that might not have been 
brought out in the current round of replies to this annual topic.

Many of us do have answers right on the top of our head.  But it takes a fair 
amount of time to compose a technically correct and hopefully helpful reply.  
It has to be EXTREMELY correct because there are some posters who seem to 
thrive on finding fault with others' posts.  And I do not mean Charles Mills.  
I would hope that in an ideal world a would-be question-poser might contrast 
how much time it takes the five or six people who give thorough and correct 
answers with how much time he should research the subject himself before asking 
the whole world.  When I was a child eating dinner with my parents, I would 
often ask them what such-and-such a word meant after first hearing it in dinner 
conversation.  My dad, who had the answer on the top of his head,  would 
usually say "you know how to spell now and how to find words that you don't 
know how to spell by breaking them down phonetically; look it up in the 
dictionary and/or encyclopedia (we had two different sets, one of which was 
Britannica) after dinner."  I would look it up and learn far more than just the 
meaning of that word.  My dad was not trying to be smug, but rather to instill 
in me more intellectual curiosity and individual resourcefulness.

OTOH, my advice to search the archives was, IMHO, much nicer than this answer:  
"No."

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, December 05, 2012 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Thanks, John.

It is so easy and facile to say "RTFM."

Yeah, sure, it's in the archives. So is everything else.

When I lived in NYC in the sixties, I had a friend who had this idea of selling 
the police "a list of everyone in Manhattan who smoked dope." It was the 
Manhattan phone book.

I have a program that will tell you anyone's RACF password. It's a random 
password generator. If you click it enough times it will generate the password 
you are looking for.

RTFM is an appropriate response in many cases, but it is vastly overused as a 
smug put-down. If a friend asked you what time it was, would you tell him there 
was a clock in a room down the hall, or would you look at your wrist and tell 
him the damned time?

I suspected someone would know the answer to my fairly simple question of the 
top of their heads, and I was right, Peter Relson did. If you don't have an 
easy answer off the top of your head, or you're too busy to respond, you are 
free to ignore a question. Put-downs are not necessary.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Wednesday, December 05, 2012 7:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Bill Fairchild is guilty of meiosis, the antonym of hyperbole.  There is very 
much too much discussion of this topic in the archives.

It is of course possible to get answers to carefully circumscribed special 
cases of this question of the sort Charles Mills is seeking.
There are no general/generic answers to it, and the prospects for one are bleak.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Oh d***, you're absolutely right. Customer says EXEC PGM=alias but CSVQUERY
returns the major name. D***, d***, d***! That is absolutely a real-world
possibility even in my constrained set of cases.

The alias would be an alias for the main entry point so finding the nearest
minor name is not a solution. D***, d***, d***!

Back to the drawing board.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jeremy Nicoll - ls mainframes
Sent: Wednesday, December 05, 2012 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Charles Mills  wrote:

>Issue CSVQUERY
>INADDR=ptr_to_any_addr_in_my_pgm,SEARCH=JPALPA,SEARCHMINOR=NO,OUTEPNM=e
>ight_
>char_fld_in_writable_storage
>
> (I know some of those parms are defaults; I'm just being extra clear.) 
> Given RC=0, that gets me "my" name. Do I need anything else on 
> CXVQUERY other than the usual MF= considerations? Am I safe ignoring 
> PLISTVER and any other parameters?

Suppose someone's defined one or more aliases of the program concerned.  

Is there any combination of uses where the JCL could say EXEC PGM=PROGRAMx
but the CSVQUERY would return "PROGRAMy" - either when one or other of
PROGRAMx/y s the 'real' program, or when both PROGRAMx/y are aliases of
something else?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command


Yes the session was in READY mode, as I stated in my previous post.

The console showed nothing other than the command I issued. No response.

Give it a try on your system and post your results.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-12-05 15:47, Mark Zelden wrote:

On Wed, 5 Dec 2012 14:49:06 -0500, Gord Tomlin 
 wrote:


[snip]

 (which was in READY

mode)
[/snip]



As far as I know, the function is still there.   Did you attempt to
exit to TSO READY?   What response did you get (if any) on
the console when you issued the stop command?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

z/OS 1.12. I was in SDSF under ISPF. I did a /P TSH009 command. I then exited 
ISPF. I next saw:

IKJ56470I TSH009 LOGGED OFF TSO AT 15:22:15 ON DECEMBER 5, 2012
IKJ56400A ENTER LOGON OR LOGOFF-

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
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® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Gord Tomlin
> Sent: Wednesday, December 05, 2012 3:17 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Historical question regarding the stop command
> 
> Yes the session was in READY mode, as I stated in my previous post.
> 
> The console showed nothing other than the command I issued. No
> response.
> 
> Give it a try on your system and post your results.
> 
> --
> 
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> 
> On 2012-12-05 15:47, Mark Zelden wrote:
> > On Wed, 5 Dec 2012 14:49:06 -0500, Gord Tomlin
>  wrote:
> >
> >> [snip]
>   (which was in READY
> >> mode)
> >> [/snip]
> >>
> >
> > As far as I know, the function is still there.   Did you attempt to
> > exit to TSO READY?   What response did you get (if any) on
> > the console when you issued the stop command?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Thanks Bill, I understand what you are saying and I apologize if my reply
was too harsh. There is no absolute answer: neither saying RTFM nor
explaining basics to a newbie is the right answer in every case. Someone
asked here the other day "so, how do I set up a WLM?" Unquestionably the
right answer is "read 'Init and Tuning' (?) and come back here with your
specific questions."

I'm not unwilling to read manuals. Someone said "use CSVQUERY." Well, I've
never used CSVQUERY before, so I read the doc from top to bottom. (And,
sadly, looked futilely in the A/S Guide for a single example or usage
paragraph!)

Yeah, the people who nit-pick the helpful-but-lacking-one-obscure-detail
answers are winning the battle but losing the war: they discourage people
from answering a simple question for fear of being flamed for omitting one
complex detail.

Take care,
Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bill Fairchild
Sent: Wednesday, December 05, 2012 12:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

It's in the archives multiple times.  About once a year this same question
is asked, followed by a flurry of technical replies, and finally a small
flurry of "it can't be done in the general case" replies.

Not everything is in the archives.  And a lot is in the archives that
doesn't need to be there, because of topic drift and periodic asking of the
same question.

I once had a colleague who asked me at least once a day what time it was.  I
told him the time of day every time he asked me for about two weeks.  Then
one day I grew tired of the process and asked him politely, but not smugly,
why he didn't have his own watch.

My answer of looking in the archives was too brief, and thus it appeared
smug.  I should have added that this was a difficult topic, there are a lot
of details to consider, the problem is insoluble in the general case, and it
is asked of IBM-MAIN about once a year.  Reviewing the archives will also
reveal the details that have been brought out in the past but that might not
have been brought out in the current round of replies to this annual topic.

Many of us do have answers right on the top of our head.  But it takes a
fair amount of time to compose a technically correct and hopefully helpful
reply.  It has to be EXTREMELY correct because there are some posters who
seem to thrive on finding fault with others' posts.  And I do not mean
Charles Mills.  I would hope that in an ideal world a would-be
question-poser might contrast how much time it takes the five or six people
who give thorough and correct answers with how much time he should research
the subject himself before asking the whole world.  When I was a child
eating dinner with my parents, I would often ask them what such-and-such a
word meant after first hearing it in dinner conversation.  My dad, who had
the answer on the top of his head,  would usually say "you know how to spell
now and how to find words that you don't know how to spell by breaking them
down phonetically; look it up in the dictionary and/or encyclopedia (we had
two different sets, one of which was Britannica) after dinner."  I would
look it up and learn far more than just the meaning of that word.  My dad
was not trying to be smug, but rather to instill in me more intellectual
curiosity and individual resourcefulness.

OTOH, my advice to search the archives was, IMHO, much nicer than this
answer:  "No."

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w:
www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, December 05, 2012 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Thanks, John.

It is so easy and facile to say "RTFM."

Yeah, sure, it's in the archives. So is everything else.

When I lived in NYC in the sixties, I had a friend who had this idea of
selling the police "a list of everyone in Manhattan who smoked dope." It was
the Manhattan phone book.

I have a program that will tell you anyone's RACF password. It's a random
password generator. If you click it enough times it will generate the
password you are looking for.

RTFM is an appropriate response in many cases, but it is vastly overused as
a smug put-down. If a friend asked you what time it was, would you tell him
there was a clock in a room down the hall, or would you look at your wrist
and tell him the damned time?

I suspected someone would know the answer to my fairly simple question of
the top of their heads, and I was right, Peter Relson did. If you don't have
an easy answer off the top of your head, or you're too busy to respond, you
are free to ignore a question. Put-downs are not necessary.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-

Re: Multiple HSM in one LPAR ?

2012-12-05 Thread Glenn Wilcock

Hi Lizette,

If the intent is to test a different version of an Exit, then there is a 
possibility.  I've never verified that this works, but it's something that may 
be tried...

Use the MASH support to start an AUXILIARY HSM.  (Yes, I know, our 
documentation needs to be improved regarding MASH).  For the AUXILIARY HSM 
host, define the startup procedure with a STEPLIB of a library containing the 
desired exits, that are unique from the STEPLIB specified for the MAIN HSM 
host.  A second library would need to be specified that contains the other 
common modules (DFSMSdss, etc).  This should enable the AUX HSM to use unique 
exits.  If the Exits reference the MCVT control block, then they need to be 
updated to use the QCT to access the correct MCVT.

Note that the Control Data Sets will be the active ones, so all testing will 
need to be mindful of any impact that will occur to the live CDSes.

Glenn Wilcock
DFSMShsm Architect

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Mark Zelden

On Wed, 5 Dec 2012 16:17:05 -0500, Gord Tomlin 
 wrote:

>Yes the session was in READY mode, as I stated in my previous post.
>

Then that is the problem.  You didn't read the OP carefully.  You have to
be in ISPF when the STOP command is issued and it keeps you from
getting to the READY prompt, which is what the objective was.  If you
are already at the READY prompt it is too late.

>The console showed nothing other than the command I issued. No response.
>
>Give it a try on your system and post your results.

I just did.  On a RACF and an ACF2 system.  It still works as advertised.

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CHPID TYPE OSE Port 1 of OSA Express3

2012-12-05 Thread Rebecca Martin

Yes Chris I did state this wrong "For the OSE cards, when TCP/IP is started, it 
uses the information in the TCP/IP profile to load the port with IP address, 
etc, that the port needs to connect to the network."

Good thing I am not the communication person here :)  

The bottom line (for us) was that to use port 1 on a OSA with a CHPID type of 
OSE and LCS in the TCPIP definitions, we need to use OSA/SF to load the ODAT 
for port 1 and set the portname in the config.  When we only had 1 port per 
CHPID, OSA/SF was not required.

For our z114 installation/implementation there is another hardware vendor that 
we have been working with.  The CE is from IBM but our other support during the 
installation/implementation is not.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Mark Zelden

On Wed, 5 Dec 2012 15:31:29 -0600, Mark Zelden  wrote:

>On Wed, 5 Dec 2012 16:17:05 -0500, Gord Tomlin 
> wrote:
>
>>Yes the session was in READY mode, as I stated in my previous post.
>>
>
>Then that is the problem.  You didn't read the OP carefully.  You have to
>be in ISPF when the STOP command is issued and it keeps you from
>getting to the READY prompt, which is what the objective was.  If you
>are already at the READY prompt it is too late.
>
>>The console showed nothing other than the command I issued. No response.
>>
>>Give it a try on your system and post your results.
>
>I just did.  On a RACF and an ACF2 system.  It still works as advertised.
>


I also did try it while sitting at a READY prompt and the next time I tried to 
do 
anything (other than hitting enter), I saw this:

IKJ56620I MVS STOP command encountered. TSO/E session is terminated. 
IKJ56470I MZELDEN LOGGED OFF TSO AT 15:35:05 ON DECEMBER 5, 2012   

I didn't mention it before, but these were z/OS 1.13 systems at RSU1209.

Regards,

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <0816473914760532.wa.paulgboulderaim@listserv.ua.edu>, on
12/05/2012
   at 11:02 AM, Paul Gilmartin  said:

>Same ECB or different ECB?

All commands chaining a CIB to the CSCB use the same ECB; this is one
of the cases where a service not requiring authorization is
documented[1] in a z/OS MVS Programming: Authorized Assembler Services
manual: z/OS MVS Programming: Authorized Assembler Services Reference,
Volume 2 (EDT-IXG). SA22-7610-17. Despite the description in 13.0 
EXTRACT -- Extract TCB Information, the data for FIELDS=COMM do not
come from the TCB )-:

>Or does the flag indicate whether the operation
>was STOP, MODIFY, 

The COMM ECB has a code identifying the last command verb chained, and
each CIB has a verb code identifying the command for that CIB.

>or ... (What else?)

HALT (Z).

[1] I typically use a more efficient way, but it involves control
block fields.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In <50bf9958.2000...@valley.net>, on 12/05/2012
   at 01:58 PM, Gerhard Postpischil  said:

>I've never had an occasion to process a CIB for a STOP command, as
>it's  easier just to test the communications ECB. Start and Modify
>both post with x'40', while STOP posts with x'50'.

Back in the old days there was no way for an unauthorized program to
enable additional MODIFY commands after a STOP command. Even today you
need code to reenable MODIFY, so testing the ECB code should still be
good enough.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

In
,
on 12/05/2012
   at 02:33 PM, Tony Harminc  said:

>It's been answered, but it's worth noting that it's "ECB", not
>"ECB(s)". That is, there is effectively but one such ECB per 
>address space,

For a batch job there are two; one is for the Initiator.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?

Suppose I modify the logic as follows. Does anyone see a problem with this?

Issue CSVQUERY OUTMJNM=name to determine the major name associated with some
address in "me." (Any old address.)

Get the jobstep program name from the JSCB. Issue CSVQUERY
INEPNAME=jscbpgnm,SEARCHMINOR=YES,OUTMJNM=eight_char_field to get the major
name associated with the possibly minor name from PGM=.

Compare the two. Equality means I am the jobstep program. (Neglecting the
"two programs/two libraries/one name" case.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Charles Mills
Sent: Wednesday, December 05, 2012 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Oh d***, you're absolutely right. Customer says EXEC PGM=alias but CSVQUERY
returns the major name. D***, d***, d***! That is absolutely a real-world
possibility even in my constrained set of cases.

The alias would be an alias for the main entry point so finding the nearest
minor name is not a solution. D***, d***, d***!

Back to the drawing board.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Jeremy Nicoll - ls mainframes
Sent: Wednesday, December 05, 2012 12:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Who loaded me?

Charles Mills  wrote:

>Issue CSVQUERY
>INADDR=ptr_to_any_addr_in_my_pgm,SEARCH=JPALPA,SEARCHMINOR=NO,OUTEPNM=e
>ight_
>char_fld_in_writable_storage
>
> (I know some of those parms are defaults; I'm just being extra clear.) 
> Given RC=0, that gets me "my" name. Do I need anything else on 
> CXVQUERY other than the usual MF= considerations? Am I safe ignoring 
> PLISTVER and any other parameters?

Suppose someone's defined one or more aliases of the program concerned.  

Is there any combination of uses where the JCL could say EXEC PGM=PROGRAMx
but the CSVQUERY would return "PROGRAMy" - either when one or other of
PROGRAMx/y s the 'real' program, or when both PROGRAMx/y are aliases of
something else?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta

In
<2995AB0EF65FC04B9EFA195743207717118A93CF@MSPWPA-DITDG1B.doitt.nycnet>,
on 12/04/2012
   at 06:20 PM, "Barkow, Eileen"  said:

>2. To overcome the cultural issue of the traditional conservatism 
>of Mainframe application developers and get them to understand, 
>learn and use regular expressions

While the extended regexen of Perl et al are newer, regular
expressions have been in the literature for half a century. Can you
say SNOBOL? Wylbur? It's time for MF developers to pick up the
concept.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

In <7745356004468557.wa.paulgboulderaim@listserv.ua.edu>, on
12/04/2012
   at 08:49 AM, Paul Gilmartin  said:

>Does ADDR= require APF authorization?

>From z/OS MVS Programming: Authorized Assembler Services Reference,
Volume 3(LLA-SDU), SA22-7611-11:

Minimum authorization:  Problem state or supervisor state, and any
PSW key. The GLOBAL, EOM, ADDR, ADDR64,
ADRNAPF and ADRNAPF64 parameters are
restricted to authorized users (APF
authorized, PSW key 0-7, or supervisor
state).


>Is there a service that will tell a priori the storage requirement
>of a load module,

BLDL.

>Can refreshable LOADed data sections be shared among address spaces
>or must each address space have a private copy? 

An authorized user can load a refreshable module into the [E]LPA; I
don't know of any way to share a split module between address spaces.

BTW, did you really mean refreshable *data* sections, as opposed to
refreshable code sections with writable data sections?.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Skip Robinson

Of course I had to try it for the first time in years.

1. Logon to TSO as SKIP01 at z/OS R13. 
2. Issue P SKIP01 from a console.
3. Hit  a few times, just get Ready. I.e. 'nothing happens'. 
4. Then...

   pdf 
IKJ56620I MVS STOP command encountered. TSO/E session is terminated. 
IKJ56470I SKIP01 LOGGED OFF TSO AT 13:51:50 ON DECEMBER 5, 2012 
IKJ56400A ENTER LOGON OR LOGOFF- 

I think the key is that user is terminated at the next actual command. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Tony Harminc 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/05/2012 12:29 PM
Subject:Re: Historical question regarding the stop command
Sent by:IBM Mainframe Discussion List 

On 5 December 2012 14:49, Gord Tomlin  
wrote:

> I had never heard of the ability to issue a STOP command for a TSO 
session,
> so I tried it with one of my TSO sessions (which was in READY mode), and
> nothing happened. It would appear that as of z/OS 1.13 this ability no
> longer exists.

I noticed that it had been removed a few years ago, but I'm not sure
when it happened. It may well have been early in TSO/E. It is
certainly there in the TSO in MVS 3.8. There is check of the
STOP/MODIFY ECB in the main loop that issues the READY message.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Specific CSVQUERY question

If I execute

 CSVQUERY INEPNAME=INNAME,SEARCH=JPALPA,OUTMJNM=OUTNAME

am I correct in my interpretation that for any valid entrypoint name in
INNAME currently known for my address space, OUTNAME will contain the major
entrypoint name associated with INNAME?

That's how I RTFM but it's not terribly explicit and there seem to be no
examples.

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

... implying that TSO is TM'ing the CIB on the way by, not doing a WAIT
ECBLIST on the ECB and the terminal.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Skip Robinson
Sent: Wednesday, December 05, 2012 1:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Historical question regarding the stop command

Of course I had to try it for the first time in years.

1. Logon to TSO as SKIP01 at z/OS R13. 
2. Issue P SKIP01 from a console.
3. Hit  a few times, just get Ready. I.e. 'nothing happens'. 
4. Then...

   pdf
IKJ56620I MVS STOP command encountered. TSO/E session is terminated. 
IKJ56470I SKIP01 LOGGED OFF TSO AT 13:51:50 ON DECEMBER 5, 2012 IKJ56400A
ENTER LOGON OR LOGOFF- 

I think the key is that user is terminated at the next actual command. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Robert A. Rosenberg

At 14:49 -0500 on 12/05/2012, Gord Tomlin wrote about Re: Historical 
question regarding the stop command:


I had never heard of the ability to issue a STOP command for a TSO 
session, so I tried it with one of my TSO sessions (which was in 
READY mode), and nothing happened. It would appear that as of z/OS 
1.13 this ability no longer exists.


The STOP takes effect when the session goes into READY mode. If you 
are already in READY mode I would expect that there is a need to 
first have a command run that when it completes will go back into 
READY mode. Try the test again and issue some command and see what 
happens. I am NOT saying that it no longer works under 1.13 but only 
that you did not test it correctly.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Robert A. Rosenberg

At 15:31 -0600 on 12/05/2012, Mark Zelden wrote about Re: Historical 
question regarding the stop command:


On Wed, 5 Dec 2012 16:17:05 -0500, Gord Tomlin 
 wrote:



Yes the session was in READY mode, as I stated in my previous post.



Then that is the problem.  You didn't read the OP carefully.  You have to
be in ISPF when the STOP command is issued and it keeps you from
getting to the READY prompt, which is what the objective was.  If you
are already at the READY prompt it is too late.


Or as I stated in a prior reply, you must get out of READY mode by 
issuing a command that will return to READY mode when it is done.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Robert A. Rosenberg

At 15:00 -0500 on 12/05/2012, Gord Tomlin wrote about Re: Historical 
question regarding the stop command:


Think back to the complaints when Windows first came up with the 
"Start" button..."What, I have to click Start to stop my computer?"


Because you are starting the STOP/SHUT-DOwN process? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

On Wed, 5 Dec 2012 13:57:35 -0800, Skip Robinson wrote:

>Of course I had to try it for the first time in years.
>
>1. Logon to TSO as SKIP01 at z/OS R13.
>2. Issue P SKIP01 from a console.
>3. Hit  a few times, just get Ready. I.e. 'nothing happens'.
>4. Then...
>
>   pdf
>IKJ56620I MVS STOP command encountered. TSO/E session is terminated.
>IKJ56470I SKIP01 LOGGED OFF TSO AT 13:51:50 ON DECEMBER 5, 2012
>IKJ56400A ENTER LOGON OR LOGOFF-
>
>I think the key is that user is terminated at the next actual command.
>
I hate that sort of behavior; if I'm sitting at a READY prompt, I'd prefer
that it interrupt immediately rather than after I've painstakingly typed
a command, reviewed it, found it good, and pressed ENTER.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LOAD and DELETE macro instructions

On Wed, 5 Dec 2012 09:07:25 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>Does ADDR= require APF authorization?
>
>From z/OS MVS Programming: Authorized Assembler Services Reference,
>Volume 3(LLA-SDU), SA22-7611-11:
>
>Minimum authorization:  Problem state or supervisor state, and any
>PSW key. The GLOBAL, EOM, ADDR, ADDR64,
>ADRNAPF and ADRNAPF64 parameters are
>restricted to authorized users (APF
>authorized, PSW key 0-7, or supervisor
>state).
>
IOW, "Yes."  (I had checked; my question was largely rhetorical, prefacing
my following sentence concerning the limited usefulness of the construct.)

>BTW, did you really mean refreshable *data* sections, as opposed to
>refreshable code sections with writable data sections?.
>
Yes.  I can envision read-only data sections so frequently used that it's
worth avoiding the I/O overhead of loading them for each job that uses
them.  Also the alternative you suggest: sharable writable data sections.
This likely presumes a locking mechanism; perhaps even entitlements,
else you're back in the Dark Ages of User Key CSA.  There may be a
better way.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Specific CSVQUERY question

2012-12-05 Thread Micheal Burn

I had post about this a while ago

If you specify an assembler entry name

Can you get the CSECT major entry point

Don't think you can

Sent from my iPhone

On Dec 5, 2012, at 5:04 PM, Charles Mills  wrote:

> If I execute
> 
> CSVQUERY INEPNAME=INNAME,SEARCH=JPALPA,OUTMJNM=OUTNAME
> 
> am I correct in my interpretation that for any valid entrypoint name in
> INNAME currently known for my address space, OUTNAME will contain the major
> entrypoint name associated with INNAME?
> 
> That's how I RTFM but it's not terribly explicit and there seem to be no
> examples.
> 
> Charles 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Specific CSVQUERY question

Charles,

The information you are seeking is, I think, better disentangled by
the CSVINFO macro.  Have you looked at this macro too?

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Tony Harminc

On 5 December 2012 17:11, Charles Mills  wrote:
> ... implying that TSO is TM'ing the CIB on the way by, not doing a WAIT
> ECBLIST on the ECB and the terminal.

Yes - which also implies that the security provided by this scheme is
illusory, since anyone who can run a program of their choice can
effectively remove the STOP command CIB. Well, perhaps these
locked-into-ISPF users can't run programs, or perhaps it's just a
means to avoid confusing them with a READY prompt that they don't
normally see.

Regardless, this issue continues to puzzle me. On a 1.13 system here I
*am* seeing the logoff after a STOP command, but without the

IKJ56620I MVS STOP command encountered. TSO/E session is terminated.

message. It goes straight to the

IKJ56470I  LOGGED OFF TSO AT time/date
IKJ56400A ENTER LOGON OR LOGOFF-

On another system I am not getting logged off, no matter how many
times I go through the READY prompt.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Specific CSVQUERY question

John, thanks. I did. It looked more complex.

I've got the other mostly coded, and have a test plan. About to give it a
shot.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Wednesday, December 05, 2012 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Specific CSVQUERY question

Charles,

The information you are seeking is, I think, better disentangled by the
CSVINFO macro.  Have you looked at this macro too?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Specific CSVQUERY question

Don't *think* so. It can't be simply what the assembler calls an ENTRY. That
name is not known by CSV. It has to be name known to CSV. It has to be an
alias name or an IDENTIFY name. I *think*. And the "major name" is not a or
the CSECT name (necessarily) -- it is the member name, the "name of the load
module." I *think*.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Micheal Burn
Sent: Wednesday, December 05, 2012 3:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Specific CSVQUERY question

I had post about this a while ago

If you specify an assembler entry name

Can you get the CSECT major entry point

Don't think you can

Sent from my iPhone

On Dec 5, 2012, at 5:04 PM, Charles Mills  wrote:

> If I execute
> 
> CSVQUERY INEPNAME=INNAME,SEARCH=JPALPA,OUTMJNM=OUTNAME

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

Apparently it depends on the command used. TIME does not cause this 
behavior:


[STOP command issued here]

READY 



 READY 

time 

 IKJ56650I TIME-06:54:36 PM. CPU-00:00:02 SERVICE-34255 
SESSION-04:12:58 DECEMBER 5,2012
 READY 

alloc f(foo) da(*) 

 IKJ56620I MVS STOP command encountered. TSO/E session is terminated. 

 IKJ56470I [redacted] LOGGED OFF TSO AT 18:55:52 ON DECEMBER 5, 2012 

 IKJ56400A ENTER LOGON OR LOGOFF- 





--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-12-05 17:23, Robert A. Rosenberg wrote:

At 14:49 -0500 on 12/05/2012, Gord Tomlin wrote about Re: Historical
question regarding the stop command:


I had never heard of the ability to issue a STOP command for a TSO
session, so I tried it with one of my TSO sessions (which was in READY
mode), and nothing happened. It would appear that as of z/OS 1.13 this
ability no longer exists.


The STOP takes effect when the session goes into READY mode. If you are
already in READY mode I would expect that there is a need to first have
a command run that when it completes will go back into READY mode. Try
the test again and issue some command and see what happens. I am NOT
saying that it no longer works under 1.13 but only that you did not test
it correctly.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Query for IBM Systems Magazine website article on z/OS community

2012-12-05 Thread Gabe Goldberg


Maybe you saw this article...

40 Years of VM Community—and Going Strong!
http://www.ibmsystemsmag.com/mainframe/trends/z-vm/vm_community/

...and wondered when it would be the z/OS community's turn. That's now.

More than for most articles, I need suggestions and contributions from 
the community. Though my first job was in POK's OS System Design 
Department, I've spent most of my career in VM Land while being on the 
z/OS community's periphery.


z/OS folk have an eight year head start on VMers, with predecessor first 
versions announced 1964 and shipped 1965 -- so there should be plenty of 
stories. Please keep 'em brief, to fit almost 50 years into a short 
article.


Remember too, this is a "community" article -- so it's about people, 
events, issues, etc. more than OS technology itself. And, please also 
send replies to me directly so they're not buried in list digests.


Here's a list of topics not in any particular order... thoughts on these 
as they pertain to the community? Other topics to include? Thanks...


z/OS heritage
SHARE, GUIDE, international user groups
Local user groups
Computer Measurement Group
NaSPA
Mascots
IBM-Main
Topical lists (DB2, assembler, etc.)
zNextGen
Marist College
Enterprise Computing Community Conference
IBM Academic Initiative
Certifications
International usage
Hardware/software/services vendors
People
Anecdotes, controversies, conflicts, triumphs, failures...

--
Gabriel Goldberg, Computers and Publishing, Inc.   g...@gabegold.com
3401 Silver Maple Place, Falls Church, VA 22042   (703) 204-0433
LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Skip Robinson

I confess to not knowing the gizzard level details, but I suspect that 
TIME is not a 'real' TSO command in the way that D T (I'm told) is not a 
real console command. The gizzard wizards on the list can evaluate this 
opinion. 

In any case, aside from some odd reports of inconsistency, it would appear 
that 'P userid' pretty much relegates a user to the trash heap once out of 
ISPF, which was the original goal of the shop I mentioned earlier. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

From:   Gord Tomlin 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   12/05/2012 03:58 PM
Subject:Re: Historical question regarding the stop command
Sent by:IBM Mainframe Discussion List 

Apparently it depends on the command used. TIME does not cause this 
behavior:

[STOP command issued here]

READY 

  READY 

time 

  IKJ56650I TIME-06:54:36 PM. CPU-00:00:02 SERVICE-34255 
SESSION-04:12:58 DECEMBER 5,2012
  READY 

alloc f(foo) da(*) 

  IKJ56620I MVS STOP command encountered. TSO/E session is terminated. 

  IKJ56470I [redacted] LOGGED OFF TSO AT 18:55:52 ON DECEMBER 5, 2012 

  IKJ56400A ENTER LOGON OR LOGOFF- 

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

On 2012-12-05 17:23, Robert A. Rosenberg wrote:
> At 14:49 -0500 on 12/05/2012, Gord Tomlin wrote about Re: Historical
> question regarding the stop command:
>
>> I had never heard of the ability to issue a STOP command for a TSO
>> session, so I tried it with one of my TSO sessions (which was in READY
>> mode), and nothing happened. It would appear that as of z/OS 1.13 this
>> ability no longer exists.
>
> The STOP takes effect when the session goes into READY mode. If you are
> already in READY mode I would expect that there is a need to first have
> a command run that when it completes will go back into READY mode. Try
> the test again and issue some command and see what happens. I am NOT
> saying that it no longer works under 1.13 but only that you did not test
> it correctly.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Historical question regarding the stop command

2012-12-05 Thread Jeremy Nicoll - ls mainframes

Skip Robinson  wrote:

> In any case, aside from some odd reports of inconsistency, it would appear
> that 'P userid' pretty much relegates a user to the trash heap once out of
> ISPF, which was the original goal of the shop I mentioned earlier.

Did that requirement occur before ispf exits were supported? 

-- 
Jeremy C B Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Who loaded me?