Re: Compiling a folder of mixed C and C++

[Charles Mills]

It's interesting, the tail wagging the dog, isn't it: big corporate software 
imitating free software.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jack J. Woehr
Sent: Friday, September 25, 2015 7:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Compiling a folder of mixed C and C++

David Crayford wrote:
>  The z/OS C/C++ compiler has a lot of GNU comparability features that 
> I really do wish the USS stack had. But I guess the compiler shares a 
> front-end with the AIX compiler which needs those features to be viable.

Well, it needs them for the z/OS compiler to be viable. A C/C++ compiler that 
can't compile GNU programs tosses away man-millenia of software.

And the USS stack gets more Gnu-like the more Gnu (and other open source 
software) programs you compile and install.

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

Re: Compiling a folder of mixed C and C++

[Jack J. Woehr]

Charles Mills wrote:

It's interesting, the tail wagging the dog, isn't it: big corporate software 
imitating free software.



I came from microcomputers to Unix servers and eventually to mainframe VM and 
OS390 in the 1990's

It was amazing to see mature code, I'd never seen 35-year-old code before.

Mainframe software systems seem to me to be like those layered liqueurs, they keep adding a new color on top. It never 
ends.


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

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

Best way to get a dataset name from a DEB (was: Recovery routine for ICHRTX00)

[Leonardo Vaz]

Hello list!

I had some good progress on my tests and I figured I'd ask for advice from my 
good friends; what is the best way of getting a dataset name from a DEB, offset 
-F (prefix table) has the CCHHR of the DSCB, which looks good enough, is that 
the way to go? Am I missing something?

Regards,
Leo

-Original Message-
From: Leonardo Vaz 
Sent: Monday, September 21, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: Recovery routine for ICHRTX00

Thank you Walt, I will test that and perhaps open a PMR to see if IBM can 
confirm this for me.

Basically I want to see if I can figure out where a module is being loaded from 
and perhaps log that information somewhere.

Regards,
Leo

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

On Mon, 21 Sep 2015 14:38:23 +, Leonardo Vaz  wrote:

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

For that particular call, made by the intended callers, you should always be in 
supervisor state and key 0 if I remember correctly. Note that this is NOT a 
normal FASTAUTH call, and many of the aspects of it (including parameter 
formats) are not documented for customers. Vendors who are registered with IBM 
as part of PartnerWorld (or whatever it may be called these days) have access 
to additional information.

I'd be interested in what you intend to do with the calls, if you can describe 
it here.

--
Walt

--
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: More "ageing mainframe" (bad) press.

[Barkow, Eileen]

I cannot resist mentioning this since it is on-topic.

The soap opera Young and Restless, which Is my favorite TV show, currently has 
a story line about hacking into
the fictional companies' computer systems in order to discredit the companies 
involved and the baddies even managed to get into the mainframe.
At least Newman Enterprises and  Jabot still have mainframes which are 
mentioned from time to time (in a usually unflattering context).
But someone needs to set these soap  writers right.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shane Ginnane
Sent: Friday, September 25, 2015 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: More "ageing mainframe" (bad) press.

On Fri, 25 Sep 2015 08:00:37 -0600, Jack J. Woehr wrote:

>Seems like actually only one of the apps actually going away, the rest being 
>Web front-ended, which is entirely appropriate.
>
>And as we all know, some of these conversions never succeed and they're
>forced to drop back on maintaining the mainframe app.
>
>I'm more sanguine about this as I catch up on the architecture. The
>last time I studied the physical mainframe, it was ES9000.
>
>The z13 is a truly amazing machine.

The largest of the sites mentioned is z13 already - multi-CEC, multi-site. 
Running Model 204 (yep, just them and the CIA left in the whole world 
apparently) Ain't going to survive like that, flashy GUI front ends or no.

They have a lot of smart people, and a lot of smart tech, but they are fighting 
a Government that has snorted the tea-leaves. They have survived a big 
outsourcing push a few years back, and sundry departmental amalgamations, but 
they are in a barbed wire canoe paddling against the current..

Shane ...

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

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

Re: Restore time question

[Elardus Engelbrecht]

