Re: Address of SRB rtn

[Peter Relson]

The SRB itself (the control block) needs to be in common storage.
The SRB routine needs to be addressable from wherever the machine will 
fetch instructions from when it is running (i.e., if it is running only 
with P=X, it can be in X).

Peter Relson
z/OS Core Technology Design

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

Re: Address of SRB rtn

[McKown, John]

Was there ever a type of SRB that could run in any address space, picked "at 
random"? Or have they always been scheduled with a particular address space 
dispatched (selected by coder)? I have a vague memory of some dispatchable unit 
which could run in "some" address space, but which one was not deterministic. 
But maybe the memory is due to a faulty understanding on my part. Wouldn't be 
the first time. Won't be the last.

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Peter Relson
> Sent: Monday, December 03, 2012 6:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Address of SRB rtn
> 
> The SRB itself (the control block) needs to be in common storage.
> The SRB routine needs to be addressable from wherever the machine will
> fetch instructions from when it is running (i.e., if it is running only
> with P=X, it can be in X).
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

CHPID TYPE OSE Port 1 of OSA Express3

[Rebecca Martin]

We are having problems using port 1 of our new OSA Express3 T1000 on a z114 (4 
ports with 2 PCHID).  Running z/OS 1.12.  The CHPID is defined as TYPE=OSE.  
For both of our two cards that we are trying to also use port 1, D M=CHP(xx) 
shows "PATH NOT OPERATIONAL" and "PATH NOT VALIDATED".  Port 0 is fine on both 
of these.  
Based on information from our hardware vendor these are the definitions we used:
CHPID PATH=(CSS(0),00),SHARED,*
   PARTITION=((all lpars,are listed here),(=)),PCHID=200,TYPE=OSE   
CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
 IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA

Because the paths are not operational, I don't think the problem is in our 
TCPIP profile but will share that as well for completeness:
DEVICE OSAFC00 LCS   FC00  AUTORESTART   
LINK   ETH1ETHERNET  0 OSAFC00   
 DEVICE OSAFC10 LCS   FC10  AUTORESTART  
 LINK ETH1  ETHERNET 1 OSAFC10   
FC00 is used on 1 LPAR and FC10 on another.  

 FC00 - is attached to port 0 (and working) and FC10 should be port 1 (and is 
not working).Cabling has been checked multiple times.

Our hardware vendor has a call into IBM, but I thought I might get an answer 
faster here from those that have BTDT.

Thank you for any help or suggestions.
Rebecca  

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

Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta

[McKown, John]

Nifty. Thanks for the cross post. I've downloaded it. 

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Robert Prins
> Sent: Sunday, December 02, 2012 10:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta
> 
> From a posting on the forum of "that" system:
> 
> 
> I've ported the PCRE (Perl Compatible Regular Expressions) to native
> z/OS (no USS [Unix Servicses], just good ol' native z/OS), including
> COBOL API. The installation file is available on:
> http://www.zaconsultants.net on the downloads page.
> 
> The concept of Regular Expressions is new for most COBOL and PL/I
> programmers on the z/OS platform, but is old news for Unix and Linux
> programmers. Regular Expressions is a technology that allows finding
> patterns in text strings in ways that are not currently available in
> COBOL, PL/I or even Rexx.
> 
> The power of regular expressions is widely used by Java, VB.net, C#,
> PHP and Perl, to mention some of the most popular languages. The
> package that I've ported is the same one that is used by PHP and is
> highly compatible with Perl which is the standard setter for that
> stuff. In other words, I brought the most advanced form of Regular
> Expressions into the COBOL, PL/I and z/OS world.
> 
> I hope that the availability of PCRE would encourage all z/OS COBOL and
> PL/I programmers to learn about regular expressions and utilize this
> port. The license is BSD which pretty much allows use and even resell
> software based on it with very few real limitations.
> 
> We are working to introduce PCRE to PL/I for MVS, z/VM and Rexx, but
> COBOL and PL/I enterprise seem to be working fins
> 
> The files should also be available on CBTTTAPE.ORG and some other
> mirror site.
> ZA
> 
> Robert
> --
> Robert AH Prins
> robert.ah.pr...@gmail.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: LOAD and DELETE macro instructions

[Peter Relson]

Let me put it simply:

In my opinion, unless you can guarantee that the owning task (for EOM=NO) 
or owning address space (for EOM=YES) will never terminate, you should 
never use LOAD with GLOBAL=YES.
It is almost (perhaps beyond "almost") impossible to serialize access to 
such code in such a way that if it gets freed there will be no subsequent 
access (where that access could blow up, could get incorrect data, or 
could be a system integrity problem depending upon how the storage was 
subsequently used).

If you have an executable module, use CSVDYLPA. In fact, use CSVDYLPA 
whether or not your task and/or address space ever terminates. 
If you have data, use LOAD with ADDR having first obtained the storage in 
whatever subpool meets your needs.

Peter Relson
z/OS Core Technology Design

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

Re: Address of SRB rtn

[Micheal Burn]

So if it runs in Address space x it can be in pvt storage of address space x

Sent from my iPhone

On Dec 3, 2012, at 7:46 AM, Peter Relson  wrote:

> The SRB itself (the control block) needs to be in common storage.
> The SRB routine needs to be addressable from wherever the machine will 
> fetch instructions from when it is running (i.e., if it is running only 
> with P=X, it can be in X).
> 
> Peter Relson
> z/OS Core Technology Design
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)

[Shmuel Metz (Seymour J.)]

In
<9673478860418448.wa.charles.kreiterbwc.state.oh...@listserv.ua.edu>,
on 11/30/2012
   at 12:23 PM, Chuck Kreiter  said:

>I always reserve SEV 1 to issues that have made my primary systems
>unusable.  I have had IBM'ers tell us to raise to SEV 1 in the
>morning and then drop to SEV 2 at quitting time.  This never set 
>well with me.  I had a supervisor (who was and remains an idiot) 
>who wanted me to open a SEV 1 ticket for an issue we had already
>identified and implemented a work around .

He wouldn't have liked me; I drop the severity once I get an
acceptable workaround.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)

[Shmuel Metz (Seymour J.)]

In <9045833222889555.wa.markmzelden@listserv.ua.edu>, on
11/30/2012
   at 02:18 PM, Mark Zelden  said:

>What I've done in those cases is to open as a Sev 2 and then 
>explain the criticality of the situation and say "please treat 
>this like a sev 1" and  that has worked well for me.   Of course 
>management (not my manager, but people above him) wants 
>everything opened as a Sev 1 when it affects our clients systems, 
>but I try not to do that except when there is an outage involved.   
>I use to work for a shop who's manager always wanted Sev 1s 
>opened for things I didn't consider Sev 1 and anything that was a 
>Sev 1 was escalated to a crit sit.  I figured IBM looked at the 
>sev 1s and said "oh, it's them again" and just treated it like a 
>sev 2.  :-)  (boy who cried wolf syndrome)

That's why I prefer to open incidents as Sev 3[1]; when I open one at
Sev 1 or Sev 2, I don't have a rack record of severity inflation to
ruin my credibility.

[1] With the occasional Sev 4. Yes, IBM does eventually deal
with those.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Donald J.]

What is in your VTAM TRLE nodes?
-- 
  Donald J.
  dona...@4email.net


