Re: SMS Routines help

[Vernooij, Kees (ITOPT1) - KLM]

I don't think this is an SMS problem, SMS would not allocate a (new) dataset to 
a non-existing volume.
I think the dataset exists and is cataloged to a volume that is not available 
in your system. What does the catalog say about this dataset?

Sometimes it is more efficient to ask help for your original problem, than for 
your intended solution.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ward, Mike S
> Sent: 28 February, 2017 23:53
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS Routines help
> 
> Because doing a TSO/PDF submit we keep getting these errors, and we
> believe it is an SMS probem.
> 
> ,IKJ56221I DATA SET S250MWE.SPFTEMP0.CNTL NOT ALLOCATED, VOLUME NOT
> AVAILABLE+,
> ,IKJ56221I VOLUME  NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND
> CANNOT B
> E MOUNTED,
> ,***,
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, February 28, 2017 3:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS Routines help
> 
> Ward,
> 
> Why do you want to nullify the SMS functions?  Just curious?
> 
> I think you can have very simple ACS Constructs, like others have
> posted. Or I think you can have an empty SCDS (not sure you would need
> to look this up)
> 
> When you copied the datasets and catalogs from PRD to Sandbox, you
> probably have ACS entries (DC/MC/SC/SG) assigned to the files.  Are you
> trying to nullify those?
> 
> Thanks
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Ward, Mike S
> > Sent: Tuesday, February 28, 2017 1:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SMS Routines help
> >
> > Hello all, we set up a sandbox LPAR where we just basically copied all
> > the operating environment (z/OS 2.2) from prod system to the sandbox.
> > What we want to do is turn off or nullify the SMS routines for a short
> > time. I have spent all morning and part of the afternoon looking for a
> > way to do that, but have come up empty handed. Can anyone give me an
> > idea of how to do that or point to some reading material that outlines
> what I need to do?
> >
> > Thanks.
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee, you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received this
> message by mistake and delete this e-mail from your system. If you are
> not the intended recipient, you are notified that disclosing, copying,
> distributing or taking any action in reliance on the contents of this
> information is strictly prohibited.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Software vendor trying to force MSU based contract

[Brian Westerman]

We maintain over 100 sites either fully or partially, and we run into this type 
of problem from time to time.

We had a recent problem where our Software AG software attempted to increase 
the cost based on SAG MSU's instead of IBM MSU's, even though the box had not 
changed (just the location was moved 2 miles away from the old data center) 
which we tangled with them over (and won).  

Some of the sites we help manage are University and County/State Government 
sites which seem to have been convinced several years back by vendors when the 
sites began to shrink in size to purchase "one-time-charge" and "perpetual" 
licenses, and it has come back to bite the vendors as the sites are still 
around.  Some vendors will allow them to upgrade to the "current" version at 
any time, but we found that some are very strict about the version they can 
run.  The worst ones were those that said as long as they don't change the 
version it was okay to keep running, knowing that the older version isn't 
supported on a newer z/OS release.  Unless it specifically says that the 
version is restricted in the original (perpetual) license though, they can't 
force the issue.  

Agreements, when they are vague in the restriction language are held against 
the company (or person) who created the agreement, and in most cases that's the 
vendor.  We have been through countless disagreeements with vendors to help the 
client get what they were promised and we have not lost yet.  In a VERY few 
cases, we were even able to re-instate licenses that were completely dropped 
without going through another big initial charge.  Compuware was particularly 
nice about that for several sites we manage. 

I don't think the vendor (or anyone) can change the language of a contract that 
has not expired in any way without the site's written approval.  If it's 
perpetual then I don't see how any vendor company can fight that.  They 
accepted the money and they have to stick with the terms. 

Sometimes I feel that some of the vendors were just trying to get extra money 
from sites that they felt were going to disappear, and unfortunately for them 
the sites are still kicking.

Which vendor is giving you problems?  I can check with the Client Services 
people here and see if we have been through this type of problem with them in 
the past and tell you what we did to handle it.

Brian

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

Re: Software vendor trying to force MSU based contract

[Jack J. Woehr]

Timothy Sipples wrote:

If a vendor wants to charge $2
per user hair follicle per fortnight


If that's head hair (as opposed to beard hair) I'd be in great demand, we'd get 
the software for next to nothing.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

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

Re: Software vendor trying to force MSU based contract

[Timothy Sipples]

John Thinnes wrote:
>A vendor for a mainframe data entry product used for the
>last 30 years (with a perpetual unlimited seat license)
>has sent us a contract addendum where they increase the
>price by 60+% and include language to change to a MSU
>based license. The use of this product is dwindling while
>our MSU foot print is growing.

