Re: Abend S602-0 when in AMODE 64

[Robert A. Rosenberg]

At 22:05 +0200 on 01/14/2015, Binyamin Dissen wrote about Re: Abend 
S602-0 when in AMODE 64:



On Wed, 14 Jan 2015 14:41:46 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on
:>01/14/2015
:>   at 08:00 AM, Donald Likens  said:

:>>AMODE 64 routines should be using relative branch and generally
:>>should  establish addressability to a static data area

:>What if the code is shared? That goes against decades of coding to be
:>reentrant and refreshable.

What issues do you perceive sharing a STATIC data area?


The issue is with a Writable not a Read-Only area. The Static area 
would need to be acquired separately with each invocation and thus 
would need to be accessed via a register not by relative addressing. 
Otherwise different address spaces would overlay each other's data.




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

Director, Dissen Software, Bar & Grill - Israel



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

IBM Launches the z13 Mainframe

[Timothy Sipples]

If you'd like some introductory information on the Vector Facility for
z/Architecture (SIMD) capabilities, this paper should help:

http://www.redbooks.ibm.com/technotes/tips1259.pdf

Yes, Mathematical Acceleration Subsystem (MASS), Basic Linear Algebra
Subprograms (BLAS), and Automatically Tuned Linear Algebra Software (ATLAS)
are among the functions arriving on z/OS and on Linux on z Systems that
exploit SIMD. Yet another piece of fantastic news.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM Launches the z13 Mainframe

[Timothy Sipples]

John McKown writes:
>This might help people to convert to z/OS. Of
>course, there is still that nasty EBCDIC
>issue for any conversion.​

That's just not correct.

z/OS imposes absolutely no requirement to use or to convert to EBCDIC.
Zero, zip, nada. Store and manage everything in Unicode if you like. (Many
do and do like.) Or Plutocode, or McKowncode. Choose whatever character
encoding you like.

Interoperating with EBCDIC-encoded data requires, well, interoperating with
EBCDIC-encoded data, whether z/OS or another operating system manages and
stores such data. z/OS provides excellent interoperation capabilities
should you wish to use them. But such interoperation requirements exist, if
they exist, no matter where you run.


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

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

Re: SMP/E version in z/OS 1.4

[Linda]

Hi Mark,

I successfully installed SMP/e at 3.5 on a z/OS 1.4 system. Worked fine, 
including the FIXCATs. After installing SMP/e at a higher level than your zones 
were. Built with, you need to issue the upgrade command for each global. 
Instructions included with the installation doc. 

HTH,

Linda 

Sent from my iPhone

> On Jan 14, 2015, at 7:21 AM, Mark Pace  wrote:
> 
> I need to have the 1.4 as a target.  But they are having issues with the
> change to the FIXCAT ++HOLD.
> 
> So I was trying to find a PTF for APAR IO7480 for their version of SMP/E.
> 566894901 D00.  It appears to me that their version did not get get the
> remedial service.
> 
> On Wed, Jan 14, 2015 at 10:13 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
> 
>> Mark Pace wrote:
>> 
>>> Can someone tell me what version of SMP/E was included in z/OS 1.4?
>> 3.3 or 3.4, possibly earlier version?
>> 
>> Probably 3.1.x or 3.2.x. I said probably, because my documentation +
>> copies are deleted by this time.
>> 
>> 
>>> No amount of googling has provided the answer for me.
>> 
>> Surprise, IBM and Google don't help me. 
>> 
>> I searched again. I tried Lifecycle pages of IBM to see if I got anything.
>> 
>> ( http://www-01.ibm.com/software/support/systemsz/lifecycle/ )
>> 
>> Perhaps below can give you a guide or estimate?
>> 
>> z/OS v1.4.x was GA around Sept 2002. SMP/E 3.1 was GA around Oct 2001 and
>> SMP/E 3.2 around May 2003.
>> SMP/E 3.3 is GA Sep 2004, just after EOM of z/OS 1.4.
>> 
>> It thus depends. Do you require z/OS 1.4 to be driving or target system?
>> 
>> Just don't take my words for granted...
>> 
>> Groete / Greetings
>> Elardus Engelbrecht
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> -- 
> The postings on this site are my own and don’t necessarily represent
> Mainline’s positions or opinions
> 
> Mark D Pace
> Senior Systems Engineer
> Mainline Information Systems
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Compile COBOL Programs In 64 Bit.

[Ed Gould]

--- 
SNIP--
Can't those arguments, both for and against, be applied to any  
language you
name?  Taken together, there were never "use cases and verifiable  
needs"
for 64-bit hardware in the first place.  In fact, it's hard to  
present "use cases"

for a product that doesn't yet exist.

-- gil



Gil:
True but there have been QUITE a few user programs that have been  
written to access 31 bit data (before it was available) I suspect 64  
bit is not too far behind as the users are few (?) that need 64  
bit (currently). I can see (in the shop where I consult) that in a  
few years, 64 bit access will be needed. The need to write ASM  
programs to access 64 bit will never materialize as the ASM  
programmers are a retiring and will not be around to do so. I suspect  
that some consulting company will come up with a way before IBM ever  
does and will make a small mint off of it.


Ed


Ed

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

Re: Abend S602-0 when in AMODE 64

[Shmuel Metz (Seymour J.)]

In <5vidba1s00e932fiphts1nu0tijahcu...@4ax.com>, on 01/14/2015
   at 10:05 PM, Binyamin Dissen  said:

>What issues do you perceive sharing a STATIC data area?

One task overwritinf data used by another task.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Compile COBOL Programs In 64 Bit.

[Shane Ginnane]

On Wed, 14 Jan 2015 19:27:54 -0600, Paul Gilmartin wrote:

>Can't those arguments, both for and against, be applied to any language you
>name?  Taken together, there were never "use cases and verifiable needs"
>for 64-bit hardware in the first place.

Doesn't stop people asking for it.
Over a year ago I was queried about 64-bit Cobol. This was for statically 
linked CICS - as in *everything* linked into one module.
And it was running out of region ... So 64-bit Cobol was going to solve 
everything.

Don't fix the inherent problem(s), chase the symptom - how common is that ?.

Shane ...

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

Re: Compile COBOL Programs In 64 Bit.

[Charles Mills]

> AMODE 64 code will run slower than AMODE 31 code

Really? Because the compile will generate extra instructions or similar, or
inherently because of the hardware architecture?

I thought there was some discussion here recently that dismissed the latter
(other than a trivial factor).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tom Ross
Sent: Wednesday, January 14, 2015 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Compile COBOL Programs In 64 Bit.

>Hi,I am looking for COBOL compiler option to compile our COBOL programs 
>in =
>64 Bit mode.Please lead me if you have such a experience .The COBOL 
>version=  is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi

AMODE 64 COBOL is still being worked on here at IBM.

I (like the other poster) would like to know what you would do with AMODE 64
COBOL?
Also, does everyone realize that AMODE 64 code will run slower than AMODE 31
code?
We assume that AMODE 64 COBOL will be used for very specialized one-off
cases to solve specific business problems, and that in general 99% of code
will be compiled for 

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

Re: Compile COBOL Programs In 64 Bit.

[Paul Gilmartin]

On Wed, 14 Jan 2015 16:51:52 -0800, Tom Ross wrote:

>>Hi,I am looking for COBOL compiler option to compile our COBOL programs in =
>>64 Bit mode.Please lead me if you have such a experience .The COBOL version=
>> is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi
>
>AMODE 64 COBOL is still being worked on here at IBM.
>
>I (like the other poster) would like to know what you would do with AMODE 64 
>COBOL?
>Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
>code?
>We assume that AMODE 64 COBOL will be used for very specialized one-off cases
>to solve specific business problems, and that in general 99% of code will be
>compiled for AMODE 31 even after we ship AMODE 64 COBOL.
>
>  Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we
>do not think very many users will need AMODE 64 in the next 10-15 years.
>We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if
>you know of any, please SHARE!  (get it? :-)
> 
Can't those arguments, both for and against, be applied to any language you
name?  Taken together, there were never "use cases and verifiable needs"
for 64-bit hardware in the first place.  In fact, it's hard to present "use 
cases"
for a product that doesn't yet exist.

-- gil

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

Re: IKJ56220I max # of datasets reached

[Gibney, Dave]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Wednesday, January 14, 2015 5:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IKJ56220I max # of datasets reached
> 
> On Wed, 14 Jan 2015 18:30:16 -0500, Tony Harminc wrote:
> 
> >On 14 January 2015 at 17:18, Paul Gilmartin wrote:
> >>
> >> >DYNAMNBR= on the EXEC card.
> >> >ref:
> >> >https://urldefense.proofpoint.com/v1/url?u=http://publibz.boulder.ib
> >> >m.com/cgi-
> bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6&k=EWEYHnIvm0nsSxnW5y
> >>
> >9VIw%3D%3D%0A&r=j6Xa1Y0fbuP2mfgCQ5Zxhg%3D%3D%0A&m=x%2B2l5U
> mcDlooWOnt
> >>
> >i2bv3QHlGhHpvdYhkDdSoLt9DiA%3D%0A&s=e5a1ec5728ce245451ef986024
> 0cbe77
> >> >7ba47a0821a69430a6706c9eaed28fd1
> >> >
> >> Why is there even such a parameter?
> >>
> >> Why is its default not "infinity"?
> >
> (Of course, for interactive TSO it's probably hard-coded in the logon JCL,
> which the user is not allowed to change.  IKJEFT01 opened that door wide.)
> 
> >It used to be worse: in MVT TSO you had to specify a
> >
> >//somename DD DYNAM
> >
> Did the names have to be different?


Never used this, before my time :)
Could it be a concatenation :)
> 
> >for each potential concurrent allocation. I wonder if that's still 
> >supported...
> >
> It is, "for compatibility".
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Dataset PACK profile

