A List management question

[J O Skip Robinson]

I may need to change my email address for IBM Main purposes. I know how to turn 
mail on and off. How do I change the address? 

BTW I may soon be needing to use a new address for all communication, not just 
the List. Please see below. 

Another BTW I'm sending this note as plain text with no HTML. Still Outlook. 
Does it look any better?

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

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

Re: HCD Switch Report

[J O Skip Robinson]

I can't really contribute to answering the original question because I've never 
tried it. At this shop we use HCM, which gives a comprehensive graphical 
representation of everything included in the IODF, including switch 
connections. I highly recommend it despite the obvious learning curve.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Wednesday, December 09, 2015 6:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: HCD Switch Report

If you're interfacing with ISPF programmes then ISPEXEC SELECT works, as well. 
I've done it for years. Of course, you have to have a valid ISPF environment 
set up.

-
-teD
-
  Original Message
From: Ravi Gaur
Sent: Wednesday, December 9, 2015 05:12
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: HCD Switch Report

The only way given in manual is to load this program "CBDMGHCP" via rexx is 
ATTACH or LINK and tried both however doesn't seems to work.ISPEXEC SELECT 
PGM doesn't work ...

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

JES2/3 Initialization member not reflecting current running system was Re: Inquire intrdr default job class

[J O Skip Robinson]

I would be more than happy with a report showing any inconsistencies between 
the running JES2 and the actual values coded in a user-selectable init deck. 
Let me decide how to resolve differences, when to do it, and by whom. As I said 
earlier, possibly fatal differences could hide for years until the next cold 
start.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Tuesday, December 08, 2015 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):JES2/3 Initialization member not reflecting current running 
system was Re: Inquire intrdr default job class

On 8 Dec 2015 14:27:38 -0800, in bit.listserv.ibm-main you wrote:

>Professor Skip assumes that it will be done wrong--at least in execution. 
>Unless the design anticipates and properly handles all execution flubs, then 
>the design is wrong. What could go wrong? 
>
>-- A faulty command is issued. If the update is echoed to the control file, 
>the component (JES2 in this thread) might fail to come up or at least work 
>properly at IPL time.
>
>-- A command is issued by an operator who may not even have READ access to 
>JES2 parms, yet the content is written into the control file.
>
>-- Two or more commands are issued in quick succession--maybe by different 
>people. What gets echoed to the control file?
>
>If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
>that many would be enthusiastic.  

As someone who did his last system programming with responsibility for JES over 
25 years ago, I feel equally nervous about have a JES modified substantially 
from the initialization member settings by command where this situation 
persists over years.  There should be some mechanism to bring initialization 
deck in line with the current operation parameters.  One possibility would be a 
option in both JES2 and JES3 to create an initialization member from the 
settings in the current running system.

Clark Morris
>
>.
>.
>.
>J.O.Skip Robinson
>Southern California Edison Company
>Electric Dragon Team Paddler
>SHARE MVS Program Co-Manager
>626-302-7535 Office
>323-715-0595 Mobile
>jo.skip.robin...@sce.com
>OR
>jo.skip.robin...@att.net
>OR
>jo.skip.robin...@gmail.com
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Paul Gilmartin
>Sent: Tuesday, December 08, 2015 9:29 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: Inquire intrdr default job class
>
>On 2015-12-08, at 10:05, J O Skip Robinson wrote:
>
>> When you're the only kid in the toy store, you have free reign. Even z HMC 
>> uses the 'write-back' function for tuning updates. But z/OS is a complex 
>> shared environment. You can't allow random process-altering commands to 
>> update common control data sets. Recipe for chaos. 
>>  
>A professor in a class I took once countered such an argument with:
>
>"Why do you assume it has to be done wrong!?"
>
>Straw man.  A wrong way would be for a sysadmin with a Windows-geek 
>orientation to:
>
>o FTP a PARMLIB member to a desktop.
>o Edit it with Notepad.
>o FTP it back.
>
>In fact, it's wrong only if two of them do it at once.
>
>ISPF EDIT has some effective techniques for serializing updates to PDS 
>members, precluding two programmers' editing the same member simultaneously.  
>Certainly an interactive tool with a "Save as Default" capability is less 
>chaotic than handwritten notes to operators, "When you IPL, be sure to issue 
>all the following SET commands ..."
>It seems to me that having a "... great many changes ... now made simply by 
>command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
>commands are embedded in a script automatically run at IPL.
>> 
>> 
>> On 2015-12-07 09:58, J O Skip Robinson wrote:
>>> Gil's point raises an issue more critical than just the question at hand. 
>>> Once upon a time, 'reading JES2 parms' would have been a reasonable 
>>> strategy in general for determining how JES2 runs. Since the advent of 
>>> pervasive dynamic changes, however, the init deck as coded is no longer a 
>>> reliable window into JES2 processing. A great many changes are now made 
>>> simply by command. Old values are ignored on hot start and in many cases 
>>> even on all-system warm start. Only a cold start will reinstate coded parm 
>>> values t

Re: Mime digests [was: IBM-MAIN Digest [snip]]

[J O Skip Robinson]

Ouch. I've been (gently) scolded for failing to remove the execrable 'External' 
carbuncle attached nowadays to all email subject lines coming from outside. But 
I have not heard about Unicode problems. I can try setting 'simple text' 
instead of default HTML. Will that help? 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 08, 2015 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Mime digests [was: IBM-MAIN Digest [snip]]

On Tue, 8 Dec 2015 19:19:28 -0500, Ed Finnell wrote:

>FWIW:The web interface at listserv.ua.edu/archives/ibm-main.html has 
>the threaded option by subject  or author. Also has interactive search  
>interface.
>
... but try following up to a message by R.S. or Skip Jo with base64 Unicode.

-- gil


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

Re: Inquire intrdr default job class

[J O Skip Robinson]

When you're the only kid in the toy store, you have free reign. Even z HMC uses 
the 'write-back' function for tuning updates. But z/OS is a complex shared 
environment. You can't allow random process-altering commands to update common 
control data sets. Recipe for chaos. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 07, 2015 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On 2015-12-07 09:58, J O Skip Robinson wrote:
> Gil's point raises an issue more critical than just the question at hand. 
> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
> in general for determining how JES2 runs. Since the advent of pervasive 
> dynamic changes, however, the init deck as coded is no longer a reliable 
> window into JES2 processing. A great many changes are now made simply by 
> command. Old values are ignored on hot start and in many cases even on 
> all-system warm start. Only a cold start will reinstate coded parm values 
> that might actually be years out of date.
> 
> There is today no substitute for a display command with full detail. 
> 
More modern systems, often on desktops, have similar dynamic change facilities. 
 However they often have a "Save as Default" checkbox which does the equivalent 
of writing the changes back to the init deck and making them persistent.

-- gil


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

Re: RLS implementation for CDS's in DFHSM

[J O Skip Robinson]

I can't speak for catalog, but RLS for HSM CDS gave us a huge boost in 
performance. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, December 08, 2015 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RLS implementation for CDS's in DFHSM

RLS does require CF (coupling facility).
Not everyone has CF.
Assuming one get internal CF for free, there's still effort to transform 
monoplex to parallel sysplex (even single-member one). And the risk of outage 
when something goes wrong.

Q: What is the performance gain from having Catalog in RLS?


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-12-08 o 13:56, Vernooij, CP (ITOPT1) - KLM pisze:
> Is RLS really so few used or so scary?
>
> I remember a quote from a z/OS course where RLS for Catalogs was introduced. 
> The Catalog people asked the VSAM people all kinds of questions because they 
> were afraid of consequences. The VSAM people replied: come on, your catalog 
> is only a KSDS, so why are you afraid of RLS? Thereby implying that RLS is so 
> common and reliable that nobody should worry about it anymore.
>
> Is it that common and reliable?
>
> Kees.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Kenneth J. Kripke
> Sent: 08 December, 2015 9:38
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RLS implementation for CDS's in DFHSM
>
> This is an inquiry to see if there are shops that have implemented Record
> Level Sharing for their CDS's in DFHSM.
>
> 1.   Concerns are how frequent have other shops experienced failures in
> the SMSVSAM asid.
>
> 2.   Do you have multiple ARCMDxx members to cover in the event of an
> SMSVSAM outage?
>
> 3.   Have you had to go through a recovery scenario due to an SMSVSAM
> outage?
>
>   
>
>   
>
> Sincerely;
>
>   
>
> Kenneth J. Kripke
>
>   
>
> Kenneth J. Kripke
>
> k.kri...@comcast.net

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

Re: Inquire intrdr default job class

[J O Skip Robinson]

Professor Skip assumes that it will be done wrong--at least in execution. 
Unless the design anticipates and properly handles all execution flubs, then 
the design is wrong. What could go wrong? 

-- A faulty command is issued. If the update is echoed to the control file, the 
component (JES2 in this thread) might fail to come up or at least work properly 
at IPL time.

-- A command is issued by an operator who may not even have READ access to JES2 
parms, yet the content is written into the control file.

-- Two or more commands are issued in quick succession--maybe by different 
people. What gets echoed to the control file?

If you take a poll of sysprogs on whether to implement this mechanism, I doubt 
that many would be enthusiastic.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, December 08, 2015 9:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On 2015-12-08, at 10:05, J O Skip Robinson wrote:

> When you're the only kid in the toy store, you have free reign. Even z HMC 
> uses the 'write-back' function for tuning updates. But z/OS is a complex 
> shared environment. You can't allow random process-altering commands to 
> update common control data sets. Recipe for chaos. 
>  
A professor in a class I took once countered such an argument with:

"Why do you assume it has to be done wrong!?"

Straw man.  A wrong way would be for a sysadmin with a Windows-geek orientation 
to:

o FTP a PARMLIB member to a desktop.
o Edit it with Notepad.
o FTP it back.

In fact, it's wrong only if two of them do it at once.

ISPF EDIT has some effective techniques for serializing updates to PDS members, 
precluding two programmers' editing the same member simultaneously.  Certainly 
an interactive tool with a "Save as Default" capability is less chaotic than 
handwritten notes to operators, "When you IPL, be sure to issue all the 
following SET commands ..."
It seems to me that having a "... great many changes ... now made simply by 
command ..." is equally a "[r]ecipe for chaos."  Only slightly less so if the 
commands are embedded in a script automatically run at IPL.
> 
> 
> On 2015-12-07 09:58, J O Skip Robinson wrote:
>> Gil's point raises an issue more critical than just the question at hand. 
>> Once upon a time, 'reading JES2 parms' would have been a reasonable strategy 
>> in general for determining how JES2 runs. Since the advent of pervasive 
>> dynamic changes, however, the init deck as coded is no longer a reliable 
>> window into JES2 processing. A great many changes are now made simply by 
>> command. Old values are ignored on hot start and in many cases even on 
>> all-system warm start. Only a cold start will reinstate coded parm values 
>> that might actually be years out of date.
>> 
>> There is today no substitute for a display command with full detail. 
>> 
> More modern systems, often on desktops, have similar dynamic change 
> facilities.  However they often have a "Save as Default" checkbox which does 
> the equivalent of writing the changes back to the init deck and making them 
> persistent.

-- gil

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

Re: Inquire intrdr default job class

[J O Skip Robinson]

Gil's point raises an issue more critical than just the question at hand. Once 
upon a time, 'reading JES2 parms' would have been a reasonable strategy in 
general for determining how JES2 runs. Since the advent of pervasive dynamic 
changes, however, the init deck as coded is no longer a reliable window into 
JES2 processing. A great many changes are now made simply by command. Old 
values are ignored on hot start and in many cases even on all-system warm 
start. Only a cold start will reinstate coded parm values that might actually 
be years out of date.

There is today no substitute for a display command with full detail. 



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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, December 07, 2015 7:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Inquire intrdr default job class

On Mon, 7 Dec 2015 16:15:16 +0100, Gabor Hoffer wrote:

>Default jobclass of INTRDR, so before submit.
> 
Might that be available by tediously parsing a PARMLIB member?

-- gil


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

Re: POLICY CHANGE PENDING - DELETE

[J O Skip Robinson]

The reason you had to FORCE these structures is that from the beginning of 
parallel sysplex and CF, disconnected DB2 structures live in a perpetual state 
of 'failed persistent'. Many CF structures are deleted by XCF when their 
exploiters go away. For the sake of DB2 recovery, associated structures never 
go away on their own. You have to hit them with a large, well-aimed hammer. One 
by one. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Monday, December 07, 2015 9:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: POLICY CHANGE PENDING - DELETE

For those that may have wondered, I was able to successfully delete all 
twenty-seven POLICY CHANGE PENDING - DELETE entries using SETXCF 
FORCE,STR,STRNAME=xxx

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Monday, December 07, 2015 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: POLICY CHANGE PENDING - DELETE

You got the right command, go for it.

Lucas
On Dec 7, 2015 15:16, "Richards, Robert B."  wrote:

> I make such infrequent changes to my CF policy that I never remember 
> how to clear the "POLICY CHANGE PENDING - DELETE" condition. I issued 
> a SETXCF START,REALLOCATE command think that would clear it, but it did not.
>
> The entries are for SCA and LOCK structures for DB2 subsystems that no 
> longer exist.
>
> The manual seems to indicate that I should use a SETXCF FORCE, 
> STR,STRNAME= command. Before I try that and shoot myself in the foot, 
> does anyone have a better idea?
>
> Bob


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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

I'm grateful to this thread for the news that MVCIN lives on. When it 
disappeared on the 3090--talk about unexpected S0C1--I did a brief RIP and 
never looked for it again. MVCIN allowed you to reverse a string and use TRT to 
find stuff that would otherwise have required a backwards loop search. Very 
handy.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Tuesday, December 01, 2015 6:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

In
<sn1pr0101mb1520a1ecdd98150f6c931ef3ce...@sn1pr0101mb1520.prod.exchangelabs.com>,
on 12/01/2015
   at 10:57 PM, J O Skip Robinson <jo.skip.robin...@sce.com> said:

>MVCIN was indeed a useful instruction. I encountered it (IIRC) on a 
>4381. I assumed that, like typical new instructions, it would stick 
>around for the duration. I was later shocked to discover that it had 
>been abandoned on a siding somewhere along the railway to the future.
>Probably still there somewhere in Nebraska with a smudged bar code. 

It's present in ECPS:VSE PoOps, XA PoOps, ESA/370 PoOps, ESA/390 PoOps and z 
PoOps; that looks like sticking around to me. I don't know what the story is on 
the 3090.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT

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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[J O Skip Robinson]

One urban legend (not necessarily fiction) is an explanation for the curious 
layout in EBCDIC coding. We have

A - I as C1 - C9
J - R as D1 - D9
S - Z as E2 - E9

Of course there is one more hex value in the neighborhood than there are 
letters in English, but why jump from D9 to E2 instead of using E1 - E8? The 
story I heard in computer school is that the EBCDIC ultimately derived from the 
punch card layout. To represent a letter, a card required both a 'zone' punch 
in one of the first three rows at the top plus a 'digit' punch further down in 
the same column. The first group of letters used the top zone row and so on 
through the alphabet. The last group of letters worked off the third zone row. 
The story goes that early punch equipment and card stock were imprecise and 
flimsy. In order to avoid having to deal with two vertically adjacent 
punches--third zone row plus first digit row--the code was constructed to skip 
the 1 digit for the letter S. Since a gap was needed anyhow, this was the ideal 
place for it. 

I love this story too much to challenge it.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, December 02, 2015 8:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

On Wed, 2 Dec 2015 10:02:01 -0600, Dana Mitchell wrote:

>On Tue, 1 Dec 2015 23:03:59 +0000, J O Skip Robinson wrote:
>
>>(This whole season feels like Friday.) A doughnut, on the other hand, 
>>requires the hole for its very definition. The hole supplies no mass or 
>>nutritional value, but without it the thing is not a doughnut. By contrast a 
>>punch card requires the solid part to give the holes meaning; they would 
>>otherwise collapse into gibberish. 
>
>In school we verified that if you multi-punch every possible punch out 
>of a card, the result is indeed very fragile.  But it was fun to dupe
> 
This could inspire a Retro engineering project:  Given the constraint of 
required mechanical strength, devise an encoding that maximizes information 
density.  Akin to GCR:

https://en.wikipedia.org/wiki/Group_code_recording

(How much does the hole diminish the mechanical strength of the bagel?)

-- gil


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

Re: User Cats and Replication Sites

[J O Skip Robinson]

I'm a little curious about whether you defined aliases to the IMPORTed catalog. 
As I mentioned, we do this sort of thing a lot for master catalogs, but I don't 
recall doing it for a user catalog that probably has aliases on the original 
system. Aliases can be a problem when sharing a user catalog because of the 
likelihood of duplicates. A given alias can resolve only one way. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, December 02, 2015 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

Thanks to all the input.
We have successfully replicated the catalog to our alternate site and was able 
to IMPORT CONNECT it and use it.

This will make our new process successful.  Since I have a tendency to over 
think processes, this was very helpful.

Thank you very much Skip.

Lizette


> -Original Message-
> From: Lizette Koehler [mailto:stars...@mindspring.com]
> Sent: Wednesday, November 25, 2015 12:59 PM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: User Cats and Replication Sites
> 
> To try and answer the question : Why do this?
> 
> If you do normal dumps/unloads of production data and ship it to your 
> DEV/QA/Lifecycle environment - you might use productions like NDM, 
> FTP, IND$FILE, etc... slow and dependent on your IP traffic or pipes.  
> Or you might
dump
> to tapes and either mail physical tape or have your tape environment 
> use its
own
> replication process.
> 
> With Replication you could land your data needed in the lifecycle 
> environment
and
> use the speed of Replication.  So, just pushing the data to a new 
> location
faster.
> 
> Skip - This is what I was thinking.  I tend to over think, so this is 
> very
helpful.
> 
> Thanks all very much
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson
> > Sent: Wednesday, November 25, 2015 11:09 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: User Cats and Replication Sites
> >
> > (Reposting with edited subject. Sorry that I forget to massage it so
> > often.)
> >
> > In order to make a 'foreign' catalog available, I don't believe you 
> > DEFINE RECAT because the catalog already exists. IMPORT CONNECT 
> > (whereby you name the
> > volume) creates all the necessary pointers in the current system's 
> > master
catalog.
> > Furthermore, IMPORT CONNECT does not require that the catalog be 
> > physically accessible. CATALOG task does not attempt to access the 
> > catalog until you perform some action that requires opening it, such 
> > as LIST. If the catalog is available, the catalog is opened and the 
> > action completes. Otherwise you get a catalog open error. I'm basing 
> > these observations on experience with making various master catalogs 
> > available to each other, which we do a lot. The foreign catalog 
> > becomes a
'user
> catalog' in the current master regardless of its status in the foreign system.
> >
> > So in the steps you propose, eliminate 3. Step 4 can be done at any 
> > time even if the volume is (still) offline; even now. Assuming that 
> > you IMPORT CONNECT ahead of time, you're left with 1, 2, and 5. As 
> > for aliases--if you want them--you can DEFINE ALIAS at any time 
> > after IMPORT
> CONNECT.
> >
> > .
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 626-302-7535 Office
> > 323-715-0595 Mobile
> > jo.skip.robin...@sce.com
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S.
> > Sent: Wednesday, November 25, 2015 2:33 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: User Cats and Replication Sites
> >
> > As far as I udnerstand you replicate UCAT, but cataloged datasets 
> > (volumes with datasets).
> > I don't see any value in such approach. What's your goal?
> >
> > Note: it could worth to consider to replicate a set of datasets and UCAT.
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
> >
> >
> >
> > W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> > > I have two sites, A and B

Re: User Cats and Replication Sites

[J O Skip Robinson]

This looks like a great idea. Not sure how it might impact or be impacted by 
XRC, but it would be worth a look. Can't tell you how much grief we went 
through after usercats began dropping like flies. Fortunately it was DEV and 
not PROD, but lots of folks had their work disrupted for days on end. ;-( 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ron Hawkins
Sent: Wednesday, December 02, 2015 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

Skip,

Is there a case here for taking regular snapshots of your UCATs and other small 
critical datasets?

Using persistent FlashCopy the UCATs or their volumes could be copied every 
hour and retained for quick receovery.

30 days' worth of hourly copies of a 1000 Cyl UCAT would use less than 1GB of 
space. Persistent FC would give you a good backup in both sites.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] User Cats and Replication Sites

Touche. We had a near catastrophic catalog problem some time back. Of course 
the replicated copy faithfully mirrored the errors, which were procedural 
rather than structural--tons of vital data deleted by mistake. Still I value 
mirroring for the classic case of disaster recovery: the production data center 
suddenly goes offline and cannot be resuscitated within an acceptable window. 
Mirrored DR allows you get up and running quickly, warts and all.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Wednesday, November 25, 2015 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

On Wed, 25 Nov 2015 20:53:09 +, J O Skip Robinson wrote:

>Nothing beats replication, the more the better. 

Hmmm - unless you happen to have a critical error in the source. Replicating 
that quietly everywhere can leave you with non-IPLable systems *everywhere*.
Which you may not find out about until you try an IPL.
And yes, it has happened - LE bug that broke MCAT access for example; ran fine 
till IPL.
Brings to mind the "Schrodingers backup" discussion a few months back.

Shane ...


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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

Timeframe was 1980 plus or minus. I was a true novice sysprog and kept an arm's 
length from OS innards. It was during that two-year gig that MVS/SP was 
announced, so not likely available just yet. I only remember being impressed 
with the clever workaround that kept the Amdahl useful. 

