Re: Fwd: Apache Spark on z listserver or forum?

[Bill Woodger]

StackOverflow and other StackExchange sites (like SuperUser) are Question and 
Answer sites. That doesn't mean they don't work, it means they are different. 
They are not a Forum, nor a Mailing List. On SO you'd ask about programming. On 
SU about setting up software. You'd get answers. Which are specific, concrete, 
answers. Comments on questions and answers can be made (once you have 50 
reputation points) to elicit more information or make the speculative "Did you 
read...?".

The arrangement is "community regulated" with Moderators in addition.

A huge advantage (I'd hope it would be) for Apache Spark is that some 
developers of Spark-for-elsewhere attend and are active contributors.

It could work very well, but you have to remember (and be aware of first) the 
rules, for both asking and answering. It is not anything like 
IBM-MAIN-just-with-fancier-stuff.

For developers of a product, stating affiliation in an answer (you can also 
mention in your "profile") is always good, and at times mandatory. Questions on 
IBM's implementation of Spark will be very welcome, and will have a natural 
tendency to "promote". Outright promotion is problematic. Being clear with 
affiliation helps around the borders.


On Sat, 7 Jan 2017 11:16:09 +0800, David Crayford  wrote:

>>> For us, it will be Spark on z/OS..
>> Glad to hear it!  Sounds like you maybe have some questions.  Feel free to
>> mail me directly (ef...@us.ibm.com), or post here until I see what I can
>> get set up for a Spark-z/OS-specific mailing list.
>
>Why not just use StackOverflow? IBM already use SO for WAS Libery
>questions to good effect. IMO, SO is far superior to mailing list
>servers, especially for searching for answers.
>
>
>> Thanks,
>> Erin
>> ef...@us.ibm.com
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: DNS, Resolver, and /etc/hosts

[Itschak Mugzach]

Resolver is a kind of dns forwarder. This is just a front-end to your dns
that usually runs outside of the mainframe. The only dns redolution it make
is those defined in hosts file.

ITschak

בתאריך 7 בינו 2017 06:01,‏ "Phil Smith"  כתב:

Mike Schwab wrote:
>https://support.microsoft.com/en-us/kb/172218
>1, itself, 2 hosts file, 3 DNS, 4 NetBios.  Stops at first result.

I'm sorry, what does that have to do with z/OS? I realize it stops at the
first result-that's what resolution would be trying to do, no?

Signed,
Confused

--
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: DNS, Resolver, and /etc/hosts

[Phil Smith]

Mike Schwab wrote:
>https://support.microsoft.com/en-us/kb/172218
>1, itself, 2 hosts file, 3 DNS, 4 NetBios.  Stops at first result.

I'm sorry, what does that have to do with z/OS? I realize it stops at the first 
result-that's what resolution would be trying to do, no?

Signed,
Confused

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

Re: Fwd: Apache Spark on z listserver or forum?

[David Crayford]

For us, it will be Spark on z/OS..

Glad to hear it!  Sounds like you maybe have some questions.  Feel free to
mail me directly (ef...@us.ibm.com), or post here until I see what I can
get set up for a Spark-z/OS-specific mailing list.


Why not just use StackOverflow? IBM already use SO for WAS Libery 
questions to good effect. IMO, SO is far superior to mailing list 
servers, especially for searching for answers.




Thanks,
Erin
ef...@us.ibm.com

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


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

Re: Fwd: Apache Spark on z listserver or forum?

[Roger Lowe]

On Fri, 6 Jan 2017 19:08:53 -0500, Erin Farr  wrote:

>>> Are you asking about Spark on z/OS, or on Linux on z?
>>> Regardless, I don't know of any forum specific to Spark on z (z/OS nor
>Linux on z.)
>>> I'm development team lead for Spark on z/OS.  I'm willing to investigate
>setting one up for Spark on z/OS if folks are interested.
>
>> For us, it will be Spark on z/OS..
>
>Glad to hear it!  Sounds like you maybe have some questions.  Feel free to
>mail me directly (ef...@us.ibm.com), or post here until I see what I can
>get set up for a Spark-z/OS-specific mailing list.
>
Thanks Erin - yes, we do have some questions, so we will email you directly for 
the time being.

Roger

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

Re: Fwd: Apache Spark on z listserver or forum?

[Erin Farr]

>> Are you asking about Spark on z/OS, or on Linux on z?
>> Regardless, I don't know of any forum specific to Spark on z (z/OS nor
Linux on z.)
>> I'm development team lead for Spark on z/OS.  I'm willing to investigate
setting one up for Spark on z/OS if folks are interested.

> For us, it will be Spark on z/OS..

Glad to hear it!  Sounds like you maybe have some questions.  Feel free to
mail me directly (ef...@us.ibm.com), or post here until I see what I can
get set up for a Spark-z/OS-specific mailing list.

Thanks,
Erin
ef...@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: Addressing Question

[Tom Ross]

>Tom,
>
>We run our compiles using COBOL v4.2 as
>
>CBL. ...NODYN,RES,RENT,DATA(31)
>
>Run options via CEEOPTS is ALL31(ON) ..
>
>This for the caller, using AMODE(31) and RMODE ANY for the binder.
>
>We call like this call 'xx' using xx
>
>Does this imply AMODE switching ?

No.  AMODE switching is when an AMODE 31 program calls a separate executable
(Program Object or Load Module) that has AMODE 24, or from AMODE 24 to
to AMODE 31.  If the programs are bound together it is only possible to have
different AMODEsi if you have a Program Object with some segments AMODE 31
and other segments AMODE 24.  Load Modules have hte same AMODE for all entry
points.  Finally, COBOL dynamic CALL requires separate executables, and COBOL
dynamic CALL support mode switching in that case.  You can get COBOL
dynamic CALL 3 ways:
1) Call 'literal' with DYNAM compiler option
2) Call identifier  (DYNAM/NODYNA do not affect these)
3) >>CALLINTERFACE DYNAM
   Call 'literal'

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

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

Re: Fwd: Apache Spark on z listserver or forum?

[Roger Lowe]

On Fri, 6 Jan 2017 16:50:01 -0500, Erin Farr  wrote:

>>
>> Hi,
>> Our site is currently in the very early stages of dabbling with
>> Apache Spark on z and was wondering if there is a Listserver or Forum
>> specifically for Apache Spark on z.
>>
>> Thanks, Roger
>
>Are you asking about Spark on z/OS, or on Linux on z?
>Regardless, I don't know of any forum specific to Spark on z (z/OS nor
>Linux on z.)
>I'm development team lead for Spark on z/OS.  I'm willing to investigate
>setting one up for Spark on z/OS if folks are interested.
>
For us, it will be Spark on z/OS..

Roger

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

Re: IBM LOGREC Analysis

[Mike Schwab]

Even for non-IBM hardware, we opened a PMR with IBM (and the other
vendor) for them to check out the logrec.  Always.

On Fri, Jan 6, 2017 at 2:58 PM, Jesse 1 Robinson
 wrote:
> OK, I have to say it. Especially given the central role that LOGREC plays in 
> mainframe software and hardware diagnosis, EREP is the least user-friendly 
> utility that IBM supplies. And has been so for decades. The answer is almost 
> always there. Good luck in finding it yourself.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Elardus Engelbrecht
> Sent: Friday, January 06, 2017 12:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: IBM LOGREC Analysis
>
> Dyck, Lionel B. (TRA) wrote:
>
>>Useful but just generates the IFCEREP1 reporting from what I can see.
>>I'm looking for some analytics (however minimal)
>
> Beside LOGREC viewer, there is nothing available AFAIK to do analytics work. 
> (No PFA, CBTTAPE or other expensive things for us at this time.)
>
> What a pity, since LOGREC is sometimes the last bastion to try fixing 
> something weird...
>
>
> In the absence of that analysis ability, I usually, when extracting LOGREC, I 
> generate 4 reports with large TABSIZE:
>
> PRINT=AL(Full details)
> EVENTS
> SYSUM
> SYSEXN
>
> (System logger, all LPARs, usual defaults with date/time overrides if needed.)
>
> All of them need serious + tedious IEBALL to get an overview starting with 
> EVENTS of course.
>
> Good luck!
>
> 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



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

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

Re: Fwd: Apache Spark on z listserver or forum?

[Erin Farr]

>
> Hi,
> Our site is currently in the very early stages of dabbling with
> Apache Spark on z and was wondering if there is a Listserver or Forum
> specifically for Apache Spark on z.
>
> Thanks, Roger

Are you asking about Spark on z/OS, or on Linux on z?
Regardless, I don't know of any forum specific to Spark on z (z/OS nor
Linux on z.)
I'm development team lead for Spark on z/OS.  I'm willing to investigate
setting one up for Spark on z/OS if folks are interested.

Thanks,
Erin Farr
ef...@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: DNS, Resolver, and /etc/hosts

[Mike Schwab]

https://support.microsoft.com/en-us/kb/172218

1, itself, 2 hosts file, 3 DNS, 4 NetBios.  Stops at first result.

On Fri, Jan 6, 2017 at 12:16 PM, Phil Smith  wrote:
> Anyone got a pointer to a coherent discussion of these three options for name 
> resolution? I know how DNS and /etc/hosts work, and know enough about the 
> Resolver to use and configure it for hosts that aren't in DNS.
>
> What I want to understand is (at least):
>
> 1) Is the Resolver always involved? That is, is it the equivalent of 
> named on *ix?
>
> 2) How is the hierarchy determined? I *think* I've read that you can have 
> z/OS use more than one of these; can you use all three? In which order?
>
> I've spent some time looking thru doc but haven't found this, though I'm sure 
> it's there.
>
> Thanks.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: IBM LOGREC Analysis

