Re: Ted? Is that you?

[Vernooij, CP - SPLXM]

Armed with ... a cell phone. 
Unbeatable!

Kees.

"zMan"  wrote in message
news:...
> http://www.jsonline.com/news/milwaukee/104252724.html
> -- 
> 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...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

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


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

Re: Design question for a UNIX facility similar to TSO SEND command

[Brian Westerman]

Sorry John,

I didn't see you original request.  We ran into the same type of issues when
deveoping SyzMAIL that send the job end condition codes (max and/or all of
them , plus statistics from all of the steps) to the notify "UserID".  We
wanted to expand that function to provide more than just the "highest
condition code" and get it to other subsystems (CICS, IMS, Etc.) and
platforms and we ended up, after a lot of testing and customer feedback,
picking standard EMAIL as the delivery method, mostly because of the
perceived nuisance factor that the people who didn't already get any form of
the notify message, didn't want to get it if it had to be like the TSO one
and be received "uncontrolled".  

We looked into sending to the -nix users directly since we can build the
table any way we wanted, but we found that they also were not interested in
getting the same type of interruption that TSO users have lived with for a
long long time.  In fact, we have found since the introduction, that a
feature which we thought would probably never be used, the ability to
redirect and NOT send the notification directly to the TSO UserID is one of
the big selling points of the software.  It allows the user (or site) to
choose to only send the email and redirect the TSO send to either a log file
or kill it completely.  

Once you provide the ability to send the message(s) to a group of interested
parties, and/or a catch-all email entity that gathers the step and ending
condition codes for every job the ends like SyzMAIL does, the whole reason
for the interruption caused by the send goes away.  

Basically it turns out that apparently given the choice, the TSO user would
rather not get the interruption caused by the message either.  I can't tell
you how many times I have received one myself and hit enter automatically
before I realized what the message said.  For us it's fairly easy to go look
at syslog and see it again, or look at the job, but I had never considered
how difficult that function was for a average user until we started to get
the notes from users who were actually thanking us for the product.  That
was a real strange happening, normally our client support expects problem
reports, which thankfully are VERY infrequent, and the positive comments
coming in randomly were completely unexpected.

Brian

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

Re: CA-OPS/MVS to IBM's System Automation?

[Timothy Sipples]

Glenn Miller asks:
>Why send out 'alerts' to the 'world' when
>we are shutting down a Started Task, say for maintenance.

I can definitely see both sides to the argument. My view is that alerts
should reflect reality, and that nobody is omniscient. If system XYZ is
going down, then the normal "XYZ going down" alert(s) should get sent.
There's nothing that prevents sending additional alerts, though.

I also get very nervous when manual steps are required to reenable alerts,
even leaving aside the potential security issues. To err is human.

