date:20180709


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 09 July, 2018 12:47
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze:
> > We all have lots of questions about your goals here, but the short
> answer to your question is Yes, sysplex is the answer. I assume that
> your two boxes are already connected in some way as to share access to
> data. Turning such a configuration into a sysplex may require some
> additional hardware, but not a lot.
> >
> > -- If you want a full-function parallel sysplex, you would need to
> create an internal coupling facility LPAR (ICF) in each CEC.
> >
> > -- You would need CF links to connect each ICF to the opposite CEC.
> >
> > -- I think you would also need server timing protocol (STP) to keep
> clocks in synch; I have not tried running without STP.
> 
> STP (or earlier sysplex timer) is mandatory for sysplex, even for basic
> sysplex.
> For production parallel sysplex it is good idea to have standalone CF.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 

In this case: yes, but to be precise: not if you run a sysplex on 1 box. The 
required 'common time source' can then be the time of that machine.
I thought the recommendation of a standalone CF was not current anymore.

Kees.


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

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



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

Re: Task Flow Recorder for CICS

2018-07-09 Thread Cameron Conacher

Actually, I was referring to this product offering from IBM:
https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=54007

Well, I guess this an offering from an IBM Partner.

...Cameron

On Mon, Jul 9, 2018 at 3:04 AM, Timothy Sipples  wrote:

> Cameron Conacher wrote:
>
> >Is anyone out there using IBM’s Task Flow Recorder for CICS?
>
>
>
> Are you referring to this product from AlgoriNet:
>
>
>
> https://www.cicsrecorder.com/tfr
>
>
>
> or something else?
>
>
>
> 
> 
>
> Timothy Sipples
>
> IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
>
> Multi-Geography
>
> E-Mail: sipp...@sg.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Task Flow Recorder for CICS

2018-07-09 Thread ITschak Mugzach

You both referenced the same product. HAven't used it myself, but have some
clients that does and are (very) happy. I think the owner, Ishai, is
monitoring the list, but you can contact him directly at
ishaibi...@yahoo.com.

ITschak

On Mon, Jul 9, 2018 at 1:38 PM Cameron Conacher  wrote:

> Actually, I was referring to this product offering from IBM:
> https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=54007
>
> Well, I guess this an offering from an IBM Partner.
>
> ...Cameron
>
> On Mon, Jul 9, 2018 at 3:04 AM, Timothy Sipples 
> wrote:
>
> > Cameron Conacher wrote:
> >
> > >Is anyone out there using IBM’s Task Flow Recorder for CICS?
> >
> >
> >
> > Are you referring to this product from AlgoriNet:
> >
> >
> >
> > https://www.cicsrecorder.com/tfr
> >
> >
> >
> > or something else?
> >
> >
> >
> > 
> > 
> >
> > Timothy Sipples
> >
> > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
> >
> > Multi-Geography
> >
> > E-Mail: sipp...@sg.ibm.com
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Sysplex between two hardware

2018-07-09 Thread R.S.

W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze:

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of R.S.
Sent: 09 July, 2018 12:47
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware

W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze:

We all have lots of questions about your goals here, but the short

answer to your question is Yes, sysplex is the answer. I assume that
your two boxes are already connected in some way as to share access to
data. Turning such a configuration into a sysplex may require some
additional hardware, but not a lot.

-- If you want a full-function parallel sysplex, you would need to

create an internal coupling facility LPAR (ICF) in each CEC.

-- You would need CF links to connect each ICF to the opposite CEC.

-- I think you would also need server timing protocol (STP) to keep

clocks in synch; I have not tried running without STP.

STP (or earlier sysplex timer) is mandatory for sysplex, even for basic
sysplex.
For production parallel sysplex it is good idea to have standalone CF.

--
Radoslaw Skorupka
Lodz, Poland

In this case: yes, but to be precise: not if you run a sysplex on 1 box. The 
required 'common time source' can then be the time of that machine.
I thought the recommendation of a standalone CF was not current anymore.

Well, I was suggested by the topic - "two different hardware".
Regarding CF and availability - for availability reasons one should 
avoid having CF and z/OS LPAR on the same hardware, which means:

a) at least 3 CPCs (of course CF-only box is much cheaper)
b) use CF structures replication which gives some performance penalty, 
especially for non-local distances.

Regards
--
Radoslaw Skorupka
Lodz, Poland

==

   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.

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

Re: TSO TEST breakpoint subcommand call either looping or not being executed

2018-07-09 Thread Joseph Reichman

Hi

I have gotten the following code to work (with the help of Binyamin) as I will 
list below but the problem is it is only being executed once and I am looping 
thru a number of records
Seems like when I get to DUMBRK OFF +4; GO +4 it is removed and I would like to 
process it for the next iteration of the code

LOAD 'MYTEST.LOAD(TESTPROG)'

 GETMAIN 24 SP(0) LOC(BELOW) EQUATE(RGESVE)  
 GETMAIN 2 SP(0) LOC (BELOW) EQUATE(DUMBRK)

 DUMBRK = X'0700'

AT +4( AT DUMBRK (COPY  RGESVE 14R L(16); OFF +4; GO +4): COPY 14 RGESVE L(16); 
RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG PARM(RGESVE) RETURN(DUMBRK)) 
TITLE('BREAK AT +4')

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Tony Harminc
Sent: Tuesday, July 3, 2018 12:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO TEST breakpoint subcommand call either looping or not being 
executed

On 2 July 2018 at 19:37, Joseph Reichman  wrote:
>> On Jul 2, 2018, at 4:31 PM, Binyamin Dissen  
>> wrote:
>>
>> If I understand you correctly and you repetitively want this to 
>> occur,  you will need:
>>
>> AT +8 (AT +C  (off +c;call ..;go);go)

> Didn’t know you can put in parens to force sequence of execution

It's not that the parentheses are forcing the sequence of evaluation as in a 
programming language. Rather, you can have as many stacked commands as you 
like.  (Well, doubtless there's some limit, but probably based only on the 
total length.)

The second operand of the AT command is one or more commands to be executed 
when the breakpoint is hit. You can have multiple commands separated by 
semicolons, done in sequence. But any of those commands can be a new AT command 
that may or may not be related to the first AT. That's what Binyamin has set up 
for you.

So basically AT looks like this:

AT  (cmd1; cmd2; cmd3...)

and those cmds can be any TEST subcommand. Typically they are things like LIST 
or LISTPSW, but they can also be AT or OFF.

Another thing to think carefully about when doing this kind of thing is where 
your +n is relative to. The first AT you issue will be relative to the current 
qualification, but the deferred AT will be relative to the qualification at the 
time that it is executed, i.e.
when the first AT triggers. If you called a new module, the qualification may 
have changed. In many cases it's best to use a more explicit address such as 
module.csect.+n to be sure. Or you can issue a Q command to change the default.

Tony H.

--
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: Sysplex between two hardware

2018-07-09 Thread Allan Staller


STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex.
For production parallel sysplex it is good idea to have standalone CF.


Not if entire sysplex is in one box. If that is the case, SYSPLEX time is not 
needed.
As long as all participants use the same time source, all will be well.

The issue requiring an ETR is synchronization/tolerization for XCF.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, July 9, 2018 5:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware

W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze:
> We all have lots of questions about your goals here, but the short answer to 
> your question is Yes, sysplex is the answer. I assume that your two boxes are 
> already connected in some way as to share access to data. Turning such a 
> configuration into a sysplex may require some additional hardware, but not a 
> lot.
>
> -- If you want a full-function parallel sysplex, you would need to create an 
> internal coupling facility LPAR (ICF) in each CEC.
>
> -- You would need CF links to connect each ICF to the opposite CEC.
>
> -- I think you would also need server timing protocol (STP) to keep clocks in 
> synch; I have not tried running without STP.

STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex.
For production parallel sysplex it is good idea to have standalone CF.

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pl&data=02%7C01%7Callan.staller%40HCL.COM%7Ca337fe0b86b840b524f408d5e58954cd%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667300404700814&sdata=pf0btoRfi3YbUVX3SPfjI0C%2B%2FTvkSY8yfb8TZDefjXg%3D&reserved=0,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


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

Re: Sysplex between two hardware

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 09 July, 2018 14:26
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze:
> >> -Original Message-
> >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On
> >> Behalf Of R.S.
> >> Sent: 09 July, 2018 12:47
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Sysplex between two hardware
> >>
> >> W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze:
> >>> We all have lots of questions about your goals here, but the short
> >> answer to your question is Yes, sysplex is the answer. I assume that
> >> your two boxes are already connected in some way as to share access
> to
> >> data. Turning such a configuration into a sysplex may require some
> >> additional hardware, but not a lot.
> >>> -- If you want a full-function parallel sysplex, you would need to
> >> create an internal coupling facility LPAR (ICF) in each CEC.
> >>> -- You would need CF links to connect each ICF to the opposite CEC.
> >>>
> >>> -- I think you would also need server timing protocol (STP) to keep
> >> clocks in synch; I have not tried running without STP.
> >>
> >> STP (or earlier sysplex timer) is mandatory for sysplex, even for
> basic
> >> sysplex.
> >> For production parallel sysplex it is good idea to have standalone
> CF.
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
> >>
> > In this case: yes, but to be precise: not if you run a sysplex on 1
> box. The required 'common time source' can then be the time of that
> machine.
> > I thought the recommendation of a standalone CF was not current
> anymore.
> 
> Well, I was suggested by the topic - "two different hardware".
> Regarding CF and availability - for availability reasons one should
> avoid having CF and z/OS LPAR on the same hardware, which means:
> a) at least 3 CPCs (of course CF-only box is much cheaper)
> b) use CF structures replication which gives some performance penalty,
> especially for non-local distances.
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