[Jesse 1 Robinson]

OK, I have to say it. Especially given the central role that LOGREC plays in 
mainframe software and hardware diagnosis, EREP is the least user-friendly 
utility that IBM supplies. And has been so for decades. The answer is almost 
always there. Good luck in finding it yourself. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Friday, January 06, 2017 12:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IBM LOGREC Analysis

Dyck, Lionel B. (TRA) wrote:

>Useful but just generates the IFCEREP1 reporting from what I can see.  
>I'm looking for some analytics (however minimal)

Beside LOGREC viewer, there is nothing available AFAIK to do analytics work. 
(No PFA, CBTTAPE or other expensive things for us at this time.)

What a pity, since LOGREC is sometimes the last bastion to try fixing something 
weird...


In the absence of that analysis ability, I usually, when extracting LOGREC, I 
generate 4 reports with large TABSIZE: 

PRINT=AL(Full details)
EVENTS
SYSUM
SYSEXN

(System logger, all LPARs, usual defaults with date/time overrides if needed.)

All of them need serious + tedious IEBALL to get an overview starting with 
EVENTS of course.

Good luck!

Groete / Greetings
Elardus Engelbrecht


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

Re: IBM LOGREC Analysis

[Elardus Engelbrecht]

Dyck, Lionel B. (TRA) wrote:

>Useful but just generates the IFCEREP1 reporting from what I can see.  I'm 
>looking for some analytics (however minimal)

Beside LOGREC viewer, there is nothing available AFAIK to do analytics work. 
(No PFA, CBTTAPE or other expensive things for us at this time.)

What a pity, since LOGREC is sometimes the last bastion to try fixing something 
weird...


In the absence of that analysis ability, I usually, when extracting LOGREC, I 
generate 4 reports with large TABSIZE: 

PRINT=AL(Full details)
EVENTS
SYSUM 
SYSEXN

(System logger, all LPARs, usual defaults with date/time overrides if needed.)

All of them need serious + tedious IEBALL to get an overview starting with 
EVENTS of course.

Good luck!

Groete / Greetings
Elardus Engelbrecht

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

Logrec analysis

[Dyck, Lionel B. (TRA)]

Discovered that MXG has the ability to report on Logrec (aka EREP) records in a 
way that makes it much easier to understand than the standard IFCEREP1 report.  
Worth checking out if you have MXG - and if you don't then you should :)


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services
Office: 512-326-6173


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

[Dyck, Lionel B. (TRA)]

Interesting - something to look at as we don't run it now.

Thank you

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

One more item: Would PFA (Predictive Failure Analysis) be of help?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Yeah, I gave it a shot.  Even many years ago when I did something that reviewed 
LOGREC, it really did not do any analysis, just built a web page(s) with an 
index.

I guess MXG or CBTTAPE File 47, both use SAS to read the LOGREC data set, but 
from there you would have determine what analysis you want, hardware or 
software?  (and all the subcategories for them, tape, disk, other?)

A Google searc with "analysis of logrec" resulted in some things, but mostly 
priced services.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Thank you - I have tried this and it is a simple way to run IFCEREP1 but there 
is no analysis - it does make it easier to use however.

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

File 857?

//***FILE 857 is from Marco Serafini and contains a REXX EXEC and   *   FILE 857
//*   several panels, to execute an interactive report  *   FILE 857
//*   against the active LOGREC dataset, or against any *   FILE 857
//*   archived copy of LOGREC.  Tested at z/OS 1.6 thru *   FILE 857
//*   1.10 by the author, and at 1.12 by Sam Golob. *   FILE 857
//* *   FILE 857
//*   This system is very nice, to be able to see what is   *   FILE 857
//*   in LOGREC, with almost no effort. *   FILE 857
//* *   FILE 857
//*   There is also some word doc, but it is in Italian.*   FILE 857
//*   Still, you can get a ton of use out of this package   *   FILE 857
//*   without reading the words of the doc, but by looking  *   FILE 857
//*   at the illustrations. *   FILE 857
//* *   FILE 857
//*   Just copy 6 panels into your panel library and run*   FILE 857
//*   the EXEC. *   FILE 857
//* *   FILE 857
//*   email:  marco.seraf...@t-systems.it   *   FILE 857
//* *   FILE 857
//*   See member $$NOTE1 for more contact information.  *   FILE 857

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe 

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Tony Harminc]

On 6 January 2017 at 08:51, Pommier, Rex  wrote:

>> What's the reason code with the $BR1?
> Hi Tony,
>
> There wasn't one.  The manual says the reason code is optional and for $BR1, 
> it got optioned out.
>
> *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS - z11 
> MODE
> *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1

Glancing at the code (yes, JES2 is still mostly not OCO), it appears
that for a catastrophic ERROR (vs ABEND) only a reason code of 0 leads
to this format of the $HASP095 message. For a non-zero reason code it
would be e.g.
$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1 (004)

Reason code 0 for a $BR1 is reached only by one path in HASPCKPT, and
that is a non-zero RC from the $DOGBERT service. If I'm right, that RC
is in R15 and survives to be displayed in the $HASP088, and is 8.
Which in turn means that $DOGBERT had to $WAIT (presumably for
checkpoint I/O), but the caller could not tolerate such a wait. There
are at least six ways to get to this RC=8 within $DOGBERT and the
routines it calls.

And that's about as far as I'm going with this, since (a) I'm not IBM
support, (b) I have a day job, (c) I'm a couple of decades out of
doing JES2 stuff, and (d) I my analysis could be anywhere up to 100%
wrong, and I don't want to send you off on a wild goose chase. Fun
while it lasted...

Tony H.

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Art Gutowski]

On Thu, 5 Jan 2017 12:19:38 -0600, Tom Marchant  
wrote:

>On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:
>
>>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone> 
>>COMPAREDTO(<2.2 zone>) and vice versa.
>
>Is that going to give you any useful information, Art? I believe that it is 
>possible to code the ++VER in a PTF so that the same PTF can be applied 
>to two different FMIDs, but I can't remember ever seeing it.
>
>Of course, I have been wrong before...

Duh, yes, I meant:

REPORT CROSSZONE
lists conditional requisites that must be installed in certain
zones because of SYSMODs that are installed in other zones. 
 

If memory serves, I did once upon a midnight dreary use multiple ++VER for a 
USERMOD.  Not quite sure why, but I think it was due to sharing a GLOBAL zone 
for multiple releases, and didn't want to have to change USERMOD names nor 
REJECT/RECEIVE during parallel testing/deployment.  REPORT SYSMODS would be 
marginally useful in this specific case.

Also, glad someone else pointed out LARGEDS=ALLOWED.  I thought that was a 
prereq for MODE=z11, so I neglected to mention it.

Regards,
Art Gutowski
General Motors, LLC

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

[Nims,Alva John (Al)]

One more item: Would PFA (Predictive Failure Analysis) be of help?

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Yeah, I gave it a shot.  Even many years ago when I did something that reviewed 
LOGREC, it really did not do any analysis, just built a web page(s) with an 
index.

I guess MXG or CBTTAPE File 47, both use SAS to read the LOGREC data set, but 
from there you would have determine what analysis you want, hardware or 
software?  (and all the subcategories for them, tape, disk, other?)

A Google searc with "analysis of logrec" resulted in some things, but mostly 
priced services.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Thank you - I have tried this and it is a simple way to run IFCEREP1 but there 
is no analysis - it does make it easier to use however.

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

File 857?

//***FILE 857 is from Marco Serafini and contains a REXX EXEC and   *   FILE 857
//*   several panels, to execute an interactive report  *   FILE 857
//*   against the active LOGREC dataset, or against any *   FILE 857
//*   archived copy of LOGREC.  Tested at z/OS 1.6 thru *   FILE 857
//*   1.10 by the author, and at 1.12 by Sam Golob. *   FILE 857
//* *   FILE 857
//*   This system is very nice, to be able to see what is   *   FILE 857
//*   in LOGREC, with almost no effort. *   FILE 857
//* *   FILE 857
//*   There is also some word doc, but it is in Italian.*   FILE 857
//*   Still, you can get a ton of use out of this package   *   FILE 857
//*   without reading the words of the doc, but by looking  *   FILE 857
//*   at the illustrations. *   FILE 857
//* *   FILE 857
//*   Just copy 6 panels into your panel library and run*   FILE 857
//*   the EXEC. *   FILE 857
//* *   FILE 857
//*   email:  marco.seraf...@t-systems.it   *   FILE 857
//* *   FILE 857
//*   See member $$NOTE1 for more contact information.  *   FILE 857

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC 
> data in a more intelligent manner than the IFCEREP1 reports?
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and 
> Technology, IT 

Re: [EXTERNAL] Re: IBM LOGREC Analysis

[Nims,Alva John (Al)]

Yeah, I gave it a shot.  Even many years ago when I did something that reviewed 
LOGREC, it really did not do any analysis, just built a web page(s) with an 
index.

I guess MXG or CBTTAPE File 47, both use SAS to read the LOGREC data set, but 
from there you would have determine what analysis you want, hardware or 
software?  (and all the subcategories for them, tape, disk, other?)

A Google searc with "analysis of logrec" resulted in some things, but mostly 
priced services.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Thank you - I have tried this and it is a simple way to run IFCEREP1 but there 
is no analysis - it does make it easier to use however.

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

