Re: AW: Re: Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[Barbara Nitz]

>a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in 
>read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful 
>information for me?
The only tcb I know of that actually, really is located in the R/W nucleus is 
the first tcb in the *master* address space. Every address space started after 
that starts with a tcb in LQSA. So unless the SSRV entries were for asid(1), I 
would find a tcb address in R/W nucleus highly suspicious. Have you checked the 
storage FDD4F8? Is it really a tcb? (Easiest way to check is a cbf x'fdd4f8' 
str(tcb). If the eyecatcher is not there, the formatter will tell you).

b) I know "SVC D" is also entered for normal task termination. In an ld MVS 
debugging manual I found that the first byte of R1 is x'08' this indicates RTM2 
is called for task termination cleanup. The x'08 does no longer seem to hold 
true. How can I identify such an non-error an SVC D entry?
Error entries usually have an asterisk is front of the word SVC. I learned 
early on to do a "f '*'" in the trace table to find the entry for the abend. If 
you don't see the *rcvy entries following the svc d, chances are that you're 
looking at normal termination. Another indication is that IIRC normal 
termination doesn't have an abend code.

c) In some dumps I see "SVC 3" (exit) trace entries, sometimes I can see the 
"SVC 3E" (DETACH), sometime it is not in the trace.
What's the question on this? Did you format the trace table using 'jobname(your 
jobname)'? Given the number of dumps you had and the abend codes, there should 
be some form of common denominator. 23E and 53E are both detach abends, so I 
would expect to see an SVC 3E entry. Detach does some validity checking and 
then issues these abends. So at the time of detach you already have an overlay.
Always look at the earlieast error indication. Are there logrec entries for it? 
What is that error? If it is a pic11, check the earlier trace table in that 
address space for a freemain - sometimes it is a larger range that got freed. 
Does a summary format on the problem address space work without errors? Is 
there more than one tcb with a completion code?

Barbara

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

Re: 64 bit execution above the bar

[Binyamin Dissen]

On Mon, 27 Mar 2017 18:10:35 -0400 Charles Mills  wrote:

:>The fact that the hardware guys and gals made the hardware capable of 
execution above the bar means IBM is giving this some thought. (The thought may 
be "Heck, no!" )

Well, they never supported code execution from a dataspace ..

:>-Original Message-
:>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
Behalf Of Paul Gilmartin
:>Sent: Monday, March 27, 2017 5:00 PM
:>To: IBM-MAIN@LISTSERV.UA.EDU
:>Subject: Re: 64 bit execution above the bar

:>On Mon, 27 Mar 2017 15:19:31 -0500, Dave Anderson wrote:
:>>What is IBM's strategy for migrating code execution to be above the bar? Has 
IBM released any documents detailing the next steps, or is this confidential?
 
:>It has been discussed here for a while.  You could disable interrupts, branch 
to code above the bar, and branch back later.  (I suppose the Old PSW was 
unconditionally scrunched.)  More recently, interrupts above the bar are 
tolerated, but no system services can be called from above the bar.

:>>Currently data areas above the bar are widely used but program execution 
above the bar is not currently supported. Other posts have suggested that Cobol 
will soon support 64 bit execution but not only for modules loaded  below the 
bar and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
with 31 bit Cobol and has performance issues.

:>Performance issues have been mentioned here.  Are those because of:
:>o I-fetch bandwidth?
:>o Address calculation/translation overhead?
:>o Computation overhead?
:>o Some combination?

:>I'd guess that instructions with 64-bit operands are slower than instructions 
with shorter operands, even in AMODE 24/31.

:>Is AMODE 31 slower than AMODE 24?  (Or even the opposite?)

:>>Does anybody know if IBM plans to run system modules above the bar? I would 
be interested in hearing any comments/insights on this topic?

:>Not I.  How close is LPA to encountering a Virtual Address Storage Constraint?

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

Director, Dissen Software, Bar & Grill - Israel


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

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

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

Re: 64 bit execution above the bar

[Chuck Arney]

You might get some ideas from my blog post. It is a couple of years old now but 
it mostly still applies today. 

Http://zosdebug.com/blog


Chuck Arney

> On Mar 27, 2017, at 3:19 PM, Dave Anderson  wrote:
> 
> What is IBM's strategy for migrating code execution to be above the bar? Has 
> IBM released any documents detailing the next steps, or is this confidential?
> 
> Currently data areas above the bar are widely used but program execution 
> above the bar is not currently supported. Other posts have suggested that 
> Cobol will soon support 64 bit execution but not only for modules loaded  
> below the bar and that 64 bit Cobol is unlikely to be widely used as it is 
> not compatible with 31 bit Cobol and has performance issues.
> 
> Does anybody know if IBM plans to run system modules above the bar? I would 
> be interested in hearing any comments/insights on this topic?
> 
> --
> 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: 64 bit execution above the bar

[Tony Harminc]

On 27 March 2017 at 20:15, Mike Schwab  wrote:
> The z13 is the LAST processor to support 31 bit mode.  I would assume
> that for the z14 all interrupt areas will be 64 bit capable.

They already are. AMODEs 24 and 31 are not going away on z14; it's the
ability to IPL and run in ESA/390 architecture that's going.

Tony H.

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

Re: 64 bit execution above the bar

[Mike Schwab]

The z13 is the LAST processor to support 31 bit mode.  I would assume
that for the z14 all interrupt areas will be 64 bit capable.

On Mon, Mar 27, 2017 at 7:09 PM, John McKown
 wrote:
> On Mon, Mar 27, 2017 at 6:13 PM, Paul Gilmartin <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
>> On 2017-03-27, at 17:00, Blaicher, Christopher Y. wrote:
>>
>> > It's called z/OS is not the only thing that runs on a 64-bit machine.  I
>> haven't looked into all the particulars, but I have heard someplace that
>> 'C' can run in 64-bit under z/LINUX.
>> >
>> Yes. but it's a very different 'C'.  I understand that z/Linux doesn't
>> even have a "bar".  What about Gnu COBOL?
>>
>
> GnuCOBOL actually translates COBOL into C and then uses GCC to compile
> that. As to "C" running in 64 bit on z/Linux, I wouldn't see why not. GCC
> can make 64 bit executables on Intel x86_64 and ARM.
>
>
>>
>> Also z/VM.  (But is that CP or just guests?)
>>
>> How full is LPA getting at some sites?
>>
>
> Hum, I'd hate to be the one to try to justify a z/OS configuration which
> would _require_ execution in 64 bit RMODE. How many DS8886 disk arrays
> would be required just for the page data sets? And then, of course, if
> RMODE(64) is _required_ in order to fit the programs into virtual, how much
> disk for the libraries. I say libraries, because I doubt you could get a
> lot of members into even an PDSE if it were so large it wouldn't load into
> RMODE(31) space.
>
>
>
>>
>>
>> -- gil
>>
>>
> I wonder if the IBMi people ever talk about this sort of thing. Of course,
> the IBMi, theoretically, uses 128 bit addressing. But the current
> implementation only supports using 48 bit addressing. That's 2^48==2^8 *
> 2^20== 256 tebibytes.
>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> Maranatha! <><
> John McKown
>
> --
> 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: 64 bit execution above the bar

[John McKown]

On Mon, Mar 27, 2017 at 6:13 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2017-03-27, at 17:00, Blaicher, Christopher Y. wrote:
>
> > It's called z/OS is not the only thing that runs on a 64-bit machine.  I
> haven't looked into all the particulars, but I have heard someplace that
> 'C' can run in 64-bit under z/LINUX.
> >
> Yes. but it's a very different 'C'.  I understand that z/Linux doesn't
> even have a "bar".  What about Gnu COBOL?
>

​GnuCOBOL actually translates COBOL into C and then uses GCC to compile
that. As to "C" running in 64 bit on z/Linux, I wouldn't see why not. GCC
can make 64 bit executables on Intel x86_64 and ARM.​


>
> Also z/VM.  (But is that CP or just guests?)
>
> How full is LPA getting at some sites?
>

​Hum, I'd hate to be the one to try to justify a z/OS configuration which
would _require_ execution in 64 bit RMODE. How many DS8886 disk arrays
would be required just for the page data sets? And then, of course, if
RMODE(64) is _required_ in order to fit the programs into virtual, how much
disk for the libraries. I say libraries, because I doubt you could get a
lot of members into even an PDSE if it were so large it wouldn't load into
RMODE(31) space.​



>
>
> -- gil
>
>
​I wonder if the IBMi people ever talk about this sort of thing. Of course,
the IBMi, theoretically, uses 128 bit addressing. But the current
implementation only supports using 48 bit addressing. That's 2^48==2^8 *
2^20== 256 tebibytes.


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: 64 bit execution above the bar

[John McKown]

On Mon, Mar 27, 2017 at 4:19 PM, Charles Mills  wrote:

> I think has been discussed here some -- did you search?
>
> Do you really have executables that you are having trouble fitting below
> the bar?
>