I disagree with the statement " avoid having CF and z/OS LPAR on the same 
hardware"
Avoiding SPOFs can well be done by z/OS LPARs on both CPCs and 2 CFs on each 
CPC.

The need for " CF structures replication", I suppose you mean System-Managed CF 
Structure Duplexing, is not evident to me either. Since the last upgrade of MQ, 
every structure owner is perfectly able to recover its structures into another 
CF after a CF failure. I don't see much benefit in it, but I see the 
disadvantages you mention.

Kees.

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

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



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

Re: REXX as JCL replacement

Ward wrote:
>What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away.  The point is important, and the basis is a valid concern.  The
conclusion is wrong.  All it takes is understanding the problem and coming
up with creative solutions.  As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts.  This is
done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y.  JOB B has access to Y and needs
exclusive on X.  Neither JOB can proceed until one is canceled, resulting
in lost production.  Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't.  I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities.  I'll share my best
educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to
our subject, happen in this order:

   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
   merged with the submitted JCL.  These are necessary for #2 below.
   2. Substitutions are processed.  This is needed for #3; if DSNs could
   change later, via substitution or IF, the ENQs would be incorrect.
   3. ENQs are obtained on all datasets.
   4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions.  These conventions could include the following, one or the
other may be appropriate depending on the applications' needs:

   - Perform ENQs in a consistent order.  (Left as an exercise for the
   reader.  :-)  )
   - Do all ALLOCations up front, and free all exclusive allocations before
   a second set of ENQs is requested.
   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
   or ALLOC failure, and taking appropriate action to recover/restart/suspend
   processing.  Initial ENQs are not required.  If implemented via a common
   routine, either site or vendor provided, this could be more viable.  A
   little additional coding to support automated restart might be needed; see
   also below on my first attempt at using REXX instead of JCL.
   - Something else.

It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s.  As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern.  E.g. an application where
all data updates are done to DB2 tables and PDSEs.  Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere.  Some smart developer may come to understand this and
provide the missing service.  Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis.  Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers.  At the same time that existing customers are locked
in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems.  This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.

Give it a try.  If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to
streamline your application.  This is not theory.  I have done it, as I
describe in the next paragraph.  AFAIK, you can code SHR for PDSEs in the
common cases.  REWRITE/UPDATE in place is the main exception; you at leas

IBM: Share your experience managing z/OS, z/OSMF & more!

2018-07-09 Thread Iris Rivera

Dear Mainframer,

Please take our survey to help us understand any time consuming or complex
tasks that you experience with managing your z/OS environment.

We'd also like to know if you are using z/OSMF and hear your thoughts on
mainframe operations, DevOps and cloud.

Here's the link to the survey:
https://www.surveygizmo.com/s3/4403313/IBM-z-OS-Survey-2018

We'd appreciate your response by July 20, 2018.

Thanks in advance for your participation!

Regards,
Iris M. Rivera
Design Researcher, z System Software
iriv...@us.ibm.com
@zsurveygirl



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

Re: Sysplex between two hardware

2018-07-09 Thread Mark A. Brooks

The essence of the matter is to ensure that the selected configuration meets 
the availability objectives of the business services supported by the sysplex.  
One must consider the service restoration objectives for the business services 
in light of the potential failures that can occur for a potential choice of 
configuration.  There are many possibilities and different installations will 
of course make different choices based on their own business objectives.  
Choices of standalone CF, or structure duplexing, and the like are really all 
talking about different ways of solving the "failure isolation" issue (wherein 
we might be concerned about the time to restore the business service if we 
simultaneously lose the data in the CF along with the system that produced that 
data).  Each choice has its own advantages and disadvantages; choose the one 
that's right for you.  
--Mark Brooks
--z/OS Sysplex Development

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

Re: TSO TEST breakpoint subcommand call either looping or not being executed

2018-07-09 Thread Walt Farrell

On Mon, 9 Jul 2018 08:29:09 -0400, Joseph Reichman  
wrote:

>I have gotten the following code to work (with the help of Binyamin) as I will 
>list below but the problem is it is only being executed once and I am looping 
>thru a number of records
>Seems like when I get to DUMBRK OFF +4; GO +4 it is removed and I would like 
>to process it for the next iteration of the code
>   
>LOAD 'MYTEST.LOAD(TESTPROG)'
> 
> GETMAIN 24 SP(0) LOC(BELOW) EQUATE(RGESVE)  
> GETMAIN 2 SP(0) LOC (BELOW) EQUATE(DUMBRK)
>
> DUMBRK = X'0700'
>
>AT +4( AT DUMBRK (COPY  RGESVE 14R L(16); OFF +4; GO +4): COPY 14 RGESVE 
>L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG PARM(RGESVE) RETURN(DUMBRK)) 
>TITLE('BREAK AT +4')

Suggestion:
(1) Increase the size of DUMBRK so it can include the instruction located at +4 
in TESTPROG, plus another x'0700'. Set DUMBRK to x'0700', then the instruction 
from TESTPROG, then another x'0700'. Assuming that TESTPROG instuction is 4 
bytes in length, DUMBRK would then be 8 bytes in length.

(2) For the breakpoints, something like the following (untested):

AT +4 (COPY 14R RGESVE L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG 
PARM(RGESVE) RETURN(DUMBRK)) TITLE('BREAK AT +4'))
AT DUMBRK (COPY  RGESVE 14R L(16); GO DUMBRK+2)
AT DUMBRK+6 (GO +8)

-- 
Walt

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

Re: Task Flow Recorder for CICS

2018-07-09 Thread Cameron Conacher

I have exchanged emails with Ishai.
Just curious if anyone has used it, and what their experiences were.
It looks very promising (IMHO).

On Mon, Jul 9, 2018 at 8:17 AM, ITschak Mugzach  wrote:

> You both referenced the same product. HAven't used it myself, but have some
> clients that does and are (very) happy. I think the owner, Ishai, is
> monitoring the list, but you can contact him directly at
> ishaibi...@yahoo.com.
>
> ITschak
>
> On Mon, Jul 9, 2018 at 1:38 PM Cameron Conacher 
> wrote:
>
> > Actually, I was referring to this product offering from IBM:
> > https://www-356.ibm.com/partnerworld/gsd/solutiondetails.do?&solution=
> 54007
> >
> > Well, I guess this an offering from an IBM Partner.
> >
> > ...Cameron
> >
> > On Mon, Jul 9, 2018 at 3:04 AM, Timothy Sipples 
> > wrote:
> >
> > > Cameron Conacher wrote:
> > >
> > > >Is anyone out there using IBM’s Task Flow Recorder for CICS?
> > >
> > >
> > >
> > > Are you referring to this product from AlgoriNet:
> > >
> > >
> > >
> > > https://www.cicsrecorder.com/tfr
> > >
> > >
> > >
> > > or something else?
> > >
> > >
> > >
> > > 
> > > 
> > >
> > > Timothy Sipples
> > >
> > > IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
> > >
> > > Multi-Geography
> > >
> > > E-Mail: sipp...@sg.ibm.com
> > >
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> ITschak Mugzach
> *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
> for Legacy **|  *
>
> --
> 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: REXX as JCL replacement

On Mon, 9 Jul 2018 08:46:56 -0400, Hobart Spitz wrote:
>
>I think that it's important to first understand the characteristics on
>which many people base their thinking that JCL is good and may never go
>away.  The point is important, and the basis is a valid concern.  The
>conclusion is wrong.  All it takes is understanding the problem and coming
>up with creative solutions.  As I describe below, DB2 based applications
>and those that use only PDSEs are likely to be good starting points.
> 
ISPF provides an alternative ENQ mechanism for both Classic PDS and PDSE,
successfully assuming that EXC ENQs will be transitory.  OTOH, LMPUT
requires EXC ENQ, needlessly for PDSE members.

>One valuable feature of z/OS batch processing is that all ENQs for the
>entire JOB are obtained before any step execution actually starts.  This is
>done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
>and needs exclusive access to dataset Y.  JOB B has access to Y and needs
>exclusive on X.  Neither JOB can proceed until one is canceled, resulting
>in lost production.  Despite this being a useful service, there is no TSO
>equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
>SLEEP mechanism to allow for retries.
> 
Unless there's a time limit or loop count limit, this results in similar 
deadlocks.

>...
>When a batch JOB becomes eligible for execution these actions, relevant to
>our subject, happen in this order:
>
>   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
>   merged with the submitted JCL.  These are necessary for #2 below.
>   2. Substitutions are processed.  This is needed for #3; if DSNs could
>   change later, via substitution or IF, the ENQs would be incorrect.
>
Data set aliases break this assumption. 

>   3. ENQs are obtained on all datasets.
>
But for ALIAS names, not RELATED names.

>   4. The EXECs for PGMs are processed, in order, one at a time.
>
At this point an ENQ for the RELATED name is attempted.  There is no
recovery from ENQ failure.