Any/every vendor can decide what to charge and how to charge for its
products, within a few legal limitations. If a vendor wants to charge $2
per user hair follicle per fortnight, that's probably legal.

Any/every customer has the option not to purchase (or to stop using) a
vendor's product if they cannot reach a mutually acceptable agreement.

In my view, a MSU-based license can be perfectly fine, even better than
fine, if the product is eligible for reasonable sub-capacity licensing
terms. Then at least you can run the product in its own softcapped LPAR,
assuming it can function that way. For example, if it's a CICS-based
product, perhaps it's possible to run the product in its own, separate CICS
region(s) in a separate, softcapped LPAR (or LPARs). You might have some
reconfiguration to handle the new license terms, but it's doable.

If a MSU-based product is not eligible for reasonable sub-capacity
licensing, and if the product does not represent at least a substantial,
reasonably steady fraction of your total machine workload (now and into the
forecast future), then that discrepancy can be a significant problem. If
you're absolutely stuck with such terms then you might be able to segregate
that product on a "penalty box," meaning a separate physical machine. As
examples, the "penalty box" could be your DR machine (otherwise idle and
with limited permanent capacity), your dedicated Coupling Facility machine,
or a machine only running other operating systems, such as an otherwise
Linux only machine. Or a new machine you buy or lease expressly as a
"penalty box." It could be IBM's machine ("IBM Cloud Managed Services on z
Systems"), or it could be another hosting company's machine, assuming the
vendor offers "hosting company" (i.e. sub-capacity) licensing terms to such
parties.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Software vendor trying to force MSU based contract

[JT]

Has anyone else experienced this?

A vendor for a mainframe data entry product used for the last 30 years (with a 
perpetual unlimited seat license) has sent us a contract addendum where they 
increase the price by 60+% and include language to change to a MSU based 
license.

The use of this product is dwindling while our MSU foot print is growing.

When questioned about the change the representative indicated government 
contracts give him no room to negotiate on price.

This will be turned over to the legal department, but I am interested how 
others have handled similar situations.


JT

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

Check out Amazon's cloud VP was on stage talking up AWS at the very moment it

[Edward Finnell]

_Amazon's  cloud VP was on stage talking up AWS at the very moment it went 
crashing down -  AOL Finance_ 
(https://www.aol.com/article/finance/2017/02/28/amazons-cloud-vp-was-on-stage-talking-up-aws-at-the-very-moment/21864170/)
 
 
 
Oh darn.

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

Re: SMS Routines help

[Lizette Koehler]

I was going to add, see what Storage Group your ISPF datasets are allocated to, 
then adjust that Storage Group with SMS Volumes in your sand box.

As was pointed out, you will probably need to update all of your Storage 
Pools/Groups to reflect the DASD on the sandbox.  Unless you keep the volser 
names the same in the sandbox.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Matthew Stitt
> Sent: Tuesday, February 28, 2017 4:52 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMS Routines help
> 
> That indicates you need to modify your storage group(s) to use the volumes
> available to the system.  Your storage groups still have the other systems
> volumes defined.  So your system is attempting to define stuff on those
> volumes, which don't exist on your sandbox system.
> 
> Matthew
> 
> On Tue, 28 Feb 2017 22:52:43 +, Ward, Mike S  wrote:
> 
> >Because doing a TSO/PDF submit we keep getting these errors, and we believe
> it is an SMS probem.
> >
> >,IKJ56221I DATA SET S250MWE.SPFTEMP0.CNTL NOT ALLOCATED, VOLUME NOT
> >AVAILABLE+, ,IKJ56221I VOLUME  NECESSARY TO SATISFY YOUR REQUEST NOT ON
> >SYSTEM, AND CANNOT B E MOUNTED, ,***,
> >
> >-Original Message-
> >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >On Behalf Of Lizette Koehler
> >Sent: Tuesday, February 28, 2017 3:28 PM
> >To: IBM-MAIN@LISTSERV.UA.EDU
> >Subject: Re: SMS Routines help
> >
> >Ward,
> >
> >Why do you want to nullify the SMS functions?  Just curious?
> >
> >I think you can have very simple ACS Constructs, like others have
> >posted. Or I think you can have an empty SCDS (not sure you would need
> >to look this up)
> >
> >When you copied the datasets and catalogs from PRD to Sandbox, you probably
> have ACS entries (DC/MC/SC/SG) assigned to the files.  Are you trying to
> nullify those?
> >
> >Thanks
> >
> >Lizette
> >
> >
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> >> On Behalf Of Ward, Mike S
> >> Sent: Tuesday, February 28, 2017 1:46 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: SMS Routines help
> >>
> >> Hello all, we set up a sandbox LPAR where we just basically copied
> >> all the operating environment (z/OS 2.2) from prod system to the sandbox.
> >> What we want to do is turn off or nullify the SMS routines for a
> >> short time. I have spent all morning and part of the afternoon
> >> looking for a way to do that, but have come up empty handed. Can
> >> anyone give me an idea of how to do that or point to some reading material
> that outlines what I need to do?
> >>
> >> Thanks.
> >>

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Paul Gilmartin]