[Paul Gilmartin]

On Wed, 14 Jan 2015 18:33:11 -0600, Dan wrote:

>I have a strange memory of a previous thread about ISPF PACKing (probably pre 
>1995).
>
>I seem to recall someone from IBM (in the ISPF area) posting a query about the 
>use of the ISPF PACK option.  I believe they were hoping to remove the 
>function.
>I've searched the archives but can't seem to find anything.
>My recollection of the thread was that IBM wanted to remove the capability of 
>turning ON packing but any member that was already packed would remain packed 
>(unless the user requested PACK OFF).  As PACK is still an option that can be 
>enabled someone must have made a strong enough argument to keep the function 
>(although I don't see why).
>
>Does anyone else recall that discussion or was I dreaming? :D
>If you do recall it, why was it not crippled?
>
z/OS 2.2 will give a site more latitude to turn it off.

-- gil

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 18:30:16 -0500, Tony Harminc wrote:

>On 14 January 2015 at 17:18, Paul Gilmartin wrote:
>>
>> >DYNAMNBR= on the EXEC card.
>> >ref:
>> >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6
>> >
>> Why is there even such a parameter?
>>
>> Why is its default not "infinity"?
> 
(Of course, for interactive TSO it's probably hard-coded in the
logon JCL, which the user is not allowed to change.  IKJEFT01
opened that door wide.)

>It used to be worse: in MVT TSO you had to specify a
>
>//somename DD DYNAM
> 
Did the names have to be different?

>for each potential concurrent allocation. I wonder if that's still supported...
> 
It is, "for compatibility".

-- gil

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

Compile COBOL Programs In 64 Bit.

[Tom Ross]

>Hi,I am looking for COBOL compiler option to compile our COBOL programs in =
>64 Bit mode.Please lead me if you have such a experience .The COBOL version=
> is 4.2 on Z9 with z/OS 1.12. Best regardsManshadi

AMODE 64 COBOL is still being worked on here at IBM.

I (like the other poster) would like to know what you would do with AMODE 64 
COBOL?
Also, does everyone realize that AMODE 64 code will run slower than AMODE 31 
code?
We assume that AMODE 64 COBOL will be used for very specialized one-off cases
to solve specific business problems, and that in general 99% of code will be
compiled for AMODE 31 even after we ship AMODE 64 COBOL.

  Unlike AMODE 31, which we expected EVERYONE to move to (still waiting :-) we
do not think very many users will need AMODE 64 in the next 10-15 years.
We are gathering use cases and verifiable needs for AMODE 64 COBOL, so if
you know of any, please SHARE!  (get it? :-)


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

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

Binder DASD SIZE (and DWARF)

[Tom Ross]

>We've installed Enterprise COBOL 5 in z/OS 2.1 and I'm experimenting with=20
>the NOTEST(DWARF) COBOL option.

>When I Bind the program, I see, for example:

>MODULE SIZE (HEX) 00072C24=20
>DASD SIZE   (HEX) 0014A000=20

>And I have no idea what that means.=20

>Has anyone been down this path?  Any ideas?

Well, I am the one in IBM who did the DWARF data in NOLOAD class segments for
COBOL V5, but I am not an expert in BINDER output.  I can guess that the
BINDER is reporting the executable size (the part that gets loaded when you
run) as MODULE SIZE, and the DASD size is the size of the Program Object
on disk, which includes the NOLOAD class segments of the PO that contain
the DWARF debugging data.  That data only gets loaded when someone calls
binder APIs to request that the NOLOAD segments be loaded, like, for
examples, a Debugger or CEEDUMP local variable formatting.

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

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

Re: Dataset PACK profile

[Dan]

I have a strange memory of a previous thread about ISPF PACKing (probably pre 
1995).

I seem to recall someone from IBM (in the ISPF area) posting a query about the 
use of the ISPF PACK option.  I believe they were hoping to remove the function.
I've searched the archives but can't seem to find anything.
My recollection of the thread was that IBM wanted to remove the capability of 
turning ON packing but any member that was already packed would remain packed 
(unless the user requested PACK OFF).  As PACK is still an option that can be 
enabled someone must have made a strong enough argument to keep the function 
(although I don't see why).

Does anyone else recall that discussion or was I dreaming? :D
If you do recall it, why was it not crippled?

Thanks,
Dan D.

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

Re: IKJ56220I max # of datasets reached

[Tony Harminc]

On 14 January 2015 at 17:18, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> >DYNAMNBR= on the EXEC card.
> >ref:
> >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6
> >
> Why is there even such a parameter?
>
> Why is its default not "infinity"?

It used to be worse: in MVT TSO you had to specify a

//somename DD DYNAM

for each potential concurrent allocation. I wonder if that's still supported...

Tony H.

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

Re: IBM United States Announcement Letters

[Shane Ginnane]

On Wed, 14 Jan 2015 20:37:41 +, Bob Shannon  
wrote:

>SMT is only implemented on zIFL and zIIP specialty engines. I expect it will 
>be extended to CPs once IBM gains experience .

I wonder if it messes with the z/OS IPL code running in single CPU mode. We'll 
probably never know.
Linux dealt with this years ago, but there were occasions where SMT had to be 
disabled in the (x86) BIOS prior to boot.

Shane ...

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 17:31:04 -0500, Mark Jacobs - Listserv wrote:

>My first guess is that it's related to system resources needed to
>support dynamic allocation in a 24-bit address space of the time.
> 
What century is this?

Is there a way for administrators to further restrict troublesome users
who would reflexively set DYNAMNBR to the max value?

If Rexx under z/OS UNIX invokes its idiosyncratic "address TSO", is
there a way to specify DYNAMNBR?


On Wed, 14 Jan 2015 17:29:25 -0500, michelbutz  wrote:

>Thanks I thought DYNAMBR was for IKJEFT01
>
Isn't that the same thing?

But, ISTR reading long ago that DYNAMNBR is policed by the TSO ALLOCATE
command and that BPXWDYN is exempt from the limit.

-- gil

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

Re: Changes with z/OS V2.1 and RMF with zFS file system activity collection

[Paul Gilmartin]

On Wed, 14 Jan 2015 15:24:49 -0700, Lizette Koehler wrote:

>Just in case a few have not seen this, RMF monitor at z/OS V2.1 will not 
>collect for zFS if it is not specified.
>
>Monitor the zFS file system activity
>Description: The Monitor III data gatherer options that control the data 
>collection for measuring zFS file system activity are ZFS and NOZFS. Before 
>z/OS V2R1, this data was gathered by default with the RMF Monitor III parmlib 
>option ZFS as set in ERBRMF04. Starting with z/OS V2R1, the default is NOZFS, 
>and RMF does not automatically gather any data about zFS file system activity.
> 
Is there a similar option controlling data gathering for HFS, or is HFS deemed
too dead to bury?

-- gil

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

Re: IKJ56220I max # of datasets reached

[Mark Jacobs - Listserv]

My first guess is that it's related to system resources needed to 
support dynamic allocation in a 24-bit address space of the time.


Mark Jacobs

Paul Gilmartin wrote:
My first guess is that it's related to system resources needed to 
support dynamic allocation in a 24-bit address space of the time.


Mark Jacobs 


--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

Re: IKJ56220I max # of datasets reached

[michelbutz]

Thanks I thought DYNAMBR was for IKJEFT01

Thanks

Sent from my iPhone

> On Jan 14, 2015, at 5:18 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Wed, 14 Jan 2015 16:14:44 -0600, John McKown wrote:
>> 
>> DYNAMNBR= on the EXEC card.
>> ref:
>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6
> Why is there even such a parameter?
> 
> Why is its default not "infinity"?
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Changes with z/OS V2.1 and RMF with zFS file system activity collection

[Lizette Koehler]

Just in case a few have not seen this, RMF monitor at z/OS V2.1 will not 
collect for zFS if it is not specified.

Monitor the zFS file system activity
Description: The Monitor III data gatherer options that control the data 
collection for measuring zFS file system activity are ZFS and NOZFS. Before 
z/OS V2R1, this data was gathered by default with the RMF Monitor III parmlib 
option ZFS as set in ERBRMF04. Starting with z/OS V2R1, the default is NOZFS, 
and RMF does not automatically gather any data about zFS file system activity.


Lizette

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

Re: IKJ56220I max # of datasets reached

[Paul Gilmartin]

On Wed, 14 Jan 2015 16:14:44 -0600, John McKown wrote:

>DYNAMNBR= on the EXEC card.
>ref:
>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6
> 
Why is there even such a parameter?

Why is its default not "infinity"?

-- gil

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

Re: IKJ56220I max # of datasets reached

[John McKown]

DYNAMNBR= on the EXEC card.
ref:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2b6a0/16.6


On Wed, Jan 14, 2015 at 4:11 PM, michelbutz  wrote:

> Hi
>
> Would anyone know if there is a way to increase the number of datasets
> dynamically allocated using
> IKJTSOEV/IKJEFTSR to execute a clist
>
> Sent from my iPhone
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

IKJ56220I max # of datasets reached

[michelbutz]

Hi

Would anyone know if there is a way to increase the number of datasets 
dynamically allocated using
IKJTSOEV/IKJEFTSR to execute a clist

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

Re: Abend S602-0 when in AMODE 64

[Robert A. Rosenberg]

At 09:11 -0600 on 01/14/2015, Tom Marchant wrote about Re: Abend 
S602-0 when in AMODE 64:



14 Return address. Bit 0 is 0 if the subtask routine gets control in 24-bit
addressing mode; bit 0 is 1 if the subtask routine gets control in 31-bit
addressing mode. 

15 When the subtask routine is to run in 24-bit or 31-bit addressing 
mode, the entry point address of the subtask routine.  When the 
subtask routine is to run in 64-bit addressing mode, it is expected 
to use relative branching and register 15 contains a value that can 
be used to determine the addressing mode of the issuer of the ATTACH 
or ATTACHX macro as follows:


Issuer AMODE 24: X'F000'
Issuer AMODE 31: X'F002'
Issuer AMODE 64: X'F004'


I assume that there is a special method of returning to a AMODE 64 
caller since there is no mention in the R14 description. I have a 
vague impression that the low bit of the return address being 1 (as 
opposed to 0) indicates a return in AMODE 64.


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

Re: IBM United States Announcement Letters

[Mike Schwab]

On Wed, Jan 14, 2015 at 2:37 PM, Bob Shannon
 wrote:
>> With SMT (Hyperthreading) the logical number of cores is double the physical 
>> cores.
>>(So it looks like any individual task that is CPU bound and limited to one 
>>core will take twice as long.)
>
> SMT is only implemented on zIFL and zIIP specialty engines. I expect it will 
> be extended to CPs once IBM gains experience .
>
> Bob Shannon
> Rocket Software

z/OS V2.2 (5650-ZOS) is planned to support the operation of zIIP
processors in simultaneous multithreading (SMT) mode, with two threads
per processor. This new function is designed to help improve
throughput for zIIP workloads and provide appropriate performance
measurement, capacity planning, and SMF accounting data. This support
is also planned to be available for z/OS V2.1 with PTFs at IBM z13
general availability.
z/OS V2.2 is planned to support up to 141 processors (CPs and zIIPs)
per LPAR or up to 128 physical processors (256 logical processors) per
LPAR in SMT mode. z/OS V2.2 is also planned to support up to 4 TB of
real memory per LPAR. This support is also planned to be available on
z/OS V2.1 with PTFs. For more information, see Software Announcement
215-006, dated January 14, 2015, z/OS V2.2 - Fueling the new Digital
Enterprise.

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

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

Re: IBM United States Announcement Letters

[Greg Dyck]

On 1/14/2015 12:28 PM, Mike Schwab wrote:

(So it looks like any individual task that is CPU bound and limited to
one core will take twice as long.)


What you state is always true for temporal multithreading, which 
timeslices the execution of CP x with CP y on a single core.


But for simultaneous multithreading it would be a worst case boundary 
condition, but not the most likely result.  There is almost 'dead' time 
in the execution of instructions while the core must wait for storage to 
be fetched or stored away.  SMT takes advantage of that time, with the 
best case boundary condition being that no perceptible change occurs in 
the CPU time required to run two tasks on the same core.


Your mileage will vary program by program, but typical results might be 
that two tasks will execute a single core at 70% of their non-SMT 
instruction rate, but the same core will execute 40% more total 
instructions between the two threads.


Greg

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

Re: IBM United States Announcement Letters

[Bob Shannon]

> With SMT (Hyperthreading) the logical number of cores is double the physical 
> cores.
>(So it looks like any individual task that is CPU bound and limited to one 
>core will take twice as long.)

SMT is only implemented on zIFL and zIIP specialty engines. I expect it will be 
extended to CPs once IBM gains experience .

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

IBM United States Announcement Letters

[Mike Schwab]

Below is the plain text announcement letter I received for the
categories I subscribed to.
Some repeat others postings, some haven't been posted.

Notes:
The max number of physical cores goes from 101 to 141.
IBM z13 Models N30, N63, N96, NC9 (129), and NE1 (141).
Max throughput is rated at 40% increase, so cores are roughly the same speed.
With SMT (Hyperthreading) the logical number of cores is double the
physical cores.
(So it looks like any individual task that is CPU bound and limited to
one core will take twice as long.)

FICON Express 16S only negotiates down to 4G speed. 8S orderable but
z13 is the last.

APARs to utilize new features for z/OS 1.13 and 2.1.

-- 



IBM United States Announcement Letters



Hardware





The IBM z13



http://www.ibm.com/vrm/newsletter_10577_9003055_290761_email_DYN_1IN/wjpen61666855





Software





IBM Ported Tools for z/OS Version 1.3 updated to include new level of
Open SSH, 6.4p1



http://www.ibm.com/vrm/newsletter_10577_9003055_290630_email_DYN_1IN/wjpen61666855



 IBM Enterprise PL/I for z/OS, V4.5 offers new function and improved performance



http://www.ibm.com/vrm/newsletter_10577_9003055_290958_email_DYN_1IN/wjpen61666855



 IBM Enterprise COBOL for z/OS, V5.2 delivers support for the latest
IBM z13 processor architecture



http://www.ibm.com/vrm/newsletter_10577_9003055_290966_email_DYN_1IN/wjpen61666855



New, high-performance IBM XL C/C++ for Linux on z Systems, V1.1
compiler now delivered for Linux on z Systems



http://www.ibm.com/vrm/newsletter_10577_9003055_290982_email_DYN_1IN/wjpen61666855



Technology Transition Offerings for the IBM z13 offer
price-performance advantages



http://www.ibm.com/vrm/newsletter_10577_9003055_290996_email_DYN_1IN/wjpen61666855



IBM Enterprise COBOL for z/OS, V5.2 delivers support for the latest
IBM z13 processor architecture



http://www.ibm.com/vrm/newsletter_10577_9003055_291006_email_DYN_1IN/wjpen61666855



Preview: IBM z/OS Version 2 Release 2 -- Fueling the new digital enterprise



http://www.ibm.com/vrm/newsletter_10577_9003055_291076_email_DYN_1IN/wjpen61666855



IBM 31-bit SDK for z/OS, Java Technology Edition, Version 8 delivers
new platform support



http://www.ibm.com/vrm/newsletter_10577_9003055_291108_email_DYN_1IN/wjpen61666855



IBM 64-bit SDK for z/OS, Java Technology Edition, Version 8 delivers
new platform support



http://www.ibm.com/vrm/newsletter_10577_9003055_291116_email_DYN_1IN/wjpen61666855





Withdrawals





Hardware withdrawal:  Select IBM z Systems products



http://www.ibm.com/vrm/newsletter_10577_9003055_291287_email_DYN_1IN/wjpen61666855





Summary of all IBM announcements for today





Announcement Summary - January 14, 2015



http://www.ibm.com/vrm/newsletter_10577_9003055_291279_email_DYN_1IN/wjpen61666855





About this newsletter



Manage your subscriptions:

http://www.ibm.com/vrm/newsletter_10577_9003055_7160_email_DYN_1IN/wjpen61666855



Subscribe:

http://www.ibm.com/vrm/newsletter_10577_9003055_7160_email_DYN_3IN/wjpen61666855



Unsubscribe:

http://www.ibm.com/vrm/newsletter_10577_9003055_7160_email_DYN_2IN/wjpen61666855



Feedback:

mailto:g...@us.ibm.com



DID YOU KNOW? Many people who read Announcement letters also read IBM
Redbooks.  For installation and implementation experiences, solution
scenarios and "how-to" information, IBM Redbooks
(http://www.redbooks.ibm.com) publications are the go-to standard for
IT professionals.



To send Announcement letter feedback or for an iNews question send a
note to: g...@us.ibm.com To ensure proper delivery please add
vrmm...@us.ibm.com to your address book. You received this e-mail
because you are subscribed to IBM's IBM United States Announcement
Letters as: mike.sch...@illinois.gov



To search for other IBM announcements -- Find announcements by date,
title, announcement letter number, part number, or other search words,
at: http://www-01.ibm.com/common/ssi/index.wss



Please note that the products described and contact addresses
mentioned in the attachment apply in the U.S. only, and may not be
applicable in other countries. Readers in other countries should
contact IBM locally for details.



The iNews subscription service is not intended to be an official IBM
notification channel, and is not represented as such.

 The ibm.com website is the official source for IBM information. The
iNews e-mail service is offered as adjunct method to receive
information, but not to replace or replicate ibm.com or fulfill any
contractual requirements for notification to clients.



© International Business Machines Corporation 2015. All rights reserved.



C

Re: Abend S602-0 when in AMODE 64

[Binyamin Dissen]

On Wed, 14 Jan 2015 14:41:46 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on
:>01/14/2015
:>   at 08:00 AM, Donald Likens  said:

:>>AMODE 64 routines should be using relative branch and generally
:>>should  establish addressability to a static data area

:>What if the code is shared? That goes against decades of coding to be
:>reentrant and refreshable.

What issues do you perceive sharing a STATIC data area?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: Abend S602-0 when in AMODE 64

[Shmuel Metz (Seymour J.)]

In <7102282945307177.wa.dlikensinfosecinc@listserv.ua.edu>, on
01/14/2015
   at 08:00 AM, Donald Likens  said:

>AMODE 64 routines should be using relative branch and generally
>should  establish addressability to a static data area

What if the code is shared? That goes against decades of coding to be
reentrant and refreshable.
 
-- 
 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...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMP/E version in z/OS 1.4

[Thomas Conley]

On 1/14/2015 12:54 PM, Paul Gilmartin wrote:

On Wed, 14 Jan 2015 10:17:41 -0500, John Eells wrote:


I love archeology (grin).

In z/OS V1.4:

Element  Last changed:  Equivalent:

SMP/E:   z/OS V1R2  SMP/E for z/OS and OS/390 V3R1, 5655-G44


Was this also the first release that supported RECEIVE FROMNTS?

Initially IBM made that SMP/E release available to customers for
download at no charge.  Is it still available?

Of course, this antedates the notorious security weakness which
was later discovered and addressed but never repaired.



It was repaired.  The offending utility was rewritten to remove the APF 
requirement.


https://share.confex.com/share/120/webprogram/Handout/Session12980/SHARE_SF_12980%20IEBCOPY.pdf

Regards,
Tom Conley

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

Enterprise COBOL 5.2 announced

[Frank Swarbrick]

More fun from 
IBM:http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&appname=gpateam&supplier=897&letternum=ENUS215-027#h2-availx
(I haven't read it yet.)


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

Re: z/OS 2.2 "nifties"

[Don Poitras]

In article <8970765119932831.wa.paulgboulderaim@listserv.ua.edu> you wrote:
> On Wed, 14 Jan 2015 10:42:52 -0500, Don Poitras wrote:
> >
> >> Good, Better, Excellent. OpenSSH has proven itself sofar to be useful.
> >
> >I just hope we finally get a binary scp. The current one is pretty
> >useless for most of the stuff I use scp for on other hosts.
> > 
> Does sftp not suffice?  I stumbled on a page that mentions an enhanced
> sftp doing UNIX<-->DOS newline conversion.  Similar enhancement might
> do ASCII<-->EBCDIC for which others have wished (but which EBCDIC?)

It's not really the "s" part of scp that I find useful. I use ftp and
nfs as my normal methods of copying to/from z/OS. Everywhere else,
I use scp. 

> And from ASCII UNIX I have done such as the cumbersome:

> ssh MVS "pax -w list-of-files | iconv -f ISO8859-1 -t IBM-1047" | pax -r

> >> I hope there is also a menu-driven presentation beside the usual 
> >> batch/prompting way of working.
> > 
> "Menu-driven"?  Clarify.  ISPF?  Other?

> -- gil

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

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

Re: SMP/E version in z/OS 1.4

[Paul Gilmartin]

On Wed, 14 Jan 2015 10:17:41 -0500, John Eells wrote:

>I love archeology (grin).
>
>In z/OS V1.4:
>
>Element  Last changed:  Equivalent:
>
>SMP/E:   z/OS V1R2  SMP/E for z/OS and OS/390 V3R1, 5655-G44
> 
Was this also the first release that supported RECEIVE FROMNTS?

Initially IBM made that SMP/E release available to customers for
download at no charge.  Is it still available?

Of course, this antedates the notorious security weakness which
was later discovered and addressed but never repaired.

Such information is of peculiar interest to a vendor of tape
subsystems who, ironically, wishes to forgo delivery of software
on tape media.

-- gil

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

Re: Forced password change held to be harmful -- Was RE: RACF password history was: AW: //STARTING JOB ...

[Thomas Berg]

A bit OT, but this, I think, is a good idea: http://www.passwordcard.org/en



Best Regards,
Thomas Berg
___ 
Thomas Berg   Specialist   zOS/RQM/IT Delivery   Swedbank AB (Publ)




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

Re: Forced password change held to be harmful -- Was RE: RACF password history was: AW: //STARTING JOB ...

[Paul Gilmartin]

On Wed, 14 Jan 2015 11:15:32 -0500, Hobart Spitz wrote:

>Under z/VM, SFS has the capability for a user to have the ability to
>grant/revoke access to files and directories that are owned by the user's
>id.  Thus, users can grant and revoke access to/from their own SFS
>resources without the bother of involving a security staffer, addressing
>(1) above.
>
>Perhaps there is a less known analogous feature in RACF or a requirement
>that needs to be written and/or supported.
> 
ACLs?

>On Mon, Dec 29, 2014 at 8:56 AM, Charles Mills wrote:
>>
>> The big negatives of forced password change are that studies have shown that
>> people forced to change passwords choose progressively weaker passwords, and
>> are more compelled to write them down.
>>
>> http://cryptosmith.com/password-sanity/exp-harmful/
>>
Lately, I stumbled on a javascripted web page my employer 5 to 10
years ago used to suggest difficult passwords.  The rule, enforced by
LDAP was that a password must represent at least 3 of the 4 categories:

o minuscule
o numeric
o special
o majuscule

The recommended generator did all 4.  Of 8 characters (the enforced
minumum):

o 1-2 are minuscule
o 3-5 are numeric
o 6 is special
o 7-8 are majuscule

But is this an optimal defense against a brute-force search?

-- gil

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

Re: z/OS 2.2 "nifties"

[John McKown]

On Wed, Jan 14, 2015 at 9:42 AM, Don Poitras  wrote:

> In article <
> 4802123765485208.wa.elardus.engelbrechtsita.co...@listserv.ua.edu> you
> wrote:
> > John McKown wrote:
>
> > >Well, at least I consider them to be. Too bad I'll never see them here.
>
> > I have for now problems reading those PDFs and announcements about z/OS
> v2.2. Will try later again.
>
> > >
>
> > >IBM plans to add OpenSSH to z/OS and enhance it by providing Kerberos
> support, which is designed to enable single sign-on from Microsoft?
> Windows? domains, and also to leverage the capabilities of IBM zEnterprise
> Data Compression (zEDC). These capabilities are also planned to be made
> available in the version of OpenSSH that is part of IBM Ported Tools for
> z/OS.
>
> > Good, Better, Excellent. OpenSSH has proven itself sofar to be useful.
>
> I just hope we finally get a binary scp. The current one is pretty
> useless for most of the stuff I use scp for on other hosts.
>

​Me too. That's another reason that I have Dovetailed Technologies' Data
Set Pipes installed. It has a UNIX commands, tofile & fromfile, which can
transfer data in binary or with code (and line ending) conversions via ssh.
There are versions to run on z/OS UNIX, z/Linux, Linux/Intel, Wintel, AIX
and source code which can be compiled on other UNIX or UNIX-like systems.​
The tofile/fromfile can basically convert to/from any code page which is
supported by the iconv() function. scp seems to be limited to
ISO8859-1(?)<->IBM-1047 with LF and NEL line endings, respectively.


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

Re: z/OS 2.2 "nifties"

[Paul Gilmartin]

On Wed, 14 Jan 2015 10:42:52 -0500, Don Poitras wrote:
>
>> Good, Better, Excellent. OpenSSH has proven itself sofar to be useful.
>
>I just hope we finally get a binary scp. The current one is pretty
>useless for most of the stuff I use scp for on other hosts.
> 
Does sftp not suffice?  I stumbled on a page that mentions an enhanced
sftp doing UNIX<-->DOS newline conversion.  Similar enhancement might
do ASCII<-->EBCDIC for which others have wished (but which EBCDIC?)

And from ASCII UNIX I have done such as the cumbersome:

ssh MVS "pax -w list-of-files | iconv -f ISO8859-1 -t IBM-1047" | pax -r

>> I hope there is also a menu-driven presentation beside the usual 
>> batch/prompting way of working.
> 
"Menu-driven"?  Clarify.  ISPF?  Other?

-- gil

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

Re: Forced password change held to be harmful -- Was RE: RACF password history was: AW: //STARTING JOB ...

[Hobart Spitz]

Under z/VM, SFS has the capability for a user to have the ability to
grant/revoke access to files and directories that are owned by the user's
id.  Thus, users can grant and revoke access to/from their own SFS
resources without the bother of involving a security staffer, addressing
(1) above.

Perhaps there is a less known analogous feature in RACF or a requirement
that needs to be written and/or supported.

On Mon, Dec 29, 2014 at 8:56 AM, Charles Mills  wrote:

> Why force your users to change passwords at all? I know "everyone does it"
> but what problems does it solve?
>
> 1. Bob needs access to some dataset that his userid does not grant. So
> Alice
> loans him her logon credentials. Forcing Alice to change her password
> prevents Bob from continuing to masquerade as Alice.
>
> 2. Bob hangs out in Alice's cubicle while she logs on. Every day he is able
> to glimpse a little of her password until he has the whole thing figured
> out. Forcing Alice to change her password periodically ameliorates this
> problem.
>
> But for (1.) a better solution is giving Bob the access his job requires
> and
> for both problems a better solution is training Alice.
>
> The big negatives of forced password change are that studies have shown
> that
> people forced to change passwords choose progressively weaker passwords,
> and
> are more compelled to write them down.
>
> http://cryptosmith.com/password-sanity/exp-harmful/
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of nitz-...@gmx.net
> Sent: Monday, December 29, 2014 6:29 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF password history was: AW: //STARTING JOB ...
>
> > Check out the SETROPTS HISTORY and MINCHANGE options if you haven't
> already.
>
> Thanks, Tom! I did that and set history accordingly. No need for an exit,
> then! I would set MINCHANGE only if I see that someone tries to change the
> many passwords that are now kept to get to the (n+1)th password.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
OREXXMan

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

Re: z/OS 2.2 "nifties"

[Don Poitras]

In article <4802123765485208.wa.elardus.engelbrechtsita.co...@listserv.ua.edu> 
you wrote:
> John McKown wrote:

> >Well, at least I consider them to be. Too bad I'll never see them here.

> I have for now problems reading those PDFs and announcements about z/OS v2.2. 
> Will try later again.

> >

> >IBM plans to add OpenSSH to z/OS and enhance it by providing Kerberos 
> >support, which is designed to enable single sign-on from Microsoft? Windows? 
> >domains, and also to leverage the capabilities of IBM zEnterprise Data 
> >Compression (zEDC). These capabilities are also planned to be made available 
> >in the version of OpenSSH that is part of IBM Ported Tools for z/OS.

> Good, Better, Excellent. OpenSSH has proven itself sofar to be useful.

I just hope we finally get a binary scp. The current one is pretty
useless for most of the stuff I use scp for on other hosts.



> I hope there is also a menu-driven presentation beside the usual 
> batch/prompting way of working.

> Groete / Greetings
> Elardus Engelbrecht


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

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

Re: SMP/E version in z/OS 1.4

[Elardus Engelbrecht]

John Eells wrote:

>I "dug into" the same one I posted last week, namely:

>  http://publibz.boulder.ibm.com/cgi-bin/bookmgr/Shelves

>I found the shelf for z/OS V1R4, opened z/OS Planning for Installation, then 
>looked at the table that lists the elements and features.

Thanks, I've got it. 

In one of the shelves named 'z/OS V1R4.0 All-Books Bookshelf', I found TWO 
versions of SMP/E mentioned there.

So, I looked at other IBM's pages before I posted in this thread.

Groete / Greetings
Elardus Engelbrecht

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

Re: SMP/E version in z/OS 1.4

[Mark Pace]

Thank you, John for the direct answer.  Thanks to everyone else that put
effort into the answer.

On Wed, Jan 14, 2015 at 10:17 AM, John Eells  wrote:

> I love archeology (grin).
>
> In z/OS V1.4:
>
> Element  Last changed:  Equivalent:
>
> SMP/E:   z/OS V1R2  SMP/E for z/OS and OS/390 V3R1, 5655-G44
>
> --
> John Eells
> z/OS Technical Marketing
> IBM Poughkeepsie
> ee...@us.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: SMP/E version in z/OS 1.4

[John Eells]

elardus.engelbre...@sita.co.za (Elardus Engelbrecht) wrote:

John Eells wrote:


I love archeology (grin).


May I ask where is the URL of that digsite you used? ;-)


I "dug into" the same one I posted last week, namely:

 http://publibz.boulder.ibm.com/cgi-bin/bookmgr/Shelves

I found the shelf for z/OS V1R4, opened z/OS Planning for Installation, 
then looked at the table that lists the elements and features.


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

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

Re: SMP/E version in z/OS 1.4

[Tom Marchant]

On Wed, 14 Jan 2015 09:53:35 -0500, Mark Pace wrote:

>Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
>or 3.4, possibly earlier version?

I looked at the Edition Notice in the SMP/E Commands manuals. The 3.1 manual 
is dated March, 2002. The 3.2 manual is dated August, 2003. z/OS 1.4 became 
available in September, 2002, so I conclude that it must have been 3.1.

>No amount of googling has provided the answer for me.

I'm not surprised.

-- 
Tom Marchant

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

Re: SMP/E version in z/OS 1.4

[Elardus Engelbrecht]

John Eells wrote:

>I love archeology (grin).

May I ask where is the URL of that digsite you used? ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: SMP/E version in z/OS 1.4

[Mark Pace]

I need to have the 1.4 as a target.  But they are having issues with the
change to the FIXCAT ++HOLD.

So I was trying to find a PTF for APAR IO7480 for their version of SMP/E.
566894901 D00.  It appears to me that their version did not get get the
remedial service.

On Wed, Jan 14, 2015 at 10:13 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Mark Pace wrote:
>
> >Can someone tell me what version of SMP/E was included in z/OS 1.4?
> 3.3 or 3.4, possibly earlier version?
>
> Probably 3.1.x or 3.2.x. I said probably, because my documentation +
> copies are deleted by this time.
>
>
> >No amount of googling has provided the answer for me.
>
> Surprise, IBM and Google don't help me. 
>
> I searched again. I tried Lifecycle pages of IBM to see if I got anything.
>
> ( http://www-01.ibm.com/software/support/systemsz/lifecycle/ )
>
> Perhaps below can give you a guide or estimate?
>
> z/OS v1.4.x was GA around Sept 2002. SMP/E 3.1 was GA around Oct 2001 and
> SMP/E 3.2 around May 2003.
> SMP/E 3.3 is GA Sep 2004, just after EOM of z/OS 1.4.
>
> It thus depends. Do you require z/OS 1.4 to be driving or target system?
>
> Just don't take my words for granted...
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: SMP/E version in z/OS 1.4

[Thomas Conley]

On 1/14/2015 9:53 AM, Mark Pace wrote:

Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
or 3.4, possibly earlier version?

No amount of googling has provided the answer for me.



My P390 running z/OS V1R4 shows 32.06.

Regardes,
Tom Conley

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

Re: SMP/E version in z/OS 1.4

[John Eells]

I love archeology (grin).

In z/OS V1.4:

Element  Last changed:  Equivalent:

SMP/E:   z/OS V1R2  SMP/E for z/OS and OS/390 V3R1, 5655-G44

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

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

Re: SMP/E version in z/OS 1.4

[Charles Mills]

I've got a V1R5 Bookmanager DVD. I'll fire that up if that would be of any help.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Pace
Sent: Wednesday, January 14, 2015 6:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMP/E version in z/OS 1.4

Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
or 3.4, possibly earlier version?

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

Re: SMP/E version in z/OS 1.4

[Elardus Engelbrecht]

Mark Pace wrote:

>Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3 or 
>3.4, possibly earlier version?

Probably 3.1.x or 3.2.x. I said probably, because my documentation + copies are 
deleted by this time.


>No amount of googling has provided the answer for me.

Surprise, IBM and Google don't help me. 

I searched again. I tried Lifecycle pages of IBM to see if I got anything.

( http://www-01.ibm.com/software/support/systemsz/lifecycle/ )

Perhaps below can give you a guide or estimate?

z/OS v1.4.x was GA around Sept 2002. SMP/E 3.1 was GA around Oct 2001 and SMP/E 
3.2 around May 2003.
SMP/E 3.3 is GA Sep 2004, just after EOM of z/OS 1.4.

It thus depends. Do you require z/OS 1.4 to be driving or target system?

Just don't take my words for granted...

Groete / Greetings
Elardus Engelbrecht

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

Re: z/OS 2.2 "nifties"

[Paul Gilmartin]

On Wed, 14 Jan 2015 07:25:59 -0600, John McKown wrote:
>===
>z/OS V2.2 JES2 and SDSF will be designed to support a new way to track job
>step completion codes. A new machine-readable data set is planned to
>contain job tracking information, including the completion codes for each
>job step. ...
> 
I guess that it's good that it will be "machine-readable".  It would be
inconvenient if it were readable only by human beings and perhaps
trained hamsters.

Would this provide a means for scripts and EXECs to monitor
progress and detect successful completion of jobs they submit?

>===
>JES3 has long supported capabilities for informal, ad hoc batch scheduling.
>In JES3, these facilities are called deadline scheduling and dependent job
>control. z/OS V2.2 JES2 will be designed to provide similar functions, with
>some additional capabilities. ...
>
JES2 is catching up with and (see above) in some areas surpassing JES3.
Is the incentive to buy JES3 dwindling?

-- gil

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

Re: Abend S602-0 when in AMODE 64

[Tom Marchant]

On Wed, 14 Jan 2015 08:00:40 -0600, Donald Likens  
wrote:

>>AMODE 64 routines should be using relative branch and generally should 
>>establish addressability to a static data area (such as where LTORG might 
>>be), often done by a LARL instruction.
>>
>>Peter Relson
>>z/OS Core Technology Design
>
>
>Is there a document that documents the above? I want to see if there is 
>anything else I didn't know about AMODE 64 coding.

See, for example, the ATTACH macro in the Assembler Services Reference.


5.1.8 Parameters

The parameters are explained as follows:
 
...
  
  Register  Contents 
0 Used as a work register by the system. 

1 Address of the user parameter list if specified on either the PARAM 
or MF=E parameters; otherwise, contains whatever GPR 1 contained 
at the time the ATTACH macro was issued.  

2-12 Used as work registers by the system.  

13 Address of a standard save area.  

14 Return address. Bit 0 is 0 if the subtask routine gets control in 24-bit 
addressing mode; bit 0 is 1 if the subtask routine gets control in 31-bit 
addressing mode.  

15 When the subtask routine is to run in 24-bit or 31-bit addressing mode, the 
entry point address of the subtask routine.  When the subtask routine is to run 
in 64-bit addressing mode, it is expected to use relative branching and 
register 15 contains a value that can be used to determine the addressing mode 
of the issuer of the ATTACH or ATTACHX macro as follows:  

Issuer AMODE 24: X'F000'  
Issuer AMODE 31: X'F002'  
Issuer AMODE 64: X'F004'


-- 
Tom Marchant

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

Re: SMP/E version in z/OS 1.4

[Mark Pace]

Thanks, Dana, but I don't know where it is set either.

On Wed, Jan 14, 2015 at 10:02 AM, Dana Mitchell  wrote:

> Mark,
>
> I have a z/OS 1.4 sysres still lying around, but I can't bring it up.
> Would you happen to know where I could find the version in the SMP/E
> libraries?  The primary panel just has a variable &GGLVL and I can't find
> where it's set.
>
> Dana
>
>
> On Wed, 14 Jan 2015 09:53:35 -0500, Mark Pace 
> wrote:
>
> >Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
> >or 3.4, possibly earlier version?
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: SMP/E version in z/OS 1.4

[Dana Mitchell]

Mark,

I have a z/OS 1.4 sysres still lying around, but I can't bring it up.  Would 
you happen to know where I could find the version in the SMP/E libraries?  The 
primary panel just has a variable &GGLVL and I can't find where it's set.

Dana


On Wed, 14 Jan 2015 09:53:35 -0500, Mark Pace  wrote:

>Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
>or 3.4, possibly earlier version?
>

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

SMP/E version in z/OS 1.4

[Mark Pace]

Can someone tell me what version of SMP/E was included in z/OS 1.4?3.3
or 3.4, possibly earlier version?

No amount of googling has provided the answer for me.

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: Abend S602-0 when in AMODE 64

[Don Poitras]

In article <2783086669968142.wa.dlikensinfosecinc@listserv.ua.edu> you 
wrote:
> In response to:

> > Can anyone explain why the following code did not work in AMODE 64 but 
> > works in AMODE 31?

> Yes... bit 32 of R15 on entry to your STIMER exit routine is on.  In 
> AMODE 64 the LA of the ECB address propagates it into R1. Thus R1 
> indicates it is a cross-memory POST.  In AMODE 31 the LA of the ECB 
> ignores it so the POST works as expected.
> Greg

> I turned off bit 32 in R15 and that fixed the problem... Thank you.

> I am confused about a couple of things however...

> 1) If in AMODE64 when the STIMERX macro was issued, why was bit 32 on in R15? 
> Seems wrong to me.
> 2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 when bit 32 on the 
> base reg was on? 

> Thank you all for your help

1) Dunno. Seem wrong to me too. LLGTR 15,15 at entry would fix it. 
2) LA doesn't access storage, it just does arithmetic.

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

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

Re: Gizmodo article about the z13

[Elardus Engelbrecht]

Pommier, Rex wrote:

>The link worked just fine for me.  Check to see if your browser dropped extra 
>junk in the URL.

Thanks to Rex and Alva. Copy+edit the URL and retry on Mozilla Firefox (not 
internet exploder) gave me the page for my sore eyes.

I like that sentence on that gizmodo page: 'IBM's new Z13 mainframe is a 
hulking silicon beast.' ;-)

Thanks for curing my 404 allergy! Much appreciated!

Groete / Greetings
Elardus Engelbrecht

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

Re: Gizmodo article about the z13

[Nims,Alva John (Al)]

Okay a slogan for the z13, "When the going gets Tough, the Tough get a z13!", 
to plagiarize an old saying, "When the going gets tough, the tough go 
SHOPPING!" 

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Regan
Sent: Wednesday, January 14, 2015 8:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Gizmodo article about the z13

http://gizmodo.com/ibms-hulking-new-mainframe-will-help-you-shop-1679413722 
Thanks,
 
Mark Regan, USNR-Ret, 1969-1991
<><

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

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

Re: Gizmodo article about the z13

[Nims,Alva John (Al)]

Actually because the email system seems to have wrapped the URL, it cut off the 
"3722" at the end of the URL, so when you click on the link it gets the 404, 
but just add 3722 to the end and the link should work.

Al Nims
Systems Admin/Programmer 3
Information Technology
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Wednesday, January 14, 2015 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gizmodo article about the z13

Elardus,

The link worked just fine for me.  Check to see if your browser dropped extra 
junk in the URL.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, January 14, 2015 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gizmodo article about the z13

Mark Regan wrote:

>http://gizmodo.com/ibms-hulking-new-mainframe-will-help-you-shop-167941
>3722

Above URL is not correct? Do you have any medicines for my allergy to '404 
page-not-found'? 

Or I really need serious cut-copy-paste training 101...

Groete / Greetings
Elardus Engelbrecht

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

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


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

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

Re: Gizmodo article about the z13

[Pommier, Rex]

Elardus,

The link worked just fine for me.  Check to see if your browser dropped extra 
junk in the URL.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Wednesday, January 14, 2015 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Gizmodo article about the z13

Mark Regan wrote:

>http://gizmodo.com/ibms-hulking-new-mainframe-will-help-you-shop-1679413722

Above URL is not correct? Do you have any medicines for my allergy to '404 
page-not-found'? 

Or I really need serious cut-copy-paste training 101...

Groete / Greetings
Elardus Engelbrecht

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

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


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

Re: Gizmodo article about the z13

[Elardus Engelbrecht]

Mark Regan wrote:

>http://gizmodo.com/ibms-hulking-new-mainframe-will-help-you-shop-1679413722

Above URL is not correct? Do you have any medicines for my allergy to '404 
page-not-found'? 

Or I really need serious cut-copy-paste training 101...

Groete / Greetings
Elardus Engelbrecht

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

Re: Abend S602-0 when in AMODE 64

[Donald Likens]

In response to:

As a reminder: AMODE 64 routines in general should not rely on the 
time-of-entry register 15 for addressability. LINK(X) / ATTACH(X) targets 
are cases for which it is "cannot" rather than "should not". The supplied 
code did use reg 15 for addressability:
STIMERX  DS0H 
... 
 USING *,R15

AMODE 64 routines should be using relative branch and generally should 
establish addressability to a static data area (such as where LTORG might 
be), often done by a LARL instruction.

Peter Relson
z/OS Core Technology Design


Is there a document that documents the above? I want to see if there is 
anything else I didn't know about AMODE 64 coding.

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

Re: z/OS 2.2 "nifties"

[Elardus Engelbrecht]

John McKown wrote:

>Well, at least I consider them to be. Too bad I'll never see them here.

I have for now problems reading those PDFs and announcements about z/OS v2.2. 
Will try later again.

>

>IBM plans to add OpenSSH to z/OS and enhance it by providing Kerberos support, 
>which is designed to enable single sign-on from Microsoft™ Windows™ domains, 
>and also to leverage the capabilities of IBM zEnterprise Data Compression 
>(zEDC). These capabilities are also planned to be made available in the 
>version of OpenSSH that is part of IBM Ported Tools for z/OS.

Good, Better, Excellent. OpenSSH has proven itself sofar to be useful.

I hope there is also a menu-driven presentation beside the usual 
batch/prompting way of working.

Groete / Greetings
Elardus Engelbrecht

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

Re: Abend S602-0 when in AMODE 64

[Donald Likens]

In response to:

> Can anyone explain why the following code did not work in AMODE 64 but works 
> in AMODE 31?

Yes... bit 32 of R15 on entry to your STIMER exit routine is on.  In 
AMODE 64 the LA of the ECB address propagates it into R1. Thus R1 
indicates it is a cross-memory POST.  In AMODE 31 the LA of the ECB 
ignores it so the POST works as expected.
Greg

I turned off bit 32 in R15 and that fixed the problem... Thank you.

I am confused about a couple of things however...

1) If in AMODE64 when the STIMERX macro was issued, why was bit 32 on in R15? 
Seems wrong to me.
2) Why didn't the "LA1,STIMECB" abend on an S0C4-38 when bit 32 on the base 
reg was on? 