John Eells wrote:

>I asked Development about this, causing some head-scratching.  They'd like you 
>to open a PMR so they can dig into why this could be happening.

Possibly hardware error - a PMR is an excellent suggestion.

If there is a PMR, ask them to check EACH tape/cartridge individual response 
times and from WHAT unit of each drive. (Same question Tim Hare also asked 
earlier)


To Tony:

Please repeat the whole restore with another set of backup+restore volsers [ 
and perhaps to other tape UNITS ] to see if timings are the same or not.

Just a guess, but are your volsers already pre-INIT or not or are they 'true' 
VTS (i.e., not really physical storage media)?

I am confused by your two [conflicting?] statements, this is why I ask above 
question:

   "We are talking real physical 3590 tape drives. (2g ficon)" 
and 
   "Tapes are not rewinding and repositioning between backup files."

Do you have PPRC from/to your DR site? (Yes, I know you said "Same physical 
CPU, same Disk, same tape drives.", but PPRC may or may not be affecting your 
writing timings.) 

Are you getting channel errors? [1]

Groete / Greetings
Elardus Engelbrecht

[1] - That channel errors bit me and others hard causing slow usage of 
tape/cartridge. That was until many parts were physically replaced.

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

Re: Compiling a folder of mixed C and C++

[David Crayford]

On 24/09/2015 8:56 PM, Paul Gilmartin wrote:

It's a peculiar sense of "more portable".  Yes, gmake is portable in
that its source is available and can be compiled on many platforms.
But I think you mean, rather, that gmake supports makefiles which
are non-portable in that they do not conform to POSIX standards.


Absolutely! I see portability as how easy it is to port something, not 
in a standard which has become somewhat stagnant. I can build stuff on 
Linux, OS X and even windows quite easily. z/OS is always a struggle, 
and not
always because of the dreaded EBCDIC but runtime functions. z/OS and 
it's strict conformance to POSIX can be a PITA. The z/OS C/C++ compiler 
has a lot of GNU comparability features that I really do wish the USS 
stack had. But I guess the compiler shares

a front-end with the AIX compiler which needs those features to be viable.

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

Re: OS/390 hard wait

[Tony Thigpen]

I do have the VM spooled output from "D T0.10"

I need to check on APAR OW56730 (PTF UA01439 for OS/390 2.10).


Tony Thigpen

Jim Mulder wrote on 09/25/2015 01:43 AM:

In a DR site, we are 'playing' with a customers OS/390 2.10 under z/VM
6.3 on a z10.

Their system was running with ARCHLVL=1, but we were having some
performance issues, so we decided to see what would happen with

ARCHLVL=2.


The initial IPL trucks along until it the console switches modes. Then
the guest enters:

"CP disabled wait PSW 0002 8000  9064"

Console:
IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNPF5 INITIALIZATION

Thoughts?


   Thinking about such things is more productive with stand-alone dump
at which to gaze.

   There was APAR OW56730 (PTF UA01439 for OS/390 2.10), which may be
of interest if it is not already installed.

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

--
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: OS/390 hard wait Subject:

[Linda]

Www-3.ibm.com/systems/z/os/support/zos_server.htm 

Shows the z990 as the newest processor to support OS/390 2.10. 

HTH,

Linda

Sent from my iPhone

On Sep 25, 2015, at 5:16 AM, Peter Relson  wrote:

>> The earliest version of MVS (sic) that is advertised 
>> to support ARCHLVL=2 is z/OS 1.6
> 
> Not true. z/OS 1.6 is the earliest release to require z/Architecture 
> (i.e., ARCHLVL=2).
> OS/390 R10 introduced ARCHLVL=2 as an option.
> 
>> IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNPF5 INITIALIZATION
> 
> As documented, this wait state code indicates that a program check 
> occurred.
> 
> If you were to ask anyone "a program check occurred, what went wrong?" 
> they'd ask for more information. As would we.
> What program check? Where? As documented there might be a message in the 
> wait state message area.
> A standalone dump would usually be needed to make much progress.
> 
> Was OS/390 R10 even a release for which z10 support was provided? have no 
> idea.
> 
> 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

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

