Re: How many CPU seconds can I consume per 10minutes?

[Barbara Nitz]

>- Software MSUs are in really Marketing MSU's, in fact any other name
>than MSU would make the situation more clear.
>- Hardware MSUs are really hardware configuration denpendent, which
>means that any variation in hardware will change the SU conversion
>factor. Vary a CPU online and you have a different amount of MP overhead
>and therefor a different SU factor, which is indeed per processor as you
>discovered above.

I heartily dislike both MSUs and MIPS in any shape, form or size, as it does
not translate into something I can comprehend.
Having said that, I used yesterday's data from one of our boxes where the
current grafic from the type70PR records shows 100% cpu usage (actually,
99,8%) on the box. Adding up all the cpu consumed  during each of those
intervals gets me a number pretty close to 3600s.

That answers the big question I had - how many cpu seconds can I achieve in
a 10-minute interval on 6 processors? Everybody who said it's equal to wall
clock time times cps was right, and I was just to dense to understand. But
this means (to my way of thinking) that 1 cpu second on a slowed down
processor model is not equal to 1 cpu second on a not-slowed down processor
model. In future, I'll be wary when I hear that a job used so-and-so much
cpu seconds. Now I also understand (I think) why service units were invented.

So, in a grafic showing the cpu seconds consumed, my 'capacity line' will be
no.of.cps*10min for a ten-minute interval. And if CoD is used again,
management can *see* where we cross that line because we had varied  more
processors online and how many cpu seconds were consumed beyond our 'normal'
capacity.

Thanks for your patience, Barbara

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

Re: Lines, Bars and ... mini-bars???

[Shane]

On Wed, 6 Jul 2011 10:01:46 -0500 Tom Marchant
  wrote:

> On Wed, 6 Jul 2011 10:32:57 -0400, Scott Rowe wrote:
> 
> >If memory is addressable with 31-bits, then it is
> >below the bar, if not, it is above the bar.
> 
> I agree.  I think that "bar" was chosen, not because "a bar has
> thickness" but to avoid confusion as to which line was meant when
> someone said, "above the line".

Nope - I recall discussions that the "bar" was an entirely appropriate
metaphor due precisely to the fact that it was 2-dimensional, and the
"line" was one-dimensional.
True, there was also a need to differentiate them, but the metaphor
was appropriate (at the time). Scotts assertion above was not entirely
true when 64-bit was first introduced. Using 64-bit storage was a pain
initially - it must have taken the best part of two years for
shared/common objects to appear.
Things have changed - perhaps it's now time the memory map stopped
changing so often. Although the memory services in 1.10 should shield
the user from a lot of the plumbing these days I guess.

Shane ...

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

Re: z/OS 1.13 preview

[Edward Jaffe]

On 7/6/2011 5:22 PM, Paul Gilmartin wrote:

Does ANY mean "any" in the conventional English sense, or does
it actually mean "any but 64"?  Sigh.


Of course! ANY continues to mean what it has meant since it was first invented 
in MVS/XA--namely either 24 or 31. It is an upward compatible specification.


The new specification meaning 24, 31 or 64 is ANY64.

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

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

Re: Ads on IBM-MAIN

[Dave Salt]

Shai,

I'm guessing the poster honestly can't remember the name of your product and 
isn't trying to infer any disrespect. Might I suggest you consider renaming 
your product to something that's easier to remember, such as "Under-priced 
Storage Solution" or simply "USS" for short?  

 ;-)   
 
Dave Salt

SimpList(tm) - try it; you'll get it! 

http://www.mackinney.com/products/program-development/simplist.html  

 



> Date: Wed, 6 Jul 2011 22:30:03 -0700
> From: shai.h...@gmail.com
> Subject: Re: Ads on IBM-MAIN
> To: IBM-MAIN@bama.ua.edu
> 
> >>MFNET (or whatever its called)
> 
> I am sorry that many people do not care about (WHAT ITS CALL) that is OK.
> I think most of the people are in this status.
> Some people love WHAT ITS CALL.
> One person in this list the inventor of WHAT ITS CALL hate this product.
> It is better to hate WHAT ITS CALL than to "not care" about WHAT ITS
> CALL , because the distance between hate to love is shorter compared
> to the distance between "not care" and love.
> Hate WHAT ITS CALL sound like big suffering to WHAT ITS CALL inventor.
> 
> So, today I will pray to God to help him and make his life happier
> compared to what it is today.
> I am sorry that something which belong to me made the inventor of WHAT
> ITS CALL to fell so bad.
> One thing I can promise you. WHAT ITS CALL is not your real problem.
> I did not mention the real name of WHAT ITS CALL even one time just to
> not give another reason to WHAT ITS CALL to be sad.
> 
> Shai
> 
> 
> On Wed, Jul 6, 2011 at 9:32 PM, Ed Gould  wrote:
> > Seymour:
> > I tried to reply earlier and my IPAD kept mangling your name.
> > I do not agree about your technical support stance on here.
> > Just imagine if everyone that got stuff from the CBT tape and the xmit 
> > program
> > and mfn** started with ther tech questions on here. IBM-MAIN would be a 
> > mess,
> > probably 80 percent of the posts would be for those types of products. There
> > would be essentially 20 percent left of IBM type posting. Then through in
> > someone who likes to post long responses (no name here) no one would want to
> > subscribe to IBM-main anymore.
> >
> > I think its entirely reasonnable for each product to have its own group or
> > possibly the CBTTAPE to have its own then Lionel's product and mfnet (or
> > whatever its called) to group thier own products in groups.
> >
> > I think the CBTTAPE is a good example why it should keep its postings to a
> > CBTTAPE group as there is a multivaried group and filexxx would be to small
> > (IMO).
> >
> > If you want to know what is going on in a group (YAHOO ANYWAY) you set 
> > yourself
> > up as nomail and the its up to you to go to YAHOO and see what the latest
> > postings are.
> > IBM-main is just broad enough to hand IBM MVS type emails and that is about
> > enough. Of course if you don't mind the endless bickering of U** then it 
> > should
> > have its own email list or Darren should step in and say NO MORE take it
> > offline. The bickering over U** was worse than MFNET (or whatever its 
> > called).
> > Frankly if I had email sent to home account I would have bit bucketed the 
> > people
> > in question long ago and I would be not talking about MFnet (or whatever its
> > called) as it would have been sent to my junk mail folder 2 years ago when 
> > it
> > was originally broadcast. YAHOO does not allow me to do so without shutting 
> > off
> > IBM-Main altogether.
> > Yes it would be nice but I can't control YAHOO and I do not want to come 
> > back
> > from a week off to find 2000 messages either.
> >
> > Ed
> >
> > Ed
> >
> >
> >
> >
> > 
> > From: Shmuel Metz (Seymour J.) 
> > To: IBM-MAIN@bama.ua.edu
> > Sent: Wed, July 6, 2011 12:38:43 PM
> > Subject: Re: Ads on IBM-MAIN
> >
> > In , on 07/05/2011
> >   at 08:00 AM, Alan Altmark  said:
> >
> >>Whether it's free or not isn't the issue.  There is a significant
> >>difference among
> >>(1) calling out a product (commercial or freeware) as a possible
> >>solution to a posted problem
> >>(2) the author occasionally posting a reminder of his product
> >>(3)discussing the technical aspects of the product
> >
> > (4)Announcing a new product or a new release.
> >
> >>I don't object to the second since the product is free and has
> >>demonstrated benefit to the readership.
> >
> > That doesn't justify posting an advertisement. OTOH, I see nothing
> > wrong with a tombstone reference in the sig
> >
> >>The third, however, is Technical Support and can be reasonably
> >>requested to reside in another forum.
> >
> > If it's a mainframe product then I see nothing wrong with technical
> > support here. That's especially true for products involving multiple
> > vendors or multiple divisions of the same vendor.
> >
> > --
> > Shmuel (Seymour J.) Metz, SysProg and JOAT
> > ISO position; see 
> > We don't care. We don't have to care, we're Congress.
> > (S877: The S

Re: Ads on IBM-MAIN

[shai hess]

>>MFNET (or whatever its called)

I am sorry that many people do not care about (WHAT ITS CALL) that is OK.
I think most of the people are in this status.
Some people love WHAT ITS CALL.
One person in this list the inventor of WHAT ITS CALL hate this product.
It is better to hate WHAT ITS CALL than to "not care" about WHAT ITS
CALL , because the distance between hate to love is shorter compared
to the distance between "not care" and love.
Hate WHAT ITS CALL sound like big suffering to WHAT ITS CALL inventor.

So, today I will pray to God to help him and make his life happier
compared to what it is today.
I am sorry that something which belong to me made the inventor of WHAT
ITS CALL to fell so bad.
One thing I can promise you. WHAT ITS CALL is not your real problem.
I did not mention the real name of WHAT ITS CALL even one time just to
not give another reason to WHAT ITS CALL to be sad.

Shai


On Wed, Jul 6, 2011 at 9:32 PM, Ed Gould  wrote:
> Seymour:
> I tried to reply earlier and my IPAD kept mangling your name.
> I do not agree about your technical support stance on here.
> Just imagine if everyone that got stuff from the CBT tape and the xmit program
> and mfn** started with ther tech questions on here. IBM-MAIN would be a mess,
> probably 80 percent of the posts would be for those types of products. There
> would be essentially 20 percent left of IBM type posting. Then through in
> someone who likes to post long responses (no name here) no one would want to
> subscribe to IBM-main anymore.
>
> I think its entirely reasonnable for each product to have its own group or
> possibly the CBTTAPE to have its own then Lionel's product and mfnet (or
> whatever its called) to group thier own products in groups.
>
> I think the CBTTAPE is a good example why it should keep its postings to a
> CBTTAPE group as there is a multivaried group and filexxx would be to small
> (IMO).
>
> If you want to know what is going on in a group (YAHOO ANYWAY) you set 
> yourself
> up as nomail and the its up to you to go to YAHOO and see what the latest
> postings are.
> IBM-main is just broad enough to hand IBM MVS type emails and that is about
> enough. Of course if you don't mind the endless bickering of U** then it 
> should
> have its own email list or Darren should step in and say NO MORE take it
> offline. The bickering over U** was worse than MFNET (or whatever its called).
> Frankly if I had email sent to home account I would have bit bucketed the 
> people
> in question long ago and I would be not talking about MFnet (or whatever its
> called) as it would have been sent to my junk mail folder 2 years ago when it
> was originally broadcast. YAHOO does not allow me to do so without shutting 
> off
> IBM-Main altogether.
> Yes it would be nice but I can't control YAHOO and I do not want to come back
> from a week off to find 2000 messages either.
>
> Ed
>
> Ed
>
>
>
>
> 
> From: Shmuel Metz (Seymour J.) 
> To: IBM-MAIN@bama.ua.edu
> Sent: Wed, July 6, 2011 12:38:43 PM
> Subject: Re: Ads on IBM-MAIN
>
> In , on 07/05/2011
>   at 08:00 AM, Alan Altmark  said:
>
>>Whether it's free or not isn't the issue.  There is a significant
>>difference among
>>(1) calling out a product (commercial or freeware) as a possible
>>solution to a posted problem
>>(2) the author occasionally posting a reminder of his product
>>(3)discussing the technical aspects of the product
>
> (4)Announcing a new product or a new release.
>
>>I don't object to the second since the product is free and has
>>demonstrated benefit to the readership.
>
> That doesn't justify posting an advertisement. OTOH, I see nothing
> wrong with a tombstone reference in the sig
>
>>The third, however, is Technical Support and can be reasonably
>>requested to reside in another forum.
>
> If it's a mainframe product then I see nothing wrong with technical
> support here. That's especially true for products involving multiple
> vendors or multiple divisions of the same vendor.
>
> --
>     Shmuel (Seymour J.) Metz, SysProg and JOAT
>     ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Rexx code to reach an IP

[jagadishan perumal]

I tried with below codes and got a message as " Socket not connected" .

On Thu, Jul 7, 2011 at 1:11 AM, Lindy Mayfield
wrote:

> it's very easy.  below is some code with all error checking taken out.  you
> can find all you need in the Communications Server documentation:
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D480/3.5
>
> The details about httpd commands (get, post, etc)  you'll have to find
> yourself.
>
> This will get the "index.html" from a server.
>
> Kind Regards,
> Lindy Mayfield
>
> /*  rexx  */
> /*  Make a connection to an http server, read the result and exit.
> */
> Host = 'www.ibm.com'
> Port = '80'
>
> srv = Socket('Initialize', 'httpd')
> srv= Socket('Socket')
> parse var srv src sockid
> srv = Socket('Ioctl',sockid,'FIONBIO','OFF' )
> srv = Socket('Gethostbyname',Host)
> parse var srv src hostip
> srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_REUSEADDR','ON')
> srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_LINGER','OFF')
> srv = Socket('Setsockopt',sockid,'SOL_SOCKET','TCP_NODELAY','OFF')
> srv = Socket('Connect',sockid,'AF_INET' Port hostip)
> /*  Communicate in ASCII  */
> srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_ASCII','ON')
> parse var srv src
> Httpmsg = 'GET /'
> srv = Socket('Send',sockid, Httpmsg "  " '0d25'x )
> srv = Socket('Recv',sockid)
> parse var srv src len data
> say data
> exit
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of jagadishan perumal
> Sent: Wednesday, July 06, 2011 6:02 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Rexx code to reach an IP
>
>  Hi Group,
>
> I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
> mainframe  Are there any sample Rexx that can be used to reach the above IP
> using TCPIP Socket ?
>
> Regards,
> Jags
>
>  --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the
> archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Ads on IBM-MAIN

[Ed Gould]

Seymour:
I tried to reply earlier and my IPAD kept mangling your name.
I do not agree about your technical support stance on here. 
Just imagine if everyone that got stuff from the CBT tape and the xmit program 
and mfn** started with ther tech questions on here. IBM-MAIN would be a mess, 
probably 80 percent of the posts would be for those types of products. There 
would be essentially 20 percent left of IBM type posting. Then through in 
someone who likes to post long responses (no name here) no one would want to 
subscribe to IBM-main anymore.

I think its entirely reasonnable for each product to have its own group or 
possibly the CBTTAPE to have its own then Lionel's product and mfnet (or 
whatever its called) to group thier own products in groups.

I think the CBTTAPE is a good example why it should keep its postings to a 
CBTTAPE group as there is a multivaried group and filexxx would be to small 
(IMO).

If you want to know what is going on in a group (YAHOO ANYWAY) you set yourself 
up as nomail and the its up to you to go to YAHOO and see what the latest 
postings are.
IBM-main is just broad enough to hand IBM MVS type emails and that is about 
enough. Of course if you don't mind the endless bickering of U** then it should 
have its own email list or Darren should step in and say NO MORE take it 
offline. The bickering over U** was worse than MFNET (or whatever its called).
Frankly if I had email sent to home account I would have bit bucketed the 
people 
in question long ago and I would be not talking about MFnet (or whatever its 
called) as it would have been sent to my junk mail folder 2 years ago when it 
was originally broadcast. YAHOO does not allow me to do so without shutting off 
IBM-Main altogether.
Yes it would be nice but I can't control YAHOO and I do not want to come back 
from a week off to find 2000 messages either. 

Ed

Ed
 




From: Shmuel Metz (Seymour J.) 
To: IBM-MAIN@bama.ua.edu
Sent: Wed, July 6, 2011 12:38:43 PM
Subject: Re: Ads on IBM-MAIN

In , on 07/05/2011
   at 08:00 AM, Alan Altmark  said:

>Whether it's free or not isn't the issue.  There is a significant
>difference among
>(1) calling out a product (commercial or freeware) as a possible
>solution to a posted problem
>(2) the author occasionally posting a reminder of his product 
>(3)discussing the technical aspects of the product

(4)Announcing a new product or a new release.

>I don't object to the second since the product is free and has
>demonstrated benefit to the readership. 

That doesn't justify posting an advertisement. OTOH, I see nothing
wrong with a tombstone reference in the sig

>The third, however, is Technical Support and can be reasonably
>requested to reside in another forum. 