Thank you all for your help

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

Gizmodo article about the z13

[Mark Regan]

http://gizmodo.com/ibms-hulking-new-mainframe-will-help-you-shop-1679413722 
Thanks,
 
Mark Regan, USNR-Ret, 1969-1991
<><

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

Re: IBM Launches the z13 Mainframe

[Bob Shannon]

> I hope it builds the z base, but I can't see it converting many over.

I doubt IBM expects anyone to convert due to SIMD. However, the SIMD 
functionality may encourage some to look towards IBM when considering Linux 
solutions. For the rest of us, compilers will generate SIMD code where 
appropriate. Those running on the z13 or higher will benefit without having to 
do anything other than to change their compile options.

Bob Shannon
Rocket Software

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com
Manage Your Subscription Preferences - 
http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: IBM Launches the z13 Mainframe

[John McKown]

On Wed, Jan 14, 2015 at 7:15 AM, Shane Ginnane  wrote:

> On Wed, 14 Jan 2015 07:01:02 -0600, John McKown wrote:
>
> >​SIMD, to me, means instructions akin to the old vector facility on a few
> >of the previous machines.
>
> Think MMX and SSE for your x86 boxes. They've had it since before the turn
> of the century. Not to mention SMT.
> All this is old news to the rest of the computing word.
> Then there is the EBCDIC issue you mentioned - and {big,little}-endian
> concerns of course.
>

