Re: Zowe for systems programmer ?

[Matt Hogstrom]

Merging is not magic.  Where I see the biggest risk is merging items like 
IEASYS00 or other critical members where a review is needed to ensure the 
system comes up versus I’ve merged code changes and are less likely to have an 
impact.  So, I agree with your statements below … not magic, but requires an 
adult for certain merges.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2018, at 8:20 PM, Andrew Rowley  
> wrote:
> 
> On 30/08/2018 12:16 AM, Jerry Callen wrote:
>> The whole idea of holding a lock on a file while a human being slowly edits 
>> it is so 1960s.
>> 
>> Since at least the mid 1970s, editors like emacs have loaded the file for 
>> editing and noted the timestamp. When the user attempts to save the file. 
>> the timestamp is checked again, and if it changed, the user is asked what to 
>> do.
> I always thought this was a result of being unable to effectively prevent 
> simultaneous edits, not a feature. The user is asked what to do - do you want 
> to throw away your changes or the other guy's changes? The answer is always 
> the other guy's changes, right?
>> And, of course, if you use a distributed source control system like git, 
>> handling merge conflicts is a built-in and normal part of the process.
> You can of course do this on z/OS if you want to.
> 
> I have been using source control for long enough that making any change 
> without source control feels like climbing without a rope. But merging isn't 
> magic.
> 
> Merging:
> 1) Gives you a version that has never been verified by a human. The people 
> who wrote the merge process assumed the person doing the merge will verify it 
> is correct. The people doing the merge far too often assume the merged 
> version is correct. Merging is OK for compiled code where the compiler does a 
> lot of verification. For something like SYS1.PARMLIB I'm not so sure.
> 2) Often you get versions that cannot be automatically merged. Sorting out 
> these issues can be a monumental mess. Particularly if one or both of the 
> merged versions were themselves the result of a merge, it can be difficult to 
> which conflicting pieces are required. In this situation you wish for the 
> simplicity of a single thread of sequential changes.
> 
> Merging is necessary and useful when you have multiple branches of 
> development. It's not a substitute for the prevention of simultaneous edits.
> 
> 
> -- 
> 
> Andrew Rowley
> Black Hill Software
> 
> --
> 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: Zowe for systems programmer ?

[Andrew Rowley]

On 30/08/2018 12:16 AM, Jerry Callen wrote:

The whole idea of holding a lock on a file while a human being slowly edits it 
is so 1960s.

Since at least the mid 1970s, editors like emacs have loaded the file for 
editing and noted the timestamp. When the user attempts to save the file. the 
timestamp is checked again, and if it changed, the user is asked what to do.
I always thought this was a result of being unable to effectively 
prevent simultaneous edits, not a feature. The user is asked what to do 
- do you want to throw away your changes or the other guy's changes? The 
answer is always the other guy's changes, right?

And, of course, if you use a distributed source control system like git, 
handling merge conflicts is a built-in and normal part of the process.

You can of course do this on z/OS if you want to.

I have been using source control for long enough that making any change 
without source control feels like climbing without a rope. But merging 
isn't magic.


Merging:
1) Gives you a version that has never been verified by a human. The 
people who wrote the merge process assumed the person doing the merge 
will verify it is correct. The people doing the merge far too often 
assume the merged version is correct. Merging is OK for compiled code 
where the compiler does a lot of verification. For something like 
SYS1.PARMLIB I'm not so sure.
2) Often you get versions that cannot be automatically merged. Sorting 
out these issues can be a monumental mess. Particularly if one or both 
of the merged versions were themselves the result of a merge, it can be 
difficult to which conflicting pieces are required. In this situation 
you wish for the simplicity of a single thread of sequential changes.


Merging is necessary and useful when you have multiple branches of 
development. It's not a substitute for the prevention of simultaneous edits.



--

Andrew Rowley
Black Hill Software

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

Re: z/OS network Speedtest

[Rob Schramm]

I have used ftp as well for speed approximations.  Having a clear picture
of your network layout will help.  Kevin's point is very real.

Rob Schramm

On Wed, Aug 29, 2018, 4:35 PM Kevin Mckenzie  wrote:

> > Is there anything for z/OS to measure upload/download speeds? Like on a
> PC
> > going to speedtest.net and running their test?
>
> From the z/OS LPAR to where?  What's the purpose of the measurement?  Can
> you prevent other network traffic from happening when you're doing the
> measurement?
>
> ---
> Kevin McKenzie
>
> External Phone: 845-435-8282, Tie-line: 8-295-8282
> z/OS Test Services - Test Architect, Provisioning
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Un-Sysplex a zOS System

[Rob Schramm]

My easy guesses

1) Prepping to sell off a business unit
2) separation dev/test from prod or some version of a compliance separation

Not so serious guess
3) manager subscribes to PHB (pointy hair boss) Magazine and thinks that 1
less system will make sysplex lighter

Out there.. maybe

4) some weird contractual agreement

Rob Schramm


On Wed, Aug 29, 2018, 6:15 PM Steve Smith  wrote:

> I don't claim the experience to understand *all* the ramifications, but
> Jerry's idea is the first thing that occurred to me.
>
> sas
>
>
> On 8/29/2018 17:34, Jerry Whitteridge wrote:
> > I agree with Skip - the risk in pulling apart a Sysplex is high, where to
> >
> > stand up a new stand-alone system will ensure the isolation required. I'd
> >
> > build a new system and move the work as needed to it.
> >
> >
> >
> > Jerry Whitteridge
> >
> > Delivery Manager / Mainframe Architect
> >
> > GTS - Safeway Account
> >
> > 602 527 4871 Mobile
> >
> > jerry.whitteri...@ibm.com
> >
> >
> >
> > IBM Services
> >
> >
> ...further snipped mainly because various email processing has turned it
> into garbage.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Un-Sysplex a zOS System

[Steve Smith]

I don't claim the experience to understand *all* the ramifications, but 
Jerry's idea is the first thing that occurred to me.


sas


On 8/29/2018 17:34, Jerry Whitteridge wrote:

I agree with Skip - the risk in pulling apart a Sysplex is high, where to

stand up a new stand-alone system will ensure the isolation required. I'd

build a new system and move the work as needed to it.



Jerry Whitteridge

Delivery Manager / Mainframe Architect

GTS - Safeway Account

602 527 4871 Mobile

jerry.whitteri...@ibm.com



IBM Services


...further snipped mainly because various email processing has turned it 
into garbage.


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

Re: Un-Sysplex a zOS System

[Jerry Whitteridge]

I agree with Skip - the risk in pulling apart a Sysplex is high, where to
stand up a new stand-alone system will ensure the isolation required. I'd
build a new system and move the work as needed to it.

Jerry Whitteridge
Delivery Manager / Mainframe Architect
GTS - Safeway Account
602 527 4871 Mobile
jerry.whitteri...@ibm.com

IBM Services

IBM Mainframe Discussion List  wrote on
08/29/2018 02:14:37 PM:

> From: Jesse 1 Robinson 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/29/2018 02:15 PM
> Subject: Re: Un-Sysplex a zOS System
> Sent by: IBM Mainframe Discussion List 
>
> The issues listed in the original post plus those suggested by
> others are potentially *very* serious. I have to ask what benefits
> are expected that would justify the risk. Surely sysplex overhead
> alone would not be worth damaging a catalog for example. Whose idea is
this?
>
> .
> .
> 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 Scott Barry
> Sent: Wednesday, August 29, 2018 1:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Un-Sysplex a zOS System
>
> On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv
>  wrote:
>
> >We're in a parallel sysplex, sharing most everything, and need to
> begin planning activities to remove one system from the sysplex,
> while continuing to use it to run a subset of our current workload.
> >
> >Some of the things we need to consider are;
> >
> >  *   PDS/e Sharing
> >  *   Catalogs (we're ECS shared now)
> >  *   Shared DASD
> >  *   RACF Database Sharing (Sysplex Enabled)
> >  *   JES2 Checkpoint in CF
> >  *   ZFS File Systems? (This system is not in a shared OMVS
Environment)
> >
> >I'd like people to shoot things at me that I might have missed
> while I keep on looking myself.
> >
> >TIA,
> >
> >Mark Jacobs
> >Time Customer Service
>
>
> Could be a consideration to review/verify - software (contractual
> language) licensing, also previous-condition with "shared" system
> dependency, then no longer accessible after un-Sysplex?
>
> 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

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

Re: Un-Sysplex a zOS System

[Jesse 1 Robinson]

The issues listed in the original post plus those suggested by others are 
potentially *very* serious. I have to ask what benefits are expected that would 
justify the risk. Surely sysplex overhead alone would not be worth damaging a 
catalog for example. Whose idea is this?

.
.
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 Scott Barry
Sent: Wednesday, August 29, 2018 1:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Un-Sysplex a zOS System

On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv 
 wrote:

>We're in a parallel sysplex, sharing most everything, and need to begin 
>planning activities to remove one system from the sysplex, while continuing to 
>use it to run a subset of our current workload.
>
>Some of the things we need to consider are;
>
>  *   PDS/e Sharing
>  *   Catalogs (we're ECS shared now)
>  *   Shared DASD
>  *   RACF Database Sharing (Sysplex Enabled)
>  *   JES2 Checkpoint in CF
>  *   ZFS File Systems? (This system is not in a shared OMVS Environment)
>
>I'd like people to shoot things at me that I might have missed while I keep on 
>looking myself.
>
>TIA,
>
>Mark Jacobs
>Time Customer Service


Could be a consideration to review/verify - software (contractual language) 
licensing, also previous-condition with "shared" system dependency, then no 
longer accessible after un-Sysplex?

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: z/OS network Speedtest

[Kevin Mckenzie]

> Is there anything for z/OS to measure upload/download speeds? Like on a
PC
> going to speedtest.net and running their test?

>From the z/OS LPAR to where?  What's the purpose of the measurement?  Can
you prevent other network traffic from happening when you're doing the
measurement?

---
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS Test Services - Test Architect, Provisioning

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

Re: z/OS network Speedtest

[Ronald Kristel]

Something we sometimes do is; Transfer large files with FTP from z/OS LPAR to 
another LPAR (or any host). The FTP program gives a nice report per certain 
amount of bytes transfered or time interval. (Either one of them, can't exactly 
remember which). It shows the amount of bytes transfered per second.

Ronald Kristel

From: IBM Mainframe Discussion List  on behalf of 
Mark Pace 
Sent: Wednesday, August 29, 2018 8:24:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS network Speedtest

Is there anything for z/OS to measure upload/download speeds? Like on a PC
going to speedtest.net and running their test?

--
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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: Un-Sysplex a zOS System

[Scott Barry]

On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv 
 wrote:

>We're in a parallel sysplex, sharing most everything, and need to begin 
>planning activities to remove one system from the sysplex, while continuing to 
>use it to run a subset of our current workload.
>
>Some of the things we need to consider are;
>
>  *   PDS/e Sharing
>  *   Catalogs (we're ECS shared now)
>  *   Shared DASD
>  *   RACF Database Sharing (Sysplex Enabled)
>  *   JES2 Checkpoint in CF
>  *   ZFS File Systems? (This system is not in a shared OMVS Environment)
>
>I'd like people to shoot things at me that I might have missed while I keep on 
>looking myself.
>
>TIA,
>
>Mark Jacobs
>Time Customer Service


Could be a consideration to review/verify - software (contractual language) 
licensing, also previous-condition with "shared" system dependency, then no 
longer accessible after un-Sysplex?

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: Un-Sysplex a zOS System

[Rob Schramm]

A little free thinking on my part...

All XCF type data sets

DFSMS datasets, archiver?

DR backup and restore?

Tape?

ICSF

Security rules, security propagation or separation, scheduler and
automation, dasd naming

SMF processing

Monthly reporting for ibm

Jes2 to jes2 shipping of jobs and output?

Change control - application code, duplicates of anything shared, promotion
to multi-environment, data movement between sysplex and non-sysplex

Change control for sysprog and promotion of fixes

Change IPL doc for operations

HTH,

Rob

On Wed, Aug 29, 2018, 2:16 PM Cameron Conacher  wrote:

> If you are dropping an LPAR, maybe there are CICSPLEX considerations?
> If your CICSPLEX runs in some number of CICS regions and half are in one
> LOAR and half in another, then half of them go away because of dropping the
> LPAR and you might no longer have an effective CICSPLEX. I mean if the
> remaining LPAR hosting your CICSPLEX CICS regions were to fail you would
> have no CICS availability.
> You probably already considered this.
>
> Sent from my iPhone
>
> > On Aug 29, 2018, at 1:57 PM, Mark Jacobs - Listserv <
> mark.jac...@custserv.com> wrote:
> >
> > We're in a parallel sysplex, sharing most everything, and need to begin
> planning activities to remove one system from the sysplex, while continuing
> to use it to run a subset of our current workload.
> >
> > Some of the things we need to consider are;
> >
> > *   PDS/e Sharing
> > *   Catalogs (we're ECS shared now)
> > *   Shared DASD
> > *   RACF Database Sharing (Sysplex Enabled)
> > *   JES2 Checkpoint in CF
> > *   ZFS File Systems? (This system is not in a shared OMVS Environment)
> >
> > I'd like people to shoot things at me that I might have missed while I
> keep on looking myself.
> >
> > TIA,
> >
> > Mark Jacobs
> > Time Customer Service
> >
> > This electronic message, including any attachments, may contain
> proprietary, confidential or privileged information for the sole use of the
> intended recipient(s). You are hereby notified that any unauthorized
> disclosure, copying, distribution, or use of this message is prohibited. If
> you have received this message in error, please immediately notify the
> sender by reply e-mail and delete it.
> >
> > --
> > 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
>
-- 

Rob Schramm

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

Re: 0,clpa

[Rob Schramm]

I have to agree.  Let's leave the 360 restart facility in the 60/70's and
move toward safe IPLs with CLPA.

ARM and DB2 and logger will continue to work with CLPA.  Making sure that
no one has left a "surprise" in LPA that will cause issues.

CLPA user since 1995

Rob Schramm


On Wed, Aug 29, 2018, 2:55 PM Carmen Vitullo  wrote:

> Thanks for the info Mr. Shmuel ! another one of those options, tools I've
> never used, off topic but reminds me of a y2k upgrade I was performing for
> a state agency, the DOL user was getting errors on the DD statement, TLMS
> was the tape managment system and once they showed me the JCL and the error
> I told them "you can't do that!, you can't code DSN='Sears and Roebuck',
> here to find out from CA, yeah you can if DISP=(,KEEP).
> again, thank you
>
>
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Seymour J Metz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, August 29, 2018 1:30:18 PM
> Subject: Re: 0,clpa
>
> ARM is a much newer facility, with a different purpose. Automatic step
> restart goes all the way back to OS/360; see the RD=R parameters on JOB and
> EXEC.
>
> Note that temp and VIO are only recovered for an automatic restart, not
> for a manual restart. That applies to both checkpoint and step restarts,
> but the restrictions on checkpoint restart, e.g., no multitasking, made it
> of limited utility.
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Carmen Vitullo 
> Sent: Wednesday, August 29, 2018 1:56 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> ah, pardon my ignorance, ARM? the coupling facility policy?
> I've never tried to restart a job that created a temp or VIO data-sets
> created in a previous step, my assumption was...they were in the bit
> bucket.
> but it's been a while for me since I had to attempt a restart of a batch
> job.
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Seymour J Metz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, August 29, 2018 12:51:33 PM
> Subject: Re: 0,clpa
>
> No, temp and VIO don't go away when the system crashes. If you have
> automatic step restart and don't do a CVIO, then the restarted job gets the
> previously allocated VIO data sets.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Carmen Vitullo 
> Sent: Wednesday, August 29, 2018 1:13 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> Guess it's been so long I had to worry about restarting a job I don't why
> step restart would be affected, if DISP=(,PASS) for temp dataset or VIO,
> well that goes away after the job is completed or failed, unless CLPA
> affects RESTART=STEPx on the jobcard?
>
>
>
> Carmen Vitullo
>
> - Original Message -
>
> From: "Seymour J Metz" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Sent: Wednesday, August 29, 2018 11:30:05 AM
> Subject: Re: 0,clpa
>
> Not just C/R, but also step restart.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of R.S. 
> Sent: Wednesday, August 29, 2018 12:21 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> Oh, those jobs using Checkpoint/Restart?
> As far as I remember it precludes usage of Extended Format and other
> "modern" (read: 25 years old and less) features.
> No, during last 20 years I haven't seen any job using that, nor heard
> about anyone using it. YMMV.
>
> BTW: It's amazing how much you love to be laconic and abstruse.
>
>
> Regarding CLPA - I'm glad that routinely using CLPA I do not loose
> anything useful (except a little bit longer IPL).
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 2018-08-29 o 17:57, Seymour J Metz pisze:
> > The jobs specifying RD=R, obviously.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List  on
> behalf of R.S. 
> > Sent: Wednesday, August 29, 2018 11:42:26 AM
> > To: IBM-MAIN@listserv.ua.edu
> > Subject: Re: 0,clpa
> >
> > W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:
> >> You'd be unable to restart those jobs.
> > What jobs?
> >
> >
> > --
> > Radoslaw Skorupka
> > Lodz, Poland
> >
> >
> >
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania,
> narusza prawo i może podlegać karze.
>
> mBank S.A. 

Re: 0,clpa

[Carmen Vitullo]

Thanks for the info Mr. Shmuel ! another one of those options, tools I've never 
used, off topic but reminds me of a y2k upgrade I was performing for a state 
agency, the DOL user was getting errors on the DD statement, TLMS was the tape 
managment system and once they showed me the JCL and the error I told them "you 
can't do that!, you can't code DSN='Sears and Roebuck', here to find out from 
CA, yeah you can if DISP=(,KEEP). 
again, thank you 





Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 1:30:18 PM 
Subject: Re: 0,clpa 

ARM is a much newer facility, with a different purpose. Automatic step restart 
goes all the way back to OS/360; see the RD=R parameters on JOB and EXEC. 

Note that temp and VIO are only recovered for an automatic restart, not for a 
manual restart. That applies to both checkpoint and step restarts, but the 
restrictions on checkpoint restart, e.g., no multitasking, made it of limited 
utility. 

-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, August 29, 2018 1:56 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

ah, pardon my ignorance, ARM? the coupling facility policy? 
I've never tried to restart a job that created a temp or VIO data-sets created 
in a previous step, my assumption was...they were in the bit bucket. 
but it's been a while for me since I had to attempt a restart of a batch job. 


Carmen Vitullo 

- Original Message - 

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 12:51:33 PM 
Subject: Re: 0,clpa 

No, temp and VIO don't go away when the system crashes. If you have automatic 
step restart and don't do a CVIO, then the restarted job gets the previously 
allocated VIO data sets. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, August 29, 2018 1:13 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

Guess it's been so long I had to worry about restarting a job I don't why step 
restart would be affected, if DISP=(,PASS) for temp dataset or VIO, well that 
goes away after the job is completed or failed, unless CLPA affects 
RESTART=STEPx on the jobcard? 



Carmen Vitullo 

- Original Message - 

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 11:30:05 AM 
Subject: Re: 0,clpa 

Not just C/R, but also step restart. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
R.S.  
Sent: Wednesday, August 29, 2018 12:21 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

Oh, those jobs using Checkpoint/Restart? 
As far as I remember it precludes usage of Extended Format and other 
"modern" (read: 25 years old and less) features. 
No, during last 20 years I haven't seen any job using that, nor heard 
about anyone using it. YMMV. 

BTW: It's amazing how much you love to be laconic and abstruse. 


Regarding CLPA - I'm glad that routinely using CLPA I do not loose 
anything useful (except a little bit longer IPL). 

-- 
Radoslaw Skorupka 
Lodz, Poland 






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze: 
> The jobs specifying RD=R, obviously. 
> 
> 
> -- 
> Shmuel (Seymour J.) Metz 
> http://mason.gmu.edu/~smetz3 
> 
>  
> From: IBM Mainframe Discussion List  on behalf of 
> R.S.  
> Sent: Wednesday, August 29, 2018 11:42:26 AM 
> To: IBM-MAIN@listserv.ua.edu 
> Subject: Re: 0,clpa 
> 
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze: 
>> You'd be unable to restart those jobs. 
> What jobs? 
> 
> 
> -- 
> Radoslaw Skorupka 
> Lodz, Poland 
> 
> 
> 


== 

Jeśli nie jesteś adresatem tej wiadomości: 

- powiadom nas o tym w mailu zwrotnym (dziękujemy!), 
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku). 
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze. 

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 

Re: Anyone here exprerienced in JSON parser (assembler)

[Martin Packer]

s/JSOPN/JSONP/ ?

Cheers, Martin

Sent from my iPad

> On 29 Aug 2018, at 18:05, Tom Ross  wrote:
>
>  >> Is there a COBOL equivalent to JSON.stringify?
>  > Yes!  It is the JSON GENERATE statement, available in 2016 in COBOL
V6.1
>
> >Awesome! I'm guessing it uses the same environment as the XML
> >parser/generator?
>
>
>  Well, it runs in the COBOL environment, so if you are talking about
> COBOL XML GENERATE and XML PARSE (COMPAT), then yes.  If you are talking
about
> the XMLSS option COBOL XML PARSE, it runs in a mixture of COBOL and
> 'z/OS XML System Services' parser environments.
>
> >The tricky part comes when the structure of the JSON is unknown and
has=20
> >to be traversed by node.
>
> Well, JSOPN is for RESTful services, where you tell clients what the JSON
> for a service request should look like.  The client and the service have
to
> know a little about each other. Good luck with your project!
>
> 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
>Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: 0,clpa

[Seymour J Metz]

ARM is a much newer facility, with a different purpose. Automatic step restart 
goes all the way back to OS/360; see the RD=R parameters on JOB and EXEC.

Note that temp and VIO are only recovered for an automatic restart, not for a 
manual restart. That applies to both checkpoint and step restarts, but the 
restrictions on checkpoint restart, e.g., no multitasking, made it of limited 
utility.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, August 29, 2018 1:56 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

ah, pardon my ignorance, ARM? the coupling facility policy?
I've never tried to restart a job that created a temp or VIO data-sets created 
in a previous step, my assumption was...they were in the bit bucket.
but it's been a while for me since I had to attempt a restart of a batch job.


Carmen Vitullo

- Original Message -

From: "Seymour J Metz" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, August 29, 2018 12:51:33 PM
Subject: Re: 0,clpa

No, temp and VIO don't go away when the system crashes. If you have automatic 
step restart and don't do a CVIO, then the restarted job gets the previously 
allocated VIO data sets.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, August 29, 2018 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

Guess it's been so long I had to worry about restarting a job I don't why step 
restart would be affected, if DISP=(,PASS) for temp dataset or VIO, well that 
goes away after the job is completed or failed, unless CLPA affects 
RESTART=STEPx on the jobcard?



Carmen Vitullo

- Original Message -

From: "Seymour J Metz" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, August 29, 2018 11:30:05 AM
Subject: Re: 0,clpa

Not just C/R, but also step restart.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 12:21 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

Oh, those jobs using Checkpoint/Restart?
As far as I remember it precludes usage of Extended Format and other
"modern" (read: 25 years old and less) features.
No, during last 20 years I haven't seen any job using that, nor heard
about anyone using it. YMMV.

BTW: It's amazing how much you love to be laconic and abstruse.


Regarding CLPA - I'm glad that routinely using CLPA I do not loose
anything useful (except a little bit longer IPL).

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze:
> The jobs specifying RD=R, obviously.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: Wednesday, August 29, 2018 11:42:26 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:
>> You'd be unable to restart those jobs.
> What jobs?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

z/OS network Speedtest

[Mark Pace]

Is there anything for z/OS to measure upload/download speeds? Like on a PC
going to speedtest.net and running their test?

-- 
The postings on this site are my own and don’t necessarily represent
Mainline’s positions or opinions

Mark D Pace
Senior Systems Engineer
Mainline Information Systems

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

Re: [External] Re: cross LPAR priority and cycle stealing

[Pommier, Rex]

Thanks, Kees;

I'll check them out.

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Vernooij, Kees (ITOPT1) - KLM
Sent: Wednesday, August 29, 2018 1:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: cross LPAR priority and cycle stealing

We did some investigation in the past.
AFAIK, there are several tools to manage the CP capacity between LPARs that are 
not in a sysplex:
IBMs Group capacity (Free!) and zCost: do not what you look for.
BMCs tool iCap (it seems to be called TrueSight Capacity Optimization now) 
takes the PI's and Importance of workload into consideration, so this is what 
you are looking for.
zDynacap (from SDS?) does the same.

Grtn,
Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pommier, Rex
> Sent: 29 August, 2018 0:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: cross LPAR priority and cycle stealing
> 
> That's what I was afraid of, but was hoping.
> 
> Thanks, Martin.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: Tuesday, August 28, 2018 4:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: cross LPAR priority and cycle stealing
> 
> 
> 
> Then the two WLMs can’t cooperate - and aren’t even aware of each
> other’s
> 
> state. :-(
> 
> 
> 
> Manual shifting the weights - via BCPii - might be doable.
> 
> 
> 
> Cheers, Martin
> 
> 
> 
> Sent from my iPad
> 
> 
> 
> > On 28 Aug 2018, at 22:11, Pommier, Rex 
> wrote:
> 
> >
> 
> > Hi Martin,
> 
> >
> 
> > Sorry, no sysplex.
> 
> >
> 
> > Rex
> 
> >
> 
> > -Original Message-
> 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> 
> Behalf Of Martin Packer
> 
> > Sent: Tuesday, August 28, 2018 3:59 PM
> 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> 
> > Subject: [External] Re: cross LPAR priority and cycle stealing
> 
> >
> 
> >
> 
> >
> 
> > Are these LPARs in the same Sysplex? Two beneficial effects if they
> are:
> 
> >
> 
> > 1) You could - with IRD Weight Management - have weights shifted
> between
> 
> > the LPARs.
> 
> >
> 
> > 2) Sysplex PI for important works comes into play.
> 
> >
> 
> > Cheers, Martin
> 
> >
> 
> > Sent from my iPad
> 
> >
> 
> >> On 28 Aug 2018, at 21:52, Pommier, Rex 
> wrote:
> 
> >>
> 
> >> Hello list,
> 
> >>
> 
> >> Hypothetical scenario is a single machine with 2 LPARs on it, each
> LPAR
> 
> > is defined as having 50% of the capacity of the entire machine,
> uncapped
> 
> > across the board.  In this scenario, if both LPAR1 and LPAR2 are
> running
> 
> > flat out, each LPAR will take 50% of the machine.  If one of the LPARs
> is
> 
> > busy and the other isn't doing anything, the busy LPAR will "steal"
> 
> cycles
> 
> > from the not busy one.  That's the easy part.  Here's where my
> thoughts
> 
> get
> 
> > fuzzy.  Is there a way to differentiate between high priority work on
> one
> 
> > LPAR and low priority work on the other LPAR.  Here's what I'd like to
> 
> do:
> 
> > Say I'm running a bunch of production on one LPAR and a bunch of test
> 
> work
> 
> > on the other one.  I'd like to be able to steal cycles from the test
> LPAR
> 
> > and give them to the production one.  I know WLM handles this within
> an
> 
> > LPAR, making sure the high priority work gets the cycles it needs, but
> is
> 
> > there a mechanism where I can do this across multiple LPARs?  If there
> 
> is,
> 
> > can somebody point me to the right place for learning how to configure
> 
> this
> 
> > to happen automatically?
> 
> >>
> 
> >> I have higher and lower priority work alternating between multiple
> LPARs
> 
> > and would like the machine to be able to better balance the workloads
> so
> 
> > that regardless of which LPAR the high priority work is on, it gets
> the
> 
> CPU
> 
> > necessary.
> 
> >>
> 
> >> TIA,
> 
> >>
> 
> >> Rex
> 
> >>
> 
> >>
> 
> >> 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-
> 

Re: Un-Sysplex a zOS System

[Cameron Conacher]

If you are dropping an LPAR, maybe there are CICSPLEX considerations?
If your CICSPLEX runs in some number of CICS regions and half are in one LOAR 
and half in another, then half of them go away because of dropping the LPAR and 
you might no longer have an effective CICSPLEX. I mean if the remaining LPAR 
hosting your CICSPLEX CICS regions were to fail you would have no CICS 
availability.
You probably already considered this.

Sent from my iPhone

> On Aug 29, 2018, at 1:57 PM, Mark Jacobs - Listserv 
>  wrote:
> 
> We're in a parallel sysplex, sharing most everything, and need to begin 
> planning activities to remove one system from the sysplex, while continuing 
> to use it to run a subset of our current workload.
> 
> Some of the things we need to consider are;
> 
> *   PDS/e Sharing
> *   Catalogs (we're ECS shared now)
> *   Shared DASD
> *   RACF Database Sharing (Sysplex Enabled)
> *   JES2 Checkpoint in CF
> *   ZFS File Systems? (This system is not in a shared OMVS Environment)
> 
> I'd like people to shoot things at me that I might have missed while I keep 
> on looking myself.
> 
> TIA,
> 
> Mark Jacobs
> Time Customer Service
> 
> This electronic message, including any attachments, may contain proprietary, 
> confidential or privileged information for the sole use of the intended 
> recipient(s). You are hereby notified that any unauthorized disclosure, 
> copying, distribution, or use of this message is prohibited. If you have 
> received this message in error, please immediately notify the sender by reply 
> e-mail and delete it.
> 
> --
> 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

Un-Sysplex a zOS System

[Mark Jacobs - Listserv]

We're in a parallel sysplex, sharing most everything, and need to begin 
planning activities to remove one system from the sysplex, while continuing to 
use it to run a subset of our current workload.

Some of the things we need to consider are;

 *   PDS/e Sharing
 *   Catalogs (we're ECS shared now)
 *   Shared DASD
 *   RACF Database Sharing (Sysplex Enabled)
 *   JES2 Checkpoint in CF
 *   ZFS File Systems? (This system is not in a shared OMVS Environment)

I'd like people to shoot things at me that I might have missed while I keep on 
looking myself.

TIA,

Mark Jacobs
Time Customer Service

This electronic message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the intended 
recipient(s). You are hereby notified that any unauthorized disclosure, 
copying, distribution, or use of this message is prohibited. If you have 
received this message in error, please immediately notify the sender by reply 
e-mail and delete it.

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

Re: 0,clpa

[Carmen Vitullo]

ah, pardon my ignorance, ARM? the coupling facility policy? 
I've never tried to restart a job that created a temp or VIO data-sets created 
in a previous step, my assumption was...they were in the bit bucket. 
but it's been a while for me since I had to attempt a restart of a batch job. 


Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 12:51:33 PM 
Subject: Re: 0,clpa 

No, temp and VIO don't go away when the system crashes. If you have automatic 
step restart and don't do a CVIO, then the restarted job gets the previously 
allocated VIO data sets. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo  
Sent: Wednesday, August 29, 2018 1:13 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

Guess it's been so long I had to worry about restarting a job I don't why step 
restart would be affected, if DISP=(,PASS) for temp dataset or VIO, well that 
goes away after the job is completed or failed, unless CLPA affects 
RESTART=STEPx on the jobcard? 



Carmen Vitullo 

- Original Message - 

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 11:30:05 AM 
Subject: Re: 0,clpa 

Not just C/R, but also step restart. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
R.S.  
Sent: Wednesday, August 29, 2018 12:21 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

Oh, those jobs using Checkpoint/Restart? 
As far as I remember it precludes usage of Extended Format and other 
"modern" (read: 25 years old and less) features. 
No, during last 20 years I haven't seen any job using that, nor heard 
about anyone using it. YMMV. 

BTW: It's amazing how much you love to be laconic and abstruse. 


Regarding CLPA - I'm glad that routinely using CLPA I do not loose 
anything useful (except a little bit longer IPL). 

-- 
Radoslaw Skorupka 
Lodz, Poland 






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze: 
> The jobs specifying RD=R, obviously. 
> 
> 
> -- 
> Shmuel (Seymour J.) Metz 
> http://mason.gmu.edu/~smetz3 
> 
>  
> From: IBM Mainframe Discussion List  on behalf of 
> R.S.  
> Sent: Wednesday, August 29, 2018 11:42:26 AM 
> To: IBM-MAIN@listserv.ua.edu 
> Subject: Re: 0,clpa 
> 
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze: 
>> You'd be unable to restart those jobs. 
> What jobs? 
> 
> 
> -- 
> Radoslaw Skorupka 
> Lodz, Poland 
> 
> 
> 


== 

Jeśli nie jesteś adresatem tej wiadomości: 

- powiadom nas o tym w mailu zwrotnym (dziękujemy!), 
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku). 
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze. 

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych. 

If you are not the addressee of this message: 

- let us know by replying to this e-mail (thank you!), 
- delete this message permanently (including all the copies which you have 
printed out or saved). 
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised. 

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the 

Re: ALLOWUSERKEYCSA

[Lizette Koehler]

There is a good write up in a Migration Guide on this

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0zm100/BCP_vsm-rsm_userkeyCA_v2r3.htm

See if that helps.  Watch the wrap

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Roland Fernandez
> Sent: Wednesday, August 29, 2018 10:05 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ALLOWUSERKEYCSA
> 
> Ron,
> 
> Take a look at APAR OA53355.  IBM recently updated it to reference a
> previously un-documented parameter called ALLOWUSERKEYCADS.
> 
> CAUTION!!! TRY THIS ON A SANDBOX LPAR FIRST!!! >>> If you code
> ALLOWUSERKEYCADS(NO) in your DIAGxx member any offenders will generate an
> S01D-15 abend.  In our experience, a couple of products kind-of recover and
> keep running while another one just fails.  Everyone's mileage may vary.
> 
> The takeaway from this is that some third party products are not yet fully
> remediated.  We have not seen this issue with any IBM products but that may
> just be a case of our particular product mix.
> 
> Thanks,
> Roland Fernandez
> Pacific Life
> 

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

Re: 0,clpa

[Seymour J Metz]

No, temp and VIO don't go away when the system crashes. If you have automatic 
step restart and don't do a CVIO, then the restarted job gets the previously 
allocated VIO data sets.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Carmen Vitullo 
Sent: Wednesday, August 29, 2018 1:13 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

Guess it's been so long I had to worry about restarting a job I don't why step 
restart would be affected, if DISP=(,PASS) for temp dataset or VIO, well that 
goes away after the job is completed or failed, unless CLPA affects 
RESTART=STEPx on the jobcard?



Carmen Vitullo

- Original Message -

From: "Seymour J Metz" 
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, August 29, 2018 11:30:05 AM
Subject: Re: 0,clpa

Not just C/R, but also step restart.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 12:21 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

Oh, those jobs using Checkpoint/Restart?
As far as I remember it precludes usage of Extended Format and other
"modern" (read: 25 years old and less) features.
No, during last 20 years I haven't seen any job using that, nor heard
about anyone using it. YMMV.

BTW: It's amazing how much you love to be laconic and abstruse.


Regarding CLPA - I'm glad that routinely using CLPA I do not loose
anything useful (except a little bit longer IPL).

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze:
> The jobs specifying RD=R, obviously.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: Wednesday, August 29, 2018 11:42:26 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:
>> You'd be unable to restart those jobs.
> What jobs?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

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

Re: ALLOWUSERKEYCSA

[Ed Jaffe]

On 8/29/2018 8:16 AM, Rob JACKSON wrote:

I have been testing setting ALLOWUSERKEYCSA to NO in the DIAGxx member and have 
encountered sporadic errors (0C4, etc). Is there anyone that might be able to 
offer any suggestions relative to this issue.


If an SVC dump is produced, analyze it to determine who owns the code at 
time of error and send them the dump.


If no SVC dump is produced, you might need to set an error-event SLIP to 
force one out...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/


This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: 0,clpa

[Carmen Vitullo]

Guess it's been so long I had to worry about restarting a job I don't why step 
restart would be affected, if DISP=(,PASS) for temp dataset or VIO, well that 
goes away after the job is completed or failed, unless CLPA affects 
RESTART=STEPx on the jobcard? 



Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 11:30:05 AM 
Subject: Re: 0,clpa 

Not just C/R, but also step restart. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
R.S.  
Sent: Wednesday, August 29, 2018 12:21 PM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

Oh, those jobs using Checkpoint/Restart? 
As far as I remember it precludes usage of Extended Format and other 
"modern" (read: 25 years old and less) features. 
No, during last 20 years I haven't seen any job using that, nor heard 
about anyone using it. YMMV. 

BTW: It's amazing how much you love to be laconic and abstruse. 


Regarding CLPA - I'm glad that routinely using CLPA I do not loose 
anything useful (except a little bit longer IPL). 

-- 
Radoslaw Skorupka 
Lodz, Poland 






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze: 
> The jobs specifying RD=R, obviously. 
> 
> 
> -- 
> Shmuel (Seymour J.) Metz 
> http://mason.gmu.edu/~smetz3 
> 
>  
> From: IBM Mainframe Discussion List  on behalf of 
> R.S.  
> Sent: Wednesday, August 29, 2018 11:42:26 AM 
> To: IBM-MAIN@listserv.ua.edu 
> Subject: Re: 0,clpa 
> 
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze: 
>> You'd be unable to restart those jobs. 
> What jobs? 
> 
> 
> -- 
> Radoslaw Skorupka 
> Lodz, Poland 
> 
> 
> 


== 

Jeśli nie jesteś adresatem tej wiadomości: 

- powiadom nas o tym w mailu zwrotnym (dziękujemy!), 
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku). 
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze. 

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych. 

If you are not the addressee of this message: 

- let us know by replying to this e-mail (thank you!), 
- delete this message permanently (including all the copies which you have 
printed out or saved). 
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised. 

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018. 

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

[Roland Fernandez]

Ron,

Take a look at APAR OA53355.  IBM recently updated it to reference a previously 
un-documented parameter called ALLOWUSERKEYCADS.

CAUTION!!! TRY THIS ON A SANDBOX LPAR FIRST!!! >>> If you code 
ALLOWUSERKEYCADS(NO) in your DIAGxx member any offenders will generate an 
S01D-15 abend.  In our experience, a couple of products kind-of recover and 
keep running while another one just fails.  Everyone's mileage may vary.

The takeaway from this is that some third party products are not yet fully 
remediated.  We have not seen this issue with any IBM products but that may 
just be a case of our particular product mix.

Thanks,
Roland Fernandez
Pacific Life

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

Re: 0,clpa

[Seymour J Metz]

Not just C/R, but also step restart.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 12:21 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

Oh, those jobs using Checkpoint/Restart?
As far as I remember it precludes usage of Extended Format and other
"modern" (read: 25 years old and less) features.
No, during last 20 years I haven't seen any job using that, nor heard
about anyone using it.  YMMV.

BTW: It's amazing how much you love to be laconic and abstruse.


Regarding CLPA - I'm glad that routinely using CLPA I do not loose
anything useful (except a little bit longer IPL).

--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze:
> The jobs specifying RD=R, obviously.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> R.S. 
> Sent: Wednesday, August 29, 2018 11:42:26 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: 0,clpa
>
> W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:
>> You'd be unable to restart those jobs.
> What jobs?
>
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>


==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1NLon2Ecmrb18gQb72iOCXNiH4gRT27vk05Uvru3piTuUa4QYQRUYZcRM_Xi7h7sbuZcNGKTE8-CMSGnYksW0r12UkRN4Met_KMPF1wNy-orqSL55g5oMFZ1MFlj61IAKSZWvBfCrKmI5VdMMzA5nljbxOD5WCZCuW2FOnWSmmXaquMxzw8bhUYykRmBUiy1fIOG3yJVYfdfebBAzQp8zGLHE6qCG3vIThJANAL4YHyN4gekOGulNyS9mqsFDcynHn6pNiqDp5wdxLkz7_-oVL_Jn8a3_HpDatXYGJK97hf_R1ToweJA0KZLkKhz79NUW3xooR8Ayb-WJFJvkDKEf9M6407k3rRp0wG3z_qt4LCVyyxEdLDhBgKXvT91KQHdb/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

--
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: 0,clpa

[R.S.]

Oh, those jobs using Checkpoint/Restart?
As far as I remember it precludes usage of Extended Format and other 
"modern" (read: 25 years old and less) features.
No, during last 20 years I haven't seen any job using that, nor heard 
about anyone using it.  YMMV.


BTW: It's amazing how much you love to be laconic and abstruse.


Regarding CLPA - I'm glad that routinely using CLPA I do not loose 
anything useful (except a little bit longer IPL).


--
Radoslaw Skorupka
Lodz, Poland






W dniu 2018-08-29 o 17:57, Seymour J Metz pisze:

The jobs specifying RD=R, obviously.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of R.S. 

Sent: Wednesday, August 29, 2018 11:42:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:

You'd be unable to restart those jobs.

What jobs?


--
Radoslaw Skorupka
Lodz, Poland






==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

>Tom,
>
>The program executes in key zero & supervisor mode. this is how it get
>control. Not sure I can write it in Cobol.

Well, you could WRITE it in COBOL, but you could not run it :-)-
COBOL can only run in problem state.

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

Re: Anyone here exprerienced in JSON parser (assembler)

[Tom Ross]

 >> Is there a COBOL equivalent to JSON.stringify?
 > Yes!  It is the JSON GENERATE statement, available in 2016 in COBOL V6.1

>Awesome! I'm guessing it uses the same environment as the XML
>parser/generator?


 Well, it runs in the COBOL environment, so if you are talking about
COBOL XML GENERATE and XML PARSE (COMPAT), then yes.  If you are talking about
the XMLSS option COBOL XML PARSE, it runs in a mixture of COBOL and
'z/OS XML System Services' parser environments.

>The tricky part comes when the structure of the JSON is unknown and has=20
>to be traversed by node.

Well, JSOPN is for RESTful services, where you tell clients what the JSON
for a service request should look like.  The client and the service have to
know a little about each other. Good luck with your project!

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

Re: 0,clpa

[Seymour J Metz]

The jobs specifying RD=R, obviously.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 11:42:26 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:
> You'd be unable to restart those jobs.
What jobs?


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1fjv3cbm9Msi5YcR51DM5LFnLWlGQ7kX9pUC9Z9rAYVKPT4tG8wNFPnHyw9RrB0WxWktyR_GG1B3M57X_MIUdKxQpqI8KhWUBO_z3lYqfG97B56F00lRr51hmX3rVqGzeZNUjzB3am3sF2LKT94rEJy_aZbOCjfMoYt2FycKhzkCIBbOwXp2X0kt6CrFsLwTnzVHQMu8gYTQ71s0vVmuQ0EVt49sW8DLP97ZZmjWiWuwlpKGtHsHjkaZbtU02IktnlQFShtzB686DgzWlRJXCe10mVuG_niIoWyqbA9Ua5NaTpXxKLZ17W1dg2NvSMexuvInSHEYxMKmjKB6NmmP5nel9Sp9QFvDxMF1YnISd9-lvyI4qJcfWItRbOJnX29ESE3qRSDTZB4AEfqVVLhhmLBaz-tkRJMsRcgS10ajlTN78_v5RFaGMn54o6gLxhgO3/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1fjv3cbm9Msi5YcR51DM5LFnLWlGQ7kX9pUC9Z9rAYVKPT4tG8wNFPnHyw9RrB0WxWktyR_GG1B3M57X_MIUdKxQpqI8KhWUBO_z3lYqfG97B56F00lRr51hmX3rVqGzeZNUjzB3am3sF2LKT94rEJy_aZbOCjfMoYt2FycKhzkCIBbOwXp2X0kt6CrFsLwTnzVHQMu8gYTQ71s0vVmuQ0EVt49sW8DLP97ZZmjWiWuwlpKGtHsHjkaZbtU02IktnlQFShtzB686DgzWlRJXCe10mVuG_niIoWyqbA9Ua5NaTpXxKLZ17W1dg2NvSMexuvInSHEYxMKmjKB6NmmP5nel9Sp9QFvDxMF1YnISd9-lvyI4qJcfWItRbOJnX29ESE3qRSDTZB4AEfqVVLhhmLBaz-tkRJMsRcgS10ajlTN78_v5RFaGMn54o6gLxhgO3/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

--
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: 0,clpa

[Tom Brennan]

> checkpoint restart

That brings back memories!  Checkpoint/Restart was a great idea, and it 
even worked some of the time :)  The programmers using it finally had 
enough and divided their one huge job into more manageable chunks (I 
think by customer name A-D, E-H, etc.) and I was never called again for 
checkpoint/restart issues.