If it's a mainframe product then I see nothing wrong with technical
support here. That's especially true for products involving multiple
vendors or multiple divisions of the same vendor.

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

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

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

Re: CFSIZER?

[Barbara Nitz]

Bill,

> CFSizer requests are fielded by a CF at the IBM Poughkeepsie site.  I
>suspect that you submitted your sizing requests during a period in which
>that CF and its containing sysplex were down for the July 4th holiday.  The
>MQ messages simply mean that your sizing request didn't get through, and the
>CFLEVEL 13 output is a meaningless default.
Well, this morning I still get CFLEVEL13 defaults and the MQ error, so it
could not have been the 4th of July! :-) Besides, for the signalling
structures I did get CFLEVEL17 results (same for ISGLOCK), but they appear
awfully small considering that CFLEVEL16 (which we're going to jump over)
had definite increases in size. Or so I have been told by people who went
through this.

> Please try your sizing requests again.  If you don't get meaningful
>results, you may email me with your exact input and I can run the
>calculations for you on a test plex.
Thanks for your offer! I'll probably not take you up on it, though. I'll
just double the RRS structure sizes, given that we *have* been warned about
the very much bigger microcode per CF, which is my justification for 3GB per
CF instead of 2. The rest of the structures can take care of themselves,
they're not really important. Besides, almost always I use the defaults
specified since I have no clue what the actual values would be, and only
adjust number of systems down to what we have. (Exception are signalling
structures - I know what to specify there!)

> We are aware that there are a number of structures that are not
>represented in CFSizer.  CFSizer is maintained on a not-to-interfere
>best-effort basis, and in the current climate, there are no resources for
>implementing support for new structures.
Somehow I am not surprised!

>I suggest that you open a
>marketing requirement to request support for the structures you need.  Two
>years ago, we were able to get a development line item approved for CFSizer
>and make up some ground.  If enough people ask, in a formal quantifiable
>way, maybe we can do it again.
I know. The problem is that every time I have to use the sizer something
doesn't work (and I complain here). And I resent IBM software support that
try to make using the sizer a *requirement* and if your numbers don't match,
they refuse to even look at things saying you didn't use the tool. In light
of what you just said above that's hard to digest (I am NOT picking on you,
Bill!)

I was going to say that one can use the OEM part of the sizer and look
through all the criteria (how many of IBMs customers actually know what
adjunct data on a list structure are :-) ), but the result I get there is
also from CFLEVEL13 and hence meaningless.

I guess next time IBM refuses to look at my problem and cites the sizer,
I'll refer them to this thread.  (Again, I am NOT picking on you, Bill, so
please don't feel bad personally.)

Best regards, Barbara

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

Re: Ads on IBM-MAIN

[Hilary Hurwitz]

Actually - just one point - as theOP - I converted from VSE - but not the 
programs . 
I moved from a VSE hop to an ZOS installation.

We always thought we were "shotchanged" by IBM by lack of freatures in VSE (e.g 
no catalog) but there are glaring features missing in the other world too.  

Hilary

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gerhard Postpischil
Sent: Thursday, July 07, 2011 2:46 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ads on IBM-MAIN

On 7/6/2011 11:48 AM, Gord Tomlin wrote:
> The OP was looking for a facility that would provide "a list of 
> modules used and which libraries they were taken from". Gerard 
> Postpischil replied with "The short answer to this is that it's not 
> possible." Since we have a product feature that provides this very 
> function, I felt that it was relevant to provide the information, and 
> I marked my post as a "shameless plug", since I was mentioning a 
> feature of one of our products.

I don't know who Gerard Postpischil is, but I agree with his post. It seems to 
me that you, and the product you mention, are not considering the full extent 
of what "program execution" 
entails.

Let's take the simplest "weird" case: I open a concatenation of PDSs. My 
program uses NOTE/POINT or EXCP to read the directories of each PDS in order to 
detect duplicates. It finds three copies of module ABC, derives the proper TTR 
for the second copy, and reads that into storage for execution (I have a 
subroutine to load modules that are neither in overlay nor scatter load); your 
program never sees this execution. If I did things the "proper" 
way, I'd use an IDENTIFY once that module is in memory. If you now see the 
execution, tracing the module name back through the open DCB, you'd find the 
first, rather than second occurrence, and record the wrong library. In general, 
any IDENTIFY can confuse source libraries, as the name need not be unique.

In the extreme, a program may build its own I/O control blocks, load a module, 
and execute it without ever using any system services other than I/O and WAIT, 
neither of which would tell you anything if intercepted. There's also the case 
of invoking the loader - the intended load module is built on the fly, and 
there is no load library it came from.

In the OP's case, programs were migrated from VSE, so it may be reasonable to 
conclude that no extremes are taken. In that case your program may well be 
highly useful; as I pointed out in the rest of the message, there may be 
commercial and CBT programs for the purpose, although I've never had to use any.

Also, your post addressed a strictly technical issue, and neither I nor most 
other readers considered it an ad.

> I have already communicated with the owner of the listserv on this 
> matter. Nevertheless, if members of this listserv believe this post to 
> be inappropriate, I will not make any similar posts in the future. My 
> intent was to inform, no to offend.

Your intent was to provide help, and was to the point, and I don't see why 
anyone would find that offensive, since that's the purpose of the list.

Gerhard Postpischil
Bradford, VT

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

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

Re: Startio

[Gerhard Postpischil]

On 7/6/2011 8:00 PM, DanD wrote:

Can EXCP(VR) read offline volumes now?


Checks for off-line volumes are made by allocation and open; if 
you build your own DEB, etc. EXCP will happily access an 
off-line volume.



I haven't read up on any of the changes to EXCP for quite some
time.
I once (25 years ago) had a tool that used STARTIO to read the
label of an offline volume. It would read the VOL1 label then
issue a WTOR indicating the volser of the offline volume.
(I just found the code and the date on it is "APR 5,1988").


I have a forty-year old program to clip volumes off-line, and 
it's always used EXCP.



If anyone wants this ANCIENT code I still have a copy...just
email me and I'll forward you a copy. No guarantees as I doubt
it will still work.


If 1988 code is ANCIENT, what does that make 1970 code? 

Gerhard Postpischil
Bradford, VT

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

Re: z/OS 1.13 preview

[Paul Gilmartin]

On Wed, 6 Jul 2011 11:16:31 -0700, Edward Jaffe wrote:
>
>Even in z/OS 1.12 you cannot load CSECTs above the bar. RMODE(64) is treated as
>RMODE(ANY) for module loading and execution. You cannot specify RMODE(64) as a
>binder option. The only exception is data class C_WSA64 which can be loaded
>above the bar. I would not call that a CSECT. AFAIK, nothing generate via HLASM
>can be loaded above the bar.
>
So I did an experiment.  HLASM is perfectly happy if I code

TEST RMODE 64

(BTW, it appears from SYSPRINT that HLASM correctly sign-extends
negative AD() constants.)

Then Binder says:

IEW2618I 4B40 RMODE 64 ESD ATTRIBUTES HAVE BEEN CHANGED TO RMODE ANY.

... if SYSLMOD is a PDS.  I get no such message if SYSLMOD is
a LIBRARY.  Apparently Binder is slightly happer with RMODE 64
if SYSLMOD is a LIBRARY than a PDS.  I have no idea what CSV
will do in either case.

Does ANY mean "any" in the conventional English sense, or does
it actually mean "any but 64"?  Sigh.

-- gil

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

Re: Ads on IBM-MAIN

[Gord Tomlin]

Gerhard, sorry for the typo in your name!

You are correct in saying that a program can contrive ways to "fool" a 
tracking mechanism; it is also possible to come up with ways to track 
the operation of such a program (although nobody would accept the 
attendant overhead). However, such programs do not represent the norm.


The loader is an interesting case. The tricky aspect there is the need 
to devise a meaningful convention for representing the origin of the 
program.


--

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

On 2011-07-06 19:45, Gerhard Postpischil wrote:

On 7/6/2011 11:48 AM, Gord Tomlin wrote:

The OP was looking for a facility that would provide "a list of
modules used and which libraries they were taken from". Gerard
Postpischil replied with "The short answer to this is that it's
not possible." Since we have a product feature that provides
this very function, I felt that it was relevant to provide the
information, and I marked my post as a "shameless plug", since I
was mentioning a feature of one of our products.


I don't know who Gerard Postpischil is, but I agree with his post. It
seems to me that you, and the product you mention, are not considering
the full extent of what "program execution" entails.

Let's take the simplest "weird" case: I open a concatenation of PDSs. My
program uses NOTE/POINT or EXCP to read the directories of each PDS in
order to detect duplicates. It finds three copies of module ABC, derives
the proper TTR for the second copy, and reads that into storage for
execution (I have a subroutine to load modules that are neither in
overlay nor scatter load); your program never sees this execution. If I
did things the "proper" way, I'd use an IDENTIFY once that module is in
memory. If you now see the execution, tracing the module name back
through the open DCB, you'd find the first, rather than second
occurrence, and record the wrong library. In general, any IDENTIFY can
confuse source libraries, as the name need not be unique.

In the extreme, a program may build its own I/O control blocks, load a
module, and execute it without ever using any system services other than
I/O and WAIT, neither of which would tell you anything if intercepted.
There's also the case of invoking the loader - the intended load module
is built on the fly, and there is no load library it came from.

In the OP's case, programs were migrated from VSE, so it may be
reasonable to conclude that no extremes are taken. In that case your
program may well be highly useful; as I pointed out in the rest of the
message, there may be commercial and CBT programs for the purpose,
although I've never had to use any.

Also, your post addressed a strictly technical issue, and neither I nor
most other readers considered it an ad.


I have already communicated with the owner of the listserv on
this matter. Nevertheless, if members of this listserv believe
this post to be inappropriate, I will not make any similar posts
in the future. My intent was to inform, no to offend.


Your intent was to provide help, and was to the point, and I don't see
why anyone would find that offensive, since that's the purpose of the list.

Gerhard Postpischil
Bradford, VT

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




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

Re: Startio

[DanD]

Can EXCP(VR) read offline volumes now?

I haven't read up on any of the changes to EXCP for quite some time.
I once (25 years ago) had a tool that used STARTIO to read the label of an 
offline volume.  It would read the VOL1 label then issue a WTOR indicating 
the volser of the offline volume.

(I just found the code and the date on it is "APR  5,1988").

Our DASD management group used it to verify that the volume they wanted to 
initialize was in fact the correct one (this was before ICKDSF VERIFY).


If anyone wants this ANCIENT code I still have a copy...just email me and 
I'll forward you a copy.  No guarantees as I doubt it will still work.


Dan

-Original Message- 
From: Lindy Mayfield
Sent: Wednesday, July 06, 2011 2:46 PM Newsgroups: bit.listserv.ibm-main 
Subject: Re: Startio


Thank you!  Very helpful.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
Of Blaicher, Chris

Sent: Wednesday, July 06, 2011 9:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Startio

Going to STARTIO is really going out in the deep end.  You are responsible 
for everything.  If you tell it to erase the system IPL pack, it will do it, 
but it will let you do very efficient I/O if you know what you are doing.


There is the 25 cent tour of STARTIO.  If you have other questions, please 
be as specific as you can and I or someone else on this list will try to get 
you the answers you want. 


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

Re: lies, d***ed lies and statistics

[Hank Oerlemans]

TASID gets its info from the CVT and SHID.

>From DDLIST do B 10.?-6. The half word at that address is where your 2817 
comes from .
B 10.?+42C?+20 is the 3 bytes that make up the rest of the designation.

D M=CPU should get the same results.

TASID can no longer display LPAR info from z/OS 1.11 onwards because the 
control blocks have moved.

Regards Hank Oerlemans, ISPF C/T


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

Re: Ads on IBM-MAIN

[Gerhard Postpischil]

On 7/6/2011 11:48 AM, Gord Tomlin wrote:

The OP was looking for a facility that would provide "a list of
modules used and which libraries they were taken from". Gerard
Postpischil replied with "The short answer to this is that it's
not possible." Since we have a product feature that provides
this very function, I felt that it was relevant to provide the
information, and I marked my post as a "shameless plug", since I
was mentioning a feature of one of our products.


I don't know who Gerard Postpischil is, but I agree with his 
post. It seems to me that you, and the product you mention, are 
not considering the full extent of what "program execution" 
entails.


Let's take the simplest "weird" case: I open a concatenation of 
PDSs. My program uses NOTE/POINT or EXCP to read the directories 
of each PDS in order to detect duplicates. It finds three copies 
of module ABC, derives the proper TTR for the second copy, and 
reads that into storage for execution (I have a subroutine to 
load modules that are neither in overlay nor scatter load); your 
program never sees this execution. If I did things the "proper" 
way, I'd use an IDENTIFY once that module is in memory. If you 
now see the execution, tracing the module name back through the 
open DCB, you'd find the first, rather than second occurrence, 
and record the wrong library. In general, any IDENTIFY can 
confuse source libraries, as the name need not be unique.


In the extreme, a program may build its own I/O control blocks, 
load a module, and execute it without ever using any system 
services other than I/O and WAIT, neither of which would tell 
you anything if intercepted. There's also the case of invoking 
the loader - the intended load module is built on the fly, and 
there is no load library it came from.


In the OP's case, programs were migrated from VSE, so it may be 
reasonable to conclude that no extremes are taken. In that case 
your program may well be highly useful; as I pointed out in the 
rest of the message, there may be commercial and CBT programs 
for the purpose, although I've never had to use any.


Also, your post addressed a strictly technical issue, and 
neither I nor most other readers considered it an ad.



I have already communicated with the owner of the listserv on
this matter. Nevertheless, if members of this listserv believe
this post to be inappropriate, I will not make any similar posts
in the future. My intent was to inform, no to offend.


Your intent was to provide help, and was to the point, and I 
don't see why anyone would find that offensive, since that's the 
purpose of the list.


Gerhard Postpischil
Bradford, VT

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

Re: manual tape library and external tape

[Linda Mooney]

Hi Mark, 



Thanks for the info, that's good to know.  



Linda 


- Original Message -


From: "Mark Zelden"  
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, July 6, 2011 1:17:58 PM 
Subject: Re: manual tape library and external tape 

On Wed, 6 Jul 2011 19:23:58 +, Linda Mooney  
wrote: 

> 
>try adding STORCLAS=NONSMS 
> 
> 

Linda, that is something local to your environment.  A "dummy"  STORCLAS. 

Typically the STORCLAS ACS routine has something like this (perhaps 
along with a check for specific userids allowed to use it) and then just 
exits out of the routine so the data set specified is not SMS managed. 

I have seen that name used often, but I've seen many others also. 
SCNONSMS, NULL, NOSMS, etc. 

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

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

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

Re: manual tape library and external tape

[Ed Finnell]

There was an INfo APAR on ways to do this. Before I got a maint pool  
established I stuck the NL tapes in holes where the bad tapes were in the  
existing pool. Got me by for a little while...
 
 
In a message dated 7/6/2011 5:21:38 P.M. Central Daylight Time,  
rex.pomm...@cnasurety.com writes:

Same  result.  " NOT ENOUGH NON-SYSTEM MANAGED VOLUMES ELIGIBLE"



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

Re: manual tape library and external tape

[Pommier, Rex R.]

Yup, we're using RMM.  I tried that too after my post.  Same result.  " NOT 
ENOUGH NON-SYSTEM MANAGED VOLUMES ELIGIBLE   "

I don't think it's getting to tape management.  I think SMS is nailing me that 
the manual tape library is SMS managed itself.

Tomorrow's another day.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Ed Finnell
Sent: Wednesday, July 06, 2011 4:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: manual tape library and external tape

What's your bypass rule for tape management. Usually EXPDT=98000?


In a message dated 7/6/2011 4:50:06 P.M. Central Daylight Time,
rex.pomm...@cnasurety.com writes:

of  trying to put a non-SMS dataset on an SMS-managed disk  pack.


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

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: manual tape library and external tape

[Ed Finnell]

What's your bypass rule for tape management. Usually EXPDT=98000?
 
 
In a message dated 7/6/2011 4:50:06 P.M. Central Daylight Time,  
rex.pomm...@cnasurety.com writes:

of  trying to put a non-SMS dataset on an SMS-managed disk  pack.


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

Re: manual tape library and external tape

[Pommier, Rex R.]

Hi Linda,

I have a dummy STORCLAS called SCNOSMS, but I still get the

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE

Error.  I think the problem is that the tape library itself is SMS managed and 
it won't let me past that.  Kind of trying to put a non-SMS dataset on an 
SMS-managed disk pack.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Linda Mooney
Sent: Wednesday, July 06, 2011 2:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: manual tape library and external tape

Hi Rex,



try adding STORCLAS=NONSMS



Linda


- Original Message -


From: "Rex R. Pommier" 
To: IBM-MAIN@bama.ua.edu
Sent: Wednesday, July 6, 2011 12:12:41 PM
Subject: manual tape library and external tape

Hi list,

I have a question on reading a non SMS-managed tape in a manual tape library 
defined as SMS managed.

Our environment is we have a TS3400 manual tape library with 2 TS1120 drives in 
it.  This library is SMS defined because normally all we do with it is push our 
backups to it.  I have an external tape - maintenance from IBM - that I want to 
read via our MTL, which are the only tape drives we have on the system.  Is 
there some way of fooling/forcing the system to read this tape?

I think the problem is that it's a unlabeled tape.

I tried several different items with the following results:

//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD,
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)   real tape 
library in the UNIT parm, real vol-ser,

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE



//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD,
//   VOL=SER=11,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)  real tape 
library, fake to a vol-ser in my SMS vol-ser range

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE


//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=500,DISP=OLD,
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)try the actual 
address of tape drive instead of the library

IEF120I RRPGENER S01COPY SYSUT1 ALLOCATION FAILED - A NON-LIBRARY REQUEST 
SPECIFIED A LIBRARY DEVICE 0500


I tried shutting down OAM and it made no difference.

Any suggestions?

TIA.

Rex

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: Z/OS Newbie question

[Tony Harminc]

On 6 July 2011 14:07, Paul Gilmartin  wrote:
> On Mon, 4 Jul 2011 14:42:37 +0300, Hilary Hurwitz wrote:
>>
>>The other thing I would like is to be able to see the compile dates in a load 
>>library - all the library at once. We do have File Aid, but it is a pain to 
>>get all dates (and maybe even sort on date ?)
>>
> Wouldn't it be nice to be able to keep your load modules in a Unix filesystem 
> (HFS, zFS, whatever) where everything has a date stamp?

Well that won't magically extract compile dates from a load module.

>    //STEPLIB  DD  PATH=...
>
> And even put Unix directories in LINKLIST?

Sure - that'd all be nice, though there are the same chicken and egg
issues as there are with PDSEs.

> (Would require some discipline maintaining those date stamps.)

Mere "last update" stamps are only part of what's wanted.

Tony H.

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

Re: How to allocate PDSE's

[Mark Zelden]

On Wed, 6 Jul 2011 14:00:16 -0500, Ray Overby  wrote:
ither..

I missed the second part of your question:
>
>Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I
>was able to allocate one on a non-sms volume. I have not tried to use
>the file yet..
>

Yes, since OS/390 2.9, but the support was rolled back to OS/390 2.6 IIRC. 
That same support includes non-SMS HFS files.  I think the main reason the
support was added was due to user community complaints for a long
time about the wrinkles SMS PDSEs and HFS files threw into their 
SYSRES cloning procedures.   But then came zFS and new wrinkles. :-)
Then new solutions (z/OS 1.12 indirect catalog).

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

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

Re: manual tape library and external tape

[Mark Zelden]

On Wed, 6 Jul 2011 19:23:58 +, Linda Mooney 
wrote:

>
>try adding STORCLAS=NONSMS 
>
>

Linda, that is something local to your environment.  A "dummy"  STORCLAS.

Typically the STORCLAS ACS routine has something like this (perhaps
along with a check for specific userids allowed to use it) and then just
exits out of the routine so the data set specified is not SMS managed. 

I have seen that name used often, but I've seen many others also.
SCNONSMS, NULL, NOSMS, etc.

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

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

Re: How to allocate PDSE's

[Mark Zelden]

On Wed, 6 Jul 2011 14:00:16 -0500, Ray Overby  wrote:


>It also appears that the TSO ALLOCATE command cannot be used to allocate
>PDSE's. Is this true? I reviewed the ALLOC command help and could not
>find a "DSNTYPE" parameter. Perhaps I missed it.

You must have. :-) DSNTYPE(LIBRARY)

DSNTYPE('DSNTYPE-VALUE') - DATA SET NAME TYPE
LIBRARY--A PARTITIONED DATA SET IN PDSE  
 FORMAT  
PDS--A PARTITIONED DATA SET IN RECORD
 FORMAT  
HFS--A PARTITIONED DATA SET IN PDSE  
 FORMAT  
LARGE--A LARGE FORMAT SEQUENTIAL DATA SET
 WITH THE ABILITY TO HAVE A SIZE GREATER 
 THAN 65535 TRACKS ON EACH VOLUME.   
BASIC--A DATA SET THAT IS TO BE LIMITED TO NO
 MORE THAN 65535 TRACKS PER VOLUME. IT   
 MIGHT BE VSAM OR SEQUENTIAL.
EXTREQ--A DATA SET MUST BE EXTENDED FORMAT   
 (REQUIRED). IT MIGHT BE VSAM OR 
 SEQUENTIAL. 
EXTPREF--REQUESTS THAT THE DATA SET BE   
 EXTENDED FORMAT(PREFERRED). IF THE  
 SYSTEM CANNOT CREATE IT IN EXTENDED 
 FORMAT, IT WILL TRY BASIC FORMAT. IT
 MIGHT BE VSAM OR SEQUENTIAL.
NULL--OVERRIDE THIS KEYWORD IF IT HAS BEEN   
 INCLUDED VIA DATA CLASS PARAMETERS  


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

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

Re: How to allocate PDSE's

[Linda Mooney]

Hi Ray, 



Sorry about that last reply - one wrong click... 



< 
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, July 6, 2011 12:00:16 PM 
Subject: How to allocate PDSE's 

I was looking at my options for allocating a PDSE. They appear to be: 

-    ISPF 3.2 using LIBRARY as "Data set name type" value. 

-    JCL - DSNTYPE= parameter. You would use other parameters similar to 
what you would use for a PDS. 

-    SVC 99 in assembler - DALDSNT (DSNTYPE) Text unit appears to allow 
the specification of PDSE. You would use other parameters similar to 
what you would use for a PDS. 

Am I missing any options? 

It also appears that the TSO ALLOCATE command cannot be used to allocate 
PDSE's. Is this true? I reviewed the ALLOC command help and could not 
find a "DSNTYPE" parameter. Perhaps I missed it. I wonder if the LIKE() 
parameter might be used? I also looked at the ATTRIB TSO command and did 
not see a "DSNTYPE" parameter there either.. 

Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I 
was able to allocate one on a non-sms volume. I have not tried to use 
the file yet.. 

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

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

Re: How to allocate PDSE's

[Linda Mooney]

Hi Ray, 



<< snip 





- Original Message -


From: "Ray Overby"  
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, July 6, 2011 12:00:16 PM 
Subject: How to allocate PDSE's 

I was looking at my options for allocating a PDSE. They appear to be: 

-    ISPF 3.2 using LIBRARY as "Data set name type" value. 

-    JCL - DSNTYPE= parameter. You would use other parameters similar to 
what you would use for a PDS. 

-    SVC 99 in assembler - DALDSNT (DSNTYPE) Text unit appears to allow 
the specification of PDSE. You would use other parameters similar to 
what you would use for a PDS. 

Am I missing any options? 

It also appears that the TSO ALLOCATE command cannot be used to allocate 
PDSE's. Is this true? I reviewed the ALLOC command help and could not 
find a "DSNTYPE" parameter. Perhaps I missed it. I wonder if the LIKE() 
parameter might be used? I also looked at the ATTRIB TSO command and did 
not see a "DSNTYPE" parameter there either.. 

Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I 
was able to allocate one on a non-sms volume. I have not tried to use 
the file yet.. 

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

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

Re: Rexx code to reach an IP

[Lindy Mayfield]

it's very easy.  below is some code with all error checking taken out.  you can 
find all you need in the Communications Server documentation:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D480/3.5

The details about httpd commands (get, post, etc)  you'll have to find yourself.

This will get the "index.html" from a server.

Kind Regards,
Lindy Mayfield

/*  rexx  */
/*  Make a connection to an http server, read the result and exit.  
*/  
Host = 'www.ibm.com'
Port = '80' 

srv = Socket('Initialize', 'httpd') 
srv= Socket('Socket')   
parse var srv src sockid
srv = Socket('Ioctl',sockid,'FIONBIO','OFF' )   
srv = Socket('Gethostbyname',Host)  
parse var srv src hostip
srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_REUSEADDR','ON')  
srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_LINGER','OFF')
srv = Socket('Setsockopt',sockid,'SOL_SOCKET','TCP_NODELAY','OFF')  
srv = Socket('Connect',sockid,'AF_INET' Port hostip)
/*  Communicate in ASCII  */
srv = Socket('Setsockopt',sockid,'SOL_SOCKET','SO_ASCII','ON')  
parse var srv src   
Httpmsg = 'GET /'   
srv = Socket('Send',sockid, Httpmsg "  " '0d25'x )  
srv = Socket('Recv',sockid) 
parse var srv src len data  
say data
exit

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
jagadishan perumal
Sent: Wednesday, July 06, 2011 6:02 PM
To: IBM-MAIN@bama.ua.edu
Subject: Rexx code to reach an IP

Hi Group,

I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from 
mainframe  Are there any sample Rexx that can be used to reach the above IP 
using TCPIP Socket ?

Regards,
Jags

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

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

Re: CFSIZER?

[Mark Zelden]

On Wed, 6 Jul 2011 18:12:30 +, Meral Temel (Garanti Teknoloji)
 wrote:


>Pr/sm Level 00a, it is  now written in  as below
>
>Important Note
>CF structures allocated in a CFLEVEL 17 coupling facility might need to be
>significantly larger than in previous CFLEVELs, in order to be allocated with a
>similar number of usable structure objects. It is highly recommended to use
>the CFSIZER tool: http://www.ibm.com/systems/support/z/cfsizer/.
>
>In addition to the potential structure size changes mentioned in this note, the
>CFCC Licensed Internal Code (LIC) for CFLEVEL 17 requires a minimum of
>512 MB of central storage in order to activate. The increase in the minimum
>storage amount is required to accommodate the CFLEVEL 17 enhancements.
>Failure to define enough central storage will prevent the CFCC image from
>activating.

That's good to know.  I hope it was specifically added to the installation 
checklist to go over with the client also.   My sandbox CFs only had 512MB.
They did activate, but that was about it.  :-)

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

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

Re: How to allocate PDSE's

[Lou Losee]

In the z/OS 1.12 TSO/E Command Reference the keywords for the ALLOC command
includes:

*DSNTYPE(LIBRARY* *|* *PDS* *|* *HFS* *|* *PIPE* *|LARGE* *|* *BASIC* *|* *
EXTREQ* *|* *EXTPREF)* specifies the type of data set to be allocated.

  *LIBRARY* specifies a partitioned data set extended (*PDSE*).

 *PDS* specifies a partitioned data set (PDS).


*HFS* specifies a UNIX file system. For better performance, do not use this
type of data set. Instead, define a VSAM linear data set and define a z/OS
file system (zFS) in it.

 *PIPE* specifies a first-in first-out (FIFO) special file, which is also
called a named pipe. If you specify PIPE, you must also specify PATH and not
specify DATASET or DSNAME.

 *LARGE* specifies a large format sequential data set. It can have a size
greater than 65535 tracks on a single volume.

 *BASIC* specifies a basic format sequential data set. It is limited to no
more than 65535 tracks per volume, which is about 3.6 GB.

 *EXTREQ* specifies that the data set must be extended format. It can be
sequential or VSAM. It can be striped, compressed format or neither.

 *EXTPREF* specifies that the data set should be allocated as extended
format, if possible. If not possible, allocate the data set as basic format
.

 If you omit DSNTYPE, the type of data set is determined by other data set
attributes, the data class for the data set, or an installation default.

Lou
Artificial Intelligence is no match for Natural Stupidity


On Wed, Jul 6, 2011 at 2:00 PM, Ray Overby  wrote:

> I was looking at my options for allocating a PDSE. They appear to be:
>
> -ISPF 3.2 using LIBRARY as "Data set name type" value.
>
> -JCL - DSNTYPE= parameter. You would use other parameters similar to
> what you would use for a PDS.
>
> -SVC 99 in assembler - DALDSNT (DSNTYPE) Text unit appears to allow the
> specification of PDSE. You would use other parameters similar to what you
> would use for a PDS.
>
> Am I missing any options?
>
> It also appears that the TSO ALLOCATE command cannot be used to allocate
> PDSE's. Is this true? I reviewed the ALLOC command help and could not find a
> "DSNTYPE" parameter. Perhaps I missed it. I wonder if the LIKE() parameter
> might be used? I also looked at the ATTRIB TSO command and did not see a
> "DSNTYPE" parameter there either..
>
> Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I was
> able to allocate one on a non-sms volume. I have not tried to use the file
> yet..
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at 
> http://bama.ua.edu/archives/**ibm-main.html
>

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

Re: manual tape library and external tape

[Linda Mooney]

Hi Rex, 



try adding STORCLAS=NONSMS 



Linda 


- Original Message -


From: "Rex R. Pommier"  
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, July 6, 2011 12:12:41 PM 
Subject: manual tape library and external tape 

Hi list, 

I have a question on reading a non SMS-managed tape in a manual tape library 
defined as SMS managed. 

Our environment is we have a TS3400 manual tape library with 2 TS1120 drives in 
it.  This library is SMS defined because normally all we do with it is push our 
backups to it.  I have an external tape - maintenance from IBM - that I want to 
read via our MTL, which are the only tape drives we have on the system.  Is 
there some way of fooling/forcing the system to read this tape? 

I think the problem is that it's a unlabeled tape. 

I tried several different items with the following results: 

//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD, 
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)       real tape 
library in the UNIT parm, real vol-ser, 

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE 



//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD, 
//   VOL=SER=11,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)      real tape 
library, fake to a vol-ser in my SMS vol-ser range 

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE 


//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=500,DISP=OLD, 
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)    try the actual 
address of tape drive instead of the library 

IEF120I RRPGENER S01COPY SYSUT1 ALLOCATION FAILED - A NON-LIBRARY REQUEST 
SPECIFIED A LIBRARY DEVICE 0500 


I tried shutting down OAM and it made no difference. 

Any suggestions? 

TIA. 

Rex 

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you. 

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

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

lies, d***ed lies and statistics

[Kirk Talman]

waiting for a job to run I noticed something curious - maybe someone can 
explain - displays are slightly censored - does this mean there are 
multiple ways to get model type and they give different answers?

batch job - CPU MODEL=2097 (Z10 EC)

JCLCHECK  11.0  AM01INVOKED AT  3:05:38 PM ON WEDNESDAY JULY 6, 2011
SYSTEM  INFORMATION: CPU MODEL=2097 SP7.1.2 TSO3.12.0 SMS31C0 ENVIRONMENT 
ARRAY: 

TASID Version 5.14 - CPU 2817-M32 (z196)

CPU utilization 100% 
CPU 2817-M32   (  3 CPUs)
ENQ Contention  2 
Real Stg 9437184K
Expand Stg 0K

MVS Information: z/OS   01.12.00z/Arch
JES Information: JES2 / z/OS1.12 / HJE7770 

Current time  15:14 on 2011/07/06 
Last IPL time 04:46 on 2011/06/26 
IPL Parameters 62A6 F0 M 1 
z/OS 01.12.00 JES version JES2 
..JES level   .12 
..RACF level  7.77.0
..TSO version 3.2.0 
..VTAM Level  6.1 
ProcStep $PGMRDFSMS level 1.12.0
Region   4M 
RACF Grp PGMGRP   DSF  level  1.17.0
Mode PR/SMISPF Level  6.1.0 
  HSM Level   01.12 