​I basically ignored the "endian" problem because _my_ C code generally
uses the​ C  "hton..." and "ntoh..." functions to convert my binary number
from/to external format (which I keep in "network order") in files. But
that is just me. Too bad the C compiler does not have a way in the language
itself to say "this is a ??? bit number in host order" and "this is a ???
bit number in network order". But the ugly EBCDIC is just ugly. I rather
like the fact that Java uses Unicode internally for all "character" data
and does the code translation on read/write.



>
> I hope it builds the z base, but I can't see it converting many over.
>
> Shane ...
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

z/OS 2.2 "nifties"

[John McKown]

Well, at least I consider them to be. Too bad I'll never see them here.

===
Generation data groups (GDGs) are limited to 255 or fewer generations. z/OS
V2.2 will be designed to support a new data set type, generation data group
extended (GDGE), which is planned to allow you to specify that up to 999
generations be kept when the function is enabled in an IGGCATxx member of
parmlib. This new support is intended to support a larger number to make it
easier to manage data sets that are created frequently. For example, it
will be possible to specify that all of the generations created every day
for a full year be kept. Additionally, IDCAMS and DFSMSdfp processing are
planned to be enhanced to allow you to specify that unexpired generation
data sets be deleted automatically when retaining them would result in the
inability to create a new generation.