On Mon, Dec 3, 2012, at 05:43 AM, Rebecca Martin wrote:
> We are having problems using port 1 of our new OSA Express3 T1000 on a
> z114 (4 ports with 2 PCHID).  Running z/OS 1.12.  The CHPID is defined as
> TYPE=OSE.  For both of our two cards that we are trying to also use port
> 1, D M=CHP(xx) shows "PATH NOT OPERATIONAL" and "PATH NOT VALIDATED". 
> Port 0 is fine on both of these.  
> Based on information from our hardware vendor these are the definitions
> we used:
> CHPID PATH=(CSS(0),00),SHARED,*
>PARTITION=((all lpars,are listed
>here),(=)),PCHID=200,TYPE=OSE   
> CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
>  IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA
> 
> Because the paths are not operational, I don't think the problem is in
> our TCPIP profile but will share that as well for completeness:
> DEVICE OSAFC00 LCS   FC00  AUTORESTART   
> LINK   ETH1ETHERNET  0 OSAFC00   
>  DEVICE OSAFC10 LCS   FC10  AUTORESTART  
>  LINK ETH1  ETHERNET 1 OSAFC10   
> FC00 is used on 1 LPAR and FC10 on another.  
> 
>  FC00 - is attached to port 0 (and working) and FC10 should be port 1
>  (and is not working).Cabling has been checked multiple times.
> 
> Our hardware vendor has a call into IBM, but I thought I might get an
> answer faster here from those that have BTDT.
> 
> Thank you for any help or suggestions.
> Rebecca  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Rebecca Martin]

Donald, for LCS we have no VTAM definition only what is in the TCPIP profile.

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Rebecca Martin]

FYI - Looks like our hardware vendor has found the answer (I'll know for sure a 
bit later on):

After spending a while researching and thinking about the OSA problem, here's 
what I think it is.
For the OSE cards, when TCP/IP is started, it uses the information in the 
TCP/IP profile to load the port with IP address, etc, that the port needs to 
connect to the network.   The default configuration that gets loaded onto the 
OSE chpids during POR has entries for unitadd 00 and 01, which makes the port 0 
connections work.  For port 1 the definitions are unitadd 10 and 11 for FC40 
and FC10.  Those unitadds do not get set up right in the card's default 
configuration.

Here's the fix :
In HCD, add a device definition for a device type OSAD at unitadd FE to each of 
the OSE chpids, like the following:
CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA 
IODEVICE ADDRESS=FCFE,UNITADD=FE,CUNUMBR=FC00),UNIT=OSAD   <--
 
CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA  
IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA 
IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA
IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=FC20),UNIT=OSAD  

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

Re: LOAD and DELETE macro instructions

[John Gilmore]

Peter,

Your post contains good generic advice.

For my shared-table subsystem I use two address spaces in  order to
greatly simplify recovery problems (in a fashion that I imagine you
have experience with).

Absolute guarantees are almost by definition impossible, but I can in
practical terms guarantee that the second (recovery) AS will live as
long as I want it to live.

In my own experience LOADs with GLOBAL=YES  and EOM=YES have been
reliable and unproblematic.  (As I tried to make clear in a preceding
post this experience is with data and not with executables.)

-- 
John Gilmore, Ashland, MA 01721 - USA

t.

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Donald J.]

Correct.  Examples for nonQDIO are in this share document:
https://share.confex.com/share/117/webprogram/Session9295.html
-- 
  Donald J.
  dona...@4email.net


On Mon, Dec 3, 2012, at 07:02 AM, Rebecca Martin wrote:
> Donald, for LCS we have no VTAM definition only what is in the TCPIP
> profile.  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

-- 
http://www.fastmail.fm - A fast, anti-spam email service.

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

More SA SLIP traps

[Hamilton, Robert]

I'm having trouble with IPv6...er...something overwriting some storage in a 
gateway server, and I want to use an SA SLIP trap to catch it. I can observe 
the error has occurred with

DATA=(8R?+2C0,NE,,AND,8R?+2C0,NE,0013)

The trouble is, the storage overwritten is in a control block that is used to 
manage a connection through the gateway, and for most of my gateway instances 
there are 200-300 possible connections, so I have 200-300 possible places where 
this might occur. The location that is being overwritten is consistent within 
the data structure, but the location is specific to the subtask and it's in 
dynamically-obtained storage. So, when I say

RANGE=(8R?+2C0,+2C7)

the SLIP...is invalid, because it can't find the starting location. Do I 
really, really need a few hundred dynamic SLIPs to trap this problem?

On the other hand, if I wait until the storage is allocated and issue just a 
single slip with this RANGE parameter, will each subtask be monitored, or just 
the main task? AND, if I then use

TRDATA=(STD,REGS,8R?,8R?+33F)

to dump the entire control block when the slip is triggered, will it just dump 
the one that was overwritten, or will it try to dump the information for each 
task?

Am I asking for too much to hope that SLIP can watch all these tasks for one 
job?

Right now I'm not even performing the data check; the (failing) SLIP currently 
looks like this:

SLIP SET,SA,ACTION=TRDUMP,
 TRDATA=(STD,REGS,8R?,8R?+33F),
 ASIDSA='gatewayjob',
 PVTMOD=(gatewaypgm,0,4697),
 RANGE=(8R?+2C0,8R?+2C7),
 SDATA=(ALLNUC,ALLPSA,LPA,LSQA,SQA,CSA,RGN,TRT,SUM),
 DEBUG,OK,
 ID=IPV6,
 END

(I mentioned IPv6 earlier because...when I restrict my application to using 
IPv4 sockets I don't seem to have this error. When I enable IPv6 sockets in the 
application, a sockaddr structure is being overwritten by  and a clientinfo structure is destroyed in the process.)

Thanks in advance.
R;


Rob Hamilton
Sr. System Engineer
Chemical Abstracts Service

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.


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

Re: LOAD and DELETE macro instructions

[Elardus Engelbrecht]

John Gilmore wrote:

>In my own experience LOADs with GLOBAL=YES  and EOM=YES have been reliable and 
>unproblematic. 

Agreed. 

I have successfully used LOAD EP= and DELETE macros without any 
problems in ancient times (before or after Julius Ceaser, hmmm? ;-D ) when SMF 
exits were not that being dynamic as today. I have used it in UJI exit where I 
loaded accounting codes via above macros, thus avoiding IPLs when a new 
accounting code is created. I only needed a fast 'F LLA,REFRESH' after 
rebuilding that module containing a list of accounting codes.

These days I just do a RACROUTE Call when SMF UJI exit needs to checkup an 
accounting code in batch jobs. It is more dynamic for my needs. ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: RMF Spreadsheet Reporter

[Ron Wells]

something strange going on...
trying to select from my monthly rmf..whole month...only getting 4days ??
not seeing anything in doc I need to cleanup anything..delete..
I have called all my datasets/local and remote diff. names just 
incase...same results...

went back against my weekly rmf..same results there too...

?



From:   Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/28/2012 08:36 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



I have not followed this thread as well as I should, so I apologize if 
this
information has been covered

Have the Share Presentations on RMF Spreadsheet Reporter been of any
assistance?

For example

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/c6192fb3a432612485256d97

0082de57/fbfd446e23654daf862576f60075f401/%24FILE/RMF%20Overview%20Records%2
0and%20Use%20with%20the%20RMF%20Spreadsheet%20Reporter.pdf

or Tiny URL  http://tinyurl.com/chbd3zj

Or this link:

https://share.confex.com/share/115/webprogram/Handout/Session7763/Latest&Gre

atest.pdf

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Ron Wells
> Sent: Sunday, November 25, 2012 11:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RMF Spreadsheet Reporter
> 
> tks for reply...sent ya another---questions ... workload/seervice
reporting...who
> too's..and altering duration of reporting ..red book sort of helpful but
missing setup or
> something to change either..
> 
> 
> 

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)

[Elardus Engelbrecht]

Shmuel Metz wrote:

>> I figured IBM looked at the sev 1s and said "oh, it's them again" and just 
>> treated it like a sev 2.  :-)  (boy who cried wolf syndrome)

>That's why I prefer to open incidents as Sev 3[1]; when I open one at Sev 1 or 
>Sev 2, I don't have a rack record of severity inflation to ruin my credibility.

Agreed.

It is the same with children/drunk students playing the games of faking 
drowing. These children do drown when lifeguards ignoring their [real] cries 
for help because of previous and unneeded attempts to help...