>So any REXX implementation would have either to forgo do initial ENQs, or
>commit to not changing DSNs during processing, or observe certain
>conventions.  These conventions could include the following, one or the
>other may be appropriate depending on the applications' needs:
>
>   - Perform ENQs in a consistent order.  (Left as an exercise for the
>   reader.  :-)  )
>
However effective this is, I doubt that it's practical.  I suspect you feel 
likewise.

>   - Do all ALLOCations up front, and free all exclusive allocations before
>   a second set of ENQs is requested. 
>
"exclusive" doesn't suffice.  Imagine that JOB A has shared access to
dataset X and needs exclusive access to dataset Y.  JOB B has shared
access to Y and needs exclusive on X.  Deadlock occurs.

>   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
>   or ALLOC failure, and taking appropriate action to recover/restart/suspend
>   processing.  Initial ENQs are not required.  If implemented via a common
>   routine, either site or vendor provided, this could be more viable.  A
>   little additional coding to support automated restart might be needed; ...
>
???  SMOP?

>   - Something else.
>
???  Another exercise for the reader?

>...
>   3. The JCL syntax (which is based on that of assembler AFAIK, a highly
>   inappropriate choice) is obscure, unintuitive, irregular, ...
>
Many Assembler facilities were created diachronically with insufficient
design consideration.  Consider the difference in semantics between
macro arguments and SETC arguments.

>   ... and has a steep learning curve.
>
ITYM "shallow" learning curve.  Proficiency is acquired slowly.

>   4. JCL is a barrier to attracting new business to z/OS.  Bad news if you
>   are a vendor. 
>
Yes.

>   6. PROC EXECs, SETs, INCLUDEs cannot be conditional.  Initial ENQs
>   prevent this.  z/OS must know all dataset names to do the ENQs.
>   7. You can not loop or retry, as was done in the application I described
>   above.
>   8. You can't compare strings, do arithmetic, or employ complex logic.
>   9. You can't call a function or return a string value. 
>
Should JCL assimilate HLASM's conditional assembly facility?

>   10. String/SET/PROC value substitution can convoluted.  Do I need a
>   double period and/or a double ampersand?  If you are passing a value down
>   two PROC level, you may have to put in 4 (!) ampersands or quotes to
>   indicate 1.  More than two levels?  Good luck!!  REXX has no such
>   requirement. 
>
Much of this could be resolved by adding HLASM's DOUBLE BIF to JCL.

-- gil

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

Re: Sysplex between two hardware

2018-07-09 Thread R.S.


W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:

The essence of the matter is to ensure that the selected configuration meets the 
availability objectives of the business services supported by the sysplex.  One must 
consider the service restoration objectives for the business services in light of the 
potential failures that can occur for a potential choice of configuration.  There are 
many possibilities and different installations will of course make different choices 
based on their own business objectives.  Choices of standalone CF, or structure 
duplexing, and the like are really all talking about different ways of solving the 
"failure isolation" issue (wherein we might be concerned about the time to 
restore the business service if we simultaneously lose the data in the CF along with the 
system that produced that data).  Each choice has its own advantages and disadvantages; 
choose the one that's right for you.
--Mark Brooks
--z/OS Sysplex Development



However "option c", that means we don't have standalone CF and we do not 
duplex CF structures is not proper one, is it?


Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


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

Re: Sysplex between two hardware

2018-07-09 Thread Allan Staller

That configuration is perfectly valid. You are merely missing some(but not all) 
 redundancy and recovery options.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, July 9, 2018 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Sysplex between two hardware

W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> The essence of the matter is to ensure that the selected configuration meets 
> the availability objectives of the business services supported by the 
> sysplex.  One must consider the service restoration objectives for the 
> business services in light of the potential failures that can occur for a 
> potential choice of configuration.  There are many possibilities and 
> different installations will of course make different choices based on their 
> own business objectives.  Choices of standalone CF, or structure duplexing, 
> and the like are really all talking about different ways of solving the 
> "failure isolation" issue (wherein we might be concerned about the time to 
> restore the business service if we simultaneously lose the data in the CF 
> along with the system that produced that data).  Each choice has its own 
> advantages and disadvantages; choose the one that's right for you.
> --Mark Brooks
> --z/OS Sysplex Development
>

However "option c", that means we don't have standalone CF and we do not duplex 
CF structures is not proper one, is it?

Regards
--
Radoslaw Skorupka
Lodz, Poland

==

--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pl&data=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229&sdata=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3D&reserved=0,
 e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział 
Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 
025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.

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

Re: Friday - off topic - human factors and TN3270

2018-07-09 Thread Porowski, Kenneth

I actually have one, should have bought 2 as mine is used and seriously grungy.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, July 07, 2018 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Friday - off topic - human factors and TN3270

1993 or so, it would appear from this page. (Mind the wrap.)

https://books.google.com/books?id=O3xyvDOfru0C&pg=PA132

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Saturday, July 7, 2018 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday - off topic - human factors and TN3270

Obvious typo. Which leads me to think it was typed in. A true mainframer
eschewing the
new-fangled mouse cut and paste. :)

http://archive.computerhistory.org/resources/access/physical-object/2009/04/
102682822.01.01.lg.jpg


In article
 you
wrote:
> 404, alas...

> On Sat, Jul 7, 2018 at 11:18 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:

> > Porowski, Kenneth wrote:
> >
> > >"Bud and Elliot Grundt develop the first Mainframe Mouse."
> >
>http://archive.computerhistory.org/resources/cccess/physical-object/2009/
> > 04/102682822.01.01.lg.jpg
> >
> > Rats! That is a good picture of that "painframe" rat! ;-)
> >
> > Hmmm, is the numbr 102682822 shown, the actual number of those
> > Mainframe Mouse manufactured?
> >
> > Will it hurts when that rat driver drives over those power cables? ;-)
> >
> > Thanks Kenneth for bringing a great smile! ;-)
> >
> > Please keep up posting on IBM-MAIN! ;-)
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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: Friday - off topic - human factors and TN3270

2018-07-09 Thread Porowski, Kenneth

And I did cut and paste, no idea how the 'a' changed to a 'c'.

If I can't spell it in 8 characters or less I use cut/paste.

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

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Monday, July 09, 2018 10:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Friday - off topic - human factors and TN3270

I actually have one, should have bought 2 as mine is used and seriously grungy.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, July 07, 2018 8:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Friday - off topic - human factors and TN3270

1993 or so, it would appear from this page. (Mind the wrap.)

https://books.google.com/books?id=O3xyvDOfru0C&pg=PA132

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Don Poitras
Sent: Saturday, July 7, 2018 3:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Friday - off topic - human factors and TN3270

Obvious typo. Which leads me to think it was typed in. A true mainframer
eschewing the
new-fangled mouse cut and paste. :)

http://archive.computerhistory.org/resources/access/physical-object/2009/04/
102682822.01.01.lg.jpg

In article
 you
wrote:
> 404, alas...

> On Sat, Jul 7, 2018 at 11:18 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:

> > Porowski, Kenneth wrote:
> >
> > >"Bud and Elliot Grundt develop the first Mainframe Mouse."
> >
>http://archive.computerhistory.org/resources/cccess/physical-object/2009/
> > 04/102682822.01.01.lg.jpg
> >
> > Rats! That is a good picture of that "painframe" rat! ;-)
> >
> > Hmmm, is the numbr 102682822 shown, the actual number of those
> > Mainframe Mouse manufactured?
> >
> > Will it hurts when that rat driver drives over those power cables? ;-)
> >
> > Thanks Kenneth for bringing a great smile! ;-)
> >
> > Please keep up posting on IBM-MAIN! ;-)
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> --
> zMan -- "I've got a mainframe and I'm not afraid to use it"
--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

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

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

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

Re: Sysplex between two hardware

That was my point: you don't miss a thing.
You are fully redundant with CFs in each CPC.
And since the latest MQ update, all applications are capable of recovering 
their structures, so recovery is guaranteed in case of a CF failure.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 09 July, 2018 16:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> That configuration is perfectly valid. You are merely missing some(but
> not all)  redundancy and recovery options.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: Monday, July 9, 2018 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> > The essence of the matter is to ensure that the selected configuration
> meets the availability objectives of the business services supported by
> the sysplex.  One must consider the service restoration objectives for
> the business services in light of the potential failures that can occur
> for a potential choice of configuration.  There are many possibilities
> and different installations will of course make different choices based
> on their own business objectives.  Choices of standalone CF, or
> structure duplexing, and the like are really all talking about different
> ways of solving the "failure isolation" issue (wherein we might be
> concerned about the time to restore the business service if we
> simultaneously lose the data in the CF along with the system that
> produced that data).  Each choice has its own advantages and
> disadvantages; choose the one that's right for you.
> > --Mark Brooks
> > --z/OS Sysplex Development
> >
> 
> However "option c", that means we don't have standalone CF and we do not
> duplex CF structures is not proper one, is it?
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
> 
> 
> 
> 
> ==
> 
> 
> --
>  Treść tej wiadomości może zawierać informacje prawnie chronione Banku
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie
> jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do
> jej przekazania adresatowi, informujemy, że jej rozpowszechnianie,
> kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze
> jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę
> wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając
> odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej
> kopie wydrukowane lub zapisane na dysku.
> 
>  This e-mail may contain legally privileged information of the Bank and
> is intended solely for business use of the addressee. This e-mail may
> only be received by the addressee and may not be disclosed to any third
> parties. If you are not the intended addressee of this e-mail or the
> employee authorized to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility
> in your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
> 
>  mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pl&da
> ta=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d%
> 7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229&sdat
> a=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3D&reserved=0,
> e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział
> Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS
> 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r.
> kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488
> złotych.
> 
> 
> --
> 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, o