On 8/29/2018 8:35 AM, Mark Jacobs - Listserv wrote:
I mandated CLPA for all IPLs around 1996 or 1997 and told everyone that 
checkpoint restart was going away. No one cared enough to argue with me.


Mark Jacobs

Seymour J Metz wrote on 8/29/18 11:32 AM:
You'd be unable to restart those jobs.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List 
 on behalf of 
R.S. 


Sent: Wednesday, August 29, 2018 11:11 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

W dniu 2018-08-29 o 16:57, Seymour J Metz pisze:

FSVO safe. CLPA implies CVIO, so if you use restart ...

Yes?
What could happen?

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub 
zapisałeś na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może 
wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia 
(kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, 
narusza prawo i może podlegać karze.


mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http://www.mBank.pl, 
e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. 
st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 
025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) 
według stanu na 01.01.2018 r. wynosi 169.248.488 złotych.


If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you 
have printed out or saved).
This message may contain legally protected information, which may be 
used exclusively by the addressee.Please be reminded that anyone who 
disseminates (copies, distributes) this message or takes any similar 
action, violates the law and may be penalised.


mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 
00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http://www.mBank.pl, 
e-mail: kont...@mbank.pl. District Court for 
the Capital City of Warsaw, 12th Commercial Division of the National 
Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share 
capital amounting to PLN 169,248,488 as at 1 January 2018.


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