​I was wondering the same thing. Now, the best that I can think of, is a
MUSAS type address space (like CICS/TS) where you have hundreds of
thousands of users logged on concurrently and tens of thousands of
concurrently ​executing transactions. But, really, that would be better
handled using multiple CICS systems in a multi-CEC parallel sysplex with
some sort of load balancing going on.



>
> Charles
>
>

-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: 64 bit execution above the bar

[Paul Gilmartin]

On 2017-03-27, at 17:00, Blaicher, Christopher Y. wrote:

> It's called z/OS is not the only thing that runs on a 64-bit machine.  I 
> haven't looked into all the particulars, but I have heard someplace that 'C' 
> can run in 64-bit under z/LINUX.
>  
Yes. but it's a very different 'C'.  I understand that z/Linux doesn't
even have a "bar".  What about Gnu COBOL?

Also z/VM.  (But is that CP or just guests?)

How full is LPA getting at some sites?

> I think this is more a case of not wanting to have to re-write half of the 
> operating system and have dual API's for everything when it isn't needed.  At 
> least not yet.
> 
> Because they have done some work in that direction, it seems to me they are 
> taking small deliberate steps to get there.
> 
> 
> -Original Message-
> From: Charles Mills
> Sent: Monday, March 27, 2017 6:11 PM
> 
> The fact that the hardware guys and gals made the hardware capable of 
> execution above the bar means IBM is giving this some thought. (The thought 
> may be "Heck, no!" )

-- gil

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

Re: 64 bit execution above the bar

[Blaicher, Christopher Y.]

It's called z/OS is not the only thing that runs on a 64-bit machine.  I 
haven't looked into all the particulars, but I have heard someplace that 'C' 
can run in 64-bit under z/LINUX.

I think this is more a case of not wanting to have to re-write half of the 
operating system and have dual API's for everything when it isn't needed.  At 
least not yet.

Because they have done some work in that direction, it seems to me they are 
taking small deliberate steps to get there.

I know nothing as fact, just a lot of looking at the tea leaves.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, March 27, 2017 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64 bit execution above the bar