Re: REXX as JCL replacement

2018-07-09 Thread Seymour J Metz

 1. I don't recall anybody on IBM-MAIN claims that JCL is good.

 2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

 2. Sleep does not address the deadly embrace problem.

 3. PDSE does not solve the problem.


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


From: IBM Mainframe Discussion List  on behalf of 
Hobart Spitz 
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Ward wrote:
>What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away.  The point is important, and the basis is a valid concern.  The
conclusion is wrong.  All it takes is understanding the problem and coming
up with creative solutions.  As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts.  This is
done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y.  JOB B has access to Y and needs
exclusive on X.  Neither JOB can proceed until one is canceled, resulting
in lost production.  Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't.  I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities.  I'll share my best
educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to
our subject, happen in this order:

   1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
   merged with the submitted JCL.  These are necessary for #2 below.
   2. Substitutions are processed.  This is needed for #3; if DSNs could
   change later, via substitution or IF, the ENQs would be incorrect.
   3. ENQs are obtained on all datasets.
   4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions.  These conventions could include the following, one or the
other may be appropriate depending on the applications' needs:

   - Perform ENQs in a consistent order.  (Left as an exercise for the
   reader.  :-)  )
   - Do all ALLOCations up front, and free all exclusive allocations before
   a second set of ENQs is requested.
   - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
   or ALLOC failure, and taking appropriate action to recover/restart/suspend
   processing.  Initial ENQs are not required.  If implemented via a common
   routine, either site or vendor provided, this could be more viable.  A
   little additional coding to support automated restart might be needed; see
   also below on my first attempt at using REXX instead of JCL.
   - Something else.

It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s.  As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern.  E.g. an application where
all data updates are done to DB2 tables and PDSEs.  Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere.  Some smart developer may come to understand this and
provide the missing service.  Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis.  Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers.  At the same time that existing customers are locked
in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems.  This would most
likely apply DB2 base applications, where all

Re: TSO TEST breakpoint subcommand call either looping or not being executed

2018-07-09 Thread Joseph Reichman

That’s working thanks I have to increase dumbrk to 10 bytes as to taking into 
consideration 6 byte instructions I have initialize it to nops 

Joe Reichman
170-10 73 rd ave 
Fresh meadows NY 11366

> On Jul 9, 2018, at 9:57 AM, Walt Farrell  wrote:
> 
>> On Mon, 9 Jul 2018 08:29:09 -0400, Joseph Reichman  
>> wrote:
>> 
>> I have gotten the following code to work (with the help of Binyamin) as I 
>> will list below but the problem is it is only being executed once and I am 
>> looping thru a number of records
>> Seems like when I get to DUMBRK OFF +4; GO +4 it is removed and I would like 
>> to process it for the next iteration of the code
>> 
>> LOAD 'MYTEST.LOAD(TESTPROG)'
>> 
>> GETMAIN 24 SP(0) LOC(BELOW) EQUATE(RGESVE)  
>> GETMAIN 2 SP(0) LOC (BELOW) EQUATE(DUMBRK)
>> 
>> DUMBRK = X'0700'
>> 
>> AT +4( AT DUMBRK (COPY  RGESVE 14R L(16); OFF +4; GO +4): COPY 14 RGESVE 
>> L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG PARM(RGESVE) 
>> RETURN(DUMBRK)) TITLE('BREAK AT +4')
> 
> Suggestion:
> (1) Increase the size of DUMBRK so it can include the instruction located at 
> +4 in TESTPROG, plus another x'0700'. Set DUMBRK to x'0700', then the 
> instruction from TESTPROG, then another x'0700'. Assuming that TESTPROG 
> instuction is 4 bytes in length, DUMBRK would then be 8 bytes in length.
> 
> (2) For the breakpoints, something like the following (untested):
> 
> AT +4 (COPY 14R RGESVE L(16); RGEAVE+10=C'PARM1'; CALL TESTPROG.TESTPROG 
> PARM(RGESVE) RETURN(DUMBRK)) TITLE('BREAK AT +4'))
> AT DUMBRK (COPY  RGESVE 14R L(16); GO DUMBRK+2)
> AT DUMBRK+6 (GO +8)
> 
> -- 
> Walt
> 
> --
> 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: SUSE splits from Microfocus

2018-07-09 Thread Steve Smith

I was at EDS ("worked at" doesn't quite cover it, "belonged to" is closer)
in the early 80s, at the Forest Lane campus.  Never actually met HRP, but
did bump into him a couple of times.  It was a big transition time for my
career, moving from operator to tech. support to systems programming.

Like everything looking like nails when you have a new hammer, WAAPDSUT was
something of a Swiss Army knife, and we certainly used it to do a whole lot
of things.  Spent the last few months there arguing with Cheryl Watson
about how to run CICS (what can I say, I was young and stupid :-)).

sas

On Fri, Jul 6, 2018 at 8:36 PM, Bill Johnson <
0047540adefe-dmarc-requ...@listserv.ua.edu> wrote:

> I worked for Packard Electric in Warren, Ohio when GM bought EDS. They
> transitioned most of us to the Charlotte data center. Took a couple of
> years. I was in Ops at the time but transitioned to development staying in
> Warren, graduated from college, and left EDS in 1988. Been a long and
> winding road since.
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, July 6, 2018, 7:44 PM, Mike Shaw 
> wrote:
>
> On 7/6/2018 7:18 PM, Bill Johnson wrote:
> > Holy crap, now there is a blast from my EDS past. I was a member of the
> first GM/EDS transition back in Feb 23, 1986.
> >
>
> I am ex-EDS too...1976 to 1978, back when Ross Perot still gave a speech
> to each graduating SED class...
>
> ...I would like to know who owns WAAPDSUT now...EDS sold it for a while
> under the name STANFAST utilities...
>
> Mike Shaw
> MVS/QuickRef Support Group
> Chicago-Soft, Ltd.
>
> --
> 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
>



-- 
sas

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

Re: Sysplex between two hardware

2018-07-09 Thread Jesse 1 Robinson

I stand by my original reply. All you need is an ICF LPAR in each CEC and 
physical links to connect the CECs, together with full CF structure duplexing. 
We have run this way for decades. Suffered two (!) CEC failures over the years. 
After repairing the failed CEC, we resumed normal operation with *no* recovery 
actions needed because all sensitive structures were duplexed in the 
non-failing CEC. 

Our standalone CFs went away with the 9674. 

.
.
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 Vernooij, Kees (ITOPT1) - KLM
Sent: Monday, July 09, 2018 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Sysplex between two hardware

That was my point: you don't miss a thing.
You are fully redundant with CFs in each CPC.
And since the latest MQ update, all applications are capable of recovering 
their structures, so recovery is guaranteed in case of a CF failure.

Kees.


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Allan Staller
> Sent: 09 July, 2018 16:33
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> That configuration is perfectly valid. You are merely missing some(but 
> not all)  redundancy and recovery options.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of R.S.
> Sent: Monday, July 9, 2018 9:20 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Sysplex between two hardware
> 
> W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze:
> > The essence of the matter is to ensure that the selected 
> > configuration
> meets the availability objectives of the business services supported 
> by the sysplex.  One must consider the service restoration objectives 
> for the business services in light of the potential failures that can 
> occur for a potential choice of configuration.  There are many 
> possibilities and different installations will of course make 
> different choices based on their own business objectives.  Choices of 
> standalone CF, or structure duplexing, and the like are really all 
> talking about different ways of solving the "failure isolation" issue 
> (wherein we might be concerned about the time to restore the business 
> service if we simultaneously lose the data in the CF along with the 
> system that produced that data).  Each choice has its own advantages 
> and disadvantages; choose the one that's right for you.
> > --Mark Brooks
> > --z/OS Sysplex Development
> >
> 
> However "option c", that means we don't have standalone CF and we do 
> not duplex CF structures is not proper one, is it?
> 
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland


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

Re: REXX as JCL replacement

On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz  wrote:

>  1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
There were such statements as "I like JCL", or similar.

>
>  2. Creative solutions are good if they solve the actual problem, not
> just an imaginary or irrelevant one.
>
I don't think anything I said was either.

>
>  2. Sleep does not address the deadly embrace problem.
>
I didn't claim that.  It is needed to do your up front ENQs in REXX.  You
still might have to exit with an error COND CODE if you can't get the ENQ
you need.  A single ALLOC does not give the TSU a message or time to free
up the dataset.

>
>  3. PDSE does not solve the problem.
>
You'll have to explain that.  From my reading of the doc., you can have
multiple readers and writers, in the same step or different JOBs opening
different members at the same time, provided the same member is not open
for OUTPUT by two different DCBs or JOBs/TSUs.  All this with SHaRed
access, i.e. no DISP=OLD or equivalent.  Note that I said, perhaps not
clearly enough, that the entire application, all foreground and background
accesses, must be SHaRed.  What am I missing?

Thanks.