So, just don't fake something as Sev 1, and you will not get a 'history' by 
'big blue lifeguards'.

Groete / Greetings
Elardus Engelbrecht

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

Re: LOAD and DELETE macro instructions

[Binyamin Dissen]

I find directed load much safer. And guaranteed not to go away until it is
explicitly removed.

I rarely find the need for a recovery A/S - an address space RESMGR is
guaranteed to get control.

On Mon, 3 Dec 2012 11:02:06 -0500 John Gilmore  wrote:

:>Peter,
:>
:>Your post contains good generic advice.
:>
:>For my shared-table subsystem I use two address spaces in  order to
:>greatly simplify recovery problems (in a fashion that I imagine you
:>have experience with).
:>
:>Absolute guarantees are almost by definition impossible, but I can in
:>practical terms guarantee that the second (recovery) AS will live as
:>long as I want it to live.
:>
:>In my own experience LOADs with GLOBAL=YES  and EOM=YES have been
:>reliable and unproblematic.  (As I tried to make clear in a preceding
:>post this experience is with data and not with executables.)

--
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: More SA SLIP traps

[Binyamin Dissen]

If your code is reentrant and the same code is being used in each thread the
PVTMOD keyword should limit the amount of code monitored.

On Mon, 3 Dec 2012 16:34:21 + "Hamilton, Robert" 
wrote:

:>I'm having trouble with IPv6...er...something overwriting some storage in a 
gateway server, and I want to use an SA SLIP trap to catch it. I can observe 
the error has occurred with
:>
:>DATA=(8R?+2C0,NE,,AND,8R?+2C0,NE,0013)
:>
:>The trouble is, the storage overwritten is in a control block that is used to 
manage a connection through the gateway, and for most of my gateway instances 
there are 200-300 possible connections, so I have 200-300 possible places where 
this might occur. The location that is being overwritten is consistent within 
the data structure, but the location is specific to the subtask and it's in 
dynamically-obtained storage. So, when I say
:>
:>RANGE=(8R?+2C0,+2C7)
:>
:>the SLIP...is invalid, because it can't find the starting location. Do I 
really, really need a few hundred dynamic SLIPs to trap this problem?
:>
:>On the other hand, if I wait until the storage is allocated and issue just a 
single slip with this RANGE parameter, will each subtask be monitored, or just 
the main task? AND, if I then use
:>
:>TRDATA=(STD,REGS,8R?,8R?+33F)
:>
:>to dump the entire control block when the slip is triggered, will it just 
dump the one that was overwritten, or will it try to dump the information for 
each task?
:>
:>Am I asking for too much to hope that SLIP can watch all these tasks for one 
job?
:>
:>Right now I'm not even performing the data check; the (failing) SLIP 
currently looks like this:
:>
:>SLIP SET,SA,ACTION=TRDUMP,
:> TRDATA=(STD,REGS,8R?,8R?+33F),
:> ASIDSA='gatewayjob',
:> PVTMOD=(gatewaypgm,0,4697),
:> RANGE=(8R?+2C0,8R?+2C7),
:> SDATA=(ALLNUC,ALLPSA,LPA,LSQA,SQA,CSA,RGN,TRT,SUM),
:> DEBUG,OK,
:> ID=IPV6,
:> END
:>
:>(I mentioned IPv6 earlier because...when I restrict my application to using 
IPv4 sockets I don't seem to have this error. When I enable IPv6 sockets in the 
application, a sockaddr structure is being overwritten by  and a clientinfo structure is destroyed in the process.)
:>
:>Thanks in advance.
:>R;
:>
:>
:>Rob Hamilton
:>Sr. System Engineer
:>Chemical Abstracts Service
:>
:>Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.
:>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: More SA SLIP traps

[Andy Wood]

On Mon, 3 Dec 2012 16:34:21 +, Hamilton, Robert  wrote:

>I'm having trouble with IPv6...er...something overwriting some storage in a 
>gateway server, and I want to use an SA SLIP trap to catch it. I can observe 
>the error has occurred with
>
>DATA=(8R?+2C0,NE,,AND,8R?+2C0,NE,0013)
>
>The trouble is, the storage overwritten is in a control block that is used to 
>manage a connection through the gateway, and for most of my gateway instances 
>there are 200-300 possible connections, so I have 200-300 possible places 
>where this might occur. The location that is being overwritten is consistent 
>within the data structure, but the location is specific to the subtask and 
>it's in dynamically-obtained storage. So, when I say
>
>RANGE=(8R?+2C0,+2C7)
>
>the SLIP...is invalid, because it can't find the starting location. Do I 
>really, really need a few hundred dynamic SLIPs to trap this problem?
>
>On the other hand, if I wait until the storage is allocated and issue just a 
>single slip with this RANGE parameter, will each subtask be monitored, or just 
>the main task? AND, if I then use
>
>TRDATA=(STD,REGS,8R?,8R?+33F)
>
>to dump the entire control block when the slip is triggered, will it just dump 
>the one that was overwritten, or will it try to dump the information for each 
>task?
>
. . .

As I see it, you have two problems.

Firstly, you don't know the address of the control block to be monitored by SA 
SLIP in advance. Dynamic PER allows you to solve that issue if you can identify 
a point in the code where the storage has been allocated (get the ball rolling 
with an IF trap at that point).

Secondly, you have not one control block, but hundreds of them. The PER 
hardware only allows one range to be defined, which is why you can only have 
one non-IGNORE SA trap "eligible for checking" at any one time. To monitor 
multiple control blocks, the range would have to start at the lowest address of 
any of the blocks, and end at the last byte of the block with the highest 
address (and covering anything in between if the blocks are not contiguous). 
You might be able to filter out unwanted updates using DATA (could be a 
challenge with so many blocks) or maybe with other traps using IGNORE or 
SUBTRAP, but still the overhead could be high.

Unless you know for sure that the control block is being hit a program which is 
addressing the control block using reg 8, the TRDATA you specified may not 
trace what you want. If the damage really is being done by "gatewaypgm", and it 
always does have a particular register pointing to the block, you could perhaps 
consider an IF trap over the whole module, with DATA used to identify when the 
block gets damaged, but since that would cause a PER interrupt for every 
instruction in the module, the overhead could also be high.

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

Re: More SA SLIP traps

[Hamilton, Robert]

>As I see it, you have two problems.
>
>Firstly, you don't know the address of the control block to be monitored by SA
>SLIP in advance. Dynamic PER allows you to solve that issue if you can
>identify a point in the code where the storage has been allocated (get the ball
>rolling with an IF trap at that point).
>
>Secondly, you have not one control block, but hundreds of them. The PER
>hardware only allows one range to be defined, which is why you can only
>have one non-IGNORE SA trap "eligible for checking" at any one time. To
>monitor multiple control blocks, the range would have to start at the lowest
>address of any of the blocks, and end at the last byte of the block with the
>highest address (and covering anything in between if the blocks are not
>contiguous). You might be able to filter out unwanted updates using DATA
>(could be a challenge with so many blocks) or maybe with other traps using
>IGNORE or SUBTRAP, but still the overhead could be high.
>
>Unless you know for sure that the control block is being hit a program which
>is addressing the control block using reg 8, the TRDATA you specified may
>not trace what you want. If the damage really is being done by
>"gatewaypgm", and it always does have a particular register pointing to the
>block, you could perhaps consider an IF trap over the whole module, with
>DATA used to identify when the block gets damaged, but since that would
>cause a PER interrupt for every instruction in the module, the overhead
>could also be high.

This is pretty much the problem. The good news is that the control blocks are 
obtained as an array at gateway startup. The bad news is, each block is used to 
store 48 counters, a handful of status bytes and a handful of ECBs and...other 
indentifying data. The block that defines a session is x'340' long, and I have 
202 in my test gateway. I can watch the whole array, and I know the point in 
the code where it is obtained and initialized. (Having trouble figuring out how 
to specify the RANGE to indicate that location).