The fact that the hardware guys and gals made the hardware capable of execution 
above the bar means IBM is giving this some thought. (The thought may be "Heck, 
no!" )

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, March 27, 2017 5:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64 bit execution above the bar

On Mon, 27 Mar 2017 15:19:31 -0500, Dave Anderson wrote:

>What is IBM's strategy for migrating code execution to be above the bar? Has 
>IBM released any documents detailing the next steps, or is this confidential?
>
It has been discussed here for a while.  You could disable interrupts, branch 
to code above the bar, and branch back later.  (I suppose the Old PSW was 
unconditionally scrunched.)  More recently, interrupts above the bar are 
tolerated, but no system services can be called from above the bar.

>Currently data areas above the bar are widely used but program execution above 
>the bar is not currently supported. Other posts have suggested that Cobol will 
>soon support 64 bit execution but not only for modules loaded  below the bar 
>and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
>with 31 bit Cobol and has performance issues.
>
Performance issues have been mentioned here.  Are those because of:
o I-fetch bandwidth?
o Address calculation/translation overhead?
o Computation overhead?
o Some combination?

I'd guess that instructions with 64-bit operands are slower than instructions 
with shorter operands, even in AMODE 24/31.

Is AMODE 31 slower than AMODE 24?  (Or even the opposite?)

>Does anybody know if IBM plans to run system modules above the bar? I would be 
>interested in hearing any comments/insights on this topic?
>
Not I.  How close is LPA to encountering a Virtual Address Storage Constraint?

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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

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

Re: 64 bit execution above the bar

[Charles Mills]

The fact that the hardware guys and gals made the hardware capable of execution 
above the bar means IBM is giving this some thought. (The thought may be "Heck, 
no!" )

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, March 27, 2017 5:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: 64 bit execution above the bar

On Mon, 27 Mar 2017 15:19:31 -0500, Dave Anderson wrote:

>What is IBM's strategy for migrating code execution to be above the bar? Has 
>IBM released any documents detailing the next steps, or is this confidential?
> 
It has been discussed here for a while.  You could disable interrupts, branch 
to code above the bar, and branch back later.  (I suppose the Old PSW was 
unconditionally scrunched.)  More recently, interrupts above the bar are 
tolerated, but no system services can be called from above the bar.

>Currently data areas above the bar are widely used but program execution above 
>the bar is not currently supported. Other posts have suggested that Cobol will 
>soon support 64 bit execution but not only for modules loaded  below the bar 
>and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
>with 31 bit Cobol and has performance issues.
>
Performance issues have been mentioned here.  Are those because of:
o I-fetch bandwidth?
o Address calculation/translation overhead?
o Computation overhead?
o Some combination?

I'd guess that instructions with 64-bit operands are slower than instructions 
with shorter operands, even in AMODE 24/31.

Is AMODE 31 slower than AMODE 24?  (Or even the opposite?)

>Does anybody know if IBM plans to run system modules above the bar? I would be 
>interested in hearing any comments/insights on this topic?
>
Not I.  How close is LPA to encountering a Virtual Address Storage Constraint?

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#89 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#94 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#95 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017d.html#1 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017d.html#3 GREAT presentation on the history of 
the mainframe

even more 3090 trivia:

before starting work on LLNL fibre channel standard (pair of fibre-optic
dedicated to transmission in each direction, original getting 1gbit/sec
concurrent, full-duplex, 2gbit/sec aggregate) ... LANL started
standardization of the Cray 100mbyte/sec parallel channel. HIPPI
https://en.wikipedia.org/wiki/HIPPI

there then forms some competition between LLNL FCS and LANL HIPPI,
where HIPPI is being extended to serial HIPPI fiber optic and
200MB/s.

3090 added vector processing as part of playing in the supercomputer
market ... however that required that they also be able to support
100mbyte/sec (and/or 1gbit/sec) I/O. 3090 was barely able to get up to
4.5mbyte/sec transfers ... so what to do?

turns out that physical memory packaging had created a problem for 3090
and to address the problem they came up with memory hierarchy with
extended store ... wide, fast bus with instructions to syncronously move
4k bytes between processor memory and extended store memory (although
the memory chip technology was the same). The extended store interface
turns out to be the only part of 3090 capable of handling the data
rate.

There is kludge that hooks HIPPI I/O interface into reserved addresses
in the extended store bus ... and a sort of PC I/O paradigm using sort
of peek/poke convention for doing I/O (extended store bus instructions
moving data to/from these reserved addresses). That enables being to
attach things like 40mbyte/sec disk arrays to 3090.

There was lab. in kinstaon that worked with these kinds of applications
... but it was populated with dozen FPS (floating point systems)
boxes that included 40mbyte/sec disk array support as part of
native environment.

one of projects I had was HSDT and was suppose to get $20M from the
director of NSF to interconnect the NSF supercomputer centers (or at
least before congress cuts the budget). However, one of my internal HSDT
links was into the (IBM) kingston datacenter that had all these FPS
boxes. some past HSDT posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt

some past 3090 extended store posts
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2008i.html#10 Different Implementations of VLIW
http://www.garlic.com/~lynn/2013g.html#41 A History Of Mainframe Computing
http://www.garlic.com/~lynn/2013h.html#3 The cloud is killing traditional 
hardware and software
http://www.garlic.com/~lynn/2013i.html#50 The Subroutine Call
http://www.garlic.com/~lynn/2013m.html#99 SHARE Blog: News Flash: The Mainframe 
(Still) Isn't Dead
http://www.garlic.com/~lynn/2017b.html#69 The ICL 2900

past posts mentioning FPS boxes (and 40mbyte/sec disk arrays in the
mid-80s)
http://www.garlic.com/~lynn/2000c.html#5 TF-1
http://www.garlic.com/~lynn/2000c.html#61 TF-1
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001d.html#32 Imitation...
http://www.garlic.com/~lynn/2001m.html#25 ESCON Data Transfer Rate
http://www.garlic.com/~lynn/2002e.html#31 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002i.html#12 CDC6600 - just how powerful a machine 
was it?
http://www.garlic.com/~lynn/2002j.html#30 Weird
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003g.html#68 IBM zSeries in HPC
http://www.garlic.com/~lynn/2003m.html#20 360 Microde Floating Point Fix
http://www.garlic.com/~lynn/2006m.html#4 The Power of the NORC
http://www.garlic.com/~lynn/2006o.html#1 harris
http://www.garlic.com/~lynn/2009j.html#54 A Complete History Of Mainframe 
Computing
http://www.garlic.com/~lynn/2010b.html#72 Happy DEC-10 Day
http://www.garlic.com/~lynn/2010f.html#61 Handling multicore CPUs; what the 
competition is thinking
http://www.garlic.com/~lynn/2011h.html#74 Vector processors on the 3090
http://www.garlic.com/~lynn/2011n.html#36 

Re: 64 bit execution above the bar

[Jesse 1 Robinson]

Execution above the bar still seems like a solution in search of a problem. 2 
GB looks like a lot of room for executable code if (most) data can be floated 
above the bar. A lot of work (=$$$) for minimal return. I've never heard IBM 
hint otherwise. 

.
.
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 Charles Mills
Sent: Monday, March 27, 2017 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: 64 bit execution above the bar

I think has been discussed here some -- did you search?

Do you really have executables that you are having trouble fitting below the 
bar?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Anderson
Sent: Monday, March 27, 2017 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 64 bit execution above the bar

What is IBM's strategy for migrating code execution to be above the bar? Has 
IBM released any documents detailing the next steps, or is this confidential?

Currently data areas above the bar are widely used but program execution above 
the bar is not currently supported. Other posts have suggested that Cobol will 
soon support 64 bit execution but not only for modules loaded  below the bar 
and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
with 31 bit Cobol and has performance issues.

Does anybody know if IBM plans to run system modules above the bar? I would be 
interested in hearing any comments/insights on this topic?


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

Re: 64 bit execution above the bar

[Charles Mills]

I think has been discussed here some -- did you search?

Do you really have executables that you are having trouble fitting below the 
bar?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dave Anderson
Sent: Monday, March 27, 2017 4:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 64 bit execution above the bar

What is IBM's strategy for migrating code execution to be above the bar? Has 
IBM released any documents detailing the next steps, or is this confidential?

Currently data areas above the bar are widely used but program execution above 
the bar is not currently supported. Other posts have suggested that Cobol will 
soon support 64 bit execution but not only for modules loaded  below the bar 
and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
with 31 bit Cobol and has performance issues.

Does anybody know if IBM plans to run system modules above the bar? I would be 
interested in hearing any comments/insights on this topic?

-

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

Re: SMP/E Tutorial

[Paul Gilmartin]

On Mon, 27 Mar 2017 16:47:41 -0400, John Eells wrote:
>
>If you BUILDMCS your current HBB FMID, you will doubtless find
>examples like this one:
>
>++PROGRAM(IWMAM431)
>SYSLIB(SIEALNKE)
>ALIAS(LARM431)
>DISTLIB(AIEALNKE) RELFILE(9)  .
> 
Which answers the question asked about new functions.  Service can also be
distributed in RELFILE format, but this is highly unconventional.  Catalog
pollution?  Does ACCEPT PURGE clean up relative files?

If you package a ++PROGRAM instream, you need GIMDTS to flatten the
program object.

Is a GIMDTS program object flattened from a UNiX file entirely interchangable
with a GIMDTS program object flattened from a PDSE member?

I remember NNTP.

-- gil

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

Re: 64 bit execution above the bar

[Paul Gilmartin]

On Mon, 27 Mar 2017 15:19:31 -0500, Dave Anderson wrote:

>What is IBM's strategy for migrating code execution to be above the bar? Has 
>IBM released any documents detailing the next steps, or is this confidential?
> 
It has been discussed here for a while.  You could disable interrupts, branch to
code above the bar, and branch back later.  (I suppose the Old PSW was
unconditionally scrunched.)  More recently, interrupts above the bar are
tolerated, but no system services can be called from above the bar.

>Currently data areas above the bar are widely used but program execution above 
>the bar is not currently supported. Other posts have suggested that Cobol will 
>soon support 64 bit execution but not only for modules loaded  below the bar 
>and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
>with 31 bit Cobol and has performance issues.
>
Performance issues have been mentioned here.  Are those because of:
o I-fetch bandwidth?
o Address calculation/translation overhead?
o Computation overhead?
o Some combination?

I'd guess that instructions with 64-bit operands are slower than instructions
with shorter operands, even in AMODE 24/31.

Is AMODE 31 slower than AMODE 24?  (Or even the opposite?)

>Does anybody know if IBM plans to run system modules above the bar? I would be 
>interested in hearing any comments/insights on this topic?
>
Not I.  How close is LPA to encountering a Virtual Address Storage Constraint?

-- gil

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

Re: SMP/E Tutorial

[John Eells]

Dan Kalmar wrote:


Thanks. Can you provide an example of a PROGRAM definition in a new Function 
SYSMOD or point me to such example?


Note: Many followers of this list do not use an NNTP newsreader. You 
will probably get faster (and more) responses if you post to the list 
rather than to the newsgroup. The footer of every post sent to the list 
appears at the bottom, and can get you started.


If you BUILDMCS your current HBB FMID, you will doubtless find 
examples like this one:


++PROGRAM(IWMAM431)
   SYSLIB(SIEALNKE)
   ALIAS(LARM431)
   DISTLIB(AIEALNKE) RELFILE(9)  .

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

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

mitchd...@gmail.com (Dana Mitchell) writes:
> 4331 had integrated disk and communication adapters built in, no 3274,
> 3705, 3880 controllers required.  Later machines just had parallel
> channels just sort of built in, not really on cards.  3090 was first
> with ESCON

re:
http://www.garlic.com/~lynn/2017d.html#1 GREAT presentation on the history of 
the mainframe

"4331" was "boeblingen" machine, like 115&125, with integrated
channels & integrated controllers
http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of 
the mainframe
http://www.garlic.com/~lynn/2017c.html#95 GREAT presentation on the history of 
the mainframe

... while "4341" was "Endicott" machine, with integrated channels like
370/158 ... however 4341 was faster than 158&3031 ... and 4341
integrated channels were much faster than 158 integrated channels (158
integrated channels was also used as external channel for all 303x
processors). 4341 integrated channels were so fast that with slight
tweak ... they could be used for 3380 3mbyte/sec testing.
http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?)
http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of 
the mainframe

past posts getting to play disk engineer in bldgs14&15
htttp://www.garlic.com/~lynn/subtopic.html#disk

mid-range disks for 4331&4341 were FBA (3310 & 3370)  also low
environmentals so straight-foward to deploy in non-datacenter
environments.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3370.html
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_3370b.html

high-end datacenter disks were 3380 3mbyte/sec, still CKD ... but small
fixed cell size (for things like error correcting) ... so record lengths
had to be rounded up to cell size ... for determining records/track. As
POK favorite son operating system continued to fail to deploy FBA
support ... and all physical disks moved to industry standard
fixed-block, CKD became an legacy anachronism, all simulated on industry
standard fixed-block disks (decades after CKD stopped being built). past
posts
http://www.garlic.com/~lynn/submain.html#dasd

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

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

64 bit execution above the bar

[Dave Anderson]

What is IBM's strategy for migrating code execution to be above the bar? Has 
IBM released any documents detailing the next steps, or is this confidential?

Currently data areas above the bar are widely used but program execution above 
the bar is not currently supported. Other posts have suggested that Cobol will 
soon support 64 bit execution but not only for modules loaded  below the bar 
and that 64 bit Cobol is unlikely to be widely used as it is not compatible 
with 31 bit Cobol and has performance issues.

Does anybody know if IBM plans to run system modules above the bar? I would be 
interested in hearing any comments/insights on this topic?

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

Re: LISTCAT QUESTION - TEMP-EXP

[Lizette Koehler]

So long as you are using best practices and samples in the HSM starter set, you 
should be okay

Note: from the HSM Starter set creates a new VSAM dataset with TEMPORTY. This 
the TEMP-EXP field is from.


 LISTCAT ENT(?UID.MCDS ?UID.BCDS ?UID.OCDS) ALL  
  EXAMINE NAME(?UID.MCDS) INDEXTEST   
  IF LASTCC = 0 THEN -
 EXPORT ?UID.MCDS ODS(?UID.EXPORT.MCDS) TEMPORARY 
  IF LASTCC = 0 THEN -
 IMPORT IDS(?UID.EXPORT.MCDS) ODS(?UID.MCDS.?NEW) -   
 OBJECTS -
  ((?UID.MCDS -   
  NEWNAME(?UID.MCDS.?NEW)) -  
   (?UID.MCDS.DATA -  
NEWNAME(?UID.MCDS.?NEW.DATA)) -   
   (?UID.MCDS.INDEX - 
NEWNAME(?UID.MCDS.?NEW.INDEX))) - 
 CATALOG(?UCATNAM)
  IF MAXCC = 0 THEN - 
 DELETE ?UID.EXPORT.MCDS NONVSAM  
  EXAMINE NAME(?UID.BCDS) INDEXTEST   
  IF LASTCC = 0 THEN -
 EXPORT ?UID.BCDS ODS(?UID.EXPORT.BCDS) TEMPORARY   


Guideline: Use the QUERY CONTROLDATASETS command to determine how full the 
control data sets are. Do not perform frequent “reorgs” of DFSMShsm control 
data sets. Unlike other databases, reorganizing DFSMShsm control data sets 
degrades performance for about three weeks. The only time that you should 
perform a reorganization is when you are moving or reallocating the data sets 
to a larger size or multiple clusters to account for growth.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of esmie moo
> Sent: Monday, March 27, 2017 8:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: LISTCAT QUESTION - TEMP-EXP
> 
> Gentle Readers,
> i have a question about TEMP-EXP which appears on a LISTCAT of the HSM
> BCDS.  I did a REPRO to a test BCDS  however when I run the LISTCAT of the
> Prod version (so as to compare the TEST & PROD. allocations) it shows TEMP-EXP
> in the ATTRIBUTES section of the DATA & INDEX components.According to the the
> explanation of TEMP-EXP it says "The data component was temporarily exported"
> Is my assumption that the REPRO function is the same as EXPORT? Also, should I
> be concerned that LISTCAT indicates that a TEMP-EXP had occurred?
> I welcome all your thoughts.  Thanks.

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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

mitchd...@gmail.com (Dana Mitchell) writes:
> 4331 had integrated disk and communication adapters built in, no 3274,
> 3705, 3880 controllers required.  Later machines just had parallel
> channels just sort of built in, not really on cards.  3090 was first
> with ESCON

minor nit, ESCON announced with ES/9000 in 1990 ... 
https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS9000.html

Enterprise Systems Connection (ESCON) Architecture implementing fiber
optic channels, which provide significantly higher data rates than
traditional parallel channels and which permit input/output equipment to
be located at distances up to nine kilometers (5.6 miles) from the
processor;

... snip ...

from Computerworld, 20Jan1992, volXXVI, #3, pg. 29 article, "No
stampeded to IBM's Escon"

IBM's Escon architecture, introduced in September 1990, is a
fiber-optic-based method of connecting processors, storage devices and
peripherals.

... snip ...

1980, STL cons me into doing channel extender support. They are moving
300 people from the IMS group to an offsite bldg with remote access back
to STL datacenter. The victim group had tried remote 3270 support and
found the human factors totally unacceptable. The channel extender
support puts 3270 channel attached controllers at the offsite bldg. The
channel extender support ... downloads channel programs to channel
simulator at the remote site ... significantly offsetting the latency
and overhead of the intensive channel protocol chatter over the extended
distance. Instead streams data & channel programs simultaneously over
full-duplex connection (side-by-side 3270 demos with real local channel
attached and channel-extender running loop-back to offsite bldg and back
... it is not possible to tell difference).

Vendor then tries to get IBM to allow release of my support. However
there is a group in POK that is playing with some fibre stuff that
gets it blocked because they are concerned that if it was in the
market, it would make it harder to get their stuff released. some
past posts
http://www.garlic.com/~lynn/submisc.html#channel.extender

STL does a special 3270 logon screen for the IMS people at the offsite
bldg (standard login for all of STL is VM370, even for people working on
IMS, DB2, MVS, etc). This was also in the days of increasing focus on
productivity from subsecond response. Standard TSO at best was second,
and most of the time much worse. Lots of internal VM370 systems were
.2sec ... but I did "SJR/VM" systems that lots of internal datacenters
ran that would get .1sec using same hardware with identical load (when I
was at science center, it was CSC/VM that lots of internal datacenters
ran, before I transfered to san jose research)
http://www.garlic.com/~lynn/vmhyper.jpg

In 1988, I'm asked to help LLNL standardize some serial technology they
are working with ... which quickly becomes Fibre Channel Standard
... including concurrent streaming in both directions of data &
downloaded I/O programs (minimizing latency of I/O program protocol
chatter).

Then ESCON is announced 1990 with ES/9000 when it is already obsolete.

Then some POK engineers became involved with fibre channel standard and
defined an extremely heavy-weight protocol that drastically cuts the
native throughput, which is eventually announced as FICON. Most recent
"peak I/O" benchmark I can find is z196 getting 2M IOPS using 104
FICON. About the same time there was native FCS announced for E5-2600
blade claiming over million IOPS (for single FCS, two such FCS having
higher throughput than 104 FICON running over 104 FCS).

There is some mention of zHPF/TCW that is a little like what I had done
originally in 1980 ... but claims only 30% improvement over standard
FICON (possibly 2M IOPS with only 70 FICON?)

some past posts
http://www.garlic.com/~lynn/submisc.html#ficon

3090 trivia: engineers were really upset being directed to use slow,
vertical microcoded JIB-prime for 3880 disk controller. It had special
hardware bypass for 3mbyte/sec data transfer ... but the controller was
really slow at processing channel programs and rest of the channel
protocol chatter, signicantly increasing channel busy (much, much slower
than the previous horizontal microcode 3830 disk controller).

3090 had designed balanced configuration throughput assuming that
channel protocol overhead busy would be similar to 3830 (with
improvement that data transferred at 3mbyte/sec). When they found
how bad 3880 channel busy was going to be, they had to significantly
increase the number of channels ... which required an additional
TCM, which increased manufacturing cost. There were semi-facetious
references that the 3090 group was going to bill the 3880
controller organization for the additional TCM.

Then marketing spins all the additional channels as how much it
increases the 3090 I/O throughput (obfuscating the fact that the
additional channels were required for the significant increase in
channel busy overhead).

past posts 

Re: Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[John McKown]

On Mon, Mar 27, 2017 at 12:06 PM, Peter Hunkeler  wrote:

>
>
> >> How grown application written in ASM and C. Works fine since years,
> except
> >> for some "out of socket descriptor" problems every now and them. I was
> >> asked to help finding the cause of S23E or S53E (both DETCH) abends
> since
> >> the developer tries to fix the above "ourt of socket descriptor"
> problem.
> >>
>  >
> ​>What is the code in R15? Just as a guess, for the S23E, I'd bet it's
> x'08'
> >which says "tasking being DETACH'd is not a subtask of the task doing the
> >DETACH".
>
>
> Sorry for having forgotten to write this.
>
>
> The S23E had reason 00, meaning "The protection key of the address does
> not match the key of the issuer of the DETACH." Interesting, isn't it?
>
>
> The S53E doesn't have different reasons. One of the possible causes listed
> in the manual is: "The protection key of the address does not match the key
> of the issuer of the DETACH." Seems likely since I see an S202 in the
> system trace before. I'm not in the office now, and I can't remember the
> S202's reason code for sure. I think it was 00, meaning "The system found
> an incorrect address for a request block (RB) in the 3 low-order bytes of
> the ECB specified by the problem program."
>

​Hum, could be the ECB has been overlain. Or that it is not currently being
WAIT'd upon.​ What are the entire 4 bytes of the ECB value (in hex please
[grin]).
values are described here:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.iead100/iead100658.htm



