Re: What was a 3314? (was: Whither VIO)

[Martin Packer]

Right. My (now long gone, I fear) VIOTOES presentation majored on (the then
new) DFSMS implementation. In particular ACS Routines and VIOMAXSIZE.

But I still thought you had to have some VIO devices defined.

Cheers, Martin

Sent from my iPad

> On 19 May 2016, at 22:53, Gibney, David Allen  wrote:
>
> Very, Very early in implementing SMS (the minimal implementation) is
managing VIO.
>
> Since we've been SMS for a long time, there aren't even any devices in
our EDT(s) for VIO
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Norman.Hollander
>> Sent: Thursday, May 19, 2016 2:45 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss?
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Ted MacNEIL
>> Sent: Thursday, May 19, 2016 1:18 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Memory is abundant‎ in most shops and cheap overall. So, why all fuss
about
>> VIO? Make s decision, implement it, forget it.
>>
>> -teD
>>  Original Message
>> From: Norman.Hollander
>> Sent: Thursday, May 19, 2016 12:19
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Reply To: IBM Mainframe Discussion List
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Track size. We actually used to use a 2305 "drum" definition for VIO.
But if
>> you genned 1 dummy address, you had to gen all 8. Made for a larger
IO-gen.
>> So we would go for the next best tracksize of the 2314. So- how many 4K
>> pages fit into a track without wasting too much of it? Plus the 2314 was
small,
>> so quick sorts in VIO might be possible, but it prevented sorting a
kabillion
>> records. I'm pretty sure 2305 support was removed a long time ago, so
you
>> couldn't define it today. Probably true for the 2311/2314/2319. Last
time I
>> went through IODF, a fake 3390 (address DEFF) was defined as the only
VIO
>> capable device. With all the various Sort and Memory exits today, it's
>> probably just a good history lesson. Oh- way back in the 70s, a company
>> named Ampex (IIRC) made look alike (aka cheaper) memory and Disk
storage.
>> Think their mountable disk was the 3314. OK- discuss further...
>>
>> zNorman
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Martin Packer
>> Sent: Wednesday, May 18, 2016 10:45 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>>
>> It's sort of come back to me:
>>
>> A small track size limits the virtual storage window (probably usually
below
>> the line in 1989 when I looked at this). Or it might've been cylinder.
But I
>> think it was track.
>>
>> I'm wondering if anyone else remembers something like this.
>>
>> Cheers, Martin
>>
>> Sent from my iPad
>>
>> On 19 May 2016, at 05:20, Edward Gould 
>> wrote:
>>
 On May 18, 2016, at 7:50 PM, Charles Mills 
>> wrote:

 I remember them well. I was answering Steve's two implied questions.

 2321 was certainly characterized as DASD. It was indeed a direct
 access
>> storage device. Not a disk, but DASD nonetheless. Certainly not magnetic
>> tape (though it had a family resemblance!) and certainly not unit
record.
>>>
>>> It addressing had MMBBCCHHR(R?) so I guess you could address it
directly.
>> Anyone remember how to do that? (progr5amming for a 2321 is a lost art
>> (where is Seymour?).
>>>
>>> Ed
>>>

 I don't think anyone recalls a 3314. I think the OP said it was a
 typo,
>> 2314 mis-remembered as 3000-series DASD.

 Charles

 -Original Message-
 From: IBM Mainframe Discussion List [mailto:IBM-
>> m...@listserv.ua.edu]
 On
>> Behalf Of Edward Gould
 Sent: Wednesday, May 18, 2016 5:33 PM
 To: IBM-MAIN@LISTSERV.UA.EDU
 Subject: Re: What was a 3314? (was: Whither VIO)

 Chales,

 2321 was a data cell (magnetic strip) hardly could be called DASD) I
>> don’t recall a 3314 . The removable 3340 (not sure the number anyone?)

 Ed

> On May 16, 2016, at 7:47 PM, Charles Mills 
>> wrote:
>
>
>
> 2301, 2321.
> CharlesSent from a mobile; please excuse the brevity
>
>  Original message 
> From: Steve Thompson 
> Date: 05/16/2016 4:51 PM (GMT-08:00)
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
>
> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've
> had the pleasure of working with. I've forgotten the drum device
> numbers and the noodle snatcher model number.

 -
 - For IBM-MAIN subscribe / signoff 

Re: What was a 3314?

[Tom Brennan]

Not if the jobs run fine.

To change the subject beyond VIO: In my experience, arbitrary limits on 
mainframe resources do nothing more than result in job reruns.  Jobs 
killed because of time/space/spool/etc might need double the CPU because 
of the rerun after the limits are increased.  What a waste of a good CPU 
that could be used for a nice game of chess.


Norman.Hollander wrote:

Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss?


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

Re: What was a 3314? (was: Whither VIO)

[Tony Harminc]

On 19 May 2016 at 16:56, Martin Packer  wrote:
> The whole disk is NOT in your virtual storage; The track window IS (IIRC).

Well I wasn't thinking *your* (the caller's) virtual storage;
obviously it can't all be there. I was thinking there would be a VSM
mapping of the whole device in *some* virtual space, but clearly this
wouldn't have worked with 24-bit addressing. So I guess my mental
model for this is wrong; presumably VIO is a driver of ASM at the same
level as VSM is. And there must be a track (or some larger or smaller
page-multiple) buffer that forms the interface to ASM.

Well I guess going and looking at the code would be best; MVS 3.8 is
still out there for the reading.

Tony H.

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

Re: What was a 3314? (was: Whither VIO)

[Ward, Mike S]

Wasn't the MM the bon number?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Wednesday, May 18, 2016 11:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
> 
> I remember them well. I was answering Steve's two implied questions.
> 
> 2321 was certainly characterized as DASD. It was indeed a direct access 
> storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
> (though it had a family resemblance!) and certainly not unit record.

It addressing had MMBBCCHHR(R?) so I guess you could address it directly. 
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).

Ed

> 
> I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 
> mis-remembered as 3000-series DASD.
> 
> Charles
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Edward Gould
> Sent: Wednesday, May 18, 2016 5:33 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> Chales,
> 
> 2321 was a data cell (magnetic strip) hardly could be called DASD) I 
> don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
> 
> Ed
> 
>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>> 
>> 
>> 
>> 2301, 2321.
>> CharlesSent from a mobile; please excuse the brevity
>> 
>>  Original message 
>> From: Steve Thompson 
>> Date: 05/16/2016  4:51 PM  (GMT-08:00)
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>> 
>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've 
>> had the pleasure of working with. I've forgotten the drum device 
>> numbers and the noodle snatcher model number.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

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

Re: What was a 3314? (was: Whither VIO)

[Gibney, David Allen]

Very, Very early in implementing SMS (the minimal implementation) is managing 
VIO. 