Re: 0,clpa

[R.S.]

W dniu 2018-08-29 o 17:32, Seymour J Metz pisze:

You'd be unable to restart those jobs.

What jobs?


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: 0,clpa

[Carmen Vitullo]

I believe he was referring to checkpoint restarts , years ago we had many long 
running processes that used checkpoint restart, if standalone was needed and 
these jobs had to be cancelled we did not perform CLPA. 
I believe this is still an issue for checkpoint restarts? 


Carmen Vitullo 

- Original Message -

From: "Seymour J Metz"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Wednesday, August 29, 2018 10:32:21 AM 
Subject: Re: 0,clpa 

You'd be unable to restart those jobs. 


-- 
Shmuel (Seymour J.) Metz 
http://mason.gmu.edu/~smetz3 

 
From: IBM Mainframe Discussion List  on behalf of 
R.S.  
Sent: Wednesday, August 29, 2018 11:11 AM 
To: IBM-MAIN@listserv.ua.edu 
Subject: Re: 0,clpa 

W dniu 2018-08-29 o 16:57, Seymour J Metz pisze: 
> FSVO safe. CLPA implies CVIO, so if you use restart ... 
Yes? 
What could happen? 

-- 
Radoslaw Skorupka 
Lodz, Poland 




== 

Jeśli nie jesteś adresatem tej wiadomości: 