>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Hobart Spitz 
> Sent: Monday, July 9, 2018 8:46 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Ward wrote:
> >What are the problems (perceived or real) that will be resolved by
> replacing JCL with REXX?
>
> I think that it's important to first understand the characteristics on
> which many people base their thinking that JCL is good and may never go
> away.  The point is important, and the basis is a valid concern.  The
> conclusion is wrong.  All it takes is understanding the problem and coming
> up with creative solutions.  As I describe below, DB2 based applications
> and those that use only PDSEs are likely to be good starting points.
>
> One valuable feature of z/OS batch processing is that all ENQs for the
> entire JOB are obtained before any step execution actually starts.  This is
> done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
> and needs exclusive access to dataset Y.  JOB B has access to Y and needs
> exclusive on X.  Neither JOB can proceed until one is canceled, resulting
> in lost production.  Despite this being a useful service, there is no TSO
> equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
> SLEEP mechanism to allow for retries.
>
> Other repliers have answered Ward's question well, I was going to cut some
> of the text out of my draft, but didn't.  I think it is important to
> understand what z/OS batch processing does, and where possible, why, so we
> don't trivialize the effort or miss easy opportunities.  I'll share my best
> educated guesses with respect to the subject at hand.
>
> When a batch JOB becomes eligible for execution these actions, relevant to
> our subject, happen in this order:
>
>1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
>merged with the submitted JCL.  These are necessary for #2 below.
>2. Substitutions are processed.  This is needed for #3; if DSNs could
>change later, via substitution or IF, the ENQs would be incorrect.
>3. ENQs are obtained on all datasets.
>4. The EXECs for PGMs are processed, in order, one at a time.
>
> So any REXX implementation would have either to forgo do initial ENQs, or
> commit to not changing DSNs during processing, or observe certain
> conventions.  These conventions could include the following, one or the
> other may be appropriate depending on the applications' needs:
>
>- Perform ENQs in a consistent order.  (Left as an exercise for the
>reader.  :-)  )
>- Do all ALLOCations up front, and free all exclusive allocations before
>a second set of ENQs is requested.
>- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
>or ALLOC failure, and taking appropriate action to
> recover/restart/suspend
>processing.  Initial ENQs are not required.  If implemented via a common
>routine, either site or vendor provided, this could be more viable.  A
>little additional coding to support automated restart might be needed;
> see
>also below on my first attempt at using REXX instead of JCL.
>- Something else.
>
> It might be helpful to know if, with all the changes and advancements,
> deadly-embraces are still the issue it was in the 1960s-1980s.  As I
> explain below, an application that does not update any sequential datasets
> or PDSs, does not have this as a major concern.  E.g. an application where
> all data updates are done to DB2 tables and PDSEs.  Replace sequential
> datasets and PDSs with PDSEs, even if there is only one member.
>
> If you allow a dataset name to be set based on something only available
> during execution time,

Re: REXX as JCL replacement

2018-07-09 Thread John McKown

On Mon, Jul 9, 2018 at 11:12 AM Hobart Spitz  wrote:

> On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz  wrote:
>
> >  1. I don't recall anybody on IBM-MAIN claims that JCL is good.
> >
> There were such statements as "I like JCL", or similar.
>

And there are people who like Limburger cheese, too!

-- 
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

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

Re: REXX as JCL replacement

2018-07-09 Thread Seymour J Metz

SLEEP is an example of the right answer to the wrong question. The problem is 
that you can't safely allocate a bunch of datasets that may potentially be used 
by other jobs.

As for PDSE, it in some ways makes the situation worse; concurrent jobs can 
update the same members, but in a different sequence, leading  to bad updates.


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


From: IBM Mainframe Discussion List  on behalf of 
Hobart Spitz 
Sent: Monday, July 9, 2018 12:11 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement

On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz  wrote:

>  1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
There were such statements as "I like JCL", or similar.

>
>  2. Creative solutions are good if they solve the actual problem, not
> just an imaginary or irrelevant one.
>
I don't think anything I said was either.

>
>  2. Sleep does not address the deadly embrace problem.
>
I didn't claim that.  It is needed to do your up front ENQs in REXX.  You
still might have to exit with an error COND CODE if you can't get the ENQ
you need.  A single ALLOC does not give the TSU a message or time to free
up the dataset.

>
>  3. PDSE does not solve the problem.
>
You'll have to explain that.  From my reading of the doc., you can have
multiple readers and writers, in the same step or different JOBs opening
different members at the same time, provided the same member is not open
for OUTPUT by two different DCBs or JOBs/TSUs.  All this with SHaRed
access, i.e. no DISP=OLD or equivalent.  Note that I said, perhaps not
clearly enough, that the entire application, all foreground and background
accesses, must be SHaRed.  What am I missing?

Thanks.

>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Hobart Spitz 
> Sent: Monday, July 9, 2018 8:46 AM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Ward wrote:
> >What are the problems (perceived or real) that will be resolved by
> replacing JCL with REXX?
>
> I think that it's important to first understand the characteristics on
> which many people base their thinking that JCL is good and may never go
> away.  The point is important, and the basis is a valid concern.  The
> conclusion is wrong.  All it takes is understanding the problem and coming
> up with creative solutions.  As I describe below, DB2 based applications
> and those that use only PDSEs are likely to be good starting points.
>
> One valuable feature of z/OS batch processing is that all ENQs for the
> entire JOB are obtained before any step execution actually starts.  This is
> done to prevent a deadly embrace:  JOB A has exclusive access to dataset X
> and needs exclusive access to dataset Y.  JOB B has access to Y and needs
> exclusive on X.  Neither JOB can proceed until one is canceled, resulting
> in lost production.  Despite this being a useful service, there is no TSO
> equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
> SLEEP mechanism to allow for retries.
>
> Other repliers have answered Ward's question well, I was going to cut some
> of the text out of my draft, but didn't.  I think it is important to
> understand what z/OS batch processing does, and where possible, why, so we
> don't trivialize the effort or miss easy opportunities.  I'll share my best
> educated guesses with respect to the subject at hand.
>
> When a batch JOB becomes eligible for execution these actions, relevant to
> our subject, happen in this order:
>
>1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
>merged with the submitted JCL.  These are necessary for #2 below.
>2. Substitutions are processed.  This is needed for #3; if DSNs could
>change later, via substitution or IF, the ENQs would be incorrect.
>3. ENQs are obtained on all datasets.
>4. The EXECs for PGMs are processed, in order, one at a time.
>
> So any REXX implementation would have either to forgo do initial ENQs, or
> commit to not changing DSNs during processing, or observe certain
> conventions.  These conventions could include the following, one or the
> other may be appropriate depending on the applications' needs:
>
>- Perform ENQs in a consistent order.  (Left as an exercise for the
>reader.  :-)  )
>- Do all ALLOCations up front, and free all exclusive allocations before
>a second set of ENQs is requested.
>- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
>or ALLOC failure, and taking appropriate action to
> recover/restart/suspend
>processing.  Initial ENQs are not required.  If implemented via a common
>routine, either site or vendor provided, this could be more viable.  A
>little additional coding to support automated restart might be needed;
> see
>also below on my first

Re: REXX as JCL replacement

2018-07-09 Thread Steve Smith

I'd like to point out that Hobart Spitz's long post is a great overview of
the practical and useful way that at least some JCL could be replaced with
REXX.  The details can be nit-picked eternally (and no doubt will be).

sas

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

Adjust CSSMTP Translation Table

2018-07-09 Thread Kayhan Tanriverir

Hi,
We started using CSSMTP in z/OSV2R3. We send e-mail with XMITIP in CSSMTP, but
Turkish characters are corrupted. I changed the charset to ISO8859-9, but
CSSMTP did not send e-mail. How can I adjust CSSMTP translation table.
I need help. Iyi calismalar, saygilar / Regards
_
Kayhan TANRIVERIR Senior Systems Programmer
VBT Bilgi Teknolojileri A.S.
www.vbt.com.tr

Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi/kişilere özeldir ve
gizlidir. Bu mesajın muhatabı olmamanıza rağmen tarafınıza ulaşmış olması
halinde mesaj içeriğinin gizliliği ve bu gizlilik yükümlülüğüne uyulması
zorunluluğu tarafınız için de söz konusudur. Mesaj ve eklerinde yer alan
bilgilerin doğruluğu ve güncelliği konusunda gönderenin ya da şirketimizin
herhangi bir sorumluluğu bulunmamaktadir. Şirketimiz mesajın ve bilgilerinin
size değişikliğe uğrayarak veya geç ulaşmasından, bütünlüğünün ve gizliliğinin
korunamamasından, virüs içermesinden ve bilgisayar sisteminize verebileceği
herhangi bir zarardan sorumlu tutulamaz.

This message and attachments are confidential and intended solely for the
individual(s) stated in this message. If you received this message although you
are not the addressee you are responsible to keep the message confidential. The
sender has no responsibility for the accuracy or correctness of the information
in the message and its attachments. Our company shall have no liability for any
changes or late receiving, loss of integrity and confidentiality, viruses and
any damages caused in anyway to your computer system.

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

Re: Adjust CSSMTP Translation Table

2018-07-09 Thread Seymour J Metz

Does it work with UTF-8? Is that an option?


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


