Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Thank you all for your contribution and time.
It sure gave me a lot to think of.

thanks,

Arye.

On Mon, Jun 12, 2017 at 6:44 PM, Phil Smith  wrote:

> There are several things intertwined here.
>
>
> *   CPACF is the "crypto on the chip" - z Systems instructions that do
> AES et al.
>
> *   CEX is the z HSM.
>
> *   ICSF is, of course, the z/OS service that talks to both (though
> you can do CPACF operations directly as well).
>
> With just CPACF, you're forced to use what's called Clear Key operation:
> keys are stored (somewhere, somehow-perhaps in CKDS), are fetched, and are
> passed to CPACF to do operations.
>
> With CEX in the mix, you add two more options: Secure Key and Protected
> Key.
>
> Secure Key means that keys are generated by the CEX, wrapped (encrypted)
> using keys known only to the CEX, and then passed to z/OS, which stores
> them (usually in CKDS). When an operation is performed, that wrapped key
> and the data are passed to the CEX, which unwraps the key, does the
> operation, and returns the result. Very secure, if relatively slow.
>
> Protected Key means that keys are generated by the CEX, wrapped, and
> stored in CKDS, like Secure Key. BUT when an operation is needed, an ICSF
> call takes that wrapped key and passes it to the CEX, where it is
> unwrapped, rewrapped using an ephemeral key generated just for the current
> IPL, and that key is returned. That ephemeral key is also passed to the
> firmware, so it's available to CPACF. Then the actual operation is
> performed by passing the rewrapped key: CPACF unwraps it using that
> ephemeral key, does the operation, returns the result. And ICSF remembers
> that it's done this, so the next operation using that key doesn't talk to
> the HSM at all. This gets you almost all of the performance and pretty well
> all of the security of Secure Key (arguably the firmware is slightly less
> secure than the tamper-resistant HSM, but the memory used in the firmware
> to hold that key is protected-it's apparently not even visible in HMC
> dumps).
>
> So your customer can switch to using Protected Key, at least in theory.
> How hard this is will depend on how keys are generated and managed now, as
> well as whether they're using ICSF or 'raw' CPACF now, as well as whether
> they're up for reprotecting all of their existing data with the new key.
>
> Does this help?
> --
> ...phsiii
>
> Phil Smith III
> Senior Architect & Product Manager, Mainframe & Enterprise
> Distinguished Technologist
> HPE Data Security
>
> phs...@hpe.com
> T 703-476-4511
> M 703-568-6662
> Hewlett Packard Enterprise
> Herndon, VA
>
>
> --
> 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: Estae and the Linkage Stack

[David Cole]

BAKRs do not create or cancel ESTAEs.

PRs do automagically cancel all ESTAEs created since the matching 
BAKR. There is a bit (in the BAKR's stack entry I think. I forget 
which and where.) that, when set on, causes an interrupt to occur 
when the PR is issued. This is how z/OS gains control so that it can 
do the purge of the appropriate SCB[s].


I remember how surprised I was to discover this some years ago when I 
was writing z/XDC's linkage stack support.


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware






At 6/12/2017 06:24 PM, Joseph Reichman wrote:

Hi

I thought for the longest time that an ESTAE was associated with a Task.
Then I saw a thread with Chris Blaicher where the upshot as that a BAKR
would deactivate it

I did a search on the archives but didn't come up with anything.


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

IBM customer anchor

[scott Ford]

All:

I have a question about something called
'customer anchor table entry' . My colleague said IBM can provide this
entry to a ISV like use so we can place an address there for routines.  I
think it's like a vector address .

Has anyone heard of this ?

-- 

 Regards,

*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: IBM customer anchor

[Tony Thigpen]

Recently came across this too. In CBT841 files:

"CONTACT PETER RELSON, rel...@us.ibm.com FOR YOUR OWN OFFSET IN THE
CUSTOMER ANCHOR TABLE. ONCE YOU HAVE RECEIVED YOUR ASSIGNED VALUE
MODIFY.."

Also, in the same CBT:

"A possible address off the Customer Anchor Table, X'CC' off the ECVT, 

 could be X'228' (assigned to a particular customer by IBM, but this 

 is an example address). 




 This is just an example.  For your site, you have to ask IBM to 

 assign this address for your site, and they are obligated to do so, 

 for a CUSTOMER.  Besides the fullwords that are assigned for VENDORS, 

 there are also four fullwords that are assignable to customers, if 

 they need a permanent address in the system to anchor some function. 




 At the time of this writing, Peter Relson of IBM is in charge of 

 assigning these addresses to either vendors or customers. 




 You are obligated to make sure that no program or product at your 


 site is already using this address.  "

Tony Thigpen

scott Ford wrote on 06/13/2017 08:35 AM:

All:

I have a question about something called
'customer anchor table entry' . My colleague said IBM can provide this
entry to a ISV like use so we can place an address there for routines.  I
think it's like a vector address .

Has anyone heard of this ?



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

Re: Estae and the Linkage Stack

[Joseph Reichman]

Will the ESTAE remain active if declared outside of the BAKR/PR pair 

David from you description it should