is this related?

TASID can not locate the LPAR information on this system

-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying,
or unauthorized use of this information, or the taking of any
action in reliance on the contents of this information is strictly
prohibited. If you have received this communication in error,
please notify us immediately by e-mail, and delete the original
message. Thank you 

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

manual tape library and external tape

[Pommier, Rex R.]

Hi list,

I have a question on reading a non SMS-managed tape in a manual tape library 
defined as SMS managed.

Our environment is we have a TS3400 manual tape library with 2 TS1120 drives in 
it.  This library is SMS defined because normally all we do with it is push our 
backups to it.  I have an external tape - maintenance from IBM - that I want to 
read via our MTL, which are the only tape drives we have on the system.  Is 
there some way of fooling/forcing the system to read this tape?

I think the problem is that it's a unlabeled tape.

I tried several different items with the following results:

//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD,
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)   real tape 
library in the UNIT parm, real vol-ser,

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE



//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=TS1120,DISP=OLD,
//   VOL=SER=11,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)  real tape 
library, fake to a vol-ser in my SMS vol-ser range

IEF343I RRPGENER S01COPY SYSUT1 - REQUEST FAILED - NOT ENOUGH NON-SYSTEM 
MANAGED VOLUMES ELIGIBLE


//SYSUT1   DD DSN=ESOINST,LABEL=(2,NL),UNIT=500,DISP=OLD,
//   VOL=SER=B04301,DCB=(LRECL=80,RECFM=FB,BLKSIZE=27920)try the actual 
address of tape drive instead of the library

IEF120I RRPGENER S01COPY SYSUT1 ALLOCATION FAILED - A NON-LIBRARY REQUEST 
SPECIFIED A LIBRARY DEVICE 0500


I tried shutting down OAM and it made no difference.

Any suggestions?

TIA.

Rex

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: Ads on IBM-MAIN

[Grinsell, Don]

I for one never cease to be amazed by the fact that the inevitable thrash
over these postings generates orders of magnitude more traffic than if we
simply let the offensive (highly subjective qualifier) post sail by.  If
it's a really blatant case of shameless self-promotion, e.g. check out
product x and order before midnight tonight, then a quiet email to Darren
would seem to be in order. If it's a response to a question, e.g. product x
has a feature that can solve your problem, then it seems to me the reply is
of value to at least the original poster.

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

"We have no more right to consume happiness without producing it than to
consume wealth without producing it."
-- George Bernard Shaw (1856-1950)

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

Re: z/OS 1.13 preview

[Jim Mulder]

> >:>> Anything with an SVC or PC entry does not require any changes for a 
64
> >:>bit
> >:>> above the bar caller - just for above the bar data.
> >
> >:>  That is not always true.  Consider, for example, what would happen
> >:>if you invoked GETMAIN or STORAGE OBTAIN via an SVC or PC from
> >:>an above the bar caller, and specified (or defaulted to)  LOC=RES.
> >
> >STORAGE is not guaranteed to return 31 bit storage for a 31 bit caller. 
Thus
> >it is not an issue to return 31 bit storage for a 64 bit caller.
> 
> But LOC=RES can not work properly for GETMAIN/STORAGE if the caller is 
above
> the bar, and therefore your statement that nothing invoked by SVC or PC
> would need to change is incorrect. STORAGE and GETMAIN would have to 
change
> to recognize this situation, which can not occur today.

  Well, that was going to be my point.  But after examination of the
code, I see that PC-entered STORAGE OBTAIN has had code to handle this
case since OS/390 2.10 (thanks to Peter Relson), and SVC-entered GETMAIN
and STORAGE OBTAIN has had code to handle this case since z/OS 1.5 
(thanks to me, although I had forgotten that I did that).

  But that doesn't mean that the code has been properly tested by 
invoking it from a program loaded above the bar, since there operating
system did not support that at the time that the code was written. 

  However,  PC-entered CPOOL BUILD definitely does not handle this
case, because it continues to consider only the low order 31 bits of
the caller's address when determining the resolution of LOC=RES. 

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

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

How to allocate PDSE's

[Ray Overby]

I was looking at my options for allocating a PDSE. They appear to be:

-ISPF 3.2 using LIBRARY as "Data set name type" value.

-JCL - DSNTYPE= parameter. You would use other parameters similar to 
what you would use for a PDS.


-SVC 99 in assembler - DALDSNT (DSNTYPE) Text unit appears to allow 
the specification of PDSE. You would use other parameters similar to 
what you would use for a PDS.


Am I missing any options?

It also appears that the TSO ALLOCATE command cannot be used to allocate 
PDSE's. Is this true? I reviewed the ALLOC command help and could not 
find a "DSNTYPE" parameter. Perhaps I missed it. I wonder if the LIKE() 
parameter might be used? I also looked at the ATTRIB TSO command and did 
not see a "DSNTYPE" parameter there either..


Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I 
was able to allocate one on a non-sms volume. I have not tried to use 
the file yet..


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

Re: Lines, Bars and ... mini-bars???

[Shmuel Metz (Seymour J.)]

In <201107051141.p65bf87f061...@ame7.swcp.com>, on 07/05/2011
   at 07:43 AM, David Cole  said:

>So what is the name for the 2G to 4G range of storage?

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

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

Re: Are IARV64 GETSHARED freed automatically (DETACH AFFINITY=SYSTEM) at job termination?

[Elpida Tzortzatos.]

Benyamin,

64-bit shared virtual storage is not freed unless all address spaces that had 
connected to the 64-bit shared memory object have terminated or have 
explicitly issued an IARV64 DETACH AFFINITY=LOCAL, AND an explicit IARV64 
DETACH AFFINITY=SYSTEM is also issued. The 64-bit shared virtual storage 
will not be freed if an IARV64 DETACH AFFINITY=SYSTEM is not explicitly 
issued.  


In your post you mentioned that the GETSHARED area appears to be freed 
even when an IARV64 DETACH AFFINITY=SYSTEM is not issued. How did you 
arrive at this conclusion? The area will not be freed unless a DETACH 
AFFINITY=SYSTEM is issued. 


Elpida Tzortzatos
z/OS Memory Management 

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

Re: Startio

[Lindy Mayfield]

Thank you!  Very helpful.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Blaicher, Chris
Sent: Wednesday, July 06, 2011 9:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Startio

Going to STARTIO is really going out in the deep end.  You are responsible for 
everything.  If you tell it to erase the system IPL pack, it will do it, but it 
will let you do very efficient I/O if you know what you are doing.

There is the 25 cent tour of STARTIO.  If you have other questions, please be 
as specific as you can and I or someone else on this list will try to get you 
the answers you want.

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

Re: If you found used gum in the parking lot, would you chew it?

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Hal Merritt
> 
> 
>  The root issue is that Windows, by design, appears to search every
nook and cranny for any sort of an
> executable and, if found, execute it. And there are a mind numbing
number of nooks and crannies.
> 
> The last I heard, MS never did figure out how to completely disable
the autorun facility. I speculate
> that many devices simply won't work at all unless given a chance to
submit code for execution.

Isn't that called "plug and pray"?  :-)

-jc-

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

Re: How to obtain the USERTOKEN of a SHARED 64 bit memory object?

[Walt Farrell]

On Wed, 6 Jul 2011 20:54:09 +0300, Binyamin Dissen
 wrote:

>It is available via "rsmdata hvshrdata" in a dump, but as far as I can see
>IARV64 LIST does not provide the information. I also cheated and looked at
>SHOWMVS, but it only does the IARV64 and thus does not have the data.
>
>Need I look for a non-standard solution, or am I missing something obvious?

Didn't you specify the user token initially when you acquired the storage?
Why not just remember it somewhere?

Or are you asking in some context other than that of the user of the storage?

-- 
Walt

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

Re: z/OS 1.13 preview

[Walt Farrell]

On Wed, 6 Jul 2011 21:08:20 +0300, Binyamin Dissen
 wrote:
>:>> Anything with an SVC or PC entry does not require any changes for a 64
>:>bit
>:>> above the bar caller - just for above the bar data.
>
>:>  That is not always true.  Consider, for example, what would happen
>:>if you invoked GETMAIN or STORAGE OBTAIN via an SVC or PC from
>:>an above the bar caller, and specified (or defaulted to)  LOC=RES.
>
>STORAGE is not guaranteed to return 31 bit storage for a 31 bit caller. Thus
>it is not an issue to return 31 bit storage for a 64 bit caller.

But LOC=RES can not work properly for GETMAIN/STORAGE if the caller is above
the bar, and therefore your statement that nothing invoked by SVC or PC
would need to change is incorrect. STORAGE and GETMAIN would have to change
to recognize this situation, which can not occur today.

-- 
Walt

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

Re: Annoyance with the IEZJSAB macro

[Paul Gilmartin]

On Wed, 6 Jul 2011 21:14:13 +0300, Binyamin Dissen wrote:

>On Wed, 6 Jul 2011 14:05:07 -0400 "Shmuel Metz (Seymour J.)" wrote:
>
>:>>Yes, as I reload R1. Why need I reissue the USING?
>
>:>The macro doesn't know that you are going to reload R1. IMHO it would
>:>be an error for IAZXJSAB to load a register and not drop the previous
>:>addressability unless it restored the previous register contents. If
>:>you insist on retaining a USING for R1 across IAZXJSAB, you can always
>:>use a labelled USING.
>
>Following your argument, any macro that alters R14-R1 should issue a DROP for
>those registers.
>
>But they do not.
>
Most important is documenting side effects.  Generally, macros
document which registers they modify.  Likewise, if a macro
changes the setting of USING (or PRINT, or whatever) that should
be documented.

Next in importance is lowering the Astonishment Factor.
programmers are accustomed to USINGs being preserved by
macro invocations regardless that the associated registers
are modified.  And they are not accustomed to inspecting
the documentation to see that a USING may be DROPped.

>Assembler is without training wheels. If I do not do a DROP, I do not want a
>DROP. It does not matter if STORAGE, GET or IAZJSAB are issued.
>
Irrelevant.  Analogously you might sqy that if you do not load
R1 you do not not want R1 modified.

And HLASM is developing the "training wheels".  Naming USINGs
in effect in listing page headers, warning of overlapping
USING ranges, warning of page zero references, etc.  Your
justifiable pride in mastering a difficult activity should not
lead to objections to making that activity simpler.

-- gil

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

Re: Startio

[Blaicher, Chris]

Lindy,

STARTIO is used when the user doesn't want to use a standard driver for some 
reason.  Sometimes, it is because a device you have added is not one that z/OS 
is set up to understand.  

Sometimes you use STARTIO because you are working on a whole device like the 
FDR product line.  (NOTE: I don't know what FDR uses, but STARTIO would be a 
good choice.)  If you want to read every data set, opening and closing them all 
gets expensive.

Sometimes it is to avoid overhead, like Syncsort.

The 'standard' I/O interfaces include QSAM, BSAM, EXCP, Media Manger and 
EXCP/VR.  Each has its pluses and minuses.  QSAM is great if you don't want to 
mess with anything, but it has the highest overhead.  With BSAM you have to do 
the blocking and de-blocking.  You can build records directly in a buffer, so 
if you know your data you can save some moves.  

With EXCP and EXCP/VR you can do more complicated I/O, like a CCW per record 
and do buffering in the channel program rather than moving data to a buffer.  
The problem there is all the page-fixing that the system has to do (EXCP) or 
you have to do (EXCP/VR).

With EXCP/VR and STARTIO it is possible to fix all your areas once at the 
beginning of you program and then just free them at the end and so save a lot 
of overhead.

If you want to start somewhere and learn the ins and outs of I/O, EXCP is a 
good place.  Even that is not for the faint of heart.  You have to detect what 
device type you are using, and if DASD, what its characteristics are, and then 
build the channel program to drive it all.  Once you can get EXCP to do 
everything you want, then convert it to EXCP/VR.  The channel program stays 
basically the same, but you have a lot more of the background work to do.  Up 
to this point the system will check that you are only going where you should 
go, i.e. running a DEBCHK against the I/O and killing the program if you are 
doing something bad.

Going to STARTIO is really going out in the deep end.  You are responsible for 
everything.  If you tell it to erase the system IPL pack, it will do it, but it 
will let you do very efficient I/O if you know what you are doing.

There is the 25 cent tour of STARTIO.  If you have other questions, please be 
as specific as you can and I or someone else on this list will try to get you 
the answers you want.


Christopher Y. Blaicher
BMC Software, Inc.
Senior Software Developer
Austin Development Lab

phone: 512.340.6154
mobile: 512.627.3803
fax: 512.340.6647

10431 Morado Circle 
Austin, TX 78759



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Lindy Mayfield
Sent: Wednesday, July 06, 2011 11:45 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Startio (Was: Ads on IBM-MAIN)

I asked  once how it is possible to make z/OS think something is a device, and 
the answer was a simple "STARTIO."  So I have been curious why.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Wednesday, July 06, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Startio (Was: Ads on IBM-MAIN)

I doubt that he uses "STARTIO", as he is on the device side and does CCW's. He 
doesn't care that the CCW's originated in EXCP, QSAM or STARTIO.

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

Re: z/OS 1.13 preview

[Edward Jaffe]

On 7/6/2011 10:53 AM, Paul Gilmartin wrote:

I understand that for some
few releases now CSV has been able to load CSECTs above the bar,


Even in z/OS 1.12 you cannot load CSECTs above the bar. RMODE(64) is treated as 
RMODE(ANY) for module loading and execution. You cannot specify RMODE(64) as a 
binder option. The only exception is data class C_WSA64 which can be loaded 
above the bar. I would not call that a CSECT. AFAIK, nothing generate via HLASM 
can be loaded above the bar.


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

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

Re: Annoyance with the IEZJSAB macro

[Binyamin Dissen]

On Wed, 6 Jul 2011 14:05:07 -0400 "Shmuel Metz (Seymour J.)"
 wrote:

:>In <4vq3171fiv25v2ogpb9gr0vphj4d3g4...@4ax.com>, on 07/04/2011
:>   at 07:36 PM, Binyamin Dissen  said:

:>>Yes, as I reload R1. Why need I reissue the USING?

:>The macro doesn't know that you are going to reload R1. IMHO it would
:>be an error for IAZXJSAB to load a register and not drop the previous
:>addressability unless it restored the previous register contents. If
:>you insist on retaining a USING for R1 across IAZXJSAB, you can always
:>use a labelled USING.

Following your argument, any macro that alters R14-R1 should issue a DROP for
those registers.

But they do not.

Assembler is without training wheels. If I do not do a DROP, I do not want a
DROP. It does not matter if STORAGE, GET or IAZJSAB are issued.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: CFSIZER?

[Meral Temel (Garanti Teknoloji)]

 I  agree that it should have been written in z196 redbooks too although I know 
it  is written in SAPR guide of z196 Release Version 4 (October 2010).
I don't know how many other customers know this before upgrading.But as 
expected, it is good  that this  information was mentioned in some sessions at 
SHARE and also it seems like IBM added this information to z196 pr/sm guide 
with update level 00a.  It was not there when it was first published. - 
According to documents/sessions the old  image size was 128 MB.Thinking 20-25 
GB of size for some users,this difference may not be that much but for some 
customers with storage constrains, the difference maybe important, as one 
example which is mentioned here. 

Pr/sm Level 00a, it is  now written in  as below

Important Note
CF structures allocated in a CFLEVEL 17 coupling facility might need to be
significantly larger than in previous CFLEVELs, in order to be allocated with a
similar number of usable structure objects. It is highly recommended to use
the CFSIZER tool: http://www.ibm.com/systems/support/z/cfsizer/.

In addition to the potential structure size changes mentioned in this note, the
CFCC Licensed Internal Code (LIC) for CFLEVEL 17 requires a minimum of
512 MB of central storage in order to activate. The increase in the minimum
storage amount is required to accommodate the CFLEVEL 17 enhancements.
Failure to define enough central storage will prevent the CFCC image from
activating. 
Best Regards
Meral




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Dick Bond
Sent: Wednesday, July 06, 2011 8:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: [IBM-MAIN] CFSIZER?

