SMS dataset oddity with COM-Plete

[Brian Westerman]

Hi,

One of our customers is running an old(er) version of Software AG's Com-Plete 
(version 6.4.1) along with testing version 6.8.1, and we have found that when a 
dataset (any sequential or PDS) is moved from a regular 3390-3 to a 3390-3 that 
is part of a storage group (same raid box, and close to the same address (in 
this case the non-SMS volume is on x'0309', and the SMS pool starts at 
x'0310'), they get an S0C1 when they try to edit or browse that dataset from 
within Com-Plete, but when we move it back to any non-SMS 3390-3 (or even a 
3390-9 or 3390-27) it can be accessed with no problems at all.  The problem 
doesn't happen with com-plete 6.8.1, and Software AG is telling us 
simultaneously that a) there should be no difference in the edit component 
between the two releases, and b) they no longer support 6.4.1 so they can't 
look into it, and even if they did, they would not be able provide a "fix" any 
more for that level.

The client is okay with not moving the datasets to SMS until after the new 
version of Com-Plete is in production (currently not planned until January 
2019), but it bothers me that this is happening and I have no explanation for 
it.  It's also throwing a wrench into my SMS conversion for them.  I have a 
"feeling" that it has something to do with the control blocks that are built in 
a different place for SMS datasets and non-SMS datasets, but since SMS has been 
around since Com-Plete 6.1.1  (8 years before 6.4.1), there appears to be no 
logical reason why it should fail just because the dataset is on an SMS volume.

Does anyone have any ideas on how to address this?

Brian

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

Re: PR/SM LPAR Controls Change Running System

[Jesse 1 Robinson]

In many/most?/all? of the HMC LPAR controls, you have three options: only 
change running system, only save changes to activation profile, or do both. The 
LPAR (Image) profile comes into play any time the LPAR is activated, which 
includes POR. Unless the profile has been updated one way or another, dynamic 
'running system' changes will be lost on the next activation. 

IPL itself with or without the LOAD profile does not cause LPAR activation 
unless the LPAR has been previously deactivated. That is, IPLing a 'not 
activated' LPAR entails first activation by Image profile followed by IPL with 
or without use of the LOAD profile. 

.
.
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 Leonardo Vaz
Sent: Friday, February 16, 2018 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: PR/SM LPAR Controls Change Running System

In my understanding both pages are correct, you lose the changes after a POR, 
you also lose the changes if you activate the partition.

When you IPL by Activate you use the activation profile settings.

You can IPL with the Load command to not re-activate the LPAR and use the 
previous defined capacity.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Arentsen
Sent: Friday, February 16, 2018 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PR/SM LPAR Controls Change Running System

Hi List, 

I have a question about what we recently experienced when dealing with Defined 
Capacity changes. Say I have a production LPAR with a defined capacity of 100 
and a tech-only LPAR with 10. Management decides that we can afford an extra 2 
MSU, temporarily. So I enter Change LPAR Controls and change the production 
LPAR's Defined Capacity to 102 and a tech-only LPAR to 8. At this point, I 
click the Change Running System button to apply the change.

A few days later, the tech-only LPAR was re-IPL'd using a custom group with a 
load profile. The IPL was performed by selecting Activate. We notice at this 
point that the tech-only LPAR's Defined Capacity was set to 10. We promptly 
changed it back to 8.

Then, to test this situation again, I started with a baseline of
production=100 and tech-only=5.  I entered Change LPAR Controls again and 
changed the tech-only to 8 and again clicked on Change Running System. 
This time, when the IPL was performed via an activate, the LPAR came up with a 
defined capacity of 8.

I've found some conflicting documentation on the Google:

http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437=1
This page says that Change Running System changes are lost after a POR

http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d=1
This page says that it's lost after a reactivation of a partition

It seems that PR/SM selects the highest Defined Capacity between the Running 
System and what's saved in the Activation profile for the LPAR. 
Can anyone shed some light as to how PR/SM actually works?