On Tue, 28 Feb 2017 17:46:46 -0500, Edward Finnell wrote:

>_Massive  Amazon cloud service outage disrupts sites_
>(http://www.usatoday.com/story/tech/news/2017/02/28/amazons-cloud-service-goes-down-sites-scramble
>/98530914/)
>
>Wondered why traffic was a little off.
> 
That URL is broken by wrap.  Google gives me one that works:
  
http://www.usatoday.com/story/tech/news/2017/02/28/amazons-cloud-service-goes-down-sites-scramble/98530914/

-- gil

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Lester, Bob]

Yep, I've had the dashboard up since this morning.

I'll be interested to learn what (if any) recourse paying customers have if 
they can say (and prove): " I lost $ due to this outage"

VMs that don't (automatically?) have access to the replicated data within the 
AZ?  That would be bad.  

More to come, I'm sure!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, February 28, 2017 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Check out Massive Amazon cloud service outage disrupts sites [ 
EXTERNAL ]

The notice says check the Dashboard for updates. They seem to have one or two 
of these a year. So far they've been pretty tight lipped about it.
 
 
In a message dated 2/28/2017 5:35:37 P.M. Central Standard Time,  
bles...@ofiglobal.com writes:

I'm  doing an AWS class and was online fiddling with my EC2 instance when 
it  happened.  I use us-west-1a (I'm in Colorado), but there was some  
increased response even there - maybe as they moved resources?   

I thought this was not supposed to happen, ever.   Should be interesting to 
see what we learn going  forward.

Thanks!


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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.

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

Re: SMS Routines help

[Edward Finnell]

Might need to adjust VATLST. There are several ways to look. PDS vol * stor 
 | pub | priv  will tell you what's mapped to which group.
 
 
In a message dated 2/28/2017 5:52:11 P.M. Central Standard Time,  
mathwst...@bellsouth.net writes:

on those  volumes, which don't exist on your sandbox  system

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Edward Finnell]

The notice says check the Dashboard for updates. They seem to have one or  
two of these a year. So far they've been pretty tight lipped about it.
 
 
In a message dated 2/28/2017 5:35:37 P.M. Central Standard Time,  
bles...@ofiglobal.com writes:

I'm  doing an AWS class and was online fiddling with my EC2 instance when 
it  happened.  I use us-west-1a (I'm in Colorado), but there was some  
increased response even there - maybe as they moved resources?   

I thought this was not supposed to happen, ever.   Should be interesting to 
see what we learn going  forward.

Thanks!


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

Re: SMS Routines help

[Matthew Stitt]

That indicates you need to modify your storage group(s) to use the volumes 
available to the system.  Your storage groups still have the other systems 
volumes defined.  So your system is attempting to define stuff on those 
volumes, which don't exist on your sandbox system.

Matthew

On Tue, 28 Feb 2017 22:52:43 +, Ward, Mike S  wrote:

>Because doing a TSO/PDF submit we keep getting these errors, and we believe it 
>is an SMS probem.
>
>,IKJ56221I DATA SET S250MWE.SPFTEMP0.CNTL NOT ALLOCATED, VOLUME NOT AVAILABLE+,
>,IKJ56221I VOLUME  NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND CANNOT 
>B
>E MOUNTED,
>,***,
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Lizette Koehler
>Sent: Tuesday, February 28, 2017 3:28 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: SMS Routines help
>
>Ward,
>
>Why do you want to nullify the SMS functions?  Just curious?
>
>I think you can have very simple ACS Constructs, like others have posted. Or I 
>think you can have an empty SCDS (not sure you would need to look this up)
>
>When you copied the datasets and catalogs from PRD to Sandbox, you probably 
>have ACS entries (DC/MC/SC/SG) assigned to the files.  Are you trying to 
>nullify those?
>
>Thanks
>
>Lizette
>
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Ward, Mike S
>> Sent: Tuesday, February 28, 2017 1:46 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: SMS Routines help
>>
>> Hello all, we set up a sandbox LPAR where we just basically copied all
>> the operating environment (z/OS 2.2) from prod system to the sandbox.
>> What we want to do is turn off or nullify the SMS routines for a short
>> time. I have spent all morning and part of the afternoon looking for a
>> way to do that, but have come up empty handed. Can anyone give me an
>> idea of how to do that or point to some reading material that outlines what 
>> I need to do?
>>
>> Thanks.
>>

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

Re: Check out Massive Amazon cloud service outage disrupts sites

[Lester, Bob]

Hi Ed!

   I'm doing an AWS class and was online fiddling with my EC2 instance when it 
happened.  I use us-west-1a (I'm in Colorado), but there was some increased 
response even there - maybe as they moved resources?  

   I thought this was not supposed to happen, ever.  Should be interesting to 
see what we learn going forward.

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: Tuesday, February 28, 2017 3:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Check out Massive Amazon cloud service outage disrupts sites [ 
EXTERNAL ]

_Massive  Amazon cloud service outage disrupts sites_ 
(https://urldefense.proofpoint.com/v2/url?u=http-3A__www.usatoday.com_story_tech_news_2017_02_28_amazons-2Dcloud-2Dservice-2Dgoes-2Ddown-2Dsites-2Dscramble=DwICAg=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jyMISBULPMnoU7rInNUdpCpFoRdcz0WuaEppIETiqMI=70jvEDM3OSBtkoXSmN-K_b_Z1tgmShl1K5OIN0hq5gE=
/98530914/)  
 
Wondered why traffic was a little off.

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.

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

Re: SMS Routines help

[Ward, Mike S]

Because doing a TSO/PDF submit we keep getting these errors, and we believe it 
is an SMS probem.

,IKJ56221I DATA SET S250MWE.SPFTEMP0.CNTL NOT ALLOCATED, VOLUME NOT AVAILABLE+,
,IKJ56221I VOLUME  NECESSARY TO SATISFY YOUR REQUEST NOT ON SYSTEM, AND CANNOT B
E MOUNTED,
,***,

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, February 28, 2017 3:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS Routines help

Ward,

Why do you want to nullify the SMS functions?  Just curious?

I think you can have very simple ACS Constructs, like others have posted. Or I 
think you can have an empty SCDS (not sure you would need to look this up)

When you copied the datasets and catalogs from PRD to Sandbox, you probably 
have ACS entries (DC/MC/SC/SG) assigned to the files.  Are you trying to 
nullify those?

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ward, Mike S
> Sent: Tuesday, February 28, 2017 1:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS Routines help
>
> Hello all, we set up a sandbox LPAR where we just basically copied all
> the operating environment (z/OS 2.2) from prod system to the sandbox.
> What we want to do is turn off or nullify the SMS routines for a short
> time. I have spent all morning and part of the afternoon looking for a
> way to do that, but have come up empty handed. Can anyone give me an
> idea of how to do that or point to some reading material that outlines what I 
> need to do?
>
> Thanks.
>

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Check out Massive Amazon cloud service outage disrupts sites

[Edward Finnell]

_Massive  Amazon cloud service outage disrupts sites_ 
(http://www.usatoday.com/story/tech/news/2017/02/28/amazons-cloud-service-goes-down-sites-scramble
/98530914/)  
 
Wondered why traffic was a little off.

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

Re: SMS Routines help

[Lizette Koehler]

Ward,

Why do you want to nullify the SMS functions?  Just curious?

I think you can have very simple ACS Constructs, like others have posted. Or I
think you can have an empty SCDS (not sure you would need to look this up)

When you copied the datasets and catalogs from PRD to Sandbox, you probably have
ACS entries (DC/MC/SC/SG) assigned to the files.  Are you trying to nullify
those?

Thanks

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ward, Mike S
> Sent: Tuesday, February 28, 2017 1:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMS Routines help
> 
> Hello all, we set up a sandbox LPAR where we just basically copied all the
> operating environment (z/OS 2.2) from prod system to the sandbox. What we want
> to do is turn off or nullify the SMS routines for a short time. I have spent
> all morning and part of the afternoon looking for a way to do that, but have
> come up empty handed. Can anyone give me an idea of how to do that or point to
> some reading material that outlines what I need to do?
> 
> Thanks.
> 

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

Re: SMS Routines help

[Ward, Mike S]

Thank you for the reply.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Tuesday, February 28, 2017 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS Routines help

the DFSMS storage Admin guide helps 'setting up' SMS because that's basically 
what your doing, at the very least I think you'll need a storage class routine 
with a small Filterlist (maybe) and a SELECT WHEN that passes a NULL storage 
class SELECT WHEN ( criteria is met) < - this never gets met set 
 =  

OTHERWISE DO
SET  = ' ' 
EXIT CODE(0)
END /* OTHERWISE */ 


END /* SELECT */ 


from the top of my head, that's what I recall - Original Message -

From: "Mike S Ward" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Tuesday, February 28, 2017 2:46:16 PM
Subject: SMS Routines help 

Hello all, we set up a sandbox LPAR where we just basically copied all the 
operating environment (z/OS 2.2) from prod system to the sandbox. What we want 
to do is turn off or nullify the SMS routines for a short time. I have spent 
all morning and part of the afternoon looking for a way to do that, but have 
come up empty handed. Can anyone give me an idea of how to do that or point to 
some reading material that outlines what I need to do? 

Thanks. 

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited. 

--
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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: SMS Routines help

[Ward, Mike S]

Thanks for the reply

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 28, 2017 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMS Routines help

On Tue, 28 Feb 2017 20:46:16 +, Ward, Mike S wrote:

>What we want to do is turn off or nullify the SMS routines for a short time.

Do you mean that you want all new data sets to be non-sms managed?

If so, you will need to have some volumes that are not SMS-managed. 
You could change the STORCLAS ACS routine to set STORCLAS to null, and the data 
sets would be non-managed.

See the Implementing System-Managed Storage manual.

--
Tom Marchant

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: SMS Routines help

[Carmen Vitullo]

the DFSMS storage Admin guide helps 'setting up' SMS because that's basically 
what your doing, at the very least I think you'll need a storage class routine 
with a small Filterlist (maybe) and a SELECT WHEN that passes a NULL storage 
class 
SELECT 
WHEN ( criteria is met) < - this never gets met 
set  =  

OTHERWISE DO 
SET  = ' ' 
EXIT CODE(0) 
END /* OTHERWISE */ 


END /* SELECT */ 


from the top of my head, that's what I recall - Original Message -

From: "Mike S Ward"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Tuesday, February 28, 2017 2:46:16 PM 
Subject: SMS Routines help 

Hello all, we set up a sandbox LPAR where we just basically copied all the 
operating environment (z/OS 2.2) from prod system to the sandbox. What we want 
to do is turn off or nullify the SMS routines for a short time. I have spent 
all morning and part of the afternoon looking for a way to do that, but have 
come up empty handed. Can anyone give me an idea of how to do that or point to 
some reading material that outlines what I need to do? 

Thanks. 

== 
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited. 

-- 
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: SMS Routines help

[Tom Marchant]

On Tue, 28 Feb 2017 20:46:16 +, Ward, Mike S wrote:

>What we want to do is turn off or nullify the SMS routines for a short time.

Do you mean that you want all new data sets to be non-sms managed?

If so, you will need to have some volumes that are not SMS-managed. 
You could change the STORCLAS ACS routine to set STORCLAS to null, 
and the data sets would be non-managed.

See the Implementing System-Managed Storage manual.

-- 
Tom Marchant

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

SMS Routines help

[Ward, Mike S]

Hello all, we set up a sandbox LPAR where we just basically copied all the 
operating environment (z/OS 2.2) from prod system to the sandbox. What we want 
to do is turn off or nullify the SMS routines for a short time. I have spent 
all morning and part of the afternoon looking for a way to do that, but have 
come up empty handed. Can anyone give me an idea of how to do that or point to 
some reading material that outlines what I need to do?

Thanks.

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: JCL History (was: ... PARMDD ... )

[Paul Gilmartin]

On Tue, 28 Feb 2017 09:41:43 -0800, Charles Mills wrote:

>There were no APF authorized programs ...
> 
But there was the hazard of buffer overruns even in unauthorized programs.

IBM provides features to protect its code without timely extension of such
features to customer-written code.  Consider the decades during which IBM
ignored the need for REFRPROT.  REFRPROT should be mandatory, not
optional.

>-Original Message-
>From: Tom Marchant
>Sent: Tuesday, February 28, 2017 9:22 AM
>
>On Tue, 28 Feb 2017 10:19:49 -0600, Paul Gilmartin wrote:
>
>>Ah!  That shows that (at least at one time) it was possible to increase 
>>the length of the PARM without introducing intolerable incompatibilities.
>
>Perhaps because the potential integrity issues were  not understood at the 
>time.

Thanks,
gil

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

Re: JCL History (was: ... PARMDD ... )

[Paul Gilmartin]

On Tue, 28 Feb 2017 11:21:50 -0600, Tom Marchant wrote:
>
>>I'm curious because others have said (in this forum?) that earliest PROCs
>>had no arguments; all modification was done by overrides.  So, at that
>>time symbols didn't exist in JCL, neither as PROC formal parameters nor
>>in the (relatively recent) SET statment.
>
>That agrees with the description of Cataloged procedures in the 1967 manual.
> 
And, apparently prior to instream PROCs, there was no PROC nor PEND statement.
IIRC, PEND used to be prohibited in library PROCs (why?)  Lately, it's allowed.
This permits INCLUDEing a library PROC to make it an instream PROC.

Is there anything done with overrides that couldn't nowadays be done as well
with arguments/symbols?  (But the problem of dangling commas when attributes
are nullified would have to be addressed.  Most easily by ignoring excess 
commas.)
And symbols could address the deficiencies of overrides when PROC calls are
nested.  Referback deficiencies persist.

Are arguments to outer PROCs available as symbols in nested-called PROCs
without being declared as formal parameters in the inner PROC?

Thanks,
gil

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

Re: JCL History (was: ... PARMDD ... )

[Charles Mills]

There were no APF authorized programs ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 28, 2017 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: JCL History (was: ... PARMDD ... )

On Tue, 28 Feb 2017 10:19:49 -0600, Paul Gilmartin wrote:

>Ah!  That shows that (at least at one time) it was possible to increase 
>the length of the PARM without introducing intolerable incompatibilities.

Perhaps because the potential integrity issues were  not understood at the time.

>Where's the PROC statement described?  I find it neither in the ToC nor 
>in the Index although there are numerous mentions of "catalogued"
>proc[edures].  (PROCs aren't catalogued; procedure libraries are.)

In-stream procedures were introduced in release 19. See the 1970 manual.

>I'm curious because others have said (in this forum?) that earliest 
>PROCs had no arguments; all modification was done by overrides.  So, at 
>that time symbols didn't exist in JCL, neither as PROC formal 
>parameters nor in the (relatively recent) SET statment.

That agrees with the description of Cataloged procedures in the 1967 manual.

--
Tom Marchant

--
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: JCL History (was: ... PARMDD ... )

[Tom Marchant]

On Tue, 28 Feb 2017 10:19:49 -0600, Paul Gilmartin wrote:

>Ah!  That shows that (at least at one time) it was possible to increase
>the length of the PARM without introducing intolerable incompatibilities.

Perhaps because the potential integrity issues were  not understood at the time.

>Where's the PROC statement described?  I find it neither in the ToC nor
>in the Index although there are numerous mentions of "catalogued"
>proc[edures].  (PROCs aren't catalogued; procedure libraries are.)

In-stream procedures were introduced in release 19. See the 1970 manual.

>I'm curious because others have said (in this forum?) that earliest PROCs
>had no arguments; all modification was done by overrides.  So, at that
>time symbols didn't exist in JCL, neither as PROC formal parameters nor
>in the (relatively recent) SET statment.

That agrees with the description of Cataloged procedures in the 1967 manual.

-- 
Tom Marchant

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

Re: z/OS 2.2 Question

[Craig Bakken]

We saw a 2X increase in JES2 CPU usage before the PTF was applied.  Afterwards 
the JES2 CPU usage was consistent with what we saw at z/OS 2.1.



On Mon, 2/27/17, SrinivasG  wrote:

 Subject: Re: z/OS 2.2 Question
 To: IBM-MAIN@LISTSERV.UA.EDU
 Date: Monday, February 27, 2017, 9:08 AM
 
 How about this:
 
 http://www-01.ibm.com/support/docview.wss?uid=isg1OA50806
 
 I don't have the PTF
 applied yet and we are a few weeks away from applying it all
 the way in production.
 How significant is
 this impact?
 
 Regards,
 Srinivas G
 

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

Re: Question about PARMDD

[Paul Gilmartin]

On Mon, 27 Feb 2017 14:54:49 -0500, John Eells wrote:

>Paul Gilmartin wrote:
>
>>>
>> You're suggesting that a transcript or summary of those discussions
>> is available.  Can you cite?  Thanks.
>>
>
>
>I suggested neither one, so I am a bit puzzled about how you inferred
>that.  What I wrote was, "In fact, there was a protracted discussion
>right here in IBM-MAIN about how we should implement this support, well
>in advance of its actual appearance, led by the designer. I am
>reasonably confident that you can find in that discussion why it was
>done as it was, if you care to look."
> 
My apologies.  I overlooked the reference to IBM-MAIN.

>The IBM-MAIN archives are searchable, here:
>https://listserv.ua.edu/archives/ibm-main.html
>
>If you are sufficiently interested, you can find the discussion.
>
The archives are a pretty big target, given the decades of discussion of
PARM length, here and elsewnere.  I'll rely on memory

I recall a general wish for a longer PARM, no mention of anything like
PARMDD until IBM unveiled it.

IIRC, there some feeling that for very long PARMs command files are
a better approach.  Alas, some utilities don't support command files
ahd may require PARM strings longer that 100 characters.  Command
files are more practical with (recent) JCL enhancements:
o JCLLIB
o DD DATA SYMBOLS=...
o Instream data sets are no longer limited to LRECL=80
o Instream data sets may now appear in PROCs

(Yes, those facilities also apply to PARMDD.)

There was considerable concern that long PARMs might be passed to
programs not prepared for them, resulting in unexpected and undesirable
results.  The LONGPARM program object attribute is a good solution for
this.  But why is it enforced only on APF-authorized programs?  Unauthorized
programs might be similarly unprepared for PARM>100 bytes.  Granted,
for unauthorized programs there's no threat to system integrity, only to
application integrity, but that still matters.  Simply, LONGPARM should
be recognized alike for any program invoked as a job step task, whether
authorized on not.

And I'm looking at the "BPX.EXECMVSAPF.program_name FACILITY class
profile".  Why does this even exist?  Having two dissimilar ways to
achieve similar functions tends to confuse system administrators.
The LONGPARM attribute is preferable because:
o It can be set by the program owner who may lack authority to
  define RACF profile classes.
o It distinguishes between similar program_names residing in
  different libraries.

-- gil

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

JCL History (was: ... PARMDD ... )

[Paul Gilmartin]

On Tue, 28 Feb 2017 07:25:32 -0600, Elardus Engelbrecht wrote:

>Tom Marchant wrote:
>
>>Some time between 1967 and 1970.
>
>I think the limits of 40 or 100 characters were based on a quick way (without 
>using tapes or extra punch cards) to give shortish parameters to a program 
>using puch cards. Or so it was told to me by an oldie years ago.
> 
My surmise, also.

>Amazing how they worded same things then and now.
> 
When was "dataset" banished in favor of "data set"?

>>See page 85 of 
>>http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf


On Tue, 28 Feb 2017 06:33:42 -0600, Tom Marchant  
wrote:
>
>>When did it change to 100?
>
>Some time between 1967 and 1970.
>
>See page 85 of 
>http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf
>for OS/360, dated June, 1970
>
>See also page 18 of the fifth edition of the OS/360 JCL manual, dated 
>March, 1967, where the limit is specified as 40 characters.
>
>http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R01-08/C28-6539-4_OS_JCL_Mar67.pdf
>
Ah!  That shows that (at least at one time) it was possible to increase
the length of the PARM without introducing intolerable incompatibilities.

Where's the PROC statement described?  I find it neither in the ToC nor
in the Index although there are numerous mentions of "catalogued"
proc[edures].  (PROCs aren't catalogued; procedure libraries are.)

I'm curious because others have said (in this forum?) that earliest PROCs
had no arguments; all modification was done by overrides.  So, at that
time symbols didn't exist in JCL, neither as PROC formal parameters nor
in the (relatively recent) SET statment.

-- gil

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

Re: Question about PARMDD

[Charles Mills]

Oh man, that brings back some memories. Check out Figure 3 on page 25 of the 
1970 manual!

Interesting -- the example of a possible PARM= value ('P1,123,MT5') has not 
changed between that manual and 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/iea3b6_Syntax89.htm
 Ditto for the first three examples on 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieab600/iea3b6_Examples_of_the_PARM_parameter.htm
 

*Accounting* information is limited to 142 characters -- perhaps that is what 
@Clark is recalling.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, February 28, 2017 4:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question about PARMDD

On Mon, 27 Feb 2017 22:20:07 -0400, Clark Morris wrote:

>When did it change to 100?

Some time between 1967 and 1970.

See page 85 of
http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf
for OS/360, dated June, 1970


PARM=value
value
consists of up to 100 characters of information or options that the system is 
to pass to the processing program.


See also page 18 of the fifth edition of the OS/360 JCL manual, dated March, 
1967, where the limit is specified as 40 characters.

http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R01-08/C28-6539-4_OS_JCL_Mar67.pdf

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

Re: Question about PARMDD

[Elardus Engelbrecht]

Tom Marchant wrote:

>Some time between 1967 and 1970.

I think the limits of 40 or 100 characters were based on a quick way (without 
using tapes or extra punch cards) to give shortish parameters to a program 
using puch cards. Or so it was told to me by an oldie years ago.


About "Reference of the PARM field":

Then (from bitsavers):

"The exact location and format of control information passed to a processing 
program are described under the topic titled "Program Management" in section 1 
of the publication IBM System/360 Operating System: Supervisor and Data 
Management Services.

Today (from my bookmanager):

"For details on the format of the passed information and its retrieval, see 
z/OS MVS Programming: Assembler Services Guide."

Amazing how they worded same things then and now.


>See page 85 of 
>http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf

Amazing those bitsavers place which I read now and then just for amusement. I 
have a look at that book.

Same familiar monospaced fonts. Same two columns per page. Same weird spacing 
of words. Pages left blank intentionally. ;-)


I also looked at the 'Programmers name' and am amazed that it is still 20 chars 
long!
I tried out a job with 21 chars and got a JCL error with this nice message in 
upper and lower case!
'HASP110 value of programmer name is too long'


Good to see those ancient manuscripts. I (re-)discovered ancient terms like 
SUL, BISAM and QISAM and such animals. 

Do you think I should fill in 'READER'S COMMENTS'? H? ;-D

Thanks, Tom for discovering this little gem! ;-)

Groete / Greetings
Elardus Engelbrecht

SUL - type of LABEL which I never ever used at all.

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

Re: Question about PARMDD

[Tom Marchant]

On Mon, 27 Feb 2017 22:20:07 -0400, Clark Morris wrote:

>When did it change to 100?

Some time between 1967 and 1970.

See page 85 of 
http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R19_Jun70/GC28-6704-0_JCL_Reference_Rel_19_Jun70.pdf
for OS/360, dated June, 1970


PARM=value 
value
consists of up to 100 characters of information or options 
that the system is to pass to the processing program.


See also page 18 of the fifth edition of the OS/360 JCL manual, dated 
March, 1967, where the limit is specified as 40 characters.

http://bitsavers.trailing-edge.com/pdf/ibm/360/os/R01-08/C28-6539-4_OS_JCL_Mar67.pdf

-- 
Tom Marchant

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

Re: PDS/E improperly shared and updated between monoplexes :(

[Beesley, Paul]

You might be able to save the 'corrupted' PDSE like this. It's worked for me 
the last few times.

D SMS,PDSE1,CONNECTIONS,DSN(pdse-name)
D SMS,PDSE,CONNECTIONS,DSN(pdse-name)
(to see which address space is managing this PDSE - call this sms-address-space)

V SMS,,REFRESH,DSN(pdse-name)

Regards and thanks
Paul


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, Dave
Sent: Monday, February 27, 2017 8:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PDS/E improperly shared and updated between monoplexes :(

I know it's improper and doesn't work and shouldn't have happened. But it did.

Important jobs now get:
IEC036I 002-A4,IGC0005E,
And
IEA995I SYMPTOM DUMP OUTPUT
SYSTEM COMPLETION CODE=0F4  REASON CODE=0024
 TIME=12.02.23  SEQ=00630  CPU=  ASID=002A
 PSW AT TIME OF ERROR  075C0001   848D7DAA  ILC 2  INTC 0D
   NO ACTIVE MODULE FOUND - PRIMARY NOT EQUAL TO HOME
   NAME=UNKNOWN
   DATA AT PSW  048D7DA4 - 58F0D818  0A0DD707  DB00DB00
   AR/GR 0: 008FF6C8/_141AA085   1: /_040F4000
 2: 0001/_00FDEB40   3: /_7F0D1808
 4: 0001/0050_0003   5: 0002/_00FD7940
 6: 0001/_00FD79B0   7: /_7F0D17B8
 8: /_7F0D208F   9: /_
 A: /_026A3148   B: /_7F0CC0C0
 C: /_048D8A28   D: /_7F0D1090
 E: /_848D7D9A   F: /_0024
END OF SYMPTOM DUMP

When accessing this PDS/E from Lpars that aren't the one that updated it.

Short of IPL, can I fix this? z/OS 2.1

Dave Gibney
Information Technology Services
Washington State University


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading 
names used by the Atos group. The following trading entities are registered in 
England and Wales: Atos IT Services UK Limited (registered number 01245534), 
Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited 
(registered number 08514184) and Canopy The Open Cloud Company Limited 
(registration number 08011902). The registered office for each is at 4 Triton 
Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for 
the addressee, and may contain confidential or privileged information. If you 
receive this e-mail in error, you are not authorised to copy, disclose, use or 
retain it. Please notify the sender immediately and delete this email from your 
systems. As emails may be intercepted, amended or lost, they are not secure. 
Atos therefore can accept no liability for any errors or their content. 
Although Atos endeavours to maintain a virus-free network, we do not warrant 
that this transmission is virus-free and can accept no liability for any 
damages resulting from any virus transmitted. The risks are deemed to be 
accepted by everyone who communicates with Atos by email.

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