File 857?

//***FILE 857 is from Marco Serafini and contains a REXX EXEC and   *   FILE 857
//*   several panels, to execute an interactive report  *   FILE 857
//*   against the active LOGREC dataset, or against any *   FILE 857
//*   archived copy of LOGREC.  Tested at z/OS 1.6 thru *   FILE 857
//*   1.10 by the author, and at 1.12 by Sam Golob. *   FILE 857
//* *   FILE 857
//*   This system is very nice, to be able to see what is   *   FILE 857
//*   in LOGREC, with almost no effort. *   FILE 857
//* *   FILE 857
//*   There is also some word doc, but it is in Italian.*   FILE 857
//*   Still, you can get a ton of use out of this package   *   FILE 857
//*   without reading the words of the doc, but by looking  *   FILE 857
//*   at the illustrations. *   FILE 857
//* *   FILE 857
//*   Just copy 6 panels into your panel library and run*   FILE 857
//*   the EXEC. *   FILE 857
//* *   FILE 857
//*   email:  marco.seraf...@t-systems.it   *   FILE 857
//* *   FILE 857
//*   See member $$NOTE1 for more contact information.  *   FILE 857

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC 
> data in a more intelligent manner than the IFCEREP1 reports?
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and 
> Technology, IT Operations and Services
> 

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

Re: [EXTERNAL] Re: IBM LOGREC Analysis

[Dyck, Lionel B. (TRA)]

Thank you - I have tried this and it is a simple way to run IFCEREP1 but there 
is no analysis - it does make it easier to use however.

--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Friday, January 06, 2017 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

File 857?

//***FILE 857 is from Marco Serafini and contains a REXX EXEC and   *   FILE 857
//*   several panels, to execute an interactive report  *   FILE 857
//*   against the active LOGREC dataset, or against any *   FILE 857
//*   archived copy of LOGREC.  Tested at z/OS 1.6 thru *   FILE 857
//*   1.10 by the author, and at 1.12 by Sam Golob. *   FILE 857
//* *   FILE 857
//*   This system is very nice, to be able to see what is   *   FILE 857
//*   in LOGREC, with almost no effort. *   FILE 857
//* *   FILE 857
//*   There is also some word doc, but it is in Italian.*   FILE 857
//*   Still, you can get a ton of use out of this package   *   FILE 857
//*   without reading the words of the doc, but by looking  *   FILE 857
//*   at the illustrations. *   FILE 857
//* *   FILE 857
//*   Just copy 6 panels into your panel library and run*   FILE 857
//*   the EXEC. *   FILE 857
//* *   FILE 857
//*   email:  marco.seraf...@t-systems.it   *   FILE 857
//* *   FILE 857
//*   See member $$NOTE1 for more contact information.  *   FILE 857

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC 
> data in a more intelligent manner than the IFCEREP1 reports?
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and 
> Technology, IT Operations and Services
> 

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

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

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

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Tom Marchant]

On Fri, 6 Jan 2017 17:35:39 +, Pommier, Rex wrote:

>Yes, I am using FlashCopy to create the clones.  I'm re-flashing the 
>spool and checkpoint volumes for subsequent tests because I have 
>others doing other testing of the z/OS 2.2 upgrade so I'm bringing it 
>up cold so they can do their testing.  Once I get a new idea based 
>on the feedback I'm getting, I'll shut it down and reflash my 5 spool 
>volumes and 2 checkpoints and re-IPL.  Much faster than re-flashing 
>the entire LPAR.

I didn't notice, did you try to IPL z/OS 1.13 with the cloned spool?
If so, were there any problems?

-- 
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] Re: IBM LOGREC Analysis

[Nims,Alva John (Al)]

File 857?

//***FILE 857 is from Marco Serafini and contains a REXX EXEC and   *   FILE 857
//*   several panels, to execute an interactive report  *   FILE 857
//*   against the active LOGREC dataset, or against any *   FILE 857
//*   archived copy of LOGREC.  Tested at z/OS 1.6 thru *   FILE 857
//*   1.10 by the author, and at 1.12 by Sam Golob. *   FILE 857
//* *   FILE 857
//*   This system is very nice, to be able to see what is   *   FILE 857
//*   in LOGREC, with almost no effort. *   FILE 857
//* *   FILE 857
//*   There is also some word doc, but it is in Italian.*   FILE 857
//*   Still, you can get a ton of use out of this package   *   FILE 857
//*   without reading the words of the doc, but by looking  *   FILE 857
//*   at the illustrations. *   FILE 857
//* *   FILE 857
//*   Just copy 6 panels into your panel library and run*   FILE 857
//*   the EXEC. *   FILE 857
//* *   FILE 857
//*   email:  marco.seraf...@t-systems.it   *   FILE 857
//* *   FILE 857
//*   See member $$NOTE1 for more contact information.  *   FILE 857

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: IBM LOGREC Analysis

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC 
> data in a more intelligent manner than the IFCEREP1 reports?
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and 
> Technology, IT Operations and Services
> 

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

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

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

DNS, Resolver, and /etc/hosts

[Phil Smith]

Anyone got a pointer to a coherent discussion of these three options for name 
resolution? I know how DNS and /etc/hosts work, and know enough about the 
Resolver to use and configure it for hosts that aren't in DNS.

What I want to understand is (at least):

1) Is the Resolver always involved? That is, is it the equivalent of named 
on *ix?

2) How is the hierarchy determined? I *think* I've read that you can have 
z/OS use more than one of these; can you use all three? In which order?

I've spent some time looking thru doc but haven't found this, though I'm sure 
it's there.

Thanks.

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

Re: IBM LOGREC Analysis

[Dyck, Lionel B. (TRA)]

Useful but just generates the IFCEREP1 reporting from what I can see.  I'm 
looking for some analytics (however minimal)


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mazer Ken G
Sent: Friday, January 06, 2017 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Lionel,

How about the IBM Logrec Viewer V1.1 see 
http://www-03.ibm.com/systems/z/os/zos/tools/downloads/logrec-viewer.html

Ken Mazer


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 11:31 AM
To: IBM-MAIN@listserv.ua.edu
Subject: IBM LOGREC Analysis

Is anyone aware of any tool that will analyze and report on LOGREC data in a 
more intelligent manner than the IFCEREP1 reports?

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

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

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

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

$DEXIT,STATUS=ENABLED gives me exits 0,1,15,40 are active in production, and 
only 0 on the sandbox.  My JES2PARM shows nothing for exit 0.

From the sandbox:

$DEXIT,STATUS=ENABLED 
$HASP823 EXIT(0) 211  
$HASP823 EXIT(0)STATUS=ENABLED,ENVIRON=JES2,ROUTINES=(),  
$HASP823SPLEVEL=CHECK,TRACE=YES,USECOUNT=0


This is my JES2PARM for production 1.13:

LOADMOD(JES2XIT1) 
LOADMOD(JESXIT15) 
LOADMOD(JS2XIT40) 
EXIT(1)  ROUTINE=JS2XIT1,TRACE=NO 
EXIT(15) ROUTINE=JS2XIT15,TRACE=NO
EXIT(40) ROUTINE=JS2XIT40,TRACE=NO

For 2.2, we have removed exit 40 because we don't use it.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Just for giggles, do a $DEXIT(*) (check my memory for correct command) and see 
if there are any exits active

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 9:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Interesting idea, Lizette.  I just tried again, after removing all 
> EXIT statements from my JES2PARM.  Same result, $BR1 catastrophic error.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Friday, January 06, 2017 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Allan,
> 
> True.  The intent was to think about
>  1) Any JES2 Exits in place that might be causing the issue
>  2) Are all Vendor related fixes for JES2 installed for the migration.
> 
> Just because something is old, does not mean it could not provide 
> insight on an issue.
> 
> :-D
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller
> > Sent: Friday, January 06, 2017 7:54 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > That APAR is ancient. The current numbers APAR numbers are OA6.
> > Seems like
> > OA25662 would be circa z/OS 1.4 vintage.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler
> > Sent: Friday, January 6, 2017 8:50 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > You did not indicate if you have MVS Solutions Thruput Manager.
> >
> > If you do, I found this on their website
> >
> > PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
> > $BR1 ABEND
> > after IBM APAR OA25562.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
> > > Sent: Friday, January 06, 2017 6:51 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > > catastrophic error
> > >
> > > Hi Tony,
> > >
> > > There wasn't one.  The manual says the reason code is optional and 
> > > for $BR1, it got optioned out.
> > >
> > > *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> > >  * z11 MODE
> > >  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
> > >   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
> > >   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
> > >   $HASP088 PCE  = INIT (165B6008)
> > >   $HASP088 R0   =   3A54502C  342C  
> > >   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
> > >   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
> > >   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> > >
> > > This was followed by the 02D abend.
> > >
> > > Thanks,
> > >
> > > Rex
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List 
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
> > > Sent: Thursday, January 05, 2017 7:02 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > > catastrophic error
> > >
> > > On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > > > 2)  $BR1 in M gives me "lots" of good information .
> > > > The doc says "JES2 initialization processing encountered an 
> > > > error examining
> > > the BERT maps" and the 

Re: IBM LOGREC Analysis

[Mazer Ken G]

Lionel,

How about the IBM Logrec Viewer V1.1 see
http://www-03.ibm.com/systems/z/os/zos/tools/downloads/logrec-viewer.html