- - - - -
Timothy Sipples
Resident Enterprise Architect
STG Value Creation & Complex Deals Team
IBM Growth Markets (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: PDSE versus PDS

[Ed Gould]

On the other hand. Not only the code that would have to be written but 
debugging it would be a nightmare without a "system" to start any trace or 
whatever debugging tools need to be loaded at IPL time. *AND* imagining at  
hours you re-ipl and it doesn't come up?There is no obvious (to me) of shooting 
this "bug" except to take a S/A dumpp. Of course uou need a system to fire up 
IPCS to shoot it with level 1 & 2.
I am not saying its impossible but the likely hood of issues would be almost 
insurmountable without something like VM or the "ancient thing" called DSS.
I sure would not want to be on any forefront with this system. I know IBM got 
the vsam catalog right with minimal issues (although there were some). But 
recoding everything that needs to access a PDSE at IPL time would not be for 
the fient of heart.
Ed

--- On Mon, 10/25/10, Rick Fochtman  wrote:

From: Rick Fochtman 
Subject: Re: PDSE versus PDS
To: IBM-MAIN@bama.ua.edu
Date: Monday, October 25, 2010, 4:29 PM

> 
> 
> --
>  
>> The decision not to support IPL-time use of PDSEs was an unconscionable 
>> one.  It would indeed be easy to caricature it as sabotage.   
>>    
> Perhaps likewise the decision not to support network-mounted files
> at IPL-time.  But Mr. Blair is wont to deem such outcomes not as
> affirmative decisions, but to assert that no such alternative was
> ever given consideration; not so much asn unconscionable choice as
> an unconscious one.
>  

I have to think that the cxomplexity of the code changes required would also 
mitigate angainst this changes as well.


The other notional deficiencies that have been cited here are, many of them, 
virtues; and the long list of PDS deficiencies that were addressed and largely 
removed for PDSEs, among them the radically deficient processing of PDS member 
aliases, has been passed over in silence.

> I understand that when a PDS member name is removed by BLDL aliases
> are not removed.  Whether this is "radically deficient" depends in large
> part on what happens when the remaining aliases are referenced or when
> the PDS is compressed.  I don't know.
> 
> The decision might easily have been made in the opposite sense:  Allow
> members to have multiple equipotent names such that when any one is
> removed any others remain effective, the space occupied by the member
> being reclaimed only when the reference count is reduced to zero.
>  
-
I think you meant STOW, rather than BLDL.

This business of not deleting the code until all the aliases are removed has 
been the same as the PDS ever since PDSE "hit the street. As long as a 
directlry entry still referes to the starting TTR of the emmber, it will be 
retained. Nothing I've read makes me believe that PDSE operates any differently.

Nothing new or different here. And STOW only removes one name at a time.

Rick

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





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

Ted? Is that you?

[zMan]

http://www.jsonline.com/news/milwaukee/104252724.html
-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: EntireX and LOCALHOST

[Gibney, Dave]

Thanks Chris,

I will likely do this. Thanks for making the steps clear. I could have
used your detailed notes on the RESOLVER address space when I first
implemented it. If I recall correctly, there was something about either
z/OS 1.4 or 1.7 that required me to implement it then. I don't remember
specifically why I took that path. Perhaps it just seemed the "right
thing to do" at the time.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Monday, October 25, 2010 5:35 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EntireX and LOCALHOST
> 
> Dave
> 
> Back at the end of August, Lizette Kohler - in effect - had a similar
> problem.
> She needed something in her name server fixed - preferably quickly -
> but the
> time-scale was out of her control. If that also applies to you in that
> you would
> prefer the "damage" to be repaired right now rather than at the end of
> the
> change cycle - and you are in charge of the Resolver-related members,
> perhaps you should follow up what I am about to mention.
> 
> It may be that in Lizette's case, she did not have a customized
> Resolver
> address space. There's every indication that you do, so you're, say,
90
> % of
> the way there - in comparison with someone who needs to get a
> customized
> Resolver set up first.[1]
> 
> Assuming you are not using an old-fashioned HOSTS.LOCAL file with the
> irritating MAKESITE command conversion, the easiest way to repair
> the "damage" is to change NOCOMMONSEARCH to COMMONSEARCH in your
> Resolver setup file and specify a
DEFAULTIPNODES('TCPIP.WSUMVS1.PARMLIB
> (IPNODES)') statement.
> 
> Then you need to create member IPNODES as the following:
> 
> 127.0.0.1 localhost
> 
> And, just to be sure, add the following statement to member TRESDATA:
> 
> LOOKUP LOCAL DNS
> 
> Note: Member name "IPNODES" is only a suggestion, It can be whatever
> suits
> you.
> 
> This is all according to section "Configuring the local host table
> (optional)" in
> Chapter 5, "TCP/IP Customization" in the Configuration Guide,
> specifically the
> last section "Creating ETC.IPNODES and /etc/ipnodes" where ETC.IPNODES
> and /etc/ipnodes are just two of many ways to identify the file -
> obviously!
> 
> Chris Mason
> 
> -
> 
> [1] This is for any reading who may need to create a customised
> Resolver.
> 
> There is a Technote(FAQ) "Customizing the z/OS RESOLVER"
> 
> http://www-01.ibm.com/support/docview.wss?uid=swg21066874
> 
> which, to my mind falls a long way short of really useful.
> 
> I tried to post this on IBMTCP-L but I see it failed so I am going to
> have to try
> again. I had hoped simply to provide an URL here but, since it's
> missing, here's
> the whole "proposed replacement Technote. I believe I sent it to
> Communications Server development for consideration - to me it's a
"no-
> brainer" but, as they say, there's no accounting for taste:
> 
> 
> 
> Customizing the z/OS Communications Server IP Resolver
> 
> Technote (FAQ)
> 
> Question
> 
> How do I control the z/OS Communications Server IP Resolver functions
> introduced with z/OS V1R12?
> 
> Answer
> 
> Background
> 
> In z/OS V1R12, the Communications Server IP Resolver takes on three
new
> functions. All three new functions are active and providing benefits
> whether or
> not you have customized the Resolver address space which you have been
> using ever since it was introduced with z/OS V1R4. For one of these
> functions, Extension Mechanisms for Domain Name System (DNS) (EDNS0)
> standards, no customization is appropriate since support for the
> enhanced
> capabilities of the name server is determined dynamically. On the
other
> hand,
> in order to be able to control the operation of the other two
> functions,
> caching of information from resolved DNS queries and monitoring
> responsiveness level of DNS name servers, the Resolver function needs
> to be
> customized.
> 
> Customizing the Resolver
> 
> In the z/OS V1R4 Communications Server IP component the resolver
> function
> was generalized and operates by default through a newly introduced
> address
> space. This address space has the name RESOLVER but, unusually, no
> procedure with the name RESOLVER is provided in SYS1.PROCLIB. This is
> because the Resolver address space is initiated with the following
> command:
> 
> START IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR,REUSASID=YES
> 
> This command uses the general purpose procedure IEESYSAS which
provides
> only for the specification of the name of the program to be executed,
> in this
> case EZBREINI, the Resolver. No DD-statements can be specified. This
> has the
> effect that the Resolver executes with only default values for its
> execution
> parameters.
> 
> It is your objective to be able to specify a DD-statement in a
> procedure
> specifically for initiating the Resolver address space. The data set
or
> file to
> which the DD-statement refers will contain parameters with values
> specific 

Re: EntireX and LOCALHOST

[Chris Mason]

Dave

Back at the end of August, Lizette Kohler - in effect - had a similar problem. 
She needed something in her name server fixed - preferably quickly - but the 
time-scale was out of her control. If that also applies to you in that you 
would 
prefer the "damage" to be repaired right now rather than at the end of the 
change cycle - and you are in charge of the Resolver-related members, 
perhaps you should follow up what I am about to mention.

It may be that in Lizette's case, she did not have a customized Resolver 
address space. There's every indication that you do, so you're, say, 90 % of 
the way there - in comparison with someone who needs to get a customized 
Resolver set up first.[1]

Assuming you are not using an old-fashioned HOSTS.LOCAL file with the 
irritating MAKESITE command conversion, the easiest way to repair 
the "damage" is to change NOCOMMONSEARCH to COMMONSEARCH in your 
Resolver setup file and specify a DEFAULTIPNODES('TCPIP.WSUMVS1.PARMLIB
(IPNODES)') statement.

Then you need to create member IPNODES as the following:

127.0.0.1 localhost

And, just to be sure, add the following statement to member TRESDATA:

LOOKUP LOCAL DNS

Note: Member name "IPNODES" is only a suggestion, It can be whatever suits 
you.

This is all according to section "Configuring the local host table (optional)" 
in 
Chapter 5, "TCP/IP Customization" in the Configuration Guide, specifically the 
last section "Creating ETC.IPNODES and /etc/ipnodes" where ETC.IPNODES 
and /etc/ipnodes are just two of many ways to identify the file - obviously!

Chris Mason

-

[1] This is for any reading who may need to create a customised Resolver.

There is a Technote(FAQ) "Customizing the z/OS RESOLVER"

http://www-01.ibm.com/support/docview.wss?uid=swg21066874

which, to my mind falls a long way short of really useful.

I tried to post this on IBMTCP-L but I see it failed so I am going to have to 
try 
again. I had hoped simply to provide an URL here but, since it's missing, 
here's 
the whole "proposed replacement Technote. I believe I sent it to 
Communications Server development for consideration - to me it's a "no-
brainer" but, as they say, there's no accounting for taste:



Customizing the z/OS Communications Server IP Resolver

Technote (FAQ)

Question

How do I control the z/OS Communications Server IP Resolver functions 
introduced with z/OS V1R12?

Answer

Background

In z/OS V1R12, the Communications Server IP Resolver takes on three new 
functions. All three new functions are active and providing benefits whether or 
not you have customized the Resolver address space which you have been 
using ever since it was introduced with z/OS V1R4. For one of these 
functions, Extension Mechanisms for Domain Name System (DNS) (EDNS0) 
standards, no customization is appropriate since support for the enhanced 
capabilities of the name server is determined dynamically. On the other hand, 
in order to be able to control the operation of the other two functions, 
caching of information from resolved DNS queries and monitoring 
responsiveness level of DNS name servers, the Resolver function needs to be 
customized.

Customizing the Resolver

In the z/OS V1R4 Communications Server IP component the resolver function 
was generalized and operates by default through a newly introduced address 
space. This address space has the name RESOLVER but, unusually, no 
procedure with the name RESOLVER is provided in SYS1.PROCLIB. This is 
because the Resolver address space is initiated with the following command:

START IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR,REUSASID=YES

This command uses the general purpose procedure IEESYSAS which provides 
only for the specification of the name of the program to be executed, in this 
case EZBREINI, the Resolver. No DD-statements can be specified. This has the 
effect that the Resolver executes with only default values for its execution 
parameters.

It is your objective to be able to specify a DD-statement in a procedure 
specifically for initiating the Resolver address space. The data set or file to 
which the DD-statement refers will contain parameters with values specific to 
your installation.

This default behaviour is caused by the following specification in the 
BPXPRMxx member responsible for z/OS UNIX System Services (OMVS) 
functions:

RESOLVER_PROC(DEFAULT)

As always there are a number of choices available. In what follows, what is 
suggested conforms to what is expected to be a popular set of such choices. 
For alternatives, please see the appended manual references.

Names which can be chosen freely have been shown in lower case but often 
with, in effect, a suggested value.

In order to customize the resolver, you first need to create a procedure. The 
following is suggested:

SYS1.PROCLIB member name: resolver

//resolver PROC PARMS='CTRACE(CTIRES00)'
//EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//SETUP DD DISP=SHR,FREE=CLOSE,DSN=hlq.pds(resolver)

Use of a partition

Re: EntireX and LOCALHOST

[Gibney, Dave]

Thanks Chris, it appears that we DID finalize our implementing of new
DNS servers and software since the last time these server address spaces
rolled. Now, I get to close another ETR that perhaps I shouldn't have
opened. :)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: Monday, October 25, 2010 3:26 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EntireX and LOCALHOST
> 
> Dave
> 
> It appears that "localhost" is conventionally mapped to 127.0.0.1 by
> the name
> server. If suddenly this mapping no longer seems to operate, it looks
> like
> someone has messed about with your name server and somehow lost the
> statements which perform this mapping.
> 
> This is what I happen to have in a document I put together for a
> customer
> long ago, 2001, concerning how to put a name server together - as
> written by
> someone who knew practically nothing - perhaps learnt just a little
> then - and
> now is again back to knowing practically nothing - about name servers!
> 
> 
> 
> /u/u80158/named.lbk - Loopback File
> 
> 0.0.127.in-addr.arpa. IN SOA testns.testplex x...@x.
>  ( 1 10800 3600 604800 86400 )
> IN NS  t1.testplex.xxx.yy.be.
> 1.0.0.127.in-addr.arpa. IN PTR localhost.
> 
> The Loopback file has the same structure as the Data File. The domain
> is now
> 0.0.127.in-addr.arpa. and not testns.testplex.xxx.yy.be. .
> 
> PTR
> 
> An IN PTR entry provides a mapping between an IP address in the
special
> domain name format and a name. It is recommended always to have an
> entry
> for the name "localhost" mapping to IP address "127.0.0.1".
> 
> Note: Why an IN PTR entry is required rather than using an IN A entry
> is
> something of a name server mystery! It can be appreciated that the
> special
> representation of (partial) IP addresses is used in the same context
as
> names
> (which use IN A entries) in SOA entries.
> 
> 
> 
> There is also a statement
> 
> localhost IN A 127.0.0.1
> 
> in the "Forward or Data File".
> 
> Obviously, the whole document is needed to even start to work out how
a
> name server is constructed and where the localhost/127.0.0.1 mapping
> fits
> into the whole structure.
> 
> Chris Mason
> 
> On Mon, 25 Oct 2010 14:21:50 -0700, Gibney, Dave 
> wrote:
> 
> >I am hoping someone can shed some light and also, I might be able to
> >warn anyone about to take this path.
> >
> >We did a POR to activate MCL maintenance on our z9BC-L03.
> >
> >
> >After the POR and IPL, we had problems with EntireX from Software AG.
> >This system consists of a "broker" address space and several RPC
> address
> >spaces. The communication is via TCPIP loopback.
> >
> >The RPC servers were configured to use LOCALHOST to make the
> connection.
> >Changing to 127.0.0.1 solved our problem.
> >
> >This software had apparently been running since 2007 with the
> LOCALHOST
> >specified in the parms.
> >
> >It took us several hours to determine what was wrong. Fortunately, we
> >found this application was working in another LPAR where 127.0.0.1
and
> >also our internet facing IP address was used instead of LOCALHOST.
> >
> >
> >Dave Gibney
> >Information Technology Services
> >Washington State University
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: EntireX and LOCALHOST

[Chris Mason]

Dave

I suspect, on reflection, Richard would be the first to say that his post 
lacked 
a bit of precision. He didn't so much mean the "Resolver" as what the 
resolver "pointed to", either the use of a name server or a "local file", of 
whichever is your preferred format, or both and which first and which second.

Actually, assuming you are the only one who would mess about with such a 
thing as the "local file", your left hand should have some idea what your right 
hand is doing and so you really should know whether you had cast a local 
version of "localhost" to the four winds. 

So, on this assumption and the assumption that folk over whom you have little 
control are supposed to take care of the name server, my money is on name 
server carelessness.

Incidentally, I see that, prompted by Richard's post, you have shown us how 
your resolver is configured and unfortunately with NOCOMMONSEARCH which, 
if you were managing a "local file" would mean you were still using the tedious 
antique format requiring a conversion utility before it could be used. This 
also 
tends to suggest that the antique "local file" is not used and you rely upon a 
name server for name to address resolution.

I also discovered in scanning the Configuration Guide for "localhost" that what 
I covered in my last post is to be found in Chapter 13, "Domain Name System".

Chris Mason

On Mon, 25 Oct 2010 15:02:35 -0700, Gibney, Dave  
wrote:

>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
>> Behalf Of Richard L Peurifoy
>> Sent: Monday, October 25, 2010 2:41 PM
>> To: IBM-MAIN@bama.ua.edu
>> Subject: Re: EntireX and LOCALHOST
>>
>> On 10/25/2010 4:23 PM, Gibney, Dave wrote:
>> > I am hoping someone can shed some light and also, I might be able to
>> > warn anyone about to take this path.
>> >
>> > We did a POR to activate MCL maintenance on our z9BC-L03.
>> >
>> >
>> > After the POR and IPL, we had problems with EntireX from Software
>AG.
>> > This system consists of a "broker" address space and several RPC
>> address
>> > spaces. The communication is via TCPIP loopback.
>> >
>> > The RPC servers were configured to use LOCALHOST to make the
>> connection.
>> > Changing to 127.0.0.1 solved our problem.
>> >
>> > This software had apparently been running since 2007 with the
>> LOCALHOST
>> > specified in the parms.
>> >
>> > It took us several hours to determine what was wrong. Fortunately,
>we
>> > found this application was working in another LPAR where 127.0.0.1
>> and
>> > also our internet facing IP address was used instead of LOCALHOST.
>>
>> For LOCALHOST to work, it needs to be defined in RESOLVER or in a DNS.
>> Have you dropped a definition that defined LOCALHOST?
>
>Unchanged since 2008:
>GLOBAL   *Browsed 7  2008/05/27  2008/06/04 16:28:32  GIBNEY
>RESOLVER *Browsed 3  2008/05/27  2008/06/18 14:18:54  GIBNEY
>TRESDATA *Browsed 4  2008/05/27  2008/06/18 14:19:04  GIBNEY
>TCPIP.WSUMVS1.PARMLIB(RESOLVER)
>DEFAULTTCPIPDATA('TCPIP.WSUMVS1.PARMLIB(TRESDATA)')
>GLOBALTCPIPDATA('TCPIP.WSUMVS1.PARMLIB(GLOBAL)')
>NOCOMMONSEARCH
> BROWSETCPIP.WSUMVS1.PARMLIB(TRESDATA)
>* Top of Da
>TCPIPJOBNAME  TCPIP
>HOSTNAME  WSUMVS1
>; TRACE   RESOLVER
>DATASETPREFIX TCPIP
> BROWSETCPIP.WSUMVS1.PARMLIB(GLOBAL) -
>* Top of D
>DOMAINORIGIN  IT.WSU.EDU
>NSINTERADDR  134.121.139.10
>NSINTERADDR  134.121.80.36
>NSPORTADDR 53
>RESOLVEVIA UDP
>RESOLVERTIMEOUT 30
>RESOLVERUDPRETRIES 1
>
>>
>> Can you resolve other names from you z/OS system (try PING validname)?
>Yes
>
>>
>> --
>> Richard

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

Re: EntireX and LOCALHOST

[Chris Mason]

Dave

It appears that "localhost" is conventionally mapped to 127.0.0.1 by the name 
server. If suddenly this mapping no longer seems to operate, it looks like 
someone has messed about with your name server and somehow lost the 
statements which perform this mapping.

This is what I happen to have in a document I put together for a customer 
long ago, 2001, concerning how to put a name server together - as written by 
someone who knew practically nothing - perhaps learnt just a little then - and 
now is again back to knowing practically nothing - about name servers!



/u/u80158/named.lbk – Loopback File

0.0.127.in-addr.arpa. IN SOA testns.testplex x...@x. 
 ( 1 10800 3600 604800 86400 )
IN NS  t1.testplex.xxx.yy.be. 
1.0.0.127.in-addr.arpa. IN PTR localhost. 

The Loopback file has the same structure as the Data File. The domain is now 
0.0.127.in-addr.arpa. and not testns.testplex.xxx.yy.be. .

PTR

An IN PTR entry provides a mapping between an IP address in the special 
domain name format and a name. It is recommended always to have an entry 
for the name “localhost” mapping to IP address “127.0.0.1”.

Note: Why an IN PTR entry is required rather than using an IN A entry is 
something of a name server mystery! It can be appreciated that the special 
representation of (partial) IP addresses is used in the same context as names 
(which use IN A entries) in SOA entries. 



There is also a statement

localhost IN A 127.0.0.1  

in the "Forward or Data File".

Obviously, the whole document is needed to even start to work out how a 
name server is constructed and where the localhost/127.0.0.1 mapping fits 
into the whole structure.

Chris Mason

On Mon, 25 Oct 2010 14:21:50 -0700, Gibney, Dave  
wrote:

>I am hoping someone can shed some light and also, I might be able to
>warn anyone about to take this path.
>
>We did a POR to activate MCL maintenance on our z9BC-L03.
>
>
>After the POR and IPL, we had problems with EntireX from Software AG.
>This system consists of a "broker" address space and several RPC address
>spaces. The communication is via TCPIP loopback.
>
>The RPC servers were configured to use LOCALHOST to make the connection.
>Changing to 127.0.0.1 solved our problem.
>
>This software had apparently been running since 2007 with the LOCALHOST
>specified in the parms.
>
>It took us several hours to determine what was wrong. Fortunately, we
>found this application was working in another LPAR where 127.0.0.1 and
>also our internet facing IP address was used instead of LOCALHOST.
>
>
>Dave Gibney
>Information Technology Services
>Washington State University

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

Re: EntireX and LOCALHOST

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Richard L Peurifoy
> Sent: Monday, October 25, 2010 2:41 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: EntireX and LOCALHOST
> 
> On 10/25/2010 4:23 PM, Gibney, Dave wrote:
> > I am hoping someone can shed some light and also, I might be able to
> > warn anyone about to take this path.
> >
> > We did a POR to activate MCL maintenance on our z9BC-L03.
> >
> >
> > After the POR and IPL, we had problems with EntireX from Software
AG.
> > This system consists of a "broker" address space and several RPC
> address
> > spaces. The communication is via TCPIP loopback.
> >
> > The RPC servers were configured to use LOCALHOST to make the
> connection.
> > Changing to 127.0.0.1 solved our problem.
> >
> > This software had apparently been running since 2007 with the
> LOCALHOST
> > specified in the parms.
> >
> > It took us several hours to determine what was wrong. Fortunately,
we
> > found this application was working in another LPAR where 127.0.0.1
> and
> > also our internet facing IP address was used instead of LOCALHOST.
> 
> For LOCALHOST to work, it needs to be defined in RESOLVER or in a DNS.
> Have you dropped a definition that defined LOCALHOST? 

Unchanged since 2008:
GLOBAL   *Browsed 7  2008/05/27  2008/06/04 16:28:32  GIBNEY
RESOLVER *Browsed 3  2008/05/27  2008/06/18 14:18:54  GIBNEY
TRESDATA *Browsed 4  2008/05/27  2008/06/18 14:19:04  GIBNEY
TCPIP.WSUMVS1.PARMLIB(RESOLVER)
DEFAULTTCPIPDATA('TCPIP.WSUMVS1.PARMLIB(TRESDATA)') 
GLOBALTCPIPDATA('TCPIP.WSUMVS1.PARMLIB(GLOBAL)')
NOCOMMONSEARCH  
 BROWSETCPIP.WSUMVS1.PARMLIB(TRESDATA) 
* Top of Da
TCPIPJOBNAME  TCPIP
HOSTNAME  WSUMVS1  
; TRACE   RESOLVER 
DATASETPREFIX TCPIP
 BROWSETCPIP.WSUMVS1.PARMLIB(GLOBAL) -
* Top of D
DOMAINORIGIN  IT.WSU.EDU  
NSINTERADDR  134.121.139.10   
NSINTERADDR  134.121.80.36
NSPORTADDR 53 
RESOLVEVIA UDP
RESOLVERTIMEOUT 30
RESOLVERUDPRETRIES 1  

> 
> Can you resolve other names from you z/OS system (try PING validname)?
Yes

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

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

Re: PDSE versus PDS

[John McKown]

On Mon, 2010-10-25 at 11:48 -0300, Clark Morris wrote:
> On 25 Oct 2010 04:49:29 -0700, in bit.listserv.ibm-main you wrote:
> 
> >>The decision not to support IPL-time use of PDSEs was an unconscionable 
> >one. ,
> >
> >OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone 
> >also needs to be in a PDSE?
> >
> >It is SYS1.NUCLEUS and LPA modules that cannot be in PDSEs. LNKLST modules 
> >can be.. And for most cases dynamic LPA can be used to add modules to LPA 
> >(from PDSEs) in advance of an application's need to use those modules. And 
> >for the cases that could not be used, I believe the "deferred LPA wait" 
> >processing introduced in z/OS 1.12 covers at least a high percentage.
> >
> >FWIW, the "decision" had to do with extreme cost (and possible sacrifice 
> >of RAS), not conscience, considering in part that all support code would 
> >not only have to be within IEANUC0x but also could not be in its own 
> >address space as, without a massive restructure,t would all have to be in 
> >place before LPA was built (which in turn is before the system can go 
> >multi-address-space). 
> 
> I want to get rid of PDSs.  My vision for the future is that all data
> reside in FBA data areas: PDSE, VSAM (ESDS, RRDS, KSDS, Linear), zFS
> etc.  Only the code to read PDSE needs to be available at NIP and IPL.
> Right now there is CKD function for which there is no FBA equivalent
> in zOS (generation data groups, some concatenation, spool and maybe a
> couple of others) but I don't advocate carrying over CKD in toto to
> new world.  Obviously there would be a long transition period.
> 
> Clark Morris

Clark,

I think you'd love parts of how the "i" (aka AS/400) works. It is truly
fascinating! All of disk is basically just one big page space.
Everything is an object of some sort. 

-- 
John McKown
Maranatha! <><

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

Re: PDSE versus PDS

[Phil Smith]

Rick Fochtman wrote:
>I have to think that the complexity of the code changes required would also 
>mitigate against this changes as well.

That's "militate against". (Yeah, common error, pet peeve.)

...phsiii

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

Re: PDSE versus PDS

[John McKown]

That's because you're one of the practical ones. I was raised as a
Mathematician, not an Engineer! It needs to be done because it is
"elegant" to do so.  Costs money? What does that have do to with
it 

On Mon, 2010-10-25 at 23:08 +1000, Shane wrote:
> Ya gotta love this guy.
> People hypothesizing (pontificating ?) all over the place, and the
> voice of reason brings all crashing back to earth.
> 
> Shane ...
> (and yes, I've dissed PDSEs at least as much as everyone else)
> 
> On Mon, 25 Oct 2010 07:48:39 -0400
> Peter Relson wrote:
> 
> > OK, I'll bite. What code of *yours* needs to run at IPL-time, let
> > alone also needs to be in a PDSE?
> ...
> 

-- 
John McKown
Maranatha! <><

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

Re: EntireX and LOCALHOST

[Richard L Peurifoy]

On 10/25/2010 4:23 PM, Gibney, Dave wrote:

I am hoping someone can shed some light and also, I might be able to
warn anyone about to take this path.

We did a POR to activate MCL maintenance on our z9BC-L03.


After the POR and IPL, we had problems with EntireX from Software AG.
This system consists of a "broker" address space and several RPC address
spaces. The communication is via TCPIP loopback.

The RPC servers were configured to use LOCALHOST to make the connection.
Changing to 127.0.0.1 solved our problem.

This software had apparently been running since 2007 with the LOCALHOST
specified in the parms.

It took us several hours to determine what was wrong. Fortunately, we
found this application was working in another LPAR where 127.0.0.1 and
also our internet facing IP address was used instead of LOCALHOST.


For LOCALHOST to work, it needs to be defined in RESOLVER or in a DNS.
Have you dropped a definition that defined LOCALHOST?

Can you resolve other names from you z/OS system (try PING validname)?

--
Richard

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

Re: PDSE versus PDS

[Rick Fochtman]

--
 

The decision not to support IPL-time use of PDSEs was an unconscionable one.  It would indeed be easy to caricature it as sabotage.   

   


Perhaps likewise the decision not to support network-mounted files
at IPL-time.  But Mr. Blair is wont to deem such outcomes not as
affirmative decisions, but to assert that no such alternative was
ever given consideration; not so much asn unconscionable choice as
an unconscious one.
 



I have to think that the cxomplexity of the code changes required would 
also mitigate angainst this changes as well.



The other notional deficiencies that have been cited here are, many of 
them, virtues; and the long list of PDS deficiencies that were addressed 
and largely removed for PDSEs, among them the radically deficient 
processing of PDS member aliases, has been passed over in silence.



I understand that when a PDS member name is removed by BLDL aliases
are not removed.  Whether this is "radically deficient" depends in large
part on what happens when the remaining aliases are referenced or when
the PDS is compressed.  I don't know.

The decision might easily have been made in the opposite sense:  Allow
members to have multiple equipotent names such that when any one is
removed any others remain effective, the space occupied by the member
being reclaimed only when the reference count is reduced to zero.
 


-
I think you meant STOW, rather than BLDL.

This business of not deleting the code until all the aliases are removed 
has been the same as the PDS ever since PDSE "hit the street. As long as 
a directlry entry still referes to the starting TTR of the emmber, it 
will be retained. Nothing I've read makes me believe that PDSE operates 
any differently.


Nothing new or different here. And STOW only removes one name at a time.

Rick

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

EntireX and LOCALHOST

[Gibney, Dave]

I am hoping someone can shed some light and also, I might be able to
warn anyone about to take this path.

We did a POR to activate MCL maintenance on our z9BC-L03.


After the POR and IPL, we had problems with EntireX from Software AG.   
This system consists of a "broker" address space and several RPC address
spaces. The communication is via TCPIP loopback.

The RPC servers were configured to use LOCALHOST to make the connection.
Changing to 127.0.0.1 solved our problem.   

This software had apparently been running since 2007 with the LOCALHOST 
specified in the parms. 

It took us several hours to determine what was wrong. Fortunately, we   
found this application was working in another LPAR where 127.0.0.1 and  
also our internet facing IP address was used instead of LOCALHOST.  


Dave Gibney
Information Technology Services
Washington State University

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

Re: VSAM delete without Cluster

[R.S.]

W dniu 2010-10-25 21:07, Larry Macioce pisze:

Many years ago we would find the vsam data, then flip the bit to make the
system think it was a pds then just delete it.
I will look but, somehere might be able to help you quicker.


...and got trash entries in VVDS. There are proven, safe and supported 
ways to delete uncataloged VSAM dataset. Cheating VTOC entries is not 
one of them.


Supported way to delete uncataloged VSAM component
//K10  EXEC PGM=IDCAMS
//DYSK DD DISP=SHR,UNIT=3390,VOL=SER=volser
//SYSPRINT DD SYSOUT=*
//SYSINDD *
 DEL HLQ.BE08.KSDS1.DATA VVR FILE(DYSK)

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 16.07.2010 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 168.248.328 zotych.

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

IBMLink, ResourceLink could not be access IBM Network problems

[Knutson, Sam]

It seems IBM had some network problems today.  We have had problems with
access to both IBMLink ResourceLink in addition to the ShopzSeries
problems already mentioned today.

 

IBMLink help desk acknowledged network problems but expected they were
all resolved.  It appears they have resolved now.

 

Best Regards, 

Sam Knutson, GEICO 
System z Team Leader 
mailto:sknut...@geico.com   
(office)  301.986.3574 
(cell) 301.996.1318  

"Think big, act bold, start simple, grow fast..." 

 


This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

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

Re: VSAM delete without Cluster

[Gibney, Dave]

DELETE dsname VVR FILE(ddname)

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
> Behalf Of Larry Macioce
> Sent: Monday, October 25, 2010 12:08 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: VSAM delete without Cluster
> 
> Many years ago we would find the vsam data, then flip the bit to make
> the
> system think it was a pds then just delete it.
> I will look but, somehere might be able to help you quicker.
> Mace
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: VSAM delete without Cluster

[Larry Macioce]

Many years ago we would find the vsam data, then flip the bit to make the 
system think it was a pds then just delete it.
I will look but, somehere might be able to help you quicker.
Mace

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

Re: VSAM delete without Cluster

[Mark Jacobs]

On 10/25/10 14:58, Ed. Benoit wrote:

Hello
I have a VSAM dataset on a pack.  The cluster is no where to be  found.  I
do not need the dataset.
The Online ISPF 3.4 do not allow a Delete, Rename, or Catalog command
foreground.
Question:  Can I use a batch IDCAMS job to scratch these datasets and  if
so,  please sent JCL and control Cards.

Ed.

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

   


Have you tried a define recatalog and then a delete?

--
Mark Jacobs
Time Customer Service
Tampa, FL


Sam Lowry: Give my best to Alison and the twins.
Jack Lint: Triplets.
Sam Lowry: Triplets? My how time flies

Brazil (1985)

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

Re: CA-OPS/MVS to IBM's System Automation?

[Glenn Miller]

We did that same migration about 5 years ago during the 'transformation' to
IBM as part of the outsource to IBM Global Services.  One of the key
'facilities/functions' we "lost" was the use of the OPS/MVS "OPSAOF"
operator command.  The "OPSAOF" command allows a console operator ( or
anyone/anything else ) to LIST, ENABLE or DISABLE OPS/MVS Rules.  We used
"OPSAOF" to disable some OPS/MVS Message rules that would get triggered when
any of our very important Started Tasks would get shutdown, like during the
shutdown of z/OS prior to an IPL.  We were told that SA/390 had no facility
like "OPSAOF".  For example, at the beginning of our z/OS shutdown process,
we had the following commands issued:

OPSAOF DISABLE MSG.msgrule1
OPSAOF RESETAUTO MSG.msgrule1
OPSAOF DISABLE MSG.msgrule2
OPSAOF RESETAUTO MSG.msgrule2
. etc etc etc etc ...

Disabling these OPS/MVS "MSG Rules" would prevent unnecessary SNMP messages
being sent ( by these "MSG Rules" to our CA-Unicenter server.  Note that the
"RESETAUTO" command will keep the "MSG Rule" disabled when OPS/MVS starts,
say during the next IPL/Startup.

Then at the end of our z/OS startup process, we had the following commands
issued:
OPSAOF ENABLE MSG.msgrule1
OPSAOF SETAUTO MSG.msgrule1
OPSAOF ENABLE MSG.msgrule2
OPSAOF SETAUTO MSG.msgrule2
. etc etc etc etc ...


We also would disabled an individual "MSG Rule" whenever we needed to
shutdown a specific Started Task.  Why send out 'alerts' to the 'world' when
we are shutting down a Started Task, say for maintenance.

HTH

Glenn Miller

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

VSAM delete without Cluster

[Ed. Benoit]

Hello
I have a VSAM dataset on a pack.  The cluster is no where to be  found.  I 
do not need the dataset. 
The Online ISPF 3.4 do not allow a Delete, Rename, or Catalog command  
foreground.
Question:  Can I use a batch IDCAMS job to scratch these datasets and  if 
so,  please sent JCL and control Cards.
 
Ed.

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

Re: z/os 1.11 and low private

[Veilleux, Jon L]

Maybe my mind is going south...lol
I was thinking of the GETMAIN changes that caused a lot of 0C4 abends. Since we 
complained about that so much IBM was especially sensitive to changes in 
behavior affecting customers, so some of them made it a practice to make new 
function be explicitly requested which has the unfortunate side effect that you 
mention.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Bob Shannon
Sent: Monday, October 25, 2010 2:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

> Did you mean you need to explicitly request to use the new behavior by 
> coding VSM >USEZOSV1R9RULES(NO)

A lot of early 1.10 customers did not complain. By making 1.9 the default, 
customers who want the new behavior will have to code this forever.

Bob Shannon

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: z/os 1.11 and low private

[Bob Shannon]

> Did you mean you need to explicitly request to use the new behavior by coding 
> VSM >USEZOSV1R9RULES(NO)

A lot of early 1.10 customers did not complain. By making 1.9 the default, 
customers who want the new behavior will have to code this forever.

Bob Shannon

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

Re: Design question for a UNIX facility similar to TSO SEND command

[John McKown]

I guess that there is little interest in this. I got something working. I
use CA-OPS/MVS to trap the SEND command. I use that to issue a new command,
SENDUNIX. The SENDUNIX command is also implemented as a CA-OPS/MVS command
rule. It sends the entire command string to a UNIX shell script, written in
REXX. This REXX UNIX shell script eventually uses the UNIX "mailx" command
to send the text to the user's mailbox. This works fine in a single image. 

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

Re: z/os 1.11 and low private

[Pommier, Rex R.]

OK, Now I see where my confusion was coming from.  In your first post, where 
you said



IBM changed the default to use the old rules and required you to explicitly 
request to use the new rules by coding VSM USEZOSV1R9RULES(YES).



You meant that IBM is now defaulting it to YES by coding the USEV1R9RULES(YES) 
and if I want to change it I need to explicitly code NO.  I took your post to 
say that I would need to code (YES) to get the behavior to change, when that's 
the default.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Veilleux, Jon L
Sent: Monday, October 25, 2010 12:57 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

When IBM first came out with this change they had NO as the default, but after 
the ESP participants complained enough they changed it to YES. So now you 
shouldn't have to do anything if you want it to work the old way.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Pommier, Rex R.
Sent: Monday, October 25, 2010 1:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Jon,

I'm confused now.  Did you mean you need to explicitly request to use the new 
behavior by coding VSM USEZOSV1R9RULES(NO)  instead of YES?  It appears from 
the doc that the default is YES which leaves the behavior unchanged.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Veilleux, Jon L
Sent: Monday, October 25, 2010 11:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Back during the ESP for 1.11 we ran into issues because the default was to use 
the new rules. After a LOT of complaining from multiple customers IBM changed 
the default to use the old rules and required you to explicitly request to use 
the new rules by coding VSM USEZOSV1R9RULES(YES).

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe D'Alessandro
Sent: Monday, October 25, 2010 12:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Hello:
One of the DIAGxx parameters addresses an optional change to the merging of 
DQEs in PVT after v1.9:  do you specify this parm to use the new rules (I am 
quoting from INIT and TUNING)?

"VSM USEZOSV1R9RULES(NO|YES)

"YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from its 
historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior for 
user-region private area subpools that are both below and above the line to be 
implemented. Thus DQEs can be merged where possible. The default is YES to 
provide a seamless migration. However, IBM recommends that you specify
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools.

The usage pattern of v/s could change due to the new rules, and if the v1.9 fit 
was snug, a small change in the usage pattern might set off a
s878/80A/106 situation.

regards, Joe D'Alessandro


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited. If you received this e-mail in error, please reply to 
sender and destroy or delete the message and any attachments. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna

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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited. If you received this e-mail in error, please reply to 
sender and destroy or delete the message and any attachments. Thank you.

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

Re: z/os 1.11 and low private

[Veilleux, Jon L]

When IBM first came out with this change they had NO as the default, but after 
the ESP participants complained enough they changed it to YES. So now you 
shouldn't have to do anything if you want it to work the old way.


-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Pommier, Rex R.
Sent: Monday, October 25, 2010 1:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Jon,

I'm confused now.  Did you mean you need to explicitly request to use the new 
behavior by coding VSM USEZOSV1R9RULES(NO)  instead of YES?  It appears from 
the doc that the default is YES which leaves the behavior unchanged.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Veilleux, Jon L
Sent: Monday, October 25, 2010 11:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Back during the ESP for 1.11 we ran into issues because the default was to use 
the new rules. After a LOT of complaining from multiple customers IBM changed 
the default to use the old rules and required you to explicitly request to use 
the new rules by coding VSM USEZOSV1R9RULES(YES).

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe D'Alessandro
Sent: Monday, October 25, 2010 12:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Hello:
One of the DIAGxx parameters addresses an optional change to the merging of 
DQEs in PVT after v1.9:  do you specify this parm to use the new rules (I am 
quoting from INIT and TUNING)?

"VSM USEZOSV1R9RULES(NO|YES)

"YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from its 
historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior for 
user-region private area subpools that are both below and above the line to be 
implemented. Thus DQEs can be merged where possible. The default is YES to 
provide a seamless migration. However, IBM recommends that you specify
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools.

The usage pattern of v/s could change due to the new rules, and if the v1.9 fit 
was snug, a small change in the usage pattern might set off a
s878/80A/106 situation.

regards, Joe D'Alessandro


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited. If you received this e-mail in error, please reply to 
sender and destroy or delete the message and any attachments. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: z/os 1.11 and low private

[Pommier, Rex R.]

Jon,

I'm confused now.  Did you mean you need to explicitly request to use the new 
behavior by coding VSM USEZOSV1R9RULES(NO)  instead of YES?  It appears from 
the doc that the default is YES which leaves the behavior unchanged.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Veilleux, Jon L
Sent: Monday, October 25, 2010 11:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Back during the ESP for 1.11 we ran into issues because the default was to use 
the new rules. After a LOT of complaining from multiple customers IBM changed 
the default to use the old rules and required you to explicitly request to use 
the new rules by coding VSM USEZOSV1R9RULES(YES).

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe D'Alessandro
Sent: Monday, October 25, 2010 12:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Hello:
One of the DIAGxx parameters addresses an optional change to the merging of 
DQEs in PVT after v1.9:  do you specify this parm to use the new rules (I am 
quoting from INIT and TUNING)?

"VSM USEZOSV1R9RULES(NO|YES)

"YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from its 
historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior for 
user-region private area subpools that are both below and above the line to be 
implemented. Thus DQEs can be merged where possible. The default is YES to 
provide a seamless migration. However, IBM recommends that you specify
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools.

The usage pattern of v/s could change due to the new rules, and if the v1.9 fit 
was snug, a small change in the usage pattern might set off a
s878/80A/106 situation.

regards, Joe D'Alessandro


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited. If you received this e-mail in error, please reply to 
sender and destroy or delete the message and any attachments. Thank you.

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

Re: How do I determine Enterprise COBOL for z/OS release level from outside COBOL or LE environment?

[Tom Ross]

>Our ISV product displays message descriptions under ISPF on z/OS. I want to
>determine the correct COBOL release level installed so that our product can
>automatically display the correct COBOL compiler and runtime message
>descriptions for that system. We do this automatic release level detection
>already for z/OS message,  VTAM messages, RACF messages, HLASM messages,
>etc. I'd like to do the same for COBOL. I just want to determine the release
>level of COBOL installed without invoking the COBOL compiler.

COBOL runtime messages all come from LE, and you can tell what release
of LE (Language Environment) from the z/OS Operating System level.

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

Re: z/os 1.11 and low private

[Joe D'Alessandro]

Hello:
One of the DIAGxx parameters addresses an optional change to the merging of 
DQEs in PVT after v1.9:  do you specify this parm to use the new rules (I am 
quoting from INIT and TUNING)?

"VSM USEZOSV1R9RULES(NO|YES)

"YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from 
its historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior for 
user-region private area subpools that are both below and above the line to 
be implemented. Thus DQEs can be merged where possible. The default is YES 
to provide a seamless migration. However, IBM recommends that you specify 
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with 
long DQE/FQE chains for user-region private area subpools.

The usage pattern of v/s could change due to the new rules, and if the v1.9 
fit was snug, a small change in the usage pattern might set off a 
s878/80A/106 situation.  

regards, Joe D'Alessandro

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

Re: z/os 1.11 and low private

[Veilleux, Jon L]

Back during the ESP for 1.11 we ran into issues because the default was to use 
the new rules. After a LOT of complaining from multiple customers IBM changed 
the default to use the old rules and required you to explicitly request to use 
the new rules by coding VSM USEZOSV1R9RULES(YES).

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Joe D'Alessandro
Sent: Monday, October 25, 2010 12:35 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: z/os 1.11 and low private

Hello:
One of the DIAGxx parameters addresses an optional change to the merging of 
DQEs in PVT after v1.9:  do you specify this parm to use the new rules (I am 
quoting from INIT and TUNING)?

"VSM USEZOSV1R9RULES(NO|YES)

"YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from its 
historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior for 
user-region private area subpools that are both below and above the line to be 
implemented. Thus DQEs can be merged where possible. The default is YES to 
provide a seamless migration. However, IBM recommends that you specify
USEZOSV1R9RULES(NO) to obtain a performance benefit for applications with long 
DQE/FQE chains for user-region private area subpools.

The usage pattern of v/s could change due to the new rules, and if the v1.9 fit 
was snug, a small change in the usage pattern might set off a
s878/80A/106 situation.  

regards, Joe D'Alessandro

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna   

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

Re: PDSE versus PDS

[Clark Morris]

On 25 Oct 2010 04:49:29 -0700, in bit.listserv.ibm-main you wrote:

>>The decision not to support IPL-time use of PDSEs was an unconscionable 
>one. ,
>
>OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone 
>also needs to be in a PDSE?
>
>It is SYS1.NUCLEUS and LPA modules that cannot be in PDSEs. LNKLST modules 
>can be.. And for most cases dynamic LPA can be used to add modules to LPA 
>(from PDSEs) in advance of an application's need to use those modules. And 
>for the cases that could not be used, I believe the "deferred LPA wait" 
>processing introduced in z/OS 1.12 covers at least a high percentage.
>
>FWIW, the "decision" had to do with extreme cost (and possible sacrifice 
>of RAS), not conscience, considering in part that all support code would 
>not only have to be within IEANUC0x but also could not be in its own 
>address space as, without a massive restructure,t would all have to be in 
>place before LPA was built (which in turn is before the system can go 
>multi-address-space). 

I want to get rid of PDSs.  My vision for the future is that all data
reside in FBA data areas: PDSE, VSAM (ESDS, RRDS, KSDS, Linear), zFS
etc.  Only the code to read PDSE needs to be available at NIP and IPL.
Right now there is CKD function for which there is no FBA equivalent
in zOS (generation data groups, some concatenation, spool and maybe a
couple of others) but I don't advocate carrying over CKD in toto to
new world.  Obviously there would be a long transition period.

Clark Morris
>
>Peter Relson
>z/OS Core Technology Design
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: PDSE versus PDS

[Clark Morris]

On 25 Oct 2010 04:41:28 -0700, in bit.listserv.ibm-main you wrote:

>At 02:28 + on 10/25/2010, john gilmore wrote about Re: PDSE versus PDS:
>
>>The decision not to support IPL-time use of PDSEs was an 
>>unconscionable one.  It would indeed be easy to caricature it as 
>>sabotage.
>
>You have a "Chicken and Egg" situation with IPL Time support for 
>PDSEs. How much  of an environment must exist before PDSEs support is 
>possible? For IPL Time PDSE usage you have to build that environment 
>somehow.  This means that you have to get the code from somewhere. 
>Right now, by having SYS1.PARMLIB and SYS1.NUCLEUS as PDS-Only you 
>can bootstrap the PDS support into existence. I think that this would 
>not be possible if you needed to also create the PDSE infrastructure 
>to allow the IPL Datasets to be PDSEs.

Given today's large disks and memory, just load all the code from a
sequential data set or member and branch to it.  Maybe combine NIP and
much of SYS1.NUCLEUS into one data set.  I suppose this is the same
argument that was used for not having support at NIP for locally
attached SNA devices as consoles.  

Clark Morris
>
>Since you raise the issue, where are you planning to get the codebase 
>from to allow the system to be IPL'ed?
>

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

Re: Shopzseries down?

[Jim Ladouceur]

I guess I've been lucky then. I don't use it often, and until now have had no 
problems. Oh well ..

Jim LaDouceur | Principal Systems Engineer | Infor | office: 508-598-4066 | 
jim.ladouc...@infor.com 

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of 
Bob Shannon
Sent: 2010-10-25 10:11
To: IBM-MAIN@bama.ua.edu
Subject: Re: Shopzseries down?

>Has anyone been able to get into Shopz today? I'm getting the following 
>message:

>ShopzSeries is temporarily unavailable for maintenance.
>ShopzSeries is scheduled to resume normal operations by Saturday, October 24th 
>at 12:00 AM >MDT / 06:00 GMT.

I haven't tried today, but IMO ShopZ is very unreliable. A couple of weeks ago 
I opened a problem and they said they had a problem open with the developer. 
Testing doesn't seem to be a priority.

Bob Shannon

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

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

Re: Shopzseries down?

[Bob Shannon]

>Has anyone been able to get into Shopz today? I'm getting the following 
>message:

>ShopzSeries is temporarily unavailable for maintenance.
>ShopzSeries is scheduled to resume normal operations by Saturday, October 24th 
>at 12:00 AM >MDT / 06:00 GMT.

I haven't tried today, but IMO ShopZ is very unreliable. A couple of weeks ago 
I opened a problem and they said they had a problem open with the developer. 
Testing doesn't seem to be a priority.

Bob Shannon

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

Re: Shopzseries down?

[Mark Pace]

Seems they have missed their window.

On Mon, Oct 25, 2010 at 10:00 AM, Jim Ladouceur wrote:

> Good morning,
>
> Has anyone been able to get into Shopz today? I'm getting the following
> message:
>
> ShopzSeries is temporarily unavailable for maintenance.
> ShopzSeries is scheduled to resume normal operations by Saturday, October
> 24th at 12:00 AM MDT / 06:00 GMT.
>
> Thanks,
> Jim
>
> Jim LaDouceur | Principal Systems Engineer | Infor | office: 508-598-4066 |
> jim.ladouc...@infor.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: PDSE versus PDS

[john gilmore]

My last post should of course have had this subject.  "PDSE versus PDSE" is too 
tendentious.

John Gilmore Ashland, MA 01721-1817 USA

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

Shopzseries down?

[Jim Ladouceur]

Good morning,

Has anyone been able to get into Shopz today? I'm getting the following message:

ShopzSeries is temporarily unavailable for maintenance.
ShopzSeries is scheduled to resume normal operations by Saturday, October 24th 
at 12:00 AM MDT / 06:00 GMT.

Thanks,
Jim

Jim LaDouceur | Principal Systems Engineer | Infor | office: 508-598-4066 | 
jim.ladouc...@infor.com


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

Re: PDSE versus PDSE

[john gilmore]

I am glad that my post touched a nerve.  Peter Relson's counter-post provided 
valuable information.
 
What I have read about "deferred LPA wait"---I have not yet used it---suggests 
that it does address the  LPA problems I have encountered.
 
I will forgive him his SYS1.NUCLEUS jibe, since the rest of his post makes it 
clear that he knows very well where the real problem lies.
 
PDSEs were an initiative that deserved to succeed, as I tried to make clear in 
my original post, which was not generically hostile to them.  
 
RAS problems with them at what I shall now call LPA-construction time needed to 
be addressed, but doing so was apparently perceived as too formidable a 
problem.  
 
I do not have the information that would be needed to second guess that 
judgment;  but addressing these RAS problems at the outset would have made 
PDSEs more robust everywhere. Then perhaps we should not have found ourselves 
in the situation we confront now, in which trailing-edge, risk-averse, always 
too conservative people are still rehearsing old war stories about deficiencies 
of PDSEs that have already been remedied.

John Gilmore Ashland, MA 01721-1817 USA


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

Re: Abending TCB

[Shane]

On Mon, 25 Oct 2010 13:23:00 +
john gilmore wrote:

> In practical terms, it is always necessary to provide
> diagnostics and messages  before recovery is attempted (tacitly
> assuming that recovery will fail) because the diagnostics and
> messages  provided afterwards will be actively misleading.

Cue Barbaras entry stage left ...
As some poor mug that has on occasion to try and diagnose "situations"
without access to source or design (???) decisions, I *really* object
to useless/misleading diagnostic info.
I object even more to being told it ain't my business to investigate
such non-existent/useless/misleading junk.

IBM is as guilty as any other vendor.

Shane ...

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

BPX.STOR.SWAP

[Chase, John]

Cross-posted to IBM-MAIN and MVS-OE

 

Hi, All,

 

We're on z/OS 1.11, trying to run the CICS Transaction Gateway (version
8.0) under an ID with a non-zero UID, and receive the following message
at startup:

 

CTG6883E Call to make address space non-swappable failed with return
code = -1, errno = 139, errno2 = 0X930

 

Message explanation (from QuickRef):

 

"The error number and error reason will indicate the cause of the
failure.  

Detailed descriptions of these errors can be found in the z/OS C/C++


Run-Time Library Reference under the __mlockall() library function. If
the 

user ID running the CICS Transaction Gateway does not have READ access
to  

BPX.STOR.SWAP, errno is set to 139 - EPERM - and the reason code
0X930."

 

In _Unix System Services Planning_, I see that if the BPX.STOR.SWAP
profile is NOT defined (currently true here), then address spaces
running with UID(0) can make themselves non-swappable while others
cannot.  But if BPX.STOR.SWAP is defined (with UACC(NONE)), then only
those IDs specifically permitted to it (including superusers) can make
their address spaces non-swappable.

 

First question:  What other tasks might "break" if we define the
BPX.STOR.SWAP profile and don't immediately include all current UID(0)
users in its access list?

 

More questions likely, depending on responses.

 

TIA,

 

-jc-

 


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

Re: Abending TCB

[john gilmore]

I sometimes think that there should be a charge for Chris Craddock's advice.  
As usual it would be hard to improve upon:
 

Most of the time the better path of valor is to request diagnostics, burp up a 
message about what went wrong and then percolate.
You will seldom get in trouble for bailing out, but a surprising number of 
major failures come from ill-advised retry efforts.

 
It is not only that "illl-advised retry efforts" too often produce major 
failures.  Even when they merely fail they muddy the waters: the situation at 
ABEND is obscured, making the diagnosis of what triggered it much more 
difficult.  
 
Galen's old maxim for physicians---Above all do no harm---should be kept 
constantly in mind in writing recovery-attempt code.  In particular, diagnostic 
information supplied after a recovery attempt will be worse than useless.   In 
practical terms, it is always necessary to provide diagnostics and messages  
before recovery is attempted (tacitly assuming that recovery will fail) because 
the diagnostics and messages  provided afterwards will be actively misleading.
 
Finally---I am fresh from an experience in which it was not---recovery code 
must be kept at the same maintenance level as the routines for which it 
provides recovery.  Again in practical terms, this means that it must be 
changed and reassembled every time these routines are changed. 

John Gilmore Ashland, MA 01721-1817 USA


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

Re: PDSE versus PDS

[Shane]

Ya gotta love this guy.
People hypothesizing (pontificating ?) all over the place, and the
voice of reason brings all crashing back to earth.

Shane ...
(and yes, I've dissed PDSEs at least as much as everyone else)

On Mon, 25 Oct 2010 07:48:39 -0400
Peter Relson wrote:

> OK, I'll bite. What code of *yours* needs to run at IPL-time, let
> alone also needs to be in a PDSE?
...

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

Re: PDSE versus PDS

[Peter Relson]

>The decision not to support IPL-time use of PDSEs was an unconscionable 
one. ,

OK, I'll bite. What code of *yours* needs to run at IPL-time, let alone 
also needs to be in a PDSE?

It is SYS1.NUCLEUS and LPA modules that cannot be in PDSEs. LNKLST modules 
can be.. And for most cases dynamic LPA can be used to add modules to LPA 
(from PDSEs) in advance of an application's need to use those modules. And 
for the cases that could not be used, I believe the "deferred LPA wait" 
processing introduced in z/OS 1.12 covers at least a high percentage.

FWIW, the "decision" had to do with extreme cost (and possible sacrifice 
of RAS), not conscience, considering in part that all support code would 
not only have to be within IEANUC0x but also could not be in its own 
address space as, without a massive restructure,t would all have to be in 
place before LPA was built (which in turn is before the system can go 
multi-address-space). 

Peter Relson
z/OS Core Technology Design

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

Re: PDSE versus PDS

[Robert A. Rosenberg]

At 02:28 + on 10/25/2010, john gilmore wrote about Re: PDSE versus PDS:

The decision not to support IPL-time use of PDSEs was an 
unconscionable one.  It would indeed be easy to caricature it as 
sabotage.


You have a "Chicken and Egg" situation with IPL Time support for 
PDSEs. How much  of an environment must exist before PDSEs support is 
possible? For IPL Time PDSE usage you have to build that environment 
somehow.  This means that you have to get the code from somewhere. 
Right now, by having SYS1.PARMLIB and SYS1.NUCLEUS as PDS-Only you 
can bootstrap the PDS support into existence. I think that this would 
not be possible if you needed to also create the PDSE infrastructure 
to allow the IPL Datasets to be PDSEs.


Since you raise the issue, where are you planning to get the codebase 
from to allow the system to be IPL'ed?


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