>
>
> I know the program does subtasking via ATTACH and DETACH. Unfortunately, I
> only have an vague idea what the program does but don't have a clue (yet)
> how it exactly works. In fact there seems to be no-one left in the company
> who does.
>
>
> I would open a PMR with IBM asking for help, but thanks to great
> management, we are not allowed to send dumps. Therefore I have to get at
> least a basic understanding to be able to describe the symptoms good enough
> before I can even think of opening a PMR.
>
>
> --
> Peter Hunkeler
>


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

>As far as finding the source statement, yes this is possible with ABO.
 >
>We run IBM's Fault Analyzer and it has PTFs that make it compatible with ABO 
>optimized code.  So, this tool can go through the updated 'listing' file 
>produced as part of the ABO output to help get back to the original source 
>code.
 >
>I would guess that other tools (ie: Abend Aid) would be able to do the same 
>thing.
 >
>As far as doing it manually - good luck, but with the output from the 
>optimization run, you can probably figure out how to get back to your original 
>code.



We don't have IBM's Fault Analyzer, and as I mentioned, we do not (yet) have 
ABO. Nevertheless, thanks for your answer.


--
Peter Hunkeler



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

AW: Re: How does ABO report its outcome? (was: Migrating Cobol)

[Peter Hunkeler]

>I think a lot of it will depend on 'how good is your COBOL?'. Yeah define  
>good. Anyway using 'IBM ABO software' did find an .html Knowledge Center
>link.
  >
>https://www.ibm.com/support/knowledgecenter/SSERQD_1.2.0/c
>om.ibm.opt.doc/ug/troubleshooting.html




That basically answers my question. Thanks


--
Peter Hunkeler



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

AW: Re: Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[Peter Hunkeler]

>> How grown application written in ASM and C. Works fine since years, except 
>> for some "out of socket descriptor" problems every now and them. I was 
>> asked to help finding the cause of S23E or S53E (both DETCH) abends since 
>> the developer tries to fix the above "ourt of socket descriptor" problem. 
>> 
 >
​>What is the code in R15? Just as a guess, for the S23E, I'd bet it's x'08' 
>which says "tasking being DETACH'd is not a subtask of the task doing the 
>DETACH". 


Sorry for having forgotten to write this. 


The S23E had reason 00, meaning "The protection key of the address does not 
match the key of the issuer of the DETACH." Interesting, isn't it?


The S53E doesn't have different reasons. One of the possible causes listed in 
the manual is: "The protection key of the address does not match the key of the 
issuer of the DETACH." Seems likely since I see an S202 in the system trace 
before. I'm not in the office now, and I can't remember the S202's reason code 
for sure. I think it was 00, meaning "The system found an incorrect address for 
a request block (RB) in the 3 low-order bytes of the ECB specified by the 
problem program."