> On Jun 13, 2017, at 3:55 AM, David Cole  wrote:
> 
> BAKRs do not create or cancel ESTAEs.
> 
> PRs do automagically cancel all ESTAEs created since the matching BAKR. There 
> is a bit (in the BAKR's stack entry I think. I forget which and where.) that, 
> when set on, causes an interrupt to occur when the PR is issued. This is how 
> z/OS gains control so that it can do the purge of the appropriate SCB[s].
> 
> I remember how surprised I was to discover this some years ago when I was 
> writing z/XDC's linkage stack support.
> 
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS:dbc...@colesoft.com
> 
> Home page:   www.colesoft.com
> LinkedIn:www.xdc.com
> Facebook:www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
> 
> 
> 
> 
> 
> 
> At 6/12/2017 06:24 PM, Joseph Reichman wrote:
>> Hi
>> 
>> I thought for the longest time that an ESTAE was associated with a Task.
>> Then I saw a thread with Chris Blaicher where the upshot as that a BAKR
>> would deactivate it
>> 
>> I did a search on the archives but didn't come up with anything.
> 
> --
> 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: Estae and the Linkage Stack

[Blaicher, Christopher Y.]

Yes they will stay defined.  If you define an ESTAE at the beginning of a 
program, outside of a linkage stack entry, you can create and delete all the 
linkage stack entries you want and it will still be there.

You could create a linkage stack entry on entry to your program rather than 
chaining save areas, create an ESTAE, and have stack entries below it and the 
ESTAE will be there until you do your final PC back to the system, not that I 
would recommend doing that.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joseph Reichman
Sent: Tuesday, June 13, 2017 8:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Estae and the Linkage Stack

Will the ESTAE remain active if declared outside of the BAKR/PR pair

David from you description it should



> On Jun 13, 2017, at 3:55 AM, David Cole  wrote:
>
> BAKRs do not create or cancel ESTAEs.
>
> PRs do automagically cancel all ESTAEs created since the matching BAKR. There 
> is a bit (in the BAKR's stack entry I think. I forget which and where.) that, 
> when set on, causes an interrupt to occur when the PR is issued. This is how 
> z/OS gains control so that it can do the purge of the appropriate SCB[s].
>
> I remember how surprised I was to discover this some years ago when I was 
> writing z/XDC's linkage stack support.
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS:dbc...@colesoft.com
>
> Home page:   www.colesoft.com
> LinkedIn:www.xdc.com
> Facebook:www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
>
>
>
>
>
>
> At 6/12/2017 06:24 PM, Joseph Reichman wrote:
>> Hi
>>
>> I thought for the longest time that an ESTAE was associated with a Task.
>> Then I saw a thread with Chris Blaicher where the upshot as that a
>> BAKR would deactivate it
>>
>> I did a search on the archives but didn't come up with anything.
>
> --
> 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





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: Estae and the Linkage Stack

[Greg Dyck]

On 6/13/2017 2:55 AM, David Cole wrote:
PRs do automagically cancel all ESTAEs created since the matching BAKR. 
There is a bit (in the BAKR's stack entry I think. I forget which and 
where.) that, when set on, causes an interrupt to occur when the PR is 
issued. This is how z/OS gains control so that it can do the purge of 
the appropriate SCB[s].


You are referring to the unstack-suppression bit in the linkage stack 
entry descriptor.  It it used to trigger several different types of 
processing within z/OS when an entry is removed from the linkage stack, 
either explicity by a PR or implicitly by a RB being dequeued from a TCB 
after terminating (normally or abnormally).


Regards,
Greg

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

Re: Estae and the Linkage Stack

[Joseph Reichman]

So PC inst will also un-define an ESTAE



> On Jun 13, 2017, at 9:05 AM, Greg Dyck  wrote:
> 
>> On 6/13/2017 2:55 AM, David Cole wrote:
>> PRs do automagically cancel all ESTAEs created since the matching BAKR. 
>> There is a bit (in the BAKR's stack entry I think. I forget which and 
>> where.) that, when set on, causes an interrupt to occur when the PR is 
>> issued. This is how z/OS gains control so that it can do the purge of the 
>> appropriate SCB[s].
> 
> You are referring to the unstack-suppression bit in the linkage stack entry 
> descriptor.  It it used to trigger several different types of processing 
> within z/OS when an entry is removed from the linkage stack, either explicity 
> by a PR or implicitly by a RB being dequeued from a TCB after terminating 
> (normally or abnormally).
> 
> Regards,
> Greg
> 
> --
> 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: Sorting a REXX STEM variable

[Albert Ferguson]

Under zOS REXX does have a STEM Sort (via BPXWUNIX). If you have an OMVS 
Segment on your USERID (and as of zOS 2.1+ you should), try this:

/*
 Do a Binary Sort (use -tn for Text)
 Using 2nd Word in each StemIn. Record as primary sort key
 Using 1st Word in each StemIn. Record as secondary sort key
 More doc on Unix Sort at 
http://publibz.boulder.ibm.com/epubs/pdf/bpx1cd10.pdf
*/ 
x = BPXWUNIX("/bin/sort -bn -k2,2 -k1,1","StemIn.","StemOut.")

Also available via the USS side of zOS is Regex support:

/*
Get the JESMSGLG output from a JOB, e.g. via SDSF or (E)JES and put in the 
STEM JesMsgLg.
Use the USS grep in, Extended mode, to search for all STEPS with an RC=12, 
16, or 20
Return only those steps to the BadSteps. STEM variable ...

Add a step using this at the very END of a JOB to determine if something 
did not go as expected, and then
possibly correct it!
*/
x = BPXWUNIX("/bin/grep -E -e'¬.{30}(.{10}  (12|16|20)'", 
"JesMsgLg.","BadSteps.")

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

Re: IBM customer anchor

[Charles Mills]

Yep!

That's what we did.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Tuesday, June 13, 2017 5:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

Recently came across this too. In CBT841 files:

"CONTACT PETER RELSON, rel...@us.ibm.com FOR YOUR OWN OFFSET IN THE CUSTOMER 
ANCHOR TABLE. ONCE YOU HAVE RECEIVED YOUR ASSIGNED VALUE MODIFY.."

Also, in the same CBT:

"A possible address off the Customer Anchor Table, X'CC' off the ECVT, 

  could be X'228' (assigned to a particular customer by IBM, but this 

  is an example address). 

 

  This is just an example.  For your site, you have to ask IBM to 

  assign this address for your site, and they are obligated to do so, 

  for a CUSTOMER.  Besides the fullwords that are assigned for VENDORS, 

  there are also four fullwords that are assignable to customers, if 

  they need a permanent address in the system to anchor some function. 

 

  At the time of this writing, Peter Relson of IBM is in charge of 

  assigning these addresses to either vendors or customers. 

 

  You are obligated to make sure that no program or product at your 

  site is already using this address.  "

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

Re: Estae and the Linkage Stack

[David Cole]

At 6/13/2017 09:07 AM, Joseph Reichman wrote:

So PC inst will also un-define an ESTAE


No... Only the PR will "un-define" an ESTAE.

PC is more similar in functionality to a BAKR than to a PR.
Both PCs and BAKRs create stack entries.
Only the PR removes them.

When a PR removes a stack entry, all ESTAE[X] routines that are newer 
than the stack entry will also be removed.


All ESTAE[X] routines that are older than the stack entry will survive.


Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware

Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS:dbc...@colesoft.com

Home page:   www.colesoft.com
LinkedIn:www.xdc.com
Facebook:www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware  


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

Notify Type in Apar

[Gilson Cesar de Oliveira]

>
>Dear list:
Does anyone know the meaning of Notify Type= Hyper DEL in apar??

I have received a notification today but I could not find the meaning of thid 
Notify Type.

Thanks for any help.

Regards,

Gilson

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

Re: Sorting a REXX STEM variable

[Nims,Alva John (Al)]

BPXWUNIX is available to z/OS 1.13 too, so this should work under z/OS 1.13.  I 
am using BPXWUNIX to invoke USS dig command get info from the DNS server.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Albert Ferguson
Sent: Tuesday, June 13, 2017 9:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sorting a REXX STEM variable

Under zOS REXX does have a STEM Sort (via BPXWUNIX). If you have an OMVS 
Segment on your USERID (and as of zOS 2.1+ you should), try this:
z
/*
 Do a Binary Sort (use -tn for Text)
 Using 2nd Word in each StemIn. Record as primary sort key
 Using 1st Word in each StemIn. Record as secondary sort key
 More doc on Unix Sort at 
http://publibz.boulder.ibm.com/epubs/pdf/bpx1cd10.pdf
*/
x = BPXWUNIX("/bin/sort -bn -k2,2 -k1,1","StemIn.","StemOut.")

Also available via the USS side of zOS is Regex support:

/*
Get the JESMSGLG output from a JOB, e.g. via SDSF or (E)JES and put in the 
STEM JesMsgLg.
Use the USS grep in, Extended mode, to search for all STEPS with an RC=12, 
16, or 20
Return only those steps to the BadSteps. STEM variable ...

Add a step using this at the very END of a JOB to determine if something 
did not go as expected, and then
possibly correct it!
*/
x = BPXWUNIX("/bin/grep -E -e'¬.{30}(.{10}  (12|16|20)'", 
"JesMsgLg.","BadSteps.")

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

Wacko S722 abend

[Jesse 1 Robinson]

I'm posting this here because I was asked too. It's beyond crazy. As I 
indicated earlier, we are trying to reduce spool full conditions by limiting 
job output via ESTLNCT. Yesterday we set the limit on one system like this:

ESTLNCT  NUM=2,INT=2,OPT=1

We changed NUM from the old value, but added OPT=1 to cancel the job with no 
dump. On this system only, a particular job started getting S722 for no 
apparent reason. It produces hardly any output at all. We looked at older 
executions-including yesterday before the JES change-and it appears that this 
job has *always* produced the output exceeded message but with no abend because 
of OPT=0. The output message appears in the job log even before the first step 
executes!

We ran the job in a different class with a different job name. Always the same 
message. Does this make sense to anyone?!?

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


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

Re: Wacko S722 abend

[Elardus Engelbrecht]

Jesse 1 Robinson wrote:

>I'm posting this here because I was asked too. It's beyond crazy. As I 
>indicated earlier, we are trying to reduce spool full conditions by limiting 
>job output via ESTLNCT. Yesterday we set the limit on one system like this:
>ESTLNCT  NUM=2,INT=2,OPT=1
>We changed NUM from the old value, but added OPT=1 to cancel the job with no 
>dump. 

What were the old values of NUM and INT?


>On this system only, a particular job started getting S722 for no apparent 
>reason. It produces hardly any output at all. We looked at older 
>executions-including yesterday before the JES change-and it appears that this 
>job has *always* produced the output exceeded message but with no abend 
>because of OPT=0. The output message appears in the job log even before the 
>first step executes!

Check if you have any wacko JES2 exit(s)... Any limiting statements in that job 
itself?


>We ran the job in a different class with a different job name. Always the same 
>message. 

You said you changed it on one system. What happens on the other system(s)?


>Does this make sense to anyone?!?

No. My users will certainly jump up and down if that happens to their jobs...

Groete / Greetings
Elardus Engelbrecht

We have now an extreme cold front in South Africa, it is so extremely cold, 
when I tried to get money from an ATM, the bank said my account is Frozen!

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

Re: Wacko S722 abend

[Tony Harminc]

On 13 June 2017 at 12:46, Jesse 1 Robinson  wrote:

> ESTLNCT  NUM=2,INT=2,OPT=1
>
> We changed NUM from the old value, but added OPT=1 to cancel the job with
> no dump. On this system only, a particular job started getting S722 for no
> apparent reason. It produces hardly any output at all. We looked at older
> executions-including yesterday before the JES change-and it appears that
> this job has *always* produced the output exceeded message but with no
> abend because of OPT=0.


Is it possible the job is printing a bazillion lines with no paper advance,
or even just very short lines? In other words lots of lines occupying
little actual space?


> The output message appears in the job log even before the first step
> executes!


Now *that* is bizarre (and shoots down my theory, I think).

Tony H.

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

Re: Wacko S722 abend

[Jesse 1 Robinson]

I don't want to turn this into a debugging session. We plan to open an SR with 
IBM. Just to verify what I've said, here are some lines from the job log. The 
first step is vanilla CA11. That's where the job dies. We completely removed 
the CA11 step; same result. I was just looking for any 'me too' responses. 

 TUESDAY,   13 JUN 2017    
 ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017  
 $HASP375 TEDD071  ESTIMATED  LINES EXCEEDED   
 $HASP373 TEDD071  STARTED - INIT 17   - CLASS K- SYS D0   
 SCEUJI02I JOB  TEDD071  STARTED03.39.19 13 JUN 17 
 IEF403I TEDD071 - STARTED - TIME=03.39.19 
 IEF450I TEDD071 RMS@30 RMS - ABEND=S722 U REASON=  841
 TIME=03.39.19 

.
.
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 Tony Harminc
Sent: Tuesday, June 13, 2017 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Wacko S722 abend

On 13 June 2017 at 12:46, Jesse 1 Robinson  wrote:

> ESTLNCT  NUM=2,INT=2,OPT=1
>
> We changed NUM from the old value, but added OPT=1 to cancel the job 
> with no dump. On this system only, a particular job started getting 
> S722 for no apparent reason. It produces hardly any output at all. We 
> looked at older executions-including yesterday before the JES 
> change-and it appears that this job has *always* produced the output 
> exceeded message but with no abend because of OPT=0.


Is it possible the job is printing a bazillion lines with no paper advance, or 
even just very short lines? In other words lots of lines occupying little 
actual space?


> The output message appears in the job log even before the first step 
> executes!


Now *that* is bizarre (and shoots down my theory, I think).

Tony H.


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

Re: Wacko S722 abend

[John McKown]

On Tue, Jun 13, 2017 at 12:41 PM, Jesse 1 Robinson 
wrote:

> I don't want to turn this into a debugging session. We plan to open an SR
> with IBM. Just to verify what I've said, here are some lines from the job
> log. The first step is vanilla CA11. That's where the job dies. We
> completely removed the CA11 step; same result. I was just looking for any
> 'me too' responses.
>
>  TUESDAY,   13 JUN 2017 
>  ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017
>  $HASP375 TEDD071  ESTIMATED  LINES EXCEEDED
>  $HASP373 TEDD071  STARTED - INIT 17   - CLASS K- SYS D0
>  SCEUJI02I JOB  TEDD071  STARTED03.39.19 13 JUN 17
>  IEF403I TEDD071 - STARTED - TIME=03.39.19
>  IEF450I TEDD071 RMS@30 RMS - ABEND=S722 U REASON=  841
>  TIME=03.39.19
>
> .
> .
> J.O.Skip Robinson
>

​Well, just to interject a likely stupid idea, can you access the job
output in SDSF? If so, I would put a question mark in front of the job to
display all the sysout entries. Then see which one has all the output lines
in it. Example:

LIH1 JOB DATA SET DISPLAY - JOB MAGI930D (JOB60835)LINE 1-6 (6)
COMMAND INPUT ===>SCROLL ===>
CSR
PREFIX=*  DEST=(ALL)  OWNER=*  SYSNAME=*
NP   DDNAME   StepName ProcStep DSID OwnerC Dest   Rec-Cnt
Page-Cnt Byte-Cnt CC
 JESMSGLG JES2 2 MDOFLI   N  4
   1
 JESJCL   JES2 3 MDOFLI   N 60
4,395  1
 JESYSMSG JES2 4 MDOFLI   N  3
  246  1
 RMSRPT   CA07RMS  RMS@2X101 MDOFLI   N  8
   1  577  1
 SYSPRINT JS010PS010 103 MDOFLI   N  0
   1
 DSSMSGDD JS010PS010 105 MDOFLI   N  0
   1​


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: Wacko S722 abend

[Allan Staller]

Any OUTLIM coded in JCL?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, June 13, 2017 12:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Wacko S722 abend

On Tue, Jun 13, 2017 at 12:41 PM, Jesse 1 Robinson 
wrote:

> I don't want to turn this into a debugging session. We plan to open an 
> SR with IBM. Just to verify what I've said, here are some lines from 
> the job log. The first step is vanilla CA11. That's where the job 
> dies. We completely removed the CA11 step; same result. I was just 
> looking for any 'me too' responses.
>
>  TUESDAY,   13 JUN 2017 
>  ICH70001I UCC7 LAST ACCESS AT 03:39:19 ON TUESDAY, JUNE 13, 2017
>  $HASP375 TEDD071  ESTIMATED  LINES EXCEEDED
>  $HASP373 TEDD071  STARTED - INIT 17   - CLASS K- SYS D0
>  SCEUJI02I JOB  TEDD071  STARTED03.39.19 13 JUN 17
>  IEF403I TEDD071 - STARTED - TIME=03.39.19  IEF450I TEDD071 RMS@30 RMS 
> - ABEND=S722 U REASON=  841
>  TIME=03.39.19
>
> .
> .
> J.O.Skip Robinson
>

​Well, just to interject a likely stupid idea, can you access the job output in 
SDSF? If so, I would put a question mark in front of the job to display all the 
sysout entries. Then see which one has all the output lines in it. Example:

LIH1 JOB DATA SET DISPLAY - JOB MAGI930D (JOB60835)LINE 1-6 (6)
COMMAND INPUT ===>SCROLL ===>
CSR
PREFIX=*  DEST=(ALL)  OWNER=*  SYSNAME=*
NP   DDNAME   StepName ProcStep DSID OwnerC Dest   Rec-Cnt
Page-Cnt Byte-Cnt CC
 JESMSGLG JES2 2 MDOFLI   N  4
   1
 JESJCL   JES2 3 MDOFLI   N 60
4,395  1
 JESYSMSG JES2 4 MDOFLI   N  3
  246  1
 RMSRPT   CA07RMS  RMS@2X101 MDOFLI   N  8
   1  577  1
 SYSPRINT JS010PS010 103 MDOFLI   N  0
   1
 DSSMSGDD JS010PS010 105 MDOFLI   N  0
   1​


--
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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


::DISCLAIMER::


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




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

Re: Java on z/OS?

[Frank Swarbrick]

Really?  I swear I tried this under z/OS 1.13 and it did not work.  Maybe I 
just assumed it, because all of the examples of using BPXBATCH don't write 
directly to SYSOUT.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Mark Zelden 
Sent: Friday, June 9, 2017 4:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Java on z/OS?

On Fri, 9 Jun 2017 18:02:25 +, Frank Swarbrick 
 wrote:

>What was the first release that allowed BPXBATCH to (finally) write to SYSOUT? 
> I wasn't
> aware of it, but indeed it does now work (z/OS 2.2)!
>
>Frank

z/OS 1.8 or z/OS 1.5, 1.6 and 1.7 with the fix for APAR OA11699 allowed MVS
files (including SYSOUT) to be used for STDOUT / STDERR / STDPARM.

Regards,

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


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

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

AW: Re: Wacko S722 abend

[Peter Hunkeler]

Can you post the JCL?


--
Peter Hunkeler






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

Re: Wacko S722 abend

[Jesse 1 Robinson]

Problem solved thanks to a colleague who put the right keywords on a Google 
search and found a past IBM-MAIN thread that provided the answer. This from the 
job card:

JOB (TE000MEJIC,DK6D,,0),...

In all my years I never learned about the 'other positional sub-parameters' of 
the accounting field. As spelled out in the JCL doc, the fourth sub-parameter 
means 'lines':

(pano,room,time,lines,cards,forms,copies,log,linect)

This job (as well as well a few others we discovered) were created by the same 
guy many years ago. Do not know what prompted him to add other sub-parameters, 
but that was the cause. As long as OPT=0 was in effect at the system level, we 
got the mysterious warning but no failure. When we set OPT=1, kaboom.

Thanks to all who chimed in. 

.  

.
.
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 Peter Hunkeler
Sent: Tuesday, June 13, 2017 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: Wacko S722 abend

Can you post the JCL? 


--
Peter Hunkeler


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

Re: Wacko S722 abend

[Porowski, Kenneth]

One reason people will code 0 linecount/cardcount in the jobcard is that it can 
affect the jes input queue priority.  On systems where queuing is frequent this 
is one way to get your job bumped to the top or at least higher on the food 
chain.



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Tuesday, June 13, 2017 3:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Wacko S722 abend

Problem solved thanks to a colleague who put the right keywords on a Google 
search and found a past IBM-MAIN thread that provided the answer. This from the 
job card:

JOB (TE000MEJIC,DK6D,,0),...

In all my years I never learned about the 'other positional sub-parameters' of 
the accounting field. As spelled out in the JCL doc, the fourth sub-parameter 
means 'lines':

(pano,room,time,lines,cards,forms,copies,log,linect)

This job (as well as well a few others we discovered) were created by the same 
guy many years ago. Do not know what prompted him to add other sub-parameters, 
but that was the cause. As long as OPT=0 was in effect at the system level, we 
got the mysterious warning but no failure. When we set OPT=1, kaboom.

Thanks to all who chimed in.

.

.
.
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 Peter Hunkeler
Sent: Tuesday, June 13, 2017 11:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):AW: Re: Wacko S722 abend

Can you post the JCL?


--
Peter Hunkeler


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

AW: Re: Wacko S722 abend

[Peter Hunkeler]

>This from the job card:>>JOB (TE000MEJIC,DK6D,,0),...


Exactly the reason I asked to see the JCL. I was just too lazy to lookup the 
format of the accounting parameter, and thought I would recognize once I see it.
Glad you found it.

I always found it somewhat strange design that JES is trying to interpret the 
accounting field, and silently jumps over stuff that does not fit.

--Peter Hunkeler





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

Re: IBM customer anchor

[Steve Thompson]

On 06/13/2017 08:35 AM, scott Ford wrote:

All:

I have a question about something called
'customer anchor table entry' . My colleague said IBM can provide this
entry to a ISV like use so we can place an address there for routines.  I
think it's like a vector address .

Has anyone heard of this ?



Yes I know about it and I kinda know the history of it. I'm not 
sure but I think I was the first one if not one of the first to 
apply for an entry when it was announced back in the mid-'90s 
when I was still working on ACS/WYLBUR and attended the "Vendor 
Disclosure Meeting"s in POK.


It solves the problem of the TCBUSER field in the TCBs, and the 
CVTUSER in the CVT. The problem being, who owns it and who can 
use it and NOT step on someone else.


It gives you an ANCHOR address where you can do a GETMAIN/STORAGE 
OBTAIN for CSA/SQA storage and store the address of that storage 
in your slot.


How you serialize it, use it, etc., is your problem as an ISV 
with multiple, or just one, product.


Regards,
Steve Thompson

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

SMFLIMxx sample?

[Pew, Curtis G]

I’m going through our SMF exits and reviewing them. I was able to eliminate 
most of what IEFUSI was doing; all that was left was setting the REGION limits. 
Then reading the manual more carefully I discovered there’s a new (apparently 
starting in z/OS 2.2) PARMLIB member, SMFLIMxx, that can do this without the 
need for an exit. However, the description of this member in Init and Tuning 
doesn’t have any examples, and I’m not really clear on the syntax just from the 
description. Is anyone using this? Would you be willing to share some sample 
rules? One of my questions is, does the rule have to fit on a single record, or 
can it be continued?

Thanks for any help.

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


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

EREP Symptom and/or Software Records

[Turner Cheryl L]

Greetings.
Our former sysprog, who paid attention to the more finer system details, has 
left the building for greener pastures.  So now we seem to have to step up our 
game.  However, I'm not sure what to do or how.

We are running several EREP reports to see what software or symptom records are 
being cut per LPAR (mostly just HISTORY reports for now).  We are finding that 
a lot of records are being cut at the time an IBM supplied SLIP trap is taken 
(for example X13E, X47B, X91A).  Some of these records can exceed hundreds on a 
given day.

What should we/I be doing? Reporting them to IBM? I just don't understand why 
IBM would set the SLIP yet cut a symptom or software record too.  We can't be 
the only shop seeing these. Yet I've tried to research a few on IBMLINK but 
can't find any hits for known problems.  Or maybe there is a way to turn of the 
creation of the software/symptom record?  Though I can't wrap my head around 
that either, thinking why are they then being cut at all if it's not anything 
to look into?

Any schooling you can give, would be most appreciated! But please, be gentle. 
I'm out of my element. Many thanks to you all.

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

Re: EREP Symptom and/or Software Records

[Jesse 1 Robinson]

Those IBM supplied SLIP traps are generally there to suppress irrelevant SVC 
dumps:

SL SET,C=13E,ID=X13E,A=NODUMP,END

Imagine what would happen if you got a dump for each S13E in addition to the 
LOGREC record? The truth is that some abends relating to 'improper' termination 
cleanup are just part of MVS noise. They seldom mean anything at all, but they 
are after all abends, so they are acknowledged and recorded. But unless you (or 
a vendor) needs to pursue the cause, nothing else needs to be done. 

There are also NODUMP or NOSVCD SLIP traps for S013, Sx37, and other common 
'user error' abends. If you need a dump for such an error, you can override the 
SLIP trap, but in most cases, the cause--and the solution--are obvious. 

.
.
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 Turner Cheryl L
Sent: Tuesday, June 13, 2017 2:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):EREP Symptom and/or Software Records