The storage that is corrupted is initialized at subtask startup and shouldn't 
change ever, barring individual subtask failure and restart. Nearly every 
subtask determines R8 at initialization time and it never changes; that's why I 
think my TRDATA should be ok. The main task shuffles among the control blocks, 
but always sets R8 to point to the one he wants, so it should be ok there too. 
Is the TRDATA start address determined at the point when the SLIP is triggered?

I'm more and more certain that the failure happens in the primary task at the 
time when IP signals an incoming connection, so the next time I can test it I'm 
going just to watch that task, as much as possible.

Confidentiality Notice: This electronic message transmission, including any 
attachment(s), may contain confidential, proprietary, or privileged information 
from Chemical Abstracts Service ("CAS"), a division of the American Chemical 
Society ("ACS"). If you have received this transmission in error, be advised 
that any disclosure, copying, distribution, or use of the contents of this 
information is strictly prohibited. Please destroy all copies of the message 
and contact the sender immediately by either replying to this message or 
calling 614-447-3600.



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

Re: RMF Spreadsheet Reporter

[Steve Conway]

Hi, Ron.

Which days are you getting?  I mean, it IS the 3rd of December.  :-)

I would verify which dates I was specifying, and what dates the data are 
on the input files.


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Ron Wells 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/03/2012 11:59 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



something strange going on...
trying to select from my monthly rmf..whole month...only getting 4days ??
not seeing anything in doc I need to cleanup anything..delete..
I have called all my datasets/local and remote diff. names just 
incase...same results...

went back against my weekly rmf..same results there too...

?



From:   Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/28/2012 08:36 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



I have not followed this thread as well as I should, so I apologize if 
this
information has been covered

Have the Share Presentations on RMF Spreadsheet Reporter been of any
assistance?

For example

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/c6192fb3a432612485256d97


0082de57/fbfd446e23654daf862576f60075f401/%24FILE/RMF%20Overview%20Records%2
0and%20Use%20with%20the%20RMF%20Spreadsheet%20Reporter.pdf

or Tiny URL  http://tinyurl.com/chbd3zj

Or this link:

https://share.confex.com/share/115/webprogram/Handout/Session7763/Latest&Gre


atest.pdf

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Ron Wells
> Sent: Sunday, November 25, 2012 11:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RMF Spreadsheet Reporter
> 
> tks for reply...sent ya another---questions ... workload/seervice
reporting...who
> too's..and altering duration of reporting ..red book sort of helpful but
missing setup or
> something to change either..
> 
> 
> 

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the 
sender, which  may be legally privileged information.  This information is 
intended only  for  the use of the individual or entity addressed above. 
If you are not  the  intended  recipient, or  an  employee  or  agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure,  copying, distribution, or the taking of any 
action in reliance on the contents of the E-mail or attached files is 
strictly prohibited.

--
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: Announcing z/OS port of PCRE 8.31 - version 0.1 beta

[Barkow, Eileen]

File zos.lked.txt is missing from the downloaded zip file (pcre.zip).


12/03/2012  10:17 AM  .
12/03/2012  10:17 AM  ..
11/13/2012  12:49 AM   923 ADDJCL.JCL
11/13/2012  12:37 AM 5,745 addmem.rex
12/03/2012  10:17 AM 2,836 inst.txt
11/13/2012  12:48 AM 2,687 LICENCE.txt
12/03/2012  09:40 AM   506,738 pcre.zip
11/17/2012  11:38 PM26,074 pcre_native_zOS_port.V0.1ba.txt
11/14/2012  11:11 PM68,641 zos.cob.txt
11/17/2012  11:28 PM21,194 zos.jcl.txt
11/11/2012  11:02 PM 1,826,082 zos.load.txt
11/13/2012  12:33 AM   666,377 zos.test.txt
  10 File(s)  3,127,297 bytes
   2 Dir(s)  170,170,175,488 bytes free

H:\pcre>
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Sunday, December 02, 2012 11:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Announcing z/OS port of PCRE 8.31 - version 0.1 beta

>From a posting on the forum of "that" system:


I've ported the PCRE (Perl Compatible Regular Expressions) to native z/OS (no 
USS [Unix Servicses], just good ol' native z/OS), including COBOL API. The 
installation file is available on:
http://www.zaconsultants.net on the downloads page.

The concept of Regular Expressions is new for most COBOL and PL/I programmers 
on the z/OS platform, but is old news for Unix and Linux programmers. Regular 
Expressions is a technology that allows finding patterns in text strings in 
ways that are not currently available in COBOL, PL/I or even Rexx.

The power of regular expressions is widely used by Java, VB.net, C#, PHP and 
Perl, to mention some of the most popular languages. The package that I've 
ported is the same one that is used by PHP and is highly compatible with Perl 
which is the standard setter for that stuff. In other words, I brought the most 
advanced form of Regular Expressions into the COBOL, PL/I and z/OS world.

I hope that the availability of PCRE would encourage all z/OS COBOL and PL/I 
programmers to learn about regular expressions and utilize this port. The 
license is BSD which pretty much allows use and even resell software based on 
it with very few real limitations.

We are working to introduce PCRE to PL/I for MVS, z/VM and Rexx, but COBOL and 
PL/I enterprise seem to be working fins

The files should also be available on CBTTTAPE.ORG and some other mirror site.
ZA

Robert
--
Robert AH Prins
robert.ah.pr...@gmail.com

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

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

Re: LOAD and DELETE macro instructions

[John Gilmore]

What I did not mention in my reply to Peter Relson--He knows it--is
that, while awareness is not automatic, it very easy to make any AS
aware that something is in the CSA and to enable that AS to access it.

I do, however, want to make it clear that my post was not part of a
marketing campaign for GLOBAL=yes.  Other techniques are certainly
appropriate in many circumstances, perhaps even in most; and those who
prefer them should use them.

John Gilmore, Ashland, MA 01721 - USA

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Rebecca Martin]

The changes did not work.  We have a copy of that Share document and have 
actually read it several times :(  

Here is the new definitions from IOCP:
CHPID PATH=(CSS(0),00),SHARED,*
   PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=200,TYPE=OSE  
CHPID PATH=(CSS(0),04),SHARED,*
   PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=210,TYPE=OSE 
 CHPID PATH=(CSS(0),05),SHARED, 
CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
 IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA
 IODEVICE ADDRESS=(FCFE,001),CUNUMBR=(FC00),UNIT=OSAD   
 CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA  
 IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA 
 IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA 
 IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=(FC20),UNIT=OSAD

After dynamic activate and IPL, FC10 and FC40 paths are still not operational.  
Do you see what we missed?  

Here are some displays:
D M=CHP(04) 
IEE174I 13.23.06 DISPLAY M 113  
CHPID 04:  TYPE=10, DESC=OSA EXPRESS, ONLINE
DEVICE STATUS FOR CHANNEL PATH 04   
 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F 
0FC2 +  +  $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@
0FC4 $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@ $@
0FCF .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  + 
SWITCH DEVICE NUMBER = NONE 
PHYSICAL CHANNEL ID = 0210   
 SYMBOL EXPLANATIONS  
 + ONLINE@ PATH NOT VALIDATED   - OFFLINE. DOES NOT EXIST  
 * PHYSICALLY ONLINE   $ PATH NOT OPERATIONAL  

-D M=DEV(FC40)   
 IEE174I 13.23.57 DISPLAY M 119  
 DEVICE 0FC40   STATUS=OFFLINE   
 CHP   04
 ENTRY LINK ADDRESS..
 DEST LINK ADDRESS 0D
 PATH ONLINE   Y 
 CHP PHYSICALLY ONLINE Y 
 PATH OPERATIONAL  N 
 PATHS NOT VALIDATED 
 
V PATH(FC40,04),ONLINE
IEE386I PATH(FC40,04) NOT BROUGHT ONLINE  
IEE763I NAME= IECVIOPM CODE= 0004 
IOS552I PATH NOT PHYSICALLY AVAILABLE 
IEE764I END OF IEE386IRELATED MESSAGES

D M=DEV(FCFE)
IEE174I 13.36.12 DISPLAY M 156   
DEVICE 0FCFE   STATUS=ONLINE 
CHP   00 
ENTRY LINK ADDRESS.. 
DEST LINK ADDRESS 0D 
PATH ONLINE   Y  
CHP PHYSICALLY ONLINE Y  
PATH OPERATIONAL  Y  
MANAGED   N  
CU NUMBER FC00   
MAXIMUM MANAGED CHPID(S) ALLOWED:  0 
DESTINATION CU LOGICAL ADDRESS = 00  

 
D M=DEV(FCFF) 
IEE174I 13.36.30 DISPLAY M 158
DEVICE 0FCFF   STATUS=ONLINE  
CHP   04  
ENTRY LINK ADDRESS..  
DEST LINK ADDRESS 0D  
PATH ONLINE   Y   
CHP PHYSICALLY ONLINE Y   
PATH OPERATIONAL  Y   
MANAGED   N   
CU NUMBER FC20
MAXIMUM MANAGED CHPID(S) ALLOWED:  0  
DESTINATION CU LOGICAL ADDRESS = 00   


Thanks
Rebecca

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Ed Finnell]