===
z/OS V2.2 JES2 and SDSF will be designed to support a new way to track job
step completion codes. A new machine-readable data set is planned to
contain job tracking information, including the completion codes for each
job step. SDSF will be designed to extract and display step-level
completion codes for batch jobs, and the z/OSMF Jobs REST API is planned to
allow you to retrieve step-level completion codes. Also, this function is
planned to support new optional SMF Type 30 information. This is intended
to make it easier to interpret job output quickly and to provide the
capability for later analyses of job step level information.

===
JES3 has long supported capabilities for informal, ad hoc batch scheduling.
In JES3, these facilities are called deadline scheduling and dependent job
control. z/OS V2.2 JES2 will be designed to provide similar functions, with
some additional capabilities. A new SCHEDULE JCL statement is planned;
STARTBY and HOLDUNTL keywords of SCHEDULE will be designed to make it
easier for you to submit jobs intended for later execution without the need
to log onto a system at the time you want the jobs to run.

Other keywords will be designed to allow you to specify ordering and
dependency information for groups of jobs, supporting both serial and
parallel execution. Corresponding operator command support is planned to
allow job groups to be held, released, modified, canceled, and purged.
Corresponding support is also planned for SDSF, which will be designed to
provide information about job group status and the status of jobs in a job
group, and WLM, which will be designed to support this function with
enhancements to Batch Initiator Management. Together, these new
capabilities are intended to supplement those of production job scheduling
products such as Tivoli Workload Scheduler for z/OS, by helping you
simplify the scheduling of batch jobs and job groups that are run only when
necessary and need not be added to production job schedules.