I know the program does subtasking via ATTACH and DETACH. Unfortunately, I only 
have an vague idea what the program does but don't have a clue (yet) how it 
exactly works. In fact there seems to be no-one left in the company who does. 


I would open a PMR with IBM asking for help, but thanks to great management, we 
are not allowed to send dumps. Therefore I have to get at least a basic 
understanding to be able to describe the symptoms good enough before I can even 
think of opening a PMR.


--
Peter Hunkeler


 

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

Re: SMP/E Tutorial

[John Eells]

Dan Kalmar wrote:


Can you still use PROGRAM elements for LE based modules ?


Yes, provided you can bind with the *lowest* level Language Environment 
stubs you need, as I'm assured they are compatible with later levels of 
z/OS.  (The level you need should define your minium supported z/OS 
level, too, of course.)


There is a list of libraries from which you are allowed to include 
interface code like stubs in the z/OS Licensed Progam Specifications.* 
See the topic "Redistribution of Code," here:


http://publibz.boulder.ibm.com/epubs/pdf/e0z3f112.pdf

Should you identify something that ought to be on that list, but is 
missing, please let me know.


* Of course, make sure your Legal Department concurs!

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

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

Re: SMP/E Tutorial

[John Eells]

Dan Kalmar wrote:


I will look into these suggestions.
Personally I'd rather stay away from doing link edits during the install as you 
can't be sure what gets pulled in.
For many years I worked for a large software vendor and although I never had to 
deal with the packaging aspect of products, I know that fixes were packaged and 
shipped as MODs so SMP/E would re-link the load modules on site as part of the 
maintenance apply process.
Can you still use PROGRAM elements for LE based modules ?


Whether you know exactly what will be pulled in largely depends on your 
packaging.


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

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

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Bill Woodger]

The output listing from the ABO process is designed to mesh with the output 
from the original compile.

If it doesn't, or there are difficulties, problems, suggestions for 
improvement, let IBM know.

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

Re: LISTCAT QUESTION - TEMP-EXP

[esmie moo]

John,
Thanks for answering my question.  Just to let you know that I did a REPRO from 
VSAM to VSAM. 

  From: John McKown 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Monday, March 27, 2017 11:36 AM
 Subject: Re: LISTCAT QUESTION - TEMP-EXP
   
On Mon, Mar 27, 2017 at 10:33 AM, John McKown 
wrote:

> On Mon, Mar 27, 2017 at 10:21 AM, esmie moo <012780d99c7b-dmarc-
> requ...@listserv.ua.edu> wrote:
>
>> Gentle Readers,
>> i have a question about TEMP-EXP which appears on a LISTCAT of the HSM
>> BCDS.  I did a REPRO to a test BCDS  however when I run the LISTCAT of the
>> Prod version (so as to compare the TEST & PROD. allocations) it shows
>> TEMP-EXP in the ATTRIBUTES section of the DATA & INDEX components.According
>> to the the explanation of TEMP-EXP it says "The data component was
>> temporarily exported"
>> Is my assumption that the REPRO function is the same as EXPORT? Also,
>> should I be concerned that LISTCAT indicates that a TEMP-EXP had occurred?
>> I welcome all your thoughts.  Thanks.
>>
>
> ​No. REPRO basically results in a physical sequential file which contains
> only data. That data is, generally, readable by, say, a COBOL program with
> the proper record description. In fact, it could use the same "copybook" as
> it would for the VSAM data set, assuming the VSAM data set is a KSDS, ESDS,
> or RRDS being read sequentially.
>
> OTOH, the output from an EXPORT would not be (easily) readable as if it
> were a PS data set because it contains VSAM "meta" information so that an
> IMPORT could recreate both the "schema" (i.e. do an IDCAMS DEFINE) and
> import the data.
>
> Basically, I use REPRO​
>

​Sorry, damn Windows (any fingers). I use REPRO when I want to unload the
data so that it can be read by something which cannot process VSAM. Such as
to do an ftp. Or to use a UNIX language such as AWK or PERL to read it. I
use EXPORT when I want to transfer the data to another z/OS system where I
want to restore the VSAM data as VSAM. Well, any more, I really use ADRDSSU
+ AMATERSE to transport data from z/OS to z/OS. But still, ... .​



>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> Maranatha! <><
> John McKown
>



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Maranatha! <><
John McKown

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

   

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

Re: SMP/E Tutorial

[Phil Smith]

Ah, good - maybe either (a) we were using old doc or, more likely, (b) we 
misunderstood. We have some things like SAMPLIB that aren't under SMP/E 
control, have been meaning to fix it, and this (perceived) limitation was 
standing in the way of making it easy!


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

Re: SMP/E Tutorial

[Edward Gould]