Guess I'd ask the CE to do wrap test on second port. Back when I was doing  
this SG24-5948 OSA-Express Implementation Guide was a really good  
reference.
 
 
In a message dated 12/3/2012 2:12:23 P.M. Central Standard Time,  
rebecca.mar...@tgslc.org writes:

After  dynamic activate and IPL, FC10 and FC40 paths are still not 
operational.   Do you see what we missed?   



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

Re: Changing PMR Severity (Was: Makes me love most of my z/OS software vendors)

[Jerry Whitteridge]

I've never been comfortable with changing severity levels for a problem. It's 
either a Sev1 - critical function not available - or it's not.  The impact to 
the business doesn't change just because of convenience. I've had managers try 
to play the raise and lower game and frequently had closed door discussions on 
the honesty of that. Additionally explained the Support organizations all know 
who plays those games and they react appropriately.  I like to feel that when I 
call in a Sev1 they know it IS a Sev1. 

Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184

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




"Email Firewall" made the following annotations.
--

Warning: 
All e-mail sent to this address will be received by the corporate e-mail 
system, and is subject to archival and review by someone other than the 
recipient.  This e-mail may contain proprietary information and is intended 
only for the use of the intended recipient(s).  If the reader of this message 
is not the intended recipient(s), you are notified that you have received this 
message in error and that any review, dissemination, distribution or copying of 
this message is strictly prohibited.  If you have received this message in 
error, please notify the sender immediately.   
 
==

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Rebecca Martin]

Thank you, Ed.  I'll ask the CE about that test.  We also have been reading the 
implementation guide.  The guide and the Share presentation give you a lot of 
information and examples for QDIO but not so much for non-QDIO, type OSE.

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

SYNCSORT

[Anthony Fletcher]

Any SYNCSORT users out there? We have one job that gets an S0C4-10. The problem 
can be reproduced with a three line set of data, so its not a capacity problem. 
There are two sort fields. If the second one's displacement is reduced the 
problem goes away but it otherwise looks like an addressing problem. The sort 
length plus displacement is nowhere near as long as the LRECL of the data set.
The abend does not appear to be in any SYNCSORT module.
It is version 1.3.0 running on z/OS 1.13. 
Waiting for vendor agent to get back.
Anyone experienced anything like this?

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

Re: SYNCSORT

[Gibney, Dave]

AS is often the case, without the sort statements, file attributes and actual 
error messages, I doubt any of us are psychic enough to give a meaningful 
answer.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Fletcher
> Sent: Monday, December 03, 2012 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYNCSORT
> 
> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
> problem can be reproduced with a three line set of data, so its not a capacity
> problem. There are two sort fields. If the second one's displacement is
> reduced the problem goes away but it otherwise looks like an addressing
> problem. The sort length plus displacement is nowhere near as long as the
> LRECL of the data set.
> The abend does not appear to be in any SYNCSORT module.
> It is version 1.3.0 running on z/OS 1.13.
> Waiting for vendor agent to get back.
> Anyone experienced anything like this?
> 
> --
> 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: CHPID TYPE OSE Port 1 of OSA Express3

[Meehan, Cheryl]

Ed-

Just a quick question- - - Have you queried the OSA using OSASF?  
If you have not, checking the Config for each LPAR in OSASF may give you some 
indication.

Cheryl

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Finnell
Sent: Monday, December 03, 2012 3:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CHPID TYPE OSE Port 1 of OSA Express3

Guess I'd ask the CE to do wrap test on second port. Back when I was doing this 
SG24-5948 OSA-Express Implementation Guide was a really good reference.
 
 
In a message dated 12/3/2012 2:12:23 P.M. Central Standard Time, 
rebecca.mar...@tgslc.org writes:

After  dynamic activate and IPL, FC10 and FC40 paths are still not 
operational.   Do you see what we missed?   



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

[Lizette Koehler]

I usually go through the EWS (PTFs) by Syncsort and if nothing is standing out, 
wait for the support staff.
I have found Syncsort support very good.

Lizette

>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Anthony Fletcher
>> 
>> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
>> problem can be reproduced with a three line set of data, so its not a 
>> capacity
>> problem. There are two sort fields. If the second one's displacement is
>> reduced the problem goes away but it otherwise looks like an addressing
>> problem. The sort length plus displacement is nowhere near as long as the
>> LRECL of the data set.
>> The abend does not appear to be in any SYNCSORT module.
>> It is version 1.3.0 running on z/OS 1.13.
>> Waiting for vendor agent to get back.
>> Anyone experienced anything like this?
>> 

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

Re: SYNCSORT

[McKown, John]

Sheer guess on my part. Take it for what it's worth. We don't use SYNCSORT. But 
I've seen some weird SOC4-10 abends in the past.

Is the input file variable length records? Does SYNCSORT have something 
equivalent to the VLSHRT parameter? Anyway, what could be happening is that one 
or more of the records is "too short" for your control fields. Sometime during 
the sort, one of these "too short" records ends up being placed so that the 
last byte of the record is on the last byte of a 4K page, and the subsequent 
virtual page is invalid. Since the SORT control field is too long, the SORT 
program does a compare which causes the comparand field in the record to extend 
into the invalid address range. Which causes an S0C4-10 abend. If SYNCSORT is 
like DFSORT, it "compiles" the SORT control fields into instructions in an 
STORAGE OBTAIN'd area, and so they are not part of any executable module. So 
the abend formatter ends up saying the abend occurred in an unknown module. 
DFSORT avoids this problem with VLSHRT by padding any records which are "too 
short" with 0x00 bytes at the end so that they will not compare high (might be 
low or equal).

-- 
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets® is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance 
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA 
Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Fletcher
> Sent: Monday, December 03, 2012 2:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYNCSORT
> 
> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
> problem can be reproduced with a three line set of data, so its not a
> capacity problem. There are two sort fields. If the second one's
> displacement is reduced the problem goes away but it otherwise looks
> like an addressing problem. The sort length plus displacement is
> nowhere near as long as the LRECL of the data set.
> The abend does not appear to be in any SYNCSORT module.
> It is version 1.3.0 running on z/OS 1.13.
> Waiting for vendor agent to get back.
> Anyone experienced anything like this?
> 
> --
> 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: SYNCSORT

[Anthony Fletcher]

John

Thanks for those comments. We mostly use DFSORT on other accounts and my
immediate take on the problem (while waiting fro proper analysis) was that
it was like the Memory Object sort problems that occurred for a while with
DFSORT but I had forgotten the VLSHRT fix. Will look at whether that could
be happening here.


regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   "McKown, John" 
To: IBM-MAIN@listserv.ua.edu,
Date:   04/12/2012 10:04
Subject:Re: SYNCSORT
Sent by:IBM Mainframe Discussion List 



Sheer guess on my part. Take it for what it's worth. We don't use SYNCSORT.
But I've seen some weird SOC4-10 abends in the past.

Is the input file variable length records? Does SYNCSORT have something
equivalent to the VLSHRT parameter? Anyway, what could be happening is that
one or more of the records is "too short" for your control fields. Sometime
during the sort, one of these "too short" records ends up being placed so
that the last byte of the record is on the last byte of a 4K page, and the
subsequent virtual page is invalid. Since the SORT control field is too
long, the SORT program does a compare which causes the comparand field in
the record to extend into the invalid address range. Which causes an
S0C4-10 abend. If SYNCSORT is like DFSORT, it "compiles" the SORT control
fields into instructions in an STORAGE OBTAIN'd area, and so they are not
part of any executable module. So the abend formatter ends up saying the
abend occurred in an unknown module. DFSORT avoids this problem with VLSHRT
by padding any records which are "too short" with 0x00 bytes at the end so
that they will not compare high (might be low or equal).

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets®

9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. HealthMarkets® is the brand name for products underwritten and
issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake
Life Insurance Company®, Mid-West National Life Insurance Company of
TennesseeSM and The MEGA Life and Health Insurance Company.SM


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Fletcher
> Sent: Monday, December 03, 2012 2:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYNCSORT
>
> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
> problem can be reproduced with a three line set of data, so its not a
> capacity problem. There are two sort fields. If the second one's
> displacement is reduced the problem goes away but it otherwise looks
> like an addressing problem. The sort length plus displacement is
> nowhere near as long as the LRECL of the data set.
> The abend does not appear to be in any SYNCSORT module.
> It is version 1.3.0 running on z/OS 1.13.
> Waiting for vendor agent to get back.
> Anyone experienced anything like this?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

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

Re: SYNCSORT

[Anthony Fletcher]

Lizette

Do you have access to the SYNCSORT WEB site? We haven't managed to get that
and have to go through an agent. Very frustrating.

regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   Lizette Koehler 
To: IBM-MAIN@listserv.ua.edu,
Date:   04/12/2012 10:02
Subject:Re: SYNCSORT
Sent by:IBM Mainframe Discussion List 



I usually go through the EWS (PTFs) by Syncsort and if nothing is standing
out, wait for the support staff.
I have found Syncsort support very good.

Lizette

>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Anthony Fletcher
>>
>> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
>> problem can be reproduced with a three line set of data, so its not a
capacity
>> problem. There are two sort fields. If the second one's displacement is
>> reduced the problem goes away but it otherwise looks like an addressing
>> problem. The sort length plus displacement is nowhere near as long as
the
>> LRECL of the data set.
>> The abend does not appear to be in any SYNCSORT module.
>> It is version 1.3.0 running on z/OS 1.13.
>> Waiting for vendor agent to get back.
>> Anyone experienced anything like this?
>>

--
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: RMF Spreadsheet Reporter

[Ron Wells]

Steve

1,2,3,4th ??  <> did each week smf tape separately..
report listing showed follwing..
 
(wk(0) has 11/24-30 
wk(-1) has 11/17-24 
wk(-2) has 11/10-17 
wk(-3) has 11/3-4 
wk(-4) has 11/3-4?? 
wk(-5) has  no Nov data>> according to rmfpp...

ran test with -5 -4 -2 -1 and (0) as inputbatch >> it ran ok and seems 
all data there...at least date wise..per the report listing


putting sort smf in place...not sure what it does...hoping will put in 
seq. and elim. any bad recs..
using the orig. month files that gave me problems...

let ya know what gives..









From:   Steve Conway 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/03/2012 01:13 PM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



Hi, Ron.

Which days are you getting?  I mean, it IS the 3rd of December.  :-)

I would verify which dates I was specifying, and what dates the data are 
on the input files.


Cheers,,,Steve

Steven F. Conway, CISSP
LA Systems
z/OS Systems Support
Phone: 703.295.1926
steve_con...@ao.uscourts.gov



From:   Ron Wells 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   12/03/2012 11:59 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



something strange going on...
trying to select from my monthly rmf..whole month...only getting 4days ??
not seeing anything in doc I need to cleanup anything..delete..
I have called all my datasets/local and remote diff. names just 
incase...same results...

went back against my weekly rmf..same results there too...

?



From:   Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/28/2012 08:36 AM
Subject:Re: RMF Spreadsheet Reporter
Sent by:IBM Mainframe Discussion List 



I have not followed this thread as well as I should, so I apologize if 
this
information has been covered

Have the Share Presentations on RMF Spreadsheet Reporter been of any
assistance?

For example

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/c6192fb3a432612485256d97



0082de57/fbfd446e23654daf862576f60075f401/%24FILE/RMF%20Overview%20Records%2
0and%20Use%20with%20the%20RMF%20Spreadsheet%20Reporter.pdf

or Tiny URL  http://tinyurl.com/chbd3zj

Or this link:

https://share.confex.com/share/115/webprogram/Handout/Session7763/Latest&Gre



atest.pdf

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf
> Of Ron Wells
> Sent: Sunday, November 25, 2012 11:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RMF Spreadsheet Reporter
> 
> tks for reply...sent ya another---questions ... workload/seervice
reporting...who
> too's..and altering duration of reporting ..red book sort of helpful but
missing setup or
> something to change either..
> 
> 
> 

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the 
sender, which  may be legally privileged information.  This information is 

intended only  for  the use of the individual or entity addressed above. 
If you are not  the  intended  recipient, or  an  employee  or  agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure,  copying, distribution, or the taking of any 

action in reliance on the contents of the E-mail or attached files is 
strictly prohibited.

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

--
Email Disclaimer
This  E-mail  contains  confidential  information  belonging to the sender, 
which  may be legally privileged information.  This information is intended 
only  for  the use of the individual or entity addressed above.  If you are not 
 the  intended  recipient, or  an  employee  or  agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
disclosure,  copying, distribution, or the taking of any action in reliance on 
the contents of the E-mail or attached files is strictly prohibited.

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

Re: SYNCSORT

[Mark Zelden]

On Mon, 3 Dec 2012 14:47:17 -0600, Anthony Fletcher  wrote:

>Any SYNCSORT users out there? We have one job that gets an S0C4-10. The 
>problem can be reproduced with a three line set of data, so its not a capacity 
>problem. There are two sort fields. If the second one's displacement is 
>reduced the problem goes away but it otherwise looks like an addressing 
>problem. The sort length plus displacement is nowhere near as long as the 
>LRECL of the data set.
>The abend does not appear to be in any SYNCSORT module.
>It is version 1.3.0 running on z/OS 1.13. 
>Waiting for vendor agent to get back.
>Anyone experienced anything like this?
>

Did you recently upgrade to z/OS 1.13?  Did you check with the vendor 
prior to your z/OS 1.13 upgrade to see what was supported and if any
fixes were needed?  I was already at 1.4 but I think 1.3 was supported
as long as you had all the fixes,  including some that are 
hardware related (z196). 

Even if this is a new problem, the vendor usually has a parm option
as a work around until they come up with a fix. 
 
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: SYNCSORT

[Mark Zelden]

On Mon, 3 Dec 2012 15:54:13 -0600, Mark Zelden  wrote:

>On Mon, 3 Dec 2012 14:47:17 -0600, Anthony Fletcher  
>wrote:
>
>>Any SYNCSORT users out there? We have one job that gets an S0C4-10. The 
>>problem can be reproduced with a three line set of data, so its not a 
>>capacity problem. There are two sort fields. If the second one's displacement 
>>is reduced the problem goes away but it otherwise looks like an addressing 
>>problem. The sort length plus displacement is nowhere near as long as the 
>>LRECL of the data set.
>>The abend does not appear to be in any SYNCSORT module.
>>It is version 1.3.0 running on z/OS 1.13. 
>>Waiting for vendor agent to get back.
>>Anyone experienced anything like this?
>>
>
>Did you recently upgrade to z/OS 1.13?  Did you check with the vendor 
>prior to your z/OS 1.13 upgrade to see what was supported and if any
>fixes were needed?  I was already at 1.4 but I think 1.3 was supported
>as long as you had all the fixes,  including some that are 
>hardware related (z196). 
>
>Even if this is a new problem, the vendor usually has a parm option
>as a work around until they come up with a fix. 
> 

You didn't say and I assumed this was a JCL invoked sort.  But are
there any E15/E35 exits in play here?   I ran into a similar problem in 1.13
where a COB2 exit (coded in COB2) was working prior to z/OS 1.13
using COB2 runtime instead of LE.   I forgot what problem they initially
had, but it wasn't an OC4. When I had them remove the COB2 runtime
and pick up LE from the LNKLST, then they got the 0C4.   The problem
was a bug in the E15 in the way they read a user parm input.  The code
was always bad (they didn't read the parm into working storage). I have
no idea how it ever worked.  

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: SYNCSORT

[Anthony Fletcher]

The point of the post was that this was something weird which someone might
have experienced.

Anyway, here is what we see:

Input:
//SORT EXEC  PGM=SORT
//SYSINDD  *
 SORT FIELDS=(61,100,CH,A,265,2000,CH,A)
 SUM FIELDS=NONE
 END
//*

Organization:  PS
Record format: FB
Record length: 2285
Block size:27420

Output:
09.04.03 JOB50717  +WER999A XSSYC801,SORT,-  UNSUCCESSFUL SORT
0C4 S
9.04.04 JOB50717  IEA995I SYMPTOM DUMP OUTPUT  036
  036 SYSTEM COMPLETION CODE=0C4  REASON CODE=0010
  036  TIME=09.04.03  SEQ=47706  CPU=  ASID=004D
  036  PSW AT TIME OF ERROR  078C   80E795C4  ILC 4  INTC
10
  036NO ACTIVE MODULE FOUND
  036NAME=UNKNOWN
  036DATA AT PSW  00E795BE - B20AF000  1BFF9180  202AA714
  036AR/GR 0: 00AFE040/   1: /2000CFBC
  036  2: /2000CFBC   3: /00E7A018
  036  4: /00ACF708   5: /00AFD830
  036  6: /00E794C0   7: /00FAA380
  036  8: /   9: /01755508
  036  A: /00AFD8F0   B: /2000CFBC
  036  C: /010DAEE0   D: /00026120
  036  E: /00FF0F00   F: 0102/
  036  END OF SYMPTOM DUMP


Changing the SORT to use these parms instead:
SORT FIELDS=(61,100,CH,A,265,1940,CH,A)
makes the problem go away.

regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   "Gibney, Dave" 
To: IBM-MAIN@listserv.ua.edu,
Date:   04/12/2012 09:49
Subject:Re: SYNCSORT
Sent by:IBM Mainframe Discussion List 



AS is often the case, without the sort statements, file attributes and
actual error messages, I doubt any of us are psychic enough to give a
meaningful answer.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Fletcher
> Sent: Monday, December 03, 2012 12:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SYNCSORT
>
> Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
> problem can be reproduced with a three line set of data, so its not a
capacity
> problem. There are two sort fields. If the second one's displacement is
> reduced the problem goes away but it otherwise looks like an addressing
> problem. The sort length plus displacement is nowhere near as long as the
> LRECL of the data set.
> The abend does not appear to be in any SYNCSORT module.
> It is version 1.3.0 running on z/OS 1.13.
> Waiting for vendor agent to get back.
> Anyone experienced anything like this?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: SYNCSORT

[Gibney, Dave]

What is your new default region in the 1.13 system?

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Anthony Fletcher
> Sent: Monday, December 03, 2012 2:12 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SYNCSORT
> 
> The point of the post was that this was something weird which someone might
> have experienced.
> 
> Anyway, here is what we see:
> 
> Input:
> //SORT EXEC  PGM=SORT
> //SYSINDD  *
>  SORT FIELDS=(61,100,CH,A,265,2000,CH,A)
>  SUM FIELDS=NONE
>  END
> //*
> 
> Organization:  PS
> Record format: FB
> Record length: 2285
> Block size:27420
> 
> Output:
> 09.04.03 JOB50717  +WER999A XSSYC801,SORT,-  UNSUCCESSFUL
> SORT
> 0C4 S
> 9.04.04 JOB50717  IEA995I SYMPTOM DUMP OUTPUT  036
>   036 SYSTEM COMPLETION CODE=0C4  REASON CODE=0010
>   036  TIME=09.04.03  SEQ=47706  CPU=  ASID=004D
>   036  PSW AT TIME OF ERROR  078C   80E795C4  ILC 4  INTC
> 10
>   036NO ACTIVE MODULE FOUND
>   036NAME=UNKNOWN
>   036DATA AT PSW  00E795BE - B20AF000  1BFF9180  202AA714
>   036AR/GR 0: 00AFE040/   1: /2000CFBC
>   036  2: /2000CFBC   3: /00E7A018
>   036  4: /00ACF708   5: /00AFD830
>   036  6: /00E794C0   7: /00FAA380
>   036  8: /   9: /01755508
>   036  A: /00AFD8F0   B: /2000CFBC
>   036  C: /010DAEE0   D: /00026120
>   036  E: /00FF0F00   F: 0102/
>   036  END OF SYMPTOM DUMP
> 
> 
> Changing the SORT to use these parms instead:
>   SORT FIELDS=(61,100,CH,A,265,1940,CH,A)
> makes the problem go away.
> 
> regards,
> Anthony Fletcher - NZ MIITP
> Team Lead NZ SMM
> (AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)
> 
> IBM Strategic Outsourcing Delivery
> Server Systems Operations
> Server Management Mainframe
> 
> Mainframe Software Program Manager  NZ
> z/OS Technical Lead A/NZ
> 
> Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
> mobile +64 21 464 864, Fax +64 4 576 5808.
> Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com
> 
>  "The biggest threat to effective communication is the belief that it has
> occurred"
>  "Winners make commitments, Losers make promises"
> 
> 
> 
> From: "Gibney, Dave" 
> To:   IBM-MAIN@listserv.ua.edu,
> Date: 04/12/2012 09:49
> Subject:  Re: SYNCSORT
> Sent by:  IBM Mainframe Discussion List 
> 
> 
> 
> AS is often the case, without the sort statements, file attributes and
> actual error messages, I doubt any of us are psychic enough to give a
> meaningful answer.
> 
> Dave Gibney
> Information Technology Services
> Washington State University
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-
> m...@listserv.ua.edu]
> > On Behalf Of Anthony Fletcher
> > Sent: Monday, December 03, 2012 12:47 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: SYNCSORT
> >
> > Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
> > problem can be reproduced with a three line set of data, so its not a
> capacity
> > problem. There are two sort fields. If the second one's displacement is
> > reduced the problem goes away but it otherwise looks like an addressing
> > problem. The sort length plus displacement is nowhere near as long as the
> > LRECL of the data set.
> > The abend does not appear to be in any SYNCSORT module.
> > It is version 1.3.0 running on z/OS 1.13.
> > Waiting for vendor agent to get back.
> > Anyone experienced anything like this?
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Address of SRB rtn

[Shmuel Metz (Seymour J.)]

In <1354502656.3436.11.ca...@mckown5.johnmckown.net>, on 12/02/2012
   at 08:44 PM, John McKown  said:

>I could have sworn that z/OS (MVS) had _something_ which did not 
>run in an address space.

DIE?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Address of SRB rtn

[Bill Fairchild]