Andrew Arentsen
Senior Mainframe Systems Engineer
Phone: 800.242.7666 x1349


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

Re: PR/SM LPAR Controls Change Running System

[Leonardo Vaz]

In my understanding both pages are correct, you lose the changes after a POR, 
you also lose the changes if you activate the partition.

When you IPL by Activate you use the activation profile settings.

You can IPL with the Load command to not re-activate the LPAR and use the 
previous defined capacity.

Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Arentsen
Sent: Friday, February 16, 2018 12:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PR/SM LPAR Controls Change Running System

Hi List, 

I have a question about what we recently experienced when dealing with Defined 
Capacity changes. Say I have a production LPAR with a defined capacity of 100 
and a tech-only LPAR with 10. Management decides that we can afford an extra 2 
MSU, temporarily. So I enter Change LPAR Controls and change the production 
LPAR's Defined Capacity to 102 and a tech-only LPAR to 8. At this point, I 
click the Change Running System button to apply the change.

A few days later, the tech-only LPAR was re-IPL'd using a custom group with a 
load profile. The IPL was performed by selecting Activate. We notice at this 
point that the tech-only LPAR's Defined Capacity was set to 10. We promptly 
changed it back to 8.

Then, to test this situation again, I started with a baseline of
production=100 and tech-only=5.  I entered Change LPAR Controls again and 
changed the tech-only to 8 and again clicked on Change Running System. 
This time, when the IPL was performed via an activate, the LPAR came up with a 
defined capacity of 8.

I've found some conflicting documentation on the Google:

http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437=1
This page says that Change Running System changes are lost after a POR

http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d=1
This page says that it's lost after a reactivation of a partition

It seems that PR/SM selects the highest Defined Capacity between the Running 
System and what's saved in the Activation profile for the LPAR. 
Can anyone shed some light as to how PR/SM actually works?

Andrew Arentsen
Senior Mainframe Systems Engineer
Phone: 800.242.7666 x1349

**
This e-mail is confidential. If you are not the intended recipient, you must 
not disclose or use the information contained in it. If you have received this 
e-mail in error, please tell us immediately by return e-mail and delete the 
document.

--
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 for COBOL users

[Paul Gilmartin]

On Fri, 16 Feb 2018 11:13:05 -0800, Tom Ross wrote:
>
>In response to other posts and Frank, I agree that we should answer the
>RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD"
>
Yaaay!

Now you may have to deal with, "But that's not the way we planned to do it."

If PARMDD refers to a SYSIN it supports symbol substitution (almost) like
EXEC PARM=.  There are a few annoying differences.

Of course, PARMDD may be a concatenation of library option members (like
SYSOPTF).  And someone suggested using DDNAME= for more flexibility
(again, like SYSOPTF).

-- gil

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

Re: Question for COBOL users

[Tom Ross]

>FWIW, I am guessing "255" was simply a brain-glitch for 100, and had no
>basis in any actual technology.

Charles, you nailed my brain fart exactly!

In response to other posts and Frank, I agree that we should answer the
RFE for a change to our SYSOPTF support as: "AVAILABLE: Use PARMDD"

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

IBM Debug tool issue

[Tom Ross]

>When using Debug Tool under CICS, every time a CALL statement is encountere=
>d the debugger steps into the called program.
>Is there a way to just have the called program called and not show its inte=
>rnal workings.
>
>We are using Debug Tool v14.1, z/OS v2.2, COBOL v6 and CICS TS v5.4.

I think what you want is STEP OVER, not STEP INTO in Debug Tool

Cheers,
TomR  >> COBOL is the Language of the Future! <<

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

PR/SM LPAR Controls Change Running System

[Andrew Arentsen]

Hi List, 

I have a question about what we recently experienced when dealing with 
Defined Capacity changes. Say I have a production LPAR with a defined 
capacity of 100 and a tech-only LPAR with 10. Management decides that we 
can afford an extra 2 MSU, temporarily. So I enter Change LPAR Controls 
and change the production LPAR's Defined Capacity to 102 and a tech-only 
LPAR to 8. At this point, I click the Change Running System button to 
apply the change.