> On Mar 27, 2017, at 10:07 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> (I don't see the OP.  Did this thread originate from Usenet?)
> 
> On Mon, 27 Mar 2017 06:31:24 -0700, Phil Smith wrote:
> 
>> One thing that surprised me (and continues to be a pain) is that a given 
>> package can only have one part with a given name. ... Seems kind of 
>> primitive in this day and age, especially when you're forced to work with 
>> eight-byte names!
>> 
> I thought that constraint had been relieved.  It's particularly onerous with
> support for multiple natural languages.
> 
> UNIX objects may have longer names, but each must have a unique 8-byte name in
> the MCS.  That constraint ought to be relieved.
> 
> 
> On Mon, 27 Mar 2017 09:18:56 -0400, Charles Mills wrote:
> 
>> The referenced publication was apparently last updated in 2010. It has a lot 
>> of detail on distribution tapes but is silent on radical concepts such as 
>> FTP, pax and the Internet. When I was looking for help on how the heck to 
>> package our stuff for SMP/E I found it less than a complete tutorial, to say 
>> the least.
>> 
> Yup.  I submitted an RCF on this a couple years ago.  I see no effect.
> 
> On Mon, 27 Mar 2017 08:37:27 -0400, Kurt Quackenbush wrote:
>> 
>> You can greatly simplify you and your customers' efforts if you can
>> avoid MODs and JCLIN altogether.  That is, it is far simpler to package
>> complete load modules using PROGRAM elements rather than as individual
>> MODs with JCLIN.  PROGRAM elements treat load modules as simple members
>> of a partitioned data set that can be copied and replaced.  No JCLIN is
>> necessary and no link edit processing is performed by SMP/E.
>> 
> The supplier must initiallly build the PROGRAM element using Binder
> control statements.  Instead, these could be converted to JCLIN for
> use wiht MOD elements.  The remaining hard part is generating the
> CSECT operand for ++MOD MCS.  I've done this by scanning the
> SYSLIN.  It would be a valuable feature if SMP/E incorporated this
> process in APPLY, relieving the supplier of the burden.
> 
>> To determine if you can successfully use PROGRAM elements you have to
>> consider the contents of your load modules and how they are built.  Do
>> your load modules include any parts not supplied by you?  For example,
>> callable services from CSSLIB or SCEELKED?  Modules from subsystems or
>> other products, like SDSNLOAD or ISPLLIB?  Side decks (IMPORT
>> statements) to resolve DLL references?  If so, then you may want to, or
>> need to, package individual modules as MODs and supply JCLIN to define
>> your load modules.  Shucks.  However, if your load modules are rather
>> simple and include only modules that you own, then you should consider
>> using PROGRAM elements in your SYSMOD packaging for your initial
>> FUNCTION and subsequent PTFs.
>> 
> ++PROGRAM packaging leads to enormous PTFs with problems of
> overflow of SMPPTS and SMPNTS.
> 
> Some customers prefer fine-grained service where each PTF targets
> a single problem.  IIRC, Ed Gould has expressed such sentiments.  But
> cafeteria-style service where each customer can customize a PTF
> selection allows a customer the opportunity to create a configuration
> that the supplier has never tested.
Gil,
I think I would interject here and say this.
*UNLESS* your module is real really large (LIKE JAVA) disregard the succeeding 
statements.
I have seen rather *LARGE* z/os PTFS and unless you have a small PTS they can 
be handled easily.
JAVA is HUMONGOUS and that is where Gils comments are reasonable.
*IF* your product is LARGE then Gills comments are applicable. What is Large? 
anything over say 20,000 80 byte “cards” would mandate some instructions that 
are in BOLD and maybe a larger font to tell the user that the libraries must be 
enlarged by say X percent.
I have seen most typical installions of the typical product and I have yet to 
see anything worth getting excited about.
Welcome to the club and I hope you believe in PREREQ and SUPs and do *NOT* tell 
the user to bypass(ID) like one product that is made by a equally hated vendor 
who will remain nameless.
Ed

 
> 
> If a ++MOD element contains PC sections, those are not replaced by
> service; the accumulate with each PTF.
> 
> ++PROGRAM service can create long PRErequisite chains.  If an earlier
> PTF has ++HOLD, all subsequent PTFs are blocked until that hold is
> resolved.
> 
> (HLASM prints its PTF level in each SYSPRINT.  I expect this to be done
> by each PTF's replacing a CSECT that contains its ID.  This should result
> in absolutely linear PRErequisite chains.)
> 
> -- 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 

Re: LISTCAT QUESTION - TEMP-EXP

[John McKown]

On Mon, Mar 27, 2017 at 10:33 AM, John McKown 
wrote:

> On Mon, Mar 27, 2017 at 10:21 AM, esmie moo <012780d99c7b-dmarc-
> requ...@listserv.ua.edu> wrote:
>
>> Gentle Readers,
>> i have a question about TEMP-EXP which appears on a LISTCAT of the HSM
>> BCDS.  I did a REPRO to a test BCDS  however when I run the LISTCAT of the
>> Prod version (so as to compare the TEST & PROD. allocations) it shows
>> TEMP-EXP in the ATTRIBUTES section of the DATA & INDEX components.According
>> to the the explanation of TEMP-EXP it says "The data component was
>> temporarily exported"
>> Is my assumption that the REPRO function is the same as EXPORT? Also,
>> should I be concerned that LISTCAT indicates that a TEMP-EXP had occurred?
>> I welcome all your thoughts.  Thanks.
>>
>
> ​No. REPRO basically results in a physical sequential file which contains
> only data. That data is, generally, readable by, say, a COBOL program with
> the proper record description. In fact, it could use the same "copybook" as
> it would for the VSAM data set, assuming the VSAM data set is a KSDS, ESDS,
> or RRDS being read sequentially.
>
> OTOH, the output from an EXPORT would not be (easily) readable as if it
> were a PS data set because it contains VSAM "meta" information so that an
> IMPORT could recreate both the "schema" (i.e. do an IDCAMS DEFINE) and
> import the data.
>
> Basically, I use REPRO​
>

​Sorry, damn Windows (any fingers). I use REPRO when I want to unload the
data so that it can be read by something which cannot process VSAM. Such as
to do an ftp. Or to use a UNIX language such as AWK or PERL to read it. I
use EXPORT when I want to transfer the data to another z/OS system where I
want to restore the VSAM data as VSAM. Well, any more, I really use ADRDSSU
+ AMATERSE to transport data from z/OS to z/OS. But still, ... .​



>
>
> --
> "Irrigation of the land with seawater desalinated by fusion power is
> ancient. It's called 'rain'." -- Michael McClary, in alt.fusion
>
> Maranatha! <><
> John McKown
>



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: LISTCAT QUESTION - TEMP-EXP

[John McKown]

On Mon, Mar 27, 2017 at 10:21 AM, esmie moo <
012780d99c7b-dmarc-requ...@listserv.ua.edu> wrote:

> Gentle Readers,
> i have a question about TEMP-EXP which appears on a LISTCAT of the HSM
> BCDS.  I did a REPRO to a test BCDS  however when I run the LISTCAT of the
> Prod version (so as to compare the TEST & PROD. allocations) it shows
> TEMP-EXP in the ATTRIBUTES section of the DATA & INDEX components.According
> to the the explanation of TEMP-EXP it says "The data component was
> temporarily exported"
> Is my assumption that the REPRO function is the same as EXPORT? Also,
> should I be concerned that LISTCAT indicates that a TEMP-EXP had occurred?
> I welcome all your thoughts.  Thanks.
>

​No. REPRO basically results in a physical sequential file which contains
only data. That data is, generally, readable by, say, a COBOL program with
the proper record description. In fact, it could use the same "copybook" as
it would for the VSAM data set, assuming the VSAM data set is a KSDS, ESDS,
or RRDS being read sequentially.

OTOH, the output from an EXPORT would not be (easily) readable as if it
were a PS data set because it contains VSAM "meta" information so that an
IMPORT could recreate both the "schema" (i.e. do an IDCAMS DEFINE) and
import the data.

Basically, I use REPRO​


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: SMP/E Tutorial

[Jesse 1 Robinson]

(Now with actual text.) My experience matches Charles's. We have usermods with 
SRC, MOD, and LMOD entries all with the same name. As long as the entry types 
are different, SMP/E has no problem managing like-named elements. 


.
.
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 Charles Mills
Sent: Monday, March 27, 2017 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SMP/E Tutorial

As you can tell from my previous post I am neither an SMP/E expert nor an SMP/E 
fan but I think you can have two BANANAs provided they are different kinds of 
things. Going into different destinations (target PDS) is not enough, they have 
to be different kinds of things: TEXTENU, SAMPENU, etc.
You can't have two different SAMPENUs named BANANA, even in different RELFILEs, 
but you can have a TEXTENU named BANANA and a SAMPENU named BANANA.

Obscure and arcane. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Monday, March 27, 2017 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Tutorial

One thing that surprised me (and continues to be a pain) is that a given 
package can only have one part with a given name. So if you have a sample 
program called BANANA and quite reasonably wanted to have a .JCL library with a 
sample job to run it called BANANA, and the source in a .SOURCE library also 
called BANANA, you can't do that. Seems kind of primitive in this day and age, 
especially when you're forced to work with eight-byte names!

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


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

Re: (External):Re: SMP/E Tutorial

[Jesse 1 Robinson]

.
.
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 Charles Mills
Sent: Monday, March 27, 2017 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SMP/E Tutorial

As you can tell from my previous post I am neither an SMP/E expert nor an SMP/E 
fan but I think you can have two BANANAs provided they are different kinds of 
things. Going into different destinations (target PDS) is not enough, they have 
to be different kinds of things: TEXTENU, SAMPENU, etc.
You can't have two different SAMPENUs named BANANA, even in different RELFILEs, 
but you can have a TEXTENU named BANANA and a SAMPENU named BANANA.

Obscure and arcane. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith
Sent: Monday, March 27, 2017 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Tutorial

One thing that surprised me (and continues to be a pain) is that a given 
package can only have one part with a given name. So if you have a sample 
program called BANANA and quite reasonably wanted to have a .JCL library with a 
sample job to run it called BANANA, and the source in a .SOURCE library also 
called BANANA, you can't do that. Seems kind of primitive in this day and age, 
especially when you're forced to work with eight-byte names!

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

LISTCAT QUESTION - TEMP-EXP

[esmie moo]

Gentle Readers,
i have a question about TEMP-EXP which appears on a LISTCAT of the HSM BCDS.  I 
did a REPRO to a test BCDS  however when I run the LISTCAT of the Prod version 
(so as to compare the TEST & PROD. allocations) it shows TEMP-EXP in the 
ATTRIBUTES section of the DATA & INDEX components.According to the the 
explanation of TEMP-EXP it says "The data component was temporarily exported"
Is my assumption that the REPRO function is the same as EXPORT? Also, should I 
be concerned that LISTCAT indicates that a TEMP-EXP had occurred?
I welcome all your thoughts.  Thanks.

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

Re: SMP/E Tutorial

[Paul Gilmartin]

(I don't see the OP.  Did this thread originate from Usenet?)

On Mon, 27 Mar 2017 06:31:24 -0700, Phil Smith wrote:

>One thing that surprised me (and continues to be a pain) is that a given 
>package can only have one part with a given name. ... Seems kind of primitive 
>in this day and age, especially when you're forced to work with eight-byte 
>names!
> 
I thought that constraint had been relieved.  It's particularly onerous with
support for multiple natural languages.

UNIX objects may have longer names, but each must have a unique 8-byte name in
the MCS.  That constraint ought to be relieved.


On Mon, 27 Mar 2017 09:18:56 -0400, Charles Mills wrote:

>The referenced publication was apparently last updated in 2010. It has a lot 
>of detail on distribution tapes but is silent on radical concepts such as FTP, 
>pax and the Internet. When I was looking for help on how the heck to package 
>our stuff for SMP/E I found it less than a complete tutorial, to say the least.
>
Yup.  I submitted an RCF on this a couple years ago.  I see no effect.

On Mon, 27 Mar 2017 08:37:27 -0400, Kurt Quackenbush wrote:
>
>You can greatly simplify you and your customers' efforts if you can
>avoid MODs and JCLIN altogether.  That is, it is far simpler to package
>complete load modules using PROGRAM elements rather than as individual
>MODs with JCLIN.  PROGRAM elements treat load modules as simple members
>of a partitioned data set that can be copied and replaced.  No JCLIN is
>necessary and no link edit processing is performed by SMP/E.
>
The supplier must initiallly build the PROGRAM element using Binder
control statements.  Instead, these could be converted to JCLIN for
use wiht MOD elements.  The remaining hard part is generating the
CSECT operand for ++MOD MCS.  I've done this by scanning the
SYSLIN.  It would be a valuable feature if SMP/E incorporated this
process in APPLY, relieving the supplier of the burden.

>To determine if you can successfully use PROGRAM elements you have to
>consider the contents of your load modules and how they are built.  Do
>your load modules include any parts not supplied by you?  For example,
>callable services from CSSLIB or SCEELKED?  Modules from subsystems or
>other products, like SDSNLOAD or ISPLLIB?  Side decks (IMPORT
>statements) to resolve DLL references?  If so, then you may want to, or
>need to, package individual modules as MODs and supply JCLIN to define
>your load modules.  Shucks.  However, if your load modules are rather
>simple and include only modules that you own, then you should consider
>using PROGRAM elements in your SYSMOD packaging for your initial
>FUNCTION and subsequent PTFs.
>
++PROGRAM packaging leads to enormous PTFs with problems of
overflow of SMPPTS and SMPNTS.

Some customers prefer fine-grained service where each PTF targets
a single problem.  IIRC, Ed Gould has expressed such sentiments.  But
cafeteria-style service where each customer can customize a PTF
selection allows a customer the opportunity to create a configuration
that the supplier has never tested.

If a ++MOD element contains PC sections, those are not replaced by
service; the accumulate with each PTF.

++PROGRAM service can create long PRErequisite chains.  If an earlier
PTF has ++HOLD, all subsequent PTFs are blocked until that hold is
resolved.

(HLASM prints its PTF level in each SYSPRINT.  I expect this to be done
by each PTF's replacing a CSECT that contains its ID.  This should result
in absolutely linear PRErequisite chains.)

-- gil

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

Re: How does ABO report its outcome? (was: Migrating Cobol)

[DiBianca, Robert]

As far as finding the source statement, yes this is possible with ABO.

We run IBM's Fault Analyzer and it has PTFs that make it compatible with ABO 
optimized code.  So, this tool can go through the updated 'listing' file 
produced as part of the ABO output to help get back to the original source code.

I would guess that other tools (ie: Abend Aid) would be able to do the same 
thing.

As far as doing it manually - good luck, but with the output from the 
optimization run, you can probably figure out how to get back to your original 
code.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, March 27, 2017 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How does ABO report its outcome? (was: Migrating Cobol)

So ABO optimizes LOAD modules.

Optimized applications created with Automatic Binary Optimizer for z/OS are 
supported by IBM DevOps Tools, which include IBM Application Delivery 
Foundation for z Systems family of products:

Developer for z Systems Enterprise Edition, which includes Debug for z 
Systems (previously known as Debug Tool for z/OS). Helps examine, monitor, and 
control the execution of application programs.

Fault Analyzer for z/OS.

Helps developers analyze and fix application and system failures.

Gathers information about an application and the surrounding 
environment.

Application Performance Analyzer for z/OS. Helps developers in the design, 
development and maintenance cycles with an non-intrusive application 
performance analyzer.

Additional information can be found on the Application Delivery Foundation for 
z Systems website.


Not sure if this helps or not.

Check out this PDF.  Also, make sure all current fixes are applied to ABO 
http://publibfp.boulder.ibm.com/epubs/pdf/c2785453.pdf



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Hunkeler
> Sent: Sunday, March 26, 2017 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How does ABO report its outcome? (was: Migrating Cobol)
>
> To help search engines: ABO = Automatic Binary Optimizer
>
> >We haven't set off down the yellow-brick ABO road, so it's hard to
> >gauge how
> much angst we'll actually have to overcome. I'm pretty sure it won't
> be trivial.
>
>
>
>
> I haven't seen ABO in action yet. Is there a listing that relates the
> instructions after the optimization to the source statement? I
> suspect, there isn't. Is LE still able to tell the statement where the
> problem occurred? How would one find the source statement that cause
> the the problem to occur? I'm often involved in cases where I have to work 
> with machine readable dumps.
>
> --
> Peter Hunkeler

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


The information in this transmission may contain proprietary and non-public 
information of BB or its affiliates and may be subject to protection under 
the law. The message is intended for the sole use of the individual or entity 
to which it is addressed. If you are not the intended recipient, you are 
notified that any use, distribution or copying of the message is strictly 
prohibited. If you received this message in error, please delete the material 
from your system without reading the content and notify the sender immediately 
of the inadvertent transmission.

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

Re: Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[John McKown]

On Mon, Mar 27, 2017 at 9:33 AM, Peter Hunkeler  wrote:

> How grown application written in ASM and C. Works fine since years, except
> for some "out of socket descriptor" problems every now and them. I was
> asked to help finding the cause of S23E or S53E (both DETCH) abends since
> the developer tries to fix the above "ourt of socket descriptor" problem.
>

​What is the code in R15? Just as a guess, for the S23E, I'd bet it's x'08'
which says "tasking being DETACH'd is not a subtask of the task doing the
DETACH". For the S53E, I don't have a good guess. If this is getting the
"true PGM 011" (whatever that means), perhaps the ECB to be posted is in an
area which as been FREEMAIN'd or the EXTR routine has been DELETEd, perhaps
by some other task, which did the LOAD, ending previously.​



>
>
> I have set SLIP traps to catch the S23E or S53E. I do have some svcdumps.
> I have found some hints in the dump. I suspect some storage overlay but am
> stuck at the moment. Need some fresh ideas.
>
>
> From the system trace I see that the S23E or S53E is preceeded by an S202
> and sometime a true PGM 011.
>

​Again, what is in R15. If it is x'0C', then the storage containing the ECB
has likely been FREEMAIN'd. Or, as you have indicated, that the area which
should have the address of the ECB was contaminated and the area containing
the pointer to the ECB was overlain.​



>
>
> Some questions:
>
>
> a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in
> read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful
> information for me?
>
>
> b) I know "SVC D" is also entered for normal task termination. In an
> ld MVS debugging manual I found that the first byte of R1 is x'08' this
> indicates RTM2 is called for task termination cleanup. The x'08 does no
> longer seem to hold true. How can I identify such an non-error an SVC D
> entry?
>
>
> c) In some dumps I see "SVC 3" (exit) trace entries, sometimes I can see
> the "SVC 3E" (DETACH), sometime it is not in the trace.
>
>
> Thoughts?
>
>
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: SMP/E Tutorial

