Re: Allocation problem with LMCOPY

[Jon Perryman]

I realized it was a REXX exec. Using a clist variable was a subtle way of 
asking the poster to post a legitimate example without making it a big deal. I 
personally think it's better to talk to people rather than down to them. 
Gilmartins method of commenting makes those who feel they are less experienced 
avoid posting for fear of making a mistake.

Thanks Shmuel doubt that I would make such a mistake.

Jon Perryman..  



>
> From: Shmuel Metz (Seymour J.) 
>
>
>
>In <5161261496916553.wa.paulgboulderaim@listserv.ua.edu>, on
>10/25/2013
>   at 05:05 PM, Paul Gilmartin  said:
>
>>On Fri, 25 Oct 2013 18:04:20 -0500, Shmuel Metz (Seymour J.) wrote:
>
>>> on 10/23/2013 at 11:44 AM, Paul Gilmartin  said:
>>>
What's this ampersand business?
>>>
>>>"Assuming this is clist"
>>>
>>I considered that possibility but deemed the presence of the
>>"address" instruction a refutation.
>
>While Jon Perryman quoted Dave Hansen's message, he didn't himself use
>an address statement.
>

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

Re: zIIP simulation

[Mark Post]

>>> On 11/1/2013 at 03:37 PM, Jon Perryman  wrote: 
> Since zVM supports zLinux, it makes sense that it allows IFL. Is there a 
> userid option that allows the usage of IFL processors? Or do they use some 
> other method?

That option only applies to so-called "VM Mode" LPARs, where all types of 
specialty engines and CPs can co-exist.  Linux can run on any type of 
processor, but if it's in an LPAR with z/OS, you wouldn't want Linux adding to 
your z/OS software charges, so the z/VM USER DIRECT file was enhanced so that 
you can specify just what types of processors a guest can use.  In a z/VM and 
Linux only LPAR, it's not necessary, since there's only one type of processor 
to dispatch work on.


Mark Post

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

Re: Security exposure of zXXP was Re: zIIP simulation

[Jon Perryman]

I think zAAP are somehow for Java but I'm not sure. I don't know how they 
restrict their usage. I doubt it is thru an SRB. 

zIIP is supposed to run vendor software. Most are APF authorized anyways so the 
exposure is not any greater. My point was if a customer discovered how to do 
this, they are discouraged from allowing it because their employee's could 
easily write programs to access anything they wanted.  

Jon Perryman.



>
> From: Clark Morris 
>
>
>
>>6. zIIP is first restricted by requiring programs run under an SRB. SRB's are 
>>a big security exposure so customers are unlikely to open them to their 
>>programmers. 
>
>In the process of saving money are z ZIP and ZAP users introducing a
>security exposure?  Is the code that runs under the ZIP and ZAP
>process code that normally run without any privileges in a problem
>state?
>

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

Re: Is there currently a way to access MongoDB from z/OS LE languages?

[Rob Schramm]

As far as Perl and EBCDIC goes the biggest objection was the lack of any
system that the Perl guys can use to validate the code with.  I had put out
a question to the list a while back... Looking to run Tomcat and Jspwiki on
a z/os system ... And offer up some system time to the Perl guys for
testing... Doesn't seem to be a way to do it.  Although.. I have stumbled
across a couple systems that folks have made freely available. Just not
sure how they are doing it legally.

Rob
On Nov 1, 2013 7:04 PM, "Rob Schramm"  wrote:

> Dave,
>
> I actually looked up jdbc after your post. .. and was somewhat surprised.
> I had assumed that jdbc was just java database connector ... Instead it is
> just for relational using sql.  I personally think that this was a huge
> assumption by the original authors.  It should have been jrdbc.  Leaving
> the 2nd char as an indicator of what type if db was being connected.  VBG
>
> Rob
> On Oct 26, 2013 12:55 AM, "David Crayford"  wrote:
>
>> On 25/10/2013 11:13 PM, Rob Schramm wrote:
>>
>>> Not sure how to respond..  on the one hand you have an excellent point.
>>> One the other hand..  Google jdbc and mongodb.. as well as there being a
>>> jdbc link on the mongodb page in addition to the mongodb java connectors.
>>>
>>> Doesn't really change my intent ... Grab the mongodb java database
>>> driver..
>>>   (how does jmdbc driver sound???) and couple it with the cobol
>>> application
>>> code.
>>>
>>
>> I understood your original intent Rob. I was just sounding off about JDBC
>> drivers for non-relational data bases.
>>
>> I've never quite grasped why there are so many SQL adapters for
>> non-relational data bases. Even IMS has a Java SQL interface with ODBC and
>> I just
>> don't get it. Is SQL really that much better then native APIs? In the
>> case of your typical key/value data store surely get/set is easier than
>> SELECT FROM WHERE/UPDATE SET IN etc.
>>
>>
>>  Rob
>>>
>>>
>>> On Oct 25, 2013 3:03 AM, "David Crayford"  wrote:
>>>
>>>  On 25/10/2013 1:51 PM, Rob Schramm wrote:

  With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA
> procedure BCDBATCH to help tie the two together.  Did a quick scan and
> there appear to be at least few JDBC drivers.
>
>  I'm scratching my head as to why a JDBC driver is useful with a NoSQL
 data
 base which has a very specific API.
 Why not just use the MongoDB Java API? Does JDBC provide some kind of
 value add?

   Rob

> Rob Schramm
> Senior Systems Consultant
> Imperium Group
>
>
>
> On Fri, Oct 25, 2013 at 1:18 AM, David Crayford 
> wrote:
>
>   On 25/10/2013 12:28 PM, Tony Harminc wrote:
>
>>   On 24 October 2013 23:49, Ze'ev Atlas  wrote:
>>
>>>   About a previous post, the endianess should not be a big issue to
>>> deal
>>>
 with once the two sides of the protocol are well defined.  The
 EBCDIC
 issue
 is a make or break issue.  MongoDB works decidedly with UTDF-8 and I
 need
 COBOL to natively view a string as UTF-8.  Does the current
 incarnation of
 COBOL (and perhaps PL/I) have a native UTF-8 string type.  If not,
 then I
 will abandon the whole project.

   I'm doubtless blowing (or something) into the wind again, but this

>>> sounds like a place for UTF-EBCDIC. Which is easily translated to and
>>> from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8
>>> was just a typo.) Presumably it would be a good start if COBOL could
>>> see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings
>>> that would live as UTF-8 in the database. Then when COBOL learns to
>>> handle UTF-EBCDIC, it could handle the complete UNICODE set.
>>>
>>>   The wire protocol is binary. The UTF-8 requirement for strings in
>>> the
>>>
>> BSON
>> spec 
>> http://bsonspec.org/#/**specification
>> 
>> >
>> > org/#/specification >
>> .
>> I really like the look of BSON. It's like google protocol buffers but
>> more
>> flexible. XML is the pleated khakis of the document markup world.
>>
>>
>>
>> http://www.unicode.org/**reports/tr16/
>> 
>> >
>> 
>> 
>> >
>>
>>> Tony H.
>>>
>>> --**--**
>>> --**--**
>>> --

Re: Is there currently a way to access MongoDB from z/OS LE languages?

[Rob Schramm]

Dave,

I actually looked up jdbc after your post. .. and was somewhat surprised. I
had assumed that jdbc was just java database connector ... Instead it is
just for relational using sql.  I personally think that this was a huge
assumption by the original authors.  It should have been jrdbc.  Leaving
the 2nd char as an indicator of what type if db was being connected.  VBG

Rob
On Oct 26, 2013 12:55 AM, "David Crayford"  wrote:

> On 25/10/2013 11:13 PM, Rob Schramm wrote:
>
>> Not sure how to respond..  on the one hand you have an excellent point.
>> One the other hand..  Google jdbc and mongodb.. as well as there being a
>> jdbc link on the mongodb page in addition to the mongodb java connectors.
>>
>> Doesn't really change my intent ... Grab the mongodb java database
>> driver..
>>   (how does jmdbc driver sound???) and couple it with the cobol
>> application
>> code.
>>
>
> I understood your original intent Rob. I was just sounding off about JDBC
> drivers for non-relational data bases.
>
> I've never quite grasped why there are so many SQL adapters for
> non-relational data bases. Even IMS has a Java SQL interface with ODBC and
> I just
> don't get it. Is SQL really that much better then native APIs? In the case
> of your typical key/value data store surely get/set is easier than SELECT
> FROM WHERE/UPDATE SET IN etc.
>
>
>  Rob
>>
>>
>> On Oct 25, 2013 3:03 AM, "David Crayford"  wrote:
>>
>>  On 25/10/2013 1:51 PM, Rob Schramm wrote:
>>>
>>>  With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA
 procedure BCDBATCH to help tie the two together.  Did a quick scan and
 there appear to be at least few JDBC drivers.

  I'm scratching my head as to why a JDBC driver is useful with a NoSQL
>>> data
>>> base which has a very specific API.
>>> Why not just use the MongoDB Java API? Does JDBC provide some kind of
>>> value add?
>>>
>>>   Rob
>>>
 Rob Schramm
 Senior Systems Consultant
 Imperium Group



 On Fri, Oct 25, 2013 at 1:18 AM, David Crayford 
 wrote:

   On 25/10/2013 12:28 PM, Tony Harminc wrote:

>   On 24 October 2013 23:49, Ze'ev Atlas  wrote:
>
>>   About a previous post, the endianess should not be a big issue to
>> deal
>>
>>> with once the two sides of the protocol are well defined.  The EBCDIC
>>> issue
>>> is a make or break issue.  MongoDB works decidedly with UTDF-8 and I
>>> need
>>> COBOL to natively view a string as UTF-8.  Does the current
>>> incarnation of
>>> COBOL (and perhaps PL/I) have a native UTF-8 string type.  If not,
>>> then I
>>> will abandon the whole project.
>>>
>>>   I'm doubtless blowing (or something) into the wind again, but this
>>>
>> sounds like a place for UTF-EBCDIC. Which is easily translated to and
>> from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8
>> was just a typo.) Presumably it would be a good start if COBOL could
>> see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings
>> that would live as UTF-8 in the database. Then when COBOL learns to
>> handle UTF-EBCDIC, it could handle the complete UNICODE set.
>>
>>   The wire protocol is binary. The UTF-8 requirement for strings in
>> the
>>
> BSON
> spec 
> http://bsonspec.org/#/**specification
> 
> >
>  org/#/specification >
> .
> I really like the look of BSON. It's like google protocol buffers but
> more
> flexible. XML is the pleated khakis of the document markup world.
>
>
>
> http://www.unicode.org/**reports/tr16/
> 
> >
> 
> 
> >
>
>> Tony H.
>>
>> --**--**
>> --**--**
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>>   --**--**
>> --**
>>
> --**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>   --**--**
>
 --
 For IBM-MAIN subscribe / signoff / archive access instructions,
 send email to lists...@listserv.ua.edu with the message: INF

Security exposure of zXXP was Re: zIIP simulation

[Clark Morris]

On 1 Nov 2013 08:44:42 -0700, in bit.listserv.ibm-main you wrote:

>Your code may be the best design possible but it still uses CPU. Redesigning 
>and rewriting code to be more efficient is not the point of zIIP processors. 
>They are simply an IBM sales tool to make the price if z hardware more price 
>competitive. Running code in zIIP is less efficient (code must be run in a 
>special SRB) but it much cheaper to use than the standard CPU.
>
>1. Specialty processors (zIIP, zAAP, IFL and others that IBM may implement) 
>are general CP's. They physically do the same things as a GCP.
>2. Prices for specialty processors are significantly cheaper than a GCP. IBM 
>does not want customers to run everything on them.
>3. To restrict customer usage of specialty processors, IBM must implement some 
>method for restricting the use of a specialty processor.
>4. For IFL (Linux processors), IBM disabled some instructions that are 
>critical to z/OS, zVSE and zVM but never used by zLinux. This keeps customers 
>from assigning IFL's to z/OS because it will fail.
>5. IBM intends zIIP to be used for system related workload (system overhead). 
>From their viewpoint, customers can easily justify paying for application CPU 
>usage. Its far more difficult to justify and portion out system overhead. 
>Customer charge various departments for their CPU usage. System overhead is 
>difficult to portion because of it's nature. Long ago when I was involved in 
>chargeback, we simply portioned database workload because we could not 
>attribute specific amounts to a specific group. With zIIP, this workload 
>becomes far less significant.
>
>6. zIIP is first restricted by requiring programs run under an SRB. SRB's are 
>a big security exposure so customers are unlikely to open them to their 
>programmers. 

In the process of saving money are z ZIP and ZAP users introducing a
security exposure?  Is the code that runs under the ZIP and ZAP
process code that normally run without any privileges in a problem
state?

Clark Morris
>7. To restrict software vendors, the SRB must run in a special enclave. 
>Vendors must sign a non-disclosure agreement about this special enclave. I 
>suspect that IBM includes some sort of usage clause in that agreement.
>
>Jon Perryman  
>
>
>
>>
>> From: Scott Ford 
>>
>>
>>After reading this thread, I understand the need for zIIP processors for 
>>heavy CPU processes, but what about resigning and rewriting these 
>>applications ? For us, who learned assembler or BAL ...we had less to use , 
>>cycle wise and storage, but still managed to develop good code.
>>
>>
>
>--
>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: Serialization without Enque

[Tony Harminc]

On 1 November 2013 16:22, Donald Likens  wrote:
> I have a situation where I need to serialize processing and cannot use CDS 
> because the two addresses being updated cannot
> be next to each other (because I use CDS with these two addresses with other 
> addresses).

CDSG, perhaps?

Tony H.

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

Re: Is there currently a way to access MongoDB from z/OS LE languages?

[Kirk Wolf]

Timothy is right - as long as your program doesn't call services that
require EBCDIC names, you don't need EBCDIC.

What's the open source equivalent of IEFBR14, the Unix "true" command?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com


On Fri, Nov 1, 2013 at 11:18 AM, Mike Schwab wrote:

> As long as the program accepts the data as valid and doesn't check it
> for valid ASCII characters, it should work for any character set.  Let
> the operating system determine if it is a valid data set name, path,
> etc.
>
> On Fri, Nov 1, 2013 at 10:51 AM, Tony Harminc  wrote:
> > On 1 November 2013 02:47, Timothy Sipples  wrote:
> >> Tony Harminc opines:
> > [with respect to the need to use EBCDIC]
> >>>Sure, if all your application does is crunch numbers or manipulate
> >>>bytes. But if it has any interaction with the operating system such as
> >>>calling its services...
> >>
> >> Which (other) services?
> >
> > ENQ/DEQ. WTO/WTOR/QEDIT and friends. OPEN/CLOSE. TPUT/TGET. Many of
> > the UNIX callable services. There are many more. Some of the services
> > "merely" use EBCDIC constants or values in their invocations; others
> > actually deal with EBCDIC data.
> >
> >> There is no requirement on z/OS to support dataset names unless
> operating
> >> on datasets (VSAM files, PDSes, PDSEs, etc.) Which I've already covered
> in
> >> my statement.
> >>
> >>>dealing with operator services, etc. etc. etc., you will find it
> >>
> >> There is no requirement on z/OS for open source ported applications to
> >> "deal with" operator services. For example, there is no requirement on
> z/OS
> >> that applications produce SMF records.
> >
> > So my statement you quoted above pretty much covers it. If you are
> > happy for your app to run isolated, you are fine. If you want to talk
> > to the outside world, you need to support EBCDIC to at least some
> > degree. If what you have is a callable subroutine that manipulates
> > data and returns a result, yes of course the caller can do the
> > necessary translations on input and output.
> >
> >> *Requirement*. Everything you're describing may be desirable, even
> highly
> >> desirable, but not REQUIRED.
> >
> > Oh come on. A program is not REQUIRED to do anything beyond its
> > specifications, and those can be as minimal as you like. I will
> > stipulate that IEFBR14 will run fine in ASCII, EBCDIC, or even UTF-8.
> > What do you accomplish by making this point?
> >
> >> Now, I stipulate that there are many desirable capabilities. Operating
> >> on/with EBCDIC data is often useful. There are two ways to try to
> >> accomplish that goal:
> >>
> >> 1. Complain to and criticize each and every individual open source
> >> community for every open source product, that they must accept adding a
> >> laundry list of features to their mainline source code in order to
> exploit
> >> z/OS-unique and z/OS-desirable features. That approach doesn't seem to
> be
> >> working, does it?
> >
> > A strange straw man to set up. I'm not aware of this complaining and
> > criticizing you speak of. Can you give an example of such a laundry
> > list?  What I hear, and have contributed to, is the notion that people
> > should design and write code in a portable manner. This was once
> > considered evident "goodness" among almost all programmers, but the
> > notion has faded with respect to non-ASCII characters sets, whereas
> > e.g. portability wrt endianness hasn't. If you write non portable
> > stuff like
> > If "A" <= char <= "Z" then char_is_uc_alpha = TRUE
> > then you will have trouble running on any non-ASCII system. But this,
> > and worse, continues to this day.
> >
> > Quite evidently this has happened because while there are many
> > prominent platforms of both big and little endian pursuasion, there
> > are approximately five current EBCDIC OSs in existence running on two
> > hardware platforms, and most people know nothing about any of them.
> >
> >> 2. As the Java community has, and IBM has (and continues to do), bolster
> >> the generalized runtime environments on z/OS so that more open source
> >> products can come to z/OS more easily and (optionally!) exploit z/OS
> >> without changes to the mainline source code (or with at least fewer
> >> changes).
> >
> > There's nothing wrong with this, certainly. But I see little to no
> > connection with your earlier point.
> >
> >> For example, if you want open source applications to be able to
> >> operate on/with EBCDIC data, how about a generic approach that works for
> >> all (or at least most) open source products? My /ebcdic path idea isn't
> >> necessarily best or even viable, but at least I'm trying.
> >
> > This addresses an already-addressed problem, arguably in a worse way,
> > and it's the narrow problem of UNIXy file I/O.
> >
> >> For example, one radical (but probably viable) idea would be a userland
> >> GNU/Linux atop z/OS. Anybody interested in doing that?
> >
> > Perhaps, but it's hard to see the business case when zLinux and z/OS
> 

Re: Serialization without Enque

[Rob Scott]

PLO with the CSDST function (compare swap and double store)

Sent from my iPhone

> On 1 Nov 2013, at 20:22, "Donald Likens"  wrote:
> 
> My code must be able to run in SRB mode and with locks held. I have a 
> situation where I need to serialize processing and cannot use CDS because the 
> two addresses being updated cannot be next to each other (because I use CDS 
> with these two addresses with other addresses). I have attempted to use a 
> combination of CS instructions to resolve this problem but it does not work. 
> I know this will work if I use a CMS lock but I am concerned about affecting 
> the whole system. Any advice?
> 
> --
> 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: Serialization without Enque

[Farley, Peter x23353]

Have you considered whether any of the PLO functions would do the trick?  More 
expensive than CDS, but perhaps they would help?

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald Likens
Sent: Friday, November 01, 2013 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Serialization without Enque

My code must be able to run in SRB mode and with locks held. I have a situation 
where I need to serialize processing and cannot use CDS because the two 
addresses being updated cannot be next to each other (because I use CDS with 
these two addresses with other addresses). I have attempted to use a 
combination of CS instructions to resolve this problem but it does not work. I 
know this will work if I use a CMS lock but I am concerned about affecting the 
whole system. Any advice?

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

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: zIIP simulation

[Wayne Driscoll]

Jon,
CMS and z/VM are fully supported on IFL's.  This is required in order to
run Linux on System z under z/VM, since originally you could not define an
LPAR that had both GCP's and IFL's defined to it.
==
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(at)us(dot)ibm(dot)com
All opinions are mine, and do not represent
IBM Corporation.
==


IBM Mainframe Discussion List  wrote on
11/01/2013 02:37:25 PM:

> From: Jon Perryman 
> To: IBM-MAIN@listserv.ua.edu,
> Date: 11/01/2013 02:37 PM
> Subject: Re: [IBM-MAIN] zIIP simulation
> Sent by: IBM Mainframe Discussion List 
>
> Since zVM supports zLinux, it makes sense that it allows IFL. Is
> there a userid option that allows the usage of IFL processors? Or do
> they use some other method?
>
> Does CMS also use that instruction to ensure it runs on a CP?
>
> Jon Perryman.
>
>
> >
> > From: Mark Post 
> >
> >
>  On 11/1/2013 at 11:44 AM, Jon Perryman  wrote:

> >> 4. For IFL (Linux processors), IBM disabled some instructions that are

> >> critical to z/OS, zVSE and zVM but never used by zLinux.
> >
> >To be precise, IBM disabled a single instruction that they ensured
> z/OS, z/VSE and z/TPF use.  z/VM does not use that instruction, and
> so can run on an IFL without any problems, as well as on a CP.
> >
>
> --
> 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

Serialization without Enque

[Donald Likens]

My code must be able to run in SRB mode and with locks held. I have a situation 
where I need to serialize processing and cannot use CDS because the two 
addresses being updated cannot be next to each other (because I use CDS with 
these two addresses with other addresses). I have attempted to use a 
combination of CS instructions to resolve this problem but it does not work. I 
know this will work if I use a CMS lock but I am concerned about affecting the 
whole system. Any advice?  

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

Re: zIIP simulation

[Jon Perryman]

Since zVM supports zLinux, it makes sense that it allows IFL. Is there a userid 
option that allows the usage of IFL processors? Or do they use some other 
method?

Does CMS also use that instruction to ensure it runs on a CP?

Jon Perryman.


>
> From: Mark Post 
>
>
 On 11/1/2013 at 11:44 AM, Jon Perryman  wrote: 
>> 4. For IFL (Linux processors), IBM disabled some instructions that are 
>> critical to z/OS, zVSE and zVM but never used by zLinux.
>
>To be precise, IBM disabled a single instruction that they ensured z/OS, z/VSE 
>and z/TPF use.  z/VM does not use that instruction, and so can run on an IFL 
>without any problems, as well as on a CP.
>

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

Re: ISPF statistics

[Jon Perryman]

Edit version and modification level are used as you see fit. In the old days 
before source comparison and source maint (e.g. SCLM & Endeavour), we would use 
these fields to identify changes and levels. VERSION sets version which is 
manually maintained. MODLVL automatically increments but you may override it 
using the LEVEL command. LEVEL is inserted into the line numbering..