Ken Mazer


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Dyck, Lionel B. (TRA)
Sent: Friday, January 06, 2017 11:31 AM
To: IBM-MAIN@listserv.ua.edu
Subject: IBM LOGREC Analysis

Is anyone aware of any tool that will analyze and report on LOGREC data in a 
more intelligent manner than the IFCEREP1 reports?

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology, 
IT Operations and Services

--
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: IEC141I 013-A8: how to read VS data sets?

[Mike Shaw]

On 1/5/2017 7:28 PM, Jesse 1 Robinson wrote:

Pretty much I would say. Just want to point out that FBS and VBS are worlds 
apart. As discussed, the 'S' in VBS is 'spanned'. The 'S' in FBS means 
'standard' or some such. This guarantees that the file has no short blocks 
other than the very last one. A file written 'normally' is usually FBS whether 
labeled that way or not, but one written to multiple times via DISP=MOD is 
almost certain to have many short blocks, one for each time the file is closed 
and then reopened.

I doubt that modern processing really cares, but once upon a time FBS was more 
efficient than FB to read because I/O routines did not have to check for and 
handle a short block on every read.



I used VBS data sets in an Assembler application that processed health 
care claims under OS/MVS 21.8 back in 1978. 'S' meant spanned then and 
it means spanned now.


No magic is required to read and/or write VBS or VS records, just 
knowledge of what the possible values for the RDWs are.


Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Dale,

Yes, I am using FlashCopy to create the clones.  I'm re-flashing the spool and 
checkpoint volumes for subsequent tests because I have others doing other 
testing of the z/OS 2.2 upgrade so I'm bringing it up cold so they can do their 
testing.  Once I get a new idea based on the feedback I'm getting, I'll shut it 
down and reflash my 5 spool volumes and 2 checkpoints and re-IPL.  Much faster 
than re-flashing the entire LPAR.  :-)

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dale R. Smith
Sent: Friday, January 06, 2017 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

On Thu, 5 Jan 2017 03:49:42 +, Pommier, Rex  wrote:

>Hello list,
>
>Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our sandbox 
>using a clone of one of our production LPARs.  Tried to bring JES2 up warm and 
>got a $HASP095 catastrophic error code=$BR1.  We are running z11 mode on 1.13 
>and the $HASP493 warm start message verified z11 mode.  I got a system dump of 
>JES2 when it failed and will attempt to figure out something in it tomorrow, 
>but was wondering if anybody has seen anything like this.  I restarted JES2 
>bringing it up COLD and it came right up, in z22 mode.
>
>Does anybody know offhand if JES2 needs to be brought up cold when migrating 
>from 1.13 to 2.2 or what might be the problem.  I didn't quiesce JES2 on the 
>current 1.13 system before creating the clone for the sandbox, but we've not 
>had issues with doing this before for DR testing (not moving to a new release).
>
>Any thoughts/ideas would be most welcome.
>
>TIA,
>
>Rex

I reply to posts using the web interface and when I tried to use your latest 
post and quote the text for a reply, it came out in 64encode format, so I went 
back to your original entry!

In all your tests since the original one, are you using the same cloned system? 
 I was wondering if you try a new clone of the production system whether it 
will work or not.  There is a possibility of some kind of error due to timing 
of the clone.  I assume the clone was done with a snapshot?

--
Dale R. Smith

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


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


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

Re: [EXTERNAL] Re: IBM LOGREC Analysis

[Dyck, Lionel B. (TRA)]

Nothing on cbttape - at least nothing that is obvious.

thx


--
Lionel B. Dyck 
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IBM LOGREC Analysis

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC 
> data in a more intelligent manner than the IFCEREP1 reports?
> 
> --
> 
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and 
> Technology, IT Operations and Services
> 

--
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: A dressing Question

[John McKown]

On Fri, Jan 6, 2017 at 11:07 AM, Chris Hoelscher 
wrote:

> I prefer thousand island
>

​With the proper stuffing, I prefer LBD.​



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


-- 
There’s no obfuscated Perl contest because it’s pointless.

—Jeff Polk

Maranatha! <><
John McKown

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

Re: IBM LOGREC Analysis

[Lizette Koehler]

Have you looked on the cbttape.org?

May be something there.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Friday, January 06, 2017 9:31 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IBM LOGREC Analysis
> 
> Is anyone aware of any tool that will analyze and report on LOGREC data in a
> more intelligent manner than the IFCEREP1 reports?
> 
> --
> Lionel B. Dyck
> Mainframe Systems Programmer - TRA
> Enterprise Operations (Station 200) (005OP6.3.10) Information and Technology,
> IT Operations and Services
> 

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Lizette Koehler]

Just for giggles, do a $DEXIT(*) (check my memory for correct command) and see 
if there are any exits active

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 9:37 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> Interesting idea, Lizette.  I just tried again, after removing all EXIT
> statements from my JES2PARM.  Same result, $BR1 catastrophic error.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, January 06, 2017 10:13 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> Allan,
> 
> True.  The intent was to think about
>  1) Any JES2 Exits in place that might be causing the issue
>  2) Are all Vendor related fixes for JES2 installed for the migration.
> 
> Just because something is old, does not mean it could not provide insight on
> an issue.
> 
> :-D
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Allan Staller
> > Sent: Friday, January 06, 2017 7:54 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > catastrophic error
> >
> > That APAR is ancient. The current numbers APAR numbers are OA6.
> > Seems like
> > OA25662 would be circa z/OS 1.4 vintage.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lizette Koehler
> > Sent: Friday, January 6, 2017 8:50 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > catastrophic error
> >
> > You did not indicate if you have MVS Solutions Thruput Manager.
> >
> > If you do, I found this on their website
> >
> > PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
> > $BR1 ABEND
> > after IBM APAR OA25562.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
> > > Sent: Friday, January 06, 2017 6:51 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > > catastrophic error
> > >
> > > Hi Tony,
> > >
> > > There wasn't one.  The manual says the reason code is optional and
> > > for $BR1, it got optioned out.
> > >
> > > *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> > >  * z11 MODE
> > >  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
> > >   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
> > >   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
> > >   $HASP088 PCE  = INIT (165B6008)
> > >   $HASP088 R0   =   3A54502C  342C  
> > >   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
> > >   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
> > >   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> > >
> > > This was followed by the 02D abend.
> > >
> > > Thanks,
> > >
> > > Rex
> > >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
> > > Sent: Thursday, January 05, 2017 7:02 PM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > > catastrophic error
> > >
> > > On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > > > 2)  $BR1 in M gives me "lots" of good information .
> > > > The doc says "JES2 initialization processing encountered an error
> > > > examining
> > > the BERT maps" and the resolution is "
> > > > Use the indicative dump and the SVC dump (if any) to diagnose the
> error.".
> > >
> > > What's the reason code with the $BR1?
> > >
> > > Tony H.
> > >
> >

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Jesse 1 Robinson]

I missed the mention of a 'clone'. We migrate system software via cloning, but 
we clone and migrate only code, e.g. the sysres volume containing (in this 
case) all of JES2. We migrate to a long existing sandbox system that has its 
own spool and checkpoint, which would have been shut down normally via $P JES2 
before IPLing the new level. 

If OP has also cloned the JES2 checkpoint and spool, there could be some 
internal inconsistency that the 2.1 level happens to fall victim to. 

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dale R. Smith
Sent: Friday, January 06, 2017 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
catastrophic error

On Thu, 5 Jan 2017 03:49:42 +, Pommier, Rex  wrote:

>Hello list,
>
>Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our sandbox 
>using a clone of one of our production LPARs.  Tried to bring JES2 up warm and 
>got a $HASP095 catastrophic error code=$BR1.  We are running z11 mode on 1.13 
>and the $HASP493 warm start message verified z11 mode.  I got a system dump of 
>JES2 when it failed and will attempt to figure out something in it tomorrow, 
>but was wondering if anybody has seen anything like this.  I restarted JES2 
>bringing it up COLD and it came right up, in z22 mode.
>
>Does anybody know offhand if JES2 needs to be brought up cold when migrating 
>from 1.13 to 2.2 or what might be the problem.  I didn't quiesce JES2 on the 
>current 1.13 system before creating the clone for the sandbox, but we've not 
>had issues with doing this before for DR testing (not moving to a new release).
>
>Any thoughts/ideas would be most welcome.
>
>TIA,
>
>Rex

I reply to posts using the web interface and when I tried to use your latest 
post and quote the text for a reply, it came out in 64encode format, so I went 
back to your original entry!

In all your tests since the original one, are you using the same cloned system? 
 I was wondering if you try a new clone of the production system whether it 
will work or not.  There is a possibility of some kind of error due to timing 
of the clone.  I assume the clone was done with a snapshot?

--
Dale R. Smith

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

Re: A dressing Question

[Chris Hoelscher]

I prefer thousand island

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Dale R. Smith]

On Thu, 5 Jan 2017 03:49:42 +, Pommier, Rex  wrote:

>Hello list,
>
>Upgrading from z/OS 1.13 to 2.2.  Attempted to IPL it tonight in our sandbox 
>using a clone of one of our production LPARs.  Tried to bring JES2 up warm and 
>got a $HASP095 catastrophic error code=$BR1.  We are running z11 mode on 1.13 
>and the $HASP493 warm start message verified z11 mode.  I got a system dump of 
>JES2 when it failed and will attempt to figure out something in it tomorrow, 
>but was wondering if anybody has seen anything like this.  I restarted JES2 
>bringing it up COLD and it came right up, in z22 mode.
>
>Does anybody know offhand if JES2 needs to be brought up cold when migrating 
>from 1.13 to 2.2 or what might be the problem.  I didn't quiesce JES2 on the 
>current 1.13 system before creating the clone for the sandbox, but we've not 
>had issues with doing this before for DR testing (not moving to a new release).
>
>Any thoughts/ideas would be most welcome.
>
>TIA,
>
>Rex