A few days later, the tech-only LPAR was re-IPL'd using a custom group 
with a load profile. The IPL was performed by selecting Activate. We 
notice at this point that the tech-only LPAR's Defined Capacity was set to 
10. We promptly changed it back to 8.

Then, to test this situation again, I started with a baseline of 
production=100 and tech-only=5.  I entered Change LPAR Controls again and 
changed the tech-only to 8 and again clicked on Change Running System. 
This time, when the IPL was performed via an activate, the LPAR came up 
with a defined capacity of 8.

I've found some conflicting documentation on the Google:

http://www-01.ibm.com/support/docview.wss?uid=tss1wp102437=1
This page says that Change Running System changes are lost after a POR

http://www-01.ibm.com/support/docview.wss?uid=isg209611e17c3b8d419852573f700645d4d=1
This page says that it's lost after a reactivation of a partition

It seems that PR/SM selects the highest Defined Capacity between the 
Running System and what's saved in the Activation profile for the LPAR. 
Can anyone shed some light as to how PR/SM actually works?

Andrew Arentsen
Senior Mainframe Systems Engineer
Phone: 800.242.7666 x1349

**
This e-mail is confidential. If you are not the intended recipient, you must 
not disclose or use the information contained in it. If you have received this 
e-mail in error, please tell us immediately by return e-mail and delete the 
document.

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

Re: Parmlib members change control?

[Bobbie Justice]

Good lord no. 

I'm reminded that somehow ("magically I guess"), we all managed to survive the 
60s, 70s, 80s, and even the early 90s without this formal change control 
nonsense. 

If you must track, then the product from action software works. 

Otherwise no, just no, easy solution below.