Since we've been SMS for a long time, there aren't even any devices in our 
EDT(s) for VIO

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Norman.Hollander
> Sent: Thursday, May 19, 2016 2:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss?
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ted MacNEIL
> Sent: Thursday, May 19, 2016 1:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> Memory is abundant‎ in most shops and cheap overall. So, why all fuss about
> VIO? Make s decision, implement it, forget it.
> 
> -teD
>   Original Message
> From: Norman.Hollander
> Sent: Thursday, May 19, 2016 12:19
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> Track size. We actually used to use a 2305 "drum" definition for VIO. But if
> you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen.
> So we would go for the next best tracksize of the 2314. So- how many 4K
> pages fit into a track without wasting too much of it? Plus the 2314 was 
> small,
> so quick sorts in VIO might be possible, but it prevented sorting a kabillion
> records. I'm pretty sure 2305 support was removed a long time ago, so you
> couldn't define it today. Probably true for the 2311/2314/2319. Last time I
> went through IODF, a fake 3390 (address DEFF) was defined as the only VIO
> capable device. With all the various Sort and Memory exits today, it's
> probably just a good history lesson. Oh- way back in the 70s, a company
> named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage.
> Think their mountable disk was the 3314. OK- discuss further...
> 
> zNorman
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Martin Packer
> Sent: Wednesday, May 18, 2016 10:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
> 
> 
> It's sort of come back to me:
> 
> A small track size limits the virtual storage window (probably usually below
> the line in 1989 when I looked at this). Or it might've been cylinder. But I
> think it was track.
> 
> I'm wondering if anyone else remembers something like this.
> 
> Cheers, Martin
> 
> Sent from my iPad
> 
> On 19 May 2016, at 05:20, Edward Gould 
> wrote:
> 
> >> On May 18, 2016, at 7:50 PM, Charles Mills 
> wrote:
> >>
> >> I remember them well. I was answering Steve's two implied questions.
> >>
> >> 2321 was certainly characterized as DASD. It was indeed a direct
> >> access
> storage device. Not a disk, but DASD nonetheless. Certainly not magnetic
> tape (though it had a family resemblance!) and certainly not unit record.
> >
> > It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
> Anyone remember how to do that? (progr5amming for a 2321 is a lost art
> (where is Seymour?).
> >
> > Ed
> >
> >>
> >> I don't think anyone recalls a 3314. I think the OP said it was a
> >> typo,
> 2314 mis-remembered as 3000-series DASD.
> >>
> >> Charles
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> >> On
> Behalf Of Edward Gould
> >> Sent: Wednesday, May 18, 2016 5:33 PM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: What was a 3314? (was: Whither VIO)
> >>
> >> Chales,
> >>
> >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
> don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
> >>
> >> Ed
> >>
> >>> On May 16, 2016, at 7:47 PM, Charles Mills 
> wrote:
> >>>
> >>>
> >>>
> >>> 2301, 2321.
> >>> CharlesSent from a mobile; please excuse the brevity
> >>>
> >>>  Original message 
> >>> From: Steve Thompson 
> >>> Date: 05/16/2016 4:51 PM (GMT-08:00)
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Subject: Re: What was a 3314? (was: Whither VIO)
> >>>
> >>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've
> >>> had the pleasure of working with. I've forgotten the drum device
> >>> numbers and the noodle snatcher model number.
> >>
> >> -
> >> - 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
> >Unless stated otherwise above:
> IBM 

Re: What was a 3314? (was: Whither VIO)

[Norman.Hollander]

Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Thursday, May 19, 2016 1:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

Memory is abundant‎ in most shops and cheap overall. So, why all fuss about 
VIO? Make s decision, implement it, forget it.

-teD
  Original Message
From: Norman.Hollander
Sent: Thursday, May 19, 2016 12:19
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: What was a 3314? (was: Whither VIO)

Track size. We actually used to use a 2305 "drum" definition for VIO. But if 
you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. So 
we would go for the next best tracksize of the 2314. So- how many 4K pages fit 
into a track without wasting too much of it? Plus the 2314 was small, so quick 
sorts in VIO might be possible, but it prevented sorting a kabillion records. 
I'm pretty sure 2305 support was removed a long time ago, so you couldn't 
define it today. Probably true for the 2311/2314/2319. Last time I went through 
IODF, a fake 3390 (address DEFF) was defined as the only VIO capable device. 
With all the various Sort and Memory exits today, it's probably just a good 
history lesson. Oh- way back in the 70s, a company named Ampex (IIRC) made look 
alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 
3314. OK- discuss further...

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Wednesday, May 18, 2016 10:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


It's sort of come back to me:

A small track size limits the virtual storage window (probably usually below 
the line in 1989 when I looked at this). Or it might've been cylinder. But I 
think it was track.

I'm wondering if anyone else remembers something like this.

Cheers, Martin

Sent from my iPad

On 19 May 2016, at 05:20, Edward Gould  wrote:

>> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
>>
>> I remember them well. I was answering Steve's two implied questions.
>>
>> 2321 was certainly characterized as DASD. It was indeed a direct 
>> access
storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
(though it had a family resemblance!) and certainly not unit record.
>
> It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).
>
> Ed
>
>>
>> I don't think anyone recalls a 3314. I think the OP said it was a 
>> typo,
2314 mis-remembered as 3000-series DASD.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On
Behalf Of Edward Gould
>> Sent: Wednesday, May 18, 2016 5:33 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Chales,
>>
>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>>
>> Ed
>>
>>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>>>
>>>
>>>
>>> 2301, 2321.
>>> CharlesSent from a mobile; please excuse the brevity
>>>
>>>  Original message 
>>> From: Steve Thompson 
>>> Date: 05/16/2016 4:51 PM (GMT-08:00)
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: What was a 3314? (was: Whither VIO)
>>>
>>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've 
>>> had the pleasure of working with. I've forgotten the drum device 
>>> numbers and the noodle snatcher model number.
>>
>> -
>> - 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 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

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

--
For IBM-MAIN subscribe / 

Re: What was a 3314?

[Anne & Lynn Wheeler]

norman.hollan...@desertwiz.biz (Norman.Hollander) writes:
> Track size.  We actually used to use a 2305 "drum" definition for VIO.
> But if you genned 1 dummy address, you had to gen all 8.  Made for a
> larger IO-gen.  So we would go for the next best tracksize of the
> 2314. So- how many 4K pages fit into a track without wasting too much
> of it?  Plus the 2314 was small, so quick sorts in VIO might be
> possible, but it prevented sorting a kabillion records.  I'm pretty
> sure 2305 support was removed a long time ago, so you couldn't define
> it today.  Probably true for the 2311/2314/2319.  Last time I went
> through IODF, a fake 3390 (address DEFF) was defined as the only VIO
> capable device. With all the various Sort and Memory exits today, it's
> probably just a good history lesson. Oh- way back in the 70s, a
> company named Ampex (IIRC) made look alike (aka cheaper) memory and
> Disk storage.  Think their mountable disk was the 3314.  OK- discuss
> further...

design point for 3090 needed lot more memory than originally planned
... combination of software bloat and 3880 disk controller was much
slower than originally predicted (which then required doubling number of
channels, which required an additional TCM, joke was 3090 product was
going to charge the disk division for the manufacturing cost of the
additional TCM). Physical packaging problem for the additional memory
required longer distance that exceeded the original latency specs ... so
they invented expanded store ... with a very wide bus and software
interface that could quickly move 4k page between processor memory and
expanded store (but physically it was the same memory technology).

Slightly before that, one of the vendors started producing simulated
2305 "electronic paging device" ... using electronic memory ... and IBM
bought a whole load of them for internal use (internal designation was
"1655"). The question was asked why couldn't IBM produce such an
electronic disk ... and the answer was every memory chip IBM was
producing was already being sold as memory (and/or expanded store)
... which had a lot higher profit margin than electronic disk. The
"1655" vendor did point out that they were using memory chips that had
failed tests required for processor memory ... but could still be used
in simulated electronic disk (with disk controller electronics being
able to compensate for various memory issues).

The 3090 expanded store bus was than also used for supercomputer HIPPI
100mbyte/sec RAID disks. Standard 3090 channels couldn't remotely come
close to handling HIPPI 100mbyte/sec ... so they came up with this hack
to cut HIPPI interface into side of the expanded store bus ... and then
they used reserved expanded store bus addressed to implement peek/poke
kind of I/O semantics (to initiate HIPPI read/write I/O operations).

I/O trivia: 1980 I was con'ed into doing channel extender support for
IBM STL lab that was moving 300 from the IMS group to off-site bldg
 with service back into the STL datacenter. They had tried "remote"
