Re: Question on 3270 Devices (3290 Orange Screen!)
In blu436-smtp10277173df1957efbeea268da...@phx.gbl, on 05/31/2015 at 01:40 PM, Tony's Outlook via Mozilla tbabo...@outlook.com said: I loved the 3290, AOL. Wish I could emulate it on my large monitor. Doesn't vista handle that, plus color? Always wishing to push a limit I once split my 3290 into 4 screens, I alway ran in 62x80, and let ISPF split it at need. I found 4 24x80 splits to be readable, but mostly I had 2 80-column splits for editing and one wide split for viewing listings. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Notify for XMIT
In 556b662e.60...@acm.org, on 05/31/2015 at 02:51 PM, Joel Ewing jcew...@acm.org said: The above CLIST code should presumably work as you expect for intercepting SEND CLIST errors in an Interactive TSO/E, ISPF environment where TSO is invoked via a TSO logon PROC as IKJEFT01 and not as IKJEFT1A or IKJEFT1B. AFAIK all of IKJEFT01, IKJEFT1A and IKJEFT1B have the same task structure.. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Where can a running TSO program get its terminal name
In 000701d09bd1$1872a0e0$4957e2a0$@mcn.org, on 05/31/2015 at 11:39 AM, Charles Mills charl...@mcn.org said: The master of the out-of-context quote. Not even close; the context was clearly IEABRCX. By all means use it blindly; it's not my dog. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: SMPE MCS construction question re aliases
In 556c5f4f.1090...@us.ibm.com, on 06/01/2015 at 09:34 AM, Kurt Quackenbush ku...@us.ibm.com said: The ++PROGRAM MCS describes a program element (a pre-built load module or a program object). It must immediately precede the load module or program object when they are within the SYSMOD. That would be a good trick. I might believe a GIMZIP compressed version. Its no trick. GIMDTS is your friend here. Certainly, but what you have is a compressed file, not a load module or program object. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: New Line vs. Line Feed
On Mon, 1 Jun 2015 22:18:20 -0500, Bill Godfrey wrote:
The grep and awk commands don't match \n to end-of-line on omvs, or on
linux for that matter.
awk certainly does. To wit:
user@OS/390.24.00: cat awknl
#! /bin/sh -x
awk 'BEGIN {
String = First line\nSecond line.\n
# Show that \n is a line end.
printf( %s, String )
# show that \n matches line end.
print( match( String, \n ) )
}'
user@OS/390.24.00: sh awknl
First line
Second line.
11
user@OS/390.24.00:
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Notify for XMIT
In 556c7872.7020...@acm.org, on 06/01/2015
at 10:21 AM, Joel Ewing jcew...@acm.org said:
Now to complete the test try invoking your invalid-keyword version
of the CLIST from the SYSTSIN SYSIN file in a Batch TSO job step
where the JCL EXEC statement invokes PGM=IKJEFT1A,
If you're trying to see a difference between background and foreground
then use the same TMP for both. If you're trying to see the difference
between IKJEFT01 and IKJEFT1A, then try both in background or both in
foreground. Changing two variable at once won't give you a clear
picture.
The whole point is that CLISTs under TSO/E behave (as documented)
somewhat differently in a batch IKJEFT1A/IKJEFT1B environment versus
an interactive TSO session.
No, foreground versus background is a red herring. The behavior of
IKJEFT1{AB} would be just as bad in foreground.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see http://patriot.net/~shmuel/resume/brief.html
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: AW: Re: AW: Re: OMVS command history
In ez-800529419.1651755...@gmx.ch, on 06/01/2015 at 07:51 AM, Peter Hunkeler p...@gmx.ch said: Well, as I wrote, the OMVS command processor There's more to OMVS than just the shell. The phrase but OMVS has no access clearly refers to more than the shell. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Question on 3270 Devices
In 556c66e1.7090...@rochester.rr.com, on 06/01/2015 at 10:06 AM, Thomas Conley pinnc...@rochester.rr.com said: Good points all, but Gil wants to have multiple ISPF sessions on the same LPAR. TSO currently doesn't support that natively, ObGungaDin WSA. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Question on 3270 Devices
In cafo-8tq0gavpzyufbhxgwxuwik6jqw4wzkq+xob-5y9hgf3...@mail.gmail.com, on 05/31/2015 at 01:54 PM, zMan zedgarhoo...@gmail.com said: Right, but this wasn't IBM, and was color (3279). 3279 is an IBM line, and 3rd party vendors rarely repurpose IBM model numbers. Clearly a 3290 competitor. Not if it can't display 4 sessions concurrently and don't let an application carve up a 62x160 session. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: LPAR MOBILITY
In 7ejoma1d3tjintk6at60q4i723p3127...@4ax.com, on 06/01/2015 at 09:20 AM, Clark Morris cfmpub...@ns.sympatico.ca said: On 31 May 2015 10:05:29 -0700, in bit.listserv.ibm-main you wrote: In 0912959236903597.wa.wwwdieuyahoo@listserv.ua.edu, on 05/28/2015 at 04:22 AM, IBMZOS 00af65f10fb1-dmarc-requ...@listserv.ua.edu said: thought Z was at the top of technology. Z is missing things that IBM developeds on S/360 and S/370. The cobbler's son is barefoot. What things? Queued Partioned Access Method[1]. DSS. Dynamic linking. Some capabilities we finally introduced into MVS, be decdes lar and in truncated form. [1] Including Queued Indexed Partitioned Access Methods. Are there replacements? Partial. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Question on 3270 Devices
In 0354368054759855.wa.paulgboulderaim@listserv.ua.edu, on 06/01/2015 at 09:52 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: As the end user, I care little about the technical details of the blockage; only that the facility is unavailable. That's fine if you don't really care about what you're asking for but are only letting off steam. It's not productive if you really do care. And I might reverse the analysis and fault ISPF for relying on an inadequate service. You might, if you didn't want to be taken seriously. An alternative approach might be to liberate ISPF from dependency on TSO. Again? Why wasn't twice enough? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: SMPE MCS construction question re aliases
In 6503242797771151.wa.paulgboulderaim@listserv.ua.edu, on 06/01/2015 at 07:40 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu said: On Sun, 31 May 2015 09:22:12 -0400, Shmuel Metz (Seymour J.) wrote: The ++PROGRAM MCS describes a program element (a pre-built load module or a program object). It must immediately precede the load module or program object when they are within the SYSMOD. That would be a good trick. I might believe a GIMZIP compressed version. This good trick is routinely accomplished by IEBCOPY and GIMDTS. No; a different trick is accomplished. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: intermittant abends
Do they all fail at offset 0 or just AMATERSE? Do you have any exits or vendor products that monitor program use - including things like Omegamon? Have they been upgraded to levels compatible with 2.1 ? I ask because I experienced a similar thing during an OS upgrade (not to 2.1 ...) where we got 0C4 abends during step completions. Turns out a monitor had an undocumented hook at the IEFACTRT exit point, the OS moved something above the 16MB line, and the un-upgraded monitor code was trying to reach it in 24-bit mode. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: intermittant abends
These abends are appearing in various areas. 1. running SCLM compiles 2. Displaying userid info from the RACF database using option 4 3. In a batch execution of AMATERSE IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 TIME=15.12.34 SEQ=00177 CPU= ASID=003A PSW AT TIME OF ERROR 078D3000 8001C3E4 ILC 6 INTC 11 ACTIVE LOAD MODULE ADDRESS=76B8 OFFSET=000 NAME=AMATERSE DATA AT PSW 0001C3DE - 1E675E60 BB6BD200 9ABC6000 GR 0: 6AA5 1: 0001C5DC 2: 0001 3: 6BE1 4: 6CC4 5: 6: 00B82FEB 7: 0001 8: 00B82FEB 9: 6248 A: 0001CA88 B: 0001BA89 C: 8001AA8A D: 6248 E: 8001B7BE F: END OF SYMPTOM DUMP IEF450I SYSJCNTE S1 - ABEND=S0C4 U REASON=0011 689 All these tasks ran fine on z/os 1.13 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, June 02, 2015 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends I am not sure you have provided enough detail here. We finished our upgrade to z/OS V2.1 and did not see this issue. Could you post the entire Summary dump from the JOBLOG with Registers? Could you post additional message in SYSLOG around where the S0C4 occurs? What are you running when you get this error? I would guess that this ran successfully prior to z/OS V2.1. Did you make any changes before moving this to z/OS V2.1? Or is this the exact same process that runs successfully on your down leveled LPAR? Lizette -Original Message- From: John Norgauer jcnorga...@ucdavis.edu Sent: Jun 2, 2015 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: intermittant abends We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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: Question on 3270 Devices
Which is what I said it did. What are you on about? On Mon, Jun 1, 2015 at 8:38 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cafo-8tq0gavpzyufbhxgwxuwik6jqw4wzkq+xob-5y9hgf3...@mail.gmail.com, on 05/31/2015 at 01:54 PM, zMan zedgarhoo...@gmail.com said: Right, but this wasn't IBM, and was color (3279). 3279 is an IBM line, and 3rd party vendors rarely repurpose IBM model numbers. Clearly a 3290 competitor. Not if it can't display 4 sessions concurrently and don't let an application carve up a 62x160 session. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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 -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: intermittant abends
What is your current maint level on z/OS V2.1. oa42694 is from 2013. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Tuesday, June 02, 2015 12:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends These abends are appearing in various areas. 1. running SCLM compiles 2. Displaying userid info from the RACF database using option 4 3. In a batch execution of AMATERSE IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 TIME=15.12.34 SEQ=00177 CPU= ASID=003A PSW AT TIME OF ERROR 078D3000 8001C3E4 ILC 6 INTC 11 ACTIVE LOAD MODULE ADDRESS=76B8 OFFSET=000 NAME=AMATERSE DATA AT PSW 0001C3DE - 1E675E60 BB6BD200 9ABC6000 GR 0: 6AA5 1: 0001C5DC 2: 0001 3: 6BE1 4: 6CC4 5: 6: 00B82FEB 7: 0001 8: 00B82FEB 9: 6248 A: 0001CA88 B: 0001BA89 C: 8001AA8A D: 6248 E: 8001B7BE F: END OF SYMPTOM DUMP IEF450I SYSJCNTE S1 - ABEND=S0C4 U REASON=0011 689 All these tasks ran fine on z/os 1.13 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, June 02, 2015 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends I am not sure you have provided enough detail here. We finished our upgrade to z/OS V2.1 and did not see this issue. Could you post the entire Summary dump from the JOBLOG with Registers? Could you post additional message in SYSLOG around where the S0C4 occurs? What are you running when you get this error? I would guess that this ran successfully prior to z/OS V2.1. Did you make any changes before moving this to z/OS V2.1? Or is this the exact same process that runs successfully on your down leveled LPAR? Lizette -Original Message- From: John Norgauer jcnorga...@ucdavis.edu Sent: Jun 2, 2015 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: intermittant abends We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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: intermittant abends
Could oa42694 be the cause ? Jim McAlpine On 2 Jun 2015 19:17, John Norgauer jcnorga...@ucdavis.edu wrote: We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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: intermittant abends
I am not sure you have provided enough detail here. We finished our upgrade to z/OS V2.1 and did not see this issue. Could you post the entire Summary dump from the JOBLOG with Registers? Could you post additional message in SYSLOG around where the S0C4 occurs? What are you running when you get this error? I would guess that this ran successfully prior to z/OS V2.1. Did you make any changes before moving this to z/OS V2.1? Or is this the exact same process that runs successfully on your down leveled LPAR? Lizette -Original Message- From: John Norgauer jcnorga...@ucdavis.edu Sent: Jun 2, 2015 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: intermittant abends We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Hillgang - 17 June
The next meeting of Hillgang, the VA/MD/DC z/VM and Linux on z user group, will take place on Wednesday, 17th June at the CA Offices in Herndon VA. The agenda, location, and registration details may be found at: http://www.vm.ibm.com/events/HILL0615.PDF. We will have Barton Robinson (Velocity), Rita Shan (PenFed Credit Union), and John Franciscovich (IBM) presenting at the meeting. Neale -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Value of ZENVIR in z/OS 2.1
Just to follow up IBM has confirmed the manual is in error and will be corrected; i.e. the value of ZENVIR in z/OS 2.1 should be 7.1 and not 7.0. Thanks to IBM and to others who responded. Dave Salt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: intermittant abends
I'll check it out with IBM Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim McAlpine Sent: Tuesday, June 02, 2015 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends Could oa42694 be the cause ? Jim McAlpine On 2 Jun 2015 19:17, John Norgauer jcnorga...@ucdavis.edu wrote: We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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
intermittant abends
We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: intermittant abends
Different locations. My sandbox appears to function OK. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Hare Sent: Tuesday, June 02, 2015 12:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends Do they all fail at offset 0 or just AMATERSE? Do you have any exits or vendor products that monitor program use - including things like Omegamon? Have they been upgraded to levels compatible with 2.1 ? I ask because I experienced a similar thing during an OS upgrade (not to 2.1 ...) where we got 0C4 abends during step completions. Turns out a monitor had an undocumented hook at the IEFACTRT exit point, the OS moved something above the 16MB line, and the un-upgraded monitor code was trying to reach it in 24-bit mode. -- 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: intermittant abends
We are at Serverpac level of maint. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, June 02, 2015 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends What is your current maint level on z/OS V2.1. oa42694 is from 2013. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Tuesday, June 02, 2015 12:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends These abends are appearing in various areas. 1. running SCLM compiles 2. Displaying userid info from the RACF database using option 4 3. In a batch execution of AMATERSE IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 TIME=15.12.34 SEQ=00177 CPU= ASID=003A PSW AT TIME OF ERROR 078D3000 8001C3E4 ILC 6 INTC 11 ACTIVE LOAD MODULE ADDRESS=76B8 OFFSET=000 NAME=AMATERSE DATA AT PSW 0001C3DE - 1E675E60 BB6BD200 9ABC6000 GR 0: 6AA5 1: 0001C5DC 2: 0001 3: 6BE1 4: 6CC4 5: 6: 00B82FEB 7: 0001 8: 00B82FEB 9: 6248 A: 0001CA88 B: 0001BA89 C: 8001AA8A D: 6248 E: 8001B7BE F: END OF SYMPTOM DUMP IEF450I SYSJCNTE S1 - ABEND=S0C4 U REASON=0011 689 All these tasks ran fine on z/os 1.13 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Tuesday, June 02, 2015 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends I am not sure you have provided enough detail here. We finished our upgrade to z/OS V2.1 and did not see this issue. Could you post the entire Summary dump from the JOBLOG with Registers? Could you post additional message in SYSLOG around where the S0C4 occurs? What are you running when you get this error? I would guess that this ran successfully prior to z/OS V2.1. Did you make any changes before moving this to z/OS V2.1? Or is this the exact same process that runs successfully on your down leveled LPAR? Lizette -Original Message- From: John Norgauer jcnorga...@ucdavis.edu Sent: Jun 2, 2015 11:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: intermittant abends We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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: EMC DLM
I know very little about EMC DLM but I do know it uses a lock directory that you need read/write access to. The lock directory is specified on the Storage tab of the administrator's web interface. Cliff McNeill We have an EMC DLM in production replicating to one for DR. We are unable to get buy getting the following message when attempting to restore from the DR box DLm455E: Error locking volume 300119 (/tapelib/DISK0/300119): Read-only file system -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
EMC DLM
We have an EMC DLM in production replicating to one for DR. We are unable to get buy getting the following message when attempting to restore from the DR box DLm455E: Error locking volume 300119 (/tapelib/DISK0/300119): Read-only file system I genned a different set of tape drives to use on the current production box to test DR. We were just expecting to be able to restore from DR box as we can in production. Obviously we made a bad assumption or missed something. I understand that the DR side is read only. All I am trying to do is restore a PDS from a 'tape' on the DR side. Any help would be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EMC DLM
I am going to say this - and I am not happy. Contact EMC through their SR process. They are very adept as helping with these types of issues. We have had several Tapes being locked and they were able to Dial in and correct the issue. They also can provide guidance on how to do what you want. We have a similar configuration, but I have not tested the DR tapes yet. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Melissa Perry Sent: Tuesday, June 02, 2015 1:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EMC DLM We have an EMC DLM in production replicating to one for DR. We are unable to get buy getting the following message when attempting to restore from the DR box DLm455E: Error locking volume 300119 (/tapelib/DISK0/300119): Read-only file system I genned a different set of tape drives to use on the current production box to test DR. We were just expecting to be able to restore from DR box as we can in production. Obviously we made a bad assumption or missed something. I understand that the DR side is read only. All I am trying to do is restore a PDS from a 'tape' on the DR side. Any help would be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MQ QMGR bringing down
Sure Lizette and this was a much needed article. Thanks..! Samat From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf of Lizette Koehler stars...@mindspring.com Sent: Monday, June 1, 2015 9:26:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MQ QMGR bringing down This is a good article on stopping/starting MQ https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/zos_websphere_mq_what_goes_up_must_come_down?lang=en Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, June 01, 2015 8:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MQ QMGR bringing down I would recommend NOT using FORCE until you know the reason the qmgr is not coming down. You may damage something you do not want to damage. In my opinion, always determine the cause before applying a hammer. It maybe that it is the right solution, but you need to make sure it is. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of zos reader Sent: Monday, June 01, 2015 8:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: MQ QMGR bringing down Thanks Kolusu, it worked and i have brought down the MQ QMGR Regards, Samat On Mon, Jun 1, 2015 at 8:51 PM, Sri h Kolusu skol...@us.ibm.com wrote: May be you need Mode FORCE Example : STOP QMGR MODE(FORCE) And this article might give more insights. https://www.ibm.com/developerworks/community/blogs/aimsupport/entr y/zo s_websphere_mq_what_goes_up_must_come_down?lang=en Thanks, Kolusu IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 06/01/2015 08:10:18 AM: From: zos reader zos.rea...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/01/2015 08:11 AM Subject: Re: MQ QMGR bringing down Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Yes, tried it and still i couldn't bring down RESPONSE=SYS9 CSQY004I /CSQ1 QUEUE MANAGER IS ALREADY STOPPING RESPONSE=SYS9 CSQ9023E /CSQ1 CSQYSCMD 'STOP QMGR' ABNORMAL COMPLETION Thanks On Mon, Jun 1, 2015 at 8:31 PM, Mullen, Patrick patrick.mul...@gwl.ca wrote: Try /CSQ1 STOP QMGR -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of zos reader Sent: Monday, June 01, 2015 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: MQ QMGR bringing down Hi All, I am trying to bring down the MQ QMGR and below are the running STC and i couldn't bring them down. I issued /CSQ1 STOP CSQMSTR and it doesn't work I have installed in Test system and brought up and all looks good and now i am trying bring down and i have brought down the CSQ1CHIN stc. CSQ1MSTR STC04693 CSQ1MSTR 15 EXECUTION SYS9 SYS9 CSQ1BTMN STC04714 CSQ1BTM15 EXECUTION SYS9 SYS9 Kindly guide me. Samat BM-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: intermittant abends
My sandbox LPAR is not having the abends. They are occurring on a D/R LPAR. The plot thickens. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Norgauer Sent: Tuesday, June 02, 2015 12:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends I'll check it out with IBM Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim McAlpine Sent: Tuesday, June 02, 2015 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: intermittant abends Could oa42694 be the cause ? Jim McAlpine On 2 Jun 2015 19:17, John Norgauer jcnorga...@ucdavis.edu wrote: We are close to turning on 2.1 z/os on in our production LPAR. We are getting sporadic abends of this kind: IEC999I IFG0554P,SYSJCNTE,S1 IEA995I SYMPTOM DUMP OUTPUT 688 SYSTEM COMPLETION CODE=0C4 REASON CODE=0011 It appears when I display user info from RACF. When I ran a terse batch job, it appeared. I sent a dump to IBM and have not heard back so that's why I posted to the list. Any thoughts from the list? -- 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: New Line vs. Line Feed
On Tue, 2 Jun 2015 03:17:35 -0500, Paul Gilmartin wrote:
On Mon, 1 Jun 2015 22:18:20 -0500, Bill Godfrey wrote:
The grep and awk commands don't match \n to end-of-line on omvs, or on
linux for that matter.
awk certainly does. To wit:
user@OS/390.24.00: cat awknl
#! /bin/sh -x
awk 'BEGIN {
String = First line\nSecond line.\n
# Show that \n is a line end.
printf( %s, String )
# show that \n matches line end.
print( match( String, \n ) )
}'
user@OS/390.24.00: sh awknl
First line
Second line.
11
user@OS/390.24.00:
I was only referring to \n in the pattern used in awk's general pattern
{action} syntax, where the pattern
is matched against text being read. I should have qualified my statement.
It's important to note that in your awk example and my Perl example
the \n is not being treated as an anchor in the regex pattern, like $ would be.
You could change \n to \n$ in the last print statement, and the result
would be 24 instead of 11.
I'm sure you know all of this already. I'm just mentioning it for anyone who
might not.
Bill
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
Ed Finnell wrote: Just as the bigwigs due to show up the 'Change toner bag' light came on and he scurried out to the van and got the replacement-still time. Got the bag swapped just as the tour was beginning so is tripping across the raised floor to the recycle exchange and stumps his toe on the floor seams. The toner bags were like 18x18x48 and said when it hit the floor TNF spewed out like a volcano. 18x18x48 - do you mean the size of the bag? What is 'TNF'? - Acronym Police said amongst a lot of things this jewel - 'That's Not Funny.' (from http://www.acronymfinder.com) Now, my question - those bags - are they not in a sturdy wood or carton box? Or from what were they made of? The hazmat crew spent 2 days decontaminating the room. No static electricity problems? 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: AW: Re: JES2 Exit 23
We had a room full of 3800's in early 80's guess they were Line mode. But DCF had a DEV(3800) and it was used extensively. Guess the big push was to the Kyocera engines with the 3835. Don't think I did a PSF install until late '86. The 3835 demo team was at SHARE and guess it was the Sunday tour. Really impressive. Think they were driving it with a POWER PC of some flavor. The Demo CE said he was still recovering from the rollout. Just as the bigwigs due to show up the 'Change toner bag' light came on and he scurried out to the van and got the replacement-still time. Got the bag swapped just as the tour was beginning so is tripping across the raised floor to the recycle exchange and stumps his toe on the floor seams. The toner bags were like 18x18x48 and said when it hit the floor TNF spewed out like a volcano. The hazmat crew spent 2 days decontaminating the room. In a message dated 6/2/2015 6:18:01 A.M. Central Daylight Time, ee...@us.ibm.com writes: PSF V1 (5665-275) was made available just in time for Christmas in 1984 (21 December). 1.1 came out in 1985, 1.2 in 1988, and 1.3 in 1989. PSF V1 was withdrawn from service in 1992, having been supplanted by PSF V2. PSF V1 ran on MVS on 168s and 158s, and later processors (43xx) when originally announced. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New CSS in HCD
W dniu 2015-06-02 o 00:49, Neubert, Kevin pisze: Sounds like your channels are not currently defined as spanned. If that is the case, add the new partition then change the channel mode. Subsequent prompts for HCS7780 are Define Access List panel CBDPCH1B and Confirm Copy Control Unit and Device Attachments panel CBDPUT48. Related help panel for the latter is CBDY6B22. Yes, my channels weren't SPANned and couldn't be SPANned, because HCD convert channel definition to SHR everytime you try to use SPAN with no LPARs from other CSS. BTW: I solved my problem by changing all channel definitions, piece by piece. It also prompts for CU connection to new CSS. BTW: I discovered an error in HCD. Example: CU 1000 is connected to MYCPC.0 using chpids: 44.0503 72.0522 4E.0302 68.0322 0D 11 31 35 After the change I got MYCPC.1 connected: 44.0503 72.0522 4E.0302 68.0322 0D.00 11 .00 31 .00 35.00 Note, the direct connection definitions are crippled. I had to delete them and define back. Regards -- Radoslaw Skorupka Lodz, Poland P.S. Thank you to all who responded. I appreciate it. -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CA-7 question
On Sun, 31 May 2015 20:54:35 -0400, Rajesh Kumar herowith.z...@gmail.com wrote: if jobs are demand , you can see entry mode of job isDEMD .. not REQ ; Also if job is demand to ca7 it will not waiting for time or date request , it will immediately start running. On Sun, May 31, 2015 at 5:53 PM, Lucas Rosalen rosalen.lu...@gmail.com wrote: Are you sure the other jobs are being added by SSCN? Maybe they have/had been demanded? Lucas On May 31, 2015 11:19 PM, Rajesh Kumar herowith.z...@gmail.com wrote: Hi Tony, I could see span value is *SPAN = 120 and INCREMENT = 60 from sscan* ; Span=120 is 2 hrs yearly, (span value must be less than increment) SPAN=- CHANGES NUMBER OF HOURS SCHEDULE SCAN IS TO LOOK FORWARD, DURING EACH WAKE-UP, FOR JOBS THAT MUST BE ADDED TO THE QUEUES. VALUE MUST BE A NUMBER OF HOURS FROM 1 TO 24. SPAN VALUE MUST NOT BE LESS THAN THE INCR VALUE. Hope now you understood yearly showing of job now Regards, Rajesh On Sun, May 31, 2015 at 4:06 PM, Tony Thigpen t...@vse2pdf.com wrote: I was hoping someone was watching the list today that could help me get over the hump on this one. I know there is some pattern, but it's just not clicking. Some jobs seem to jump in several hours early, while other jump in only 30 minutes before their time. Tony Thigpen Lizette Koehler wrote on 05/31/2015 04:06 PM: I might recommend that, if you have not done so, join the CA Community for CA7. Or open a case with CA. You may get a much faster response. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU ] On Behalf Of Tony Thigpen Sent: Sunday, May 31, 2015 12:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CA-7 question I am trying to better understand why jobs show up in the REQ when the show up. For example, I have a job with the following: ID=003 ROLL=D INDEX=+000 SCAL=DOTM=1640 LEADTM=0010 SUBTM=1630 STARTM=1630 WEEKLYDAY=SUN And it already in the queue two hours early: LQ,SEQ=JOB XXX REQ 0823 151/1630 151/1630 151/1640 ALL- 003 SSCN 001 SLIF-00 REQUEST COMPLETED AT 14:44:59 ON 15.151 Yet, other jobs don't seem to appear until almost the time they need to run. I think it has to do with the SSCAN values, but nothing seems to be making sense at this point: SSCAN CURRENT SCHEDULE SCAN VALUES SPAN = 120 INCREMENT = 60 QUEUE DWELL = 30 SKELETON RETRY = 0 REPROMPT= 10 LEAD TIME = 0 STATUS: REQQ IS ACTIVE ABR MSGS = NO RDYQ IS ACTIVE HOLD JOBS = NO NEXT SCAN WAKE-UP = 15151 AT 1517 NEXT SCAN PERIOD START TIME = 15151 AT 1647 -- Tony Thigpen Check with your CA-7 SYSADMIN - your site will have a GDG-managed CA-7 event-log file setup to address the question about how/when a job might process through the CA-7 system. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
edgould1...@comcast.net (Ed Gould) wrote: snip PSF didn't become available about the 1992 (or there abouts). As I installed PSF in the 1980's, when APA print was fairly new, I was surprised enough by this statement to look it up. PSF V1 (5665-275) was made available just in time for Christmas in 1984 (21 December). 1.1 came out in 1985, 1.2 in 1988, and 1.3 in 1989. PSF V1 was withdrawn from service in 1992, having been supplanted by PSF V2. PSF V1 ran on MVS on 168s and 158s, and later processors (43xx) when originally announced. The current release, available since about this time last year, is PSF V4.5 (5655-M32). Incidentally, PSF's SMF6 records have more content these days, some of which was added to make SMF-based accounting easier. Also, PSF 4.5 can be installed separately in its own SMP/E zones (it used to be necessary to install it in the z/OS zones) and it supports enable/disable via IFAPRDxx. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
John Eells wrote: The current release, available since about this time last year, is PSF V4.5 (5655-M32). Indeed. See the below URL for more info + lifecycle of PSF. http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=ddsubtype=smhtmlfid=897/ENUS5655-M32 Watch that wrrap of above URL. Also, PSF 4.5 can be installed separately in its own SMP/E zones (it used to be necessary to install it in the z/OS zones) Hmmm. Interesting. I believe it will make the life of SMP/E diehards easier... ;-) 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: New Line vs. Line Feed
On Tue, 2 Jun 2015 05:48:31 -0500, Bill Godfrey wrote:
I was only referring to \n in the pattern used in awk's general pattern
{action} syntax, where the pattern
is matched against text being read. I should have qualified my statement.
This is a characteristic not of awk's pattern matching but of awk's input
processing. Awk discards the delimiting \n like gets() rather than
retaining it like fgets().
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Notify for XMIT
Think it is time to change subject lines for this topic drift? On 06/02/2015 08:49 AM, Joel Ewing wrote: On 06/01/2015 07:23 PM, Shmuel Metz (Seymour J.) wrote: In 556b662e.60...@acm.org, on 05/31/2015 at 02:51 PM, Joel Ewing jcew...@acm.org said: The above CLIST code should presumably work as you expect for intercepting SEND CLIST errors in an Interactive TSO/E, ISPF environment where TSO is invoked via a TSO logon PROC as IKJEFT01 and not as IKJEFT1A or IKJEFT1B. AFAIK all of IKJEFT01, IKJEFT1A and IKJEFT1B have the same task structure.. That may well be, but according to IBM and TSO documentation the behavior of IKJEFT1A/IKJEFT1B is by design slightly different, specifically for TSO commands that give a non-zero return code that are running directly under the TMP; and their definition of directly in this context includes TSO commands executed within a CLIST that is directly invoked under the TMP. It doesn't have to be a difference in TCB structure that makes this behavior of IKJEFT01 vs. IKJEFT1A/IKJEFT1B different, but if you avoid executing the commands directly under the TMP --e.g., by executing them from within a REXX EXEC -- you can circumvent that behavioral difference. I think one adds a TCB by invoking a REXX EXEC, but probably more significantly it's no longer the TMP that sees the TSO Command return code for commands within the EXEC. The interpretation of whether a non-zero return code is or is not a fatal error is solely at the discretion of the calling program, and IKJEFT1A/IKJEFT1B appear to be designed to regard any non-zero return code they see as fatal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Notify for XMIT
On 06/01/2015 07:23 PM, Shmuel Metz (Seymour J.) wrote: In 556b662e.60...@acm.org, on 05/31/2015 at 02:51 PM, Joel Ewing jcew...@acm.org said: The above CLIST code should presumably work as you expect for intercepting SEND CLIST errors in an Interactive TSO/E, ISPF environment where TSO is invoked via a TSO logon PROC as IKJEFT01 and not as IKJEFT1A or IKJEFT1B. AFAIK all of IKJEFT01, IKJEFT1A and IKJEFT1B have the same task structure.. That may well be, but according to IBM and TSO documentation the behavior of IKJEFT1A/IKJEFT1B is by design slightly different, specifically for TSO commands that give a non-zero return code that are running directly under the TMP; and their definition of directly in this context includes TSO commands executed within a CLIST that is directly invoked under the TMP. It doesn't have to be a difference in TCB structure that makes this behavior of IKJEFT01 vs. IKJEFT1A/IKJEFT1B different, but if you avoid executing the commands directly under the TMP --e.g., by executing them from within a REXX EXEC -- you can circumvent that behavioral difference. I think one adds a TCB by invoking a REXX EXEC, but probably more significantly it's no longer the TMP that sees the TSO Command return code for commands within the EXEC. The interpretation of whether a non-zero return code is or is not a fatal error is solely at the discretion of the calling program, and IKJEFT1A/IKJEFT1B appear to be designed to regard any non-zero return code they see as fatal. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Notify for XMIT
On Tue, 2 Jun 2015 07:49:47 -0500, Joel Ewing wrote: It doesn't have to be a difference in TCB structure that makes this behavior of IKJEFT01 vs. IKJEFT1A/IKJEFT1B different, but if you avoid executing the commands directly under the TMP --e.g., by executing them from within a REXX EXEC -- you can circumvent that behavioral difference. I think one adds a TCB by invoking a REXX EXEC, but probably more significantly it's no longer the TMP that sees the TSO Command return code for commands within the EXEC. The interpretation of whether a non-zero return code is or is not a fatal error is solely at the discretion of the calling program, and IKJEFT1A/IKJEFT1B appear to be designed to regard any non-zero return code they see as fatal. I consider it a design shortcoming that an EXEC can't set the return code for the IKJEFT01 step. If it were supported, this could be as simple as: address TSO 'LOGOFF' code ... causing the job step to complete with code in R15. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
On Tue, 2 Jun 2015 07:47:58 -0400, Ed Finnell wrote: The toner bags were like 18x18x48 and said when it hit the floor TNF spewed out like a volcano. The hazmat crew spent 2 days decontaminating the room. Dammit, Ed stoppit. I'm trying to concentrate on watching a soccer game with a glass of red in front of a fire . These stories should be playing in a bar, not a list ... ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OMVS command history
(Re: AW: Re: AW: Re: AW: trimmed.) On Tue, 2 Jun 2015 17:48:13 +0200, Peter Hunkeler wrote: Well, as I wrote, the OMVS command processor There's more to OMVS than just the shell. The phrase but OMVS has no access clearly refers to more than the shell. Not sure what you're referring to, but I was talking about the OMVS *TSO command processor*, only. And no, that statement you cited does neither refer to a shell nor to anything more than what I wrote: The OMVS TSO Command processor has not been programmed to read/write/care for any command history file any UNIX shell program might use. In 3270 TSO OMVS, I can use the escape character (default is ¢) to enter control codes. So, with set -o vi, I can do ¢[kENTER to execute the fifth previous command. Unfortunately, it executes the command immediately, rather than just fetching it to the input area for modification before execution. I'm calling this a bug; IBM probably thinks it's WAD. (PF10 (Refresh) doesn't help.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEB814I IEBUPDTE puzzle
From the JCL Reference manual:DISP=OLD MEANS that the dataset must already exist. DISP=MOD means that if the dataset does not exist, create it - no JCL error. I Regards, Jim On Tue, Jun 2, 2015 at 11:59 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: I have JCL excerpt: //* ... //DEL EXEC PGM=IEFBR14 //HANDLEDD DISP=(MOD,DELETE),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* //SPLITIT EXEC PGM=IEBUPDTE,PARM=NEW //SYSPRINT DD SYSOUT=(,) //SYSIN DD DISP=OLD,DSN=*.INSERT.OUTPUT //HANDLEDD DISP=(MOD,CATLG),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //SYSUT2DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE // ... which fails with SYSPRINT: 1 SYSINNEW MASTER IEBUPDTE LOG PAGE 0001 - ./ ADD NAME= //MVSMODS1 JOB 527TEC000S0003,TEC,CLASS=8,MSGCLASS=5,PRTY=10, DOC FILE IEB814I DDNAME SYSUT2 CANNOT BE OPENED. IEB818I HIGHEST CONDITION CODE WAS 0012 IEB819I END OF JOB IEBUPDTE. However: //* ... //DEL EXEC PGM=IEFBR14 //HANDLEDD DISP=(MOD,DELETE),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* //SPLITIT EXEC PGM=IEBUPDTE,PARM=NEW //SYSPRINT DD SYSOUT=(,) //SYSIN DD DISP=OLD,DSN=*.INSERT.OUTPUT //SYSUT2DD DISP=(MOD,CATLG),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* SUT2DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE // ... succeeds and creates the expected few hundred members in SYSUT2. What makes the difference? Is DISP=OLD incompatible with PARM=NEW? But DISP=MOD is OK, but in either case the data set is allocated before IEBUPDTE is entered. Enlighten me? I've used the referback trick before, but only on DSORG=PS, in order to eliminate the (MOD,DELETE) setup step. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: AW: Re: AW: Re: OMVS command history
Well, as I wrote, the OMVS command processor There's more to OMVS than just the shell. The phrase but OMVS has no access clearly refers to more than the shell. Not sure what you're referring to, but I was talking about the OMVS *TSO command processor*, only. And no, that statement you cited does neither refer to a shell nor to anything more than what I wrote: The OMVS TSO Command processor has not been programmed to read/write/care for any command history file any UNIX shell program might use. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
John, Thanks, I am surprised. Going back to conversations I had with PSF level 2, 1. They were surprised at my calling back almost daily on bugs. 2. They seem to indicate this was all new code. They were fairly good at finding the bugs (thank goodness). Ed On Jun 2, 2015, at 6:17 AM, John Eells wrote: edgould1...@comcast.net (Ed Gould) wrote: snip PSF didn't become available about the 1992 (or there abouts). As I installed PSF in the 1980's, when APA print was fairly new, I was surprised enough by this statement to look it up. PSF V1 (5665-275) was made available just in time for Christmas in 1984 (21 December). 1.1 came out in 1985, 1.2 in 1988, and 1.3 in 1989. PSF V1 was withdrawn from service in 1992, having been supplanted by PSF V2. PSF V1 ran on MVS on 168s and 158s, and later processors (43xx) when originally announced. The current release, available since about this time last year, is PSF V4.5 (5655-M32). Incidentally, PSF's SMF6 records have more content these days, some of which was added to make SMF-based accounting easier. Also, PSF 4.5 can be installed separately in its own SMP/E zones (it used to be necessary to install it in the z/OS zones) and it supports enable/disable via IFAPRDxx. -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Cache Fast Write (CFW) - Data in the CFW is *not* mirrored, is it?
Where's Ron when we need him ?. Yep, but what does this help me? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEB814I IEBUPDTE puzzle
I have JCL excerpt: //* ... //DEL EXEC PGM=IEFBR14 //HANDLEDD DISP=(MOD,DELETE),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* //SPLITIT EXEC PGM=IEBUPDTE,PARM=NEW //SYSPRINT DD SYSOUT=(,) //SYSIN DD DISP=OLD,DSN=*.INSERT.OUTPUT //HANDLEDD DISP=(MOD,CATLG),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //SYSUT2DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE // ... which fails with SYSPRINT: 1 SYSINNEW MASTER IEBUPDTE LOG PAGE 0001 - ./ ADD NAME= //MVSMODS1 JOB 527TEC000S0003,TEC,CLASS=8,MSGCLASS=5,PRTY=10, DOC FILE IEB814I DDNAME SYSUT2 CANNOT BE OPENED. IEB818I HIGHEST CONDITION CODE WAS 0012 IEB819I END OF JOB IEBUPDTE. However: //* ... //DEL EXEC PGM=IEFBR14 //HANDLEDD DISP=(MOD,DELETE),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* //SPLITIT EXEC PGM=IEBUPDTE,PARM=NEW //SYSPRINT DD SYSOUT=(,) //SYSIN DD DISP=OLD,DSN=*.INSERT.OUTPUT //SYSUT2DD DISP=(MOD,CATLG),UNIT=SYSALLDA, // DSN=PFX..CBTINDEX, // SPACE=(80,(,,1)),DSNTYPE=LIBRARY //* SUT2DD DISP=OLD,DSN=*.HANDLE,VOL=REF=*.HANDLE // ... succeeds and creates the expected few hundred members in SYSUT2. What makes the difference? Is DISP=OLD incompatible with PARM=NEW? But DISP=MOD is OK, but in either case the data set is allocated before IEBUPDTE is entered. Enlighten me? I've used the referback trick before, but only on DSORG=PS, in order to eliminate the (MOD,DELETE) setup step. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: JES2 Exit 23
Yep size of bag. They were made of soft sided quilts and were recycled to pull out the toner. TNF is short for chemical composition Tri-nitro flouride(?). It was powdered on 3835 on 3800 it was pellets and there was a grinder to make the powder. In a message dated 6/2/2015 7:01:24 A.M. Central Daylight Time, elardus.engelbre...@sita.co.za writes: 18x18x48 - do you mean the size of the bag? What is 'TNF'? - Acronym Police said amongst a lot of things this jewel - 'That's Not Funny.' (from http://www.acronymfinder.com) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where can a running TSO program get its terminal name
For some reason, which I can't make work Shmuel believes the In 000701d09bd1$1872a0e0$4957e2a0$@mcn.org, on 05/31/2015 He always includes is of value. Where this link may lead is not anywhere I can seem to get to :) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, June 01, 2015 4:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where can a running TSO program get its terminal name In 000701d09bd1$1872a0e0$4957e2a0$@mcn.org, on 05/31/2015 at 11:39 AM, Charles Mills charl...@mcn.org said: The master of the out-of-context quote. Not even close; the context was clearly IEABRCX. By all means use it blindly; it's not my dog. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see https://urldefense.proofpoint.com/v1/url?u=http://patriot.net/~shmuel/resu me/brief.htmlk=EWEYHnIvm0nsSxnW5y9VIw%3D%3D%0Ar=j6Xa1Y0fbuP2 mfgCQ5Zxhg%3D%3D%0Am=7SKyCkAfJ67LTYAs%2Fp0A661K9Gktd1tGjWsHJ Kdg3gw%3D%0As=7ca3515d0428275e42f8a293fc866b35f3d11efa4ac80944f 4d3a132e9063bf7 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