P.S. The same machine had a load button on the system keyboard. One day an 
operator's purse fell over and caused a midmorning IPL. Amdahl installed a 
little box around the button. They were clever folks. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Tuesday, December 01, 2015 7:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

On Tue, 1 Dec 2015 12:52:05 +, Bob Shannon wrote:

>> Amdahl responded by shipping some code that was loaded early in IPL 
>>to accommodate the new instructions
> 
>SE and SP Assist. They trapped the abend in the FLIH. I remember it well.

That's SE Assist. And it led to the design on the 580 series of computers that 
provided a third state of operation called (IIRC) System state. The 580 design 
included hardware to virtualize the user's processor.

The code that ran in System state was called Macrocode and it was loaded from 
the console processor into memory that was outside of the memory available to 
customers. Macrodode routines emulated new instructions.

A side benefit of all that was that it made Multiple Domain Facility possible. 
The hardware that supported the virtualization included additional registers 
for the use of Macrocode and other facilities that made MDF quite efficient.

--
Tom Marchant


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

Re: What's a "ton" of JCL? [was:RE: Straightforward way to determine hardware architecture level?]

[J O Skip Robinson]

(This whole season feels like Friday.) A doughnut, on the other hand, requires 
the hole for its very definition. The hole supplies no mass or nutritional 
value, but without it the thing is not a doughnut. By contrast a punch card 
requires the solid part to give the holes meaning; they would otherwise 
collapse into gibberish. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barry Merrill
Sent: Tuesday, December 01, 2015 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What's a "ton" of JCL? [was:RE: Straightforward way to 
determine hardware architecture level?]

I think a box of 2000 IBM cards is on the order of 6 pounds, so a TON of JCL 
cards would be 333 boxes, or about 666,666 card images.

But, the useful weight is zero, since we only use the holes.

Barry


Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229-5112
ba...@mxg.com
Fax:  214 350 3694 - Still works, received as email
Tel:  214 351 1966 - Unreliable, please use email

www.mxg.comHomePage: FAQ answers most questions
ad...@mxg.com  License Forms, Invoice, Payment, ftp information
supp...@mxg.comTechnical Issues 
MXG-L FREE ListServer  http://www.mxg.com/mxg-l_listserver/



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Tuesday, December 01, 2015 1:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: What's a "ton" of JCL? [was:RE: Straightforward way to determine 
hardware architecture level?]

Re: "ton" of JCL, at least one large shop of my prior acquaintance (20 or so 
years ago) had over 250,000 members in the production applications JCL 
libraries.

Not sure how much of that was obsolete at the time, but the batch operations 
control product they used had vast quantities of data as well.

I think that counts as a "ton" or 2 . . . :)

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Tuesday, December 01, 2015 9:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?



. . . migrating from Cobol 4 to Cobol 5 without changing a ton of JCL (how much 
JCL is a "ton" anyway?).

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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

MVCIN was indeed a useful instruction. I encountered it (IIRC) on a 4381. I 
assumed that, like typical new instructions, it would stick around for the 
duration. I was later shocked to discover that it had been abandoned on a 
siding somewhere along the railway to the future. Probably still there 
somewhere in Nebraska with a smudged bar code. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Tuesday, December 01, 2015 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

On 12/01/2015 10:27 AM, Tom Marchant wrote:
> On Tue, 1 Dec 2015 12:52:05 +, Bob Shannon wrote:
>
>>> Amdahl responded by shipping some code that was loaded early in IPL 
>>> to accommodate the new instructions
>>
>> SE and SP Assist. They trapped the abend in the FLIH. I remember it well.
>
> That's SE Assist. And it led to the design on the 580 series of 
> computers that provided a third state of operation called (IIRC) 
> System state. The 580 design included hardware to virtualize the user's 
> processor.
>
> The code that ran in System state was called Macrocode and it was 
> loaded from the console processor into memory that was outside of the 
> memory available to customers. Macrodode routines emulated new instructions.
>
> A side benefit of all that was that it made Multiple Domain Facility possible.
> The hardware that supported the virtualization included additional 
> registers for the use of Macrocode and other facilities that made MDF quite 
> efficient.
>
If I remember correctly, that led to FAM (a part of Macrocode), Fast Assist 
Mode. It allowed Amdahl to emulate instructions rather rapidly -- both on the 
machine and building the instruction emulation to install on machines.

I do remember a very interesting thing that Amdahl did: MVCIN

It was implemented on those machines, but not on the IBM 3090s. 
Which caused me a problem on a VSE to MVS migration, because I needed that 
inverse move. When I was working at Amdahl I was amazed at how that had been 
implemented.

I miss those days.

Regards,
Steve Thompson


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

Re: IBM Automatic (COBOL) Binary Optimizer Now Availabile

[J O Skip Robinson]

In early discussions of this facility at SHARE, several customers owned up to 
the iffy practice of sharing load libraries across boundaries such that shared 
PDSEs would be unworkable. This practice is fixable, of course, but a 
considerable amount of work might be required in the application migration 
procedure. I don't think anyone complained about the additional storage 
allocations for multiple load libraries, merely that SOP would have to be 
rewritten in order to ship module ABC to multiple non-sharing systems.  

For shops that already have unique load libraries, there is no issue because 
migration procedures are all set. APO can be implemented without upending 
migration procedures all at once. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 30, 2015 4:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM Automatic (COBOL) Binary Optimizer Now Availabile

Here is the deal. Here is why the ABO. I am going to do this without reference 
to materials, and some of the details are NDA anyway, but let me give this a 
very general shot.

For years IBM was able to sell new boxes by saying "Mr. CIO, your batch window 
is shrinking? No problem, buy our new mainframe and all your COBOL will run 30% 
faster." (Gross oversimplification, but bear with me.) Now CMOS is no longer 
getting any faster. Not Z CMOS, not Intel CMOS. Barring an outside the box 
breakthrough that is not expected, CMOS is not going to get 30% faster. Look 
back at the mainframe model performance numbers. Each box is 30 to 100% faster 
than the one that came before ... until roughly the z12. They aren't getting 
significantly faster anymore. So you can't sell mainframes with "your COBOL 
will automatically run faster."

Now, in a sense, mainframes ARE getting faster. More cache. Higher real memory 
limits and for Z, dramatically lowered memory prices. That processor 
multi-threading thing. But especially, new instructions that are inherently 
faster than the old way of doing things. Load and store on condition are the 
i-cache's dream instructions! Lots and lots of new "faster way to do things" 
instructions on the z12 and z13.

But in order to take advantage of those new instructions, two things have to 
happen: (a.) IBM had to release a dramatically improved COBOL compiler (they 
did) and (b.) Mr. CIO has to recompile everything. But Mr. CIO has either lost 
the source code, or does not know if his source code corresponds to his 
production loadlibs, or Mr. CIO has laid off all the programmers and there is 
no one to re-compile and re-test.

Enter the ABO ...

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Monday, November 30, 2015 3:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM Automatic (COBOL) Binary Optimizer Now Availabile

On Mon, 30 Nov 2015 22:43:37 +, Gibney, David Allen,Jr wrote:

>And it doesn't stick you with the requirement for the loadlib to be PDS/E...

;0)
I wonder if this hasn't been such an impediment to V5 take-up that it enabled a 
business case to be built to release the ABO.
So, what could possibly be the basis of the funding for this - maybe a future 
enforcing of a "ABO or latest version" policy so that the compiler folks can 
issue a restricted support statement like BCP ?.

Cynical ??? ... me ???

Shane ...


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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

I'm reaching back a long way to stretch the notion of 'straightforward', but 
here goes. When I was a novice sysprog, my shop had an Amdahl. MVS at that time 
predated 'system product'. (Way back.) IBM shipped a new level of MVS that 
executed instructions not present our Amdahl. Amdahl responded by shipping some 
code that was loaded early in IPL to accommodate the new instructions. The code 
would trap a S0C1, determine if it were a new instruction, and if so, 'fix' it. 
Some instructions were considered unnecessary; others needed to be simulated. 
Unnecessary instructions were NOOPed in memory; a simulated instruction was 
replaced in memory with a direct branch to the simulation routine. As time went 
on after an IPL, there were fewer and fewer S0C1s to deal with. 

So what about taking a similar approach with an all-architecture product? Write 
it to run on the latest hardware and trap the S0C1s that occur on older 
hardware, then simulate the unexecutable instruction with something 
'traditional'. Whew. Sounds like a lot of work, but you would have a truly 
universal product. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 30, 2015 5:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

Sorry. MSUs are *incredibly* important to some (most?) customers. They are a 
major buy/no-buy decider. I cannot ship z900 code and shrug my shoulders about 
performance on a z13. IBM (as an example) has come to realize that customers 
are not willing to run S/390 instruction set COBOL executables on a z13  -- 
witness the Binary Optimizer. I get paid to be concerned about this stuff and I 
take the responsibility to live my life in a way that avoids ulcers. Shipping 
the source is utterly out of the question, both for intellectual property 
reasons and because at more and more customers even coding a Rexx script is 
beyond the local programming abilities: they could never compile the code 
successfully -- and many are so busy (understaffed?) they would not be willing 
to take the time even if they could.

At some sites we process millions of events per day per LPAR. A millisecond per 
event is thousands of CPU seconds per day. 

> let the responsibility lie with the customer

Customers basically pay us to take that responsibility.

> you will always get an 0C1 if you execute the instruction on a machine
that is incapable of executing that instruction

No argument there! 

Seriously, thanks for your input.

Charles


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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

I get it. There are different meanings of 'architecture level'. You need more 
granularity. Not knowing the ins and outs of the various control blocks 
suggested by others, I would take the KISS approach with a table of supported 
models and what action you would take for each. A substantial but not endless 
list. Inelegant, but easy(ish) to build and maintain. DISPLAY M=CPU gives 
detail on CPC family and model number in various formats. If a match is not 
found in your table, use the highest one you support and issue a warning 
message. You have to determine this at run time because a program could easily 
need to run on a machine higher or lower than one it's compiled on. 

IEE174I 12.15.00 DISPLAY M 245 
PROCESSOR STATUS   
ID  CPU  SERIAL
00  + ss2827   
01  + ss2827   
02  +Iss2827   
03  -  
04  -I 
   
CPC ND = 002827.H43.IBM.02.000ss   
CPC SI = 2827.704.IBM.02.00ss
 Model: H43
CPC ID = 00
CPC NAME = cpc-name 
LP NAME = lpar-name LP ID =  #
CSS ID  = 0
MIF ID  = 1
   
+ ONLINE- OFFLINE. DOES NOT EXISTW WLM-MANAGED 
N NOT AVAILABLE
   
IINTEGRATED INFORMATION PROCESSOR (zIIP)   
CPC ND  CENTRAL PROCESSING COMPLEX NODE DESCRIPTOR 
CPC SI  SYSTEM INFORMATION FROM STSI INSTRUCTION   
CPC ID  CENTRAL PROCESSING COMPLEX IDENTIFIER  
CPC NAME CENTRAL PROCESSING COMPLEX NAME   
LP NAME  LOGICAL PARTITION NAME
LP IDLOGICAL PARTITION IDENTIFIER  
CSS ID   CHANNEL SUBSYSTEM IDENTIFIER  
MIF ID   MULTIPLE IMAGE FACILITY IMAGE IDENTIFIER  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, November 29, 2015 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

I am not a LOADXX guru but  looks like waaay too little 
granularity. It seems to *stop* at ARCHLVL=2, "z Architecture." My OP was 
looking to distinguish *among* recent models -- say z990 to z13.

The basic problem is the C compiler will optimize to give best performance on, 
say, a z196 -- but the resulting code S0C1's on a z10. My boss wants something 
more user-friendly than a S0C1.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Sunday, November 29, 2015 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

I confess to not having slogged through this thread, but from the beginning 
I've wondered why no one has suggested the static system symbol 
System symbols can be queried from pretty much any environment. They're set 
automatically at IPL. Maybe OP needs more detail...

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

Re: Straightforward way to determine hardware architecture level?

[J O Skip Robinson]

I confess to not having slogged through this thread, but from the beginning 
I've wondered why no one has suggested the static system symbol  
System symbols can be queried from pretty much any environment. They're set 
automatically at IPL. Maybe OP needs more detail...

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, November 29, 2015 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Straightforward way to determine hardware architecture 
level?

Two corrections:

1. At several points in this thread I think I may have said "facility bits in 
the CVT." I wuz of course confused. Make that "facility bits in the PSA."

2. My last bullet below is muddled. Make that "before I start relying on
ARCH(12) and therefore need to distinguish it from ARCH(11). As I am currently 
tentatively relying on ARCH(9) I have about six years ..."

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Sunday, November 29, 2015 9:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Straightforward way to determine hardware architecture level?

> Charles Mills has a reason. But part of that reason is that he's 
> running
...

Right. And dealing with imperfect co-workers dealing with imperfect information 
from sales and pre-sales and a boss who says "can't we give them a nice message 
rather than a S0C1?" 

 > I'm actually curious if you can tell at runtime what C/C++ ARCH level was 
 > this module compiled at

Per the U/G, "[The C macro] __ARCH__ is predefined to the integer value of the 
ARCH compiler option." That is what I am using.

> What are you actually trying to accomplish with the tests of the 
> facility
bits to determine machine?

I like Kirk's approach. I have code that works now using CSRSI and a machine 
type lookup table, but I think I am going to switch to  Kirk's approach because
- I think it should work more reliably for zPDT and Hercules. (I know z/OS is 
not licensed for Hercules, but I hear rumors that some people may be running it 
there, and my job is writing code that works, not enforcing IBM's license terms.
- I think it may be a better solution under VM.
- It is a somewhat better approach for the situation where code written and 
shipped today is running on some future IBM machine. My current code says "if 
you don't recognize the type, it must be new and therefore okay." Kirk's 
approach will presumably return ARCH(11) for an ARCH(12) machine. All I need to 
do is update Kirk's code before I start relying on ARCH(13) and therefore need 
to distinguish it from ARCH(12). As I am currently tentatively relying on 
ARCH(9) I have about eight years ...

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

Re: User Cats and Replication Sites

[J O Skip Robinson]

Touche. We had a near catastrophic catalog problem some time back. Of course 
the replicated copy faithfully mirrored the errors, which were procedural 
rather than structural--tons of vital data deleted by mistake. Still I value 
mirroring for the classic case of disaster recovery: the production data center 
suddenly goes offline and cannot be resuscitated within an acceptable window. 
Mirrored DR allows you get up and running quickly, warts and all.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Wednesday, November 25, 2015 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

On Wed, 25 Nov 2015 20:53:09 +, J O Skip Robinson wrote:

>Nothing beats replication, the more the better. 

Hmmm - unless you happen to have a critical error in the source. Replicating 
that quietly everywhere can leave you with non-IPLable systems *everywhere*.
Which you may not find out about until you try an IPL.
And yes, it has happened - LE bug that broke MCAT access for example; ran fine 
till IPL.
Brings to mind the "Schrodingers backup" discussion a few months back.

Shane ...


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

Re: (External):Re: User Cats and Replication Sites

[J O Skip Robinson]

In order to make a 'foreign' catalog available, I don't believe you DEFINE 
RECAT because the catalog already exists. IMPORT CONNECT (whereby you name the 
volume) creates all the necessary pointers in the current system's master 
catalog. Furthermore, IMPORT CONNECT does not require that the catalog be 
physically accessible. CATALOG task does not attempt to access the catalog 
until you perform some action that requires opening it, such as LIST. If the 
catalog is available, the catalog is opened and the action completes. Otherwise 
you get a catalog open error. I'm basing these observations on experience with 
making various master catalogs available to each other, which we do a lot. The 
foreign catalog becomes a 'user catalog' in the current master regardless of 
its status in the foreign system.

So in the steps you propose, eliminate 3. Step 4 can be done at any time even 
if the volume is (still) offline; even now. Assuming that you IMPORT CONNECT 
ahead of time, you're left with 1, 2, and 5. As for aliases--if you want 
them--you can DEFINE ALIAS at any time after IMPORT CONNECT. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, November 25, 2015 2:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

As far as I udnerstand you replicate UCAT, but cataloged datasets (volumes with 
datasets).
I don't see any value in such approach. What's your goal?

Note: it could worth to consider to replicate a set of datasets and UCAT.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> I have two sites, A and B
>
> A usercat is replicated (asynchronously) from Site A to Site B (one way trip)
> The volumes are offline in SITE B and ONLINE in SITE A
>
> I want to use that usercat on Site B at some point.
>
> So my plan is to
> 1) Break Replication
> 2) Vary the replication Volumes online to Site B
> 3) Define  RECAT the USERCAT
> 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT.
> 5) Then access the files and VSAM datasets on SITE B through the replicated
> UCAT.
>
> I am fairly comfortable with an IMPORT CONNECT, but was wondering if there 
> were
> other steps other than ensuring the aliases from Site A to this UCAT are
> available/installed/defined in Site B.
>
>
> Anything I need to be concerned about?
>
> I have discussed a couple of ideas with my team, but wanted to see if there 
> was
> any other wisdom in this group that might help me make this right.
>
> Thanks
>
>
> Lizette Koehler

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

Re: User Cats and Replication Sites

[J O Skip Robinson]

(Reposting with edited subject. Sorry that I forget to massage it so often.)

In order to make a 'foreign' catalog available, I don't believe you DEFINE 
RECAT because the catalog already exists. IMPORT CONNECT (whereby you name the 
volume) creates all the necessary pointers in the current system's master 
catalog. Furthermore, IMPORT CONNECT does not require that the catalog be 
physically accessible. CATALOG task does not attempt to access the catalog 
until you perform some action that requires opening it, such as LIST. If the 
catalog is available, the catalog is opened and the action completes. Otherwise 
you get a catalog open error. I'm basing these observations on experience with 
making various master catalogs available to each other, which we do a lot. The 
foreign catalog becomes a 'user catalog' in the current master regardless of 
its status in the foreign system.

So in the steps you propose, eliminate 3. Step 4 can be done at any time even 
if the volume is (still) offline; even now. Assuming that you IMPORT CONNECT 
ahead of time, you're left with 1, 2, and 5. As for aliases--if you want 
them--you can DEFINE ALIAS at any time after IMPORT CONNECT. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Wednesday, November 25, 2015 2:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

As far as I udnerstand you replicate UCAT, but cataloged datasets (volumes with 
datasets).
I don't see any value in such approach. What's your goal?

Note: it could worth to consider to replicate a set of datasets and UCAT.

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> I have two sites, A and B
>
> A usercat is replicated (asynchronously) from Site A to Site B (one 
> way trip) The volumes are offline in SITE B and ONLINE in SITE A
>
> I want to use that usercat on Site B at some point.
>
> So my plan is to
> 1) Break Replication
> 2) Vary the replication Volumes online to Site B
> 3) Define  RECAT the USERCAT
> 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT.
> 5) Then access the files and VSAM datasets on SITE B through the 
> replicated UCAT.
>
> I am fairly comfortable with an IMPORT CONNECT, but was wondering if 
> there were other steps other than ensuring the aliases from Site A to 
> this UCAT are available/installed/defined in Site B.
>
>
> Anything I need to be concerned about?
>
> I have discussed a couple of ideas with my team, but wanted to see if 
> there was any other wisdom in this group that might help me make this right.
>
> Thanks
>
>
> Lizette Koehler

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

Re: User Cats and Replication Sites

[J O Skip Robinson]

In addition--a point I've made in other threads that touch on 'recovery'--do 
not depend on 'one final step' in production to allow for recovery elsewhere. 
You must assume that production has died an instant and agonizing death. There 
will be *no opportunity* for any further action there. What you get in the 
recovery environment is not a whit (no pun intended) more than what you have 
provided in advance of Armageddon. Nothing beats replication, the more the 
better. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Wednesday, November 25, 2015 12:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