3270 and found it totally unacceptable (comapare to the direct channel
attached 3270 human factors that they were use to). The channel extender
support put a channel emulator at off-site bldg with direct channel
attached 3270 controllers, Channel programs were down loaded to the
remote channel emulator ... which went a long way to eliminating the
enormous overhead & latency of chnanel interface protocol chatter.  The
vendor then wanted to get approval from IBM to release my support, but
there was a group in POK playing with some serial stuff that objected
(because they were afraid if my stuff was released, it would make it
harder to get their stuff released).

Then in 1988, I was asked to help LLNL get some serial stuff they were
playing with standardized (the standard would include remote i/o program
download to eliminate significant I/O program protocol chatter
latency). This quickly becomes fibre-channel standard (originally
supporting 1gbit/sec concurrent transfer in both directions).

Then in 1990, the POK group gets their stuff released as ESCON when it
is already obsolete.

Then some POK people get involved in fibre-channel standard and define a
heavy-weight protocol that drastically reduces the native throughput
... that is eventually released as FICON. Latest published "peak I/O"
throughput was z196 using 104 FICON to get 2M IOPS. At about the same
time a (single) fibre-channel was announced for E5-2600 blade claiming
over million IOPS (two such fibre-channel having higher native
throughput than 104 FICON running over 104 fibre-channel).

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: What was a 3314? (was: Whither VIO)

[Martin Packer]

ESCTVIO (Expanded Storage Criterion Age for VIO) was supposed to control
it. Current Migration Age was compared to the Criterion Age.

(I think Criterion Age SINGULAR for VIO. Someone correct me if I'm wrong,
please.)

Cheers, Martin

Sent from my iPad

> On 19 May 2016, at 22:05, Longabaugh, Robert E 
wrote:
>
> Small track sizes were considered more efficient for VIO because of the
number of page slots that had to be used in order to satisfy the
allocation.  Also VIO would get all 16 extents at once, so saying TRK(1,1)
was not better than saying TRK(16).  When a job did the VIO allocation, it
got the page slots.
>
> In 1990 or 1991 (before I worked for Sterling Software and now CA) my
employer had a series of system slowdowns which were caused by paging slot
shortages, or exhaustion.  We found that many jobs were using VIO for
SORTWKnn DDs.  This all traced back to an individual application programmer
who knew just enough about VIO to see it was virtual, but did not grasp the
difference between "virtual" and "unlimited".
>
> I don't remember there being a way to put a hard limit on the total
amount of VIO in use by the system. Now in the days of cached and solid
state DASD the I/O performance payback isn't as big.  As in the previous
response, the system did not set aside an entire 2314 (or 3330) worth of
page slots to back the VIO requests.  It just fulfilled the requests for
"tracks" as they came in.
>
>
> Bob Longabaugh
> CA Technologies
> Storage Management
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Martin Packer
> Sent: Thursday, May 19, 2016 3:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: What was a 3314? (was: Whither VIO)
>
>
> The whole disk is NOT in your virtual storage; The track window IS
(IIRC).
>
> Cheers, Martin
>
> Sent from my iPad
>
>>> On 19 May 2016, at 21:45, Tony Harminc  wrote:
>>>
>>> On 19 May 2016 at 01:44, Martin Packer 
wrote:
>>> It's sort of come back to me:
>>>
>>> A small track size limits the virtual storage window (probably
>>> usually below the line in 1989 when I looked at this). Or it might've
>>> been cylinder. But I think it was track.
>>>
>>> I'm wondering if anyone else remembers something like this.
>>
>> I'm not sure I get the "virtual storage window" idea. VIO emulates an
>> entire disk drive in virtual storage. So where is there a window? The
>> whole disk has to be in virtual storage at once. Well, I suppose there
>> could be logic to not allocate Virtual until used, but that would
>> surely better be left to VSM's and RSM's expertise at managaing their
>> respective kinds of storage.
>>
>> Now maybe VIO was changed much later (surely there wasn't expanded
>> storage in 1989...?) to use or perhaps favour expanded storage, in
>> which case a window model could make some sense. But only if VIO was
>> directly dealing with expanded storage rather than just requesting
>> that RSM use it to back virtual storage used to hold the VIO disk
>> data.
>>
>> Tony H.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,  send
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>
>
> --
> 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-MAINUnless 
> stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: What was a 3314? (was: Whither VIO)

[Longabaugh, Robert E]

Small track sizes were considered more efficient for VIO because of the number 
of page slots that had to be used in order to satisfy the allocation.  Also VIO 
would get all 16 extents at once, so saying TRK(1,1) was not better than saying 
TRK(16).  When a job did the VIO allocation, it got the page slots.  

In 1990 or 1991 (before I worked for Sterling Software and now CA) my employer 
had a series of system slowdowns which were caused by paging slot shortages, or 
exhaustion.  We found that many jobs were using VIO for SORTWKnn DDs.  This all 
traced back to an individual application programmer who knew just enough about 
VIO to see it was virtual, but did not grasp the difference between "virtual" 
and "unlimited".

I don't remember there being a way to put a hard limit on the total amount of 
VIO in use by the system. Now in the days of cached and solid state DASD the 
I/O performance payback isn't as big.  As in the previous response, the system 
did not set aside an entire 2314 (or 3330) worth of page slots to back the VIO 
requests.  It just fulfilled the requests for "tracks" as they came in.


Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Thursday, May 19, 2016 3:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


The whole disk is NOT in your virtual storage; The track window IS (IIRC).

Cheers, Martin

Sent from my iPad

> On 19 May 2016, at 21:45, Tony Harminc  wrote:
>
>> On 19 May 2016 at 01:44, Martin Packer  wrote:
>> It's sort of come back to me:
>>
>> A small track size limits the virtual storage window (probably 
>> usually below the line in 1989 when I looked at this). Or it might've 
>> been cylinder. But I think it was track.
>>
>> I'm wondering if anyone else remembers something like this.
>
> I'm not sure I get the "virtual storage window" idea. VIO emulates an 
> entire disk drive in virtual storage. So where is there a window? The 
> whole disk has to be in virtual storage at once. Well, I suppose there 
> could be logic to not allocate Virtual until used, but that would 
> surely better be left to VSM's and RSM's expertise at managaing their 
> respective kinds of storage.
>
> Now maybe VIO was changed much later (surely there wasn't expanded 
> storage in 1989...?) to use or perhaps favour expanded storage, in 
> which case a window model could make some sense. But only if VIO was 
> directly dealing with expanded storage rather than just requesting 
> that RSM use it to back virtual storage used to hold the VIO disk 
> data.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,  send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: What was a 3314? (was: Whither VIO)

[Martin Packer]

The whole disk is NOT in your virtual storage; The track window IS (IIRC).

Cheers, Martin

Sent from my iPad

> On 19 May 2016, at 21:45, Tony Harminc  wrote:
>
>> On 19 May 2016 at 01:44, Martin Packer  wrote:
>> It's sort of come back to me:
>>
>> A small track size limits the virtual storage window (probably usually
>> below the line in 1989 when I looked at this). Or it might've been
>> cylinder. But I think it was track.
>>
>> I'm wondering if anyone else remembers something like this.
>
> I'm not sure I get the "virtual storage window" idea. VIO emulates an
> entire disk drive in virtual storage. So where is there a window? The
> whole disk has to be in virtual storage at once. Well, I suppose there
> could be logic to not allocate Virtual until used, but that would
> surely better be left to VSM's and RSM's expertise at managaing their
> respective kinds of storage.
>
> Now maybe VIO was changed much later (surely there wasn't expanded
> storage in 1989...?) to use or perhaps favour expanded storage, in
> which case a window model could make some sense. But only if VIO was
> directly dealing with expanded storage rather than just requesting
> that RSM use it to back virtual storage used to hold the VIO disk
> data.
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: What was a 3314? (was: Whither VIO)