- powiadom nas o tym w mailu zwrotnym (dziękujemy!), 
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku). 
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze. 

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych. 

If you are not the addressee of this message: 

- let us know by replying to this e-mail (thank you!), 
- delete this message permanently (including all the copies which you have 
printed out or saved). 
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised. 

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018. 

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

[Tom Marchant]

On Wed, 29 Aug 2018 15:16:36 +, Rob JACKSON wrote:

>I have been tasked with 'Preparing for the removal of support 
>for user key common areas (Recommended, as of V2R3)'.  I 
>have been testing setting ALLOWUSERKEYCSA to NO in the 
>DIAGxx member and have encountered sporadic errors (0C4, etc).

I would not expect S0C4 because of this, but a B04-5C, B0A-5C, 
or B78-5C abend when the request for user key CSA is made.

In that case, the program that gets that abend code must be 
investigated and changed.

-- 
Tom Marchant

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

Re: 0,clpa

[Mark Jacobs - Listserv]

I mandated CLPA for all IPLs around 1996 or 1997 and told everyone that 
checkpoint restart was going away. No one cared enough to argue with me.

Mark Jacobs

Seymour J Metz wrote on 8/29/18 11:32 AM:
You'd be unable to restart those jobs.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List 
 on behalf of R.S. 