Greetings.
Our former sysprog, who paid attention to the more finer system details, has 
left the building for greener pastures.  So now we seem to have to step up our 
game.  However, I'm not sure what to do or how.

We are running several EREP reports to see what software or symptom records are 
being cut per LPAR (mostly just HISTORY reports for now).  We are finding that 
a lot of records are being cut at the time an IBM supplied SLIP trap is taken 
(for example X13E, X47B, X91A).  Some of these records can exceed hundreds on a 
given day.

What should we/I be doing? Reporting them to IBM? I just don't understand why 
IBM would set the SLIP yet cut a symptom or software record too.  We can't be 
the only shop seeing these. Yet I've tried to research a few on IBMLINK but 
can't find any hits for known problems.  Or maybe there is a way to turn of the 
creation of the software/symptom record?  Though I can't wrap my head around 
that either, thinking why are they then being cut at all if it's not anything 
to look into?

Any schooling you can give, would be most appreciated! But please, be gentle. 
I'm out of my element. Many thanks to you all.


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

Re: IBM customer anchor

[Charles Mills]

As a user of the word, you really, really want to think about upward 
compatibility. Don't store the address of your product's anchor table there. 
Assume you will someday have multiple products. You would want to store the 
address of a vector of anchor table addresses. Think about upward compatibility 
for the layout. Include a length and a version number in your vector. Clear 
everything unused to zero. Think about how your products will cooperate if 
product A starts up first; or if product B starts up first. 