Re: Best way to get a dataset name from a DEB (was: Recovery routine for ICHRTX00)

[Leonardo Vaz]

Thanks Charles and Eileen!

That means I would have to use SWAREQ to actually get from TIOEJFCB to 
JFCBDSNM, right?

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Barkow, Eileen
Sent: Friday, September 25, 2015 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way to get a dataset name from a DEB (was: Recovery routine 
for ICHRTX00)

TCBTIO -> addr TIOT
DEBDCBAD -> addr DCB
DCBTIOT->  offset in TIOT
TIOEJFCB  ->  JFCBDSNM


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, September 25, 2015 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way to get a dataset name from a DEB (was: Recovery routine for 
ICHRTX00)

Hello list!

I had some good progress on my tests and I figured I'd ask for advice from my 
good friends; what is the best way of getting a dataset name from a DEB, offset 
-F (prefix table) has the CCHHR of the DSCB, which looks good enough, is that 
the way to go? Am I missing something?

Regards,
Leo

-Original Message-
From: Leonardo Vaz
Sent: Monday, September 21, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: Recovery routine for ICHRTX00

Thank you Walt, I will test that and perhaps open a PMR to see if IBM can 
confirm this for me.

Basically I want to see if I can figure out where a module is being loaded from 
and perhaps log that information somewhere.

Regards,
Leo

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

On Mon, 21 Sep 2015 14:38:23 +, Leonardo Vaz  wrote:

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

For that particular call, made by the intended callers, you should always be in 
supervisor state and key 0 if I remember correctly. Note that this is NOT a 
normal FASTAUTH call, and many of the aspects of it (including parameter 
formats) are not documented for customers. Vendors who are registered with IBM 
as part of PartnerWorld (or whatever it may be called these days) have access 
to additional information.

I'd be interested in what you intend to do with the calls, if you can describe 
it here.

--
Walt

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

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

--
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: Best way to get a dataset name from a DEB (was: Recovery routine for ICHRTX00)

[Charles Mills]

That's the right way. SWAREQ is no big deal -- easy to use.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, September 25, 2015 1:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best way to get a dataset name from a DEB (was: Recovery routine 
for ICHRTX00)

Thanks Charles and Eileen!

That means I would have to use SWAREQ to actually get from TIOEJFCB to 
JFCBDSNM, right?

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

Re: Dataset enqueue, how to find the culprit.

[Graham Harris]

MXI has comprehensive ENQ query capabilities, and a very usable REXX
interface as well.

On 25 September 2015 at 01:44, Anthony Thompson 
wrote:

> For trapping the results in a REXX you could use the SDSF ISFSLASH service
> to capture the results of a D GRS, RES= or D GRS,C command. I imagine you
> could use the TSO CONSOLE command too. Assuming you have the authority for
> either...
>
> Ant.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, 25 September 2015 1:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Dataset enqueue, how to find the culprit.
>
> On Thu, 24 Sep 2015 14:33:03 +, Pommier, Rex wrote:
> >
> >Commands for viewing ENQs and ENQ contention:
> >
> >o   Enq
> >Show existing ENQs on the system or systems. You can specify RNAME,
> >QNAME, system name and job or user name to narrow down the search.
> > ...
> Thanks.  I fear that "You can specify ..." means that when ISRDDN displays
> a panel that panel will contain fields in which to enter those options, not
> that they may be entered (from Rexx) on the command line.
>
> Oh, I forgot to mention that I'd like to be able to OUTTRAP (or similar)
> the result for further processing.  ZSCREEN?  Probably not; my process runs
> headless.  GUIs are often overrated.
>
> Thanks again,
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: OS/390 hard wait Subject:

[Tony Thigpen]

Well, with the z800 compatibility feature installed, it runs on a z10.

As long as we use ARCHLVL=1. :-)

Tony Thigpen

Linda wrote on 09/25/2015 12:36 PM:

Www-3.ibm.com/systems/z/os/support/zos_server.htm

Shows the z990 as the newest processor to support OS/390 2.10.

HTH,

Linda

Sent from my iPhone