Sent: Wednesday, August 29, 2018 11:11 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

W dniu 2018-08-29 o 16:57, Seymour J Metz pisze:

FSVO safe. CLPA implies CVIO, so if you use restart ...

Yes?
What could happen?

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http://www.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 169.248.488 
złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http://www.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, 
NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

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


Please be alert for any emails that may ask you for login information or directs you 
to login via a link. If you believe this message is a phish or aren't sure whether 
this message is trustworthy, please send the original message as an attachment to 

Re: 0,clpa

[Seymour J Metz]

You'd be unable to restart those jobs.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 11:11 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

W dniu 2018-08-29 o 16:57, Seymour J Metz pisze:
> FSVO safe. CLPA implies CVIO, so if you use restart ...
Yes?
What could happen?

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/1zb-00QHMl9j7U68wSYcxh6-cvhwLStfrZBUS4MVbpzt7jn7AhsuuRWLbc7S7NBRKW4pm6bhB_UBTJfXeb8-UwBzIi_Q3Ef6w7LH2_rWeMhLl53_1g3eXW9dt8_dT2oTnpw-aXSmwvIL8ItOaJ7PKelZ0R9tpu4IjDhX1_TPLiRLyqr348RvoYq10pIJLwmkOAy3j7-yweSAik2BZHtoiuM4w2x7_Pzh2gggvuPYCbItyAU9IP1NiUfmjKjnDiu4PTO9SwS2quEiwjNgv-mtGYYBt9w976IT-Uukhk-Hp68AmSemHX_yzWH_acah3r7QMv41jUivZZHc8GOVZXjYQ8GTALMPyECZeLTZefNxupnglIcTuZ4yadWc6yneHOvGj/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

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

[Seymour J Metz]

S0C4 in your programs, IBM software or 3rd party software? Details?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of Rob 
JACKSON 
Sent: Wednesday, August 29, 2018 11:16 AM
To: IBM-MAIN@listserv.ua.edu
Subject: ALLOWUSERKEYCSA

I have been tasked with 'Preparing for the removal of support for user key 
common areas (Recommended, as of V2R3)'.  I have been testing setting 
ALLOWUSERKEYCSA to NO in the DIAGxx member and have encountered sporadic errors 
(0C4, etc).  Is there anyone that might be able to offer any suggestions 
relative to this issue.

Thanks,
Rob Jackson
rwjackso...@msn.com
Cell: (615) 689-1435

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

[Jousma, David]

Do you have SAS and MXG at your location?  If so, I run a weekly SAS job that 
reads SMF30 data (from a PDB) and produces a report.   We do have a few items 
to take care of before z/OS 2.4 that are being worked on.

DATA LIMIT;  
SET PDB1.SMFINTRV PDB2.SMFINTRV PDB3.SMFINTRV PDB4.SMFINTRV  
PDB5.SMFINTRV PDB6.SMFINTRV PDB7.SMFINTRV ;  
IF CPUTM NE .  ; 
 IF SMF30_RAXFLAGS='80'X THEN DELETE;
/* 1000 = 80 = AUDIT ON  */  
/* 1001 = 90 = CHANGE KEY*/  
/* 1010 = A0 = CADS USAGE*/  
/* 1011 = B0 = CADS+CHANGE KEY   */  
/* 1100 = C0 = CSA USAGE */  
/* 1101 = D0 = CSA+CHANGE KEY*/  
/* 1110 = E0 = CSA+CADS  */  
/*  = F0 = CSA+CADS+CHANGEKEY*/  
 IF SMF30_RAXFLAGS='90'X THEN USERKEY='CHGKEY' ; 
 IF SMF30_RAXFLAGS='A0'X THEN USERKEY='CADS' ;   
 IF SMF30_RAXFLAGS='B0'X THEN USERKEY='CADS+CHGKEY' ;
 IF SMF30_RAXFLAGS='C0'X THEN USERKEY='CSA' ;
 IF SMF30_RAXFLAGS='D0'X THEN USERKEY='CSA+CHGKEY' ; 
 IF SMF30_RAXFLAGS='E0'X THEN USERKEY='CSA+CADS' ;   
 IF SMF30_RAXFLAGS='F0'X THEN USERKEY='CSA+CADS+CHGKEY' ;
RUN; 
 PROC MEANS DATA=LIMIT SUM NWAY MISSING NONOBS PRINT;
   CLASS  SYSTEM JOB PROGRAM SMF30_RAXFLAGS USERKEY;
   VAR CPUTM;   
OUTPUT OUT=POSTAV1(DROP=_TYPE_) SUM = GCPU  ;   

PROC PRINT DATA=POSTAV1;
TITLE 'SMF30_USERKEY';  
ID SYSTEM PROGRAM SMF30_RAXFLAGS USERKEY ;  
VAR JOB;
RUN;

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob JACKSON
Sent: Wednesday, August 29, 2018 11:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ALLOWUSERKEYCSA

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