In addition to Lizette's comments - In the traditional Unload, Transmit, Load 
data transfer model you have to wait for the unload to complete before the 
transmit can start (I know Gil - Pipes in Unix can do things that classic MVS 
cant/doesn't). When writing large amounts of data this can induce long delays 
before the transmits can start. By using replication  as soon as the first 
track is written into the replication pool the data starts it journey to the 
remote site. Once the tracks are all synced in the receiving replication pool 
bringing the volumes on line then has the data accessible to the receiving site.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

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




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, November 25, 2015 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: User Cats and Replication Sites

To try and answer the question : Why do this?

If you do normal dumps/unloads of production data and ship it to your 
DEV/QA/Lifecycle environment - you might use productions like NDM, FTP, 
IND$FILE, etc... slow and dependent on your IP traffic or pipes.  Or you might 
dump to tapes and either mail physical tape or have your tape environment use 
its own replication process.

With Replication you could land your data needed in the lifecycle environment 
and use the speed of Replication.  So, just pushing the data to a new location 
faster.

Skip - This is what I was thinking.  I tend to over think, so this is very 
helpful.

Thanks all very much

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of J O Skip Robinson
> Sent: Wednesday, November 25, 2015 11:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: User Cats and Replication Sites
> 
> (Reposting with edited subject. Sorry that I forget to massage it so 
> often.)
> 
> In order to make a 'foreign' catalog available, I don't believe you 
> DEFINE
RECAT
> because the catalog already exists. IMPORT CONNECT (whereby you name 
> the
> volume) creates all the necessary pointers in the current system's 
> master
catalog.
> Furthermore, IMPORT CONNECT does not require that the catalog be 
> physically accessible. CATALOG task does not attempt to access the 
> catalog until you
perform
> some action that requires opening it, such as LIST. If the catalog is
available, the
> catalog is opened and the action completes. Otherwise you get a 
> catalog open error. I'm basing these observations on experience with 
> making various master catalogs available to each other, which we do a 
> lot. The foreign catalog
becomes a
> 'user catalog' in the current master regardless of its status in the 
> foreign
system.
> 
> So in the steps you propose, eliminate 3. Step 4 can be done at any 
> time even
if the
> volume is (still) offline; even now. Assuming that you IMPORT CONNECT 
> ahead of time, you're left with 1, 2, and 5. As for aliases--if you 
> want them--you can
DEFINE
> ALIAS at any time after IMPORT CONNECT.
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Wednesday, November 25, 2015 2:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: User Cats and Replication Sites
> 
> As far as I udnerstand you replicate UCAT, but cataloged datasets 
> (volumes
with
> datasets).
> I don't see any value in such approach. What's your goal?
> 
> Note: it could worth to consider to re

Re: User Cats and Replication Sites

[J O Skip Robinson]

Just be sure you don't let catalog replication resume while the catalog is open 
on the second system. Much carnage will ensue.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, November 25, 2015 11:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: User Cats and Replication Sites

To try and answer the question : Why do this?

If you do normal dumps/unloads of production data and ship it to your 
DEV/QA/Lifecycle environment - you might use productions like NDM, FTP, 
IND$FILE, etc... slow and dependent on your IP traffic or pipes.  Or you might 
dump to tapes and either mail physical tape or have your tape environment use 
its own replication process.

With Replication you could land your data needed in the lifecycle environment 
and use the speed of Replication.  So, just pushing the data to a new location 
faster.

Skip - This is what I was thinking.  I tend to over think, so this is very 
helpful.

Thanks all very much

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of J O Skip Robinson
> Sent: Wednesday, November 25, 2015 11:09 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: User Cats and Replication Sites
> 
> (Reposting with edited subject. Sorry that I forget to massage it so 
> often.)
> 
> In order to make a 'foreign' catalog available, I don't believe you 
> DEFINE
RECAT
> because the catalog already exists. IMPORT CONNECT (whereby you name 
> the
> volume) creates all the necessary pointers in the current system's 
> master
catalog.
> Furthermore, IMPORT CONNECT does not require that the catalog be 
> physically accessible. CATALOG task does not attempt to access the 
> catalog until you
perform
> some action that requires opening it, such as LIST. If the catalog is
available, the
> catalog is opened and the action completes. Otherwise you get a 
> catalog open error. I'm basing these observations on experience with 
> making various master catalogs available to each other, which we do a 
> lot. The foreign catalog
becomes a
> 'user catalog' in the current master regardless of its status in the 
> foreign
system.
> 
> So in the steps you propose, eliminate 3. Step 4 can be done at any 
> time even
if the
> volume is (still) offline; even now. Assuming that you IMPORT CONNECT 
> ahead of time, you're left with 1, 2, and 5. As for aliases--if you 
> want them--you can
DEFINE
> ALIAS at any time after IMPORT CONNECT.
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Wednesday, November 25, 2015 2:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: User Cats and Replication Sites
> 
> As far as I udnerstand you replicate UCAT, but cataloged datasets 
> (volumes
with
> datasets).
> I don't see any value in such approach. What's your goal?
> 
> Note: it could worth to consider to replicate a set of datasets and UCAT.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> 
> 
> W dniu 2015-11-24 o 23:24, Lizette Koehler pisze:
> > I have two sites, A and B
> >
> > A usercat is replicated (asynchronously) from Site A to Site B (one 
> > way trip) The volumes are offline in SITE B and ONLINE in SITE A
> >
> > I want to use that usercat on Site B at some point.
> >
> > So my plan is to
> > 1) Break Replication
> > 2) Vary the replication Volumes online to Site B
> > 3) Define  RECAT the USERCAT
> > 4) Connect the UCAT to my MCAT on SITE B using IMPORT CONNECT.
> > 5) Then access the files and VSAM datasets on SITE B through the 
> > replicated UCAT.
> >
> > I am fairly comfortable with an IMPORT CONNECT, but was wondering if 
> > there were other steps other than ensuring the aliases from Site A 
> > to this UCAT are available/installed/defined in Site B.
> >
> >
> > Anything I need to be concerned about?
> >
> > I have discussed a couple of ideas with my team, but wanted to see 
> > if there was any other wisdom in this group that might help me make this 
> > right.
> >
> > Thanks
> >
> >
> > Lizette Koehler
> 
> -

Re: SMPE apply excluding certain FMID's?

[J O Skip Robinson]

Being able to install maintenance separately can be very important depending on 
your shop's organization and the distribution of duties among (even a small 
number of) folks. I see two classes of components: 

1) Those closely akin to z/OS that install on and migrate with sysres.
2) Those not in category 1, including products managed by other people on their 
own timetable. 

I believe that it's best for category 2 products to be installed in one or more 
zones outside of the common z/OS zone and even ordered separately. For example, 
we tried a while back ordering Omegastuff in the common ServerPac. But some 
Omegamon products here needed to be managed in concert with new CICS or DB2 
releases irrespective of z/OS level. Combining did not work and caused problems 
for other folks. Once components begin cohabitating in a single zone, handling 
them by different rules is complicated, time-consuming, and error prone. 
Omegamon is especially unruly because of the manual (non-SMPE) work needed for 
migration. We went back to ordering and managing Omegamon separately.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, November 23, 2015 8:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):SMPE apply excluding certain FMID's?

I've done that, and it works.  I guess I should have been more clear to Kurt's 
question.  I actually would like to maintenance Omegamon's separately than the 
rest of the Operating system.  The issue is being able to apply general 
maintenance to all other FMID's with the exception of OMEGAMON at my choosing.  
It's not a huge issue, more of general convenience for the folks that will have 
to review Omegamon hold data.
_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: Robert A. Rosenberg [mailto:hal9...@panix.com]
Sent: Thursday, November 19, 2015 8:55 PM
To: IBM Mainframe Discussion List
Cc: Jousma, David
Subject: Re: SMPE apply excluding certain FMID's?

At 14:35 + on 11/19/2015, Jousma, David wrote about Re: SMPE apply 
excluding certain FMID's?:

>Do you really want/need to segregate applying maintenance for the 
>Omegamon suite, or during a maintenance cycle do you simply want to 
>more easily identify the relevant HOLDs just for >Omegamon?  I don't 
>necessarily have in mind a solution for you, but I'm curious what your 
>real goal is.
>
>The latter.

An APPLY CHECK listing your created Omagamon FMIDSET (or the FMIDs) will give 
you this info since only Omegamon SYSMODs will be selected.

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

Re: (External):Re: Were you at SHARE in Seattle? Watch your credit card statements!

[J O Skip Robinson]

None of my cards has been chipified, surprising considering the size of the 
issuing institutions. I shopped yesterday at an upscale supermarket using my 
magstripe card. The clerk pointed out that the card machine included a chip 
reader but allowed that it had not yet been activated, so I would have had to 
swipe a chip card anyway. 

Bank of America offers an online service called ShopSafe, which will generate a 
fictitious number with user-specified expiration date and--most 
important--transaction limit. I almost always use this for online transactions, 
but it offers no solace for in-person use. Sort of reverses the popular view of 
relative security.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joel C. Ewing
Sent: Sunday, November 22, 2015 6:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Were you at SHARE in Seattle? Watch your credit card 
statements!

On 11/21/2015 10:27 AM, Robert A. Rosenberg wrote:
> At 09:04 -0700 on 11/21/2015, Paul Gilmartin wrote about Re: Were you 
> at SHARE in Seattle? Watch your credit card st:
>
>> On 11/21/2015 08:49 AM, Bob Shannon wrote:
  Maybe someone should raise a requirement that the SHARE Hotels 
 credit card system should be secure.
>>>  Seriously Ed? Do you really think a major hotel chain is going to 
>>> tell potential customers their credit card system is insecure?
>>>   
>> Credit card companies are on the verge of providing an incentive by 
>> making vendors liable for fraudulent charges on insecure credit 
>> cards.
>
> That went into effect as of October 1. That is why all the credit 
> cards are being reissued with chips. If a card with a chip is 
> presented to a merchant and the card is swiped in lieu of the chip 
> being read, the merchant is responsible for the fraudulent charge.
>
>>
>> -- gil
>>
>
The biggest incentive was on merchants to get chip-card-capable readers in 
place to avoid higher fraud liability, and at least most of the merchants I 
frequent have complied,  With enough compliance by the merchants (which lowers 
odds of offloading fraud liability to non-complying merchants), there appears 
to be much less incentive for the credit card issuers to hurry up with the new 
cards -- only 1 in 5 of the cards I regularly use have been updated to chip 
technology so far.

-- 
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: (External):Re: Deleting all members of a pds

[J O Skip Robinson]

Can also be accomplished with PDS[85] command or StarTool product. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, November 19, 2015 3:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Deleting all members of a pds

I have installed the CBTTAPE.ORG utility PDSCLEAN for both PDS and PDSE 
datasets an it works very well.  File 693.

Lizette



-Original Message-
>From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Nov 19, 2015 3:51 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Deleting all members of a pds
>
>On 2015-11-19 14:54, Ed Finnell wrote:
>> File 182 on CBT tape contains PDS command. It's a great tool. Can 
>> delete or  delete by mask add space, copy, merge and fix. The 
>> commercial version is Startools from Serena. Has saved my bacon numerous 
>> times.
>>  
> STOW  DCB,,I
>
>I believe (or hope) PDS uses that nowadays, since its older technique, 
>basically zapping the directory, didn't work for PDSE.
>
>> In a message dated 11/19/2015 3:43:17 P.M. Central Standard Time, 
>> johnmattson...@gmail.com writes:
>> 
>> Someone  was asking about deleting all members of a pds.  I just 
>> noticed that  DFSort has a bunch of "samples" one of which includes 
>> how to use ICETOOL to  delete all members of a PDS.  Hope this helps.  
>> Lots of  other neat things in here  too.
>
>I hope it (and IDCAMS) uses STOW.  Deleting members one-by-one can be 
>expensive.
>But if so, first sort in reverse order.
>
>I'm not going to measure timings
>
>-- gil


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

Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

[J O Skip Robinson]

The OUTPUT command (at least here) shows only Held output. XMITted files must 
be in (non-held) Output. If I try to see my file via OUTPUT, I get

IKJ56339I NO HELD OUTPUT FOR JOB my-userid

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Thursday, November 19, 2015 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TSO RECEIVE under UNIX Rexx (was: REXX-question)

How about TSO output command to list all waiting files?

ITschak

ITschak Mugzach
Z/OS, ISV Products and Application Security & Risk Assessments Professional