[Charles Mills]

As you can tell from my previous post I am neither an SMP/E expert nor an
SMP/E fan but I think you can have two BANANAs provided they are different
kinds of things. Going into different destinations (target PDS) is not
enough, they have to be different kinds of things: TEXTENU, SAMPENU, etc.
You can't have two different SAMPENUs named BANANA, even in different
RELFILEs, but you can have a TEXTENU named BANANA and a SAMPENU named
BANANA.

Obscure and arcane. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith
Sent: Monday, March 27, 2017 9:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Tutorial

One thing that surprised me (and continues to be a pain) is that a given
package can only have one part with a given name. So if you have a sample
program called BANANA and quite reasonably wanted to have a .JCL library
with a sample job to run it called BANANA, and the source in a .SOURCE
library also called BANANA, you can't do that. Seems kind of primitive in
this day and age, especially when you're forced to work with eight-byte
names!

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

Seeking for help finding cause of S23E/S53E with preceeding S202, and PGM 011/004

[Peter Hunkeler]

How grown application written in ASM and C. Works fine since years, except for 
some "out of socket descriptor" problems every now and them. I was asked to 
help finding the cause of S23E or S53E (both DETCH) abends since the developer 
tries to fix the above "ourt of socket descriptor" problem.


I have set SLIP traps to catch the S23E or S53E. I do have some svcdumps. I 
have found some hints in the dump. I suspect some storage overlay but am stuck 
at the moment. Need some fresh ideas.


>From the system trace I see that the S23E or S53E is preceeded by an S202 and 
>sometime a true PGM 011.


Some questions:


a) I see a couple of FREEMAIN (SSRV 78) trace entries pointing to a TCB in 
read/write nucleus (TCB address is 00FDD4F8). Do these hold some useful 
information for me?


b) I know "SVC D" is also entered for normal task termination. In an ld MVS 
debugging manual I found that the first byte of R1 is x'08' this indicates RTM2 
is called for task termination cleanup. The x'08 does no longer seem to hold 
true. How can I identify such an non-error an SVC D entry?


c) In some dumps I see "SVC 3" (exit) trace entries, sometimes I can see the 
"SVC 3E" (DETACH), sometime it is not in the trace.


Thoughts?




--
Peter Hunkeler

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

Re: GREAT presentation on the history of the mainframe

[R.S.]

Dana,
Thank you for the response, I appreciate it.

Just minor remarks:
* HMC in 9672 was OS/2 based (at least since G3)
* There were some crypto options in pre-9672 machines, it was rather 
predecessor of CCF, not the cards. I have some information it was ICRF 
(Integrated CRyptographic Feature) which consisted of TCM and KSU (Key 
Storage Unit).

Not to mention earlier 4753 aka NSP or 3945.
* I believe first OSA in 9672 was OSA2 and  of course there was OSA (1) 
before.
* I vaguely remember some photograph of pre-9672 machina (which one?) 
with cards similar to those in 9672.



Regards
--
Radoslaw Skorupka
Lodz, Poland