Think about how your customer will recover without an IPL if the tables become 
corrupted.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Tuesday, June 13, 2017 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

On 06/13/2017 08:35 AM, scott Ford wrote:
> All:
> 
> I have a question about something called 'customer anchor table entry' 
> . My colleague said IBM can provide this entry to a ISV like use so we 
> can place an address there for routines.  I think it's like a vector 
> address .
> 
> Has anyone heard of this ?
> 

Yes I know about it and I kinda know the history of it. I'm not sure but I 
think I was the first one if not one of the first to apply for an entry when it 
was announced back in the mid-'90s when I was still working on ACS/WYLBUR and 
attended the "Vendor Disclosure Meeting"s in POK.

It solves the problem of the TCBUSER field in the TCBs, and the CVTUSER in the 
CVT. The problem being, who owns it and who can use it and NOT step on someone 
else.

It gives you an ANCHOR address where you can do a GETMAIN/STORAGE OBTAIN for 
CSA/SQA storage and store the address of that storage in your slot.

How you serialize it, use it, etc., is your problem as an ISV with multiple, or 
just one, product.

Regards,
Steve Thompson

--
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: Wacko S722 abend

[Edward Gould]

> On Jun 13, 2017, at 2:36 PM, Porowski, Kenneth  wrote:
> 
> One reason people will code 0 linecount/cardcount in the jobcard is that it 
> can affect the jes input queue priority.  On systems where queuing is 
> frequent this is one way to get your job bumped to the top or at least higher 
> on the food chain.
> 