I reply to posts using the web interface and when I tried to use your latest 
post and quote the text for a reply, it came out in 64encode format, so I went 
back to your original entry!

In all your tests since the original one, are you using the same cloned system? 
 I was wondering if you try a new clone of the production system whether it 
will work or not.  There is a possibility of some kind of error due to timing 
of the clone.  I assume the clone was done with a snapshot?

-- 
Dale R. Smith

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Jesse 1 Robinson]

We have several JES2 exits crucial to running business-as-usual in our shop. 
Over the years, problems with exits in a new release have generally been of two 
types:

-- Data that used to be reached one way now has to be reached another way. 
Unless thoroughly documented, this sort of change can be difficult to diagnose. 
In the best of cases, JES2 developers will have removed or renamed old control 
block labels so that exit assembly gets an error. The fix may be quite complex, 
but at least there is an upfront warning. 

-- Data that used to be contained in, say, a halfword, now occupies a fullword. 
Fortunately JES2 developers have been conscientious in renaming such fields so 
that exit assembly gets an error--an unmistakable pointer to a change that 
requires (usually minor) recoding. 

In the current case, OP has disabled all exits to no avail. Assuming that all 
JES2 mods are true exits with no inline tweaks, my post is probably moot. There 
is however the possibility that some data written to checkpoint or spool was 
itself modified by some exit code such that turning exits off cannot dodge the 
problem.

Knowing nothing else, I'm leaning toward some kind of 1.13/2.1 compatibility 
issue. I would expect JES2 Level 2 to figure this out.  

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


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Pommier, Rex
Sent: Friday, January 06, 2017 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
catastrophic error

Interesting idea, Lizette.  I just tried again, after removing all EXIT 
statements from my JES2PARM.  Same result, $BR1 catastrophic error.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Allan,

True.  The intent was to think about
 1) Any JES2 Exits in place that might be causing the issue
 2) Are all Vendor related fixes for JES2 installed for the migration.

Just because something is old, does not mean it could not provide insight on an 
issue.

:-D

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Allan Staller
> Sent: Friday, January 06, 2017 7:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> That APAR is ancient. The current numbers APAR numbers are OA6. 
> Seems like
> OA25662 would be circa z/OS 1.4 vintage.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Friday, January 6, 2017 8:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> You did not indicate if you have MVS Solutions Thruput Manager.
> 
> If you do, I found this on their website
> 
> PR08075   TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
> $BR1 ABEND
> after IBM APAR OA25562.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
> > Sent: Friday, January 06, 2017 6:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > Hi Tony,
> >
> > There wasn't one.  The manual says the reason code is optional and 
> > for $BR1, it got optioned out.
> >
> > *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> >  * z11 MODE
> >  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
> >   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
> >   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
> >   $HASP088 PCE  = INIT (165B6008)
> >   $HASP088 R0   =   3A54502C  342C  
> >   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
> >   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
> >   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> >
> > This was followed by the 02D abend.
> >
> > Thanks,
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
> > Sent: Thursday, January 05, 2017 7:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > > 2)  $BR1 in M gives me "lots" of good information .
> > > The doc says "JES2 

Re: IBM LOGREC Analysis

[Pew, Curtis G]

On Jan 6, 2017, at 10:30 AM, Dyck, Lionel B. (TRA)  wrote:
> 
> Is anyone aware of any tool that will analyze and report on LOGREC data in a 
> more intelligent manner than the IFCEREP1 reports?

MXG can process LOGREC data, but I don’t think it has any pre-built reports.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Interesting idea, Lizette.  I just tried again, after removing all EXIT 
statements from my JES2PARM.  Same result, $BR1 catastrophic error.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

Allan,

True.  The intent was to think about
 1) Any JES2 Exits in place that might be causing the issue
 2) Are all Vendor related fixes for JES2 installed for the migration.

Just because something is old, does not mean it could not provide insight on an 
issue.

:-D

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Allan Staller
> Sent: Friday, January 06, 2017 7:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> That APAR is ancient. The current numbers APAR numbers are OA6. 
> Seems like
> OA25662 would be circa z/OS 1.4 vintage.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Friday, January 6, 2017 8:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> You did not indicate if you have MVS Solutions Thruput Manager.
> 
> If you do, I found this on their website
> 
> PR08075   TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
> $BR1 ABEND
> after IBM APAR OA25562.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex
> > Sent: Friday, January 06, 2017 6:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > Hi Tony,
> >
> > There wasn't one.  The manual says the reason code is optional and 
> > for $BR1, it got optioned out.
> >
> > *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> >  * z11 MODE
> >  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
> >   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
> >   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
> >   $HASP088 PCE  = INIT (165B6008)
> >   $HASP088 R0   =   3A54502C  342C  
> >   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
> >   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
> >   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> >
> > This was followed by the 02D abend.
> >
> > Thanks,
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
> > Sent: Thursday, January 05, 2017 7:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> > catastrophic error
> >
> > On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > > 2)  $BR1 in M gives me "lots" of good information .
> > > The doc says "JES2 initialization processing encountered an error 
> > > examining
> > the BERT maps" and the resolution is "
> > > Use the indicative dump and the SVC dump (if any) to diagnose the error.".
> >
> > What's the reason code with the $BR1?
> >
> > Tony H.
> >
> 

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


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


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

IBM LOGREC Analysis

[Dyck, Lionel B. (TRA)]

Is anyone aware of any tool that will analyze and report on LOGREC data in a 
more intelligent manner than the IFCEREP1 reports?

--
Lionel B. Dyck
Mainframe Systems Programmer - TRA
Enterprise Operations (Station 200) (005OP6.3.10)
Information and Technology, IT Operations and Services

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

OK, sounds good.  I'm sure glad we have this list to bounce issues off.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, January 06, 2017 10:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

I saw from your original post you were z11 mode, I was curoius of BERTS were 
exhausted . 
OK, still scratching my head 


- Original Message -

From: "Rex Pommier" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, January 6, 2017 10:16:14 AM
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Carmen, 

I'm already at z11 mode. I'm using about 500 BERTs and have about 17000 free 
BERTs. 

Rex 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, January 06, 2017 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

since your skipping a release , there were some 1.13 to 2.1 pre install actions 
to take, may be related to your $BR1 abends Before issuing the 
$ACTIVATE,LEVEL=z11 command, review the current utilization of BERT data to 
determine whether there are sufficient BERTs 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0zm100/checkbert.htm
 



- Original Message - 

From: "Rex Pommier" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, January 6, 2017 9:18:50 AM
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Lizette. 

No, we don't have Thruput Manager. Thanks, though. 

Rex 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

You did not indicate if you have MVS Solutions Thruput Manager. 

If you do, I found this on their website 

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a $BR1 ABEND after 
IBM APAR OA25562. 

Lizette 


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Hi Tony,
> 
> There wasn't one. The manual says the reason code is optional and for 
> $BR1, it got optioned out.
> 
> *21.10.54 *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> * z11 MODE
> *21.10.54 *$HASP095 JES2 CATASTROPHIC ERROR. CODE = $BR1
> $HASP088 HASPIRDA 165B7690 + 000F8C OA49165 BERTMAP
> $HASP088 HASPIRA 165B5000 + 0004FC OA47827 IRDA
> $HASP088 PCE = INIT (165B6008)
> $HASP088 R0 =  3A54502C 342C 
> $HASP088 R4 = 16CA7000 73B7 7718 48B4CC30
> $HASP088 R8 = 3A545018 009FE980 16642BD0 7000
> $HASP088 R12 = 1647B098 165B6008 9647B144 0008
> 
> This was followed by the 02D abend. 
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc
> Sent: Thursday, January 05, 2017 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote: 
> > 2) $BR1 in M gives me "lots" of good information . 
> > The doc says "JES2 initialization processing encountered an error 
> > examining
> the BERT maps" and the resolution is " 
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.". 
> 
> What's the reason code with the $BR1? 
> 
> Tony H. 
> 

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


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


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

I think the "wrinkle" is that a file mark need not be written if there is no 
room for it at end-of-extent.  ie. no point getting a new extent just for the 
file mark;  end-of-(last)extent is a valid EOF. 

Too bad "DASD Bill" (Fairchild) hasn't chimed in.  I'm sure he would cite the 
gospel on this.  I presume he may well be retired by now.  

Sent from my iPhone

> On Jan 6, 2017, at 11:08, Bill Woodger  wrote:
> 
> I, weakly, remember there was some apparent "wrinkle" with "end of data"

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Carmen Vitullo]

I saw from your original post you were z11 mode, I was curoius of BERTS were 
exhausted . 
OK, still scratching my head 


- Original Message -

From: "Rex Pommier"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, January 6, 2017 10:16:14 AM 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Carmen, 

I'm already at z11 mode. I'm using about 500 BERTs and have about 17000 free 
BERTs. 

Rex 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo 
Sent: Friday, January 06, 2017 9:49 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

since your skipping a release , there were some 1.13 to 2.1 pre install actions 
to take, may be related to your $BR1 abends Before issuing the 
$ACTIVATE,LEVEL=z11 command, review the current utilization of BERT data to 
determine whether there are sufficient BERTs 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0zm100/checkbert.htm
 