From: IBM Mainframe Discussion List  on behalf of 
Kayhan Tanriverir <01bdd42c15bc-dmarc-requ...@listserv.ua.edu>
Sent: Monday, July 9, 2018 1:01 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Adjust CSSMTP Translation Table

Hi,
We started using CSSMTP in z/OSV2R3. We send e-mail with XMITIP in CSSMTP, but 
Turkish characters are corrupted. I changed the charset to ISO8859-9, but 
CSSMTP did not send e-mail. How can I adjust CSSMTP translation table.
I need help.   Iyi calismalar, saygilar / Regards 
_
Kayhan TANRIVERIR Senior Systems Programmer
VBT Bilgi Teknolojileri A.S.
http://secure-web.cisco.com/1HrzgkABT9pgxRTHmeYSMKtKUGWfzjLFAZ_iYOeC9afiGt6NF_tviKaS6S70zBXmQPiTYefs7-4nlgiu_3hYU8QgWZctrivqjSlaMEVihd2mYNm45J3HK5QqTXOC_cJjcend-EjNuc0-iFvgP1OgS1po7luQYMGKH-frKTE92jsXryZh8s3lk0EVXorVFSsMUEczdnlmQ9ISTpipac6HEy7JhlUeCoVmsGLChV2-nDZq5l-C2QL7hRPSsBf8S-Kav6aMQS8JsJoZI17pmigmIKqJ3aOLJVmAjran7TnO9dl7i3dA2D2z7Wx9VQH3SaOETzN9cN3e82IZ-nzgmulr5iZyDfY7TfbP5KfLA2MVJrvEHCpcf0-zY9u5IJPLHE9QnyP-vyYA-IPDqDaQQOXvyhAGppMY4rFAsx7e8lTjHH9o-j3Kh7-oDeqj0itB2F-d3/http%3A%2F%2Fwww.vbt.com.tr

Bu mesaj ve ekleri mesajda gönderildiği belirtilen kişi/kişilere özeldir ve 
gizlidir. Bu mesajın muhatabı olmamanıza rağmen tarafınıza ulaşmış olması 
halinde mesaj içeriğinin gizliliği ve bu gizlilik yükümlülüğüne uyulması 
zorunluluğu tarafınız için de söz konusudur. Mesaj ve eklerinde yer alan 
bilgilerin doğruluğu ve güncelliği konusunda gönderenin ya da şirketimizin 
herhangi bir sorumluluğu bulunmamaktadir. Şirketimiz mesajın ve bilgilerinin 
size değişikliğe uğrayarak veya geç ulaşmasından, bütünlüğünün ve gizliliğinin 
korunamamasından, virüs içermesinden ve bilgisayar sisteminize verebileceği 
herhangi bir zarardan sorumlu tutulamaz.

 This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee you are responsible to keep the message confidential. The 
sender has no responsibility for the accuracy or correctness of the information 
in the message and its attachments. Our company shall have no liability for any 
changes or late receiving, loss of integrity and confidentiality, viruses and 
any damages caused in anyway to your computer system.

--
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: REXX as JCL replacement

2018-07-09 Thread Ed Jaffe


On 7/9/2018 8:09 AM, Seymour J Metz wrote:

  1. I don't recall anybody on IBM-MAIN claims that JCL is good.


Even Fred Brooks (who led the IBM team that invented JCL) calls it "the 
worst programming language ever designed anywhere by anybody for any 
purpose..."


https://youtu.be/8c0_Lzb1CJw?t=4735

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

IEC614I Scratch

2018-07-09 Thread Hervey Martinez

We have instances where some GDG files don't get deleted while these are in 
ML1; thus, they end up generating errors during Secondary Space Management 
generating a RC=20 RSN=98.

I opened a ticket with IBM and they tell me that there should be an IEC614I 
Scratch message being generated and this is what we need to correct this issue.

I have not been able to locate this msg, I have looked in HSM, several hundred 
job listings and several days of syslog files for all of our LPARS. I can't 
seem to find this error.

Anybody have a clue as to where I can find this message in my system?

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

Re: Adjust CSSMTP Translation Table

On Mon, 9 Jul 2018 17:01:12 +, Kayhan Tanriverir wrote:

>Hi,
>We started using CSSMTP in z/OSV2R3. We send e-mail with XMITIP in CSSMTP, but 
>Turkish characters are corrupted. I changed the charset to ISO8859-9, but 
>CSSMTP did not send e-mail. How can I adjust CSSMTP translation table.
>I need help.   Iyi calismalar, saygilar / Regards 
>_ 
> 
What CCSID are you using on the z?  In:
z/OSIBM Unicode Services User's Guide and
Reference
Version 2 Release 3
SA38-0680-30

I find:
CONFIGDD: DD
Configuration DD, allowing users to customize the default EBCDIC and ASCII 
CCSID for input and output. If not provided, EBCDIC CCSID 1141 and ASCII CCSID 
923 are used.
Format of configuration:
1. 2.
3.
Lines starting with ‘#’ are taken as Comments.
DEFAULT_EBCDIC_CCSID is the keyword of default EBCDIC CCSID. The value after 
the ‘=’ is taken as the EBCDIC CCSID.
DEFAULT_ASCII_CCSID is the keyword of default EBCDIC CCSID. The value after the 
‘=’ is taken as the EBCDIC CCSID.

Is this relevant?  Are you doing anything like this?

-- gil

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

Re: IEC614I Scratch

2018-07-09 Thread Mark Jacobs - Listserv


Is it being suppressed either using MPFLSTxx or AutoOps? Either one can prevent 
the message from being written to the log.

Hervey Martinez wrote on 7/9/18 2:39 PM:

We have instances where some GDG files don't get deleted while these are in 
ML1; thus, they end up generating errors during Secondary Space Management 
generating a RC=20 RSN=98.

I opened a ticket with IBM and they tell me that there should be an IEC614I 
Scratch message being generated and this is what we need to correct this issue.

I have not been able to locate this msg, I have looked in HSM, several hundred 
job listings and several days of syslog files for all of our LPARS. I can't 
seem to find this error.

Anybody have a clue as to where I can find this message in my system?

--
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 
'phish...@meredith.com'.



--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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: REXX as JCL replacement

Steve, thanks for the kind words.

One afterthought that might improve the use of the TSO PROC, if one is so
inclined.  Use //   EXEC TSO,CMD=REXXTRY ,  Put REXXTRY into one of the
SYSEXEC/SYSPROC libraries, if it's not already there.  It gives access to
most of REXX to the SYSTSPRT records.  REXXTRY is roughly to REXX what csh
is to C.  If you don't have REXXTRY, you can find the source on the web.  I
would recommend one of the IBM versions.

For example (untested):

   1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
   2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
   3. *//   EXEC TSO,CMD=REXXTRY*
   4. *//SYSTSIN  DD *  Recommended DD to avoid conflicts with SYSIN
   use.*
   5. *Trace = "e" /* Unique to REXXTRY. Show error commands. You may
   prefer "c". */*
   6. *"profile"*
   7. *call outtrap "Lines."*
   8. *"st myjobname"*
   9. *call outtrap "off"*
   10. *parse var Lines.1 "(" JESNum ")" /* cutting some corners here in
   interest of brevity */*
   11. *"%myrexpgm"*
   12. *OutDSN = "out.data(results)"*
   13. *DSStat = sysdsn(OutDSN)*
   14. *if DSStat == "OK" | DSStat == "MEMBER NOT FOUND" then **DSOptions =
   "shr"*
   15. *if DSStat == "DATASET NOT FOUND" then **DSOptions = "new
   catalog cyl space(10 10) dsntype(library)"*
   16. *if var("DSOptions") == "LIT" then do;** say time() Lines.1 OutDSN
   "-" DSStat; **exit 20; **end*
   17. *"alloc reuse dd(sysut2) dsn("OutDSN")" DSOptions*
   18. *if RC <> 0 then exit RC*
   19. *"alloc reuse dd(sysin) dummy"*
   20. *"alloc reuse dd(sysut1) shr dsn('my.in.data')"*
   21. *"call *(iebgener)" /* Trace = "e" reports failures; GENER stops if
   SYSIN/SYSUT1 missing/invalid. */*
   22. *"free dd(sysut2, sysin, sysut1)"*
   23. *//*

Here we can use SHR with our output PDSE if it already exists.