Ken:

Bingo we have a winner… A long time ago memory popped up with this. The 
programmers found out about it and started using it. We started getting calls 
about test turn around. After a bit of digging we figured out the issue.
We got  busy and wrote some minor JES2 code to disregard the number of lines 
when it came time to figure out priority.

Complaints dropped dramatically when we implemented it.

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

Re: EREP Symptom and/or Software Records

[Edward Gould]

> On Jun 13, 2017, at 4:24 PM, Turner Cheryl L  wrote:
> 
> Greetings.
> Our former sysprog, who paid attention to the more finer system details, has 
> left the building for greener pastures.  So now we seem to have to step up 
> our game.  However, I'm not sure what to do or how.
> 
> We are running several EREP reports to see what software or symptom records 
> are being cut per LPAR (mostly just HISTORY reports for now).  We are finding 
> that a lot of records are being cut at the time an IBM supplied SLIP trap is 
> taken (for example X13E, X47B, X91A).  Some of these records can exceed 
> hundreds on a given day.
> 
> What should we/I be doing? Reporting them to IBM? I just don't understand why 
> IBM would set the SLIP yet cut a symptom or software record too.  We can't be 
> the only shop seeing these. Yet I've tried to research a few on IBMLINK but 
> can't find any hits for known problems.  Or maybe there is a way to turn of 
> the creation of the software/symptom record?  Though I can't wrap my head 
> around that either, thinking why are they then being cut at all if it's not 
> anything to look into?