Also ran into that here since we also followed the "big bang" theory while
replacing two z9's with one z196.  CFSIZER is "ok" if taken
"tongue-in-cheek", but some warning about CFLEVEL code size should be
available somewhere.   Wait state since GRS wouldn't come up due to not
enough storage left in the CFs to allocate its structure.   Doubled the size
of the CF storage and all was well - but that was after trying various other
things first since I had no warning of the code size increase.

On Tue, Jul 5, 2011 at 5:55 AM, Mark Zelden  wrote:

> On Tue, 5 Jul 2011 11:48:37 +0200, mario@tiscali 
> wrote:
>
> >
> >Also, when moving to CFLEVEL17 don't forget that the size of the CF
> >Control Code itself increases significantly. From some 100 MB to some
> >500 MB if I remember correctly. The CFCC LPAR memory definition should
> >be updated to accomodate this.
> >
>
> This is the one that bothered me - only because it was a surprise.  I
> couldn't
> find anything written that told me it was normal nor was it mentioned in
> any of the z196 pre-install meetings that my client had.  It took me a
> while
> to get confirmation from a large systems specialist within IBM that it was
> expected. He passed along this information from a colleague:
>
> "the growth of the image is do to many enhancements in function and
> recovery
> in the CFCC 17 code." CFCC 17 on z196 has added some function and added
> enhanced recovery of the CF code. The number of supported structures was
> increased from 1023 to 2047 structures, the number of logical connection to
> a structure was increased, and the recovery was enhanced to improve
> nondisruptive MCL activation to maintain code levels and the ability to
> take
> nondisruptive CF dumps. CFCC recovery code has been added to take
> nondisruptive dumps of the CF and signal all connected images with a CRW
> machine check to invoke sysplex wide SVC and nondisruptive CF dumps for
> some
> CF recovery events to gather problem data."
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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


This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the message confidential. 
The sender has no responsibility for the accuracy or correctness of the 
information in the message and its attachments. Our company shall have no 
liability for any changes or late receiving, loss of integrity and 
confidentiality, viruses and any damages caused in anyway to yo

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In , on 07/05/2011
   at 08:00 AM, Alan Altmark  said:

>Whether it's free or not isn't the issue.  There is a significant
>difference among
>(1) calling out a product (commercial or freeware) as a possible
>solution to a posted problem
>(2) the author occasionally posting a reminder of his product 
>(3)discussing the technical aspects of the product

(4)Announcing a new product or a new release.

>I don't object to the second since the product is free and has
>demonstrated benefit to the readership. 

That doesn't justify posting an advertisement. OTOH, I see nothing
wrong with a tombstone reference in the sig

>The third, however, is Technical Support and can be reasonably
>requested to reside in another forum. 

If it's a mainframe product then I see nothing wrong with technical
support here. That's especially true for products involving multiple
vendors or multiple divisions of the same vendor.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In
,
on 07/05/2011
   at 07:46 PM, shai hess  said:

>IBM-MAIN to my opinion is not suppose to be democratic forum.

Correct; in the last analysis it is Darrens responsibility to set the
rules.

>I was wrong when I came to conclusion that I contribute to this
>forum by talking technically about my product to everyone.

Always assume that only a subset will be interested in any given
topic.

>I was wrong, even if minority group think that my posts are not OK
>to publish in this forum, I must accept it.

What counts is what Darrens says. By all means take different
viewpoints into account, but if he says that it's legitimate then it's
legitimate. If he says it's not, then it's not.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z/OS 1.13 preview

[Binyamin Dissen]

On Wed, 6 Jul 2011 14:03:02 -0400 Jim Mulder  wrote:

:>IBM Mainframe Discussion List  wrote on 07/06/2011 
:>12:42:25 PM:

:>> :>Other possible 'restrictions' immediately come to mind as well. 
:>> For example, 
:>> :>there are hundreds of callable z/OS services. I imagine the process of 

:>> :>inspecting, updating, testing and documenting required to make 
:>> them all work for 
:>> :>callers executing above the bar will take years.
 
:>> Anything with an SVC or PC entry does not require any changes for a 64 
:>bit
:>> above the bar caller - just for above the bar data.

:>  That is not always true.  Consider, for example, what would happen
:>if you invoked GETMAIN or STORAGE OBTAIN via an SVC or PC from
:>an above the bar caller, and specified (or defaulted to)  LOC=RES. 

STORAGE is not guaranteed to return 31 bit storage for a 31 bit caller. Thus
it is not an issue to return 31 bit storage for a 64 bit caller.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Z/OS Newbie question

[Paul Gilmartin]

On Mon, 4 Jul 2011 14:42:37 +0300, Hilary Hurwitz wrote:
>
>The other thing I would like is to be able to see the compile dates in a load 
>library - all the library at once. We do have File Aid, but it is a pain to 
>get all dates (and maybe even sort on date ?)
>
Wouldn't it be nice to be able to keep your load modules in a Unix
filesystem (HFS, zFS, whatever) where everything has a date stamp?

//STEPLIB  DD  PATH=...

And even put Unix directories in LINKLIST?

(Would require some discipline maintaining those date stamps.)

-- gil

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

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In , on 07/04/2011
   at 07:55 PM, Ed Gould  said:

>I was going to write you off list but since you brought it up. There
>is a on going advertisement on the list here that started as a minor
>annoyance and become a major pita. That is the bandwidth pig on
>IBM-MAIN of mfnet or what ever it's called. IMO it should be moved
>off to a separate list. The constant announcements of features and
>bugs and trial offers is getting past noise and is worth setting up a
>spam filter for.

While I wouldn't mind seeing those posts reduced in size and
frequency, and in more of a tombstone format, I questionable whether
they are advertisements. Certainly brief announcements of new
mainframe software products and of new releases are useful.

OTOH, an official set of guidelines on where the line is would be
nice.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In
,
on 07/04/2011
   at 08:34 PM, shai hess  said:

>I feel sorry that some people think that MFNetDisk thread is related
>to MF the same as Viagra related to MF.

Mah pitom! Who wrote anything about viagra? The question at issue is
whether your announcements are advertising, not whether the software
is legitimate.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In <0377b9a583fd0e4aacd676ee33ee994b4da73...@sdkmail13.emea.sas.com>,
on 07/05/2011
   at 12:22 PM, Lindy Mayfield  said:

>Lionel has a wonderful and free product that many people use called
>XMITIP.  He has his own yahoo group for people who are interested in
>the product, ask for new features, report bugs, and Lionel can also
>report any changes he made.

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

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

Re: Ads on IBM-MAIN

[Shmuel Metz (Seymour J.)]

In <6023e7ce-becd-4541-8a4c-085ecd33c...@yahoo.com>, on 07/06/2011
   at 11:55 AM, Ed Gould  said:

>I will stand and say one announcement is fine discussion of it really
>belongs on another list.

I would prefer to not see this list balkanized. If someone announces a
mainframe product here, I want the discussion here. I don't want to
subscribe to a bunch of google groups and yahoo groups.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Annoyance with the IEZJSAB macro

[Shmuel Metz (Seymour J.)]

In <4vq3171fiv25v2ogpb9gr0vphj4d3g4...@4ax.com>, on 07/04/2011
   at 07:36 PM, Binyamin Dissen  said:

>Yes, as I reload R1. Why need I reissue the USING?

The macro doesn't know that you are going to reload R1. IMHO it would
be an error for IAZXJSAB to load a register and not drop the previous
addressability unless it restored the previous register contents. If
you insist on retaining a USING for R1 across IAZXJSAB, you can always
use a labelled USING.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Annoyance with the IEZJSAB macro

[Shmuel Metz (Seymour J.)]

In , on 07/05/2011
   at 12:48 AM, Paul Gilmartin  said:

>o A blanket statement in any relevant Users Guide(s) that no macro
>  modifies any caller's setting such as USING (PRINT? Others?)
>  without restoring it before returning to caller.

I would prefer a blanket statement that no macro should be assumed to
retain a simple USING for R14, R15 or R1.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: z/OS 1.13 preview

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 07/06/2011 
12:42:25 PM:

> :>Other possible 'restrictions' immediately come to mind as well. 
> For example, 
> :>there are hundreds of callable z/OS services. I imagine the process of 

> :>inspecting, updating, testing and documenting required to make 
> them all work for 
> :>callers executing above the bar will take years.
> 
> Anything with an SVC or PC entry does not require any changes for a 64 
bit
> above the bar caller - just for above the bar data.

  That is not always true.  Consider, for example, what would happen
if you invoked GETMAIN or STORAGE OBTAIN via an SVC or PC from
an above the bar caller, and specified (or defaulted to)  LOC=RES. 

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

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

Re: Z/OS Newbie question

[Frank Swarbrick]

Indeed, I ran in to the same things when converting from VSE to z/OS last year. 
 I look forward to any useful ideas.
-- 

Frank Swarbrick
Applications Architect - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO  USA
P: 303-235-1403


On 7/4/2011 at 5:42 AM, in message
, Hilary Hurwitz
 wrote:
> I recently moved from being System programmer and ADABAS DBA in a VSE/ESA 
> shop and "converted" myself to DBA in a Z/OS 1.9 shop.
> 
> I am still a little overwhelmed by the sheer volume of work, and I managed 
> to get used to saying ISPF and  JES instead of Vollie and Power :)
> 
> I really miss one function - provided by FAQS/ASO.
> 
> At the end of every batch job, it printed out a list of modules used and 
> which libraries they were taken from.
> 
> Since we are in the middle of some major conversions here and have pretty 
> complicated jcl procs, it would really help me to have this feature.
> 
> Has anyone written it ? Could it be done ? Maybe in REXX ?
> 
> The other thing I would like is to be able to see the compile dates in a 
> load library - all the library at once. We do have File Aid, but it is a pain 
> to get all dates (and maybe even sort on date ?)
> 
> Ah - the wish list gets longer.
> 
> Thanks for your help
> 
> Hilary Hurwitz
> Israel National Insurance (Social Security)
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

>>> 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

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

Re: z/OS 1.13 preview

[Edward Jaffe]

On 7/6/2011 9:42 AM, Binyamin Dissen wrote:

On Wed, 6 Jul 2011 09:33:20 -0700 Edward Jaffe
wrote:

:>Other possible 'restrictions' immediately come to mind as well. For example,
:>there are hundreds of callable z/OS services. I imagine the process of
:>inspecting, updating, testing and documenting required to make them all work 
for
:>callers executing above the bar will take years.

Anything with an SVC or PC entry does not require any changes for a 64 bit
above the bar caller - just for above the bar data.


Some SVCs inspect RBOPSW, some (e.g., MODESET) modify flags in RBOPSW, and some 
update the next sequential instruction address in RBOPSW. Seems like there would 
need to be an accommodation made to either a) allow these routines to 
transparently continue working or to b) modify them to access the new 128-bit 
PSW fields as necessary. The last case seems especially tricky.


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

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

How to obtain the USERTOKEN of a SHARED 64 bit memory object?

[Binyamin Dissen]

It is available via "rsmdata hvshrdata" in a dump, but as far as I can see
IARV64 LIST does not provide the information. I also cheated and looked at
SHOWMVS, but it only does the IARV64 and thus does not have the data.

Need I look for a non-standard solution, or am I missing something obvious?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: z/OS 1.13 preview

[Paul Gilmartin]

On Wed, 6 Jul 2011 09:33:20 -0700, Edward Jaffe wrote:

>On 7/5/2011 1:57 PM, Steve Comstock wrote:
>
>The Feb 15, 2011 announcement preview is the only public information I'm aware
>of. It tells you a lot if you know how to translate the 'announcementese'. It's
>been out there four months which proves (I guess) that nobody reads these
>announcement previews. Many thanks to Jim Mulder for bringing this to light on
>IBM-MAIN!
>
In fact, in February Steve commented enthusiastically on some topics
in the announcement.  I assume he read part of it, then got carried
away.

>The part where IBM talks about this enhancement providing VSCR to applications
>that 'imbed code in data areas' seems to suggest that applications might have 
>to
>manually copy eligible code into data areas above the bar. If so, that seems
>like a pretty big 'restriction' to me.
>
An earlier post in this thread suggested this refers to OO designs
that bundle methods and associated data.  I understand that for some
few releases now CSV has been able to load CSECTs above the bar,
but to date this is useful only for "data areas" (and possibly for
disabled code).

-- gil

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

Re: CFSIZER?

[Dick Bond]

Also ran into that here since we also followed the "big bang" theory while
replacing two z9's with one z196.  CFSIZER is "ok" if taken
"tongue-in-cheek", but some warning about CFLEVEL code size should be
available somewhere.   Wait state since GRS wouldn't come up due to not
enough storage left in the CFs to allocate its structure.   Doubled the size
of the CF storage and all was well - but that was after trying various other
things first since I had no warning of the code size increase.

On Tue, Jul 5, 2011 at 5:55 AM, Mark Zelden  wrote:

> On Tue, 5 Jul 2011 11:48:37 +0200, mario@tiscali 
> wrote:
>
> >
> >Also, when moving to CFLEVEL17 don't forget that the size of the CF
> >Control Code itself increases significantly. From some 100 MB to some
> >500 MB if I remember correctly. The CFCC LPAR memory definition should
> >be updated to accomodate this.
> >
>
> This is the one that bothered me - only because it was a surprise.  I
> couldn't
> find anything written that told me it was normal nor was it mentioned in
> any of the z196 pre-install meetings that my client had.  It took me a
> while
> to get confirmation from a large systems specialist within IBM that it was
> expected. He passed along this information from a colleague:
>
> "the growth of the image is do to many enhancements in function and
> recovery
> in the CFCC 17 code." CFCC 17 on z196 has added some function and added
> enhanced recovery of the CF code. The number of supported structures was
> increased from 1023 to 2047 structures, the number of logical connection to
> a structure was increased, and the recovery was enhanced to improve
> nondisruptive MCL activation to maintain code levels and the ability to
> take
> nondisruptive CF dumps. CFCC recovery code has been added to take
> nondisruptive dumps of the CF and signal all connected images with a CRW
> machine check to invoke sysplex wide SVC and nondisruptive CF dumps for
> some
> CF recovery events to gather problem data."
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Lines, Bars and ... mini-bars???

[Walt Farrell]

On Wed, 6 Jul 2011 11:50:05 -0500, Eric Bielefeld 
wrote:

>What release were those changes made?  I guess I have to start reading the
release notes again.
>

I'd start with Elpida's presentation, as it gives the details. 
http://share.confex.com/share/115/webprogram/Handout/Session7511/BostonSHAREVSM.pdf

We developed the Java enhancement (from her presentation) in z/OS V1.11, but
PTFs for it exist back to V1.08.

The second enhancement came in z/OS V1.12.

-- 
Walt

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

Re: RSU on z/OS 1.10

[sourabh khandelwal]

Thanks everybody for reply.

I will create a big zFS dataset in OMVS and then rerun this job for unzip.

Regards
Saurabh

On Wed, Jul 6, 2011 at 10:42 PM, Linda Mooney wrote:

> Hi Jags,
>
>
>
> I'm sorry. It was past midnight. :-)
>
>
>
> Linda
>
>
> - Original Message -
>
>
> From: "jagadishan perumal" 
> To: IBM-MAIN@bama.ua.edu
> Sent: Wednesday, July 6, 2011 1:02:11 AM
> Subject: Re: RSU on z/OS 1.10
>
> Hi Linda,
>
> Original Poster of this message is Sourabh not me :) .
>
> Regards,
> Jags
>
> On Wed, Jul 6, 2011 at 1:09 PM, Linda Mooney  >wrote:
>
> > Hi Jags,
> >
> >
> >
> > Multi-volume HFS files are required to be SMS controlled.  Are you sure
> > that you are actually writing to the secondary volumes?
> >
> >
> >
> > Also, your parm value says "HASH=NO". Are you using crypto?
> >
> >
> >
> > HTH,
> >
> >
> >
> > Linda
> >
> >
> > - Original Message -
> >
> >
> > From: "sourabh khandelwal" 
> > To: IBM-MAIN@bama.ua.edu
> > Sent: Wednesday, July 6, 2011 12:03:14 AM
> > Subject: Re: RSU on z/OS 1.10
> >
> > Hello,
> >   Getting below error on SYSPRINT for my unzip job.
> >
> >
> >
> ---
> > DATE 07/05/11  TIME 10:48:30  SMP/E
> > 35.16
> > UNIX COMMAND OUTPUT
> >
> > > /bin/pax -zvrf
> > /u/zos110/rsu1104/SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z .
> > > /GIMFAF.XML
> >
> > ./GIMFAF.XML
> >
> >
> ---
> > DATE 07/05/11  TIME 10:54:07  SMP/E
> > 35.16
> > UNIX COMMAND OUTPUT
> >
> > > /bin/pax -zvrf
> > /u/zos110/rsu1104/SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z
> >
> > ./GIMFAF.XML
> > ./SMPPTFIN
> > pax: FSUM6260 write error on file "./SMPPTFIN": EDC5133I No space left on
> > device
> >  BOTTOM OF DATA
> > 
> >
> >
> > Regards
> > Saurabh
> >
> >
> > On Wed, Jul 6, 2011 at 12:02 PM, sourabh khandelwal <
> > sourabhkhandelwal...@gmail.com> wrote:
> >
> > > Hello,
> > > I am trying to instal RSU 1104 on z/OS 1.10 system . The RSU
> size
> > > is 4.6 GB.
> > >
> > > But when I am trying to unzip the MCS and HOLD data, I am
> getting
> > > error for insufficient space on volume. To resolve this problem I
> > performed
> > > below stpes.
> > >
> > > 1) I created the multi volume data set and tried again to unzip it .
> But
> > I
> > > am getting the same error for space.
> > >
> > > 2) Initially I tried with 2 volume then went upto 8 volume dataset .
> But
> > > getting same error for space.
> > >
> > >upto  8 volume x 4300 = 34,400 Cylinders of data.
> > >
> > > for reference below is the JCL which is used to unzip this RSU.
> > >
> > > //RSU1008C JOB (3623),'SAURABH',MSGCLASS=X,CLASS=A,
> > > // NOTIFY=&SYSUID,REGION=0M
> > > //UNZIPEXEC PGM=GIMUNZIP,PARM='HASH=NO'
> > > //SYSUT3   DD UNIT=3390,SPACE=(CYL,(400,100))
> > > //SYSUT4   DD UNIT=3390,SPACE=(CYL,(400,100))
> > > //SMPOUT   DD SYSOUT=*
> > > //SYSPRINT DD SYSOUT=*
> > > //SMPDIR   DD PATH='/u/zos110/rsu1104',
> > > //PATHDISP=KEEP
> > > //SYSINDD DATA,DLM=$$
> > > 
> > >  > > name="SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z"
> > > newname="SMPE.ZOS110.RSU.S5373846.SMPMCS"
> > > replace="yes">
> > > 
> > >  > > name="SMPHOLD/S0002.SHOPZ.S5373846.SMPHOLD.pax.Z"
> > > volume="RSU004"
> > > newname="SMPE.ZOS110.RSU.S5373846.SMPHOLD">
> > > 
> > > 
> > > $$
> > > --
> > > Thanks & Regards
> > > Saurabh Khandelwal
> > >
> >
> >
> >
> > --
> > Thanks & Regards
> > Saurabh Khandelwal
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>



-- 
Thanks & Regards
Saurabh Khandelwal

--
For IBM-MAIN subscribe / signoff / archive access instruct

Re: Ads on IBM-MAIN

[Mark Zelden]

On Wed, 6 Jul 2011 11:48:59 -0400, Gord Tomlin
 wrote:

>I suspect that the reference to a post from a software company is
>referring to a post I made on Monday on a thread started by Hilary
>Hurwitz with the subject "Z/OS Newbie question".
>

I *highly* doubt it.

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

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

Re: RSU on z/OS 1.10

[Linda Mooney]

Hi Jags, 



I'm sorry. It was past midnight. :-) 



Linda 


- Original Message -


From: "jagadishan perumal"  
To: IBM-MAIN@bama.ua.edu 
Sent: Wednesday, July 6, 2011 1:02:11 AM 
Subject: Re: RSU on z/OS 1.10 

Hi Linda, 

Original Poster of this message is Sourabh not me :) . 

Regards, 
Jags 

On Wed, Jul 6, 2011 at 1:09 PM, Linda Mooney wrote: 

> Hi Jags, 
> 
> 
> 
> Multi-volume HFS files are required to be SMS controlled.  Are you sure 
> that you are actually writing to the secondary volumes? 
> 
> 
> 
> Also, your parm value says "HASH=NO". Are you using crypto? 
> 
> 
> 
> HTH, 
> 
> 
> 
> Linda 
> 
> 
> - Original Message - 
> 
> 
> From: "sourabh khandelwal"  
> To: IBM-MAIN@bama.ua.edu 
> Sent: Wednesday, July 6, 2011 12:03:14 AM 
> Subject: Re: RSU on z/OS 1.10 
> 
> Hello, 
>           Getting below error on SYSPRINT for my unzip job. 
> 
> 
> ---
>  
> DATE 07/05/11  TIME 10:48:30                                      SMP/E 
> 35.16 
> UNIX COMMAND OUTPUT 
> 
> > /bin/pax -zvrf 
> /u/zos110/rsu1104/SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z . 
> > /GIMFAF.XML 
> 
> ./GIMFAF.XML 
> 
> ---
>  
> DATE 07/05/11  TIME 10:54:07                                      SMP/E 
> 35.16 
> UNIX COMMAND OUTPUT 
> 
> > /bin/pax -zvrf 
> /u/zos110/rsu1104/SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z 
> 
> ./GIMFAF.XML 
> ./SMPPTFIN 
> pax: FSUM6260 write error on file "./SMPPTFIN": EDC5133I No space left on 
> device 
>  BOTTOM OF DATA 
>  
> 
> 
> Regards 
> Saurabh 
> 
> 
> On Wed, Jul 6, 2011 at 12:02 PM, sourabh khandelwal < 
> sourabhkhandelwal...@gmail.com> wrote: 
> 
> > Hello, 
> >         I am trying to instal RSU 1104 on z/OS 1.10 system . The RSU size 
> > is 4.6 GB. 
> > 
> >         But when I am trying to unzip the MCS and HOLD data, I am getting 
> > error for insufficient space on volume. To resolve this problem I 
> performed 
> > below stpes. 
> > 
> > 1) I created the multi volume data set and tried again to unzip it . But 
> I 
> > am getting the same error for space. 
> > 
> > 2) Initially I tried with 2 volume then went upto 8 volume dataset . But 
> > getting same error for space. 
> > 
> >            upto  8 volume x 4300 = 34,400 Cylinders of data. 
> > 
> > for reference below is the JCL which is used to unzip this RSU. 
> > 
> > //RSU1008C JOB (3623),'SAURABH',MSGCLASS=X,CLASS=A, 
> > //             NOTIFY=&SYSUID,REGION=0M 
> > //UNZIP    EXEC PGM=GIMUNZIP,PARM='HASH=NO' 
> > //SYSUT3   DD UNIT=3390,SPACE=(CYL,(400,100)) 
> > //SYSUT4   DD UNIT=3390,SPACE=(CYL,(400,100)) 
> > //SMPOUT   DD SYSOUT=* 
> > //SYSPRINT DD SYSOUT=* 
> > //SMPDIR   DD PATH='/u/zos110/rsu1104', 
> > //            PATHDISP=KEEP 
> > //SYSIN    DD DATA,DLM=$$ 
> >  
> >  > name="SMPPTFIN/S0001.SHOPZ.S5373846.SMPMCS.pax.Z" 
> > newname="SMPE.ZOS110.RSU.S5373846.SMPMCS" 
> > replace="yes"> 
> >  
> >  > name="SMPHOLD/S0002.SHOPZ.S5373846.SMPHOLD.pax.Z" 
> > volume="RSU004" 
> > newname="SMPE.ZOS110.RSU.S5373846.SMPHOLD"> 
> >  
> >  
> > $$ 
> > -- 
> > Thanks & Regards 
> > Saurabh Khandelwal 
> > 
> 
> 
> 
> -- 
> Thanks & Regards 
> Saurabh Khandelwal 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
> 
> -- 
> For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO 
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
> 

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

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

Re: Z/OS Maintanance

[Ed Gould]

Bobbie,

I really think it depends on the situation. At one time we were early ship on a 
couple of IBM devices and was regularly d/l fixes daily and applying daily 
fixes.

For hipers it really depends. Say it was for something that I knew we didn't 
use I wouldn't even consider it. Example off the top of my head say BTAM I 
would not waste any time on it. I had a damn good idea what was going on so a 
judgement call on my part was made. I never had my boss question me on my 
decision processes.

Ed 

Sent from my iPad

On Jul 6, 2011, at 6:54 AM, Bobbie Justice  wrote:

> Answer: It depends. 
> 
> I've always kept roughly 3 months behind IBM in the RSU + hipers field. I
> receive holddata regularly, review (and in relevant cases apply) hipers
> outside of that schedule if I deem it necessary. 
> "You can't be applying maintenance daily, unless you're really bored". 
> 
> Sometimes you get lucky and don't hit problem xyz, other times you don't
> get so lucky. 
> 
> YMMV. 
> 
> Bobbie Justice
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: Rexx code to reach an IP

[Tony Harminc]

On 6 July 2011 11:01, jagadishan perumal  wrote:

> I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
> mainframe  Are there any sample Rexx that can be used to reach the above IP
> using TCPIP Socket ?

Look in your .SEZAINST dataset for members EZARXRxx.

Tony H.

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

Re: Lines, Bars and ... mini-bars???

[Eric Bielefeld]

What release were those changes made?  I guess I have to start reading the 
release notes again.
 
--
Eric Bielefeld
Systems Programmer


 Walt Farrell  wrote: 
> Yes, originally we had a 2GiB dead space between 2**31 and (2**32)-1, but we
> no longer have that.
> 
> Instead, we revised it that so that a 32GiB area starting at 2**31 was
> reserved for use by Java.
> 
> And then we further revised that so there's an additional 256GiB above that
> reserved for system usage.
> 
> -- 
> Walt

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

Re: Ads on IBM-MAIN

[Ed Gould]

Allan,
This started two or so years ago. When the writer inundated the list with 
information on the list. I asked him privately to slow down the volume. he did 
so and indeed the volume slowed to an acceptable level(I didn't care for it but 
since no one else cared so I remained silent). 
The current volume and it's associated noise was in my opinion excessive. Like 
I said before I was considering writing to Darren but his email address is on 
another computer and I kept forgetting to write the note.
I will stand and say one announcement is fine discussion of it really belongs 
on another list. I for one would never us his product  as I am of the opinion 
that no software should be run on a PC or the mainframe that doesn't have a 
signed contract with terms agreed upon.
It's one thing for a PC but the mainframe is whole different circumstance. 
If you are OK with that fine that's your comfort level. I would suggest you 
rethink it.

Ed

Sent from my iPad

On Jul 6, 2011, at 7:22 AM, "Staller, Allan"  wrote:

> I do not feel that Shai has violated the spirit of this list.  He is not
> charging for his product.
> There have been occasional posts from one of the major software vendors
> (actually an individual working at that vendor) 
> that come far closer to "crossing the line" than Shai. But again, they
> were providing information, not soliciting.
> 
> Unlike Ed, I prefer to have information about something that might (or
> might not) be of use to me.
> Information is the commodity this list was created to exchange.
> Most of the posts on this list take less than 10 seconds to read
> (including this one).
> 
> I can spare 10 seconds a few times a day to read the posts and decide if
> they are of any interest.
> 
> Just my $0.02 USD
> 
> 
> 
> While I am sure its a nice product, a list dedicated to it is
> appropriate.
> 
> Ed
> 
> .Snippage
> 
> 
>> I was going to write you off list but since you brought it up. There
> is a on going advertisement on the list here that started as a minor
> annoyance and become a major pita.
>> That is the bandwidth pig on IBM-MAIN of mfnet or what ever it's
> called. IMO it should be moved off to a separate list. The constant
> announcements of features and bugs and trial offers is getting past
> noise and is worth setting up a spam filter for. 
>> Could you please consider asking the author to create it's own list,
> please? Thanks.
>> 
>> Ed 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: z/OS 1.13 preview

[Steve Comstock]

On 7/6/2011 10:33 AM, Edward Jaffe wrote:

On 7/5/2011 1:57 PM, Steve Comstock wrote:


WOW! That's a big deal.

Is this documented somewhere public? Or is this NDA?

Do you what the "certain restrictions" are? Can you tell us? Can
you tell us how it's done?


The Feb 15, 2011 announcement preview is the only public information I'm aware
of. It tells you a lot if you know how to translate the 'announcementese'. It's
been out there four months which proves (I guess) that nobody reads these
announcement previews. Many thanks to Jim Mulder for bringing this to light on
IBM-MAIN!


I read that announcement, and even posted an allusion
to it in one of my posts. I was looking for the next
level of detail. Guess I'll just have to wait.



The previewed enhancement allows 'applications' that need 'virtual storage
constraint relief' (i.e., ordinary, enabled, DAT-ON code) to have some 'programs
running in 64-bit storage'. From that we can infer that the operating system can
now save status over an interrupt for code located above the bar.I agree that is
a 'big deal'!

The part where IBM talks about this enhancement providing VSCR to applications
that 'imbed code in data areas' seems to suggest that applications might have to
manually copy eligible code into data areas above the bar. If so, that seems
like a pretty big 'restriction' to me.

Other possible 'restrictions' immediately come to mind as well. For example,
there are hundreds of callable z/OS services. I imagine the process of
inspecting, updating, testing and documenting required to make them all work for
callers executing above the bar will take years. Enablement and/or approval of
each service will likely need to be individually justified for expenditure of
necessary development, test and tech-writing resources. In z/OS 1.13, probably
only a handful (or possibly none!) of the z/OS services will have been
enabled/approved for use by such code.

Saving status over an interrupt is indeed a 'big deal', but only the tip of the
iceberg...




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* Special promotion: 15% off on all DB2 training classes
scheduled by September 1, taught by year end 2011

* Check out our entire DB2 curriculum at:
http://www.trainersfriend.com/DB2_and_VSAM_courses/DB2curric.htm

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

Re: If you found used gum in the parking lot, would you chew it?

[Hal Merritt]

 The root issue is that Windows, by design, appears to search every nook and 
cranny for any sort of an executable and, if found, execute it. And there are a 
mind numbing number of nooks and crannies.  

The last I heard, MS never did figure out how to completely disable the autorun 
facility. I speculate that many devices simply won't work at all unless given a 
chance to submit code for execution.  



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Wednesday, July 06, 2011 6:22 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: If you found used gum in the parking lot, would you chew it?

On Wed, 6 Jul 2011 06:09:26 -0500 Norbert Friemel  wrote:

:>On Thu, 30 Jun 2011 11:56:56 -0500, Mike Schwab wrote:

:>>The main thing would be to disable the auto run feature before inserting.

:>The "evil mouse" works with autorun disabled:
:>http://pentest.snosoft.com/2011/06/24/netragards-hacker-interface-device-hid/

I don't really get it.

Is a mouse such a thick client that the OS has to run code from it? The drivers 
extract executable code from the mouse memory?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: Startio (Was: Ads on IBM-MAIN)

[Lindy Mayfield]

I asked  once how it is possible to make z/OS think something is a device, and 
the answer was a simple "STARTIO."  So I have been curious why.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Binyamin Dissen
Sent: Wednesday, July 06, 2011 10:03 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Startio (Was: Ads on IBM-MAIN)

I doubt that he uses "STARTIO", as he is on the device side and does CCW's. He 
doesn't care that the CCW's originated in EXCP, QSAM or STARTIO.

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

Re: B&T cables

[August Carideo]