[Tony Harminc]

On 19 May 2016 at 01:44, Martin Packer  wrote:
> It's sort of come back to me:
>
> A small track size limits the virtual storage window (probably usually
> below the line in 1989 when I looked at this). Or it might've been
> cylinder. But I think it was track.
>
> I'm wondering if anyone else remembers something like this.

I'm not sure I get the "virtual storage window" idea. VIO emulates an
entire disk drive in virtual storage. So where is there a window? The
whole disk has to be in virtual storage at once. Well, I suppose there
could be logic to not allocate Virtual until used, but that would
surely better be left to VSM's and RSM's expertise at managaing their
respective kinds of storage.

Now maybe VIO was changed much later (surely there wasn't expanded
storage in 1989...?) to use or perhaps favour expanded storage, in
which case a window model could make some sense. But only if VIO was
directly dealing with expanded storage rather than just requesting
that RSM use it to back virtual storage used to hold the VIO disk
data.

Tony H.

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

Re: What was a 3314? (was: Whither VIO)

[Ted MacNEIL]

Memory is abundant‎ in most shops and cheap overall. So, why all fuss about 
VIO? Make s decision, implement it, forget it.

-teD
  Original Message  
From: Norman.Hollander
Sent: Thursday, May 19, 2016 12:19
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: What was a 3314? (was: Whither VIO)

Track size. We actually used to use a 2305 "drum" definition for VIO. But if 
you genned 1 dummy address,
you had to gen all 8. Made for a larger IO-gen. So we would go for the next 
best tracksize of the 2314. So-
how many 4K pages fit into a track without wasting too much of it? Plus the 
2314 was small, so quick sorts in VIO
might be possible, but it prevented sorting a kabillion records. I'm pretty 
sure 2305 support was removed a long
time ago, so you couldn't define it today. Probably true for the 
2311/2314/2319. Last time I went through IODF,
a fake 3390 (address DEFF) was defined as the only VIO capable device. With all 
the various Sort and Memory exits
today, it's probably just a good history lesson. Oh- way back in the 70s, a 
company named Ampex (IIRC) made look
alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 
3314. OK- discuss further...

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Wednesday, May 18, 2016 10:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


It's sort of come back to me:

A small track size limits the virtual storage window (probably usually below 
the line in 1989 when I looked at this). Or it might've been cylinder. But I 
think it was track.

I'm wondering if anyone else remembers something like this.

Cheers, Martin

Sent from my iPad

On 19 May 2016, at 05:20, Edward Gould  wrote:

>> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
>>
>> I remember them well. I was answering Steve's two implied questions.
>>
>> 2321 was certainly characterized as DASD. It was indeed a direct 
>> access
storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
(though it had a family resemblance!) and certainly not unit record.
>
> It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).
>
> Ed
>
>>
>> I don't think anyone recalls a 3314. I think the OP said it was a 
>> typo,
2314 mis-remembered as 3000-series DASD.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On
Behalf Of Edward Gould
>> Sent: Wednesday, May 18, 2016 5:33 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Chales,
>>
>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>>
>> Ed
>>
>>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>>>
>>>
>>>
>>> 2301, 2321.
>>> CharlesSent from a mobile; please excuse the brevity
>>>
>>>  Original message 
>>> From: Steve Thompson 
>>> Date: 05/16/2016 4:51 PM (GMT-08:00)
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: What was a 3314? (was: Whither VIO)
>>>
>>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've 
>>> had the pleasure of working with. I've forgotten the drum device 
>>> numbers and the noodle snatcher model number.
>>
>> -
>> - 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 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

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

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

Re: Mirror/back up your Development DASD

[Ted MacNEIL]

You may, if the source changed after the last backup.

-teD
  Original Message  
From: van der Grijn, Bart (B)
Sent: Thursday, May 19, 2016 11:24
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: Mirror/back up your Development DASD

Andy, we mirror our production to a recovery site using Global Mirror. 
We do back up the NonProd data and send it offsite. The thought is that we do 
want to be able to recover the other lifecycles at some point but don't have 
the RTO/RPO requirements that drive a mirror solution.

Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, May 19, 2016 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mirror/back up your Development DASD

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy

--
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: [EXTERNAL] Re: Two RFE's to please vote for

[Dyck, Lionel B. (TRA)]

You can add your comments to the comments section on both RFEs - I think that 
would be terrific.

Thank you

--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, May 19, 2016 2:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Two RFE's to please vote for

On Thu, 19 May 2016 13:57:41 -0500, Dyck, Lionel B. (TRA) wrote:

>I would like to encourage everyone on these listservs to check out these two 
>RFE's and please vote for them - let's "nudge" IBM into doing them:
> 
I have voted for both of these.  I think.  How does one indicate strength of 
interest (1-2-3-4-5)?  I couldn't find that.

>TSO Pipes
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47
>699
>
That's a weak "yes" for me.  But it shouldn't be "similar to CMS"; it should 
rely on reusable code as much as possible, for 
portability/compatibility/synchronized
maintenance.

>also for StreamIO
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47
>742
>
That's a strong "yes".  I'd add a couple things:

o Stream I/O is already supported in compiled Rexx, but only for Classic data 
sets,
  and in OMVS interpreted, but only for UNIX files.  Both should be supported 
everywnere.