===
z/OS V2.2 ISPF is planned to provide a new option you can use to completely
disable the use of ISPF Edit Pack. This function will be designed to allow
you to help control CPU utilization for ISPF users by preventing the
overhead of software compression and inflation for data sets used in
conjunction with ISPF and ISPF services, and assure that newly created and
unpacked data sets processed by ISPF can be easily processed by other
programs.


===
Inline assembler statements support will be designed to allow you to insert
assembler statements inlined with XL C and XL C++ code. This support will
be designed to not require Metal C compilation and to allow you to easily
use specialized instructions with your C and C++ objects.

===
z/OS V2.2 is planned to introduce a new z/OS Client Web Enablement Toolkit,
designed to enable applications written in C/C++, COBOL, PL/I, and High
Level Assembler to participate more easily as a client in a RESTful web
application programming model. The toolkit is planned to provide a z/OS
JSON parser able to process text coming from any source, to build new JSON
text, or add to existing JSON text; and, an HTTP/HTTPS protocol enabler
that uses interfaces similar to other industry-standard APIs. These
components are also planned to be available for z/OS V2.1. The PTF for
OA46575 is planned to include the z/OS JSON Parser and be made available in
the first quarter of 2015. The PTF for OA46622 is planned to provide the
z/OS HTTP enabler and to be closed by the z/OS V2.2 general availability
date.