I was doing this in the 1990’s. I would look through the report to see if there 
were possibly duplicates. If there was I would fire up ibmlink and do a search 
on the modules and abend code. I almost always get a hit. I would research the 
apartment and look up the pff number and it would go in ASAP (scheduled IPL 
every weekend). Sometimes a system dump would show up as well. Kept an eye on 
those as well.
It kept our system up and running and no strange things ever happened.
I also kept a eagle eye on PSF bends as we were ECS and always needed the 
latest software available. I also was on a first name basis of level 2/3 for 
PSF issues. It was a lot of work because IMO PSF was bug ridden when we got it.
Ed
> 
> Any schooling you can give, would be most appreciated! But please, be gentle. 
> I'm out of my element. Many thanks to you all.
> 
> --
> 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: IBM customer anchor

[John McKown]

On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:

> As a user of the word, you really, really want to think about upward
> compatibility. Don't store the address of your product's anchor table
> there. Assume you will someday have multiple products. You would want to
> store the address of a vector of anchor table addresses. Think about upward
> compatibility for the layout. Include a length and a version number in your
> vector. Clear everything unused to zero. Think about how your products will
> cooperate if product A starts up first; or if product B starts up first.
>
> Think about how your customer will recover without an IPL if the tables
> become corrupted.
>
> Charles
>