o The standard SIGNAL ON NOTREADY should be part of the requirement.  (That
  can't be done in a function package.)

(Can you amend?)

There's some overlap here; it should be possible to bridge stream I/O to the 
putative TSO Pipelines.

Thanks,
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: Two RFE's to please vote for

[Paul Gilmartin]

On Thu, 19 May 2016 13:57:41 -0500, Dyck, Lionel B. (TRA) wrote:

>I would like to encourage everyone on these listservs to check out these two 
>RFE's and please vote for them - let's "nudge" IBM into doing them:
> 
I have voted for both of these.  I think.  How does one indicate strength of
interest (1-2-3-4-5)?  I couldn't find that.

>TSO Pipes
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699
>
That's a weak "yes" for me.  But it shouldn't be "similar to CMS"; it should 
rely
on reusable code as much as possible, for portability/compatibility/synchronized
maintenance.

>also for StreamIO
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47742
>
That's a strong "yes".  I'd add a couple things:

o Stream I/O is already supported in compiled Rexx, but only for Classic data 
sets,
  and in OMVS interpreted, but only for UNIX files.  Both should be supported 
everywnere.

o The standard SIGNAL ON NOTREADY should be part of the requirement.  (That
  can't be done in a function package.)

(Can you amend?)

There's some overlap here; it should be possible to bridge stream I/O to the
putative TSO Pipelines.

Thanks,
gil

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

Two RFE's to please vote for

[Dyck, Lionel B. (TRA)]

I would like to encourage everyone on these listservs to check out these two 
RFE's and please vote for them - let's "nudge" IBM into doing them:

TSO Pipes

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47699

also for StreamIO

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=47742


--
Lionel B. Dyck (Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI Service Delivery & Engineering

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

Re: Interesting (?) 64-bit assembler surprise

[Phil Smith III]

Ah.thanks, Rob and Greg! SYSSTATE is it then. Kinda figured it couldn't be
this broken-ish.

 


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

Re: Interesting (?) 64-bit assembler surprise

[Greg Dyck]

On 5/19/2016 9:54 AM, Phil Smith III wrote:
...

The surprise here was that since R14 had something in the top half of the
grande register, Bad Things resulted (S0C4) on the line with comment "ADDR
SYST LINKAGE TABLE". This seemed.unintuitive. Are we the only ones who were
(or have been) surprised by this? Should we have known better somehow?
Should that macro be doing an XGR, maybe?


You did not tell the z/OS macros the truth, the whole truth, and nothing 
but the truth about your execution environment.  If you had issued a 
SYSSTATE AMODE64=YES when you switched into AMODE 64 the macro would 
have generated a LLGT instead of a L instruction.  This is discussed in 
the z/OS books.

Greg

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

Re: Interesting (?) 64-bit assembler surprise

[Rob Scott]

Did you issue a SYSSTATE to inform the assembler which AMODE you are in before 
the STORAGE macro?

Sent from my iPhone

> On 19 May 2016, at 17:55, Phil Smith III  wrote:
>
> Doing a STORAGE OBTAIN in 64-bit mode:
>
>
>
>  STORAGE OBTAIN,LENGTH=WORKLEN
>
> + CNOP   0,4
>
> + B  IHB0012B .BRANCH AROUND DATA
>
> +IHB0012L DC A(WORKLEN)   .STORAGE LENGTH
>
> +IHB0012F DC BL1''
>
> + DC AL1(9*16).KEY
>
> +.BYTE2A  DC AL1(230) .SUBPOOL
>
> + DC BL1'0010'.FLAGS
>
> +IHB0012B DS 0F
>
> + L  0,IHB0012L   .STORAGE LENGTH   @P9C
>
> + L  15,IHB0012F  .CONTROL INFORMATION  @P9C
>
> + L  14,16(0,0)   .CVT ADDRESS
>
> + L  14,772(14,0) .ADDR SYST LINKAGE TABLE
>
> + L  14,160(14,0) .OBTAIN LX/EX FOR OBTAIN
>
> + PC 0(14).PC TO STORAGE RTN
>
>
>
> The surprise here was that since R14 had something in the top half of the
> grande register, Bad Things resulted (S0C4) on the line with comment "ADDR
> SYST LINKAGE TABLE". This seemed.unintuitive. Are we the only ones who were
> (or have been) surprised by this? Should we have known better somehow?
> Should that macro be doing an XGR, maybe?
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
+1 877.328.2932 ■ +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

Interesting (?) 64-bit assembler surprise

[Phil Smith III]

Doing a STORAGE OBTAIN in 64-bit mode:

 

  STORAGE OBTAIN,LENGTH=WORKLEN

+ CNOP   0,4

+ B  IHB0012B .BRANCH AROUND DATA

+IHB0012L DC A(WORKLEN)   .STORAGE LENGTH

+IHB0012F DC BL1''

+ DC AL1(9*16).KEY

+.BYTE2A  DC AL1(230) .SUBPOOL

+ DC BL1'0010'.FLAGS

+IHB0012B DS 0F

+ L  0,IHB0012L   .STORAGE LENGTH   @P9C

+ L  15,IHB0012F  .CONTROL INFORMATION  @P9C

+ L  14,16(0,0)   .CVT ADDRESS

+ L  14,772(14,0) .ADDR SYST LINKAGE TABLE

+ L  14,160(14,0) .OBTAIN LX/EX FOR OBTAIN

+ PC 0(14).PC TO STORAGE RTN

 

The surprise here was that since R14 had something in the top half of the
grande register, Bad Things resulted (S0C4) on the line with comment "ADDR
SYST LINKAGE TABLE". This seemed.unintuitive. Are we the only ones who were
(or have been) surprised by this? Should we have known better somehow?
Should that macro be doing an XGR, maybe?

 


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

Re: Mirror/back up your Development DASD

[Jesse 1 Robinson]

We began mirroring production around 2000. It was several years before we able 
to sell the idea of mirroring development too. The argument went something like 
this:

-- In our business (utility), program changes are constantly required by the 
State (PUC)
-- We cannot luxuriate in a lengthy period of stability after a disaster
-- The very act of moving production might itself spur the need for programming 
changes
-- The prospect of having to restore development from backups is totally 
unrealistic 
-- Especially in view of the most likely cause of disaster: earthquake--no one 
knows who will be available and where

We finally got funded for additional DASD to mirror the whole shop. There was 
an added benefit: when we moved the entire data center in 2013, we did it by 
mirroring to the new data center, engaging in a full 'DR test', and staying 
put. We could not have done that if we had not been mirroring development as 
well.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of van der Grijn, Bart (B)
Sent: Thursday, May 19, 2016 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Mirror/back up your Development DASD

Andy, we mirror our production to a recovery site using Global Mirror. 
We do back up the NonProd data and send it offsite. The thought is that we do 
want to be able to recover the other lifecycles at some point but don't have 
the RTO/RPO requirements that drive a mirror solution.
 
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, May 19, 2016 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mirror/back up your Development DASD

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy

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

Re: What was a 3314? (was: Whither VIO)

[Paul Gilmartin]

On Thu, 19 May 2016 13:40:48 +, Roach, Dennis wrote:

>Since almost all "3390" DASD resides on FBA arrayed disks, the software exists 
>and is running in the control units to convert ECKD to FBA requests.
> 
Kinda proprietary, though, whether from IBM or competitors, and hard to make
a business case for any of them to install in a thumb drive.

>[Default] On 18 May 2016 19:31:34 -0700, (Steve Thompson) wrote:
>>> snip
>>Makes one very glad to have things like thumb drives that we have 
>>today. Now if I could just get one big enough to IPL z/OS...

-- gil

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

Re: What was a 3314? (was: Whither VIO)

[Norman.Hollander]

Track size.  We actually used to use a 2305 "drum" definition for VIO.  But if 
you genned 1 dummy address,
you had to gen all 8.  Made for a larger IO-gen.  So we would go for the next 
best tracksize of the 2314. So-
how many 4K pages fit into a track without wasting too much of it?  Plus the 
2314 was small, so quick sorts in VIO
might be possible, but it prevented sorting a kabillion records.  I'm pretty 
sure 2305 support was removed a long
time ago, so you couldn't define it today.  Probably true for the 
2311/2314/2319.  Last time I went through IODF,
a fake 3390 (address DEFF) was defined as the only VIO capable device. With all 
the various Sort and Memory exits
today, it's probably just a good history lesson. Oh- way back in the 70s, a 
company named Ampex (IIRC) made look
alike (aka cheaper)  memory and Disk storage.  Think their mountable disk was 
the 3314.   OK- discuss further...

zNorman

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Martin Packer
Sent: Wednesday, May 18, 2016 10:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)


It's sort of come back to me:

A small track size limits the virtual storage window (probably usually below 
the line in 1989 when I looked at this). Or it might've been cylinder. But I 
think it was track.

I'm wondering if anyone else remembers something like this.

Cheers, Martin

Sent from my iPad

On 19 May 2016, at 05:20, Edward Gould  wrote:

>> On May 18, 2016, at 7:50 PM, Charles Mills  wrote:
>>
>> I remember them well. I was answering Steve's two implied questions.
>>
>> 2321 was certainly characterized as DASD. It was indeed a direct 
>> access
storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape 
(though it had a family resemblance!) and certainly not unit record.
>
> It addressing had MMBBCCHHR(R?) so I guess you could address it directly.
Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where 
is Seymour?).
>
> Ed
>
>>
>> I don't think anyone recalls a 3314. I think the OP said it was a 
>> typo,
2314 mis-remembered as 3000-series DASD.
>>
>> Charles
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>> On
Behalf Of Edward Gould
>> Sent: Wednesday, May 18, 2016 5:33 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: What was a 3314? (was: Whither VIO)
>>
>> Chales,
>>
>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I
don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>>
>> Ed
>>
>>> On May 16, 2016, at 7:47 PM, Charles Mills  wrote:
>>>
>>>
>>>
>>> 2301, 2321.
>>> CharlesSent from a mobile; please excuse the brevity
>>>
>>>  Original message 
>>> From: Steve Thompson 
>>> Date: 05/16/2016  4:51 PM  (GMT-08:00)
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: What was a 3314? (was: Whither VIO)
>>>
>>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've 
>>> had the pleasure of working with. I've forgotten the drum device 
>>> numbers and the noodle snatcher model number.
>>
>> -
>> - 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 
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
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: Mirror/back up your Development DASD

[van der Grijn, Bart (B)]

Andy, we mirror our production to a recovery site using Global Mirror. 
We do back up the NonProd data and send it offsite. The thought is that we do 
want to be able to recover the other lifecycles at some point but don't have 
the RTO/RPO requirements that drive a mirror solution.
 
Bart

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, May 19, 2016 10:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mirror/back up your Development DASD

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy

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

Re: What was a 3314? (was: Whither VIO)

[R.S.]

W dniu 2016-05-19 o 15:40, Roach, Dennis pisze:

Since almost all "3390" DASD resides on FBA arrayed disks, the software exists 
and is running in the control units to convert ECKD to FBA requests.

Not so easy.
USB stick use USB "CCW", so without hardware changes on mainframe side 
there would be no possibility to IPL from that. No USB port on mainframe.

Or change USB tisk to support mainframe "CCW" and FICON...
Another possibility is to create standalone Linux x64 image on the 
stick, with Hercules or zPDT, with some z/OS image.

;-)