current parm/proclib member - current name 
backout parm/proclib member - with a $ suffix at the end (if you want one more 
backlevel, then use a # as the suffix)

Implementation and backout plans work wonders and have been way before formal 
change management was ever devised.

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

Re: Question: Users of Pacific Systems Group -- Vendor

[Sasso, Leonard]

Our Systems Development tested the ZWESASY Product as a “front-end” to 
CA-Easytrieve (we migrated away from CA Products).

They were satisfied and we have been using it in Production for about three 
months.

My only issue with it is it does not use Easytrieve Macros.


Thank You,
Len Sasso
System Administrator
Out-Of-The-Office:
TEAM: Together Everyone Achieves More

RDC - 327 Columbia TPKE, Rensselaer NY 12144-4400
t: +1.518.257.4209 | m: +1.518.894.0879
len.sa...@csra.com | www.csra.com Follow us on Facebook | Twitter | LinkedIn
CSRA
Think Next. Now.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of PINION, RICHARD W.
Sent: Friday, February 16, 2018 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question: Users of Pacific Systems Group -- Vendor

We trialed their other product SMF Writer.  I liked the product.  
Unfortunately, upper management didn't want to spend the money to acquire the 
product.  In comparison to what we recently spent on hardware upgrades, that 
cost was insignificant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Friday, February 16, 2018 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question: Users of Pacific Systems Group -- Vendor

[External Email]

I'm looking for users of Pacific Systems Group software, in particular z-Writer 
and its "front-ends" for other products, specifically ZWQUIK and ZWEASY.

I'd like to know how well these work for you and how Pacific Systems Group is 
as a vendor.

Regards,
Steve Thompson

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

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

This electronic message transmission contains information from CSRA that may be 
attorney-client privileged, proprietary or confidential. The information in 
this message is intended only for use by the individual(s) to whom it is 
addressed. If you believe you have received this message in error, please 
contact me immediately and be aware that any use, disclosure, copying or 
distribution of the contents of this message is strictly prohibited. NOTE: 
Regardless of content, this email shall not operate to bind CSRA to any order 
or other contract unless pursuant to explicit written agreement or government 
initiative expressly permitting the use of email for such purpose.

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

Re: J line command was: TSO temp dataset

[Pommier, Rex]

Thanks, Kolusu!

That was it.  I haven't thought about PACK for so long that it never crossed my 
mind.  I thought I had PACK OFF in everything because I've seen it cause issues 
in the past.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Sri h Kolusu
Sent: Thursday, February 15, 2018 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: J line command was: TSO temp dataset

Pommier Rex,

Check if you have PACK ON in your Profile.

I can replicate your JCL error if the member has PACK ON and I get a JCL
error.

TYPE PACK OFF while editing the member and save it then try the J command

Thanks,
Kolusu

IBM Mainframe Discussion List  wrote on
02/15/2018 03:39:41 PM:

> From: "Pommier, Rex" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 02/15/2018 03:40 PM
> Subject: J line command was: TSO temp dataset
> Sent by: IBM Mainframe Discussion List 
>
> Subject change due to topic drift.
>
> I don't know what I'm doing wrong.  z/OS 2.2.  My PDS member looks like
this:
>
>

> EDIT   RRP.JCL(I) - 01.04
Columns
> Command ===>
Scro
> ** * Top of Data
*
> 01 //RRPB JOB (040423,495),RRP,CLASS=T,MSGCLASS=X,MSGLEVEL=(1,1),

> 02 // NOTIFY=

> 03 //STEP001 EXEC PGM=IEFBR14

>
> Backing out to the member list:
>
> DSLISTRRP.JCL
> Command ===>
>Name Prompt   Size   Created
> j I 3  2018/02/15
>
>
> when I hit enter, I get this:
>
> IKJ56700A ENTER JOBNAME CHARACTER(S) -
>
>
> And I put in a random character (like Z) and get this:
>
> IKJ56250I JOB RRPZ(JOB02979) SUBMITTED
> 16.35.54 JOB02979 $HASP165 RRPZ ENDED AT MVSJES2 - JCL ERROR CN
> (INTERNAL)
>
> And my output looks like this:
>
> J E S 2  J O B  L O G  --  S Y S T E M  Z O S 1
> --  N O D E  M V S J E S 2
>

> 16.35.54 JOB02979  THURSDAY,  15 FEB 2018 

> 16.35.54 JOB02979  IRR010I  USERID RRP  IS ASSIGNED TO THIS JOB.

> 16.35.54 JOB02979  IEFC452I RRPZ - JOB NOT RUN - JCL ERROR  478

> -- JES2 JOB STATISTICS --

> 6 CARDS READ

>20 SYSOUT PRINT RECORDS

> 0 SYSOUT PUNCH RECORDS

> 1 SYSOUT SPOOL KBYTES

>  0.00 MINUTES EXECUTION TIME

> FILE>RRP.RRPZ.JOB02979.D003.JESJCL,2018.046,16:
> 36:03:211 //RRPZ  JOB 3331,
> JOB02979
>   // RRP,   **JOB STATEMENT GENERATED BY
> SUBMIT**
>   // NOTIFY=RRP,

>   // MSGLEVEL=(1,1)

> 2 //SYSIN DD *   GENERATED STATEMENT

> FILE>   RRP.RRPZ.JOB02979.D004.JESYSMSG,2018.046,16:
> 36:03:21STMT NO. MESSAGE

> 2 IEFC019I MISPLACED DD STATEMENT

> 2 IEFC607I JOB HAS NO STEPS

>
>
> I have no idea what it's submitting besides nothing, but it
> definitely isn't what I put a "J" in front of.  Ideas?
>
> Rex
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU
> ] On Behalf Of Sri h Kolusu
> Sent: Thursday, February 15, 2018 3:36 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: TSO temp dataset
>
> >>Am I looking in the wrong place?
>
> Gil,
>
> You need to look in ISPF User's guide Vol 1 under the section "Library
and
> data set list utility line commands"
>
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/
> com.ibm.zos.v2r1.f54ug00/bdpr.htm
>
>
> Thanks,
> Kolusu
>
> 
>
> The information contained in this message is confidential, protected
> from disclosure and may be legally privileged.  If the reader of
> this message is not the intended recipient or an employee or agent
> responsible for delivering this message to the intended recipient,
> you are hereby notified that any disclosure, distribution, copying,
> or any action taken or action omitted in reliance on it, is strictly
> prohibited and may be unlawful.  If you have received this
> communication in error, please notify us immediately by replying to
> this message and destroy the material in its entirety, whether in
> electronic or hard copy format.  Thank you.
>
> --
> 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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are 