As for PDS directory entries, each member has a user area. It is not used by 
PDS but it ensures it is propagated properly (e.g. IEBCOPY). It can be anything 
you want as long as it fits into this area. The ISPF group uses this area for 
ISPF statistics. The linkage editor group uses this area this for loading 
information (amode, rmode, ac, rent, reuse, ...). PDS does not require any 
specific information in the user area so you could put any information you 
wanted in this area. The downside is that for load modules, the loader expects 
specific information in this area to load the module. I don't know what would 
happen if ISPF found garbage in this area but I suspect it would run with STATS 
OFF. 

ISPF stats and load module attributes are the most supported information in the 
user area. Specialized programs could use and maintain user data as they feel 
but if they interact with ISPF, users will feel it should contain ISPF 
supported information that does not require the product to display this 
information.

ISPF chose not support EDIT for RECFM=U. Browse (load module and non-load 
module) does support it so it is possible to support it for edit. Since RECFM=U 
is most often load modules, why take the risk of someone damaging a load 
module. Why allow ISPF stat the ability to overlay load module attributes?

I think that ISPF does not support RECFM=VBS or FBS for edit either (not 
positive about this).

RECFM=U is undefined record format. It simply means that some attributes may be 
ignored (e.g. lrecl and blocksize). We see it mostly as load libraries. You 
can't specifically say it's a load module. The member user area may contain 
what looks like load module attributes but it's an assumption that it is valid 
load module attributes.

I don't recommend mixing data members and load modules in a single PDS but you 
can do it today without a problem. Just don't try loading a data member. 

With RECFM=U, the LRECL is usually ignored. Most people omit LRECL which is why 
you usually see 0. It is not an indication of a load model. The linkage editor 
and loader is a good example. The load library may have an LRECL but it does 
not have meaning.

There are some products that use RECFM=U and ignore both LRECL and BLKSIZE. In 
these case, they use track size as their buffer size and use physical records 
instead of logical records (recfm=fb / recfm=vb).

In z/OS 2.1 REXX, it will most likely use physical records on the disk as long 
as they don't exceed REXX variable size. As for the user data, it will most 
likely be 0's. I think it will work in a similar manner as IEBGENER RECFM=U 
support.

Jon Perryman.


>
> From: Thomas Berg 
>
>
>> -Original Message-
>> Behalf Of nitz-...@gmx.net
>> 
>> > It's certainly possible to have DSORG=PS,RECFM=U data set that does
>> > not contain load modules.  I've used them.  I believe it's also
>> > possible to have DSORG=PO,DSNTYPE=PDS,RECFM=U with content other than
>> > load modules, but ISPF refuses to recognize this fact.  I don't know
>> > whether DSORG=PO,DSNTYPE=LIBRARY,RECFM=U can have content other than
>> > program objects.
>> Yes, it can. I just ran my IEBDG job that allocated a PDS to allocate a
>> PDSE instead, and it gets filled with text data by iebdg
 without a
>> problem. ISPF does NOT support editing recfm=u data sets, which is
>> clearly indicated in the ISPF books. ISPF statistics are *only*
>> supported for fixed or variable record format.
>> 
>> This is the root of my first question: Application developers apparently
>> call 'ISPF statistics' what they see for recfm=u data sets (and most of
>> them have never encountered a recfm=u data set that was NOT a load
>> library). I believe the data shown by ISPF are stored in the directory
>> entry itself mapped by IHAPDS owned by DFP. Unfortunately ISPF itself
>> seems to call these directory data 'ISPF statistics', at least in the
>> ISPF user guide(s).
>> 
>> ISPF just *assumes* that any RECFM=U data set is a load module, when in
>> fact it isn't. As far as I can see 'real' load libraries always have an
>> lrecl of zero. Which ISPF does not test. When I use a RECFM=U data
 set
>> in ISPF (with LRECL other than zero), I get 'browse substituted' on any
>> edit attempt.
>> 
>> > It has been announced that in 2.1 Rexx EXECIO will support RECFM=U.
>> > When we get 2.1 I'll need to experiment to discover the restrictions.
>> I believe what that means is that execio will make sure that the data in
>> the directory entry IHAPDS are filled in correctly for a recfm=u data
>> set, too. I do NOT beli

Re: HSM and changed or archive bit

[Darth Keller]

Once you've generated your query, you can save the query in ISMF and then 
run it in batch using NAVIQuest.


Using NaviQuest
z/OS V1R12.0 DFSMSdfp Storage Administration   SC26-7402-14 

http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.idas200%2Fjob.htm

Chapter 3.  Performing Storage Adminstrator Tasks in Batch   -  Generate 
Report from ISMF-save Data Set List:  ACBQBAR1

Example in SYS1.SACBCNTL(ACBJBAOD)

I will tell you up-front that it can be a bit of an exercise in patience 
getting it modified to run in your environment.

ddk




///
You can see the state of the changed flag in ISMF option 1. It is column 
24.

**
This e-mail message and all attachments transmitted with it may contain legally 
privileged and/or confidential information intended solely for the use of the 
addressee(s). If the reader of this message is not the intended recipient, you 
are hereby notified that any reading, dissemination, distribution, copying, 
forwarding or other use of this message or its attachments is strictly 
prohibited. If you have received this message in error, please notify the 
sender immediately and delete this message and all copies and backups thereof. 
Thank you.

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

Re: Flashcopy on a DS6800 question

[Joel C. Ewing]

On 10/22/2013 01:45 PM, Pommier, Rex wrote:
> Hi list,
> 
> I just dug thru the Advanced Copy Redbook and the Advanced Copy Services 
> regular document, as well as looking thru the archives to no avail.
> 
> Here's my question.  I have a large VSAM dataset that I am backing up with 
> DFDSS COPY services using Flashcopy (full copy, not NOCOPY) right before 
> running batch against the source dataset.  Hypothetical situation is that the 
> batch job updates a couple records in the source dataset then abends 
> immediately, before the background copy has completed.  What happens if I try 
> to submit a DFDSS COPY job to copy the target VSAM dataset back on top of the 
> original source VSAM dataset?  I know this is an illegal operation while the 
> original Flashcopy relationship is in place, but the manuals don't tell me 
> what kind of result I can expect.  
> 
> Will the second copy job fail due to the original FC relationship still being 
> there?  This is my guess but would like some verification.  If so, what kind 
> of error can I expect?  
> 
> Will the second copy job just wait until the original background copy is 
> complete (I doubt this)?  
> 
> Will it try to copy the dataset back and destroy the data?
> 
> 
> TIA,
> 
> Rex
> 
> 
...

If this were to work like flash copy of a full volume and the 2nd
"restore" copy operation is just an ordinary copy (not a flash copy) I
would expect this to restore the original VSAM data set contents without
any problem.

With full volume flash copy, if you read from the target volume before
the physical background copy to that track is done, the DASD subsystem
is smart enough to know it really needs to read that track from the
source volume.  If you try to update a track on the source volume before
it has been copied to the target volume, it is smart enough to copy that
track from source to target before allowing the original source track to
be overwritten.

Establishing a flash copy relationship is designed to give the same
effect as if the physical copy actually completes in the time it takes
just to establish the relationship (which completes in the time it takes
to record the intended relationship between tracks on the two devices).
 Reading from the target, and writing to the source, after that point in
time is supposed to produce the same end result as if the physical copy
also completed at the same time the flash copy establishment was completed.

I would expect flash copy at the data set level to behave similarly.  If
there are any restrictions on what you can do with source and target
while the first physical copy is still incomplete, those restrictions
should be on establishing other flash copy relationships involving the
same tracks, not on ordinary reads and writes involving the tracks of
either the source or target.
-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: zIIP simulation