--
Radoslaw Skorupka
Lodz, Poland






---
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci 
wpacony) wynosi 168.955.696 zotych.


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

Re: Mirror/back up your Development DASD

[John McKown]

On Thu, May 19, 2016 at 9:31 AM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> Backup Dasd via your laptop to an USB stick? Your company differs a lot
> from mine.
>

​Well, it is one way to make the mainframe security administrator have a
heart attack. Or hire a "wetworks" team to escort you from the planet.​

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: Mirror/back up your Development DASD

[Vernooij, CP (ITOPT1) - KLM]

Backup Dasd via your laptop to an USB stick? Your company differs a lot from 
mine.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: 19 May, 2016 16:14
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Mirror/back up your Development DASD

White, Andy wrote:
> Currently, we mirror all production but don't mirror the development DASD we 
> back most via VTS but I am pushing or trying that we back up all DASD.

At this point in the Moore curve, can't you just stick a USB in your laptop and 
write a script to back it up?


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

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

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: Mirror/back up your Development DASD

[Ambros, Thomas]

Mirroring development because we don't want to toss out a week or so worth of 
work, also allows our guys to fix apps fast (OK, not fast but you get the idea) 
if it comes to that.  It doesn't cost that much more to do it in our 
environment so it's worth the investment. 

Thomas Ambros
zEnterprise Operating Systems
zEnterprise Systems Management
518-436-6433

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of White, Andy
Sent: Thursday, May 19, 2016 10:03
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Mirror/back up your Development DASD

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy



The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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


This communication may contain privileged and/or confidential information. It 
is intended solely for the use of the addressee. If you are not the intended 
recipient, you are strictly prohibited from disclosing, copying, distributing 
or using any of this information. If you received this communication in error, 
please contact the sender immediately and destroy the material in its entirety, 
whether electronic or hard copy. This communication may contain nonpublic 
personal information about consumers subject to the restrictions of the 
Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose 
such information for any purpose other than to provide the services for which 
you are receiving the information.

127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from 
Key 
send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in 
the 
SUBJECT line.

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

Re: Mirror/back up your Development DASD

[Bigendian Smalls]

In general .. 

Mirroring is a recovery technology for infrastructure - should you lose 
hardware / geographic incident, etc. -  If you have any data corruption 
(intentional or otherwise) - Mirroring just makes it worse..  If you’re serious 
about having a development environment (Most shops are - Prodduction fixes, 
round the clock development, etc) you have to treat it as good as you would 
production.

Backups are for putting the pieces back in the event of inadvertant (or 
intentional) corruption / deletion / modification of something.  You need both 
- if your environment is important to you.

Sell it like this - Suppose you have a major development outage - what’s that 
costing you in lost productivity by the dev staff?   What if you had a 
production issue during that outage - is your source code availble?   Could you 
apply / test a fix?   

lastly - how long would it take to rebuild / buy a new development environment 
if you had a major issue.  Could you be down that long?  I suspect not, if you 
are like most places.

At a minimum you should back up and offsite your source code repos - any IP you 
cannot easily replace.

My .02

Chad




> On May 19, 2016, at 9:02 AM, White, Andy  wrote:
> 
> Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
> many of them back up the development DASD?
> 
> Currently, we mirror all production but don't mirror the development DASD we 
> back most via VTS but I am pushing or trying that we back up all DASD. My 
> thoughts about this are the development cycles and releases have a lot of 
> time and money invested if it lost this work, how much is this worth?
> 
> Anyway, if you are mirroring your development how did you "sell" it to your 
> management? If you're not why not?
> 
> Thanks
> Andy
> 
> 
> 
> The information contained in this message may be CONFIDENTIAL and is for the 
> intended addressee only.  Any unauthorized use, dissemination of the 
> information, or copying of this message is prohibited.  If you are not the 
> intended addressee, please notify the sender immediately and delete this 
> message.
> 
> --
> 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: Mirror/back up your Development DASD

[Jack J. Woehr]

White, Andy wrote:

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD.


At this point in the Moore curve, can't you just stick a USB in your laptop and 
write a script to back it up?


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

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

Mirror/back up your Development DASD

[White, Andy]

Hi people - For companies that mirror their mainframe DASD via XRC, SRDF, how 
many of them back up the development DASD?

Currently, we mirror all production but don't mirror the development DASD we 
back most via VTS but I am pushing or trying that we back up all DASD. My 
thoughts about this are the development cycles and releases have a lot of time 
and money invested if it lost this work, how much is this worth?

Anyway, if you are mirroring your development how did you "sell" it to your 
management? If you're not why not?

Thanks
Andy



The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only.  Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited.  If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: GDG retention

[Vernooij, CP (ITOPT1) - KLM]

CA-1 can keep the tape longer, but cannot prevent it from rolling off the GDG.
Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Fraser
Sent: 19 May, 2016 15:49
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDG retention

Depends in the tape management system as well.
CA-1 can be set and override retention
On 19 May 2016 20:58, "Lizette Koehler"  wrote:

> You need to see if the JCL that creates the JCL have things like
>
> RETPD=
> EXPDT=
>
> For GDGs, you also need to list the BASE GDG and see if it has NOSCRATCH
> OR NOEMPTY or SCRATCH or EMPTY
>
> Normally a GDG is created with EXPDT=99000 which is Catalog control.  Then
> when the +1 generation is created, if the Limit is reached, then the oldest
> version will drop off if the GDG is defined with Scratch NOEMPTY.
>
> A Limit of 14 means keep 14 versions.  If you create 14 in one day, then
> it will cycle very quickly.  If you create a GDG once per week it will last
> for 14 weeks.  This will depend on the frequency of the creation of the GDG.
>
> A search on the IBM Website for GDG CREATION provides this link.  It
> should be helpful
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab500/iea3b5_Generation_data_sets_.htm
>
>
>
> Check with your storage Admins for assistance.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Nathan Astle
> > Sent: Thursday, May 19, 2016 2:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: GDG retention
> >
> > Hello,
> >
> > We have some GDG getting created during the SMF processing. Is there a
> way to
> > determine its retention ?
> >
> > I see the value for GDG as LIM 14. Does that mean the retention would be
> 14
> > days ?
> >
> > Nathan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