You must put ALLOCs, TSO CALLs, FREEs, and any other commands with
parentheses or characters that REXX is sensitive to, in quotes or quotation
marks.  Quotation marks ( " ) are prefered if you have fully qualified
dataset names with quotes.  See line 20.

Lines 12 thru 18 could form the basis of a common, external routine, since
it may be needed often.

Personally, I think this approach is so much better that I might set
REXXTRY as the default &CMD value in the PROC.  On the other hand, you
don't have multil-line commands, continuations, the ability to supply
internal routines or SIGNAL handlers, so at some point it becomes
preferable to make a long sequence of commands into a program of its own.

Maybe this is what a JCL replacement could look like.  Add in some commands
for compatibility (e.g. JCL DD, JCL STEPEXEC, JCL SET, etc.), and things
look rosier and practical.

Caution:  DD DDNAME=... and "alloc ddname(...)" are two completely
different animals.

OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Mon, Jul 9, 2018 at 12:56 PM, Steve Smith  wrote:

> I'd like to point out that Hobart Spitz's long post is a great overview of
> the practical and useful way that at least some JCL could be replaced with
> REXX.  The details can be nit-picked eternally (and no doubt will be).
>
> sas
>
> --
> 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: IEC614I Scratch

2018-07-09 Thread Lizette Koehler

So this is the message you expect?

IEC614I   func FAILED - RC rc, DIAGNOSTIC INFORMATION IS (diaginfo) sss, ser, 
dsname DATA SET NAME IS IN USE BUT YOU HAVE AUTHORITY TO OVERRIDE THIS TEST

Routing code 11 Descriptor code 4


Do you have this code in SYSLOG HARDCOPY ?

If you are JES2, and use SDSF - go to Menu bar in LOG O and use FILTER for 
IEC614*

If you have a tool like OPS/MVS - Use OPSBROWSE and select message IEC614* 
place curser on an entry and hit Enter.  It will describe in detail how the 
message is seen by z/OS and OPS/MVS

Look at the MPF list and the AUTOR00 member in SYS1.PARMLIB



Lizette 
 

> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of
> Hervey Martinez
> Sent: Monday, July 09, 2018 11:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: IEC614I Scratch
> 
> We have instances where some GDG files don't get deleted while these are in
> ML1; thus, they end up generating errors during Secondary Space Management
> generating a RC=20 RSN=98.
> 
> I opened a ticket with IBM and they tell me that there should be an IEC614I
> Scratch message being generated and this is what we need to correct this
> issue.
> 
> I have not been able to locate this msg, I have looked in HSM, several
> hundred job listings and several days of syslog files for all of our LPARS. I
> can't seem to find this error.
> 
> Anybody have a clue as to where I can find this message in my system?
> 

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

Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-09 Thread Clark Morris

[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>On 7/9/2018 8:09 AM, Seymour J Metz wrote:
>>   1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
>Even Fred Brooks (who led the IBM team that invented JCL) calls it "the 
>worst programming language ever designed anywhere by anybody for any 
>purpose..."

How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL.  How does z/OS
JCL compare with VSE JCL?  My memories of DOS360 JCL probably are
irrelevant.

Clark Morris
>
>https://youtu.be/8c0_Lzb1CJw?t=4735

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

Re: REXX as JCL replacement

On Mon, 9 Jul 2018 15:20:07 -0400, Hobart Spitz wrote:

>Steve, thanks for the kind words.
>
>One afterthought that might improve the use of the TSO PROC, if one is so
>inclined.  Use //   EXEC TSO,CMD=REXXTRY ,  Put REXXTRY into one of the
>SYSEXEC/SYSPROC libraries, if it's not already there.  It gives access to
>most of REXX to the SYSTSPRT records.  REXXTRY is roughly to REXX what csh
>is to C. 
>
Not really.  And you stated the restrictions yourself.  And IBM wisely 
originally
implemented the POSIX shell, only later caving to pressure from (t)csh 
partisans.

>For example (untested):
>
>   1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
>   2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
>   3. *//   EXEC TSO,CMD=REXXTRY*
>
That's more cumbersome than than just submitting an old-fashioned IEBGENER job.

The problem isn't JCL; it's OS.

I don't see that you allocated SYSPRINT.

Try doing the same with UNIX files and OMVS.  It's easier.

>...  On the other hand, you
>don't have multil-line commands, continuations, the ability to supply
>internal routines or SIGNAL handlers, ...

-- gil

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

Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

2018-07-09 Thread Farley, Peter x23353

WFL, Work Flow Language, actually.  I had a very brief association with an 
employer's Burroughs 6500 long ago, and at the same time I actually wrote a 
term paper for an Operating Systems Survey course I was taking that compared 
WFL, MVS JCL and CDC6600 Control Language.

WFL was the clear winner by a huge margin.

Thanks for the lovely memory.  I really enjoyed researching and writing that 
paper.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Clark Morris
Sent: Monday, July 9, 2018 3:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

 [Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:

>On 7/9/2018 8:09 AM, Seymour J Metz wrote:
>>   1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
>Even Fred Brooks (who led the IBM team that invented JCL) calls it "the 
>worst programming language ever designed anywhere by anybody for any 
>purpose..."

How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL.  How does z/OS
JCL compare with VSE JCL?  My memories of DOS360 JCL probably are
irrelevant.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Primary & secondary space values in DFSORT's dynamic work space allocation.

It might be worth pointing out what might be a little known fact.  Any
allocation, primary or secondary, can be done in up to 5 extents.  That
means that, on a highly fragmented pack, SPACE=(CYL,(5,5)) might only get
16 cylinders (in 16 extents) before running out of extends.  Fragmentation
at this level is unusual on modern systems, but I wouldn't assume that all
allocations were in single extents.  If you have significant fragmentation,
perhaps because work packs are not managed like other packs, you may be
dealing with a different problem then you think.

If you think specifying FILSZ might help, have you considered adding a REXX
EXEC that issues a CALL LISTDSI or a SQL SELECT COUNT(*) ... and that
calculates a crude estimate of space from that information.  The result
could then be passed to the COBOL program, either as a parm or in a VIO
dataset, and the COBOL program could pass that to sort.

Have you tried it and are getting some kind of negative result, or are you
just in the planning stage?



OREXXMan
JCL is the buggy whip of 21st century computing.  Stabilize it.
Put Pipelines in the z/OS base.  Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.

On Wed, Jul 4, 2018 at 3:36 PM, Peter Hunkeler  wrote:

> Some background, first.
>
> I was asked to help a COBOL application calling DFSORT internally via
> INPUT / OUTPUT PRODECURE (E15/E35) interface. The input data size is
> unknown, but varying greatly. FILESZ cannot be supplied. So, DFSORT has no
> way to calculate the required disk work space.
>
>
> The application was asked to change from JCL allocated SORTWKnn to
> dynamically allocated sort work space.
>
>
> DFSORT options DYNALLOC, DYNAPCT, and DYNSPC are the options used to help
> DFSORT optimally allocate the sort work space. Some extracts from the
> manual are listed below.
>
>
> I read the relevant parts in the Installation & Customization, the
> Application Programmer, and the Tuning Guide, but still I'm not sure I
> understand how and when the work space data set are allocated. The disk
> space allocated is of special interest here.
>
>
> Suppose: DYNALLOC=(,8),DYNAPCT=50,DYNSPC=2400
>
>
> Now here are the statements with a lot of uncertainty, and question marks.
> I'd appreciate confirmation, or correction where I'm wrong.
>
>
> a) DFSORT will allocate 8 initial work data sets with primary space, and
> 50% of that, i.e. 4 reserve data sets with zero space initially. The total
> amount of primary space is the equivalent of 2400 MB. The manual says this
> is the total over *all* work data sets.
>
>
>
> b) So, the primary space for each of the 12 work data sets is 200MB, but
> only the 8 initial ones are allocated with that primary amount. The 4
> reserved data sets are initially allocated with 0 space, but 200 MB will be
> allocated once DFSORT decides it needs them.
>
>
>
>
> c) The secondary space is said to be 20% of the primary, i.e. 480MB. It is
> not clear to me, whether this means any secondary extent is 480MB, or
> whether the secondary value is 480MB / 12, i.e. 40MB. This greatly
> influences the theoretical total amount of workspace.
>
>
>
>
> d) When DFSORT decides it needs more space, will it extend one, some, or
> all of the additional work data sets? At this time, the initial work data
> set have probably been extended to their maximum size (1 x primary + 15 x
> secondary). Will the additional data sets be extended by the primary amount
> only, and will grow later as needed?
>
>
>
>
> e) The first extension amount used with d) will be the primary amount
> calculated above, i.e. 200MB, right? Later, these additional data sets can
> be expanded by the secondary extent value, up to 15 times. Correct?
>
>
>
>
>
> Extracts from the Application Programmer's Guide:
>
> DYNAPCT=x
>
> specifies additional work data sets to be dynamically allocated with zero
> space. DFSORT only extends these data sets when necessary to complete a
> sort application.
>
> x specifies the number of additional work data sets (y) as a percentage of
> the maximum number of dynamically allocated work data sets
> (DYNALLOC/DYNALOC n value) in effect.
>
> DYNSPC=n
>
> DYNSPC=n temporarily overrides the DYNSPC installation option, which
> specifies the total default primary space allocation for all of the
> dynamically allocated work data sets when the input file size is unknown.
>
> ..., DFSORT uses the DYNSPC value in effect as the approximate amount of
> primary space. DFSORT uses 20% of the primary space as secondary space.
> Although the primary space is always allocated, secondary space (up to 15
> extents) is only allocated as needed.
>
> n specifies the total default primary space, in megabytes, to be allocated
> for all dynamically allocated work data sets (n is not the primary space
> for each data set).
>
>
> --
> Peter Hunkeler
>
> ---

Re: REXX as JCL replacement

2018-07-09 Thread Andrew Rowley


On 9/07/2018 10:46 PM, Hobart Spitz wrote:


Basically, JCL is so far from real a programming language, that I can't
describe it.

That's because JCL isn't a programming language. There are plenty of 
other languages that also suck as programming languages e.g. HTML, XML, 
JSON, but that's not what they are supposed to be.


JCL is really a kind of definition language. In programming language 
terms it is more like a set of classes in OOP than a language in itself: 
you have a job, which has steps, steps have DDs etc. The syntax is old 
fashioned, but the concepts are very much OOP. It would be relatively 
simple to create a set of classes in your OOP language of choice to hide 
the syntax - just create a Job object, add Step objects, add 
DataDefinition objects etc. and have a Submit method emit JCL.