[Mark Post]

>>> On 11/1/2013 at 11:44 AM, Jon Perryman  wrote: 
> 4. For IFL (Linux processors), IBM disabled some instructions that are 
> critical to z/OS, zVSE and zVM but never used by zLinux.

To be precise, IBM disabled a single instruction that they ensured z/OS, z/VSE 
and z/TPF use.  z/VM does not use that instruction, and so can run on an IFL 
without any problems, as well as on a CP.


Mark Post

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

Re: Is there currently a way to access MongoDB from z/OS LE languages?

[Mike Schwab]

As long as the program accepts the data as valid and doesn't check it
for valid ASCII characters, it should work for any character set.  Let
the operating system determine if it is a valid data set name, path,
etc.

On Fri, Nov 1, 2013 at 10:51 AM, Tony Harminc  wrote:
> On 1 November 2013 02:47, Timothy Sipples  wrote:
>> Tony Harminc opines:
> [with respect to the need to use EBCDIC]
>>>Sure, if all your application does is crunch numbers or manipulate
>>>bytes. But if it has any interaction with the operating system such as
>>>calling its services...
>>
>> Which (other) services?
>
> ENQ/DEQ. WTO/WTOR/QEDIT and friends. OPEN/CLOSE. TPUT/TGET. Many of
> the UNIX callable services. There are many more. Some of the services
> "merely" use EBCDIC constants or values in their invocations; others
> actually deal with EBCDIC data.
>
>> There is no requirement on z/OS to support dataset names unless operating
>> on datasets (VSAM files, PDSes, PDSEs, etc.) Which I've already covered in
>> my statement.
>>
>>>dealing with operator services, etc. etc. etc., you will find it
>>
>> There is no requirement on z/OS for open source ported applications to
>> "deal with" operator services. For example, there is no requirement on z/OS
>> that applications produce SMF records.
>
> So my statement you quoted above pretty much covers it. If you are
> happy for your app to run isolated, you are fine. If you want to talk
> to the outside world, you need to support EBCDIC to at least some
> degree. If what you have is a callable subroutine that manipulates
> data and returns a result, yes of course the caller can do the
> necessary translations on input and output.
>
>> *Requirement*. Everything you're describing may be desirable, even highly
>> desirable, but not REQUIRED.
>
> Oh come on. A program is not REQUIRED to do anything beyond its
> specifications, and those can be as minimal as you like. I will
> stipulate that IEFBR14 will run fine in ASCII, EBCDIC, or even UTF-8.
> What do you accomplish by making this point?
>
>> Now, I stipulate that there are many desirable capabilities. Operating
>> on/with EBCDIC data is often useful. There are two ways to try to
>> accomplish that goal:
>>
>> 1. Complain to and criticize each and every individual open source
>> community for every open source product, that they must accept adding a
>> laundry list of features to their mainline source code in order to exploit
>> z/OS-unique and z/OS-desirable features. That approach doesn't seem to be
>> working, does it?
>
> A strange straw man to set up. I'm not aware of this complaining and
> criticizing you speak of. Can you give an example of such a laundry
> list?  What I hear, and have contributed to, is the notion that people
> should design and write code in a portable manner. This was once
> considered evident "goodness" among almost all programmers, but the
> notion has faded with respect to non-ASCII characters sets, whereas
> e.g. portability wrt endianness hasn't. If you write non portable
> stuff like
> If "A" <= char <= "Z" then char_is_uc_alpha = TRUE
> then you will have trouble running on any non-ASCII system. But this,
> and worse, continues to this day.
>
> Quite evidently this has happened because while there are many
> prominent platforms of both big and little endian pursuasion, there
> are approximately five current EBCDIC OSs in existence running on two
> hardware platforms, and most people know nothing about any of them.
>
>> 2. As the Java community has, and IBM has (and continues to do), bolster
>> the generalized runtime environments on z/OS so that more open source
>> products can come to z/OS more easily and (optionally!) exploit z/OS
>> without changes to the mainline source code (or with at least fewer
>> changes).
>
> There's nothing wrong with this, certainly. But I see little to no
> connection with your earlier point.
>
>> For example, if you want open source applications to be able to
>> operate on/with EBCDIC data, how about a generic approach that works for
>> all (or at least most) open source products? My /ebcdic path idea isn't
>> necessarily best or even viable, but at least I'm trying.
>
> This addresses an already-addressed problem, arguably in a worse way,
> and it's the narrow problem of UNIXy file I/O.
>
>> For example, one radical (but probably viable) idea would be a userland
>> GNU/Linux atop z/OS. Anybody interested in doing that?
>
> Perhaps, but it's hard to see the business case when zLinux and z/OS
> UNIX already exist. And it certainly won't be IBM distributing it if
> it's GPL licensed, which any GNU/Linux-based product would be.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

Re: zIIP simulation

[Jon Perryman]

Peter is correct.

SRB's are standard. Enclaves are standard. So workload that will run on zIIP 
will also run on a GCP without any change. There is not a requirement to 
execute the code in a TCB. It's up to the vendor.

For customers without zIIP, the SRB/enclave overhead will make the product more 
expensive to run. If this overhead makes the software significantly more 
expensive, then vendors will allow both methods. For other vendors, this may be 
insignificant (e.g. using a single SRB for the life of the product may be 
possible which would eliminate a lot of the overhead).

Jon Perryman.



>
> From: Peter Relson 
>
>
>>I suspect that every product that exploits zIIPs already does this. 
>>Vendors cannot count on zIIPs being installed at customer locations. 
>>If no zIIPs are available, the work must run in TCB mode.  Vendor
>>products can't just terminate if zIIPs aren't available.
>>
>
>I suspect the opposite, since it is not true that "if no zIIPs are 
>available, the work must run in TCB mode". Bob must have been thinking of 
>something else.
>
>Thus you are talking about the products having additional code paths to do 
>things in two different ways, when one way will "work".
>If there is sufficient performance justification for having that 
>additional code, then they likely do have it.
>

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

Re: Is there currently a way to access MongoDB from z/OS LE languages?

[Tony Harminc]

On 1 November 2013 02:47, Timothy Sipples  wrote:
> Tony Harminc opines:
[with respect to the need to use EBCDIC]
>>Sure, if all your application does is crunch numbers or manipulate
>>bytes. But if it has any interaction with the operating system such as
>>calling its services...
>
> Which (other) services?

ENQ/DEQ. WTO/WTOR/QEDIT and friends. OPEN/CLOSE. TPUT/TGET. Many of
the UNIX callable services. There are many more. Some of the services
"merely" use EBCDIC constants or values in their invocations; others
actually deal with EBCDIC data.

> There is no requirement on z/OS to support dataset names unless operating
> on datasets (VSAM files, PDSes, PDSEs, etc.) Which I've already covered in
> my statement.
>
>>dealing with operator services, etc. etc. etc., you will find it
>
> There is no requirement on z/OS for open source ported applications to
> "deal with" operator services. For example, there is no requirement on z/OS
> that applications produce SMF records.

So my statement you quoted above pretty much covers it. If you are
happy for your app to run isolated, you are fine. If you want to talk
to the outside world, you need to support EBCDIC to at least some
degree. If what you have is a callable subroutine that manipulates
data and returns a result, yes of course the caller can do the
necessary translations on input and output.

> *Requirement*. Everything you're describing may be desirable, even highly
> desirable, but not REQUIRED.

Oh come on. A program is not REQUIRED to do anything beyond its
specifications, and those can be as minimal as you like. I will
stipulate that IEFBR14 will run fine in ASCII, EBCDIC, or even UTF-8.
What do you accomplish by making this point?