​Hum, I'm likely missing something, but my thought is to just use a global
NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
using that versus "chain chasing" from the CVT. If necessary, the NAME
portion could be an initialization parameter just in case some other
"product" used the same one. It could be set via a configuration CSECT,
which is compiled into the execution library & LOADed. Or specified in the
PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
weird, make the "configuration repository" a "hard coded" UNIX file name
such as /etc/.conf where  depends on what you call your
product (e.g. /etc/sdsf.conf for the SDSF parameters).


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: Notify Type in Apar

[Dan Little]

I believe it means the Hiper flag is being removed from the APAR for some 
reason. Perhaps there is a different root cause than originally thought or 
something like that.

Thanks.
Dan

On Jun 13, 2017, 12:35 PM -0400, Gilson Cesar de Oliveira , 
wrote:
>
> >
> > Dear list:
> Does anyone know the meaning of Notify Type= Hyper DEL in apar??
>
> I have received a notification today but I could not find the meaning of thid 
> Notify Type.
>
> Thanks for any help.
>
> Regards,
>
> Gilson
>
> --
> 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: EREP Symptom and/or Software Records

[Lizette Koehler]

So Logrec has two types of sysprogs using it

the ones that want to know everything that is going on - read it hourly (i use 
to do that)

the ones that only look at it when it is associated with a problem. (i do that 
now.)

If your shop has a lot of issues with software and/or hardware, then reviewing 
logrec is helpful.  There is a tool called LOGGER that that helps with 
reviewing logrec online.  I am not sure where that REXX is but I think you 
should be able to find it in an IBM Tools area.


If you do not have a lot of software or hardware issue, then you might want to 
revisit what should be done about logrec.

I have it in a offloaded GDG and rarely look at it.  When I had physical 
cartridge tape, I needed to see how bad the errors were on the tapes.  Now that 
i have virtual tape, I hardly look at it at all.

Lizette



-Original Message-
>From: Turner Cheryl L 
>Sent: Jun 13, 2017 2:24 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: EREP Symptom and/or Software Records
>
>Greetings.
>Our former sysprog, who paid attention to the more finer system details, has 
>left the building for greener pastures.  So now we seem to have to step up our 
>game.  However, I'm not sure what to do or how.
>
>We are running several EREP reports to see what software or symptom records 
>are being cut per LPAR (mostly just HISTORY reports for now).  We are finding 
>that a lot of records are being cut at the time an IBM supplied SLIP trap is 
>taken (for example X13E, X47B, X91A).  Some of these records can exceed 
>hundreds on a given day.
>
>What should we/I be doing? Reporting them to IBM? I just don't understand why 
>IBM would set the SLIP yet cut a symptom or software record too.  We can't be 
>the only shop seeing these. Yet I've tried to research a few on IBMLINK but 
>can't find any hits for known problems.  Or maybe there is a way to turn of 
>the creation of the software/symptom record?  Though I can't wrap my head 
>around that either, thinking why are they then being cut at all if it's not 
>anything to look into?
>
>Any schooling you can give, would be most appreciated! But please, be gentle. 
>I'm out of my element. Many thanks to you all.
>

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