On Thu, Nov 19, 2015 at 8:33 PM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 19 Nov 2015 12:18:23 -0600, Elardus Engelbrecht wrote:
> >
> >>RECEIVE is extraordinarily ill-suited to automation:
> >>o The user has no a priori control over which spool file will be
> RECEIVEd.
> >>o The user must be present to reply to a prompt.
> >
> >That is very true. JES2 simply gives to you what it seemed to be the
> first. I could not find the reason/algorithm for how RECEIVE and JES2 
> decide what to present to the receiver.
> >
> Deep within the Rexx SDSF API, a program can cause SDSF to ALLOCATE a 
> DSID to a SYS00nnn DD name.  The programmer could use that in RECEIVE 
> INDD(SYS00nnn) (I think; I haven't tried it.), gaining control of what 
> to RECEIVE.
>
> >I recommend using FTP instead of XMIT/RECEIVE for another reason - 
> >Speed
> and no filling up of JES2 spool.
> >
> I like a combination of sftp and pax.
>
> -- gil


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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[J O Skip Robinson]

I can see the relevant fields only on O(utput) screen, not on ST(atus). There 
are actually two significant fields: Dest, which is the target userid, and 
Status, which shows 'USER'. I believe that 'USER' will prevent a JES2 defined 
destid from hijacking the output. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 19, 2015 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 15:23, J O Skip Robinson wrote:
> An XMITted file sits in the JES output queue in a designated class (usually 
> B) with the recipient's userid as DEST.  ... 
> 
So administrators must be careful not to assign User IDs that might match 
plausible DESTs.

Can anyone tell me how to obtain DEST via the Rexx SDSF API?
AFAICT, DEST (or DESTN) is a field on the JDS panel but not on the ST panel, 
and address SDSF supports "isfact ST" but not "isfact JDS".

Thanks,
gil


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

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

I haven't experimented with this, but going with NOSCRATCH is likely to cause 
big problems with DASD GDGs. A data set residing on an SMS-managed volume must 
be cataloged. It cannot just sit there uncataloged. Irresistible force meets 
unmovable object. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:

>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest way 
>to read OLDEST GDG entry:
>
>>you might want to make sure the GDG is defined with NOSCRATCH before 
>>doing this.
>
>Note that NOSCRATCH will (I think) not only leave the V00 of a
>V01->V00 replacement cataloged (as a normally named file with the V01
>being in the GDG base) but also do the same as GDG generations roll off 
>due to the limit. Normally once it rolls you would want it deleted.

Correct. And if you set the GDG to NOSRCATCH before replacing a data set, then 
change the GDG back to SCRATCH, and if a new generation that would have caused 
an old one to roll off is created during the interval, I suspect that old 
generation would have to be scratched manually.

--
Tom Marchant


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

Re: (External):Is there an Standard Size for 3390-27's?

[J O Skip Robinson]

Yes.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Wednesday, November 18, 2015 9:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Is there an Standard Size for 3390-27's?

In
<sn1pr0101mb1520b1e7af45d8e84a4d2023ce...@sn1pr0101mb1520.prod.exchangelabs.com>,
on 11/18/2015
   at 05:19 PM, J O Skip Robinson <jo.skip.robin...@sce.com> said:

>relative to a (mythical?) Mod-1

Mythical? What are the 3390-A14, 3390-A18, 3390-B14, 3390-B18 and 3390-B1C, 
chopped liver?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: (External):Is there an Standard Size for 3390-27's?

[J O Skip Robinson]

Since IBM does define any model larger than a Mod-9, usage of other Mod-xx 
terms is user defined. I would think, however, that the historical derivation 
of model terminology is based on capacity relative to a (mythical?) Mod-1. In 
any case, a Mod-9 is 3x the size of a Mod-3, so I would expect a Mod-27 to be 
3x a Mod-9. Similar consideration for a Mod-54. (Have not heard discussion of 
anything larger.) 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jasi Grewal
Sent: Wednesday, November 18, 2015 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Is there an Standard Size for 3390-27's?

Greetings, I would like to know, if there are any standard sizes for 3390-27's 
because I read different manuals and each of them refers as either 30015 Cyl or 
32760Cyl for Mod 27's.

Would like to hear your setup of Mod 27's and if you are using 30015 or 32760 
Cyl for Mod 27's.
Here's the two manuals that states two different settings for mod 27's:

http://www.scribd.com/doc/51615339/IBM-Mainframe-Disk-Capacity-Table#scribd
http://www.redbooks.ibm.com/redpapers/pdfs/redp4187.pdf

Model Cylinders Tracks Bytes/volume Bytes/track
3390-1 1113 16695 946 MB 56664
3390-2 2226 33390 1.89 GB 56664
3390-3 3339 50085 2.83 GB 56664
3390-9 10017 150255 8.51 GB 56664
3390-27 32760 491400 27.84 GB 56664
3390-54 65520 982800 55.68 GB 56664

Then this manual states 30015 Cylinders:
http://www-01.ibm.com/support/docview.wss?uid=tss1prs4558=1

Thanks in advance,
Regards,

Jasi Grewal.


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

Re: Is there an Standard Size for 3390-27's?

[J O Skip Robinson]

So now I was moved to look at our actual sizes. 

Mod-9: 10016 cyls
Mod-27: 30050 cyls (3x would be 30048 cyls)
Mod-54: 60101 cyls (6x would be 60096 cyls)

I'm not a storage guy; just reporting what I see. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Wednesday, November 18, 2015 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Is there an Standard Size for 3390-27's?

We have 30051 for mod-27, and 60102 for mod-54

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jasi Grewal
Sent: Wednesday, November 18, 2015 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Is there an Standard Size for 3390-27's?

Greetings, I would like to know, if there are any standard sizes for 3390-27's 
because I read different manuals and each of them refers as either 30015 Cyl or 
32760Cyl for Mod 27's.

Would like to hear your setup of Mod 27's and if you are using 30015 or 32760 
Cyl for Mod 27's.
Here's the two manuals that states two different settings for mod 27's:

http://www.scribd.com/doc/51615339/IBM-Mainframe-Disk-Capacity-Table#scribd
http://www.redbooks.ibm.com/redpapers/pdfs/redp4187.pdf

Model Cylinders Tracks Bytes/volume Bytes/track
3390-1 1113 16695 946 MB 56664
3390-2 2226 33390 1.89 GB 56664
3390-3 3339 50085 2.83 GB 56664
3390-9 10017 150255 8.51 GB 56664
3390-27 32760 491400 27.84 GB 56664
3390-54 65520 982800 55.68 GB 56664

Then this manual states 30015 Cylinders:
http://www-01.ibm.com/support/docview.wss?uid=tss1prs4558=1

Thanks in advance,
Regards,

Jasi Grewal.


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

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

This happened some years ago, different incident. We had a nightly job that ran 
on four different parallel sysplexes to [list catalog stuff]. Don’t remember 
the details. Essentially the same job ran on three sysplexes in about 2 
minutes. On the fourth it ran over 20 minutes. I looked at the environments to 
see what was different in molasses world. The only difference I could see was 
that the three speedy sysplexes were set up for GRS star. The fourth, because 
it had only one active member, was still GRS ring. (I was stingy in those days 
with CF storage.) So on a lark I converted Mr. Snail to GRS star. From then on 
the job ran in 2 minutes. Sounds like a tall tale, but it really happened.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Tuesday, November 17, 2015 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

Paul Gilmartin wrote:
> Naively, I'd expect that LISTCAT use CSI, or something very similar.

Years ago a Storage Admin mentioned that his "List every dataset" 
nightly job was running more than an hour.  I was playing around with CSI at 
the time (via assembler) and modified some existing code to list every alias, 
and then every dsn under each alias.  I think the result ran in less than 5 
minutes, so at the time I assumed LISTCAT wasn't calling CSI.  Maybe things 
have changed though.


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

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
issued. This can be problematic when the response cannot be known in advance of 
issuing the command. For example, the data set name to use for RECEIVE may 
depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
the output that contains the data set name, and END without actually receiving 
the data set. Then construct a prompt response based the known data set name, 
QUEUE the appropriate response, and issue RECEIVE again. Might be undoable if 
more than one data set is waiting for RECEIVE.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, November 17, 2015 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

Some example REXX which might be of some help:

/* REXX */
X=OUTTRAP("OUT.","*");
"LISTC ENT('gdg.base.name') ALL"
X=OUTTRAP("OFF")
DSN='?'
DO I=1 TO OUT.0
   IF 'NONVSAM-' <> LEFT(STRIP(OUT.I,'L'),8) THEN ITERATE
   DSN=WORD(TRANSLATE(OUT.I,' ','-'),2)
   LEAVE
END
IF DSN='?' THEN EXIT(12) /* NO DSN FOUND */ "RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person 
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
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: Moving a Sysplex

[J O Skip Robinson]

I remain impressed with Jerry's accomplishment. Our outage was on the order of 
12 hours, but that included time for major network configuration changes and 
for hours of user testing. They had to give thumbs up for staying in the new 
location. Until the move was declared successful, we could not allow any actual 
production work, which would have updated data in a (possibly) throw-away 
location. There was no going back.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Tuesday, November 17, 2015 2:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Moving a Sysplex

Mark

If you look at the Share presentations in Seattle I presented on moving a 
Datacenter (2 sysplexes ) and how we did it.  If you look at that I'd be happy 
to discuss any questions that arise. My windows were only the time it took for 
replication to go consistent and then the times to IPL and verify.

Jerry Whitteridge
Manager Mainframe Systems & Storage
Albertsons - Safeway Inc.
925 738 9443
Corporate Tieline - 89443

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




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 2:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Moving a Sysplex

Thanks for the information. Do you remember how long your outage was? 
We're being told (using one solution) that the outage will be on the order of 
two hours.

Mark Jacobs

> J O Skip Robinson <mailto:jo.skip.robin...@sce.com> November 17, 2015 
> at 2:11 PM Others may know something I don't, but I would answer No. I 
> don't believe you can run a (parallel) sysplex over that distance 
> because of CF link limitations. Furthermore, assuming that you could 
> somehow get one sysplex member sharing across that distance, you would 
> have to switch from using production DASD volumes to GDPS-mirrored 
> volumes. I just don't see how you could do that seamlessly. We 
> performed a multi-sysplex move a couple of years back using 
> essentially GDPS DR procedures, but we took a full outage to 
> accomplish it.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Mark Jacobs - Listserv
> Sent: Tuesday, November 17, 2015 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Moving a Sysplex
>
> Would a GDPS like solution work for moving a sysplex from here to 
> there, where the there is over 1200 miles from here, without taking a 
> sysplex outage?
> --
> Mark Jacobs
> Time Customer Service
> Technology and Product Engineering
>
> The standard you walk past, is the standard you accept.
> Lieutenant General David Morrison
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
> Please be alert for any emails that may ask you for login information 
> or directs you to login via a link. If you believe this message is a 
> phish or aren't sure whether this message is trustworthy, please send 
> the original message as an attachment to 'phish...@timeinc.com'.
>

-- 

Mark Jacobs
Time Customer Service
Technology and Product Engineering

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

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

Re: Moving a Sysplex

[J O Skip Robinson]

Others may know something I don't, but I would answer No. I don't believe you 
can run a (parallel) sysplex over that distance because of CF link limitations. 
Furthermore, assuming that you could somehow get one sysplex member sharing 
across that distance, you would have to switch from using production DASD 
volumes to GDPS-mirrored volumes. I just don't see how you could do that 
seamlessly. We performed a multi-sysplex move a couple of years back using 
essentially GDPS DR procedures, but we took a full outage to accomplish it. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, November 17, 2015 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Moving a Sysplex

Would a GDPS like solution work for moving a sysplex from here to there, where 
the there is over 1200 miles from here, without taking a sysplex outage?
--
Mark Jacobs
Time Customer Service
Technology and Product Engineering

The standard you walk past, is the standard you accept.
Lieutenant General David Morrison

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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[J O Skip Robinson]

An XMITted file sits in the JES output queue in a designated class (usually B) 
with the recipient's userid as DEST. When that user issues RECEIVE, all pending 
XMIT files are presented one by one. For each file, the user can store it, 
delete it, or issue END. END terminates the RECEIVE command without processing 
the current file. You could issue RECEIVE again and get the same files (I'm 
pretty sure) in the same sequence. So on each pass, you could store the next 
file with attributes gleaned from the previous pass and then END. Repeat until 
no more files are presented. 

Pretty kludgy, but it would probably work. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, November 17, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 12:00, J O Skip Robinson wrote:
> Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
> which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
> issued. This can be problematic when the response cannot be known in advance 
> of issuing the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match and 
surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil


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

Re: (External):Re: RSU APPLY

[J O Skip Robinson]

In a memorable scene from Lethal Weapon 3, Mel Gibson and Rene Russo compare 
battle scars. Many of us could easily step into that scene and compete. RSU* 
might represent some of our scars. OTOH RSU* might have prevented some of those 
scars. Maintenance is an art, not a science. There's no magic algorithm. But 
you still need to know exactly how the SOURCEID syntax works. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Monday, November 16, 2015 6:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RSU APPLY

It depends on your objective.  If the objective is to "bring the system 'up to 
RSU1509,'" then:

  SELECT(RSU*) with EXSRCID(all available RSUs later than RSU1509)

...is what you want.  And, I'd hope that is the objective, rather than the 
alternative of installing "only what's in RSU1509 that is eligible for 
selection."  As Kurt points out, RSU* is a better objective from our point of 
view.



Mainframe Mainframe wrote:
> Hi,
>While apply RSU into SMPE, do we need to specify only that 
> particular RSU number in SOURCEID parm or we can use RSU* . For 
> example
>
>
> Currently in our z/OS system we RSU1403 and now we planning to apply
> RSU1509 then in this case, in SOURCEID parameter what we should be 
> specifying
>
> SOURCEID(RSU1509)  or SOURCEID(RSU*) .


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com


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

Re: (External):Re: Applications in a Sysplex/CICSplex

[J O Skip Robinson]

We have an application that utilizes an RYO record locking mechanism. I believe 
that it predates even LPAR, when all CICS regions ran on a single OS image that 
occupied an entire CEC. The locks live in a CSA table, which is great for 
regions running in the same image but problematic for regions running on other 
images. Nonetheless this application was 'parallelized' decades ago and works 
quite well--except when we need to roll the application to another LPAR for 
maintenance or IPL. In that case, the table-owning region is shut down on its 
usual LPAR and brought up on the alternate LPAR. Of course ideally the roll 
should be transparent, but the lock table move imposes two minutes-long outages 
to the application. 

If this table were transformed into a CF lock structure, the application could 
be rolled seamlessly. No one has been able to sell the business case for such a 
transformation to save a few minutes of down time per month. Despite this 
imperfection, the benefits of a parallelized application are truly game 
changing.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Thursday, November 12, 2015 11:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Applications in a Sysplex/CICSplex

Jumping slightly ahead, let's assume for sake of argument the application in 
question "would not work correctly as-is" in a CICSplex. When then?

It's not typically a "hard stop." It depends on what you're trying to 
accomplish. Let's suppose, for example, that you have an MQ channel interface 
logically in front of the CICS-hosted application in question.
It's possible that implementing an MQ shared queue -- one of the many possible 
Sysplexed services -- could, all by itself, provide substantial value. If the 
single CICS region (or single set of regions) hosting this application is(are) 
offline -- perhaps because a whole z/OS LPAR is undergoing maintenance -- MQ 
could still be receiving messages and queuing them up for processing when the 
application comes back online. And that could still be really useful in 
business service terms. In this scenario you could also probably automate "flip 
flop" of the single CICS region (or single set of regions) across LPARs to 
minimize service interruptions, even with a "CICSplex hostile" application. MQ 
holds the incoming work across switchovers. The queue/channel interface is 
continuously available, though when there's a switchover in back the outbound 
response might be slightly delayed. Not "perfect," but not so bad!

That's just an example, and there are many variations. I simply wanted to make 
the point that even if it's "the end of the world" (so speak), and the 
application in question is just awfully designed and relatively difficult to 
cure (hopefully not!), you still might have some reasonably or even 
tremendously useful options to explore. "It depends."

(But hopefully this whole hypothetical is moot in your particular
situation.)


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

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

Re: (External):Re: IPL wait state

[J O Skip Robinson]

z/OS does indeed behave this way. Every volume is initialized with the 
non-sysres wait state code. This is how IBM can document the consequence of 
IPLing from a non-sysres volume. The wait state code gets overwritten by 
properly formed IPL text. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Friday, November 13, 2015 4:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPL wait state

Actually, there is, as long as the volume has been initialized.  (Thanks to JM 
for helping track this down.)  From the ICKDSF book, under INIT:

"If you do not specify IPLDD, ICKDSF writes special bootstrap records that 
cause the processing unit to be placed in a WAIT state if the volume or 
minidisk is specified during an attempt to load the system. 
Bit 12 of the wait state PSW is set on."  I have not verified that this loads a 
WAIT00F, however.  I suppose one could argue that this is a special case of IPL 
text (and I'd be forced to agree) but when we use that term we usually mean the 
one we write to IPL an operating system.

So it seems we might have a volume that was not INITted or that has incorrect 
IPL text written to it.

In any event, the best next action is unchanged: Write the IPL text and try the 
IPL again.

Gerhard Adam wrote:
> You can't get a wait state code because there is nothing there to load it.  
> All zeros is what you would expect if the "bootstrap" records never got 
> loaded.
>
> Sent from my iPhone
>
>> On Nov 12, 2015, at 6:58 AM, John Eells  wrote:
>>
>> Nathan Astle wrote:
>>> Hello,
>>>
>>> I did applied some maintenance to my sandbox system. When i loaded 
>>> with the LPAR with the new address.
>>>
>>> i got the below message in the HMC,
>>>
>>> Central processor (CP) 0 is looping due to switching between program 
>>> status words (PSWs) that are not valid. The program status word 
>>> (PSW) is .
>>>
>>> The IPLTEXT was not written to the newly cloned RES Volume. Could 
>>> that be a reason ?
>>>
>>>
>>> I am not getting a correct explanation about x'000' on my search 
>>> about the above PSW in MVS manual codes.
>>>
>>> Any suggestions ?
>>>
>>> z/OS 1.11
>> 
>>
>> I think (but have not tested that) you should get a 00F wait if you try to 
>> IPL from a volume with no IPL text.  However, the IPL text--at the level 
>> matching the system you are trying to IPL--is required to IPL.  If you never 
>> wrote it to the IPL volume the IPL will fail.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Premature SYMBOL substitution in SYSIN?

[J O Skip Robinson]

A Friday musing. We at SHARE pounded on IBM for years to implement symbol 
substitution in batch. IBM's defense of the status quo was that unlike STC and 
TSO, where execution is immediate on a known system, a batch job could wander 
all around the JES network on its way from submit to execute. And then languish 
indefinitely on the end point system before actually executing. Where and how 
would appropriate substitution take place? In a several open forums over the 
years, attendees (customers) often disagreed on the 'right' place and method to 
do it. Just sayin'. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Friday, November 13, 2015 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Premature SYMBOL substitution in SYSIN?

It would seem to be a case of (as I think was mentioned in an earlier reply) 
associating the second SET with the second execution of PROC P and processing 
the second SET *before* starting the second execution of PROC P.  Inserting an 
extra step to execute IEFBR14 just before the second SET statement also gives 
correct results in the GENER output:

//  EXPORT SYMLIST=*
//P PROC
//GEN   EXEC  PGM=IEBGENER  
//SYSPRINT  DD  SYSOUT=(,)  
//SYSIN DD  DUMMY   
//SYSUT2DD  SYSOUT=(,)  
//P PEND
//* 
//  SET V2=WOMBAT  *
//WOMBAT1  EXEC P   
//SYSUT1DD  *,SYMBOLS=JCLONLY   
GENER STEP; 
  WITH V2= 
//WOMBAT2  EXEC P   
//SYSUT1DD  *,SYMBOLS=JCLONLY   
GENER STEP; 
  WITH V2= 
//NEWSTEP EXEC PGM=IEFBR14   < INSERTED STEP HERE   
//  SET V2=XYZZY   *
//XYZZY1   EXEC P   
//SYSUT1DD  *,SYMBOLS=JCLONLY   
GENER STEP; 
  WITH V2= 
//XYZZY2   EXEC P   
//SYSUT1DD  *,SYMBOLS=JCLONLY   
GENER STEP; 
  WITH V2= 
//  

HTH

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, November 13, 2015 4:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Premature SYMBOL substitution in SYSIN?

On Mon, 9 Nov 2015 10:12:01 -0600, Tom Marchant wrote:
>
>Mine was corrected with OA47958
>
My systems programmer tells me we now have that.  In my somewhat different 
case, the JESJCL shows:
   ...


Still broke.


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

Re: RE-IPL for the Daylight to Standard time conversion?

[J O Skip Robinson]

I can contribute one factoid to this discussion. We use IBM's TWS for job 
scheduling. Because of the scheduling's extreme sensitivity to time stamps and 
because of a negative incident we had a few years back, we've been accustomed 
to bouncing TWS shortly after the 'fallback' time change. This time we rode it 
out and watched for any scheduling anomalies. We found none. Meanwhile no 
application area has reported problems with duplicate time stamps interfering 
with their production. (Is that a second factoid?) So running with true UTC and 
current OS and middleware, fallback time change should no longer be a global 
concern.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Giliad Wilf
Sent: Friday, November 06, 2015 3:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion?

Much to my regret I've seen the discussion on topic "RE-IPL for the Daylight to 
Standard time conversion?" too late, and was unable to read all posts on the 
issue, so bear with me if it turns out that someone else has already mentioned 
an excellent publication I'm mentioning now:
  
SG24-2070 - S/390 Time Management and IBM 9037 Sysplex Timer, at 
http://www.redbooks.ibm.com/redbooks/pdfs/sg242070.pdf
   
Chapter 9, "Offset Change Impacts to Subsystems", is worth reading (and so is 
Chapter 8).

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

Re: Question on IMS and dr volume backups

[J O Skip Robinson]

This may be OT for your actual question, but an alarm went off in my head while 
reading this post. If you carefully shut down your systems before copying to 
your DR site, you may well find yourself in a world of hurt in the event of a 
real disaster. If systems die a sudden death without warning, you will have no 
opportunity to shut down cleanly or do any other kind of processing on the 
production side. 

To test DR properly, you need to stop processing like yanking a plug. How you 
accomplish that action depends on your configuration and mirroring technology 
(if any). Maybe you depend on tornado alerts where you live. We have 
earthquakes. No time for any preparation whatsoever.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Saturday, November 07, 2015 10:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Question on IMS and dr volume backups

We are testing DR for an OS/390 2.10 system with IMS.
Before the backups, CICSs are shut down and /DBR DB ALL is issued. We then copy 
all disk volumes to tape to send to the DR site.

When we restore the system to the DR box, sometimes we have to issue the 
/ERESTART OVERRIDE command to get IMS happy. Sometimes IMS is happy without the 
/ERESTART.

My main systems programmer says 'We are doing it the way we always have.' I am 
wondering if there is something else we should be doing.

[We can't flash as OS/390 2.10 does not talk correctly with flashcopy on the 
DS8300 we are using. A flash command turns into a standard disk copy.]

--
Tony Thigpen


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

Re: (External):Re: OMVS mount failure

[J O Skip Robinson]

Too much time on my hands. BPMTEXT EF096058 :

Description: HFS-compat mount, - error attaching aggregate or was found not to
be HFS-compat.
  
Action: Ensure that the HFS compatibility mode aggregate that is being MOUNTed
has a single read-write file system and the file system name is the same as   
the aggregate name (that is, the VSAM Linear Data Set name). This can also
mean that you attempted to move ownership of a zFS sysplex-aware read-write   
file system to a system that does not support zFS sysplex-aware (that is, 
either the target system is prior to z/OS V1R11 or it is z/OS V1R11 but is
running sysplex=off). This is not allowed. Otherwise, contact the service 
representative. A mount of a zFS file system that fails with return code 138  
(ENXIO) and reason code EF096058 can indicate that the file system is already 
mounted on another system that is not in the same sysplex but is sharing DASD 
accessibility. zFS prevents data corruption by not allowing a zFS file system 
to be mounted read-write on two systems that are not in a shared file system  
environment. In this case, verify that the file system is not already mounted 
read-write on another system. zFS prevents a system from writing to a zFS 
aggregate that is mounted read-write on another system.   

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Tuesday, November 03, 2015 7:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: OMVS mount failure

Assuming z/OS 2.1, here: SA23-2284-01z/OS UNIX System Services Messages and 
Codes 

Lucas
On Nov 3, 2015 15:56, "Field, Alan"  wrote:

> You can always do:
>
> exec 'SYS1.SBPXEXEC(bpxmtext)' 'EF096058'
>
> Alan Field
> Systems Engineer Principal
> Blue Cross Blue Shield of MN
>
> 651.662.3546
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, November 03, 2015 8:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OMVS mount failure
>
> I think in TSO/ISPF Option 6 you can enter BPXMTEXT EF096058
>
> That might provide some info.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richard Pinion
> > Sent: Tuesday, November 03, 2015 7:49 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: OMVS mount failure
> >
> > Which manual(s) do I look in to find a mount failure when I receive 
> > the messages below.  This is for z/OS 2.1.
> >
> > BPXF274I FILE SYSTEM Z220.OMVS.ETC 952 FAILED TO MOUNT.
> > RETURN CODE = 008A, REASON CODE = EF096058


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

Re: (External):Re: Share your z Systems expertise: survey improvement

[J O Skip Robinson]

After grousing about terminology in my previous post, I need to elaborate. I 
used 'console command' as a straw dog for API. Actually various groups in SHARE 
have been clamoring for *decades* for improved APIs, particularly to facilitate 
automation. What we have been offered for the most part is a schema to issue a 
system or subsystem command, retrieve the output, and parse it for each 
specific purpose. That in the minds of many customers is not really an API, or 
least not the sort of API we envisioned. 

An example of a true API is the SDSF Rexx interface, where a user's interactive 
session talks directly to SDSF and receives output directly from SDSF. There 
are no (overt) system commands involved. More generally, any Rexx facility that 
begins with "ADDRESS env-name" is probably a true API. I also gave the example 
of HSM. If we had "ADDRESS DFHSM" in order to query and control HSM, that would 
qualify as an API. We have very few such interfaces in Rexx. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Monday, November 02, 2015 8:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Share your z Systems expertise: survey improvement

Thanks for that link Jack.  That PDF from IBM may also be helpful in educating 
us about the terms used in this survey, though to get the document that web 
page annoyingly *requires* entry of name/address/company/role information (all 
of which may be faked without consequences) and does not allow you to un-check 
ALL of the "how should we communicate with you" boxes (it obviously *assumes* 
you actually *want* to be contacted, which is hardly ever the case).

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Saturday, October 31, 2015 4:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Share your z Systems expertise: survey improvement

Greg Lubel wrote:
> I am the IBM design lead for our z Systems API strategy.
Surprised no one cited this IBM PDF freely downloadable yet, /APIs for 
Dummies./ 


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

Re: 'Secure' 'Remote' access/control of the HMC(s)

[J O Skip Robinson]

Brian Valentine has presented a session at SHARE called "Top Ten Things You 
Should be Doing on Your HMC but You're Not". It includes security tips. In our 
case, we come into the company network remotely via VPN, which defines the 
various applications that we (by userid) are allowed to access. It works like 
this:

1. No one gets to an HMC directly from the outside. VPN is required to get 
inside the network before touching an HMC.
2. Each defined userid is either allowed or disallowed 'remote' access, which 
applies to working from an internal office or from a hotel in Hong Kong. I.e. 
anything access other than fingers on the keyboard of a real HMC. This control 
is defined as an attribute on each userid.
3. Each defined userid has appropriate authority for the role to be performed.

There was a time years ago when some security folk had a big problem with 
remote access to HMC. The world has since moved into a different orbit.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ken Smith
Sent: Monday, November 02, 2015 12:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: 'Secure' 'Remote' access/control of the HMC(s)

I'm not an expert but did a search at www.ibm.com for 'hmc security' with a 
processor type and found a bunch of stuff.

Ken

On Mon, Nov 2, 2015 at 10:11 AM, Jackson, Robin W. Contractor < 
robin.w.jack...@ssa.gov> wrote:

> When dealing with the issue of security, I am looking for a method of 
> configuring the HMC(s) for 'Secure' 'Remote' access/control ?
>
> Thanks,
>
> Rob Jackson


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

Re: (External):Re: RE-IPL for the Daylight to Standard time conversion?

[J O Skip Robinson]

Not mentioned in the article is a motivation I heard from childhood: tending 
one's garden. As part of the general war effort, the populace were encouraged 
to grow at least some of their own food in order to free up commercial 
agriculture for the troops. These so-called Victory Gardens were deemed more 
manageable by working stiffs if there were still some daylight left at the end 
of the job day. Having to prune tomato plants in the pitch of night was rightly 
considered a disincentive to self-sufficiency. 

All of this early campaigning occurred well before the exigencies of IT. Reset 
the household clocks before retiring Saturday night and all would be well the 
next morning. Who would even notice at 2 AM on a Sunday? Ah, the simpler days. 
Well, the early opponents trotted out the true objectors: cows and other farm 
animals who were governed by internal biological clock. Try to explain to them 
why their daily lives were periodically jerked around by an hour. Ah, the 
simpler days. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 31, 2015 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion?

On Mon, 26 Oct 2015 20:43:14 -0400, Ted MacNEIL wrote:

>I've been wondering how long it would take for time-change questions to start. 
>It's a little later this year.
> 
Well, the U.S. keeps extending the DST season.

Here's the CSM's take on it:


http://www.csmonitor.com/USA/Society/2015/1031/Daylight-saving-time-Why-isn-t-going-away

-- gil


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

Re: (External):Re: Share your z Systems expertise: survey improvement

[J O Skip Robinson]

(It must be Friday somewhere.) My first encounter with APIs was a (likely 
fictitious) anecdote about an engineer who went to a programmer and asked for a 
program to calculate a square root. "Are you sure that's all you want? Just a 
calculation?" The engineer insisted that's all he needed. The next day the 
programmer handed over a deck of cards (ah, those were the days). "This will 
calculate square roots."

"Great" said the engineer. "How do I run it?" 

"Put this deck the card reader and press Start."

"How do I input the number?"

"Input? You didn't ask for input. Or output either, for that matter. This 
program does exactly what you asked for. It calculates a square root."

Like I said, undoubtedly apocryphal. The original point of the tale was the 
importance of providing specifications. But I see it also in larger terms: 
given a computer that is somehow running some software, what APIs are needed to 
make any practical use of it? More specifically, what is an API in the simplest 
terms? In the context of the survey, I have no idea what sort of API the author 
has in mind. The term is not defined, yet the entire survey assumes an 
agreed-upon definition. Does 'API' encompass both the ability to enter a 
console command and a program-callable interface to HSM? 

I gave up on the survey. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: Friday, October 30, 2015 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Share your z Systems expertise: survey improvement

I just started the survey, by the third page I had no idea what you were 
asking, so I quit

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Steve Beaver
> Sent: Friday, October 30, 2015 12:51 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Share your z Systems expertise: survey improvement
> 
> Tom,
> 
> My best description would be SHARE on-line where the audience that can 
> respond with suggestions and/or answers
> 
> Steve
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tom Brennan
> Sent: Friday, October 30, 2015 12:43 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Share your z Systems expertise: survey improvement
> 
> Tell them there's a printable $10 bill waiting for them at the end :)
> 
> Actually, I'm one of the looky-loos.  I was only trying to understand 
> what this is all about and don't have any applications.  I didn't 
> fully understand the background and objectives after the first few 
> questions, so I left.  It's probably just me though, my wife repeatedly says 
> I'm a little dense.
> 
> Greg Lubel wrote:
> > Thanks to all who have followed the link to my survey. This is a 
> > quick
> question to those of you who've looked at it and decided not to complete it.
> >
> > Would you mind letting me know in a sentence how I could make it 
> > better,
> to encourage completion?
> >
> > Many thanks,
> >
> > Greg


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

Re: (External):Re: HMC/Browser access and JAVA

[J O Skip Robinson]

If the SHARE Singalong were still running in high gear, we could write an 
anti-romantic ballad about the despair of 'Java compatibility'. I would suggest 
that each new Java release contains antibodies to all previous releases and--of 
course--to all future releases. The love doctor will advise that you get off of 
Java, but unfortunately that means getting off the (modern) world altogether. 
Prepare to live in perpetual discontent. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, October 30, 2015 4:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: HMC/Browser access and JAVA

That is odd.  One thing I noticed that I don't care for is that once you 
upgrade the HMC to 2.13.0 for the JAVA 8 support, accessing it from machines 
with JAVA 6 or 7 no longer works.   That really surprised me, because I always 
thought there was downward compatibility.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Field, Alan
Sent: Thursday, October 29, 2015 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC/Browser access and JAVA

Another Data Processing mystery.

I upgraded to JAVA 8.65 and it still didn't work. 

I did nothing but wait a few days and a few PC restarts later ... 

I tried again today and lo and behold 3270 and operating system messages are 
working. 

Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, October 19, 2015 6:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: HMC/Browser access and JAVA

Alan,  HMC needs to be at 2.13.0 for JAVA 8 to work.   

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Field, Alan
Sent: Sunday, October 18, 2015 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: HMC/Browser access and JAVA

My HMC access via a browser to the Integrated 3270 and Operating System 
messages broke again.

It is a JAVA problem. I had been running JAVA V7.21 but it won't reinstall 
properly again. I have JAVA 8.60 installed and it doesn't start either of the 
functions.

My HMC microcode is at a high level - it is supposed to support Java V8.

Any suggestions? Thanks

Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546

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

Re: (External):Re: RE-IPL for the Daylight to Standard time conversion?

[J O Skip Robinson]

OP did not state whether GMT is set to UTC or local. I would have thought by 
now shops would have converted to UTC. I understand that the hit is much bigger 
for shops located in the Eastern Hemisphere because the change requires 
shutting down--once--for a prodigious period, but in the Western Hemisphere 
there should be little or no extended down time.

If OP's shop is already running UTC, then he's dealing with fear and 
uncertainty in the application community. My standard (flippant) response is 
that the local apothecary has formulations to soothe the troubled psyche. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert A. Rosenberg
Sent: Monday, October 26, 2015 5:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RE-IPL for the Daylight to Standard time conversion?

At 23:33 + on 10/26/2015, Chris Hoelscher wrote about Re: RE-IPL for the 
Daylight to Standard time conversion?:

>We also shutdown for 1 hour - even oif there were no system issues (and  
>I believe there are not) - our friends in development cannot tell us if 
>there are any apps they rely upon/depend upon/require a non-overlapping 
>timing sequence (would a duplicate time violate any physical 
>integrity(keys) or logical integrity (app expectations) - without such 
>explicit clearance, it is prudent to shutdown for 1 hour .

That is the fallout of using Local not UT/GMT timestamps.

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

Re: (External):Re: Redirect or hide IEBCOPY output when using the TSO RECEIVE Command

[J O Skip Robinson]

The sysout keyword goes on the response to the RECEIVE prompt, e.g.

da(myds) shr sysout(x) 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, October 24, 2015 4:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Redirect or hide IEBCOPY output when using the TSO 
RECEIVE Command

On Fri, 23 Oct 2015 18:06:07 -0400, Scott Ford wrote:

>What about,
>
>NoPreview or Sysout(class other than *)   * defaults to terminal
> 
That's certainly what the manual says, and othert report it works, but I get:

 READY
receive indd(NETDATA) sysout(R)
 IKJ56712I INVALID KEYWORD, SYSOUT(R)
 IKJ56703A REENTER THIS OPERAND -

???


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

Re: (External):Re: z/OS version by Sysres Module

[J O Skip Robinson]

OP asked literally about 'z/OS version'. Several fine answers followed. But if 
OP is actually interested in something like 'maintenance level', then the 
answer is that nothing will tell you that unless you have zapped some literal 
into a user-modifiable area such as (for example) NUCLEUS. We do that as 
discussed in another recent thread. If you do that, then you can examine your 
own literal a very precise answer. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Norbert Friemel
Sent: Friday, October 23, 2015 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: z/OS version by Sysres Module

On Fri, 23 Oct 2015 20:35:46 +0530, Peter wrote:

>Hello,
>
>Is there a module within SYSRES dataset's which can help me to 
>determine the z/OS version ?
>
>This Question is just for the Knowledge sake and not trying solve any 
>problem.
>
>Any Pointers ?
>


//STEP1   EXEC PGM=AMASPZAP  
//SYSLIBDD DISP=SHR,DSN=SYS1.NUCLEUS 
//SYSPRINT  DD SYSOUT=*  
//SYSIN DD * 
  DUMPT IEANUC01 IEASYSID
/*   

Norbert Friemel


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

Re: (External):Re: Unicode Query

[J O Skip Robinson]

I don't understand the reference to IPLTEXT, which is not part of the fix. 
Otherwise, as already noted, you could just copy the three module (plus one 
alias!) to the appropriate libraries and IPL. We have been known to take such 
an action, but there has to be a good reason not to clone the whole sysres. Two 
issues:

1. As simple as this fix appears to be, there is always a chance that something 
could go wrong in the copy process. If a module gets fatally fractured to the 
point that IPL fails, how will you recover? If you have cloned a new sysres, 
you can IPL back to the old sysres. If you have overwritten modules, backout 
could be a quagmire. 

2. This fix contains a linklist component. As soon as the LINKLIB module (with 
alias!) is copied, a subsequent LLA refresh will make the new guy next up in 
the batting order, while LPA and NUC components will take the field only at the 
next IPL. (Pardon the baseball metaphors; tis the season.) If you IPL 
immediately after the copy, there should not be a problem. If there's any 
significant delay, you could get some weird results.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, October 23, 2015 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode Query

If that is the only change, then no.   However, I am a firm believer of doing 
the cloning process the same way every time unless there are extenuating 
circumstances.   I've seen too many times where just the "updated libraries" 
were pushed out, and something is invariably missed, and problems occur.

You also don’t mention it, but if you also manage a matching SMPE target zone 
along with the cloned SYSRES, then what you describe will put them out of sync.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: Friday, October 23, 2015 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unicode Query

Hello Group,

I am Going to Apply UNICODE Conversion PTF to our sandbox system. If Understand 
correct the UNICODE PTF changes the SYS1.LPALIB,SYS1.LINKLIB and SYS1.NUCLEUS 
alone.

So after Applying the Fix Instead of Cloning the Whole SYSRES volume, Can i 
Just copy the above three dataset and Just an IPLTEXT ?

Will there be any Problem If I dont copy the Whole SYSRES ?

Nathan


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

Re: (External):Re: Is there an alternative to SYSDSN(fully.qual.dataset.name) that DOES NOT Recall Migrated Datasets

[J O Skip Robinson]

The requirement is 'onerous' if you're determined--or required--to run a Rexx 
in a non-TSO environment such as batch via PGM=IRXJCL. The Rexx manual 
documents a number of functions as 'TSO/E extensions' that are usable only if 
PGM=IKJEFTxx. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, October 23, 2015 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Is there an alternative to 
SYSDSN(fully.qual.dataset.name) that DOES NOT Recall Migrated Datasets

If the OP wanted a function that would not recall a dataset, the LISTDSI would 
be the solution, even if it has onerous restrictions.

But could  you elaborate on which restrictions are onerous?

Otherwise, I would suggest going to Developerworks and input an RFE to have 
SYSDSN not recall the file.  Another parm like NORECALL would be nice.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Friday, October 23, 2015 9:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Is there an alternative to 
> SYSDSN(fully.qual.dataset.name) that DOES NOT Recall Migrated Datasets
> 
> On Fri, 23 Oct 2015 07:49:32 -0700, Lizette Koehler wrote:
> 
> >No SYSDSN does not as far as I know have a norecall function.
> >
> >However LISTDSI does.
> >
> LISTDSI has the sometimes onerous restriction that it must be issued 
> from a TSO session.
> 
> -- gil


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

Re: (External):Re: Fwd: Bank’s severance deal indebts laid off IT workers to be ‘on call’ for 2 years of tech support — without pay

[J O Skip Robinson]

I've never heard that a severance package is required by law in the US, 
although it would likely be a state issue rather than Federal. From war stories 
I've encountered I'd say almost certainly not. Large responsible companies 
usually offer something. Terms vary, but it's designed to keep torch carrying 
peasants from storming the castle.

The chutzpa of Sun Trust appears to be mind-boggling. If the package is paid up 
front in a lump sum (usual practice), then let a judge decide whether the 
company has the right to demand labor from a person no longer employed. If the 
package is paid out gradually over time, then it looks more like a retainer and 
could be subject to termination for non-compliance. Sigh.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Beaver
Sent: Thursday, October 22, 2015 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fwd: Bank’s severance deal indebts laid off IT workers 
to be ‘on call’ for 2 years of tech support — without pay

I am ignorant: is a severance package legally required? Depends and it is 
NEGOCIABLE 

Otherwise its Pay-to-Stay 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Thursday, October 22, 2015 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fwd: Bank’s severance deal indebts laid off IT workers to be ‘on 
call’ for 2 years of tech support — without pay

Wow - a bank lets staff go - and then expects on-call answers? And the bank 
expects "truthful" answers?  And even if the "answers" are provided in good 
faith, but in the end turn out not the best advice, what happens then? 
Personally - if I let someone go - I would want to be done with them ; not rely 
on them at all'

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, October 22, 2015 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Fwd: Bank’s severance deal indebts laid off IT workers 
to be ‘on call’ for 2 years of tech support — without pay

I certainly dislike what the bank did. I am ignorant: is a severance package 
legally required? Hum, that probably varies. If the employment contract does 
not require that a severance be paid, then the company can require anything 
(legal) in order to qualify for it. IIRC, at one time our company had something 
similar. You wouldn't get a lump sum, but you would continue to get a 
fortnightly (2 week) pay check, with no deductions other than taxes for (up to) 
6 months. While receiving this pay out, you could still be called to answer 
questions. I.e. you couldn't log onto the company's systems or need to "come 
it". But you did need to be "reasonably"
available for phone contact. If you refused, you're payout would stop. So it 
really wasn't "severance", per se, more like a "retainer".

On Thu, Oct 22, 2015 at 12:46 PM, Elardus Engelbrecht < 
elardus.engelbre...@sita.co.za> wrote:

> Ed Gould wrote:
>
>
> http://www.rawstory.com/2015/10/banks-severance-deal-indebts-laid-off-
> it-workers-to-be-on-call-for-2-years-of-tech-support-without-pay/
>
> WTF! G! Those crappies are too cheap to support their employees! 
> That bank wants to have its bread buttered on both sides.
>
> If you drop me, I drop you. Simple. My new employer wants my full 
> attention and if needed 24 hours be on standby. Goodbye ex-employer.
>
> If my ex-employer wants my work, they need to setup a contract with pay.
> Treat me like a consultant with full [hourly] pay, not like a 
> cheap/free slave.
>
> I will surely challenge that "no-pay work after being dismissed" clause.
> (BTW, I think our land's somewhat militant unions will go very badly 
> mad about this...)
>
> And of course move my money to another bank.
>
> Even when I'm retired, I still want to be paid for any work to any 
> ex-employer.
>
> PS: You think I'm ranting for fun? Read this disgusting story about a 
> doctor being misused for 8 years:
>
>
> http://www.health24.com/Lifestyle/Healthy-you/Slave-doctor-in-SA-worki
> ng-for-free-for-8-years-20151020
>
> 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
>



-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you 

Re: (External):Re: Fwd: Bank’s severance deal indebts laid off IT workers to be ‘on call’ for 2 years of tech support — without pay

[J O Skip Robinson]

Hmm. I'll let you know next year. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of michelbutz
Sent: Thursday, October 22, 2015 2:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Fwd: Bank’s severance deal indebts laid off IT 
workers to be ‘on call’ for 2 years of tech support — without pay

What about the tax issue 

Think severance and employment are taxed differently I think severance is at 
higher tax rate

Sent from my iPhone

> On Oct 22, 2015, at 5:21 PM, J O Skip Robinson <jo.skip.robin...@sce.com> 
> wrote:
> 
> I've never heard that a severance package is required by law in the US, 
> although it would likely be a state issue rather than Federal. From war 
> stories I've encountered I'd say almost certainly not. Large responsible 
> companies usually offer something. Terms vary, but it's designed to keep 
> torch carrying peasants from storming the castle.
> 
> The chutzpa of Sun Trust appears to be mind-boggling. If the package is paid 
> up front in a lump sum (usual practice), then let a judge decide whether the 
> company has the right to demand labor from a person no longer employed. If 
> the package is paid out gradually over time, then it looks more like a 
> retainer and could be subject to termination for non-compliance. Sigh.
> 
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Steve Beaver
> Sent: Thursday, October 22, 2015 11:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Fwd: Bank’s severance deal indebts laid off IT 
> workers to be ‘on call’ for 2 years of tech support — without pay
> 
> I am ignorant: is a severance package legally required? Depends and it 
> is NEGOCIABLE
> 
> Otherwise its Pay-to-Stay
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Chris Hoelscher
> Sent: Thursday, October 22, 2015 11:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fwd: Bank’s severance deal indebts laid off IT workers to 
> be ‘on call’ for 2 years of tech support — without pay
> 
> Wow - a bank lets staff go - and then expects on-call answers? And the bank 
> expects "truthful" answers?  And even if the "answers" are provided in good 
> faith, but in the end turn out not the best advice, what happens then? 
> Personally - if I let someone go - I would want to be done with them ; not 
> rely on them at all'
> 
> Chris Hoelscher
> Technology Architect, Database Infrastructure Services Technology 
> Solution Services
> : humana.com
> 123 East Main Street
> Louisville, KY 40202
> Humana.com
> (502) 714-8615, (502) 476-2538
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John McKown
> Sent: Thursday, October 22, 2015 1:55 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] Fwd: Bank’s severance deal indebts laid off IT 
> workers to be ‘on call’ for 2 years of tech support — without pay
> 
> I certainly dislike what the bank did. I am ignorant: is a severance package 
> legally required? Hum, that probably varies. If the employment contract does 
> not require that a severance be paid, then the company can require anything 
> (legal) in order to qualify for it. IIRC, at one time our company had 
> something similar. You wouldn't get a lump sum, but you would continue to get 
> a fortnightly (2 week) pay check, with no deductions other than taxes for (up 
> to) 6 months. While receiving this pay out, you could still be called to 
> answer questions. I.e. you couldn't log onto the company's systems or need to 
> "come it". But you did need to be "reasonably"
> available for phone contact. If you refused, you're payout would stop. So it 
> really wasn't "severance", per se, more like a "retainer".
> 
>> On Thu, Oct 22, 2015 at 12:46 PM, Elardus Engelbrecht < 
>> elardus.engelbre...@sita.co.za> wrote:
>> 
>> Ed Gould wrote:
>> 
>> 
>> http://www.rawstory.com/2015/10/banks-severance-deal-indebts-laid-off
>> - it-workers-to-be-on-call-for-2-years-of-tech-support-without-pay/
>> 
>> WTF! G! Those crappies are too 

Re: (External):Re: Subscribe to RACF-L

[J O Skip Robinson]

A new colleague recently had great difficulty subscribing to IBM-MAIN. The 
problem turned out to be on our side but not specific to IBM-MAIN. Some time 
ago a filter was put in place to reject email whose Envelope Sender was blank. 
This was supposedly to ward off unsolicited, unwanted list server traffic. (Say 
what?) 

Meanwhile I was having no problem because I had subscribed (long) before this 
filter was put in place. The response to 'Info' was OK because it had a 
nonblank Sender. I believe the postings themselves are OK because they also 
have a Sender. Only the response to Subscribe came back blank. Our email guru 
allowed the Subscribe response to come through. Now all is well.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Thursday, October 22, 2015 11:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Subscribe to RACF-L

On Thu, 22 Oct 2015 09:37:03 -0500, Jorge Garcia  wrote:

>Thank Elardus. We know this link is ready and working but when you add 
>you name and email al push subscribe appears in the top: "A confirmation 
>request is being sent under separate cover. " but no mail is received in our 
>shop.

If your networking people cannot locate the problem, try sending a note to the 
list-owner for RACF-L, lsvma...@uga.edu  

Perhaps their logs will show the issue and then you can work on fixing it.

--
Walt 


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

Re: (External):Re: Bookmanager BUILD and z/OS V2.2

[J O Skip Robinson]

A more outrageous example. Some years ago management decided that we did not 
really need Netview, so they refused to order the next upgrade that was 
actually quite a bit more expensive. BUILDMCS came to the rescue. By comparison 
with Book Mgr, Netview is very complicated. Had elements in NUCLEUS as I 
recall. Nonetheless it worked long enough for management to see the light and 
pony up for the next version. BUILDMCS a powerful tool. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Thursday, October 22, 2015 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Bookmanager BUILD and z/OS V2.2

Juergen Kehr wrote:
> As you probably know Bookmanager BUILD isn't supported and delivered with 
> z/OS V2.2 anymore.
>
> We've had the idea to transfer the "old" Bookmanager BUILD FMIDs via BUILDMCS 
> into a seperate CSI in the V2.2 environment. Now our question is: Will this 
> work? Of course it's not offically supported, but their are many unsupported 
> old z/OS or even MVS or OS/VS product, which run perfect although in very new 
> environments.
>
> Does anybody have any experiences with this approach? Thanks in advance.


We generally do not break things on purpose when they are no longer supported 
or offered. For example, I think BTAM/SP worked for at *least* a decade after 
we withdrew it, and maybe even two. However, we also do not test with them, and 
if we happen to make a change that breaks them, we will not even know we did 
it--as happened, eventually, to BTAM.

That said, my guess is that Bookmanager Build does nothing special and will 
likely continue to work. The usual caveats around BUILDMCS apply, though. 
ACCEPT all service first, look in the zone where it's installed to see whether 
it has any cross-FMID considerations that would preclude installation in a 
separate zone and libraries (e.g., shared load modules), and so on.  If it does 
have an intra-zone dependency, it might even be something reasonably easy to 
manage (such as an interaction with Bookmanager Read, which you could BUILDMCS 
out and install alongside it).

BUILDMCS is remarkably fast, and APPLYing something relatively small without 
any PTFs is pretty quick too. I'd be inclined to do some quick checking, try 
it, and see whether it works.

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


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

Re: IBM's PDUU utility

[J O Skip Robinson]

PDDU is totally new to me. For years I've used PUTDOC to send all manner of doc 
to IBM. If someone has used both, could you post a short compare-and-contrast 
review? 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 20, 2015 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM's PDUU utility

Thanks Bill.  I just ran my own test, and it seems to work well.  Reading the 
doc however, it doesn't support VBS data, which I find interesting, since TERSE 
does, as I have sent SMF data this way in the past.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Skeldum, William
Sent: Tuesday, October 20, 2015 1:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's PDUU utility

I have been using the PDUU for quite some time now and love it.  Most of my use 
has been to upload problem data for DFHSM, but have worked with other groups 
also.
Bill Skeldum

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Tuesday, October 20, 2015 7:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's PDUU utility

Thanks Chris, that's good to hear.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Tuesday, October 20, 2015 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM's PDUU utility

Back in 2013 - we encountered a major problem in DB2 - IBM strongly requested 
(required?) that we use the PDUU utility to send them dump or test output


//FTP EXEC PGM=AMAPDUPL
//SYSUDUMP DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=dump input
//SYSINDD  *
USERID=anonymous
PASSWORD=my email address
TARGET_SYS=testcase.boulder.ibm.com
TARGET_DSN=the remote file name
WORK_DSN=a valid temp dsn
CC_FTP=05
WORK_DSN_SIZE=5000
DIRECTORY=/toibm/im/
PMR=38836.082.000


Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services
: humana.com
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 714-8615, (502) 476-2538


The information transmitted is intended only for the person or entity to which 
it is addressed and may contain CONFIDENTIAL material.  If you receive this 
material/information in error, please contact the sender and delete or destroy 
the material/information.

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

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

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

Re: (External):Re: Logrec and EREP

[J O Skip Robinson]

There have been times when I preferred to send raw unformatted LOGREC data if 
only to create a smaller attachment. But I've never found any way to select a 
from-to range of raw data, so I end up running EREP just to make use of 
selection criteria. We all send 'raw' SVC dumps, right? No one would format a 
dump in order to ship it.

As others have said, the ISV request is puzzling and at best poorly worded. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lucas Rosalen
Sent: Monday, October 19, 2015 11:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Logrec and EREP

Maybe they just want a different LOGREC report?
You can the description and instructions for each one in these manuals
here:
http://m.ibm.com/http/www-03.ibm.com/systems/z/os/zos/library/bkserv/v2r1pdf/#IFC
(for zOS 2.1)

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


2015-10-20 1:49 GMT+02:00 Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net>:

> In
> ,
> on 10/19/2015
>at 05:02 PM, Peter  said:
>
> >I am trying to Understand the Difference between a Logrec Report and 
> >a EREP report.
>
> EREP is a program that reports the contents of LOGREC.
>
> >This question came to my mind when I was working with one of ISV 
> >vendor. Initially we gave EREP report but later on he wanted to have 
> >a Logrec Report.
>
> Ask the ISV for a better educated technician.
>
> >Could someone please shed light on the above.
>
> My guess is that you gave him a report on hardware records and he 
> wanted a report on software records, or he wants the raw records.  --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 

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

Re: (External):Re: Coupling facility users

[J O Skip Robinson]

Lizette, I'm not sure what you're looking for. CF Sizer does calculations for 
'Enhanced Catalog Sharing' and for 'DFSMShsm Common Recall Queue'. Is there 
some other function you're trying to size?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, October 19, 2015 7:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Coupling facility users

I have been waiting on some enhancements for CFSizer.
It does not calculate for Catalog in CF or HSM Using RLS.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of John Eells
> Sent: Monday, October 19, 2015 7:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Coupling facility users
> 
> Roger Lowe wrote:
> 
> > Have a look at the CF Sizer tool -
> > http://www-947.ibm.com/systems/support/z/cfsizer/
> 
> 
> Now, why didn't I think of that?  (Too simple and direct, I suppose.)
> 
> Of course, that might well be a resource only for IBM exploiters of 
> the CF, and there are others.
> 
> --
> John Eells
> z/OS Technical Marketing
> IBM Poughkeepsie
> ee...@us.ibm.com
> 


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

Re: (External):Re: AW: Re: IEAVAPE2/IEAVPSE2 another address space

[J O Skip Robinson]

I've known Tom for twenty years and never knew what the 'G' was for. OTOH I get 
address as 'JO' all the time. A sure mark of spam. ;-) 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Sunday, October 18, 2015 11:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: AW: Re: IEAVAPE2/IEAVPSE2 another address space

Peter Hunkeler wrote:
> And who can we be sure Josef Reichman isn't just another name you've 
> arbitrarily chosen?

With that, I need to say that I've had business emails in the past from a 
Joseph Reichman and the originating IP address matches the michelbutz posts.  
So it's either Joe, or it's one of those internet dogs impersonating him after 
hacking into his network.

However, out of respect for the folks he's requesting help from, I think it 
would be good if he at least put a sig on his posts with his real name.

Thomas George Brennan

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

Re: (External):Re: AW: Re: IEAVAPE2/IEAVPSE2 another address space

[J O Skip Robinson]

'Skip' is the only name I've ever gone by with acquaintances, but it's nowhere 
on any legal document. In general, if someone includes a nickname in their 
email or signature, that's what they want be called. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Monday, October 19, 2015 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: AW: Re: IEAVAPE2/IEAVPSE2 another address space

So you must go by Skip...?

On Monday, October 19, 2015, J O Skip Robinson <jo.skip.robin...@sce.com>
wrote:

> I've known Tom for twenty years and never knew what the 'G' was for. 
> OTOH I get address as 'JO' all the time. A sure mark of spam. ;-)
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com <javascript:;>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU 
> <javascript:;>] On Behalf Of Tom Brennan
> Sent: Sunday, October 18, 2015 11:59 PM
> To: IBM-MAIN@LISTSERV.UA.EDU <javascript:;>
> Subject: (External):Re: AW: Re: IEAVAPE2/IEAVPSE2 another address 
> space
>
> Peter Hunkeler wrote:
> > And who can we be sure Josef Reichman isn't just another name you've
> arbitrarily chosen?
>
> With that, I need to say that I've had business emails in the past 
> from a Joseph Reichman and the originating IP address matches the 
> michelbutz posts.  So it's either Joe, or it's one of those internet 
> dogs impersonating him after hacking into his network.
>
> However, out of respect for the folks he's requesting help from, I 
> think it would be good if he at least put a sig on his posts with his real 
> name.
>
> Thomas George Brennan


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

Problem subscribing to IBM-Main

[J O Skip Robinson]

I don't know where to direct this. A colleague is having trouble subscribing to 
the List. He can successfully send INFO IBM-MAIN, but when he sends SUBSCRIBE, 
nothing happens. No reply at all from UA.EDU. His userid is on the same 
corporate domain as mine. OTOH he has subscribed from his personal email and 
all is well.

Working with our email guru, but he sees no blockage on our side. Any debugging 
possible at Bama?

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


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

Re: (External):Re: Problem subscribing to IBM-Main

[J O Skip Robinson]

Looks like I jumped the gun a bit. Our email guru found something on our side 
he hadn't noticed. Dinesh finally got an acknowledgment from his SUBSCRIBE 
request. Waiting to see if he actually gets postings delivered...

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Finnell
Sent: Monday, October 19, 2015 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Problem subscribing to IBM-Main

If you don't hear from Darren in a while use the web interface at 
listserv.ua.edu/archives/ibm-main.html
 
 
In a message dated 10/19/2015 5:59:42 P.M. Central Daylight Time,  
jo.skip.robin...@sce.com writes:

Working  with our email guru, but he sees no blockage on our side. Any 
debugging  possible at Bama?

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

Re: IBM

[J O Skip Robinson]

We have sort of the opposite 'problem'. Our network security people run some 
kind of probe against every device found on our network. When it pokes the HMC, 
he calls home and reports a possible intruder. Then Support Center opens an 
incident and our CE gets dragged in. I tried to get the HMCs exempted from our 
internal probe. No dice. No exceptions. Our guys actually told me to ask 
Support Center to ignore the HMC complaint. 

We all know the classic tale of the boy who cried wolf. If you recall, it was 
the wolf who won the day. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Monday, October 19, 2015 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM

On 15Oct16:1752+, Lance D. Jackson wrote:

> This is disturbing: 
> http://www.wsj.com/articles/ibm-allows-chinese-government-to-review-so
> urce-code-1444989039

If your only concern is IP misappropriation, I understand your concern.
My concern is the possibility of backdoors in appliances like the HMC and SE 
boxen.  The problem is we don't know just what the Chinese are looking at nor 
for.  Neither can we know if any apparent acceptance by them of the code as 
untainted is applicable to the code our machines are running.  Are any other 
customers receiving such preferential treatment (perhaps the good folks at No 
Such Agency)? 
--

May the LORD God bless you exceedingly abundantly!

Dave_Craig__

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

Re: (External):HMC/Browser access and JAVA

[J O Skip Robinson]

Both functions are working for me today. Java level:

java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) Client VM (build 25.60-b23, mixed mode)

We have had Java problems off and on but finally standardized on this version 
after upgrading all HMCs to the latest driver. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Field, Alan
Sent: Sunday, October 18, 2015 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):HMC/Browser access and JAVA

My HMC access via a browser to the Integrated 3270 and Operating System 
messages broke again.

It is a JAVA problem. I had been running JAVA V7.21 but it won't reinstall 
properly again. I have JAVA 8.60 installed and it doesn't start either of the 
functions.

My HMC microcode is at a high level - it is supposed to support Java V8.

Any suggestions? Thanks

Alan Field
Systems Engineer Principal
Blue Cross Blue Shield of MN

651.662.3546

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

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

The PTF does not update any macro, but as Peter says, it's not a programming 
interface anyway. 

One more point. The NUCLEUS element CUNMIIPL has the alias IEAVNPUN. If you 
choose to put the fix elements in place 'manually' ahead of the next IPL, don't 
forget the alias. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 16, 2015 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

On Fri, 16 Oct 2015 06:04:35 -0700, Richard Pinion wrote:

>What happens if one does not use Unicode services and does not apply the PTF?
> 
Can you do that?

Can you audit all your in-house code to assure that nothing uses Unicode 
services?
What about indirectly?

Can you electively disable Unicode services and observe what fails?  (Can you 
zap the evil bit on?  Or zap the CC mask in the test so it always takes the 
"disabled" path?  Yah, I know: OCO.)

I assume the repair is to test the correct bit, ignoring the correct store of 
the system clock.  Are all defective macros (even non-GUPI) repaired?

-- gil


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

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

OK, what Peter said. I get a C- for the explanation part, but I think the 
method part is sound. We're now running R13 on sandbox with the fix in place. 
V2R1 to follow soon. 

A note on circumvention options. If you are truly out of harm's way for this 
problem, I don't suppose you have to do anything. I personally would not want 
to bet the farm on that judgment, but Seymour has repeatedly bequeathed you the 
dog. The timestamp is stored at UCCB+10 only at IPL, so the current value will 
remain indefinitely until the next IPL. Regardless of your IPL schedule, keep 
in mind that any system failure--software or hardware--could cause an 
unscheduled IPL on or after Dec 15. Best to have the fix in place by then. OTOH 
you don't have to actually IPL in advance if you have the three fix elements in 
place in NUC, LINK, and LPA. If your system crashes, re-IPL will implement the 
fix and you will be OK. As long as you got it right.

Another note. Our R13 system is fairly current but not pristinely so. All three 
fix elements were at base level, so the PTF installed without any requisites. 
The NUC element CUNMIIPL is a 77K standalone module--not part of IEANUC01--so 
it should be easy to drop into SYS1.NUCLEUS if you wish to defer IPL.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Friday, October 16, 2015 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

from Gil:
>I'm curious: how (not when) does this problem occur?  Is it some OCO 
>doing a TM on the wrong address?

yes.

It should have been testing a flag byte but, because of the error, was testing 
a byte that was not a flag byte but was the target of a STCK.

from Skip: 
>1. The UCCB is a defined control block, mapped in several (!) MACLIB 
>members such as CUNBAIDF.
The UCCB is not an interface and should not have been placed into any MACLIB 
member. This was part of the origin of the erroneous code. You may notice that 
while the mapping is there, there is no interface provided to locate the area. 
So while there is a mapping that is visible, it does not effectively constitute 
an interface.

>2. Various flags are defined beginning at UCCB+10.
Nope. What is defined at UCCB+10 is a timestamp. See the answer to Gil's 
question.

>3. Somehow during IPL the system clock has been overlaying
>UCCB+10 by (presumably) Unicode set up processing.
Nope. See #2.

>4. No one noticed all this time because the flag nibble in the 
>timestamp has always, coincidentally, indicated 'Unicode available'.
Yup. And no one (apparently) tested "prior to z/OS 1.10 is this function 
available".
By the way, it's not actually "Unicode available". It's "Unicode conversion 
services available".

>5. As of the magic moment on December 15, the clock rolls over and 
>reverses the benign bit. Without the fix, Unicode appears to be 
>unavailable more or less forever. Until the bit once again changes 
>back?
Not all of unicode, but these services. And "yes" (more specifically, until you 
re-IPL after the bit changes back -- in 18 or so years). 

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: (External):Re: IBM Mobile Systems Remote

[J O Skip Robinson]

Remote access--literally getting to an application from outside the glass 
house--is not intrinsically risky. I'm logged on to my system now from my 
dining room table. To get to any application--including HMC--I must first VPN 
into the company network. That requires several hoop jumping steps, after which 
I have essentially the same access that I have from my office.

The rub for me is that I cannot VPN from my mobile device. The aforementioned 
hoops are Windows applications. Even if there were some technological solution, 
I don't know that the company would allow it. Otherwise the HMC is just a 
browser away. That's how I get there from my office PC.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Friday, October 16, 2015 8:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM Mobile Systems Remote

On 16 Oct 2015 08:22:03 -0700, in bit.listserv.ibm-main you wrote:

>Is anyone using it?
>
>It is (in my understanding) some kind of remote access to HMC from 
>mobile device.
>I have no idea what is functionality of the application and it connect 
>to the HMC.
>Associated webpage ibmremote.com does not work.

I hope that IBM isn't allowing that.  Remote access to a HMC seems to be a 
security hole large enough to drive a truck through.

Clark Morris
>
>--
>Radoslaw Skorupka
>Lodz, Poland

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

Re: (External):Re: IBM

[J O Skip Robinson]

Gotta agree. That wording is not quite the same thing as saying 'there are no 
back doors'. On balance, however, I usually impugn such wobbly subtext to 
imprecise verbiage, not to finely crafted misdirection. I give IBM a pass on 
the statement. But then again, I'm easy.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Friday, October 16, 2015 1:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM

Why be terrified?  If IBM is as good as they claim regarding security, they 
should welcome looky-loos with secret cameras in their eyeglasses.

"IBM does not provide government access to client data or back doors into our 
technology" (IBM statement to Reuters)

Oops, did IBM just say that there are back doors?
Need a former English teacher's help with commas.  Skip?

Bigendian Smalls wrote:
> Positively terrifying.   I know large companies often get to review 
> unthinkable source code, because of the risks this article states.  But a 
> foreign government, and China no less - seems risky.  I’m sure it is done 
> ‘eyes only’ and they don’t actually get to keep a copy.  But still, stealing 
> IP would be the one bad outcome - finding ugly undisclosed vulnerabilities 
> quite another.
> 
> 
>>On Oct 16, 2015, at 12:52 PM, Lance D. Jackson 
>> wrote:
>>
>>This is disturbing: 
>>http://www.wsj.com/articles/ibm-allows-chinese-government-to-review-so
>>urce-code-1444989039


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

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

We have installed the R13 PTF and tested with assistance from IBM. To see your 
vulnerability, use IPCS ACTIVE or Omegamon MLST or Mainview (???) to display 
data currently in the UCCB control block at +10:

10?+220?+3C?+10

Before the PTF, you will see something like CFA83DBE 87F18D69 , which is a copy 
of the system clock at the last IPL. The problem is that on December 15, this 
data turns to D000  . With this clock value, the flag being checked 
for Unicode availability returns 'not available' via RC 8. After the PTF is 
IPLed (required!), the field is all zeroes, which is OK. The fix moves the time 
stamp to UCCB+20 and zeroes out UCCB+10. 

In order to verify functionally, SYS1.SAMPLIB contains member CUNSISMA, which 
calls Unicode. RC 0 indicates Unicode is available, RC 8 indicates it is not 
available. If you run CUNSISMA today, you'll get RC 0. But if you use your 
favorite memory altering tool--we used Omegamon MZAP--to set UCCB+10 to 
D000 , the program will get RC 8. After the fix is IPLed, UCCB+10 
is all zeroes, and CUNSISMA gets RC 0. 

We could go further and IPL the system to December 16, but that's a lot of 
trouble just to see if IBM is telling the truth. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dno
Sent: Thursday, October 15, 2015 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

Great! Thanks Al. I did not see the fix in the link.

Sent from my iPhone

> On Oct 15, 2015, at 1:40 PM, Nims,Alva John (Al)  wrote:
> 
> PTF UA79203 for z/OS 1.13 is available today, I just received it and when I 
> did an APPLY CHECK, it was the only one applied.
> 
> Al Nims
> Systems Admin/Programmer 3
> EI
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dno
> Sent: Thursday, October 15, 2015 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
> 
> I applied the APAR fix to be safe, but I see that IBM did not publish a PTF 
> for 1.13??? Any reason why?
> 
> Sent from my iPhone
> 
>> On Oct 15, 2015, at 9:14 AM, Mike Shorkend  wrote:
>> 
>> The PTFs are out there
>> 
>> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>> 
>> for version specific fixes
>> 
>>> On 8 October 2015 at 18:27, גדי בן אבי  wrote:
>>> 
>>> I was told, by our IBM person, that the official PTF we be made 
>>> available on October 16th.
>>> Gadi
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>>> Sent: 08 October 2015 17:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Unicode services Red alert
>>> 
>>> So far we have the APAR, Any idea when we will be getting the GA PTF 
>>> for this ?
>>> 
>>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson  wrote:
>>> 
> What bugs me is that z/OS 1.13 systems are not exposed to this 
> defect yet IBM created an aparfix for 1.13.
 
 Any application, whether customer-owned, ISV-owned, or IBM-owned 
 could be using this service (which has been in z/OS since z/OS 
 1.10).  IBM has no idea what might fit into those first two 
 categories. Thus I would think
>>> it
 would be in everyone's best interest to get this PTF and apply it, 
 if for no other reason than to avoid having to figure out if you truly 
 care.
 
 The IBM use in LE apparently is new with z/OS 2.1.
 
 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: (External):Re: Unicode services Red alert

[J O Skip Robinson]

I wish we could take credit for discovering the problem. I've learned that many 
sites do time-warp testing on a regular basis. Remember the Y2K Flash Mob scene 
when we all did that incessantly? I seriously doubt that this problem was 
discovered by IPLing at Dec. 15. There was undoubtedly some further future date 
being explored. Whoa! Unicode is broken. Eventually it was narrowed down by the 
original customer (wishful thinking) or more likely by IBM to the actual fail 
point. 

Our PMR was opened by a diligent colleague who wanted more specific details. 
And I appreciate that IBM complied and supplied more details, especially the 
SAMPLIB pointer, which allowed us to test without the painful need to change 
the system time at IPL. 

OK, I warned about a RACF war story. A DB2 sysprog was trying to debug what 
looked like a RACF problem in DB2. She found a flag documented in DB2 as 'RACF 
available'. She could see that it was zero, so she zapped it to one. This was 
not a DB2 control block but the actual MVS CVT flag. The entire system stopped 
working. Every RACF access of any kind resulted in a WTOR requesting permission 
to allow access. Somehow we got the flag zeroed out before total system 
collapse. Luckily it was the development system, and luckily we didn't have to 
IPL. But that's how I remember the meaning of the RACF flag. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, October 15, 2015 8:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

On 2015-10-15, at 21:06, J O Skip Robinson wrote:

> I'm piecing together various clues. It appears to me that:
> 
> 1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
> such as CUNBAIDF.
>  
A more modular design might map it in one macro and call it from all the 
others.  Jurisdiction probably precludes.

> 2. Various flags are defined beginning at UCCB+10.
> 3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
> (presumably) Unicode set up processing.
> 4. No one noticed all this time because the flag nibble in the timestamp has 
> always, coincidentally, indicated 'Unicode available'.
> 5. As of the magic moment on December 15, the clock rolls over and reverses 
> the benign bit. Without the fix, Unicode appears to be unavailable more or 
> less forever. Until the bit once again changes back?
> 
> I suspect that checks for the timestamp are far rarer than checks for Unicode 
> availability. So the fix is to store the clock somewhere else at IPL 
> (UCCB+20) and ensure that the critical flags are zero. Our PMR indicates what 
> I suspected: a zero value means OK, a one value means not OK. This is 
> analogous to the RACF flag in the CVT. Zero means that RACF is functional 
> while one means that it is not. I have a hilarious war story about how I know 
> that. 
>  
And I wonder how the problem was discovered.  Does someone routinely test with 
the system clock advanced a few weeks; long enough for an APAR to turn around?  
May I infer from "Our PMR" that you're the reporting site?

-- gil

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

Re: Unicode services Red alert

[J O Skip Robinson]

I think I received the following link internally rather than from IBM-MAIN. 
It's a good discussion of the issue. 

http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Thursday, October 15, 2015 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

We have installed the R13 PTF and tested with assistance from IBM. To see your 
vulnerability, use IPCS ACTIVE or Omegamon MLST or Mainview (???) to display 
data currently in the UCCB control block at +10:

10?+220?+3C?+10

Before the PTF, you will see something like CFA83DBE 87F18D69 , which is a copy 
of the system clock at the last IPL. The problem is that on December 15, this 
data turns to D000  . With this clock value, the flag being checked 
for Unicode availability returns 'not available' via RC 8. After the PTF is 
IPLed (required!), the field is all zeroes, which is OK. The fix moves the time 
stamp to UCCB+20 and zeroes out UCCB+10. 

In order to verify functionally, SYS1.SAMPLIB contains member CUNSISMA, which 
calls Unicode. RC 0 indicates Unicode is available, RC 8 indicates it is not 
available. If you run CUNSISMA today, you'll get RC 0. But if you use your 
favorite memory altering tool--we used Omegamon MZAP--to set UCCB+10 to 
D000 , the program will get RC 8. After the fix is IPLed, UCCB+10 
is all zeroes, and CUNSISMA gets RC 0. 

We could go further and IPL the system to December 16, but that's a lot of 
trouble just to see if IBM is telling the truth. ;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dno
Sent: Thursday, October 15, 2015 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

Great! Thanks Al. I did not see the fix in the link.

Sent from my iPhone

> On Oct 15, 2015, at 1:40 PM, Nims,Alva John (Al) <ajn...@ufl.edu> wrote:
> 
> PTF UA79203 for z/OS 1.13 is available today, I just received it and when I 
> did an APPLY CHECK, it was the only one applied.
> 
> Al Nims
> Systems Admin/Programmer 3
> EI
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dno
> Sent: Thursday, October 15, 2015 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
> 
> I applied the APAR fix to be safe, but I see that IBM did not publish a PTF 
> for 1.13??? Any reason why?
> 
> Sent from my iPhone
> 
>> On Oct 15, 2015, at 9:14 AM, Mike Shorkend <mike.shork...@gmail.com> wrote:
>> 
>> The PTFs are out there
>> 
>> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>> 
>> for version specific fixes
>> 
>>> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>>> 
>>> I was told, by our IBM person, that the official PTF we be made 
>>> available on October 16th.
>>> Gadi
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>>> Sent: 08 October 2015 17:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Unicode services Red alert
>>> 
>>> So far we have the APAR, Any idea when we will be getting the GA PTF 
>>> for this ?
>>> 
>>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>>> 
>>>>> What bugs me is that z/OS 1.13 systems are not exposed to this 
>>>>> defect yet IBM created an aparfix for 1.13.
>>>> 
>>>> Any application, whether customer-owned, ISV-owned, or IBM-owned 
>>>> could be using this service (which has been in z/OS since z/OS 
>>>> 1.10).  IBM has no idea what might fit into those first two 
>>>> categories. Thus I would think
>>> it
>>>> would be in everyone's best interest to get this PTF and apply it, 
>>>> if for no other reason than to avoid having to figure out if you truly 
>>>> care.
>>>> 
>>>> The IBM use in LE apparently is new with z/OS 2.1.
>>>> 
>>>> 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: (External):Re: Unicode services Red alert

[J O Skip Robinson]

I'm piecing together various clues. It appears to me that:

1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
such as CUNBAIDF. 
2. Various flags are defined beginning at UCCB+10.
3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
(presumably) Unicode set up processing.
4. No one noticed all this time because the flag nibble in the timestamp has 
always, coincidentally, indicated 'Unicode available'.
5. As of the magic moment on December 15, the clock rolls over and reverses the 
benign bit. Without the fix, Unicode appears to be unavailable more or less 
forever. Until the bit once again changes back?

I suspect that checks for the timestamp are far rarer than checks for Unicode 
availability. So the fix is to store the clock somewhere else at IPL (UCCB+20) 
and ensure that the critical flags are zero. Our PMR indicates what I 
suspected: a zero value means OK, a one value means not OK. This is analogous 
to the RACF flag in the CVT. Zero means that RACF is functional while one means 
that it is not. I have a hilarious war story about how I know that. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, October 15, 2015 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

On 2015-10-15 17:37, J O Skip Robinson wrote:
> I think I received the following link internally rather than from IBM-MAIN. 
> It's a good discussion of the issue. 
> 
> http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>  
I'm curious: how (not when) does this problem occur?  Is it some OCO doing a TM 
on the wrong address?  I suppose I should infer something from:


Problem summary

Correct the code involved to move the timestamp field to
allow the Unicode services active indicator to remain valid.

-- gil

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

Re: (External):Re: What is a request block prefix?

[J O Skip Robinson]

Abend FDB indicates an invalid SVC call. The SVC number is x'DB', or 219, which 
is in the range of installation defined SVCs. In other words, it's not an 
official IBM SVC. Either the SVC environment was set up improperly, or it was 
not an actual SVC call but execution of code that looks like an SVC but isn't. 
You need to find the location where the SVC was issued. Easiest way I know of 
is system trace table. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of michelbutz
Sent: Tuesday, October 13, 2015 2:03 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: What is a request block prefix?

It's in the data areas for RB IHARB the RB like TCB Seems to have a prefix

Sent from my iPhone

> On Oct 13, 2015, at 5:01 PM, Lindy Mayfield  wrote:
>
> In the system completion codes documentation it says that for an abend FDB 
> that register 2 points to the request block prefix.  What is a 'request block 
> prefix' in this context?
>
> Verbatim it reads:
> "When nn is not equal to 13, 14, 17, or 37, the system records in register 2 
> the address of the request block prefix for the program that issued the 
> incorrect SVC."
>
> Thanks in advance for any advice.
> Regards,
> Lindy

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

Re: (External):Re: Dell - EMC

[J O Skip Robinson]

This is reminiscent of Sun buying STK and getting into a business they clearly 
did not understand. If the pattern holds, Larry Ellison will postpone buying 
his next island and throw a barrelful of cash at Dell. That he does not 
understand mainframe hardware either is no obstacle for him. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, October 12, 2015 9:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Dell - EMC

This is an EXTERNAL email. If the sender is not recognized, do not open 
attachments or click on any Internet links within the message.

I mean that the NY Times article also did not mention all of the non-mainframe 
technologies impacted; for example, they did not mention that Dell would by 
implication be acquiring the RSA encryption and SIEM businesses of EMC's. My 
point being that the omission of the mainframe from the article should not be 
taken as a mainframe slight but rather as an indication of the technological 
superficiality of the article.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, October 12, 2015 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dell - EMC

On Mon, 12 Oct 2015 07:58:55 -0700, Charles Mills wrote:

>No mention of RSA either for that matter.
>
Related articles mention that as a done deal; no longer news.


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

Subscribing to IBM-MAIN

[J O Skip Robinson]

Two of my colleagues are trying to join IBM-MAIN. Neither one is successful. 
Both have sent notes to LISTSERV trying to following the INFO directive:

SUBSCRIBE IBM-MAIN  

What's with the angle brackets? Required? Prohibited? Nothing seems to work.



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


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

Re: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

[J O Skip Robinson]

I'm guessing that most shops have some STORCLASS that bypasses at least some 
SMS rules. We have NULL. That bypasses volser assignment, but not all rules. In 
the absence of ISMF, you really need to get direction from your storage admin. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Wednesday, September 30, 2015 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

This is an EXTERNAL email. If the sender is not recognized, do not open 
attachments or click on any Internet links within the message.

As I said, I need to check some application program error logic designed to do 
application-specific recovery steps when there is a file-full condition.  I 
need a file that I can fill up and that stays filled and does not extend in 
order to test that application logic.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ted MacNEIL
Sent: Wednesday, September 30, 2015 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

What problems are you attempting to solve by enforcing this?

-
-teD
-
  Original Message
From: Farley, Peter x23353
Sent: Wednesday, September 30, 2015 12:25
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: How to limit tiny SMS-managed VSAM KSDS to one volume?

I need some advice from storage gurus. I need to make a tiny SMS-managed VSAM 
KSDS that will NOT extend, neither to secondary space on the first volume nor 
to secondary volumes. I need to test some error logic in an application program 
and I need a "file full" or "no more space" condition to test it.

I have these parameters in the define cluster command:

VOLUME(*) CYL (1 0)

But when I try to fill up that file with IDCAMS REPRO so that there is no more 
room for any records by copying from a similar file with many records into the 
tiny one, it automatically extends to new volumes, with messages like this:

SMS4000I TSOUSERZ, MKTSTFIL, SYS1, ATTEMPTING SPACVOLA FOR TSOUSER. 
TINY.DATA, XX, 1 SMS4400I VOLUME ADDED - OLD VOLUME XX, NEW VOLUME SMS 
. VOLUME COUNT IS 2

I assume this is due to some hidden parameter in the STORCLAS that overrides my 
specification of only one candidate volume.

My question is, how do I override that hidden STORCLAS parameter to force a 
no-more-space error here? I deliberately want the attempt to add one more 
record to force an error.

I do NOT have easy access to a storage admin on this system, so I need help 
from you. ISMF is not available in my TSO menus, so I cannot check the STORCLAS 
for myself.

TIA for any help you can offer.

Peter

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

Re: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

[J O Skip Robinson]

So you're getting 

   STORAGECLASS SCLARGE MANAGEMENTCLASS--MCLARGE
   DATACLASS -OTHER 

These are all installation defined names. (I don't believe that SMS natively 
provides default names, but I'm not a storage admin.) There is *no way* to 
guess what name you could use to give you the result you're after. If you're 
not defined to SAF as having access to the relevant STGADMIN profile in the 
facility class, I don't think there's any way for you to poke around SMS for 
alternative class names. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Wednesday, September 30, 2015 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

This is an EXTERNAL email. If the sender is not recognized, do not open 
attachments or click on any Internet links within the message.

I have no way to check the storage or management classes, I have no access to 
ISMF from ISPF menus.  Unless there is a batch JCL I could run to display that 
information, if so please point me to the right manual.

What is DVC please?  I'm guessing Dynamic Volume Count?

Here is a sanitized LISTCAT, as requested.  I also forgot to say that this is a 
z/OS 2.1 system, in case that matters.

CLUSTER --- TSOUSER.VSAM.TINY
 IN-CAT --- ICF.TEST.CATALOG
 HISTORY
   DATASET-OWNER-(NULL) CREATION2015.273
   RELEASE2 EXPIRATION--.000
 SMSDATA
   STORAGECLASS SCLARGE MANAGEMENTCLASS--MCLARGE
   DATACLASS -OTHER LBACKUP ---.000.
   CA-RECLAIM-(YES)
   EATTR-(NULL)
   BWO STATUS-- BWO TIMESTAMP---0 00:00:00.0
   BWO---(NULL)
 RLSDATA
   LOG (NULL)   RECOVERY REQUIRED --(NO) FRLOG 
(NULL)
   VSAM QUIESCED ---(NO)RLS IN USE -(NO) 
LOGREPLICATE-(NO)
   LOGSTREAMID-(NULL)
   RECOVERY TIMESTAMP LOCAL-X''
   RECOVERY TIMESTAMP GMT---X''
 PROTECTION-PSWD-(NULL) RACF(NO)
 ASSOCIATIONS
   DATA-TSOUSER.VSAM.TINY.DATA
   INDEXTSOUSER.VSAM.TINY.INDEX
   DATA --- TSOUSER.VSAM.TINY.DATA
 IN-CAT --- ICF.TEST.CATALOG
 HISTORY
   DATASET-OWNER-(NULL) CREATION2015.273
   RELEASE2 EXPIRATION--.000
   ACCOUNT-INFO---(NULL)
 PROTECTION-PSWD-(NULL) RACF(NO)
 ASSOCIATIONS
   CLUSTER--TSOUSER.VSAM.TINY
 ATTRIBUTES
   KEYLEN40 AVGLRECL1600 
BUFSPACE---37888 CISIZE-18432
   RKP0 MAXLRECL1600 
EXCPEXIT--(NULL) CI/CA-45
   SHROPTNS(2,3)  SPEED UNIQUE   NOERASE INDEXED   
NOWRITECHK UNORDERED  REUSE
   NONSPANNED
 STATISTICS
   REC-TOTAL495 SPLITS-CI--0 
EXCPS--2
   REC-DELETED0 SPLITS-CA--0 
EXTENTS1
   REC-INSERTED---0 FREESPACE-%CI--0 
SYSTEM-TIMESTAMP:
   REC-UPDATED0 FREESPACE-%CA--0  
X'CFA093A23D754BAD'
   REC-RETRIEVED--0 FREESPC0
 ALLOCATION
   SPACE-TYPE--CYLINDER HI-A-RBA--829440
   SPACE-PRI--1 HI-U-RBA--829440
   SPACE-SEC--0
 VOLUME
   VOLSERXX PHYREC-SIZE18432 
HI-A-RBA--829440 EXTENT-NUMBER--1
   DEVTYPE--X'3010200F' PHYRECS/TRK3 
HI-U-RBA--829440 EXTENT-TYPEX'40'
   VOLFLAGPRIME TRACKS/CA-15
   EXTENTS:
   LOW-CCHH-X'029D' LOW-RBA0 
TRACKS15
   HIGH-CCHHX'029D000E' HIGH-RBA--829439
   INDEX -- TSOUSER.VSAM.TINY.INDEX
 IN-CAT --- ICF.TEST.CATALOG
 HISTORY
   DATASET-OWNER-(NULL) CREATION2015.273
   RELEASE2 EXPIRATION--.000
 PROTECTION-PSWD-(NULL) RACF(NO)
 ASSOCIATIONS
   CLUSTER--TSOUSER.VSAM.TINY
 ATTRIBUTES
   KEYLEN40 AVGLRECL---0 
BUFSPACE---0 CISIZE--1024
   RKP0 MAXLRECL1017 
EXCPEXIT--(NULL) CI/CA-33
   

Re: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one volume?

[J O Skip Robinson]

Do you have any way to 'flood' the VSAM file with data? If so, try allocating 
the VSAM file as small as possible, although SMS may give you more than you 
want. In any case it won't be infinite. Try writing so much data that the file 
eventually fills up. Maybe you could prime the file to almost full, then let 
the application program hit the limit with it's own output. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Farley, Peter x23353
Sent: Wednesday, September 30, 2015 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one 
volume?

I have reached out to that organization, but getting an answer to such a 
non-emergency question may take days or more.  Hence my attempt to find a way 
to do it a bit sooner from the expertise on this list.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Wednesday, September 30, 2015 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: How to limit tiny SMS-managed VSAM KSDS to one 
volume?

I'm guessing that most shops have some STORCLASS that bypasses at least some 
SMS rules. We have NULL. That bypasses volser assignment, but not all rules. In 
the absence of ISMF, you really need to get direction from your storage admin. 

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

Re: (External):So Long, and Thanks for All the Fish

[J O Skip Robinson]

Alas. The sysprog that Time forgot. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Jacobs - Listserv
Sent: Tuesday, September 29, 2015 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):So Long, and Thanks for All the Fish

This is an EXTERNAL email. If the sender is not recognized, do not open 
attachments or click on any Internet links within the message.

This is the last week that Time Inc employees will be responsible for our zOS 
and zVM Tampa Data Center. Support and services is being outsourced to IBM and 
AT, and sometime in 2016 our mainframe LPARs will be moved to IBM's zCloud 
environment. I'm one of the few Data Center employees being retained (for now), 
but I'm not going to be directly responsible for the zOS environments I've 
lovingly supported for 20 years after Friday.

I'll still be subscribed to the mailing list, but without being involved in new 
and interesting "stuff" going forward my ability to contribute might be limited.
--

Mark Jacobs
Time Customer Service
Technology and Product Engineering

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

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

Re: Testing with dates in the future

[J O Skip Robinson]

The ability to IPL a system with a non-current date--past or future--was a 
response to the myriad problems faced by all mainframe customers preparing for 
Y2K. Certainly there are products that enable *simulation* of non-current 
dates, but the h/w capability is free and universal. That is, the simulated 
date is presented to the OS and to all applications without any special setup 
or priming of applications. Sure, a system has to be reIPLed to change the 
date, but I wager that in general that takes less time and effort than playing 
with date-fudging software. 

Of course this assumes that you have a true sandbox system to play with.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, September 23, 2015 5:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Testing with dates in the future

There were a rash of this sort of product built to address testing of Y2K 
remediation. I had a friend who wrote one and sold it to one of the big guys 
(Compuware?) who incorporated it into a whole suite of Y2K-oriented products.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Metcalfe
Sent: Wednesday, September 23, 2015 2:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Testing with dates in the future

There are a number of vendor tools to facilitate this at a job/user level 
rather than disturbing the sysplex/system time- IBM's Hourglass is but one.


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

Re: Accept nothing less than Z

[J O Skip Robinson]

Well I for one am not voting for Fiorina until she gets this whole thing 
straightened out. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, September 21, 2015 3:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accept nothing less than Z

Fundamentally (IANAL) the test is "might it create confusion in a potential 
customer's mind." You could not open a restaurant called macdonalds even though 
their trademark is on McDonald's. (Well, you could, but you would hear from 
Mickey D's lawyers, and they would be grumpy.)

In this case the customer is fairly sophisticated. It's hard to see an Global 
5000 IT manager ordering a Z from HP and being shocked when it arrived and was 
an Intel server, not a mainframe. Unlike your macdonalds restaurant where some 
poor doofus might wander in and expect to get a Big Mac.

OTOH might a negative press article about the HP Z become conflated in some 
CIO's mind with the IBM z? Perhaps more of an argument there. As McDonald's 
would argue that if I read a negative Yelp review of your restaurant I might 
hold it against McDonald's.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, September 21, 2015 3:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accept nothing less than Z

On 2015-09-21 15:49, Charles Mills wrote:
> I saw that and almost posted it here.
> 
> IBM has a registered trademark on "z Systems" and on "System z." If I were an 
> IBM trademark lawyer I would be taking a very long, hard look at HP Z.
>  
Are trademarks case-sensitive?  I've long wondered about "zFS" vs. "ZFS"
(GIYF).  I don't know that either is trademarked, and I'm not allowed to do 
searches in such areas.

I know that The Workstation Group is constrained to use "Uni-XEDIT"
in order to avoid infringing on IBM's "XEDIT".  Does "HP Z" likewise avoid 
infringing on "Z"?  Can one trademark a single letter? I believe it's 
impossible to trademark any simple number ("9672"?  "3390"?).


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

Re: Downloading from Shopz

[J O Skip Robinson]

IIRC after some big digit calculations, I borrowed a couple of Mod 27s but 
never actually needed the second one for SererPac work. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gibney, David Allen,Jr
Sent: Monday, September 21, 2015 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Downloading from Shopz

   The calculation of space required 16489MB * 1.4 * 2 = 46169 cyl is more than 
a Mod 27. So, I'd like to use one M27 for NTS and another for SMPWKDIR.
Is there an option I'm missing to specify SMPWKDIR in the RECEIVE an order from 
the server option? Or do I need to edit the JCL before submitting.

   Or should I just add two M27's to the STORAGEPOOL and do it all in one big 
NTS ZFS file?

   The link from my order in Shopz to the current Using the Installation Dialog 
is broken with too many redirects.

Dave Gibney
Information Technology Services
Washington State University

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

Re: Recovery routine for ICHRTX00

[J O Skip Robinson]

One more recovery war story. So old that I cannot find a reference in Google. 
JES2 followed a long tradition when they added support in the 1980s for the 
8100 high speed laser printer. While older clackety-clack devices were fairly 
easy to handle, the 8100 was so complex that JES2 recovery code got more and 
more convoluted. At one point, developers decided that chuck-it-and-start-over 
was a more effective short-term strategy than trying to handle any of an 
increasing number of anomalies. The easiest way achieve a complete reset was a 
'controlled abend' in JES2 itself. Recovery code was that good.

So a 'fix' was released where at various points of unresolvable 8100 conundrum, 
a branch would be deliberately taken to a known abend location. This location 
would contain unexecutable code that would serve as an eyecatcher in S0C1 
analysis. Existing recovery routines were so good that the environment would be 
cleaned up and JES2 execution would continue after displaying some diagnostic 
printer information. Problem: the 'unexecutable code' was an EBCDIC string that 
looked to the CPU like a packed decimal instruction. So instead of the expected 
S0C1, JES2 took a S0C7 that the recovery routine thought was a true code 
failure. JES2 would go down. It didn't take long for an APAR fix that inserted 
binary zeroes in front of the EBCDIC string, but it was all pretty 
embarrassing. Or so I was told.   

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Monday, September 21, 2015 7:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

Thank you all very much for your inputs! I keep finding assembler more 
interesting the more I play with it.

The main reason I wanted a recovery routine for this exit is, as Walt 
described, any abends on the routine won't disable it (there is no simple way 
to disable it, other than "zap" an IEFBR14 on top of it) and it directly 
affects the issuer of the RACROUTE macro, so a simple recovery routine to 
terminate processing, returning with zeroes on R15 would pass control to the 
ESS.

It is very interesting that you lean against recovery routines on system exits, 
I was wanting to add some to our JES2 type 5 exits to prevent JES2 termination 
from an abend on a custom display commands, but I guess properly testing should 
prevent abends anyway; just something I wouldn't get from manuals, thanks for 
the hint.

I am trying to use this exit with REQUEST=FASTAUTH,CLASS=PROGRAM, which means a 
local lock may be held and I may be in problem state/key8 so I don't think I 
can really set a recovery routine in that state anyway, can I?

Having to IPL to implement/fallback on the routine means I will never really 
want to put it in a production environment.

Thanks again and best regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Saturday, September 19, 2015 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

My view of recovery routines may have been jaded by an experience early in my 
career. We sysprogs were implored to debug an application that was taking truly 
bizarre abends. One repeatable abend was in a DFSORT routine. Another was in a 
printer error handling routine. Trouble was, it was a straight COBOL program 
that was neither sorting nor printing. 

After spending hours on a Saturday morning with various sysprog tricks and 
tools, the problem boiled down to this. At initialization, the application 
called a years-old recovery setup program that no one knew anything about. 
Somewhere along the line, the COBOL program took a S0C7 as application programs 
are wont to do. The recovery routine got control and screwed up registers, 
which led to a wild branch that seemed most often to land in the middle of 
either DFSORT or hardware error correction modules. That inevitably led to a 
head-scratching S0C4. 

The solution was to replace the old recovery setup program with an IEFBR14. I 
have not been a fan of recovery routines ever since.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Saturday, September 19, 2015 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

>I lean against recovery actions for system exits

I don't specifically disagree with this. 

Three main reasons to have recovery come to mind
-- to release resources that you have obtained
-- to gath

Re: Recovery routine for ICHRTX00

[J O Skip Robinson]

My view of recovery routines may have been jaded by an experience early in my 
career. We sysprogs were implored to debug an application that was taking truly 
bizarre abends. One repeatable abend was in a DFSORT routine. Another was in a 
printer error handling routine. Trouble was, it was a straight COBOL program 
that was neither sorting nor printing. 

After spending hours on a Saturday morning with various sysprog tricks and 
tools, the problem boiled down to this. At initialization, the application 
called a years-old recovery setup program that no one knew anything about. 
Somewhere along the line, the COBOL program took a S0C7 as application programs 
are wont to do. The recovery routine got control and screwed up registers, 
which led to a wild branch that seemed most often to land in the middle of 
either DFSORT or hardware error correction modules. That inevitably led to a 
head-scratching S0C4. 

The solution was to replace the old recovery setup program with an IEFBR14. I 
have not been a fan of recovery routines ever since.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Saturday, September 19, 2015 6:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

>I lean against recovery actions for system exits

I don't specifically disagree with this. 

Three main reasons to have recovery come to mind
-- to release resources that you have obtained
-- to gather diagnostic data to help debug your error
-- to protect your caller from unexpectedly getting control in its recovery

The first is critical. But most exits do not obtain any resources (especially 
if they can be given dynamic storage to work with).
The second is, to a customer, "up to you".
The importance of third depends on the code calling the exit.

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: Recovery routine for ICHRTX00

[J O Skip Robinson]

This may sound heretical, but I lean against recovery actions for system exits. 
In most cases, the environment in which a system-defined exit runs is protected 
already. Messages are issued, dumps are taken, and some semblance of order is 
restored. In many cases the exit is disabled so that repetitive abends are 
avoided. What actions would a user recovery environment take better than this? 
Test your exit for as long as possible on a sandbox system. Then move it to a 
development system for as long as possible. At long last move it to production. 
A user written recovery routine would probably take longer to debug than 
whatever exit code caused a failure in the first place. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Friday, September 18, 2015 6:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Recovery routine for ICHRTX00

On Fri, 18 Sep 2015 18:01:16 +, Leonardo Vaz  wrote:

>I want to make use of the MVS router exit ICHRTX00 but I am having trouble 
>defining a recovery routine for it. I can't use ESTAE-like routines because 
>locks can be held when the exit is called and I can't use FRR because it needs 
>Supervisor state and PSW key 0 while the exit might be called in any state and 
>key.
>
>This will be my first real recovery routine so I'm pretty sure I'm missing 
>something basic, does anyone has any ideas?

If you want recovery in that exit you basically need to determine the 
environment you were invoked in and do something appropriate. As you've 
noticed, "appropriate" will vary depending on the request type and other 
options, and will depend in some cases on how the caller has decided to invoke 
you.

Some are simpler than others. REQUEST=VERIFY, for example, is documented as 
requiring an environment where an SVC can be issued, and does not require any 
particular state or key. So for that you could use an ESTAE(X). Each request 
type has a documented programming environment.

So you start out by figuring out what you want to do in the routine (which 
request type(s) you want to process), and what environments they can be called 
in. If you only want one particular request type, I would filter other requests 
out before establishing your recovery as that will make things much simpler.

By the way, starting your recovery adventure with ICHRTX00 may not be your best 
choice. You should probably learn about recovery using (a) some simpler routine 
that (b) won't kill your system if you get it wrong.

--
Walt


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

Re: MPF message processing not started for msg

[J O Skip Robinson]

When you get 'terminated at end of memory', all bets are off. This generally 
happens when the address space has run out of storage to the point that 
recovery routines cannot run. No recovery, no message processing, no 
preservation of sysout, etc. Your MPF entries indicate user exit processing. 
Probably not going to happen.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brad Wissink
Sent: Friday, September 18, 2015 2:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: MPF message processing not started for msg

I have a batch job that abended with the following messages .

N C00 H50A 2015260 17:03:16.08 J0684125   $HASP310 U0051299 
TERMINATED AT END OF MEMORY
M 400 H50A 2015260 17:03:16.25    IEF402I U0051299 
FAILED IN ADDRESS SPACE 0058 892   
E   892   SYSTEM ABEND 
S04F - REASON CODE F30901  

I have two MPF message exits defined for one for each message.   

/*$HASP310 - JOBNAME TERMINATED AT END OF MEMORY  */
$HASP310,SUP(NO),USEREXIT(SY159)
/*IEF402I - JOBNAME FAILED IN ADDRESS SPACE SYSTEM ABEND SXXX */
IEF402I,SUP(NO),USEREXIT(SY147) 

I did a 'D MPF' to make sure the exits were defined and active.

Does anyone have an idea on why the exits were not called?


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

Re: Dataset enqueue, how to find the culprit.

[J O Skip Robinson]

Well I'll be darned. I had not looked carefully at OP's message. That is 
*exactly* the context of the enqueue case I posted generically. SDAA004I is NDM 
or ConnectDirect depending on your perspective. We seem to have a lot of these 
self-clashes in our environment. I have not talked with the affected users, but 
it appears from the NDM control statements echoed in syslog that they are 
trying to send a data set from SystemX to SystemX with the same name. I suspect 
that they are requesting exclusive control of the 'target', i.e. OLD. But NDM 
is already using the data set as 'source', so it cannot obtain an exclusive 
enqueue for the same name. When the enqueue fails, the NDM process terminates, 
so a D GRS command a split second later shows no enqueue. That's how our 
(ancient) version of NDM works.

OP's situation may not be so simple, but I suggest looking the NDM process to 
see if there's a logic problem. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, September 18, 2015 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

So, it will depend on how often the TSO message for enqueue is produced.  If it 
is not frequent, you may have to set slips or live with rerunning the job.

Or if it is frequent, you might try adding a first step with DISP=OLD on your 
file.  then you would have a better idea of what is doing it or have the job 
wait until the file is freed.

You did not show what type of process is being used when this occurs.  So if 
this is REXX/CLIST that does LM functions, or an IEBCOPY, or other

Perhaps if you could describe the process and functions being used that this 
condition occurred,  we might provide better diags or alternatives.



Lizette


>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
>On Behalf Of Toni Cecil
>Sent: Friday, September 18, 2015 12:21 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Dataset enqueue, how to find the culprit.
>
>Hello,
>yesterday I got the following dsn enqueue:
>IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
>SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
>DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
>REQUESTED DATA SET NOT AVAILABLE.
>SDAB005I ALLOCATED TO ANOTHER JOB.
>
>Is there a way to find today, who was "locking" the pds library ?? I run DAF 
>tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
>but I didn't find anything, am I doing something wrong ?? Or is there any 
>other utility that could be more appropriate to check this "problem" ??
>
>Many thx, A.Cecilio.


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

Re: IPCS BLS18028I message suppression

[J O Skip Robinson]

I have no particular insight into this design, but I know a few things about 
TPUT vs. PUTLINE. For one thing, TPUT does not even work at all in batch. 
Neither can it be captured by OUTTRAP in foreground or background. PUTLINE 
works for both. So from the evidence presented, I would guess that BLS18028I 
issued in batch via PUTLINE but interactively via TPUT. So why the difference? 
Sounds like a bug, whether at the design level or in implementation. 

You could try first to get an APAR. Sigh, good luck. Failing that an RFE. I 
can't imagine that IBM would defend the current function as, Yes, that's 
exactly what we had in mind. Like the cat who bounces off the patio glass and 
tries to look purposefully nonchalant. An oops is an oops.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hardee, Chuck
Sent: Friday, September 18, 2015 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS BLS18028I message suppression

Interesting you should suggest that.
I did a batch IPCS run with my REXX and sure enough, in TSO/Batch the BLS18028I 
is captured by OUTTRAP and my REXX displays it as expected.

Question now is, why isn't it captured with the REXX is executed interactively?

So, if IPCS is executed in interactive TSO, the BLS18028I messages is issued to 
the "print" file that is displayed upon the terminal.
If, however, the same REXX is executed in TSO/Batch, the message is captured by 
OUTTRAP and placed in the stem that was passed in the first OUTTRAP call. It 
does not appear in the print file nor on the output associated with SYSTSPRT.

Interesting.

Since the primary use of this REXX will be batch as opposed to interactive, I 
can live with it I guess.
Just wish it would work the same regardless of environment.

C-

Charles (Chuck) Hardee
Senior Systems Engineer/Database Administration EAS Information Technology

Thermo Fisher Scientific
300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 
(412) 877-2809 | FAX: +1 (412) 490-9230 chuck.har...@thermofisher.com  | 
www.thermofisher.com

WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this 
e-mail or the information herein by anyone other than the intended recipient, 
or an employee or agent of a system responsible for delivering the message to 
the intended recipient, is prohibited. If you are not the intended recipient, 
please inform the sender and delete all copies.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J R
Sent: Friday, September 18, 2015 10:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPCS BLS18028I message suppression

Assuming it is a TPUT and assuming your logic doesn't depend on it, (yeah, I 
know) could you run it in batch?  This may prevent the message messing up your 
report.  
 

 
> Date: Fri, 18 Sep 2015 14:12:45 +
> From: chuck.hardee
/snip/
> Charles (Chuck) Hardee
> Senior Systems Engineer/Database Administration EAS Information 
> Technology

> > It's more frustrating than technical, but I'm trying to produce a 
> > custom
> report from
> > the dump and this message gets in the way of the report's information.

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

Re: Dataset enqueue, how to find the culprit.

[J O Skip Robinson]

As others have pointed out, enqueue is often a fleeting problem. By the time 
you get around to looking into it, it's long gone. After experiencing this 
problem a while back, we instructed our automation product to issue a D GRS 
command at the time of the conflict based on msgid IKJ56225I.  

IKJ56225I DATA SET already-in-use-dataset ALREADY IN USE, TRY LATER+
IKJ56225I DATA SET IS ALLOCATED TO ANOTHER JOB OR USER

D GRS,RES=(*, already-in-use-dataset)  

If you decide to implement a similar process, be aware of some gotchas. (1) The 
msgid appears twice. If you're not careful, you'll be issuing D GRS for dataset 
'IS'. Not a big deal, but it looks squirrelly. (2) The command itself might be 
issued too late to capture the contention. It can happen, for instance, that a 
task is actually enqueuing on itself (!). If the task terminates upon the 
enqueue, D GRS will find no contention. As odd as this sounds, we have seen 
cases like this. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steely, Mark
Sent: Friday, September 18, 2015 9:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

I created a REXX called WHI (who has it). Here is the code:

PROC 1 DSN   
/* CLRSCRN */
ISRDDN E 

Then in 3.4 enter WHI and it will display any enqueue. 

Thanks

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, September 18, 2015 11:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

Sorry, you have to hit PF1 twice to get the display I mentioned.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Friday, September 18, 2015 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Dataset enqueue, how to find the culprit.

One of the quickest ways, is to go to ISPF option 3.4, and pull up that 
dataset, and do a "R" to rename it(don’t really rename it though).  When it 
says 'dataset in use", hit PF1 and you get a list of jobs with enqueues on it.  

_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Toni Cecil
Sent: Friday, September 18, 2015 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Dataset enqueue, how to find the culprit.

Hello,
yesterday I got the following dsn enqueue:
IKJ56225I DATA SET TLF.ZPT.JCL.CNTL ALREADY IN USE, TRY LATER+ IKJ56225I DATA 
SET IS ALLOCATED TO ANOTHER JOB OR USER SDAA004I - RETURN=(DD),PERM=YES 
DSN=TLF.ZPT.JCL.CNTL(ZZZTXXXB), DISP=SHR SDAB005I - ERR=0210, INFO=, 
REQUESTED DATA SET NOT AVAILABLE.
SDAB005I ALLOCATED TO ANOTHER JOB.

Is there a way to find today, who was "locking" the pds library ?? I run DAF 
tool against TLF.ZPT.JCL.CNTL to see if something was shown about the enqueue, 
but I didn't find anything, am I doing something wrong ?? Or is there any other 
utility that could be more appropriate to check this "problem" ??

Many thx, A.Cecilio.


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

Re: RSU or maintenance level on a system

[J O Skip Robinson]

I have pitched this idea before. In a process that predates me in this shop, it 
was recognized that quite apart from auditors' poking around, we sysprogs 
needed a way to track a 'system package' at it migrated from one system to the 
next throughout the enterprise. The choice was to attach an arbitrary label to 
identify a particular *bundle* of maintenance that we would migrate stepwise 
from sandbox to production. The label looks like this

R##@

R is a constant, ## represents the OS release, and @ is letter that starts with 
A and get incremented for each new maintenance bundle. Currently we have R13@ 
for z/OS 1.13 and R21@ for z/OS 2.1. This label shows us at a glance which OS 
release a system is running, while the suffix allows us to track the migration 
of a particular bundle. We can easily tell which systems are at the same level, 
or which are up or down level if they're not the same. 

Once a bundle is ready for migration, we ZAP the new level into the nucleus in 
the user area. This is supported by a program/command that displays the level. 
Furthermore, we create members in text files like ISPF and OMVS that are easily 
viewed. The level can also be embedded in dataset names used for migration. 
Before we IPL a system at a new level, we run a Rexx that checks consistency 
among various components to verify that all relevant pieces have been migrated 
properly.  

This process has worked extremely well since the 1980s, before 'OS390' or 
'z/OS'. If you want something like this, you can start with the label. Then 
write some code to display it. Then build the label into a migration process. 
You can take it as far as you want.

As for auditors, they seem fixated on RACF and OMVS APARs. Something they must 
be taught in summer camp. The level strategy is really for us.  

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, September 16, 2015 7:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

Or another Technique could be to use the CVTUSER field.  Zap it with a Usermod 
to include the RSU with your live system
00D4  212 Signed   4 CVTUSER- FIELD AVAILABLE TO USER

Thought I do like the SYMBOLS option, but it is way too easy to change.  
Zapping the CVTUSER would take more effort and the USERMOD would remind you to 
do it.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> One more thing, IBM supplies the OS information for you using 
>   You cannot change it and you don't have to specify it in your 
> IEASYMxx member.
For us
> when we enter D SYMBOLS it's:  = "Z1020100".
> 
> 
> 
> ;-D an
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Blake, Daniel J [CTR]
> Sent: Wednesday, September 16, 2015 9:00 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> So give your auditors want they want using your IEASYMxx member.  Add 
> "SYMDEF(='.RSU1nnn')" to it and when they ask for your RSU 
> issue the "D SYMBOLS" command.  Just make sure nnn is your current RSU number.
> 
> 
> 
> ;-D an
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Wednesday, September 16, 2015 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RSU or maintenance level on a system
> 
> IBM is correct.  No way to do that.
> 
> _
> Dave Jousma
> Assistant Vice President, Mainframe Engineering david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lopez, Sharon
> Sent: Wednesday, September 16, 2015 8:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RSU or maintenance level on a system
> 
> I already posted this question to IBM but wanted to find out if others 
> are
getting this
> request from their auditors.
> 
> Our auditors want to be able to display the RSU or maintenance level 
> of our
z/OS
> system.  To my knowledge, there is no way to do that (IBM has also agreed).
Does
> anyone know if this is possible and are you getting the same request 
> from your auditors.? Keep in mind that our auditors do know z/OS or 
> mainframe.  It
sounds like
> they are used to seeing displays on other platforms with this 
> information with release and fix 

Re: RSU or maintenance level on a system

[J O Skip Robinson]

We may be zapping our label in NUC at an unconventional spot. IPLINFO does not 
show it. Here's what we see at IPL time. 

   IEA008I R13V   PARMS FOLLOW FOR z/OS 01.13.00 HBB7780

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Wednesday, September 16, 2015 9:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RSU or maintenance level on a system

On Wed, 16 Sep 2015 15:50:20 +, Bob Shannon  
wrote:

>We apply PUT maintenance, not RSU, but we have a usermod to update 
>CVTVERID with maintenance level. If you did that you could give the 
>auditors some Rexx code  to display the value.

My last post mentioned IPLINFO for displaying what Skip was referring to.  This 
is actually what IPLINFO will display if present.  

Mark
Best Regards / Mit freundlichen Grüßen,

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

Re: IPL Shutdown Problem

[J O Skip Robinson]

The problem is OP's shutdown logic. Not all tasks need to be shut down, and 
those that do not run under JES2 cannot be shut down using JES2 commands. The 
message 

   IEE707I $DA,XNOT EXECUTED

indicates that JES2 itself has already terminated and therefore cannot be 
called upon to shut down any other task. Since JES2 has already terminated, any 
tasks still running either do not need to be terminated (RACF task is one), or 
run SUB=MSTR and must be terminated via commands directly to the task itself.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, September 16, 2015 8:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

Stop the ZFS address space. It should stop as part of OMVS shut down anyway, 
but that's probably post-JES2 completion at your site. Issue command F 
OMVS,STOPPFS=ZFS. SYSLOG should close as part of normal JES2 shut down. Under 
z/OS 2.2, it is not recommended to run ZFS processing in its own address space.

Ant. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, 17 September 2015 12:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPL Shutdown Problem

The list is not the best place for an urgent issue.  But we will try to help.

If this is PRODUCTION, Just take a Stand alone dump and IPL.
If this is any other system  - how long can you be down before you IPL.

Normally I do the SA Dump and IPL.  I worry about why later.

You do not want to spend a lot of time trying to resolve things when you are 
IPL'ing.  Especially if this is a critical system.

You may need IBM's assistance in determine your shutdown issue, if you have not 
used IPCS on a Stand alone dump.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Meenakshi, Vinoth - CW
> Sent: Wednesday, September 16, 2015 8:03 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IPL Shutdown Problem
> 
> Hi All,
> 
> We are having issue with bringing down the JES2,two of the STC are 
> running and it's not coming down. Even Purge command is not working.
> 
>ZFS  STC03291 OMVS   15 EXECUTION  SYS9  SYS9
>   SYSLOG   STC09890 +MASTER+   15 EXECUTION  SYS9  SYS9
> 
> Even we can't able issue command from other systems.
> 
> RESPONSE=SYS9  IEE707I $DA,XNOT EXECUTED
> 
> Kindly guide us on this.
> 
> Thanks.
> Vinoth M


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

Re: SMPE -removal of USERMOD ++HOLD created instream

[J O Skip Robinson]

I thought that ++HOLD records always had a date, which the corresponding 
++RELEASE had to match. I just looked at a random held IBM PTF. It has a date. 
My user hold records have dates. 

Where did your ++HOLD come from? Could there be a construction error?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Monday, September 14, 2015 11:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE -removal of USERMOD ++HOLD created instream

Yep, doing a RECEIVE for a ++RELEASE HOLDDATA does not do anthing.

Before:

 Entry Type:  HOLDDATAZone Name: GLOBAL   
 Entry Name:  SZPE113 Zone Type: GLOBAL   
  
HOLD DATA 
--
++HOLD(SZPE113) SYSTEM REASON(ACTION) FMID(PKZ1500) .  
++HOLD(SZPE113) SYSTEM REASON(PSTINST) FMID(PKZ1500) DATE(15258) .  
   
*** Bottom of data ***

JCL:

//PROCESS EXEC SMPECC,RGN=512 
//SMPHOLD  DD  *  
++RELEASE(SZPE113) SYSTEM REASON(ACTION) FMID(PKZ1500) .  
//SYSINDD  *  
  SET BDY(GLOBAL) .   
  RECEIVE 
 HOLDDATA 
 LIST 
. 
/*


Result:


RECEIVE ++HOLD/++RELEASE SUMMARY REPORT 
   

   
   NOTE:  SMD NF   - SYSMOD NOT RELEASED - NOT FOUND IN 
THE GLOBAL ZONE
  RSN NF   - SYSMOD NOT RELEASED - NOT HELD FOR 
THIS REASONID  
  INT HLD  - SYSMOD NOT RELEASED - CANNOT 
RELEASE INTERNAL SYS HOLD

   
SYSMOD  TYPE STATUS   REASON  FMID  ++HOLD MCS 
STATEMENTS  

   
SZPE113 SYS  RSN NF   ACTION  PKZ1500   
   
 *** Bottom 
of Data ***


Suppose I will have to open a PMR.

Thanks
Bruce


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

Re: SMPE -removal of USERMOD ++HOLD created instream

[J O Skip Robinson]

I’m not sure exactly what you're doing, but maybe this will help. I create my 
own ++HOLD records occasionally to prevent a PTF from installing before a 
corresponding 'conditioning PTF' is running on all sharing systems. Haven't 
seen one for a while, but these have typically been for a sysplex XCF change 
that is accomplished in two stages. An IBM ++HOLD instructs me to hold off 
applying the final PTF until all systems are ready for it. My ++HOLD keeps it 
from going on too soon, since only I know the downstream runtime environment. 
The user reason documents the PTF relationship. Once I'm ready for the final 
PTF, I release my ++HOLD as shown below. Note that this is a standalone SMPE 
job not embedded in any sysmod. 

//SMPHOLD  DD *   
++RELEASE(UA70373) FMID(HDZ1D10) USER REASON(UA70229) DATE(14010) .   
//*   
//SYSINDD *   
  SETBOUNDARY(GLOBAL) .   
  RECEIVE 
 HOLDDATA  LIST . 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bruce Hewson
Sent: Friday, September 11, 2015 10:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE -removal of USERMOD ++HOLD created instream

Hi all,

I have been changing ++HOLD REASON codes for some USERMODs.

But I found that the previous ++HOLD does not disappear nicely.

I tried using ++RELEASE but that fails. Something about the ++HOLD being 
encoded inside the ++USERMOD.

Does anyone have a way to remove these ++HOLDs nicely?

Thanks
Bruce


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

Re: SYMUP - Umod

[J O Skip Robinson]

REWORK can be any string you choose up to eight characters. I use REWORK on all 
of my usermods. I use the sysmod update date in Julian format, e.g. 2015157, 
which I like because that shows up in an SMPE display of the sysmod. This date 
format (seven characters) allows you to add an eighth character in the unlikely 
event (!) that the first APPLY does not work and you have to fix the mod and 
reRECEIVE it. A sysmod can be RECEIVEd over and over as long as the new REWORK 
value is higher than the old.  

A personal corollary of my rule is that if I have used up all suffixes 0 - 9 
and still can't get it right, it's time to go home and try again the next day. 
;-)

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nathan Astle
Sent: Monday, September 14, 2015 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SYMUP - Umod

Hello All,

I am in a process of customizing for z/OS upgrade. So one Item which came to my 
list was applying SYMUP UMOD.

I was referring : http://www.redbooks.ibm.com/redbooks/pdfs/sg247328.pdf

++USERMOD(umod_name) REWORK(2005001). ++VER(Z038) FMID(HBB7709) . ++JCLIN .
//LKED EXEC PGM=IEWL,PARM='LIST,MAP,XREF,NCAL,LET' //SYSLMOD DD 
DSN=LINKLIB,DISP=SHR //SAMPLIB DD DSN=SAMPLIB //SYSLIN DD * INCLUDE
SAMPLIB(IEASYMUP) SETCODE AC(1) ENTRY IEASYMUP NAME IEASYMUP(R)
++MOD(IEASYMUP) DISTLIB(SAMPLIB) LKLIB(SAMPLIB). $$ //SMPCNTL DD * SET
BDY(GLOBAL) . RECEIVE S(umod_name) . SET BDY(MVST100) . APPLY CHECK
S(umod_name) REDO RC(RECEIVE=0) . APPLY S(umod_name) REDO RC(APPLY=0) .
UCLIN RC(APPLY=4) . REP SAMP(IEASYMUP) RMID(umod_name) . ENDUCL . /*


Sorry if the above information scrambled. I was just wondering what could be 
Ideal value for REWORK on the USERMOD statement.

Could someone please clarify or guide ? I am going from z/OS 1.13 to z/OS
2.1


Regards,
Nathan


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