> Now, I stipulate that there are many desirable capabilities. Operating
> on/with EBCDIC data is often useful. There are two ways to try to
> accomplish that goal:
>
> 1. Complain to and criticize each and every individual open source
> community for every open source product, that they must accept adding a
> laundry list of features to their mainline source code in order to exploit
> z/OS-unique and z/OS-desirable features. That approach doesn't seem to be
> working, does it?

A strange straw man to set up. I'm not aware of this complaining and
criticizing you speak of. Can you give an example of such a laundry
list?  What I hear, and have contributed to, is the notion that people
should design and write code in a portable manner. This was once
considered evident "goodness" among almost all programmers, but the
notion has faded with respect to non-ASCII characters sets, whereas
e.g. portability wrt endianness hasn't. If you write non portable
stuff like
If "A" <= char <= "Z" then char_is_uc_alpha = TRUE
then you will have trouble running on any non-ASCII system. But this,
and worse, continues to this day.

Quite evidently this has happened because while there are many
prominent platforms of both big and little endian pursuasion, there
are approximately five current EBCDIC OSs in existence running on two
hardware platforms, and most people know nothing about any of them.

> 2. As the Java community has, and IBM has (and continues to do), bolster
> the generalized runtime environments on z/OS so that more open source
> products can come to z/OS more easily and (optionally!) exploit z/OS
> without changes to the mainline source code (or with at least fewer
> changes).

There's nothing wrong with this, certainly. But I see little to no
connection with your earlier point.

> For example, if you want open source applications to be able to
> operate on/with EBCDIC data, how about a generic approach that works for
> all (or at least most) open source products? My /ebcdic path idea isn't
> necessarily best or even viable, but at least I'm trying.

This addresses an already-addressed problem, arguably in a worse way,
and it's the narrow problem of UNIXy file I/O.

> For example, one radical (but probably viable) idea would be a userland
> GNU/Linux atop z/OS. Anybody interested in doing that?

Perhaps, but it's hard to see the business case when zLinux and z/OS
UNIX already exist. And it certainly won't be IBM distributing it if
it's GPL licensed, which any GNU/Linux-based product would be.

Tony H.

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

Re: Linux on System z (IFL) and Spares

[John Eells]

John Eells wrote:

There is indeed a machine-level curve that reduces the capacity of the
overall machine when an engine is added (or activated) to a CEC.


Oops; I should have written:

There is indeed a machine-level curve that reduces the capacity of 
*other processors within* the overall machine when an engine is added 
(or activated) to a CEC.


(And, again, lest this be taken out of context, I'm told this is a minor 
effect compared to single-LPAR MP effects.)


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: zIIP simulation

[Jon Perryman]

Your code may be the best design possible but it still uses CPU. Redesigning 
and rewriting code to be more efficient is not the point of zIIP processors. 
They are simply an IBM sales tool to make the price if z hardware more price 
competitive. Running code in zIIP is less efficient (code must be run in a 
special SRB) but it much cheaper to use than the standard CPU.

1. Specialty processors (zIIP, zAAP, IFL and others that IBM may implement) are 
general CP's. They physically do the same things as a GCP.
2. Prices for specialty processors are significantly cheaper than a GCP. IBM 
does not want customers to run everything on them.
3. To restrict customer usage of specialty processors, IBM must implement some 
method for restricting the use of a specialty processor.
4. For IFL (Linux processors), IBM disabled some instructions that are critical 
to z/OS, zVSE and zVM but never used by zLinux. This keeps customers from 
assigning IFL's to z/OS because it will fail.
5. IBM intends zIIP to be used for system related workload (system overhead). 
From their viewpoint, customers can easily justify paying for application CPU 
usage. Its far more difficult to justify and portion out system overhead. 
Customer charge various departments for their CPU usage. System overhead is 
difficult to portion because of it's nature. Long ago when I was involved in 
chargeback, we simply portioned database workload because we could not 
attribute specific amounts to a specific group. With zIIP, this workload 
becomes far less significant.

6. zIIP is first restricted by requiring programs run under an SRB. SRB's are a 
big security exposure so customers are unlikely to open them to their 
programmers. 
7. To restrict software vendors, the SRB must run in a special enclave. Vendors 
must sign a non-disclosure agreement about this special enclave. I suspect that 
IBM includes some sort of usage clause in that agreement.

Jon Perryman  



>
> From: Scott Ford 
>
>
>After reading this thread, I understand the need for zIIP processors for heavy 
>CPU processes, but what about resigning and rewriting these applications ? For 
>us, who learned assembler or BAL ...we had less to use , cycle wise and 
>storage, but still managed to develop good code.
>
>

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

Re: Linux on System z (IFL) and Spares

[John Eells]

Shane Ginnane wrote:

On Thu, 31 Oct 2013 15:32:20 +, Pommier, Rex wrote:


According to this IBM web site, the IFL runs at full speed.

http://www-03.ibm.com/systems/z/os/linux/solutions/ifl.html

"Full functionality of a System z processor and operating on full capacity"


FSVO "full capacity".
You don't get the "real" (i.e. UP) full cpacity, but the equivalent "full 
capacity" of the MP level of your base CEC.
So if you upgrade (within the model range) to more CP engines, not only do 
(each of) your CPs get smaller, so do your IFLs.



This was so surprising a statement to me that I had to poke at it 
because I had never heard of a CEC-level MP effect.


I am reliably told that there are in fact *two* MP effect curves.  There 
is indeed a machine-level curve that reduces the capacity of the overall 
machine when an engine is added (or activated) to a CEC.  I have not 
seen the numbers but I'm told this particular MP effect, which has to do 
with things related to shared hardware infrastructure within the 
machine, while nonzero, is relatively small in the grand scheme of things.


Then there's the single-LPAR, i.e., single-operating system MP effect. 
This MP effect is far more pronounced than the one above, and it's the 
one I had always heard people talk about (up until today, that is).


You learn something new every day...

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Space allocation using OGET

[Richard Pinion]

Based on the output data set name, the allocaton will be extended format with a 
dynamic volume count of 15.
I manually allocated the data set with that name and got the extended format 
with dynamic volume count.
Since I don't know what DCB attributes OGET might generate, I don't think using 
a pre-allocated data 
set will help.



--- mike.a.sch...@gmail.com wrote:

From: Mike Schwab 
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Space allocation using OGET
Date: Fri, 1 Nov 2013 10:14:32 -0500

http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idak100%2Fsmsr13.htm

2. Allowing larger data set sizes: In z/OS V1R13, SMS expands the size
limit for data sets it supports. The new size limit is X'7FFF'
megabytes or higher, which is greater than 2500 million cylinders. The
SMS changes are essentially transparent to end user. Message IGD17351I
is issued when the converted space in MBs exceeds the limit imposed by
other components. For DD or dynamic defined VSAM data sets, SMS issues
IGD17351I when the converted space in megabytes exceeds X'FF'.

Use extended format dataset, allow extents onto additional volumes.

On Fri, Nov 1, 2013 at 10:05 AM, Richard Pinion  wrote:
> z/OS 1.13, I am getting the following error when I issue an OGET with the 
> output data set being new.
>
>  OGET '/work/shopzseries'   'LDARP1.SHOPZ.ZOS'
>
> IKJ56893I DATA SET LDARP1.SHOPZ.ZOS NOT ALLOCATED+
> IGD17351I SPACE REQUESTED IS TOO LARGE. ALLOCATION FAILED FOR DATA SET
> LDARP1.SHOPZ.ZOS
> IGD17409I FAILURE OCCURRED IN DATA SET PROPERTIES MERGE WHILE ATTEMPTING TO
> DEFINE DATA SET LDARP1.SHOPZ.ZOS
>
>
>
> _
> Netscape.  Just the Net You Need.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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