I have been tasked with 'Preparing for the removal of support for user key 
common areas (Recommended, as of V2R3)'.  I have been testing setting 
ALLOWUSERKEYCSA to NO in the DIAGxx member and have encountered sporadic errors 
(0C4, etc).  Is there anyone that might be able to offer any suggestions 
relative to this issue.

Thanks,
Rob Jackson
rwjackso...@msn.com
Cell: (615) 689-1435

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

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

ALLOWUSERKEYCSA

[Rob JACKSON]

I have been tasked with 'Preparing for the removal of support for user key 
common areas (Recommended, as of V2R3)'.  I have been testing setting 
ALLOWUSERKEYCSA to NO in the DIAGxx member and have encountered sporadic errors 
(0C4, etc).  Is there anyone that might be able to offer any suggestions 
relative to this issue.

Thanks,
Rob Jackson
rwjackso...@msn.com
Cell: (615) 689-1435

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

Re: 0,clpa

[R.S.]

W dniu 2018-08-29 o 16:57, Seymour J Metz pisze:

FSVO safe. CLPA implies CVIO, so if you use restart ...

Yes?
What could happen?

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Zowe for systems programmer ?

[Matt Hogstrom]

This is a good point.  For PDS what would be ideal is that you checkout a 
member and when saving it perform a diff / merge (while holding the ENQ) for a 
short period of time.  Not a long hold that will eventually cause issues with 
ENQs that were requested and not released in a timely manner.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On Aug 29, 2018, at 7:16 AM, Jerry Callen  wrote:
> 
> 
> 
> The whole idea of holding a lock on a file while a human being slowly edits 
> it is so 1960s. 
> 
> Since at least the mid 1970s, editors like emacs have loaded the file for 
> editing and noted the timestamp. When the user attempts to save the file. the 
> timestamp is checked again, and if it changed, the user is asked what to do.
> 
> And, of course, if you use a distributed source control system like git, 
> handling merge conflicts is a built-in and normal part of the process.
> 
> It's very easy to imagine a zowe plugin that backs a source PDS with a git 
> repo on a server (GitHub/BitBucket) and integrates editing with the whole git 
> ecosystem of branches and pull requests. 
> 
> I say again: z/OS systems are too complex and mission-critical for us to 
> continue using outdated tooling and engineering processes to maintain them.
> 
> 
> 
> --
> 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: 0,clpa

[Seymour J Metz]

FSVO safe. CLPA implies CVIO, so if you use restart ...


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
R.S. 
Sent: Wednesday, August 29, 2018 6:56 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: 0,clpa

My $0.02:
CLPA vs no CLPA is matter of less than minute in IPL time (30-40s last
time I checked). So, I always use CLPA and sleep safe.

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/16z8cp_8ZB-4OCaddV5wfrWLPbL8M5wwnFda_pbH-lHIzE_-xWLsUA2Y-Vdiq7JuZUKPNo63npW5mIF2AtkL0Z3llPxV140Gvl6EMJ4WT42pgU2kAFS7_ROeuni6w6h8lfD2Bbq8-yawrI02vA_ujVnuuBkffhv-NrzH9lotwD-MA7GgenWhWs2BLjEB3sbXD-XWbCY2utaJpWMy8pnz37WB6wWRknVD0gCLAmcizC-bIddtJwHqNiobXgUUoFZnVHVBU15peaqWA33b0rQ-RwX5KBycDqlgP4W1jrN8VfWUzpt0tqytHhI0uCyROu-OnkOe-WFbCQVTeFqtmbAhya9OWXppbsPQELntiuRieSurl5KfOTmb1KpQSj8c9GYG_/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. 
Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2018 r. wynosi 
169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,http://secure-web.cisco.com/16z8cp_8ZB-4OCaddV5wfrWLPbL8M5wwnFda_pbH-lHIzE_-xWLsUA2Y-Vdiq7JuZUKPNo63npW5mIF2AtkL0Z3llPxV140Gvl6EMJ4WT42pgU2kAFS7_ROeuni6w6h8lfD2Bbq8-yawrI02vA_ujVnuuBkffhv-NrzH9lotwD-MA7GgenWhWs2BLjEB3sbXD-XWbCY2utaJpWMy8pnz37WB6wWRknVD0gCLAmcizC-bIddtJwHqNiobXgUUoFZnVHVBU15peaqWA33b0rQ-RwX5KBycDqlgP4W1jrN8VfWUzpt0tqytHhI0uCyROu-OnkOe-WFbCQVTeFqtmbAhya9OWXppbsPQELntiuRieSurl5KfOTmb1KpQSj8c9GYG_/http%3A%2F%2Fwww.mBank.pl,
 e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th 
Commercial Division of the National Court Register, KRS 025237, NIP: 
526-021-50-88. Fully paid-up share capital amounting to PLN 169,248,488 as at 1 
January 2018.

--
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: $HASP568 - Connect to a Unkown APPL

[Cieri, Anthony]

Do you receive the same error messages if you start the connection 
manually??

$S N,A=APPL01



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gilson Cesar de Oliveira
Sent: Tuesday, August 28, 2018 9:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: $HASP568 - Connect to a Unkown APPL

Dear list:

  We have configured an NJE connection using the following statements in JES2 
PARM:

APPL(APPL01)   NODE=31 

CONNECT  NODEA=1,MEMBA=1,NODEB=31,MEMBB=1

N(31)   NAME=NODE01,PATHMGR=YES,CONNECT=(YES,30)

 In VTAMLST we have the following definitions:

 VBUILD  TYPE=CDRSC  
  NETWORK NETID=NETB
APPL01CDRSC   ==> Remote Node

My NETID is NETA
   VBUILD  TYPE=APPL 
LCLNJE11  APPLVPACING=5,AUTH=ACQ,   
   DLOGMOD=JESMODE,MODETAB=JES2MODE



I'm receiving the message $HASP568 with the following content:

$HASP568 NODE=NODE01 - AUTOMATIC CONNECT (APPL=NODE01)

and VTAM messages with sense code 087D0001 with the following contents:

IST663I  INIT OTHER REQUEST   FAILED  , SENSE=087D0001   
IST664I  REAL  OLU=NETA.LCLNJE11 ALIAS DLU=NETA.NODE01 

I'd like to know why the connection retry is using node name instead of APPL 
name as defined in JES2 parm ??

We are at z/OS V2R2.

Thanks in advance for any help.

Regards,

Gilson Cesar

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

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

Re: [External] Re: cross LPAR priority and cycle stealing

[Pommier, Rex]

Mike,

Sorry, my bad - I wasn't clear in my original note.  I'm running both 
production and test work on both LPARs, but at different times.  I can have any 
mix of production and test work running on both sides simultaneously.  I was 
hoping for a way of dynamically swinging CPU resources to the LPAR running the 
production work and allowing the test work to wait, regardless of which LPAR 
each component is on.

Thanks for the suggestion,

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Tuesday, August 28, 2018 5:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: cross LPAR priority and cycle stealing

Hard cap the test system, soft cap the production system?  Then the
test system can't exceed its percent, even if the CPU is not 100%.
The soft cap would allow the production system to get extra cycles if
the test system isn't using its full share.
On Tue, Aug 28, 2018 at 4:13 PM Martin Packer  wrote:
>
>
> Then the two WLMs can’t cooperate - and aren’t even aware of each other’s
> state. :-(
>
> Manual shifting the weights - via BCPii - might be doable.
>
> Cheers, Martin
>
> Sent from my iPad
>
> > On 28 Aug 2018, at 22:11, Pommier, Rex  wrote:
> >
> > Hi Martin,
> >
> > Sorry, no sysplex.
> >
> > Rex
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> > Sent: Tuesday, August 28, 2018 3:59 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: [External] Re: cross LPAR priority and cycle stealing
> >
> >
> >
> > Are these LPARs in the same Sysplex? Two beneficial effects if they are:
> >
> > 1) You could - with IRD Weight Management - have weights shifted between
> > the LPARs.
> >
> > 2) Sysplex PI for important works comes into play.
> >
> > Cheers, Martin
> >
> > Sent from my iPad
> >
> >> On 28 Aug 2018, at 21:52, Pommier, Rex  wrote:
> >>
> >> Hello list,
> >>
> >> Hypothetical scenario is a single machine with 2 LPARs on it, each LPAR
> > is defined as having 50% of the capacity of the entire machine, uncapped
> > across the board.  In this scenario, if both LPAR1 and LPAR2 are running
> > flat out, each LPAR will take 50% of the machine.  If one of the LPARs is
> > busy and the other isn't doing anything, the busy LPAR will "steal"
> cycles
> > from the not busy one.  That's the easy part.  Here's where my thoughts
> get
> > fuzzy.  Is there a way to differentiate between high priority work on one
> > LPAR and low priority work on the other LPAR.  Here's what I'd like to
> do:
> > Say I'm running a bunch of production on one LPAR and a bunch of test
> work
> > on the other one.  I'd like to be able to steal cycles from the test LPAR
> > and give them to the production one.  I know WLM handles this within an
> > LPAR, making sure the high priority work gets the cycles it needs, but is
> > there a mechanism where I can do this across multiple LPARs?  If there
> is,
> > can somebody point me to the right place for learning how to configure
> this
> > to happen automatically?
> >>
> >> I have higher and lower priority work alternating between multiple LPARs
> > and would like the machine to be able to better balance the workloads so
> > that regardless of which LPAR the high priority work is on, it gets the
> CPU
> > necessary.
> >>
> >> TIA,
> >>
> >> Rex
> >>
> >>
> >> 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
> >> Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
> >
> > --
> > 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 