===

IBM plans to add OpenSSH to z/OS and enhance it by providing Kerberos
support, which is designed to enable single sign-on from Microsoft™
Windows™ domains, and also to leverage the capabilities of IBM zEnterprise
Data Compression (zEDC). These capabilities are also planned to be made
available in the version of OpenSSH that is part of IBM Ported Tools for
z/OS.

===

-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111

Re: IBM Launches the z13 Mainframe

[Shane Ginnane]

On Wed, 14 Jan 2015 07:01:02 -0600, John McKown wrote:

>​SIMD, to me, means instructions akin to the old vector facility on a few
>of the previous machines.

Think MMX and SSE for your x86 boxes. They've had it since before the turn of 
the century. Not to mention SMT.
All this is old news to the rest of the computing word.
Then there is the EBCDIC issue you mentioned - and {big,little}-endian concerns 
of course.

I hope it builds the z base, but I can't see it converting many over.

Shane ...

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

Re: IBM Launches the z13 Mainframe

[John McKown]

On Wed, Jan 14, 2015 at 6:28 AM, Binyamin Dissen  wrote:

> Did not find the link to the new POPs.
>

​And I am eager to see it too, due to this:

z/OS V2.2 XML System Services is planned to use the new vector (SIMD)
instructions available on z13 processors. This function, also available on
z/OS V2.1 with the PTF for APAR OA44545, is intended to help improve the
performance for nonvalidating XML parsing for some documents.
​