I have some in RYE, NY curled up under floor if still needed
everything here was converted to ESCON or FICON
Augie



   
 Scott Rowe
   To 
 Sent by: IBM  IBM-MAIN@bama.ua.edu
 Mainframe  cc 
 Discussion List   
  Re: B&T cables  
   
   
 07/06/2011 12:23  
 PM
   
   
 Please respond to 
   IBM Mainframe   
  Discussion List  

   
   




We have at least one set of B&T cables under our floor in Ohio (Cleveland
area) that will be de-commissioned in early August.  I would have to check,
but we might also have some non-IBM 3270s lying around.

On Fri, Jul 1, 2011 at 3:52 PM, William Donzelli
wrote:

> I have a couple of requests for some bus and tag cables - one request
> from the Computer History Museum - as well as a request for some old
> IBM 3270 family terminals (any vintage).
>
> Does anyone know of any in the New York/New England area I could go
fetch?
>
> --
> Will
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank
you.

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

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

Re: z/OS 1.13 preview

[Binyamin Dissen]

On Wed, 6 Jul 2011 09:33:20 -0700 Edward Jaffe 
wrote:

:>Other possible 'restrictions' immediately come to mind as well. For example, 
:>there are hundreds of callable z/OS services. I imagine the process of 
:>inspecting, updating, testing and documenting required to make them all work 
for 
:>callers executing above the bar will take years.

Anything with an SVC or PC entry does not require any changes for a 64 bit
above the bar caller - just for above the bar data.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: z/OS 1.13 preview

[Edward Jaffe]

On 7/5/2011 1:57 PM, Steve Comstock wrote:


WOW! That's a big deal.

Is this documented somewhere public? Or is this NDA?

Do you what the "certain restrictions" are? Can you tell us? Can
you tell us how it's done?


The Feb 15, 2011 announcement preview is the only public information I'm aware 
of. It tells you a lot if you know how to translate the 'announcementese'. It's 
been out there four months which proves (I guess) that nobody reads these 
announcement previews. Many thanks to Jim Mulder for bringing this to light on 
IBM-MAIN!


The previewed enhancement allows 'applications' that need 'virtual storage 
constraint relief' (i.e., ordinary, enabled, DAT-ON code) to have some 'programs 
running in 64-bit storage'. From that we can infer that the operating system can 
now save status over an interrupt for code located above the bar.I agree that is 
a 'big deal'!


The part where IBM talks about this enhancement providing VSCR to applications 
that 'imbed code in data areas' seems to suggest that applications might have to 
manually copy eligible code into data areas above the bar. If so, that seems 
like a pretty big 'restriction' to me.


Other possible 'restrictions' immediately come to mind as well. For example, 
there are hundreds of callable z/OS services. I imagine the process of 
inspecting, updating, testing and documenting required to make them all work for 
callers executing above the bar will take years. Enablement and/or approval of 
each service will likely need to be individually justified for expenditure of 
necessary development, test and tech-writing resources. In z/OS 1.13, probably 
only a handful (or possibly none!) of the z/OS services will have been 
enabled/approved for use by such code.


Saving status over an interrupt is indeed a 'big deal', but only the tip of the 
iceberg...


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

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

Re: Ads on IBM-MAIN

[Elardus Engelbrecht]

Gord Tomlin wrote:

>I have already communicated with the owner of the listserv on this matter. 

Excellent! :-)

>Nevertheless, if members of this listserv believe this post to be 
>inappropriate, 
I will not make any similar posts in the future. My intent was to inform, no to 
offend.

You did not offend anyone, or at least me. :-D 
Be a nice sport and please continue with your posts and ads. 

Groete / Greetings
Elardus Engelbrecht

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

Re: Ads on IBM-MAIN

[Pommier, Rex R.]

Gord,

Yours wasn't the post I was referring to.  I was referring to the post from Mr. 
Gould where he was complaining directly to Darren about Shai Hess' posts 
regarding updates to his software.  I saw the "shameless plug" and it didn't 
bother me a bit.  I don't believe your post was inappropriate; as, as you said, 
the OP was looking for information and you responded to his request.

As I said in my earlier post, your "shameless plug" pretty much sailed by me 
without my even taking a second look.  I, along with the vast majority of 
people on the list (both posters and lurkers), had no problem with your post as 
it wasn't an unsolicited advertisement.  To those few who objected to it, build 
a rule in your inbox to delete the messages you don't like, and get over it.  
It was nothing compared to a lot of the noise on the list.

I'll quit ranting now.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gord Tomlin
Sent: Wednesday, July 06, 2011 10:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ads on IBM-MAIN

I suspect that the reference to a post from a software company is
referring to a post I made on Monday on a thread started by Hilary
Hurwitz with the subject "Z/OS Newbie question".

The OP was looking for a facility that would provide "a list of modules
used and which libraries they were taken from". Gerard Postpischil
replied with "The short answer to this is that it's not possible." Since
we have a product feature that provides this very function, I felt that
it was relevant to provide the information, and I marked my post as a
"shameless plug", since I was mentioning a feature of one of our products.

I have already communicated with the owner of the listserv on this
matter. Nevertheless, if members of this listserv believe this post to
be inappropriate, I will not make any similar posts in the future. My
intent was to inform, no to offend.

--

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