Re: Zowe for systems programmer ?

[Jerry Callen]

The whole idea of holding a lock on a file while a human being slowly edits it 
is so 1960s. 

Since at least the mid 1970s, editors like emacs have loaded the file for 
editing and noted the timestamp. When the user attempts to save the file. the 
timestamp is checked again, and if it changed, the user is asked what to do.

And, of course, if you use a distributed source control system like git, 
handling merge conflicts is a built-in and normal part of the process.

It's very easy to imagine a zowe plugin that backs a source PDS with a git repo 
on a server (GitHub/BitBucket) and integrates editing with the whole git 
ecosystem of branches and pull requests. 

I say again: z/OS systems are too complex and mission-critical for us to 
continue using outdated tooling and engineering processes to maintain them.



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

Re: Encryption keys and EM waves

[Tomasz Rola]

On Wed, Aug 29, 2018 at 02:00:39PM +0200, R.S. wrote:
[...]
> 
> Note: the effort paid for the attack depends on expected value. And
> attacker usually choose the weakest link in the chain, usually
> people.

Bingo.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.  **
** As the answer, master did "rm -rif" on the programmer's home**
** directory. And then the C programmer became enlightened...  **
** **
** Tomasz Rola  mailto:tomasz_r...@bigfoot.com **

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

GSE UK Conference - Speaker Slots

[Leanne Wilson]

The agenda for the GSE UK Annual Conference - Large Systems stream is almost 
full!

We have 3 presentation slots remaining! If you want to get involved contact 
Leanne Wilson(lean...@rsmpartners.com)

This event will be held from the 5th – 7th November 2018 at Whittlebury Hall.



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

Re: cross LPAR priority and cycle stealing

[Allan Staller]

What you are describing is the behavior of WLM in a SYSPLEX.
You do not say if the 2 lpars are members of the same sysplex.

EWLM (Enterprise WLM) might be of some assistance here. I am not that familiar 
with EWLM and its capabilities.

HTH,
-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Tuesday, August 28, 2018 3:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: cross LPAR priority and cycle stealing

Hello list,

Hypothetical scenario is a single machine with 2 LPARs on it, each LPAR is 
defined as having 50% of the capacity of the entire machine, uncapped across 
the board.  In this scenario, if both LPAR1 and LPAR2 are running flat out, 
each LPAR will take 50% of the machine.  If one of the LPARs is busy and the 
other isn't doing anything, the busy LPAR will "steal" cycles from the not busy 
one.  That's the easy part.  Here's where my thoughts get fuzzy.  Is there a 
way to differentiate between high priority work on one LPAR and low priority 
work on the other LPAR.  Here's what I'd like to do:  Say I'm running a bunch 
of production on one LPAR and a bunch of test work on the other one.  I'd like 
to be able to steal cycles from the test LPAR and give them to the production 
one.  I know WLM handles this within an LPAR, making sure the high priority 
work gets the cycles it needs, but is there a mechanism where I can do this 
across multiple LPARs?  If there is, can somebody point me to the right place 
for learning how to configure this to happen automatically?

I have higher and lower priority work alternating between multiple LPARs and 
would like the machine to be able to better balance the workloads so that 
regardless of which LPAR the high priority work is on, it gets the CPU 
necessary.

TIA,

Rex


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

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

Re: Encryption keys and EM waves

[R.S.]

IMHO this is another example of hypothetically possible attack method, 
but it will be never used in real world.
There are several "attacks" which are quite popular in terms people talk 
about them, airline magazines write about it, but there is no evidence 
any of them was ever successfully used. For some of them feasibility was 
tested in laboratory conditions, some of them remain purely theoretical.


Note: the effort paid for the attack depends on expected value. And 
attacker usually choose the weakest link in the chain, usually people.


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: Zowe for systems programmer ?

[Tom Marchant]

On Tue, 28 Aug 2018 16:41:40 -0400, Gord Tomlin wrote:

>"plays well with the other children, iff requested to do so."

That is the question. Does Zowe request that it do so?

-- 
Tom Marchant

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

Re: 0,clpa

[R.S.]

My $0.02:
CLPA vs no CLPA is matter of less than minute in IPL time (30-40s last 
time I checked). So, I always use CLPA and sleep safe.


--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

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, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2018 r. wynosi 169.248.488 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169,248,488 as at 1 January 2018.

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

Re: [External] Re: cross LPAR priority and cycle stealing

[Vernooij, Kees (ITOPT1) - KLM]

We did some investigation in the past.
AFAIK, there are several tools to manage the CP capacity between LPARs that are 
not in a sysplex:
IBMs Group capacity (Free!) and zCost: do not what you look for.
BMCs tool iCap (it seems to be called TrueSight Capacity Optimization now) 
takes the PI's and Importance of workload into consideration, so this is what 
you are looking for.
zDynacap (from SDS?) does the same.

Grtn,
Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pommier, Rex
> Sent: 29 August, 2018 0:04
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: cross LPAR priority and cycle stealing
> 
> That's what I was afraid of, but was hoping.
> 
> Thanks, Martin.
> 
> Rex
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Martin Packer
> Sent: Tuesday, August 28, 2018 4:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [External] Re: cross LPAR priority and cycle stealing
> 
> 
> 
> Then the two WLMs can’t cooperate - and aren’t even aware of each
> other’s
> 
> state. :-(
> 
> 
> 
> Manual shifting the weights - via BCPii - might be doable.
> 
> 
> 
> Cheers, Martin
> 
> 
> 
> Sent from my iPad
> 
> 
> 
> > On 28 Aug 2018, at 22:11, Pommier, Rex 
> wrote:
> 
> >
> 
> > Hi Martin,
> 
> >
> 
> > Sorry, no sysplex.
> 
> >
> 
> > Rex
> 
> >
> 
> > -Original Message-
> 
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> 
> Behalf Of Martin Packer
> 
> > Sent: Tuesday, August 28, 2018 3:59 PM
> 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> 
> > Subject: [External] Re: cross LPAR priority and cycle stealing
> 
> >
> 
> >
> 
> >
> 
> > Are these LPARs in the same Sysplex? Two beneficial effects if they
> are:
> 
> >
> 
> > 1) You could - with IRD Weight Management - have weights shifted
> between
> 
> > the LPARs.
> 
> >
> 
> > 2) Sysplex PI for important works comes into play.
> 
> >
> 
> > Cheers, Martin
> 
> >
> 
> > Sent from my iPad
> 
> >
> 
> >> On 28 Aug 2018, at 21:52, Pommier, Rex 
> wrote:
> 
> >>
> 
> >> Hello list,
> 
> >>
> 
> >> Hypothetical scenario is a single machine with 2 LPARs on it, each
> LPAR
> 
> > is defined as having 50% of the capacity of the entire machine,
> uncapped
> 
> > across the board.  In this scenario, if both LPAR1 and LPAR2 are
> running
> 
> > flat out, each LPAR will take 50% of the machine.  If one of the LPARs
> is
> 
> > busy and the other isn't doing anything, the busy LPAR will "steal"
> 
> cycles
> 
> > from the not busy one.  That's the easy part.  Here's where my
> thoughts
> 
> get
> 
> > fuzzy.  Is there a way to differentiate between high priority work on
> one
> 
> > LPAR and low priority work on the other LPAR.  Here's what I'd like to
> 
> do:
> 
> > Say I'm running a bunch of production on one LPAR and a bunch of test
> 
> work
> 
> > on the other one.  I'd like to be able to steal cycles from the test
> LPAR
> 
> > and give them to the production one.  I know WLM handles this within
> an
> 
> > LPAR, making sure the high priority work gets the cycles it needs, but
> is
> 
> > there a mechanism where I can do this across multiple LPARs?  If there
> 
> is,
> 
> > can somebody point me to the right place for learning how to configure
> 
> this
> 
> > to happen automatically?
> 
> >>
> 
> >> I have higher and lower priority work alternating between multiple
> LPARs
> 
> > and would like the machine to be able to better balance the workloads
> so
> 
> > that regardless of which LPAR the high priority work is on, it gets
> the
> 
> CPU
> 
> > necessary.
> 
> >>
> 
> >> TIA,
> 
> >>
> 
> >> Rex
> 
> >>
> 
> >>
> 
> >> 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
> 
> >> Unless stated otherwise above:
> 
> > IBM United Kingdom Limited - Registered in England and Wales with
> number
> 
> 741598.
> 
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 
> 3AU
> 
> >
> 
> >
> 
> > --
> 
>