_
Netscape.  Just the Net You Need.

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

Re: Space allocation using OGET

[Mike Schwab]

http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idak100%2Fsmsr13.htm

2. Allowing larger data set sizes: In z/OS V1R13, SMS expands the size
limit for data sets it supports. The new size limit is X'7FFF'
megabytes or higher, which is greater than 2500 million cylinders. The
SMS changes are essentially transparent to end user. Message IGD17351I
is issued when the converted space in MBs exceeds the limit imposed by
other components. For DD or dynamic defined VSAM data sets, SMS issues
IGD17351I when the converted space in megabytes exceeds X'FF'.

Use extended format dataset, allow extents onto additional volumes.

On Fri, Nov 1, 2013 at 10:05 AM, Richard Pinion  wrote:
> z/OS 1.13, I am getting the following error when I issue an OGET with the 
> output data set being new.
>
>  OGET '/work/shopzseries'   'LDARP1.SHOPZ.ZOS'
>
> IKJ56893I DATA SET LDARP1.SHOPZ.ZOS NOT ALLOCATED+
> IGD17351I SPACE REQUESTED IS TOO LARGE. ALLOCATION FAILED FOR DATA SET
> LDARP1.SHOPZ.ZOS
> IGD17409I FAILURE OCCURRED IN DATA SET PROPERTIES MERGE WHILE ATTEMPTING TO
> DEFINE DATA SET LDARP1.SHOPZ.ZOS
>
>
>
> _
> Netscape.  Just the Net You Need.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Notification of New Function APARs

[Marna WALLE]

Sorry, some tips that I should have mentioned:

- don't search for "NewFunction", search for "New Function".  That works.  

- the "backlog" file (and also the instruction file) don't seem to have a name 
on them from the overview page.  Not sure how it got formatting into the 
Techdoc.  You should see two unnamed files on the overview page:  a PDF (the 
instructions) and a text file (the backlog file). Download both files.

This should help! 

Thanks for the interest,
Marna WALLE
IBM Poughkeepsie

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

Space allocation using OGET

[Richard Pinion]

z/OS 1.13, I am getting the following error when I issue an OGET with the 
output data set being new.

 OGET '/work/shopzseries'   'LDARP1.SHOPZ.ZOS' 
 
IKJ56893I DATA SET LDARP1.SHOPZ.ZOS NOT ALLOCATED+  
IGD17351I SPACE REQUESTED IS TOO LARGE. ALLOCATION FAILED FOR DATA SET  
LDARP1.SHOPZ.ZOS
IGD17409I FAILURE OCCURRED IN DATA SET PROPERTIES MERGE WHILE ATTEMPTING TO 
DEFINE DATA SET LDARP1.SHOPZ.ZOS



_
Netscape.  Just the Net You Need.

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

Re: zIIP simulation

[Peter Vander Woude]

I know of at least one of our vendors whose product does not generate the srb's 
that would get dispatched on the zIIP, if it's not there.  However, they will, 
if you ask, take some of the smf data for the sorts and run their analysis of 
those records, and come back with projections based on your sort workload.  At 
least for us, it was very useful.  Unfortunately, we can't get the zIIP on our 
z9 anymore :(

Peter

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

Re: zIIP simulation

[Scott Ford]

After reading this thread, I understand the need for zIIP processors for heavy 
CPU processes, but what about resigning and rewriting these applications ? For 
us, who learned assembler or BAL ...we had less to use , cycle wise and 
storage, but still managed to develop good code.

Scott ford
www.identityforge.com
from my IPAD

'Infinite wisdom through infinite means'


> On Nov 1, 2013, at 8:45 AM, David Andrews  wrote:
> 
>> On Fri, 2013-11-01 at 17:00 +1100, Wayne Bickerdike wrote:
>> I believe that CA-Datacom will utilise a zIIP if present.
> 
> As will IDMS.  (We're seeing approximately 50% offload of so-called
> "system mode" time in CV.)
> 
> -- 
> David Andrews
> A. Duda & Sons, Inc.
> david.andr...@duda.com
> 
> --
> 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: Testing SyncSort exit using TSO TEST

[Micheal Butz]

I link it serially reusable it will pick up the copy loaded via the TEST task

Thanks


Sent from my iPhone

> On Nov 1, 2013, at 9:47 AM, Jim Blalock  wrote:
> 
> Does the exit require APF authorization?  If so you're going to have trouble 
> with TEST.  You may need TESTAUTH.
> 
> If the exit is reentrant and you LOAD it with TEST(AUTH) first, Syncsort 
> should find it and use it if it plays by the rules.  If the exit runs 
> APF-authorized it's good practice to make it reentrant anyway.  (I'm in the 
> habit of writing everything reentrant now, but then I have tools that make it 
> easy.)
> 
>> On 10/31/2013 4:45 PM, Micheal Butz wrote:
>> Hi,
>> 
>> I am trying to test a SyncSort exit using TSO TEST.
>> 
>> The exit is not re-entrant if I load the exit under TEST would SyncSort first
>> Check the Jpa to see if the exit was already loaded.
>> 
>> Thanks
> -- 
> -- Jim Blalock
>   z/OS Support Manager
>   CCIT, Clemson University
>   (864) 656-3680
> 
> --
> 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: Testing SyncSort exit using TSO TEST

[Jim Blalock]

Does the exit require APF authorization?  If so you're going to have 
trouble with TEST.  You may need TESTAUTH.


If the exit is reentrant and you LOAD it with TEST(AUTH) first, Syncsort 
should find it and use it if it plays by the rules.  If the exit runs 
APF-authorized it's good practice to make it reentrant anyway.  (I'm in 
the habit of writing everything reentrant now, but then I have tools 
that make it easy.)


On 10/31/2013 4:45 PM, Micheal Butz wrote:

Hi,

I am trying to test a SyncSort exit using TSO TEST.

The exit is not re-entrant if I load the exit under TEST would SyncSort first
Check the Jpa to see if the exit was already loaded.

Thanks



--
-- Jim Blalock
   z/OS Support Manager
   CCIT, Clemson University
   (864) 656-3680

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

Re: zIIP simulation

[Russ Teubner]

I will go on record as being another zIIP-enabled vendor (like those who have 
already opined) for which PROJECTCPU is worthless.  When CICS starts and our 
product initializes, we look to see if a zIIPs are available.  If not, we don't 
worry about marking the enclave SRB as zIIP elidgeble.  If fact, there's an 
option to not even run it under an Enclave SRB.  This approach holds true for 
the following products: HB Base, HB JavaScript Engine, HB Socket Support.  HB 
BPIC (Batch Programs Inside CICS) doesn't exploit zIIP.

Russ Teubner
HostBridge Technology
www.hostbridge.com

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

Re: [slightly] off topic: SPFPRO on Win 8.1

[Jim Turner]

I'm running SPF/Pro 5.0 on Windows 8.1 without any problems.  For several years 
now when I upgrade Windows or switch machines I simply copy the SPFPro 
directory over to the new version/machine.  Then I create a shortcut for 
SPFPROW.EXE on my desktop.

You do need to open the shortcuts properties and make sure the shortcut tab 
shows the proper directory in the 'Start in:' field so it can find its own DLL 
files.

I'm not using any compatibility mode setting and it's running just fine.

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

Re: Assembling SHOWMVS errors

[Elardus Engelbrecht]

Peter X. DeFabritus wrote:

>When I execute the SHOWMVS command under ISPF I get continuous 0C4 ABENDs.

Ouch. Even before SHOWMVS shows what it gets from all those scannings of all 
those control blocks?

Or at what point(s) during the scanning/reporting?

Do you get these abends when running as APF or not?

>Since it should be over a year before the problem might be encountered in 
>z/OS, I am releasing the current SHOWzOS version 7.21 now, with this caveat.  
>Don't use it on z/OS 2.1 until the bug is fixed.  (SG - July 2012)

And you're still trying to use it on z/OS 2.1! :-D

Ok. I think we all have to wait for the owner to correct this.

Thanks again!

Groete / Greetings
Elardus Engelbrecht

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

Re: Assembling SHOWMVS errors

[Peter X. DeFabritus]

You got me - maybe I'm assembling it incorrectly.

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

Re: Assembling SHOWMVS errors

[Don Poitras]

Works for me:

 BROWSEGSF Utilities - SHOWzOS R721 
 Command ===>   
*** Top of Data 

SHOWMVS is running authorized   

>Operating System:  

  z/OS 02.01.00   FMID: HBB7790CVTOSLVL: FF FF FF FF EF 7F A0 00


In article <9204671585097536.wa.pxdefabrgmail@listserv.ua.edu> you wrote:
> When I execute the SHOWMVS command under ISPF I get continuous 0C4 ABENDs.
> Here is the note from over a year ago:

> Since it should be over a year before the problem might be
> encountered in z/OS, I am releasing the current SHOWzOS version   
> 7.21 now, with this caveat.  Don't use it on z/OS 2.1 until the   
> bug is fixed.  (SG - July 2012)


> On Fri, 1 Nov 2013 08:00:41 -0500, Elardus Engelbrecht 
>  wrote:

> >Peter X. DeFabritus wrote:
> >
> >>It does not seem to work, 
> >
> >What part(s)? 
> >
> >>... and there is a note in the PDS that indicates that it is not yet 
> >>working under z/OS 2.1.
> >
> >Fully or partly? just curious of course, please.
> >
> >Groete / Greetings
> >Elardus Engelbrecht

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Assembling SHOWMVS errors

[Peter X. DeFabritus]

When I execute the SHOWMVS command under ISPF I get continuous 0C4 ABENDs.
Here is the note from over a year ago:

Since it should be over a year before the problem might be
encountered in z/OS, I am releasing the current SHOWzOS version   
7.21 now, with this caveat.  Don't use it on z/OS 2.1 until the   
bug is fixed.  (SG - July 2012)


On Fri, 1 Nov 2013 08:00:41 -0500, Elardus Engelbrecht 
 wrote:

>Peter X. DeFabritus wrote:
>
>>It does not seem to work, 
>
>What part(s)? 
>
>>... and there is a note in the PDS that indicates that it is not yet working 
>>under z/OS 2.1.
>
>Fully or partly? just curious of course, please.
>
>Groete / Greetings
>Elardus Engelbrecht
>
>--
>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: Assembling SHOWMVS errors

[Elardus Engelbrecht]

Peter X. DeFabritus wrote:

>It does not seem to work, 

What part(s)? 

>... and there is a note in the PDS that indicates that it is not yet working 
>under z/OS 2.1.

Fully or partly? just curious of course, please.

Groete / Greetings
Elardus Engelbrecht

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

Re: IBM 3584 tape library error

[Pommier, Rex]

Mike,

Thanks for the link, but actually it references error 8282 as tape drive needs 
cleaning in the answer instead of the B282.  My CE pointed me to the correct 
portion of the manual.  B282 is actually hidden inside error 04 44 00 b2 82 in 
the manual and it says "Top I/O station get failure, I/O station will not 
release cartridge".  Actual problem was the gripper failed and threw the 
cartridge when it spun around from the I/O station to put the tape away.  

The odd thing about the manual is that there is a separate large section that 
documents 4 character error codes and B282 isn't in there.  That's where my 
original confusion came from.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Thursday, October 31, 2013 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM 3584 tape library error

http://www.tek-tips.com/viewthread.cfm?qid=1298857
Have you tried a cleaning tape?

On Thu, Oct 31, 2013 at 11:29 AM, Pommier, Rex  wrote:
> Hi,
>
> We have an IBM 3584 library.  The front panel display is showing error B282.  
> The maintenance manual that we got with the machine doesn't have this error 
> listed and I can't find a description from the web.  Anybody got an idea what 
> this error means?
>
> Thanks,
>
> Rex
>
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged.  If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful.  If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format.  Thank you.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.

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

Re: Assembling SHOWMVS errors

[Peter X. DeFabritus]

It does not seem to work, and there is a note in the PDS that indicates that it 
is not yet working under z/OS 2.1.

On Fri, 1 Nov 2013 05:16:16 -0500, John P Kalinich  wrote:

>Does SHOWMVS run under z/OS 2.1?  I haven't heard from Roland S. in a
>while.
>
>Regards,
>John K
>
>--
>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: zIIP simulation

[David Andrews]

On Fri, 2013-11-01 at 17:00 +1100, Wayne Bickerdike wrote:
> I believe that CA-Datacom will utilise a zIIP if present.

As will IDMS.  (We're seeing approximately 50% offload of so-called
"system mode" time in CV.)

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

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

Re: zIIP simulation

[Peter Relson]

>I would expect PROJECTCPU to be pretty accurate as I would expect it to 
>work off when the task is marked zIIP-eligible.

For non-z/OS core code, there is no such thing as a task marked 
zIIP-eligible (ignoring the zAAP on zIIP functionality).

So for products that dual-path "if zIIP available then use them, otherwise 
use tasks", projectCPU will not account for them.
For the purposes of projection accuracy, it would be better if the 
products used "if zIIP available or projectCPU is on then...".
That bit isn't currently a programming interface (SVT_CpuProjection) but 
could be made so.

>For example, time to do 
>"Expensive Work X" reduced by 64% by splitting (using educated 
>"guesstimation") the work up across three dispatchable units, including 
>overhead of startup/takedown of the two additional SRBs 

That would apply whether zIIPs were in use or not (although on a machine 
where offload engines are faster than standard CPs, elapsed time is going 
to be shorter when those faster engines can be used).

Some zIIP protocols leave the SRBs around for future use, so that it's 
less "startup/takedown" than "wakeup/put-to-sleep".

Peter Relson
z/OS Core Technology Design

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

Re: Assembling SHOWMVS errors

[John P Kalinich]

Does SHOWMVS run under z/OS 2.1?  I haven't heard from Roland S. in a 
while.

Regards,
John K

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

Re: Linux on System z (IFL) and Spares

[Shane Ginnane]

On Thu, 31 Oct 2013 15:32:20 +, Pommier, Rex wrote:

>According to this IBM web site, the IFL runs at full speed.
>
>http://www-03.ibm.com/systems/z/os/linux/solutions/ifl.html
>
>"Full functionality of a System z processor and operating on full capacity"

FSVO "full capacity".
You don't get the "real" (i.e. UP) full cpacity, but the equivalent "full 
capacity" of the MP level of your base CEC.
So if you upgrade (within the model range) to more CP engines, not only do 
(each of) your CPs get smaller, so do your IFLs.

Cute, huh ?.

Shane ...

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

Re: Linux on System z (IFL) and Spares

[Timothy Sipples]

Of course software, networking, data centers, storage, output (e.g.
printing), and staffing are always and everywhere free, so let's just spend
countless hours talking about the acquisition price of server hardware, and
even then neither considering how much actual work a processor performs nor
QoS factors.

:-)


Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
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