Re: small MPF exit question concerning 'sticky' console messages

[Tony Thigpen]

You are correct. Thanks.

Tony Thigpen

Vernooij, Kees (ITOPT1) - KLM wrote on 02/16/2018 08:42 AM:

I think your problem is not the message but the console. I suppose this is a 
WTOR and that is sticky. It only remains on the console if the console is in 
MODE=RD, not in MODE=R.

Kees.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Tony Thigpen
Sent: 16 February, 2018 14:37
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: small MPF exit question concerning 'sticky' console messages

The programmers have a Cobol program that uses:
DISPLAY OPR-MSG UPON CONSOLE.
DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL'
UPON CONSOLE.
MOVE SPACES TO OPR-RPL.
ACCEPT OPR-RPL FROM CONSOLE.

This shows up on the console as:
+OPERATOR ACTION: IGNORE, RETRY, CANCEL
   @15 IGZI AWAITING REPLY

Currently, we trap the "AWAITING REPLY" in the MPF list using:
IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX)
The exit causes an email to be sent. (And that works)

The outstanding issue is that the highlighted message rolls off the
console. They would like for it to be sticky and not roll off. (It  has
always rolled off, even before we used the MPF exit.)

Can this be done in the MPF exit? Somewhere else?

z/OS 1.13

Thanks,

--
Tony Thigpen

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


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
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: Users of Pacific Systems Group -- Vendor

[PINION, RICHARD W.]

We trialed their other product SMF Writer.  I liked the product.  
Unfortunately, upper management didn't want to spend the money to acquire the 
product.  In comparison to what we recently spent on hardware upgrades, that 
cost was insignificant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Thompson
Sent: Friday, February 16, 2018 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Question: Users of Pacific Systems Group -- Vendor

[External Email]

I'm looking for users of Pacific Systems Group software, in particular z-Writer 
and its "front-ends" for other products, specifically ZWQUIK and ZWEASY.

I'd like to know how well these work for you and how Pacific Systems Group is 
as a vendor.

Regards,
Steve Thompson

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Question: Users of Pacific Systems Group -- Vendor

[Steve Thompson]

I'm looking for users of Pacific Systems Group software, in 
particular z-Writer and its "front-ends" for other products, 
specifically ZWQUIK and ZWEASY.


I'd like to know how well these work for you and how Pacific 
Systems Group is as a vendor.


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: small MPF exit question concerning 'sticky' console messages

[Vernooij, Kees (ITOPT1) - KLM]

I think your problem is not the message but the console. I suppose this is a 
WTOR and that is sticky. It only remains on the console if the console is in 
MODE=RD, not in MODE=R.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Tony Thigpen
> Sent: 16 February, 2018 14:37
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: small MPF exit question concerning 'sticky' console messages
> 
> The programmers have a Cobol program that uses:
>DISPLAY OPR-MSG UPON CONSOLE.
>DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL'
>UPON CONSOLE.
>MOVE SPACES TO OPR-RPL.
>ACCEPT OPR-RPL FROM CONSOLE.
> 
> This shows up on the console as:
>+OPERATOR ACTION: IGNORE, RETRY, CANCEL
>   @15 IGZI AWAITING REPLY
> 
> Currently, we trap the "AWAITING REPLY" in the MPF list using:
> IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX)
> The exit causes an email to be sent. (And that works)
> 
> The outstanding issue is that the highlighted message rolls off the
> console. They would like for it to be sticky and not roll off. (It  has
> always rolled off, even before we used the MPF exit.)
> 
> Can this be done in the MPF exit? Somewhere else?
> 
> z/OS 1.13
> 
> Thanks,
> 
> --
> Tony Thigpen
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