On Sep 25, 2015, at 5:16 AM, Peter Relson  wrote:


The earliest version of MVS (sic) that is advertised
to support ARCHLVL=2 is z/OS 1.6


Not true. z/OS 1.6 is the earliest release to require z/Architecture
(i.e., ARCHLVL=2).
OS/390 R10 introduced ARCHLVL=2 as an option.


IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNPF5 INITIALIZATION


As documented, this wait state code indicates that a program check
occurred.

If you were to ask anyone "a program check occurred, what went wrong?"
they'd ask for more information. As would we.
What program check? Where? As documented there might be a message in the
wait state message area.
A standalone dump would usually be needed to make much progress.

Was OS/390 R10 even a release for which z10 support was provided? have no
idea.

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


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

Setting the writers right

[Charles Mills]

A recurring theme here the past couple of weeks has been the "head in the
1960's" writing about mainframes in news stories and now soap operas.

Seriously, would it make sense for our community to put together a volunteer
team (under the auspices of SHARE? Or ... ?) that would maintain a watch for
stupid mainframe media putdowns and send off a packet of
layperson-accessible education to the offending writers, editors and/or
producers? Perhaps have a Website where writers could get current facts
about the mainframe? Would IBM participate in some way?

Any ideas? I volunteer to participate but not to lead.

Charles 

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

Re: Compiling a folder of mixed C and C++

[Elardus Engelbrecht]

Jack J. Woehr wrote:

>> It's interesting, the tail wagging the dog, isn't it: big corporate software 
>> imitating free software.
>I came from microcomputers to Unix servers and eventually to mainframe VM and 
>OS390 in the 1990's
>It was amazing to see mature code, I'd never seen 35-year-old code before.

Indeed! Yes, this I also see. Look at IBM tools and toys pages and other 
freebies to download to get an idea.

Working with RACF/SMS/HSM/zOS/Automation/various 
languages/TSO/ISPF/REXX/Assembler/and more other things I find one interesting 
thing with Mainframes - You learn something new nearly everyday.

For example, for one IBM-MAIN member, I confirmed a bug in ISMF earlier this 
year - a PTF was eventually made available. This is while I'm currently a RACF 
admin who was wearing a storage admin hat many centuries ago...

In fact, I started with DOS, windoze and such animals on the 8086/80286/386 
machines before I started with Mainframe, starting with VM+MVS/ESA and ending 
up with z/OS and all its goodies...

Fact is - I see many IBM-MAIN members are having more experience than me and 
you... Just check their postings and CVs+websites...


>Mainframe software systems seem to me to be like those layered liqueurs, they 
>keep adding a new color on top. It never ends.

Cool! My auditors still can't believe that z/OS has so much security features - 
other platforms just don't have it.
For them this is a new wild area, just like those sweets... ;-)

I like their quote: 'Why is green screen so much secure than other platforms?'

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: Best way to get a dataset name from a DEB (was: Recovery routine for ICHRTX00)

[Charles Mills]

It should be available in memory without disk I/O I would think.

What do you have besides the DEB? Can you get to the JFCB and JFCBDSNM?

What about other than legacy datasets? Do you need UNIX filenames also? Tougher.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, September 25, 2015 9:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way to get a dataset name from a DEB (was: Recovery routine for 
ICHRTX00)

Hello list!

I had some good progress on my tests and I figured I'd ask for advice from my 
good friends; what is the best way of getting a dataset name from a DEB, offset 
-F (prefix table) has the CCHHR of the DSCB, which looks good enough, is that 
the way to go? Am I missing something?

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

Re: Best way to get a dataset name from a DEB (was: Recovery routine for ICHRTX00)

[Barkow, Eileen]

TCBTIO -> addr TIOT
DEBDCBAD -> addr DCB
DCBTIOT->  offset in TIOT
TIOEJFCB  ->  JFCBDSNM


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Friday, September 25, 2015 12:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Best way to get a dataset name from a DEB (was: Recovery routine for 
ICHRTX00)

Hello list!

I had some good progress on my tests and I figured I'd ask for advice from my 
good friends; what is the best way of getting a dataset name from a DEB, offset 
-F (prefix table) has the CCHHR of the DSCB, which looks good enough, is that 
the way to go? Am I missing something?