Re: IBM customer anchor

[Steve Thompson]

On 06/13/2017 09:06 PM, John McKown wrote:

On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:


As a user of the word, you really, really want to think about upward
compatibility. Don't store the address of your product's anchor table
there. Assume you will someday have multiple products. You would want to
store the address of a vector of anchor table addresses. Think about upward
compatibility for the layout. Include a length and a version number in your
vector. Clear everything unused to zero. Think about how your products will
cooperate if product A starts up first; or if product B starts up first.

Think about how your customer will recover without an IPL if the tables
become corrupted.

Charles



​Hum, I'm likely missing something, but my thought is to just use a global
NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
using that versus "chain chasing" from the CVT. If necessary, the NAME
portion could be an initialization parameter just in case some other
"product" used the same one. It could be set via a configuration CSECT,
which is compiled into the execution library & LOADed. Or specified in the
PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
weird, make the "configuration repository" a "hard coded" UNIX file name
such as /etc/.conf where  depends on what you call your
product (e.g. /etc/sdsf.conf for the SDSF parameters).



Me thinks you are missing something.

However, data set names and/or code paths are an interesting 
thing to hold in your storage that is anchored out of the User's 
Anchor Table.


When I started working with this many years ago, I immediately 
started thinking about how to use that anchor point to allow 
cross product communications, should ACS ever acquire another 
company that had a product.


So as Charles Mills said, one really needs to think about how to 
use this (and now I will add to what he said) before one paints 
themselves into a corner and this anchor point becomes a problem.


That "Think about how your customer will recover without an IPL 
if the tables become corrupted." is a very interesting statement.


So, running a chain to get to your anchor is not that big of a 
deal, AND, if your product is starting up, it can, from any 
address space, find out if it had been running, or if any of its 
compatriots are running and change its start up code paths 
accordingly.


Regards,
Steve Thompson

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

Re: IBM customer anchor

[scott Ford]

Steve,

This is exactly as Charles stated we want to do.

Scott

On Tue, Jun 13, 2017 at 10:51 PM Steve Thompson  wrote:

> On 06/13/2017 09:06 PM, John McKown wrote:
> > On Tue, Jun 13, 2017 at 5:44 PM, Charles Mills  wrote:
> >
> >> As a user of the word, you really, really want to think about upward
> >> compatibility. Don't store the address of your product's anchor table
> >> there. Assume you will someday have multiple products. You would want to
> >> store the address of a vector of anchor table addresses. Think about
> upward
> >> compatibility for the layout. Include a length and a version number in
> your
> >> vector. Clear everything unused to zero. Think about how your products
> will
> >> cooperate if product A starts up first; or if product B starts up first.
> >>
> >> Think about how your customer will recover without an IPL if the tables
> >> become corrupted.
> >>
> >> Charles
> >>
> >
> > ​Hum, I'm likely missing something, but my thought is to just use a
> global
> > NAME/TOKEN pair​. Of course, I don't know the relative CPU efficiency of
> > using that versus "chain chasing" from the CVT. If necessary, the NAME
> > portion could be an initialization parameter just in case some other
> > "product" used the same one. It could be set via a configuration CSECT,
> > which is compiled into the execution library & LOADed. Or specified in
> the
> > PARM= on the EXEC. Or even in a DSN specified using a DD. For the truly
> > weird, make the "configuration repository" a "hard coded" UNIX file name
> > such as /etc/.conf where  depends on what you call your
> > product (e.g. /etc/sdsf.conf for the SDSF parameters).
> 
>
> Me thinks you are missing something.
>
> However, data set names and/or code paths are an interesting
> thing to hold in your storage that is anchored out of the User's
> Anchor Table.
>
> When I started working with this many years ago, I immediately
> started thinking about how to use that anchor point to allow
> cross product communications, should ACS ever acquire another
> company that had a product.
>
> So as Charles Mills said, one really needs to think about how to
> use this (and now I will add to what he said) before one paints
> themselves into a corner and this anchor point becomes a problem.
>
> That "Think about how your customer will recover without an IPL
> if the tables become corrupted." is a very interesting statement.
>
> So, running a chain to get to your anchor is not that big of a
> deal, AND, if your product is starting up, it can, from any
> address space, find out if it had been running, or if any of its
> compatriots are running and change its start up code paths
> accordingly.
>
> Regards,
> Steve Thompson
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: "New" Java-less Operating System Messages blips like crazy

[David Crayford]

On 11/06/2017 7:15 AM, Ed Jaffe wrote:

On 6/6/2017 8:54 PM, David Crayford wrote:

On 7/06/2017 1:43 AM, Ed Jaffe wrote:


We test (E)JES Web with current releases of Chrome, Firefox, Opera, 
Safari, and IE. We also test with IE8 because it's a different 
animal and requires special code to make things work right...




Do you have a firm requirement to support IE8?


We'd love, Love, LOVE to drop support for IE8 but for some strange 
reason a LOT of customers are still using it. :-(




Interesting. I hope none of our customers are using IE8 because they 
won't be able to use the Web UI!


Do you have any idea why they are using an unsupported browser?

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