On 2011-07-06 10:57, Pommier, Rex R. wrote:
> I'm with you, Mace.  I don't mind Shai's posts.  In fact, when the brown 
> material started coming into contact with the oscillating air movement 
> device, I had to go dig through my deleted messages to figure out what was 
> happening.  I didn't notice the post from the software company, but one of 
> the people complaining about Shai's posts is being caught by an outlook rule 
> I have set up and his messages are trashed.  If he doesn't want to see Shai's 
> posts, maybe he could set up a similar rule.  :-)
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Larry Macioce
> Sent: Wednesday, July 06, 2011 8:17 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Ads on IBM-MAIN
>
> I am more of a question asker or lurker than a contributor, but I am going to
> give my $.02 anyway.
>
> If you look at the op they are from a major software firm, unless it is
> Scandinavian Airlines.
>
> So to me it is a bit of sour grapes. If they felt there was/is a problem they
> should have addressed it with the mod or the offender. Then one other poster
> complained ,couldn't even name the product and Alan gave an opinion.
> For a total of 2 ½ (I'll give Alan an assist...lol)
>
> So the way I see it, is the majority of the posters have no problem with what
> Shai is doing. I have thought of downloading the product and testing it.
>
> This is American society today, a few don't like what the majority
> are doing and complain.
> Let's set up frivolous law suites to stop the majority, or complain so the
> majority must change
>
> Anyway, here is a solution, if you see him posting DON'T OPEN THE TREAD,
> there problem solved.
>
> mace

The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: Ads on IBM-MAIN

[Elardus Engelbrecht]

Pommier, Rex wrote:

>... when the brown material started coming into contact with the oscillating 
air movement device,

Just say 'sh*t hits the fan'... ;-D

No, seriously, I agree 101% with you! 

Groete / Greetings
Elardus Engelbrecht

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

Re: B&T cables

[Scott Rowe]

We have at least one set of B&T cables under our floor in Ohio (Cleveland
area) that will be de-commissioned in early August.  I would have to check,
but we might also have some non-IBM 3270s lying around.

On Fri, Jul 1, 2011 at 3:52 PM, William Donzelli wrote:

> I have a couple of requests for some bus and tag cables - one request
> from the Computer History Museum - as well as a request for some old
> IBM 3270 family terminals (any vintage).
>
> Does anyone know of any in the New York/New England area I could go fetch?
>
> --
> Will
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

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

Re: Ads on IBM-MAIN

[Jerry Whitteridge]

 I agree with Allan (and others). I have seen nothing from Shai that is not 
relevant to this list. And it's way better than pedantic repeats of things that 
have been hashed out many times.

Jerry Whitteridge
Design Engineer
Safeway Inc.
925 951 4184

If you feel in control
you just aren't going fast enough.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Staller, Allan
> Sent: Wednesday, July 06, 2011 5:23 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Ads on IBM-MAIN
> 
> I do not feel that Shai has violated the spirit of this list.  He is
> not
> charging for his product.
> There have been occasional posts from one of the major software
> vendors
> (actually an individual working at that vendor)
> that come far closer to "crossing the line" than Shai. But again,
> they
> were providing information, not soliciting.
> 
> Unlike Ed, I prefer to have information about something that might
> (or
> might not) be of use to me.
> Information is the commodity this list was created to exchange.
> Most of the posts on this list take less than 10 seconds to read
> (including this one).
> 
> I can spare 10 seconds a few times a day to read the posts and
> decide if
> they are of any interest.
> 
> Just my $0.02 USD
> 
> 
> 
> While I am sure its a nice product, a list dedicated to it is
> appropriate.
> 
> Ed
> 
> .Snippage
> 
> 
> > I was going to write you off list but since you brought it up.
> There
> is a on going advertisement on the list here that started as a minor
> annoyance and become a major pita.
> > That is the bandwidth pig on IBM-MAIN of mfnet or what ever it's
> called. IMO it should be moved off to a separate list. The constant
> announcements of features and bugs and trial offers is getting past
> noise and is worth setting up a spam filter for.
> > Could you please consider asking the author to create it's own
> list,
> please? Thanks.
> >
> > Ed
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN
> INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

Re: Lines, Bars and ... mini-bars???

[Elardus Engelbrecht]

Tom Marchant wrote:
>Scott Rowe wrote:
>>If memory is addressable with 31-bits, then it is below the bar, if not, it 
>>is 
above the bar.

>I agree.  I think that "bar" was chosen, not because "a bar has thickness"
but to avoid confusion as to which line was meant when someone said,
"above the line".

I tend to think of the 'bar' as something like a fence or a ceiling. You or 
your 
code/programs is on 'this side' or 'other side' depending on your usage and 
addressing mode/usage.

Actually, I don't like the term 'bar', because the 'bar' has a relation to the 
power of 2. But then I don't have a better word for it to replace that ugly 
word. I indeed saw some good 'suggestions' giving me smiles ... :-D

Groete / Greetings
Elardus Engelbrecht

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

Re: Rexx code to reach an IP

[Paul Gilmartin]

On Wed, 6 Jul 2011 18:21:34 +0300, Itschak Mugzach wrote:

>   1. ftp://ftp.software.ibm.com/s390/zos/vse/download/xmps/vseesoc.pdf
>   2. ITschak
>
... which is VSE-centric.  If the OP wanted from MVS ("mainframe" is
pretty vague), the RXSOCKET functions which originated in VM/CMS
at some time worked on MVS.  Most web references are from the 20th
century.  I don't know whether RXSOCKET/MVS survived the transition
from surrogate IUCV to Unix-based sockets.

For VM/CMS, nowadays there's the eminently usable PIPE TCPCLIENT.
Linux for z?  TPF?  No idea.

>On Wed, Jul 6, 2011 at 6:01 PM, jagadishan perumal wrote:
>>
>> I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
>> mainframe  Are there any sample Rexx that can be used to reach the above IP
>> using TCPIP Socket ?

I find:

http://billlalonde.tripod.com/rexx/urlinfo.txt
http://billlalonde.tripod.com/rexx/sample.htm


http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.hala001/dqx1rexx_socket_sample_programs_r.htm

-- gil

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

Re: Ads on IBM-MAIN

[Binyamin Dissen]

Agree completely - of course, no shills.

On Wed, 6 Jul 2011 11:56:45 -0400 "Veilleux, Jon L" 
wrote:

:>Sooo, if someone not associated with your software company was to say 
'you know this product has a feature that would do that' it would be OK, but 
you cannot say the same thing?
:>Personally, I don't see a problem with you giving that information in 
response to someone's request. 
:>That is not the same as unsolicited advertising, which would be an issue.
:>Jon
:>
:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
Of Gord Tomlin
:>Sent: Wednesday, July 06, 2011 11:49 AM
:>To: IBM-MAIN@bama.ua.edu
:>Subject: Re: Ads on IBM-MAIN
:>
:>I suspect that the reference to a post from a software company is referring 
to a post I made on Monday on a thread started by Hilary Hurwitz with the 
subject "Z/OS Newbie question".
:>
:>The OP was looking for a facility that would provide "a list of modules used 
and which libraries they were taken from". Gerard Postpischil replied with "The 
short answer to this is that it's not possible." Since we have a product 
feature that provides this very function, I felt that it was relevant to 
provide the information, and I marked my post as a "shameless plug", since I 
was mentioning a feature of one of our products.
:>
:>I have already communicated with the owner of the listserv on this matter. 
Nevertheless, if members of this listserv believe this post to be 
inappropriate, I will not make any similar posts in the future. My intent was 
to inform, no to offend.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Ads on IBM-MAIN

[Veilleux, Jon L]

Sooo, if someone not associated with your software company was to say 'you 
know this product has a feature that would do that' it would be OK, but you 
cannot say the same thing?
Personally, I don't see a problem with you giving that information in response 
to someone's request. 
That is not the same as unsolicited advertising, which would be an issue.
Jon

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Gord Tomlin
Sent: Wednesday, July 06, 2011 11:49 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ads on IBM-MAIN

I suspect that the reference to a post from a software company is referring to 
a post I made on Monday on a thread started by Hilary Hurwitz with the subject 
"Z/OS Newbie question".

The OP was looking for a facility that would provide "a list of modules used 
and which libraries they were taken from". Gerard Postpischil replied with "The 
short answer to this is that it's not possible." Since we have a product 
feature that provides this very function, I felt that it was relevant to 
provide the information, and I marked my post as a "shameless plug", since I 
was mentioning a feature of one of our products.

I have already communicated with the owner of the listserv on this matter. 
Nevertheless, if members of this listserv believe this post to be 
inappropriate, I will not make any similar posts in the future. My intent was 
to inform, no to offend.

--

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

On 2011-07-06 10:57, Pommier, Rex R. wrote:
> I'm with you, Mace.  I don't mind Shai's posts.  In fact, when the brown 
> material started coming into contact with the oscillating air movement 
> device, I had to go dig through my deleted messages to figure out what was 
> happening.  I didn't notice the post from the software company, but one of 
> the people complaining about Shai's posts is being caught by an outlook rule 
> I have set up and his messages are trashed.  If he doesn't want to see Shai's 
> posts, maybe he could set up a similar rule.  :-)
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf 
> Of Larry Macioce
> Sent: Wednesday, July 06, 2011 8:17 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Ads on IBM-MAIN
>
> I am more of a question asker or lurker than a contributor, but I am going to
> give my $.02 anyway.
>
> If you look at the op they are from a major software firm, unless it is
> Scandinavian Airlines.
>
> So to me it is a bit of sour grapes. If they felt there was/is a problem they
> should have addressed it with the mod or the offender. Then one other poster
> complained ,couldn't even name the product and Alan gave an opinion.
> For a total of 2 ½ (I'll give Alan an assist...lol)
>
> So the way I see it, is the majority of the posters have no problem with what
> Shai is doing. I have thought of downloading the product and testing it.
>
> This is American society today, a few don't like what the majority
> are doing and complain.
> Let's set up frivolous law suites to stop the majority, or complain so the
> majority must change
>
> Anyway, here is a solution, if you see him posting DON'T OPEN THE TREAD,
> there problem solved.
>
> mace
>
>
> The information contained in this e-mail may contain confidential and/or 
> privileged information and is intended for the sole use of the intended 
> recipient. If you are not the intended recipient, you are hereby notified 
> that any unauthorized use, disclosure, distribution or copying of this 
> communication is strictly prohibited and that you will be held responsible 
> for any such unauthorized activity, including liability for any resulting 
> damages. As appropriate, such incident(s) may also be reported to law 
> enforcement. If you received this e-mail in error, please reply to sender and 
> destroy or delete the message and any attachments. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>

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

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

Re: Ads on IBM-MAIN

[Gord Tomlin]

I suspect that the reference to a post from a software company is 
referring to a post I made on Monday on a thread started by Hilary 
Hurwitz with the subject "Z/OS Newbie question".


The OP was looking for a facility that would provide "a list of modules 
used and which libraries they were taken from". Gerard Postpischil 
replied with "The short answer to this is that it's not possible." Since 
we have a product feature that provides this very function, I felt that 
it was relevant to provide the information, and I marked my post as a 
"shameless plug", since I was mentioning a feature of one of our products.


I have already communicated with the owner of the listserv on this 
matter. Nevertheless, if members of this listserv believe this post to 
be inappropriate, I will not make any similar posts in the future. My 
intent was to inform, no to offend.


--

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

On 2011-07-06 10:57, Pommier, Rex R. wrote:

I'm with you, Mace.  I don't mind Shai's posts.  In fact, when the brown 
material started coming into contact with the oscillating air movement device, 
I had to go dig through my deleted messages to figure out what was happening.  
I didn't notice the post from the software company, but one of the people 
complaining about Shai's posts is being caught by an outlook rule I have set up 
and his messages are trashed.  If he doesn't want to see Shai's posts, maybe he 
could set up a similar rule.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Larry Macioce
Sent: Wednesday, July 06, 2011 8:17 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ads on IBM-MAIN

I am more of a question asker or lurker than a contributor, but I am going to
give my $.02 anyway.

If you look at the op they are from a major software firm, unless it is
Scandinavian Airlines.

So to me it is a bit of sour grapes. If they felt there was/is a problem they
should have addressed it with the mod or the offender. Then one other poster
complained ,couldn't even name the product and Alan gave an opinion.
For a total of 2 ½ (I'll give Alan an assist...lol)

So the way I see it, is the majority of the posters have no problem with what
Shai is doing. I have thought of downloading the product and testing it.

This is American society today, a few don't like what the majority
are doing and complain.
Let's set up frivolous law suites to stop the majority, or complain so the
majority must change

Anyway, here is a solution, if you see him posting DON'T OPEN THE TREAD,
there problem solved.

mace


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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




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

Re: Web version of mainframes

[Hal Merritt]

Your question is a little confusing. Actually, there seem to be two separate 
questions. 

Question one: can the MF be a web server? Answer: yes. But you need the 
applications. 

Question two: can my user access the MF from a wireless Internet connection? 
Answer: yes. Actually, this is a networking/firewall issue and has little to do 
with the MF. 

HTH and good luck. 

 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
jagadishan perumal
Sent: Wednesday, July 06, 2011 12:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Web version of mainframes

Hi Group,

Just wanted to know whether a web version of mainframe can be implemented.
One of our user is trying to access from a remote location using a wireless 
internet in which the IP changes everytime.

Regards,
Jags

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at 
http://bama.ua.edu/archives/ibm-main.html
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.

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

Re: Rexx code to reach an IP

[Lizette Koehler]

Jags,

This probably would be better on the TSO-REXX newsgroup.  They are specific to 
everything REXX.

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


Lizette



-Original Message-
>From: jagadishan perumal 
>Sent: Jul 6, 2011 11:01 AM
>To: IBM-MAIN@bama.ua.edu
>Subject: Rexx code to reach an IP
>
>Hi Group,
>
>I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
>mainframe  Are there any sample Rexx that can be used to reach the above IP
>using TCPIP Socket ?
>
>Regards,
>Jags
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html

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

Re: Rexx code to reach an IP

[Itschak Mugzach]

   1. ftp://ftp.software.ibm.com/s390/zos/vse/download/xmps/vseesoc.pdf
   2. ITschak


On Wed, Jul 6, 2011 at 6:01 PM, jagadishan perumal wrote:

> Hi Group,
>
> I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
> mainframe  Are there any sample Rexx that can be used to reach the above IP
> using TCPIP Socket ?
>
> Regards,
> Jags
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

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

Re: Lines, Bars and ... mini-bars???

[Tom Marchant]

On Wed, 6 Jul 2011 10:32:57 -0400, Scott Rowe wrote:

>If memory is addressable with 31-bits, then it is
>below the bar, if not, it is above the bar.

I agree.  I think that "bar" was chosen, not because "a bar has thickness" 
but to avoid confusion as to which line was meant when someone said, 
"above the line".

Alas, it seems to have caused another kind of confusion.

-- 
Tom Marchant

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

Rexx code to reach an IP

[jagadishan perumal]

Hi Group,

I am trying to reach a URL :http://xxx.41.xxx.x:8080/MF/services  from
mainframe  Are there any sample Rexx that can be used to reach the above IP
using TCPIP Socket ?

Regards,
Jags

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

Re: Ads on IBM-MAIN

[Pommier, Rex R.]

I'm with you, Mace.  I don't mind Shai's posts.  In fact, when the brown 
material started coming into contact with the oscillating air movement device, 
I had to go dig through my deleted messages to figure out what was happening.  
I didn't notice the post from the software company, but one of the people 
complaining about Shai's posts is being caught by an outlook rule I have set up 
and his messages are trashed.  If he doesn't want to see Shai's posts, maybe he 
could set up a similar rule.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Larry Macioce
Sent: Wednesday, July 06, 2011 8:17 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Ads on IBM-MAIN

I am more of a question asker or lurker than a contributor, but I am going to
give my $.02 anyway.

If you look at the op they are from a major software firm, unless it is
Scandinavian Airlines.

So to me it is a bit of sour grapes. If they felt there was/is a problem they
should have addressed it with the mod or the offender. Then one other poster
complained ,couldn't even name the product and Alan gave an opinion.
For a total of 2 ½ (I'll give Alan an assist...lol)

So the way I see it, is the majority of the posters have no problem with what
Shai is doing. I have thought of downloading the product and testing it.

This is American society today, a few don't like what the majority
are doing and complain.
Let's set up frivolous law suites to stop the majority, or complain so the
majority must change

Anyway, here is a solution, if you see him posting DON'T OPEN THE TREAD,
there problem solved.

mace


The information contained in this e-mail may contain confidential and/or 
privileged information and is intended for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any unauthorized use, disclosure, distribution or copying of this communication 
is strictly prohibited and that you will be held responsible for any such 
unauthorized activity, including liability for any resulting damages. As 
appropriate, such incident(s) may also be reported to law enforcement. If you 
received this e-mail in error, please reply to sender and destroy or delete the 
message and any attachments. Thank you.

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

Re: IEBCOPY in z/OS R13 (was (re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???))

[Walt Farrell]

On Tue, 5 Jul 2011 19:15:45 -0500, Paul Gilmartin  wrote:

># Enhancements are planned for the IEBCOPY utility that are intended
>  to improve performance when copying a partitioned data set (PDS)
>  to another PDS. In addition, IEBCOPY is planned to exploit 31-bit
>  storage for track buffers, and the current requirement for APF
>  authorization is planned to be removed in z/OS V1.13.
>
>Wow!  Then I could run SMP/E also without APF authorization,
>provided I avoid using the WAIT option on DDDEFS.  Could this
>result in a relaxation of the constraints introduced by the
>notorious APAR IO11698?  I insist on my view that if a program
>operating without APF authorization can leverage an integrity
>exposure, the OS itself needs repair; it is insufficient to
>repair that program or restrict access to it.

You don't need to "insist on (your) view", gil. That's the basic idea of our
z/OS Integrity Statement. Unauthorized programs must not be able to
compromise the system in contravention of the security and integrity
controls the system implements. (That's just my unofficial rephrasing, for
the purpose of this discussion, by the way, and not an official IBM
statement of our policy.)

The issue with SMP/E that resulted in that APAR is different, though, as
SMP/E -does- operate with APF authorization, and therefore applying some
restrictions (such as over who can run it) is an appropriate control
mechanism, but it's not the situation you mention above (restricting who can
run an unauthorized program).

Additionally I'll note that we do allow unauthorized programs to perform
sensitive operations under the control of a RACF authorization check. While
one might view that as a form of restricting access to the program, it's
really a control implemented at a lower level, within the system itself. And
so we view that as an appropriate control mechanism. 

One example (among many) is that an unauthorized programs with authority to
an appropriate CSVAPF-prefixed resource in the FACILITY class can make
changes to the system APF configuration. But if you don't allow it via that
FACILITY check, the action is not allowed unless the program runs authorized. 

If an unauthorized program were able to take that action, without having the
appropriate RACF authority, then yes, I would agree that the OS is broken
and needs a fix, and that asking you to restrict access to the program
itself (e.g., via RACF PROGRAM control, or restricting access to the load
library) would not be appropriate.

By the way, I have no idea if or when we might plan to change SMP/E so it
runs unauthorized, but I consider the change to IEBCOPY to be one step in
the right direction that might help allow that change one day. I also have
no idea what it would mean for the authorization checks that SMP/E APAR
introduced, but that's clearly something for us to consider someday, too.

-- 
Walt Farrell
IBM STSM, z/OS Security Design

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

Re: Lines, Bars and ... mini-bars???

[Scott Rowe]

Until this thread started, I had never even considered the idea that the bar
had any "thickness".  If memory is addressable with 31-bits, then it is
below the bar, if not, it is above the bar.  While I find this discussion
interesting, I have not seen any argument that would cause me to change my
view.

On Wed, Jul 6, 2011 at 10:24 AM, Walt Farrell  wrote:

> On Wed, 6 Jul 2011 13:34:28 +, Bill Fairchild 
> wrote:
>
> >A few days ago I composed and sent a post in which I believed that the bar
> was the 2GB line because I had just seen a comment statement inside the
> IARV64 macro that stated that as a fact.  Today I reviewed an IBM SHARE
> presentation in which the word "bar" was attached to a very wide arrow
> pointing at the middle of the 2GB area in between virtual addresses 2GB and
> 4GB.  So I must conclude that the technical term "bar" officially means
> whatever IBM wants it to mean today, where the meaning of "today" changes
> from day to day.  This situation is very much like that of another
> controversial term which once meant the U.S. Steel Corporation (inter
> alia).
> >
>
> I'm not sure which presentation you looked at, Bill, but Elpida's
> presentation (mentioned yesterday in this thread) clearly shows the bar as
> being the 2G line (chart on page 48).
>
> And to me, nothing else makes much sense today.
>
> Yes, originally we had a 2GiB dead space between 2**31 and (2**32)-1, but
> we
> no longer have that.
>
> Instead, we revised it that so that a 32GiB area starting at 2**31 was
> reserved for use by Java.
>
> And then we further revised that so there's an additional 256GiB above that
> reserved for system usage.
>
> "Above the bar" is perhaps still a useful term, but the real question is
> whether one is dealing with 31- or 64-bit addresses, and one might speak in
> those terms instead. The exact location of the storage should have little
> or
> no relevance to most programs and programmers, but I suppose one might
> argue
> that for normal programs, the "bar" now has a thickness of 288 GiB rather
> than the old thickness of 2GiB. (I would not make that argument, however; I
> would say the bar has no thickness.)
>
> --
> Walt
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains
confidential and privileged information intended only for the addressee.
If you are not the intended recipient, please be advised that you have
received this material in error and that any forwarding, copying, printing,
distribution, use or disclosure of the material is strictly prohibited.
If you have received this material in error, please (i) do not read it,
(ii) reply to the sender that you received the message in error, and
(iii) erase or destroy the material. Emails are not secure and can be
intercepted, amended, lost or destroyed, or contain viruses. You are deemed
to have accepted these risks if you communicate with us by email. Thank you.

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

Re: z/OS 1.13 preview (was: Lines, Bars and ... mini-bars???)

[Tom Marchant]

On Tue, 5 Jul 2011 19:15:45 -0500, Paul Gilmartin wrote:

>What's the rationale for bit 12?  It must be 0 for LPSWE and 1
>for LPSW, but in either case a 0 is loaded into the PSW.

In the System/360, bit 12 was the USASCII bit.  It controlled the operation 
of only a few instructions.  UNPK was one.

System/370 removed the USASCII support and bit 12 was required to be 0.

Later, when virtual addressing was added, a 1 in bit 12 signified 
Extended-Control mode.  This enabled Dynamic Address Translation and 
changed the format of the PSW.

Some time later, Basic-Control mode was removed and bit 12 was required 
to be set to 1.

z/Architecture introduced a 128-bit PSW and in z/Architecture mode, 
bit 12 in the PSW must be 0.  LPSW inverts the value in bit 12 and 
LPSWE leaves it alone.  Perhaps st some time in the future, IBM will 
define something new in the architecture that requires another change 
in the PSW and bit 12 will be used to signify the change.  Then again, 
maybe not.

In any case, when looking at a dump in storage, bit 12 tells whether it is
a 64-bit or a 128-bit PSW.

>But none of this would seem to support forming a 64-bit PSW
>when "an interrupt [occurs] while executing above the bar.

When an interrupt occurs, the 128-bit PSW is stored.  In order to be able 
to run interruptable work above the bar, the 128-bit PSW must be preserved 
and used to dispatch the program again.  AFAIK, IBM has not said how they 
will do that.

-- 
Tom Marchant

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

Re: Lines, Bars and ... mini-bars???

[Walt Farrell]

On Wed, 6 Jul 2011 13:34:28 +, Bill Fairchild  wrote:

>A few days ago I composed and sent a post in which I believed that the bar
was the 2GB line because I had just seen a comment statement inside the
IARV64 macro that stated that as a fact.  Today I reviewed an IBM SHARE
presentation in which the word "bar" was attached to a very wide arrow
pointing at the middle of the 2GB area in between virtual addresses 2GB and
4GB.  So I must conclude that the technical term "bar" officially means
whatever IBM wants it to mean today, where the meaning of "today" changes
from day to day.  This situation is very much like that of another
controversial term which once meant the U.S. Steel Corporation (inter alia).
>

I'm not sure which presentation you looked at, Bill, but Elpida's
presentation (mentioned yesterday in this thread) clearly shows the bar as
being the 2G line (chart on page 48).

And to me, nothing else makes much sense today. 

Yes, originally we had a 2GiB dead space between 2**31 and (2**32)-1, but we
no longer have that.

Instead, we revised it that so that a 32GiB area starting at 2**31 was
reserved for use by Java.

And then we further revised that so there's an additional 256GiB above that
reserved for system usage.

"Above the bar" is perhaps still a useful term, but the real question is
whether one is dealing with 31- or 64-bit addresses, and one might speak in
those terms instead. The exact location of the storage should have little or
no relevance to most programs and programmers, but I suppose one might argue
that for normal programs, the "bar" now has a thickness of 288 GiB rather
than the old thickness of 2GiB. (I would not make that argument, however; I
would say the bar has no thickness.)

-- 
Walt

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

Re: Lines, Bars and ... mini-bars???

[John P Kalinich]

Bill Fairchild  of the IBM Mainframe Discussion List
 wrote on 07/06/2011 08:34:28 AM:

> And just why do we use the word "grande" to describe machine
> instructions that operate on 64-bit addresses and which have the
> letter "G" somewhere in the op code?  When did IBM make that
> official?  Why not "gargantuan" or "ginormous"?  lol

I first heard the term "grande" used by Bob Rogers in his "What You Do When
You're a CPU" SHARE presentation (2004).

Regards,
John K

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

Re: Z/OS Maintenance

[Shane Ginnane]

H - well, I did finally see some hardware fail.
C'mon software vendors, your turn to step up to the plate ...

Shane ...
(I deleted all addresses as otherwise some may see it as disingenuous - gawd
knows how)

> >There's that old saw about not fixing something that ain't broke.
> 
> And the one that states:  Hardware will eventually fail.  Software will 
> eventually work.

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

Re: Z/OS Maintenance

[Art Gutowski]

On Tue, 5 Jul 2011 12:36:17 -0700, Skip Robinson 
 wrote:

>There's that old saw about not fixing something that ain't broke. My
>response is that it's *always* broke. You may or may not personally
>encounter the problem, but every corrective APAR tells a tale of woe for
>some poor soul somewhere.

And the one that states:  Hardware will eventually fail.  Software will 
eventually work.

Art Gutowski
Compuware Corporation

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

Re: Lines, Bars and ... mini-bars???

[Binyamin Dissen]

On Wed, 6 Jul 2011 13:34:28 + Bill Fairchild  wrote:

:>And just why do we use the word "grande" to describe machine instructions 
that operate on 64-bit addresses and which have the letter "G" somewhere in the 
op code?  When did IBM make that official?  Why not "gargantuan" or 
"ginormous"?  lol

G operates on 64bit DATA. Pretty much all instructions operate on 64 bit
addresses.

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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