For 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: GDG retention

[Brian Fraser]

Depends in the tape management system as well.
CA-1 can be set and override retention
On 19 May 2016 20:58, "Lizette Koehler"  wrote:

> You need to see if the JCL that creates the JCL have things like
>
> RETPD=
> EXPDT=
>
> For GDGs, you also need to list the BASE GDG and see if it has NOSCRATCH
> OR NOEMPTY or SCRATCH or EMPTY
>
> Normally a GDG is created with EXPDT=99000 which is Catalog control.  Then
> when the +1 generation is created, if the Limit is reached, then the oldest
> version will drop off if the GDG is defined with Scratch NOEMPTY.
>
> A Limit of 14 means keep 14 versions.  If you create 14 in one day, then
> it will cycle very quickly.  If you create a GDG once per week it will last
> for 14 weeks.  This will depend on the frequency of the creation of the GDG.
>
> A search on the IBM Website for GDG CREATION provides this link.  It
> should be helpful
>
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab500/iea3b5_Generation_data_sets_.htm
>
>
>
> Check with your storage Admins for assistance.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Nathan Astle
> > Sent: Thursday, May 19, 2016 2:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: GDG retention
> >
> > Hello,
> >
> > We have some GDG getting created during the SMF processing. Is there a
> way to
> > determine its retention ?
> >
> > I see the value for GDG as LIM 14. Does that mean the retention would be
> 14
> > days ?
> >
> > Nathan
>
> --
> 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: What was a 3314? (was: Whither VIO)

[Roach, Dennis]

Since almost all "3390" DASD resides on FBA arrayed disks, the software exists 
and is running in the control units to convert ECKD to FBA requests.

Dennis Roach, CISSP, PMP
IAM Access Administration - Consumer - Senior Analyst 
2929 Allen Parkway, America Building, 3rd Floor, Houston, TX 77019
Work:  713-831-8799
Cell:  713-591-1059
Email:  dennis.ro...@aig.com 

All opinions expressed by me are mine and may not agree with my employer or any 
person, company, or thing, living or dead, on or near this or any other planet, 
moon, asteroid, or other spatial object, natural or manufactured, since the 
beginning of time.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Thursday, May 19, 2016 8:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What was a 3314? (was: Whither VIO)

[Default] On 18 May 2016 19:31:34 -0700, in bit.listserv.ibm-main 
ste...@copper.net (Steve Thompson) wrote:

>> snip
>Makes one very glad to have things like thumb drives that we have 
>today. Now if I could just get one big enough to IPL z/OS...

Would 128 gigabytes be enough.  I think I have seen 256 GB.
The software to emulate ECKD would be interesting.

Clark Morris

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

Re: What was a 3314? (was: Whither VIO)

[Clark Morris]

[Default] On 18 May 2016 19:31:34 -0700, in bit.listserv.ibm-main
ste...@copper.net (Steve Thompson) wrote:

>> snip
>Makes one very glad to have things like thumb drives that we have 
>today. Now if I could just get one big enough to IPL z/OS...

Would 128 gigabytes be enough.  I think I have seen 256 GB.
The software to emulate ECKD would be interesting.

Clark Morris
>
>Regards,
>Steve Thompson
>
>
>On 05/18/2016 09:07 PM, Paul Gilmartin wrote:
>> On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote:
>>
>>> ... It was indeed a direct access storage device. Not a disk, but DASD 
>>> nonetheless. Certainly not magnetic tape (though it had a family 
>>> resemblance!) and certainly not unit record.
>>>
>> What's the criterion?  Max/Min latency ratio?  Statistical distribution of 
>> latency
>> between randomly selected records?  For tape, it's sort of triangular; for 
>> DASD
>> it has a sort of plateau.
>>
>> Addressable by block and writable randomly without corrupting other blocks?
>> DECtape had preformatted addressable blocks; it held a filesystem with a
>> directory.  It moved from reel to reel past a stationary R/W head.  It met 
>> some
>> criteria for DASD and some for tape; it was both.
>>
>> -- 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

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

Re: LOGR Format Level

[Dazzo, Matt]

Thanks Mark

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Wednesday, May 18, 2016 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LOGR Format Level

On Wed, 18 May 2016 14:04:59 -0400, Dazzo, Matt  wrote:

>>Started the 1.13 to 2.2 migration guide and they suggest upgrading 
>>LOGR dsn's to  level HBB7705, we are at HBB6603. We are a monoplex 
>>shop and probably always  will be. Is there any need to take this action in 
>>our environment?


>
> Below are the dsn's defined in couplxx member.  
> 
>DATA   TYPE(LOGR)  
>  PCOUPLE(SYS1.LOGR.ZOS.TECH01,OSPAG2)
> ACOUPLE(SYS1.LOGR.ZOS.TECH02,OSMCAT)
> 
>When I issue command D LOGGER,CONN,SYSPLEX,LSN=*, the display does not contain 
>those
> datasets.  Does that mean nothing  is writing to them?   
 
The command you issued displays logstreams, not couple data sets.  Do you see 
any
DASD logstreams in use?   I'm assuming you do.

To display the LOGR couple data sets the command would be:
   D XCF,COUPLE,TYPE=LOGR  or D XCF,CPL,TYPE=LOGR

I would have to go back and RTFM to know for sure, but IIRC the change was for 
SMDUPLEX (support system managed duplex rebuilding of structures) which you 
would never use in a monoplex.  So no, you don't have to do it but it wouldn't 
hurt and if it were me, I would do it anyway.

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
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: Privileged Users (was: EXTERNAL: Re: [EXTERNAL] Re: smp/e sha-2 support?)

[Joel C. Ewing]

On 05/18/2016 05:16 AM, Elardus Engelbrecht wrote:
> Robert S. Hansel (RSH) wrote:
>
>> OPERATIONS users actually can grant privileges because they can create 
>> dataset profiles for any group. And if they own a profile they create, they 
>> can permit access to it.
> RACF by default will allow that OPERATIONS stunt. IRREVX01 can be used to 
> block those acrobats.
>
> I needed to block them, because 'they' created profiles causing outages. No 
> Production STCs are going to use users own datasets. 
>
> Groete / Greetings
> Elardus Engelbrecht
>
>
Even a non-OPERATIONS user can potentially create RACF profiles for data
sets under their authority that might cause problems in an installation
where data set qualifiers and generic profiles are intended to control
default access and exceptions require justification.

At some point it makes sense to rely on installation standards, some
user education that the foot they shoot may be their own, and maybe some
blocked ISPF panel options to not make it easy for someone not properly
trained in installation RACF conventions to create RACF profiles, even
on their own data sets.

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: What was a 3314? (was: Whither VIO)

[John McKown]

On Wed, May 18, 2016 at 7:33 PM, Edward Gould 
wrote:

> Chales,
>
> 2321 was a data cell (magnetic strip) hardly could be called DASD)
>

​Technically, it was because you could get to a particular "block" of data
"directly" (DASD == Direct Access Storage Device) as opposed to a "serial"
device like tape (no "seek" on the original tape drives). It definitely
was​ wasn't a "random access" device because of the seek time (the same is
true of all disk devices). SSD and Flash are possibly the only non-volatile
true "random" access mass storage devices at present. And I'm not totally
sure about them.



> I don’t recall a 3314 . The removable 3340 (not sure the number anyone?)
>
> Ed
>
>

-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

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: GDG retention

[Lizette Koehler]

You need to see if the JCL that creates the JCL have things like

RETPD=
EXPDT=

For GDGs, you also need to list the BASE GDG and see if it has NOSCRATCH OR 
NOEMPTY or SCRATCH or EMPTY