​SIMD, to me, means instructions akin to the old vector facility on a few
of the previous machines.

I'm still don't understand why IBM doesn't use GPU processing as is done on
many Intel boxes. My only guess is that they don't consider the current
GPUs to be reliable enough. But, IMO, they should at least embrace the
OpenCL paradigm ( http://en.wikipedia.org/wiki/OpenCL ). This might help
people to convert to z/OS. Of course, there is still that nasty EBCDIC
issue for any conversion.​


-- 
​
While a transcendent vocabulary is laudable, one must be eternally careful
so that the calculated objective of communication does not become ensconced
in obscurity.  In other words, eschew obfuscation.

111,111,111 x 111,111,111 = 12,345,678,987,654,321

Maranatha! <><
John McKown

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

Re: Abend S602-0 when in AMODE 64

[Elardus Engelbrecht]

Donald Likens wrote:

>The "LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS" reply was in response to Dave 
>Day's inquiry. He asked what the left half values of the registers are.

Many thanks. I now understand. I'm just trying to catch up with all the posts 
on IBM-MAIN including yours.

Did you resolved your problem after Peter Relson and Greg Dyck's questions / 
explanations?

Groete / Greetings
Elardus Engelbrecht

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

Re: Abend S602-0 when in AMODE 64

[Donald Likens]

On response to: 
On Tue, 13 Jan 2015 05:30:17 -0600, Donald Likens wrote:

You didn't quote any of the message(s) that you replied to, so you 
leave us guessing. That is not a good way to ask for help.

-- 
Tom Marchant

Thanks you... I will try to include the question in the response from now on.

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

Re: Abend S602-0 when in AMODE 64

[Donald Likens]

In response to Elardus Engelbrecht question. 

The "LEFT HALVES OF ALL REGISTERS CONTAIN ZEROS" reply was in response to Dave 
Day's inquiry. He asked what the left half values of the registers are.

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

Re: IBM Launches the z13 Mainframe

[Binyamin Dissen]

Did not find the link to the new POPs.

On Wed, 14 Jan 2015 14:54:41 +0800 Timothy Sipples  wrote:

:>IBM has now posted a great deal of information on the new IBM z13 including
:>a data sheet, redbook, frequently asked questions (and answers), a preview
:>of z/OS 2.2, and much more. Here's the link:
:>
:>http://www.ibm.com/systems/z/announcement.html
:>
:>I plan to offer some thoughts live during IBM's Webcast starting at 19:00
:>UTC on January 14, 2015, on Twitter (@sipples) if you're interested.
:>
:>
:>Timothy Sipples
:>IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
:>E-Mail: sipp...@sg.ibm.com

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: IBM Launches the z13 Mainframe

[Vernooij, CP (ITOPT1) - KLM]

Now we will see who is right: IBM or the Triskaidekaphobiae.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 14 January, 2015 10:21
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Launches the z13 Mainframe

Mark Regan wrote:

>http://www-03.ibm.com/press/us/en/pressrelease/45808.wss   Thanks,

Is it fast? Superfast, Lightspeed fast? If so I want 4 of these gems. One Prod, 
Dev and DRP and nr 4 to take home to play. ;-)

Thanks Mark! ;-)

Hmm, I hope Big Blue can sell this toy, z13 successfully despite customers 
having 'Triskaidekaphobia' ... ;-)

http://en.wikipedia.org/wiki/Triskaidekaphobia

Groete / Greetings
Elardus Engelbrecht

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

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

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




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

Re: IBM Launches the z13 Mainframe

[Elardus Engelbrecht]

Mark Regan wrote:

>http://www-03.ibm.com/press/us/en/pressrelease/45808.wss   Thanks,

Is it fast? Superfast, Lightspeed fast? If so I want 4 of these gems. One Prod, 
Dev and DRP and nr 4 to take home to play. ;-)

Thanks Mark! ;-)

Hmm, I hope Big Blue can sell this toy, z13 successfully despite customers 
having 'Triskaidekaphobia' ... ;-)

http://en.wikipedia.org/wiki/Triskaidekaphobia

Groete / Greetings
Elardus Engelbrecht

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