Regards,
Leo

-Original Message-
From: Leonardo Vaz
Sent: Monday, September 21, 2015 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RE: Recovery routine for ICHRTX00

Thank you Walt, I will test that and perhaps open a PMR to see if IBM can 
confirm this for me.

Basically I want to see if I can figure out where a module is being loaded from 
and perhaps log that information somewhere.

Regards,
Leo

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

On Mon, 21 Sep 2015 14:38:23 +, Leonardo Vaz  wrote:

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

For that particular call, made by the intended callers, you should always be in 
supervisor state and key 0 if I remember correctly. Note that this is NOT a 
normal FASTAUTH call, and many of the aspects of it (including parameter 
formats) are not documented for customers. Vendors who are registered with IBM 
as part of PartnerWorld (or whatever it may be called these days) have access 
to additional information.

I'd be interested in what you intend to do with the calls, if you can describe 
it here.

--
Walt

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

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



This e-mail, including any attachments, may be confidential, privileged or 
otherwise legally protected. It is intended only for the addressee. If you 
received this e-mail in error or from someone who was not authorized to send it 
to you, do not disseminate, copy or otherwise use this e-mail or its 
attachments. Please notify the sender immediately by replying to this e-mail 
and delete the e-mail from your system.

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

Re: OS/390 hard wait Subject:

[R.S.]

W dniu 2015-09-25 o 18:36, Linda pisze:

Www-3.ibm.com/systems/z/os/support/zos_server.htm

Shows the z990 as the newest processor to support OS/390 2.10.

HTH,

Linda

Some people claimed they ran OS/390 2.10 on z9 or even z10.
Supported <> working.

--
Radoslaw Skorupka
Lodz, Poland






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

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

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


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

Re: OS/390 hard wait

[Shane Ginnane]

On Fri, 25 Sep 2015 01:43:41 -0400, Jim Mulder wrote:

>  Thinking about such things is more productive with stand-alone dump
>at which to gaze.

My recollection of SADump at OS/390 2.10 (and z/OS 1.1 for that matter) in 
64-bit is less than happy. Me-thinks we had a discussion about memory not being 
dumped ... ?

As it happens I have a set of 2.10 CDs (yep real sparkling disks that work a 
treat for keeping the birds off the tomatoes) - updated for 64-bit even.
Not much of interest in the Planning for Install - standard PARMLIB updates, 
including ARCHLVL. Some notes re compatibility for those unfortunate enough to 
have a z900 - so I would also reckon a z10 might be a stretch given the manuals 
are dated December 2000.

Shane ...

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

Re: Debug Tool question

[Elardus Engelbrecht]

michelbutz wrote:

>I'm trying to make a breakpoint when register 3 displacement 14 is not equal 
>x'30'
>This statement doesn't seem to work
>At statement number when %gpr3->+14 ~= x'30'
>I don't have the symbol for not x'5f' on my iPhone 
>But the above statement passes the debug tool 
>Parser but it still stops when reg3 + 14 is equal to x'30'
>14 is decimal 14 the debug tool parser doesn't take +E

On iPhone [1]? What are you using to access your system? Mocha TN3270? If so, 
*Check* your code page! Are you using US 037 code page?

Ok. Some questions since you gave too few details:

What are you trying to debug?
What Language?
What Debug Tool?
Do you try to debug in TSO, CICS or batch or what?
What z/OS version and what versions of the tools and language?

And SHOW your debug statements!

Groete / Greetings
Elardus Engelbrecht

[1] - I don't like to access the z/OS system using a lame cellphone or similar 
toys like tablets. Yes, I know about Bluetooth keyboards and such toys to make 
editing easy, but ...

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

Re: OS/390 hard wait

[Elardus Engelbrecht]

Shane Ginnane wrote:

>As it happens I have a set of 2.10 CDs (yep real sparkling disks that work a 
>treat for keeping the birds off the tomatoes) - updated for 64-bit even.

Or use them to keep animals running into fences if you have no paint cans lids 
to use. LaserDiscs, CDs, DVDs, Blu-rays, etc., they're equally sparkling... ;-D