- Original Message - 

From: "Rex Pommier"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, January 6, 2017 9:18:50 AM 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Lizette. 

No, we don't have Thruput Manager. Thanks, though. 

Rex 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler 
Sent: Friday, January 06, 2017 8:50 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

You did not indicate if you have MVS Solutions Thruput Manager. 

If you do, I found this on their website 

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a $BR1 ABEND after 
IBM APAR OA25562. 

Lizette 


> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex 
> Sent: Friday, January 06, 2017 6:51 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error 
> 
> Hi Tony, 
> 
> There wasn't one. The manual says the reason code is optional and for 
> $BR1, it got optioned out. 
> 
> *21.10.54 *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS - 
> * z11 MODE 
> *21.10.54 *$HASP095 JES2 CATASTROPHIC ERROR. CODE = $BR1 
> $HASP088 HASPIRDA 165B7690 + 000F8C OA49165 BERTMAP 
> $HASP088 HASPIRA 165B5000 + 0004FC OA47827 IRDA 
> $HASP088 PCE = INIT (165B6008) 
> $HASP088 R0 =  3A54502C 342C  
> $HASP088 R4 = 16CA7000 73B7 7718 48B4CC30 
> $HASP088 R8 = 3A545018 009FE980 16642BD0 7000 
> $HASP088 R12 = 1647B098 165B6008 9647B144 0008 
> 
> This was followed by the 02D abend. 
> 
> Thanks, 
> 
> Rex 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc 
> Sent: Thursday, January 05, 2017 7:02 PM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error 
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote: 
> > 2) $BR1 in M gives me "lots" of good information . 
> > The doc says "JES2 initialization processing encountered an error 
> > examining 
> the BERT maps" and the resolution is " 
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.". 
> 
> What's the reason code with the $BR1? 
> 
> Tony H. 
> 

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


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


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


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


The information contained in this message is confidential, protected from 

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Carmen,

I'm already at z11 mode.  I'm using about 500 BERTs and have about 17000 free 
BERTs.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Carmen Vitullo
Sent: Friday, January 06, 2017 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

since your skipping a release , there were some 1.13 to 2.1 pre install actions 
to take, may be related to your $BR1 abends Before issuing the 
$ACTIVATE,LEVEL=z11 command, review the current utilization of BERT data to 
determine whether there are sufficient BERTs 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0zm100/checkbert.htm
 



- Original Message -

From: "Rex Pommier" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, January 6, 2017 9:18:50 AM
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Lizette. 

No, we don't have Thruput Manager. Thanks, though. 

Rex 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

You did not indicate if you have MVS Solutions Thruput Manager. 

If you do, I found this on their website 

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a $BR1 ABEND after 
IBM APAR OA25562. 

Lizette 


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Hi Tony,
> 
> There wasn't one. The manual says the reason code is optional and for 
> $BR1, it got optioned out.
> 
> *21.10.54 *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> * z11 MODE
> *21.10.54 *$HASP095 JES2 CATASTROPHIC ERROR. CODE = $BR1
> $HASP088 HASPIRDA 165B7690 + 000F8C OA49165 BERTMAP
> $HASP088 HASPIRA 165B5000 + 0004FC OA47827 IRDA
> $HASP088 PCE = INIT (165B6008)
> $HASP088 R0 =  3A54502C 342C 
> $HASP088 R4 = 16CA7000 73B7 7718 48B4CC30
> $HASP088 R8 = 3A545018 009FE980 16642BD0 7000
> $HASP088 R12 = 1647B098 165B6008 9647B144 0008
> 
> This was followed by the 02D abend. 
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc
> Sent: Thursday, January 05, 2017 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote: 
> > 2) $BR1 in M gives me "lots" of good information . 
> > The doc says "JES2 initialization processing encountered an error 
> > examining
> the BERT maps" and the resolution is " 
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.". 
> 
> What's the reason code with the $BR1? 
> 
> Tony H. 
> 

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


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


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


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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in 

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Lizette Koehler]

Allan,

True.  The intent was to think about 
 1) Any JES2 Exits in place that might be causing the issue
 2) Are all Vendor related fixes for JES2 installed for the migration.

Just because something is old, does not mean it could not provide insight on an 
issue.

:-D

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: Friday, January 06, 2017 7:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> That APAR is ancient. The current numbers APAR numbers are OA6. Seems like
> OA25662 would be circa z/OS 1.4 vintage.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Friday, January 6, 2017 8:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> You did not indicate if you have MVS Solutions Thruput Manager.
> 
> If you do, I found this on their website
> 
> PR08075   TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
> $BR1 ABEND
> after IBM APAR OA25562.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Pommier, Rex
> > Sent: Friday, January 06, 2017 6:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > catastrophic error
> >
> > Hi Tony,
> >
> > There wasn't one.  The manual says the reason code is optional and for
> > $BR1, it got optioned out.
> >
> > *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
> >  * z11 MODE
> >  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
> >   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
> >   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
> >   $HASP088 PCE  = INIT (165B6008)
> >   $HASP088 R0   =   3A54502C  342C  
> >   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
> >   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
> >   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> >
> > This was followed by the 02D abend.
> >
> > Thanks,
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Tony Harminc
> > Sent: Thursday, January 05, 2017 7:02 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> > catastrophic error
> >
> > On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > > 2)  $BR1 in M gives me "lots" of good information .
> > > The doc says "JES2 initialization processing encountered an error
> > > examining
> > the BERT maps" and the resolution is "
> > > Use the indicative dump and the SVC dump (if any) to diagnose the error.".
> >
> > What's the reason code with the $BR1?
> >
> > Tony H.
> >
> 

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

As part of my experimentation, the one record I wrote was for sure as small as 
80 bytes. That would seem to have been quite "favourable", and no, the 
remainder of the track was untouched by the data which was MODded to it.

I, weakly, remember there was some apparent "wrinkle" with "end of data" but 
assumed it was a "normal" thing, rather than anything specific to what I was 
doing. From memory, of four years ago, with no need of the detail since, when 
the track was full (could not contain another logical record) there was no "end 
of file" (file mark). Something like that. I could be wrong, having made the 
assumption (which seemed to be borne out by the experimentation), I didn't 
research it.

On Fri, 6 Jan 2017 15:41:53 +, J R  wrote:

>Sent from my iPhone
>
>> On Jan 6, 2017, at 10:27, Bill Woodger  wrote:
>> 
>> 1) short or coincidentally-full  block, unfilled track; 
>
>So, in the case of a favorable TRKBAL, the access method doesn't back up over 
>the file mark and write the first new block in its stead?  
>
>It would have to remove the file mark in either eventuality.  
>--
>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: IEC141I 013-A8: how to read VS data sets?

[Jesse 1 Robinson]

Thanks for the IPCS observation. I had never noticed that dynamic dump 
allocation creates FBS data sets. It makes a lot of sense. 

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Friday, January 06, 2017 5:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: IEC141I 013-A8: how to read VS data sets?

On Fri, 6 Jan 2017 01:20:19 -0600, Bill Woodger wrote:

>The S in FS is the same "standard" as the S in FBS.
>
>FS guarantees (by the person who coded it) that there is no partial 
>track within the file/data set, so that a record can be read directly 
>through the calculation of its position.

Correct. I usually think of it FBS as meaning only that there are no short 
blocks, but there are other requirements, including:
* Every track except the last contains the same number of blocks.  
* Every track except the last is filled as determined by the track
  capacity formula established for the device.

>As far as I know, it is simply that guarantee that is the difference, 
>so it can be acted upon. S meaning "this data set has not been MODded

Are you sure? I'm not sure, but I thought that MOD would start by filling up 
the last track.

BTW, IPCS requires FBS for dump data sets.

--
Tom Marchant


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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Carmen Vitullo]

since your skipping a release , there were some 1.13 to 2.1 pre install actions 
to take, may be related to your $BR1 abends 
Before issuing the $ACTIVATE,LEVEL=z11 command, review the current utilization 
of BERT data to determine whether there are sufficient BERTs 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.e0zm100/checkbert.htm
 



- Original Message -

From: "Rex Pommier"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, January 6, 2017 9:18:50 AM 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

Hi Lizette. 

No, we don't have Thruput Manager. Thanks, though. 

Rex 

-Original Message- 
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler 
Sent: Friday, January 06, 2017 8:50 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error 

You did not indicate if you have MVS Solutions Thruput Manager. 

If you do, I found this on their website 

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a $BR1 ABEND after 
IBM APAR OA25562. 

Lizette 


> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex 
> Sent: Friday, January 06, 2017 6:51 AM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error 
> 
> Hi Tony, 
> 
> There wasn't one. The manual says the reason code is optional and for 
> $BR1, it got optioned out. 
> 
> *21.10.54 *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS - 
> * z11 MODE 
> *21.10.54 *$HASP095 JES2 CATASTROPHIC ERROR. CODE = $BR1 
> $HASP088 HASPIRDA 165B7690 + 000F8C OA49165 BERTMAP 
> $HASP088 HASPIRA 165B5000 + 0004FC OA47827 IRDA 
> $HASP088 PCE = INIT (165B6008) 
> $HASP088 R0 =  3A54502C 342C  
> $HASP088 R4 = 16CA7000 73B7 7718 48B4CC30 
> $HASP088 R8 = 3A545018 009FE980 16642BD0 7000 
> $HASP088 R12 = 1647B098 165B6008 9647B144 0008 
> 
> This was followed by the 02D abend. 
> 
> Thanks, 
> 
> Rex 
> 
> -Original Message- 
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc 
> Sent: Thursday, January 05, 2017 7:02 PM 
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error 
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote: 
> > 2) $BR1 in M gives me "lots" of good information . 
> > The doc says "JES2 initialization processing encountered an error 
> > examining 
> the BERT maps" and the resolution is " 
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.". 
> 
> What's the reason code with the $BR1? 
> 
> Tony H. 
> 

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


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


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


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