small MPF exit question concerning 'sticky' console messages

[Tony Thigpen]

The programmers have a Cobol program that uses:
  DISPLAY OPR-MSG UPON CONSOLE.
  DISPLAY 'OPERATOR ACTION: IGNORE, RETRY, CANCEL'
  UPON CONSOLE.
  MOVE SPACES TO OPR-RPL.
  ACCEPT OPR-RPL FROM CONSOLE.

This shows up on the console as:
  +OPERATOR ACTION: IGNORE, RETRY, CANCEL
 @15 IGZI AWAITING REPLY

Currently, we trap the "AWAITING REPLY" in the MPF list using:
IGZI,RETAIN(YES),SUP(NO),USEREXIT(MPFTREXX)
The exit causes an email to be sent. (And that works)

The outstanding issue is that the highlighted message rolls off the 
console. They would like for it to be sticky and not roll off. (It  has 
always rolled off, even before we used the MPF exit.)


Can this be done in the MPF exit? Somewhere else?

z/OS 1.13

Thanks,

--
Tony Thigpen

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

Re: Parmlib members change control?

[Sean Gleann]

Thanks to all who have responded - it looks like we are going to at least
try the Git solution.


In all my past placements as a sysprog, 'change control' or something like
it has been part of the job, along with the associated 'royal pain' as
Seymour rightly describes it.

In this particular instance, I'm a 'team of one' looking after 2
mainframe-based z/OS's, and 3 more and a z/Linux running under z/VM on a
z-PDT rig.

Because I'm on my own, the idea of a formal, external change control system
has never come up before, but the powers that be are beginning to look over
their collective shoulder and recognising the fact that I am rapidly
approaching retirement age.

Strangely enough, having to start using a change control system again after
all this time almost has a sense of 'coming home' associated with it.



Sean


On 16 February 2018 at 01:06, Steve Horein  wrote:

> Years ago, I had the opportunity to work with NewEra's ImageFocus. Neat
> stuff to perform "virtual IPLs" (my description, not theirs), running the
> gauntlet based on loadparm and load address, checking syntax of members,
> verifying existence of data sets, etc.Like I say, neat stuff. Anyway, they
> were developing a new offering: Control Editor. If I recall from some of
> the presentations, it had the capability to enforce recording of change
> justification, and retain backup copies of members. I never personally used
> that offering - the company I worked for at the time stopped using the z
> platform as their system of record, and I had to find a new place to work.
> I had full intention of making use of it, had I the opportunity. That may
> be something to look into.
> http://www.newera-info.com/index.html
>
> --
> 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: TSO temp dataset

[Ron hawkins]

Elardus,

Thanks for the correction.

I had read your reply, but the thread at that stage sounded to me like zSECURE 
built the JCL, and then the OP manually submitted it.

I see that was incorrect, and we're just rehashing your original advice.

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: Thursday, February 15, 2018 10:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] TSO temp dataset

Ron Hawkins wrote:

>We're talking about the temp dataset that ISPF==>EDIT==>SUB command creates 
>before copying to INTRDR.

Correct, but actually, in this specific thread, it is about how the allocation 
is done by zSecure and how to fix it.

zSecure has its own version of Submit running REXX programs to do the 
allocations which I have described earlier in this thread.

The OP has asked on RACF-L how to delete 200 000 ids (yes, one fifth of 1 
million) and now asking space related question on IBM-MAIN.

That is a lot of ids and he got the advice to split that job in parts. Perhaps 
this is why he has trouble submitting his extrememly large jobs.

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

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