They're coming without those IOS000I DEVICE FENCED ... ;-D

Is it Friday today? ;-D

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: Restore time question

[Tony Thigpen]

Tim,
Sorry missed you question earlier.

> Have you looked at individual volume timings?
No, I guess we need to.

> How many tape drives were used for the DUMP? How many for the restore?
In both cases 6.
But, there are actually 10 backup and 10 restore jobs and thus 10 tapes.

Tony Thigpen

Tim Hare wrote on 09/21/2015 03:50 PM:

Apologies - I had overlooked the configuration.

Have you looked at individual volume timings?  Are some as quick as their 
original dump and some not or are all of the restores a lot longer?

How many tape drives were used for the DUMP? How many for the restore?

--
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: Restore time question

[Tony Thigpen]

Elardus,

> Do you have PPRC from/to your DR site?
No PRCC on the 8300 box.

> I am confused by your two [conflicting?] statements,
These are real 3590's attached via 2g ficon via (what I understand is) a 
J70 controller. The 'real z/os sysprog' (I normally manage the z/VM 
stuff) asked me to watch the drives to make sure they were not rewinding 
and repositioning between each job step as the job used a different job 
step for each 3390 volume restore. I saw no indication of rewinding 
between steps.


Tony Thigpen

Elardus Engelbrecht wrote on 09/25/2015 06:55 AM:

John Eells wrote:


I asked Development about this, causing some head-scratching.  They'd like you 
to open a PMR so they can dig into why this could be happening.


Possibly hardware error - a PMR is an excellent suggestion.

If there is a PMR, ask them to check EACH tape/cartridge individual response 
times and from WHAT unit of each drive. (Same question Tim Hare also asked 
earlier)


To Tony:

Please repeat the whole restore with another set of backup+restore volsers [ 
and perhaps to other tape UNITS ] to see if timings are the same or not.

Just a guess, but are your volsers already pre-INIT or not or are they 'true' 
VTS (i.e., not really physical storage media)?

I am confused by your two [conflicting?] statements, this is why I ask above 
question:

"We are talking real physical 3590 tape drives. (2g ficon)"
and
"Tapes are not rewinding and repositioning between backup files."

Do you have PPRC from/to your DR site? (Yes, I know you said "Same physical CPU, 
same Disk, same tape drives.", but PPRC may or may not be affecting your writing 
timings.)

Are you getting channel errors? [1]

Groete / Greetings
Elardus Engelbrecht

[1] - That channel errors bit me and others hard causing slow usage of 
tape/cartridge. That was until many parts were physically replaced.

--
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: Restore time question

[Elardus Engelbrecht]

Tony Thigpen wrote:

> > Do you have PPRC from/to your DR site?
>No PRCC on the 8300 box.

Ok. One thing less to worry about.

> > I am confused by your two [conflicting?] statements,
>These are real 3590's attached via 2g ficon via (what I understand is) a J70 
>controller. The 'real z/os sysprog' (I normally manage the z/VM stuff) asked 
>me to watch the drives to make sure they were not rewinding and repositioning 
>between each job step as the job used a different job step for each 3390 
>volume restore. I saw no indication of rewinding between steps.

Ok. Many thanks for your kind reply. I believe this will help John Eells and 
his friends to help you out.

Just trying to give some help if you don't mind (I was Storage admin in ancient 
years.)

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: Restore time question

[Tony Thigpen]

I would love to open a PMR, but I don't think they would accept it.

This is os/390 2.10 on a z/10 using a DS8300