If I want to write a program, I will choose a programming language. If I 
want to define a unit of work to the system, JCL does a pretty good job. 
I definitely prefer JCL to long command lines with multiple switches and 
options defining input and output files, which is the non-z/OS equivalent.


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: REXX as JCL replacement

2018-07-09 Thread Charles Mills

I wrote a product that as part of its processing generated JCL. (It was a side 
chore; it was not a "JCL-generator.") And yes, JCL mapped really well to an OOP 
sort of approach. Within DDs you have positional operand classes and keyword 
operand classes, and then various children of those, and so forth.

RECFM objects stood on their own, so an abstract file object could have a 
RECFM, and then you could assign that RECFM object to a DD statement for that 
file.

It sounds weird but it actually mapped quite well.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Andrew Rowley
Sent: Monday, July 9, 2018 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

On 9/07/2018 10:46 PM, Hobart Spitz wrote:
>
> Basically, JCL is so far from real a programming language, that I can't
> describe it.
>
That's because JCL isn't a programming language. There are plenty of 
other languages that also suck as programming languages e.g. HTML, XML, 
JSON, but that's not what they are supposed to be.

JCL is really a kind of definition language. In programming language 
terms it is more like a set of classes in OOP than a language in itself: 
you have a job, which has steps, steps have DDs etc. The syntax is old 
fashioned, but the concepts are very much OOP. It would be relatively 
simple to create a set of classes in your OOP language of choice to hide 
the syntax - just create a Job object, add Step objects, add 
DataDefinition objects etc. and have a Submit method emit JCL.

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

Re: REXX as JCL replacement

2018-07-09 Thread Steve Smith

Ed Jaffe posted a video... it seems he worked some magic on it so that it's
only an excerpt from a longer presentation.  It runs about 5 minutes, and
it's well worth that.  Frederick P. Brooks had many talents, one of which
is he's an engaging and funny speaker.

The upshot (for our purposes) of his talk was that while they had a lot of
smart people designing some smart languages, JCL somehow appeared without
ever being planned or designed.  He *emphatically* states it's "the worst
language ever created, for any purpose, ever".  Twice, if I counted
correctly.

Learning JCL is like learning Sheephead... at some point, you start to
think people are just making sh*t up as they go along.  Come to think of
it, I think they probably did.

I've probably said this before, but I like JCL too, it's an interesting
puzzle-solving thing, like sudoku.  But I never thought it was the "right"
way to do it.

sas

On Mon, Jul 9, 2018 at 7:15 PM, Andrew Rowley 
wrote:

> On 9/07/2018 10:46 PM, Hobart Spitz wrote:
>
>>
>> Basically, JCL is so far from real a programming language, that I can't
>> describe it.
>>
>> That's because JCL isn't a programming language. There are plenty of
> other languages that also suck as programming languages e.g. HTML, XML,
> JSON, but that's not what they are supposed to be.

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

Re: REXX as JCL replacement

On Mon, 9 Jul 2018 16:45:00 -0700, Charles Mills wrote:

>I wrote a product that as part of its processing generated JCL. (It was a side 
>chore; it was not a "JCL-generator.") ...
>
I've done that a lot.  I like to keep JCL embedded in POSIX shell scripts as 
here-documents.

o Not Rexx, first because Rexx has no instream data facility.

o I can use shell looping to generate multiple similar job steps.  I might
  do somewhat the same with PROC calls, but I think shell source is more
  compact than JCL.  And finer granularity: I can write a shell function
  that generates a single DD statement -- not so with a JCL proc.

o I can substitute shell variables in JCL commands and JES instream data alike.
  I started doing this before SET and DD *,SYMBOLS existed.  It still works 
well.

o Like Rexx it's free of the apostrophe catastrophe.  Metacharacters arising
  from symbol expansion have no metasignificance -- they become ordinary
  text with no need to escape, protect, or double them.

On Mon, 9 Jul 2018 20:11:17 -0400, Steve Smith wrote:

>Ed Jaffe posted a video... it seems he worked some magic on it so that it's
>only an excerpt from a longer presentation.  It runs about 5 minutes, and
>it's well worth that.  Frederick P. Brooks had many talents, one of which
>is he's an engaging and funny speaker.
>
>The upshot (for our purposes) of his talk was that while they had a lot of
>smart people designing some smart languages, JCL somehow appeared without
>ever being planned or designed.  
>
I see much the same about HLASM.  It has a woeful lack of lexical uniformity.

> ...He *emphatically* states it's "the worst
>language ever created, for any purpose, ever".  Twice, if I counted
>correctly.
>
>Learning JCL is like learning Sheephead... at some point, you start to
>think people are just making sh*t up as they go along.  Come to think of
>it, I think they probably did.
>
https://en.wikipedia.org/wiki/Sheepshead_(game)
??? Calvinball?

-- gil

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

Re: REXX as JCL replacement

2018-07-09 Thread David Crayford


On 10/07/2018 7:15 AM, Andrew Rowley wrote:

On 9/07/2018 10:46 PM, Hobart Spitz wrote:


Basically, JCL is so far from real a programming language, that I can't
describe it.

That's because JCL isn't a programming language. There are plenty of 
other languages that also suck as programming languages e.g. HTML, 
XML, JSON, but that's not what they are supposed to be.



Java Batch (JSR 352) has basically re-implemented JCL using XML. Now 
that must really suck!





JCL is really a kind of definition language. In programming language 
terms it is more like a set of classes in OOP than a language in 
itself: you have a job, which has steps, steps have DDs etc. The 
syntax is old fashioned, but the concepts are very much OOP. It would 
be relatively simple to create a set of classes in your OOP language 
of choice to hide the syntax - just create a Job object, add Step 
objects, add DataDefinition objects etc. and have a Submit method emit 
JCL.


If I want to write a program, I will choose a programming language. If 
I want to define a unit of work to the system, JCL does a pretty good 
job. I definitely prefer JCL to long command lines with multiple 
switches and options defining input and output files, which is the 
non-z/OS equivalent.


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: Task Flow Recorder for CICS

2018-07-09 Thread Timothy Sipples

You might want to ask for reviews on the CICS-L mailing list if you haven't
already.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Re: Sysplex between two hardware

2018-07-09 Thread Timothy Sipples

I should also respond to this part:

Radoslaw Skorupka wrote:
>...for availability reasons one should avoid having CF
>and z/OS LPAR on the same hardware, which means

That's not phrased as IBM would phase it, and it's not correct as written.

Even when there's some merit in physically separating the CF, the physical
separation need only be between that CF and the particular z/OS Parallel
Sysplex it serves. Having other z/OS LPARs, even LPARs that are
participating in other Parallel Sysplexes, on the same machine as the CF is
consistent with IBM's recommendations here.

David Raften has published a whitepaper (updated in May, 2018) that
explains the various CF configuration options. The direct link to the
current edition is here:

https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf

If you're reading this post substantially later than July, 2018, then
please check first to see whether there's yet another updated edition.
David discusses what I just described, the "Logical Stand-Alone CF"
configuration, starting on page 9 of that whitepaper.

Just because something has merit doesn't automatically mean it has merit
for the next available increment of resources (budget, effort, etc.) I
always try to approach business risk reduction holistically, in end-to-end
business service terms starting with the most critical business services.
If adopting a stand-alone CF configuration is the highest, next best use of
available resources within that end-to-end service context, great. And
isn't it wonderful how much flexibility you have with these technologies,
to craft (and re-craft) the most appropriate configurations for the desired
business outcomes?

Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com

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

Netiquette (was:Sysplex between two hardware)

2018-07-09 Thread Peter Hunkeler


Peter,You've been asking for help here. I consider it very impolite that you 
don't answer peoples inquiries for details.

--
Peter Hunkeler


 Von: Peter  An:   
IBM-MAIN@LISTSERV.UA.EDU Betreff: Sysplex between two hardware Datum: 06.07.18, 
04:45


Hi

We are looking up for a solution where we need a LPAR to have a hot standby
in other LPAR running in a different machine .

As we are trying to create a sysplex relationship between two LPARS running
in a different machines .

Apology for my ignorance and is it possible ?

Peter

--
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: Netiquette (was:Sysplex between two hardware)

2018-07-09 Thread Peter

I apologise as I was on personal leave and I will be back on Monday.

I honestly appreciate all the replies and query for which I can
collectively chose and research


Thanks again

On Tue 10 Jul, 2018, 10:02 AM Peter Hunkeler,  wrote:

>
> Peter,
> You've been asking for help here. I consider it very impolite that you
> don't answer peoples inquiries for details.
>
>
> --
> Peter Hunkeler
>
>
>
> *Von: * Peter 
> *An: * IBM-MAIN@LISTSERV.UA.EDU
> *Betreff: * Sysplex between two hardware
> *Datum: * 06.07.18, 04:45
>
> Hi
>
> We are looking up for a solution where we need a LPAR to have a hot
> standby
> in other LPAR running in a different machine .
>
> As we are trying to create a sysplex relationship between two LPARS
> running
> in a different machines .
>
> Apology for my ignorance and is it possible ?
>
> Peter
>
> --
> 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: Sysplex between two hardware