W dniu 2017-03-27 o 16:09, Dana Mitchell pisze:

On Fri, 24 Mar 2017 20:44:10 +0100, R.S.  wrote:


BTW:
What about LPARs?

3090 was first generation with PR/SM facility.  CEC could be PORed in PR/SM 
mode or 370 mode.


How HMC looked like? Was it PC-DOS-based?

4331/4341 had a dedicated 3278 with extra buttons and LED's on keyboard, could 
also be used as operating system console.  3083/3081 had dedicated 3270s one 
mounted inside 3082 processor controller.  3090 had dedicated 3180 displays for 
system control.   9672 had first linux based HMC.


What about I/O cards? were they similar to cards available in 9672?

4331 had integrated disk and communication adapters built in, no 3274, 3705, 
3880 controllers required.  Later machines just had parallel channels just sort 
of built in,  not really on cards.  3090 was first with ESCON


What OSA options were available?

First on 9672, I think was basically a 3172 built into frame.


What about cryptoHW?

nope

Dana

--





--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: GREAT presentation on the history of the mainframe

[Dana Mitchell]

On Fri, 24 Mar 2017 20:44:10 +0100, R.S.  wrote:

>BTW:
>What about LPARs?

3090 was first generation with PR/SM facility.  CEC could be PORed in PR/SM 
mode or 370 mode.

>How HMC looked like? Was it PC-DOS-based?

4331/4341 had a dedicated 3278 with extra buttons and LED's on keyboard, could 
also be used as operating system console.  3083/3081 had dedicated 3270s one 
mounted inside 3082 processor controller.  3090 had dedicated 3180 displays for 
system control.   9672 had first linux based HMC.

>What about I/O cards? were they similar to cards available in 9672?

4331 had integrated disk and communication adapters built in, no 3274, 3705, 
3880 controllers required.  Later machines just had parallel channels just sort 
of built in,  not really on cards.  3090 was first with ESCON

>What OSA options were available?

First on 9672, I think was basically a 3172 built into frame.

>What about cryptoHW?
nope

Dana

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

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Lizette Koehler]

So ABO optimizes LOAD modules.  

Optimized applications created with Automatic Binary Optimizer for z/OS are
supported by IBM DevOps Tools, which include IBM Application Delivery Foundation
for z Systems family of products:

Developer for z Systems Enterprise Edition, which includes Debug for z
Systems (previously known as Debug Tool for z/OS). Helps examine, monitor, and
control the execution of application programs.

Fault Analyzer for z/OS.

Helps developers analyze and fix application and system failures.

Gathers information about an application and the surrounding
environment. 

Application Performance Analyzer for z/OS. Helps developers in the design,
development and maintenance cycles with an non-intrusive application performance
analyzer. 

Additional information can be found on the Application Delivery Foundation for z
Systems website.


Not sure if this helps or not.

Check out this PDF.  Also, make sure all current fixes are applied to ABO
http://publibfp.boulder.ibm.com/epubs/pdf/c2785453.pdf



Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Sunday, March 26, 2017 10:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: How does ABO report its outcome? (was: Migrating Cobol)
> 
> To help search engines: ABO = Automatic Binary Optimizer
> 
> >We haven't set off down the yellow-brick ABO road, so it's hard to gauge how
> much angst we'll actually have to overcome. I'm pretty sure it won't be
> trivial.
> 
> 
> 
> 
> I haven't seen ABO in action yet. Is there a listing that relates the
> instructions after the optimization to the source statement? I suspect, there
> isn't. Is LE still able to tell the statement where the problem occurred? How
> would one find the source statement that cause the the problem to occur? I'm
> often involved in cases where I have to work with machine readable dumps.
> 
> --
> Peter Hunkeler

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

Re: SMP/E Tutorial

[Phil Smith]

One thing that surprised me (and continues to be a pain) is that a given 
package can only have one part with a given name. So if you have a sample 
program called BANANA and quite reasonably wanted to have a .JCL library with a 
sample job to run it called BANANA, and the source in a .SOURCE library also 
called BANANA, you can't do that. Seems kind of primitive in this day and age, 
especially when you're forced to work with eight-byte names!

Obviously if I'm wrong here I'd love to be corrected...
(And maybe everyone knew this from birth except me)
--
...phsiii

Phil Smith III


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

Re: SMP/E Tutorial

[Charles Mills]

The referenced publication was apparently last updated in 2010. It has a lot of 
detail on distribution tapes but is silent on radical concepts such as FTP, pax 
and the Internet. When I was looking for help on how the heck to package our 
stuff for SMP/E I found it less than a complete tutorial, to say the least.

Do you need SMP/E at all? Consider instead using the new z/OSMF "export a 
software instance" facility. Slick as can be. z/OSMF now a standard part of 
z/OS.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Monday, March 27, 2017 8:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMP/E Tutorial

On 3/27/2017 7:52 AM, Dan Kalmar wrote:
> Can anyone recommend a good tutorial for using SMP/E to package a new 
> product for distribution ?

Not so much a tutorial, but try "IBM, Standard Packaging Rules for z/OS-Based 
Products" here:
http://publibz.boulder.ibm.com/epubs/pdf/gimpkg80.pdf

Some personal thoughts on the process of packaging your software in SMP/E 
SYSMOD format:  I assume one of the reasons you are asking is not so much 
because you (or your customers) think the initial install of your software in 
SMP/E format is very exciting, but rather because of the prospect of follow-on 
service in PTF format.  Therefore, you must consider how you intend to supply 
parts/files later in PTFs before you create your initial FUNCTION SYSMOD.

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

Re: SMP/E Tutorial

[Kurt Quackenbush]

On 3/27/2017 7:52 AM, Dan Kalmar wrote:

Can anyone recommend a good tutorial for using SMP/E to package a new
product for distribution ?


Not so much a tutorial, but try "IBM, Standard Packaging Rules for 
z/OS-Based Products" here:

http://publibz.boulder.ibm.com/epubs/pdf/gimpkg80.pdf

Some personal thoughts on the process of packaging your software in 
SMP/E SYSMOD format:  I assume one of the reasons you are asking is not 
so much because you (or your customers) think the initial install of 
your software in SMP/E format is very exciting, but rather because of 
the prospect of follow-on service in PTF format.  Therefore, you must 
consider how you intend to supply parts/files later in PTFs before you 
create your initial FUNCTION SYSMOD.


In my opinion, most parts/files ("elements" in SMP/E terminology) are 
very simple to package and install.  Things like procs, parmlib members, 
sample JCL, execs, ISPF panels, are all very simple to manage, package, 
and install, because they are just members of a partitioned data set 
that are copied and replaced by SMP/E.  It is modules and load modules 
that cause the most grief.


Traditional z/OS software is SMP/E packaged using MOD elements to 
describe modules that get link edited during the APPLY to create load 
modules (load modules or program objects).  It is link edit steps in 
JCLIN that tells SMP/E how to put the MODs together to create these load 
modules.  This is all a very well grooved path, but, JCLIN and MODs can 
be a great pain, and I'd say the cause of most grief for packagers and 
installers.


You can greatly simplify you and your customers' efforts if you can 
avoid MODs and JCLIN altogether.  That is, it is far simpler to package 
complete load modules using PROGRAM elements rather than as individual 
MODs with JCLIN.  PROGRAM elements treat load modules as simple members 
of a partitioned data set that can be copied and replaced.  No JCLIN is 
necessary and no link edit processing is performed by SMP/E.


To determine if you can successfully use PROGRAM elements you have to 
consider the contents of your load modules and how they are built.  Do 
your load modules include any parts not supplied by you?  For example, 
callable services from CSSLIB or SCEELKED?  Modules from subsystems or 
other products, like SDSNLOAD or ISPLLIB?  Side decks (IMPORT 
statements) to resolve DLL references?  If so, then you may want to, or 
need to, package individual modules as MODs and supply JCLIN to define 
your load modules.  Shucks.  However, if your load modules are rather 
simple and include only modules that you own, then you should consider 
using PROGRAM elements in your SYSMOD packaging for your initial 
FUNCTION and subsequent PTFs.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: How does ABO report its outcome? (was: Migrating Cobol)

[Edward Finnell]

I think a lot of it will depend on 'how good is your COBOL?'. Yeah define  
good. Anyway using 'IBM ABO software' did find an .html Knowledge Center  
link.
 
https://www.ibm.com/support/knowledgecenter/SSERQD_1.2.0/c
om.ibm.opt.doc/ug/troubleshooting.html
 
 
In a message dated 3/27/2017 12:36:14 A.M. Central Daylight Time,  
p...@gmx.ch writes:

I  haven't seen ABO in action yet. Is there a listing that relates the  
instructions after the optimization to the source statement? I suspect, there  
isn't. Is LE still able to tell the statement where the problem occurred? 
How  would one find the source statement that cause the the problem to occur? 
I'm  often involved in cases where I have to work with machine readable 
dumps.  


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