Normally a GDG is created with EXPDT=99000 which is Catalog control.  Then when 
the +1 generation is created, if the Limit is reached, then the oldest version 
will drop off if the GDG is defined with Scratch NOEMPTY.

A Limit of 14 means keep 14 versions.  If you create 14 in one day, then it 
will cycle very quickly.  If you create a GDG once per week it will last for 14 
weeks.  This will depend on the frequency of the creation of the GDG.  

A search on the IBM Website for GDG CREATION provides this link.  It should be 
helpful

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieab500/iea3b5_Generation_data_sets_.htm



Check with your storage Admins for assistance.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: Thursday, May 19, 2016 2:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: GDG retention
> 
> Hello,
> 
> We have some GDG getting created during the SMF processing. Is there a way to
> determine its retention ?
> 
> I see the value for GDG as LIM 14. Does that mean the retention would be 14
> days ?
> 
> Nathan

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

Re: Product name by module

[Peter Relson]

I would have added, just in case the excellent advice previously given 
didn't pan out:

You might well get a clue simply from the name of the load module, as 
"module prefixes" are pretty carefully managed by most.
The prefix might not tell you all you want to know but will at least 
usually get you to the owning company who could then provide more granular 
info.

I'm not sure how accessible to the general public is the list of module 
prefixes vs owning company, but the information is available as a last 
resort.

Peter Relson
z/OS Core Technology Design


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

Re: Logrec Analysis

[Tom Conley]

On 5/19/2016 4:06 AM, Jake Anderson wrote:

Hi,

One of our sandbox system took an outage, During the Outage period I found
the below messages in Logrec.

ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84




MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA





PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000

the failing CSECT is CNZM1RM


I am unable to get the explanation for the abend S077 in the manual.



Jake,

From the MVS System Codes (Fine) Manual:

077
Explanation: While the system was processing a
console service request, an error occurred.
Register 15 contains a hexadecimal error code in the
format . The fields in this error code are the
following:
 This halfword is for IBM internal use only.
 This halfword is the unique reason code
identifier. Only  is listed below.
The following are the  values and their meanings

You need R15, then you can finger out what went wrong.

Regards,
Tom Conley

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

Re: GDG retention

[Vernooij, CP (ITOPT1) - KLM]

What is the 'no days' parameter?
Yes, retention periods in days are an attribute of the managementclass and your 
storage administrators can tell you how this is implemented at your site. Be 
aware that both SMS retention and GDG limit work, so if you want only the SMS 
retention to be effective, you must alter the GDG limit to is maximum: 255.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: 19 May, 2016 11:52
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDG retention

Hi,

Since these GDG were defined with No days Parmeter, So i assume this can be
deleted can be anytime. Is there a way to determine the retentions of this
GDG ? I hope My storage administrators can answer ?

Any suggestions ?

On Thu, May 19, 2016 at 3:08 PM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> No, 14 versions/members. When G0015v00 is created, G0001V00 is deleted.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: 19 May, 2016 11:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: GDG retention
>
> Hello,
>
> We have some GDG getting created during the SMF processing. Is there a way
> to determine its retention ?
>
> I see the value for GDG as LIM 14. Does that mean the retention would be 14
> days ?
>
> Nathan
>
> --
> 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
>

--
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: GDG retention

[Nathan Astle]

Hi,

Since these GDG were defined with No days Parmeter, So i assume this can be
deleted can be anytime. Is there a way to determine the retentions of this
GDG ? I hope My storage administrators can answer ?

Any suggestions ?

On Thu, May 19, 2016 at 3:08 PM, Vernooij, CP (ITOPT1) - KLM <
kees.verno...@klm.com> wrote:

> No, 14 versions/members. When G0015v00 is created, G0001V00 is deleted.
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: 19 May, 2016 11:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: GDG retention
>
> Hello,
>
> We have some GDG getting created during the SMF processing. Is there a way
> to determine its retention ?
>
> I see the value for GDG as LIM 14. Does that mean the retention would be 14
> days ?
>
> Nathan
>
> --
> 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
>

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

Re: GDG retention

[Vernooij, CP (ITOPT1) - KLM]

No, 14 versions/members. When G0015v00 is created, G0001V00 is deleted.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: 19 May, 2016 11:33
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GDG retention

Hello,

We have some GDG getting created during the SMF processing. Is there a way
to determine its retention ?

I see the value for GDG as LIM 14. Does that mean the retention would be 14
days ?

Nathan

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

GDG retention

[Nathan Astle]

Hello,

We have some GDG getting created during the SMF processing. Is there a way
to determine its retention ?

I see the value for GDG as LIM 14. Does that mean the retention would be 14
days ?

Nathan

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

Re: Logrec Analysis

[Lucas Rosalen]

Complete description of S077 can be found here:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieah700/m014885.htm

Regards,

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com
*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +48 (71) 792 809 198


2016-05-19 11:08 GMT+02:00 Edward Finnell <
000248cce9f3-dmarc-requ...@listserv.ua.edu>:

> Yep. CNZ definitely console. R15  where  is return code.
>
>
> In a message dated 5/19/2016 4:02:23 A.M. Central Daylight Time,
> rreyno...@cix.co.uk writes:
>
> I am  rusty, but I think I saw this from a product trying to allocate  a
> console.
>
>
> --
> 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: Logrec Analysis

[Edward Finnell]

Yep. CNZ definitely console. R15  where  is return code.
 
 
In a message dated 5/19/2016 4:02:23 A.M. Central Daylight Time,  
rreyno...@cix.co.uk writes:

I am  rusty, but I think I saw this from a product trying to allocate  a
console.


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

Re: Logrec Analysis

[Rupert Reynolds]

I am rusty, but I think I saw this from a product trying to allocate a
console.
On 19 May 2016 9:06 a.m., "Jake Anderson"  wrote:

> Hi,
>
> One of our sandbox system took an outage, During the Outage period I found
> the below messages in Logrec.
>
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
> ABEND S077  PSW 070C1000 84
>
>
>
>
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
> MODULE CNZINLPA
>
>
>
>
>
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
> PSW 070C1000
>
> the failing CSECT is CNZM1RM
>
>
> I am unable to get the explanation for the abend S077 in the manual.
>
> Can someone please point ?
>
> Jake
>
> --
> 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: Logrec Analysis

[Elardus Engelbrecht]

Jake Anderson wrote:

>One of our sandbox system took an outage, During the Outage period I found the 
>below messages in Logrec.

>ABEND S077  PSW 070C1000 84
>MODULE CNZINLPA
>PSW 070C1000

>the failing CSECT is CNZM1RM

Please post the SYSLOG messages during that abend. What is the Register 15 
content?

>I am unable to get the explanation for the abend S077 in the manual.

Did you searched the IBM Knowledge Center Website?

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

Logrec Analysis

[Jake Anderson]

Hi,

One of our sandbox system took an outage, During the Outage period I found
the below messages in Logrec.

ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84
ABEND S077  PSW 070C1000 84




MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA
MODULE CNZINLPA





PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000
PSW 070C1000

the failing CSECT is CNZM1RM


I am unable to get the explanation for the abend S077 in the manual.

Can someone please point ?

Jake

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

Re: Old OS/390 1.3 loading in z890

[Brian Westerman]

You cannot have any "specialty" engines active when you IPL an OS that doesn't 
support them.  You will need to disable them via the HMC before the IPL.  There 
is another setting that sets the arch level, but I don't think that is your 
(current) problem.  When the 890 first came out, we had some clients still 
running the very old OS/390 versions, and we found that we had to disable any 
processor that was not configured as a normal processor to get past this 
problem.  I'm not even sure that IFL's were supported then.

Brian

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