Not really a 'supported' situation. :-(

Tony Thigpen

John Eells wrote on 09/25/2015 06:16 AM:

I asked Development about this, causing some head-scratching.  They'd
like you to open a PMR so they can dig into why this could be happening.

Tony Thigpen wrote:

Original question since it's been a few days:

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15 (hh:mm), but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?


We are talking real physical 3590 tape drives. (2g ficon)
We are talking about 400 3390-3 equivalents (some are -9s) (IBM 8300)
Backups are done with CICS up, but no users. (this is a dr box test).
Restores are done with nothing up on a recovery system.
Same physical CPU, same Disk, same tape drives.
Tapes are not rewinding and repositioning between backup files.

We are just trying to understand if this is normal or not.

Tony Thigpen

Tim Hare wrote on 09/21/2015 10:47 AM:

Does the tape subsystem have physical tape cartridges?   If so, then
tape mounts are probably a big part of the time involved. I can only
speak to the IBM TS 7700 I last used before I semi-retired, which had
high-capacity tape cartridges.

1.  Scratch tapes are 'fast ready' (I think that's the term) - there's
no mount time as long as your disk cache has space for virtual tapes.
So writing a bunch of tapes incurs very little mount time.

2. When doing a restore, first you load the physical cartridges into
the VTS before you ever start any jobs.

3. When you run the restore job, there's _nothing_ in the disk cache.

4. Therefore, every virtual tape mount is a cache miss and requires a
recall.

5.  Recall is a mount, fast forward to the virtual tape's position,
reading the virtual volume from the tape and writing it to the disk
cache, _before_ your virtual mount is satisfied.

6.  If you run multiple restore jobs, and they refer to virtual tapes
on the same physical cartridge, you will have contention for the
physical tape (which you don't see in any monitor on zOS! )and one
job's virtual mount will have to wait on the other one's.

As you can see there are quite a few delay points in a restore.

I created a SHARE enhancement request (in the Storage project) that I
hope IBM will implement, which would help with some of these delays.
Basically, it would be an HMC enhancement on the VTS so that you could
indicate that you are loading tapes for DR, and when that indicator
was set, each tape loaded would immediately be mounted, and  have its
virtual tapes written to the disk cache, up to some threshold of the
cache.  Doing so would help alleviate the problems in 3, 4, 5, and 6.

I don't know of good ways to pre-mount the tapes and therefore
pre-load the cache from zOS but it might be possible.  It's also
possible, if you use BVIR to retrieve data telling you which virtual
tape is on which physical cartridge, to try to split your restores by
physical cartridge to try to eliminate some of the physical mount
contention.





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

Re: OS/390 hard wait Subject:

[Peter Relson]

>The earliest version of MVS (sic) that is advertised 
>to support ARCHLVL=2 is z/OS 1.6

Not true. z/OS 1.6 is the earliest release to require z/Architecture 
(i.e., ARCHLVL=2).
OS/390 R10 introduced ARCHLVL=2 as an option.

>IEA304W SYSTEM WAIT STATE CODE 80009064 DURING IEAVNPF5 INITIALIZATION

As documented, this wait state code indicates that a program check 
occurred.

If you were to ask anyone "a program check occurred, what went wrong?" 
they'd ask for more information. As would we.
What program check? Where? As documented there might be a message in the 
wait state message area.
A standalone dump would usually be needed to make much progress.

Was OS/390 R10 even a release for which z10 support was provided? have no 
idea.

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

More "ageing mainframe" (bad) press.

[Shane Ginnane]

http://www.itnews.com.au/news/the-top-five-green-screen-systems-that-run-australia-409614

Some large (by Aussie standards) mainframe customers that may be no more in the 
foreseeable future.

Shane ...

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

Re: Restore time question

[John Eells]

I asked Development about this, causing some head-scratching.  They'd 
like you to open a PMR so they can dig into why this could be happening.


Tony Thigpen wrote:

Original question since it's been a few days:

Using ADRDSSU:
DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
RESTORE FULL INDD(BACKUP) OUTDD(DASD) PRG CAN ADMIN

All the dasd can be backed up in 1:15 (hh:mm), but restore takes 5:08.

Are we doing something wrong, or is this 4.5x longer normal?


We are talking real physical 3590 tape drives. (2g ficon)
We are talking about 400 3390-3 equivalents (some are -9s) (IBM 8300)
Backups are done with CICS up, but no users. (this is a dr box test).
Restores are done with nothing up on a recovery system.
Same physical CPU, same Disk, same tape drives.
Tapes are not rewinding and repositioning between backup files.

We are just trying to understand if this is normal or not.

Tony Thigpen

Tim Hare wrote on 09/21/2015 10:47 AM:

Does the tape subsystem have physical tape cartridges?   If so, then
tape mounts are probably a big part of the time involved. I can only
speak to the IBM TS 7700 I last used before I semi-retired, which had
high-capacity tape cartridges.

1.  Scratch tapes are 'fast ready' (I think that's the term) - there's
no mount time as long as your disk cache has space for virtual tapes.
So writing a bunch of tapes incurs very little mount time.

2. When doing a restore, first you load the physical cartridges into
the VTS before you ever start any jobs.

3. When you run the restore job, there's _nothing_ in the disk cache.

4. Therefore, every virtual tape mount is a cache miss and requires a
recall.

5.  Recall is a mount, fast forward to the virtual tape's position,
reading the virtual volume from the tape and writing it to the disk
cache, _before_ your virtual mount is satisfied.

6.  If you run multiple restore jobs, and they refer to virtual tapes
on the same physical cartridge, you will have contention for the
physical tape (which you don't see in any monitor on zOS! )and one
job's virtual mount will have to wait on the other one's.

As you can see there are quite a few delay points in a restore.

I created a SHARE enhancement request (in the Storage project) that I
hope IBM will implement, which would help with some of these delays.
Basically, it would be an HMC enhancement on the VTS so that you could
indicate that you are loading tapes for DR, and when that indicator
was set, each tape loaded would immediately be mounted, and  have its
virtual tapes written to the disk cache, up to some threshold of the
cache.  Doing so would help alleviate the problems in 3, 4, 5, and 6.

I don't know of good ways to pre-mount the tapes and therefore
pre-load the cache from zOS but it might be possible.  It's also
possible, if you use BVIR to retrieve data telling you which virtual
tape is on which physical cartridge, to try to split your restores by
physical cartridge to try to eliminate some of the physical mount
contention.



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

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

Re: More "ageing mainframe" (bad) press.

[Jack J. Woehr]

Shane Ginnane wrote:

http://www.itnews.com.au/news/the-top-five-green-screen-systems-that-run-australia-409614

Some large (by Aussie standards) mainframe customers that may be no more in the 
foreseeable future.

Shane ...


Seems like actually only one of the apps actually going away, the rest being 
Web front-ended, which is entirely appropriate.

And as we all know, some of these conversions never succeed and they're forced to drop back on maintaining the mainframe 
app.


I'm more sanguine about this as I catch up on the architecture. The last time I studied the physical mainframe, it was 
ES9000.


The z13 is a truly amazing machine.

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

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

Re: Compiling a folder of mixed C and C++

[Jack J. Woehr]

David Crayford wrote:
 The z/OS C/C++ compiler has a lot of GNU comparability features that I really do wish the USS stack had. But I guess 
the compiler shares

a front-end with the AIX compiler which needs those features to be viable.


Well, it needs them for the z/OS compiler to be viable. A C/C++ compiler that can't compile GNU programs tosses away 
man-millenia of software.


And the USS stack gets more Gnu-like the more Gnu (and other open source 
software) programs you compile and install.

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

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

Re: More "ageing mainframe" (bad) press.

[Shane Ginnane]

On Fri, 25 Sep 2015 08:00:37 -0600, Jack J. Woehr wrote:

>Seems like actually only one of the apps actually going away, the rest being 
>Web front-ended, which is entirely appropriate.
>
>And as we all know, some of these conversions never succeed and they're forced 
>to drop back on maintaining the mainframe
>app.
>
>I'm more sanguine about this as I catch up on the architecture. The last time 
>I studied the physical mainframe, it was
>ES9000.
>
>The z13 is a truly amazing machine.

The largest of the sites mentioned is z13 already - multi-CEC, multi-site. 
Running Model 204 (yep, just them and the CIA left in the whole world 
apparently)
Ain't going to survive like that, flashy GUI front ends or no.

They have a lot of smart people, and a lot of smart tech, but they are fighting 
a Government that has snorted the tea-leaves. They have survived a big 
outsourcing push a few years back, and sundry departmental amalgamations, but 
they are in a barbed wire canoe paddling against the current..

Shane ...

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