The interrupt handlers for I/O and external interrupts are designed not to need 
to access any storage in whatever the current A/S might be at the time of the 
interrupt, if any.  Sometimes no address space is running and the system is in 
a wait state when such interrupts occur.

Bill Fairchild
Programmer
Rocket Software
408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA
t: +1.617.614.4503 *  e: bfairch...@rocketsoftware.com * w: 
www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Shmuel Metz (Seymour J.)
Sent: Monday, December 03, 2012 4:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Address of SRB rtn

In <1354502656.3436.11.ca...@mckown5.johnmckown.net>, on 12/02/2012
   at 08:44 PM, John McKown  said:

>I could have sworn that z/OS (MVS) had _something_ which did not run in 
>an address space.

DIE?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

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

Re: More SA SLIP traps

[Andy Wood]

On Mon, 3 Dec 2012 19:13:20 +, Hamilton, Robert  wrote:

. . .

>
>I can watch the whole array, and I know the point in the code where it is 
>obtained and initialized. (Having trouble figuring out how to specify the 
>RANGE to indicate that location).
>

The code that obtains and initializes the array must have the address of it 
somewhere. Set an IF slip somewhere there (probably best after it has been 
initialized), with ACTION=TARGETID, and TARGETID pointing to the SA slip. The 
SA SLIP can have a RANGE specified using a register, or a field pointed to by a 
register, and the register contents used to set the range will be the content 
at the point where the IF trap was triggered. I did not look now, but I am 
pretty sure there is an example of this sort of thing in the fine manual.

> . . . Nearly every subtask determines R8 at initialization time and it never 
> changes; that's why I think my TRDATA should be ok. The main task shuffles 
> among the control blocks, but always sets R8 to point to the one he wants, so 
> it should be ok there too. Is the TRDATA start address determined at the 
> point when the SLIP is triggered?

The data traced will be determined by the register contents at the time the SA 
PER interrupt occurs, in other words at the time the storage is altered. If the 
storage is altered by the code you expect, with reg 8 pointing to the block, 
then that is what you will get. If it is hit by something else, with some other 
address in reg 8, then too bad, you might get no storage traced, or get some 
other chunk of storage traced. If you use DATA on the SA trap, the registers 
used for that are also those at the point that the storage was altered.

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

Re: CHPID TYPE OSE Port 1 of OSA Express3

[Dale R. Smith]

On Mon, 3 Dec 2012 14:12:16 -0600, Rebecca Martin  
wrote:

>The changes did not work.  We have a copy of that Share document and have 
>actually read it several times :(  
>
>Here is the new definitions from IOCP:
>CHPID PATH=(CSS(0),00),SHARED,*
>   PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=200,TYPE=OSE  
>CHPID PATH=(CSS(0),04),SHARED,*
>   PARTITION=((MVSD,MVSM,MVSP,MVSZ),(=)),PCHID=210,TYPE=OSE
>  
> CHPID PATH=(CSS(0),05),SHARED, 
>CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA  
> IODEVICE ADDRESS=(FC00,032),CUNUMBR=(FC00),UNIT=OSA   
>  
> IODEVICE ADDRESS=(FCFE,001),CUNUMBR=(FC00),UNIT=OSAD  
>  
> CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA 
>  
> IODEVICE ADDRESS=(FC20,016),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA
>  
> IODEVICE ADDRESS=(FC40,016),UNITADD=10,CUNUMBR=(FC20),UNIT=OSA
>  
> IODEVICE ADDRESS=FCFF,UNITADD=FE,CUNUMBR=(FC20),UNIT=OSAD
>
>After dynamic activate and IPL, FC10 and FC40 paths are still not operational. 
> Do you see what we missed?  

I'm not 100% certain, but I believe the OSAD is the last device in the range of 
devices, (in this case 32), with a unit address of FE and the other devices 
have a unit address of 00.  So I think your definitions should look like this:

CNTLUNIT CUNUMBR=FC00,PATH=((CSS(0),00)),UNIT=OSA
IODEVICE ADDRESS=(FC00,031),UNITADD=00,CUNUMBR=(FC00),UNIT=OSA
IODEVICE ADDRESS=(FC1E,001),UNITADD=FE,CUNUMBR=(FC00),UNIT=OSAD 
  
CNTLUNIT CUNUMBR=FC20,PATH=((CSS(0),04)),UNIT=OSA
IODEVICE ADDRESS=(FC20,031),UNITADD=00,CUNUMBR=(FC20),UNIT=OSA
IODEVICE ADDRESS=(FC3F,001),UNITADD=FE,CUNUMBR=(FC20),UNIT=OSAD

The first 31 devices are OSA and the 32nd device in each range is an OSAD.

All wrongs reserved, no warranties expressed or implied, etc.  :-)>

-- 
Dale R. Smith

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

Re: SYNCSORT

[Anthony Fletcher]

Thanks to all for the helpful comments.

Turned out to be that a z/OS 1.13 compatibility fix was required and had
been missed - SY69690. Various symptoms from that only one of which was the
S0C4-10. SY69691 is the same problem for version 1.4, so needs to be on for
z/OS 1.13 and later.

regards,
Anthony Fletcher - NZ MIITP
Team Lead NZ SMM
(AirNZ, Westpac NZ , TelstraClear NZ and NWM AU)

IBM Strategic Outsourcing Delivery
Server Systems Operations
Server Management Mainframe

Mainframe Software Program Manager  NZ
z/OS Technical Lead A/NZ

Ph: Direct +64 4 576 8142, tieline 61 929 8142, ITN *869298142,
mobile +64 21 464 864, Fax +64 4 576 5808.
Internet: flet...@nz1.ibm.com, Sametime: flet...@nz1.ibm.com

 "The biggest threat to effective communication is the belief that it has
occurred"
 "Winners make commitments, Losers make promises"



From:   Anthony Fletcher/New Zealand/IBM@IBMNZ
To: IBM-MAIN@listserv.ua.edu,
Date:   04/12/2012 09:47
Subject:SYNCSORT
Sent by:IBM Mainframe Discussion List 



Any SYNCSORT users out there? We have one job that gets an S0C4-10. The
problem can be reproduced with a three line set of data, so its not a
capacity problem. There are two sort fields. If the second one's
displacement is reduced the problem goes away but it otherwise looks like
an addressing problem. The sort length plus displacement is nowhere near as
long as the LRECL of the data set.
The abend does not appear to be in any SYNCSORT module.
It is version 1.3.0 running on z/OS 1.13.
Waiting for vendor agent to get back.
Anyone experienced anything like this?

--
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: Address of SRB rtn

[Henry Willard]

John McKown wrote:

> I guess I had a major memory failure. I got into the books and you are
> correct. Even a global SRB is scheduled into an address space. It's just
> that global SRBs are dispatched before address spaces.
>
> I could have sworn that z/OS (MVS) had _something_ which did not run in
> an address space.
>
> And the books all seem to say that the program needs to be in globally
> addressable storage. Which seems strange to me if it an SRB runs in the
> context of an address space, why can't the code be in only that address
> space?
>
> I eagerly await being enlightened by the more knowledgeable of our
> members.

There are times when you need to run code an address space to do something
requiring PASN=HASN, but it is not convenient to load code in that address
space's private space.

Regards,
Henry

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

Re: RMF Spreadsheet Reporter

[Elardus Engelbrecht]

Ron Wells wrote:

> DATE(11012012,11302012)
> RTOD(,2400)
> ETOD(,2400)
> STOD(,2400)
> DINTV(0800)

Please post the dates, quantity and type of records read as collected. 

>putting sort smf in place...not sure what it does...hoping will put in seq. 
>and elim. any bad recs..

Please post the SORT job and results. RMF is absolutely very picky about the 
correct sequence of its input.

>using the orig. month files that gave me problems...

One or many LPARs? On what z/OS level are you?

Groete / Greetings
Elardus Engelbrecht

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