Sent from my iPhone

> On Jan 6, 2017, at 10:27, Bill Woodger  wrote:
> 
> 1) short or coincidentally-full  block, unfilled track; 

So, in the case of a favorable TRKBAL, the access method doesn't back up over 
the file mark and write the first new block in its stead?  

It would have to remove the file mark in either eventuality.  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

When DISP=MOD is used and there is existing data on the data set I think there 
are three possibilities (in likelihood order) with the existing data: 1) short 
or coincidentally-full  block, unfilled track; 2) short block, 
otherwise-coincidentally-filled track; 3) full block, filled track (double 
coincidence).

For 1), the first block written for "MODding" will be the first block on the 
"next" track, with the remainder of the final track of the previous content of 
the data set being "empty", screwing up a "seek" (there will obviously be a 
short block in one case, and a full one in the other).

For 2), the first block written for "MODding" will be the first block on the 
"next" track, and the previous block will be short, screwing up a "seek".

For 3), by the double coincidence, everything will be fine, and there will be 
no evidence from the content of the data set itself that it was ever MODded. 
"seek" works perfectly. May not, or may, on the next run.

It is unproblematic for "seek" if the final block is short, or the final track 
is short, or both. But, entirely problematic - at least potentially - for 
subsequent data (that which has been MODded) if there is any "gap" of any type 
(short block, short track), if there are embedded short blocks or unfilled 
tracks.

Whether the "seek" would work sometimes, fail all the time, or the programmer 
noted something but did not diagnose but coded-around, and probably other 
scenarios, will be down to the actual data and program.

For ordinary sequential reads, nothing with DISP=MOD is problematic (assuming 
that RECFM/LRECL are consistent with how later used).



On Fri, 6 Jan 2017 14:55:22 +, J R  wrote:

>Sent from my iPhone
>
>> On Jan 6, 2017, at 09:37, Bill Woodger  wrote:
>> 
>> "with the exception of the last block or track." 
>
>Are we not talking about the "last (used) track" in the case of MOD?  
>
>--
>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: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Lizette.

No, we don't have Thruput Manager.  Thanks, though.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 06, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

You did not indicate if you have MVS Solutions Thruput Manager.

If you do, I found this on their website

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
$BR1 ABEND after IBM APAR OA25562.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Hi Tony,
> 
> There wasn't one.  The manual says the reason code is optional and for 
> $BR1, it got optioned out.
> 
> *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
>  * z11 MODE
>  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
>   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
>   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
>   $HASP088 PCE  = INIT (165B6008)
>   $HASP088 R0   =   3A54502C  342C  
>   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
>   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
>   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> 
> This was followed by the 02D abend.
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc
> Sent: Thursday, January 05, 2017 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > 2)  $BR1 in M gives me "lots" of good information .
> > The doc says "JES2 initialization processing encountered an error 
> > examining
> the BERT maps" and the resolution is "
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.".
> 
> What's the reason code with the $BR1?
> 
> Tony H.
> 

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


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


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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

Sent from my iPhone

> On Jan 6, 2017, at 09:37, Bill Woodger  wrote:
> 
> "with the exception of the last block or track." 

Are we not talking about the "last (used) track" in the case of MOD?  

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Allan Staller]

That APAR is ancient. The current numbers APAR numbers are OA6. Seems like 
OA25662 would be circa z/OS 1.4 vintage.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, January 6, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

You did not indicate if you have MVS Solutions Thruput Manager.

If you do, I found this on their website

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
$BR1 ABEND after IBM APAR OA25562.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> Hi Tony,
> 
> There wasn't one.  The manual says the reason code is optional and for 
> $BR1, it got optioned out.
> 
> *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
>  * z11 MODE
>  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
>   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
>   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
>   $HASP088 PCE  = INIT (165B6008)
>   $HASP088 R0   =   3A54502C  342C  
>   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
>   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
>   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> 
> This was followed by the 02D abend.
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Tony Harminc
> Sent: Thursday, January 05, 2017 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 
> catastrophic error
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > 2)  $BR1 in M gives me "lots" of good information .
> > The doc says "JES2 initialization processing encountered an error 
> > examining
> the BERT maps" and the resolution is "
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.".
> 
> What's the reason code with the $BR1?
> 
> Tony H.
> 

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


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.




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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Lizette Koehler]

You did not indicate if you have MVS Solutions Thruput Manager.

If you do, I found this on their website

PR08075 TR62009 $ADD LOADMOD(DTMJ2MV6) command fails with a 
$BR1 ABEND after IBM APAR OA25562.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pommier, Rex
> Sent: Friday, January 06, 2017 6:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> Hi Tony,
> 
> There wasn't one.  The manual says the reason code is optional and for $BR1,
> it got optioned out.
> 
> *21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
>  * z11 MODE
>  *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1
>   $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP
>   $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
>   $HASP088 PCE  = INIT (165B6008)
>   $HASP088 R0   =   3A54502C  342C  
>   $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30
>   $HASP088 R8   = 3A545018  009FE980  16642BD0  7000
>   $HASP088 R12  = 1647B098  165B6008  9647B144  0008
> 
> This was followed by the 02D abend.
> 
> Thanks,
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Harminc
> Sent: Thursday, January 05, 2017 7:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2
> catastrophic error
> 
> On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> > 2)  $BR1 in M gives me "lots" of good information .
> > The doc says "JES2 initialization processing encountered an error examining
> the BERT maps" and the resolution is "
> > Use the indicative dump and the SVC dump (if any) to diagnose the error.".
> 
> What's the reason code with the $BR1?
> 
> Tony H.
> 

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

All the documentation I read suggested that a latest incomplete track, when 
present, is not written to with DISP=MOD. My experiments bore this out.

It is possible that I misread everything and borked all the experiments. I can 
perhaps re-check at some point if this (MOD backfills empty space on a 
partially used track) is the predominant feeling.

Here is the JCL Reference:

"S
(1) For fixed-length records, indicates that the records are written as 
standard blocks, that is, no truncated blocks or unfilled tracks within the 
data set, with the exception of the last block or track."

If tracks were backfilled, that "or unfilled tracks" would be redundant.

No, I've nothing to back that up.

Whilst it may seem profligate with space, probably more determinant on why 
would be "how fast does it take to slap this data onto DASD, given that in 
99.% (or more) of slaps, the particular slap is not the first slap to a 
DISP=MOD with prior data.

On Fri, 6 Jan 2017 14:12:16 +, J R  wrote:

>MOD, I believe, does start by filling the last track;  but it would be sheer 
>luck if the erstwhile last block were a standard block.  Consequently, the 
>odds are stacked against the dataset remaining properly standard.  
>
>In any event, DISP=MOD with RECFM=FBS leaves the dataset labelled as RECFM=FB 
>to obviate behavior unexpected by subsequent users.  
>
>Sent from my iPhone
>
>> On Jan 6, 2017, at 08:13, Tom Marchant 
>> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> Are you sure? I'm not sure, but I thought that MOD would start by 
>> filling up the last track.
>
>--
>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: How many FRR stack entries are available?

[Steve Smith]

The text seems to come from the explanation for a S07D abend.  Which not
coincidentally means "too many FRRs".  The first two explanations imply
that's your own fault.  But maybe there's a situation where the system
needs 14 entries at once.. who knows?

SETFRR has no return code, just the abend.  So I assume this is considered
an extremely pathological condition.

sas

On Fri, Jan 6, 2017 at 7:44 AM, Peter Relson  wrote:

> 
> Is there
> some programmable way I can determine how many are free (if only 1, I
> would
> prefer to have it at the PC level)?
> 
>
> There is of course a programmable way, but there is nothing that is a
> programming interface.
>
> The FRR stack is not complex. There is a pointer to where the first entry
> would go, there is a pointer to the current entry. And each entry is of
> fixed size.
>
> 
> >>The manual states   "The system only guarantees that installations can
> add two FRRs"
> >>Is that still true for zOS 2?
> >Yes it is still true.
>
> Thanks! I have searced around, but in what book is that written?
> 
>
> I assume that it is wherever Binyamin found it; I do not happen to know
> off-hand.
>
> 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
>



-- 
sas

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

Re: IEC141I 013-A8: how to read VS data sets?

[J R]

MOD, I believe, does start by filling the last track;  but it would be sheer 
luck if the erstwhile last block were a standard block.  Consequently, the odds 
are stacked against the dataset remaining properly standard.  

In any event, DISP=MOD with RECFM=FBS leaves the dataset labelled as RECFM=FB 
to obviate behavior unexpected by subsequent users.  

Sent from my iPhone

> On Jan 6, 2017, at 08:13, Tom Marchant 
> <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
> 
> Are you sure? I'm not sure, but I thought that MOD would start by 
> filling up the last track.

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

Re: IEC141I 013-A8: how to read VS data sets?

[Bill Woodger]

On Fri, 6 Jan 2017 07:12:52 -0600, Tom Marchant  
wrote:

[...]
>
>>As far as I know, it is simply that guarantee that is the difference, 
>>so it can be acted upon. S meaning "this data set has not been 
>>MODded
>
>Are you sure? I'm not sure, but I thought that MOD would start by 
>filling up the last track.
>

Unless it has changed with V2, I am sure, through reading the documentation and 
subsequent experimentation.

For instance, one experiment was OPEN, WRITE one record, CLOSE for DISP=NEW 
with TRK,1.

Run again with DISP=MOD. BANG!

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Pommier, Rex]

Hi Tony,

There wasn't one.  The manual says the reason code is optional and for $BR1, it 
got optioned out.

*21.10.54  *$HASP493 JES2 ALL-MEMBER WARM START IS IN PROGRESS -
 * z11 MODE  
 *21.10.54  *$HASP095 JES2 CATASTROPHIC ERROR.  CODE = $BR1  
  $HASP088  HASPIRDA 165B7690 + 000F8C  OA49165  BERTMAP 
  $HASP088  HASPIRA  165B5000 + 0004FC  OA47827  IRDA
  $HASP088 PCE  = INIT (165B6008)
  $HASP088 R0   =   3A54502C  342C   
  $HASP088 R4   = 16CA7000  73B7  7718  48B4CC30 
  $HASP088 R8   = 3A545018  009FE980  16642BD0  7000 
  $HASP088 R12  = 1647B098  165B6008  9647B144  0008 

This was followed by the 02D abend.  

Thanks,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Thursday, January 05, 2017 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic 
error

On 5 January 2017 at 12:38, Pommier, Rex  wrote:
> 2)  $BR1 in M gives me "lots" of good information .
> The doc says "JES2 initialization processing encountered an error examining 
> the BERT maps" and the resolution is "
> Use the indicative dump and the SVC dump (if any) to diagnose the error.".

What's the reason code with the $BR1?

Tony H.

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


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


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

Apache Spark on z listserver or forum?

[Roger Lowe]

Hi,
   Our site is currently in the very early stages of dabbling with Apache Spark 
on z and was wondering if there is a Listserver or Forum specifically for 
Apache Spark on z.

Thanks, Roger

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

Re: IEC141I 013-A8: how to read VS data sets?

[Tom Marchant]

On Thu, 5 Jan 2017 15:34:12 -0700, Paul Gilmartin wrote:

>VBS should have been the only RECFM anyone ever needed,
>thus the only one ever defined and supported.

Are you forgetting that in MVS, and in OS/360 before it, a program 
doesn't have to care what kind of device it is working with?

Certainly a program designed to read cards would not use VBS. 
Neither would a program that punches cards or writes to a printer.

The performance advantages of FBS for random access cannot 
be achieved with VBS.

These are just a few reasons why VBS isn't the only RECFM anyone 
would ever need.

-- 
Tom Marchant

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

Re: IEC141I 013-A8: how to read VS data sets?

[Tom Marchant]

On Fri, 6 Jan 2017 01:20:19 -0600, Bill Woodger wrote:

>The S in FS is the same "standard" as the S in FBS.
>
>FS guarantees (by the person who coded it) that there is no 
>partial track within the file/data set, so that a record can be 
>read directly through the calculation of its position.

Correct. I usually think of it FBS as meaning only that there are 
no short blocks, but there are other requirements, including:
* Every track except the last contains the same number of blocks.  
* Every track except the last is filled as determined by the track 
  capacity formula established for the device.

>As far as I know, it is simply that guarantee that is the difference, 
>so it can be acted upon. S meaning "this data set has not been 
>MODded

Are you sure? I'm not sure, but I thought that MOD would start by 
filling up the last track.

BTW, IPCS requires FBS for dump data sets.

-- 
Tom Marchant

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

Re: Delete NVR entries where ENQ shows from LLA/XCFAS

[Peter Relson]

Why not
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/remenq.htm

?


This is exactly the intended approach when you are trying to deal with an 
uncataloged data set of the same name as a LNKLST data set.

Also, where it talks about LLA, you could use the CSVLLAxx parameter
GET_LIB_ENQ(NO) 

Both of these should be done only temporarily, and put back the way they 
had been (e.g., LNKLST ALLOCATE and GET_LIB_ENQ(YES) ) once the operation 
has been done, in order to keep the system protected. 

I will submit a pub-update request to add this information.

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: How many FRR stack entries are available?

[Peter Relson]

Is there
some programmable way I can determine how many are free (if only 1, I 
would
prefer to have it at the PC level)?


There is of course a programmable way, but there is nothing that is a 
programming interface.

The FRR stack is not complex. There is a pointer to where the first entry 
would go, there is a pointer to the current entry. And each entry is of 
fixed size.


>>The manual states   "The system only guarantees that installations can 
add two FRRs"
>>Is that still true for zOS 2?
>Yes it is still true.

Thanks! I have searced around, but in what book is that written?


I assume that it is wherever Binyamin found it; I do not happen to know 
off-hand.

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: UTC and Daylight Savings Time

[Scott Chapman]

On Thu, 5 Jan 2017 17:02:23 +, Bill Bishop (TMNA)  
wrote:

>Using STP, the local time changes automatically and I am not aware of any way 
>prevent it.  
>
>Is anyone aware of how to accomplish this?

My recollection was that you could disable the automatic adjustment of DST, and 
the Redbook supports that memory...

"If the selected time zone does not support automatic adjustment or if the user 
does not wish to use automatic adjustment of daylight saving time, select Set 
standard time or Set daylight saving time depending on what is in effect at the 
time that the change is made. "

See PDF page 93, indicated page 75 in: 
http://www.redbooks.ibm.com/redbooks/pdfs/sg247281.pdf

Scott Chapman

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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

Elardus-
The macro used is very similar to the one you have posted below. I have finally 
worked out how the code that
"works" avoids the abend: it opens the data set as RECFM=F and reads the max 
LRECL. Needless to say, the output 
received is not useful. I am changing the code to check for RECFM=VS and send 
an "unsupported format" error 
message.

Thanks to all who contributed to this thread.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 06 January 2017 16:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Robin Atwood wrote:

>But my curiosity was piqued when I found that another of our products *could* 
>read the data set; I just cannot work out how!

If you can find out, could you post your macro used for that VS dataset? I'm 
just curious if you don't mind, please.

Something like this example I'm using for reading VBS (not VS) datasets (SMF in 
this case):

INVOERDCB   DSORG=PS,MACRF=(GM),DDNAME=INVOER,EODAD=EINDE

(I admit that above macro is not perfect or optimal or ideal, but it is 
*working* and fast+furious for both tape/disk)

Robin (and others too!), thanks for your posts in this thread. It was very 
educational to me.

Thanks again! 

Groete / Greetings
Elardus Engelbrecht

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

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

Re: IEC141I 013-A8: how to read VS data sets?

[Elardus Engelbrecht]

Robin Atwood wrote:

>But my curiosity was piqued when I found that another of our products *could* 
>read the data set; I just cannot work out how!

If you can find out, could you post your macro used for that VS dataset? I'm 
just curious if you don't mind, please.

Something like this example I'm using for reading VBS (not VS) datasets (SMF in 
this case):

INVOERDCB   DSORG=PS,MACRF=(GM),DDNAME=INVOER,EODAD=EINDE

(I admit that above macro is not perfect or optimal or ideal, but it is 
*working* and fast+furious for both tape/disk)

Robin (and others too!), thanks for your posts in this thread. It was very 
educational to me.

Thanks again! 

Groete / Greetings
Elardus Engelbrecht

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

GSE UK Large Systems Working Group - Sponsors

[Leanne Wilson]

GSE UK Large Systems Working Group – Sponsors

We are beginning to plan the mid-year meeting for the Large Systems Working 
Group

This event will be held on the 28th March 2017.

We are currently looking for a sponsor to hold the event, preferably in London

If you would like to sponsor this event, please contact Leanne Wilson 
lean...@rsmpartners.com





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

Re: IEC141I 013-A8: how to read VS data sets?

[Robin Atwood]

This is a vendor product and I am the developer. I got a bug report from some 
customer who tried to download  a
VS data set from the spool and the server got the abend. I have reproduced this 
by using IEBCOPY to unload a PDS 
and pointing SYSUT2 at SYSOUT. If I use the SDSF JOB DATA SET display and 
scroll to the right, I can see the data set is RECFM=VS, LRECL=23212. Since the 
message manual quite clearly states you cannot read a VS data set from SYSOUT 
using QSAM, I should close the bug as a permanent restriction. But my curiosity 
was piqued when I found that another of our products *could* read the data set; 
I just cannot work out how!

Thanks
Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: 06 January 2017 01:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEC141I 013-A8: how to read VS data sets?

Like Walt, I'm skeptical of the assertion that a spool data set is VS, where 
'S' means 'spanned'. Spanned records are extremely rare in MVS. The only use 
for them I've ever come across is MANx SMF, which I believe predates dirt. Most 
standard utilities fail when opened to V(B)S records. Only IFASMFDP can read 
SMF data, and the output from that is ordinary VB. 

SAPI should be able to handle any spool data set. OTOH I've never coded 
anything for SAPI; we use VPS (Levi, Ray, Shoup) to extract spool data and ship 
it to network printers. Likewise, SDSF or equivalent ISV product can handle 
spool data sets whether created as V or F. SDSF now has a Rexx interface that 
makes it very usable for processing spool files. 

FWIW it was once possible to utilize JES2 interfaces to read spool data sets 
directly. That ability evaporated a long, long time ago. 

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